一位客服怎样在一个页面里办好预约改期？

已经能查数据了，为什么还要做一个应用？

分析界面允许人不断换角度提问，适合查原因、比较群体、寻找规律。阿宁面对的却是一件反复发生的工作：每次接到改期请求，都要查看相同几类信息，作出选择，再提交修改。她需要的界面应该把这条办理顺序组织清楚，让重要内容在恰当的时候出现。

Workshop 正是用于搭建这类交互业务应用的工具。它以业务对象为主要数据基础。假设团队已经定义“预约”“导览场次”和“讲解员”，并建立它们之间的关系，页面便可以直接使用这些对象的属性和关联。阿宁看到的“明天下午三点预约”，背后就是一条可以被查找、关联和修改的业务记录。

这种方式为什么能减少开发？因为一些常用工作已经有了共同基础：对象提供业务信息，组件提供表格和表单等界面，函数提供可复用逻辑，操作定义规定怎样修改记录。新页面可以把这些能力组合起来，团队不必每次重新搭建数据查询、业务规则和整套前端交互。

原文用“没有开发团队也能搭建应用”强调这类复用带来的效率。真正省下的主要是许多页面的重复实现。数据接入、对象含义、复杂逻辑和外部接口仍需要有人维护。先把这个前提放清楚，我们再来看：当阿宁点击某条预约时，页面里发生了什么。

本节事实核查：官方资料 [1]

点中一条预约，详情为什么会跟着切换？

团队把待处理预约放在左侧表格中。阿宁搜索团体名称，点中编号 A102 的预约，右侧便显示原场次、人数和联系信息。页面看似只是“点一下”，实际需要记住一个当前选择：现在正在处理的是 A102。

这个被页面记住的值，叫变量。表格组件输出选中的预约，详情组件把它作为输入，再读取相应属性和关联对象。用户点击或切换选项后发生的界面行为，叫事件。事件可以更新变量、打开面板或者切换页面。变量保存当前情况，事件推动情况变化，组件据此展示对应内容。

因此，左侧列表和右侧详情能联动，并不需要为每一条预约单独写一个页面。它们共享“当前预约”这个变量。同样的结构还可以驱动下方的时间安排：阿宁选中另一个目标场次，比较区就显示那个场次的时段和人数。

界面组件可以围绕她眼下的疑问出现。甘特图用时间条帮助看出排期重叠；PDF 阅读器显示团体提交的材料；操作历史解释此前谁改过这条预约；透视表则适合按场馆或时间汇总一批记录。它们的价值来自各自承担了哪一段工作。现在阿宁已找到预约，接下来最想知道的，就是四点场次到底还能不能接待这 20 人。

本节事实核查：官方资料 [2]官方资料 [14]官方资料 [15]

“还剩 25 个名额”这个数字，是怎样算出来的？

剩余名额不一定是原始资料中现成的一列。它可能来自场次容量减去已经确认的人数，还要考虑哪些预约已取消、哪些预留仍有效。把这套计算写成可重复调用的逻辑，就是函数。Functions 可以读取对象属性、沿关系找到相关记录，再返回页面需要的结果。

在我们的方案里，页面把目标场次交给同一段函数，函数返回剩余名额以及计算所依据的当前预约。别的页面如果也要显示余量，可以复用这个逻辑。团队改进“有效预约”的定义时，便有明确的地方维护计算口径。函数复用的意义，是让相同业务问题有共同算法。

有些分析已经在其他工具里完成，也可以进入工作页面。比如把 Quiver 的预约趋势看板嵌入 Workshop，阿宁可以了解某场次是否经常临时满员；把 Vertex 的关系图嵌入，就能查看场次与展厅安排的关系。现有分析结果因此能在办理当下被使用。

如果阿宁临时想问“本周哪个场次经常满员”，页面可以接入 AIP Analyst 的自然语言分析；如果她不理解某个按钮的用法，可以打开 AIP Assist 的平台帮助或配置好的企业说明。Workshop 的事件也支持把模型输出逐步写入页面变量，让回答持续显示出来。这些能力最终仍围绕同一项工作提供所需信息。

界面联动有一个实现细节：Workshop 的事件依次执行，但不会自动等待前一步引发的全部后续计算结束。切换目标场次后，旧的剩余名额可能还显示片刻。于是这张虚构工作台把“正在重新计算”表达出来，在结果明确对应新场次以后，再让阿宁继续提交。到这一步，她已经看懂方案；接下来才是正式改变业务记录。

本节事实核查：官方资料 [2]官方资料 [3]官方资料 [16]官方资料 [17]官方资料 [18]官方资料 [19]

点击“确认改期”，为什么需要一个正式的业务操作？

阿宁选择四点场次以后，页面上的选择仍然只是待提交内容。真正改期，需要让原预约指向新的场次，并保留本次修改的相关信息。Foundry 用 Action 表达这种业务操作。严格地说，Action type 是预先定义的操作规则，Action 是按这套定义进行的一次提交。日常讨论里常把两者都简称为操作。

“改期预约”操作需要参数，例如要修改哪条预约、新场次是哪一场、此次人数是多少。表单是收集这些输入的地方。字段可以来自统一的参数定义，这样其他页面调用同一种操作时，也可以使用同样的输入含义。默认值、隐藏字段或页面对参数的覆盖，仍会影响实际送出的内容。

仅有输入还不够，操作还需要提交条件。三点时查到四点场有 25 个名额，几分钟后可能已被别人占用。我们的虚构方案在真正提交时再次检查最新容量，也检查这条预约是否允许改期。页面上的可选项帮助用户选择，提交条件则决定这次修改此刻能否成立。

权限也在这一刻变得具体。阿宁能看到预约，不代表她可以改所有场馆的预约；能使用“改期预约”，也不代表她有权更改它的业务规则。因此查看数据、提交操作、修改操作定义，是不同权限。

把业务修改放进统一操作后，页面、其他应用或后面的自动化都可以按同一规则办理。如果人数超过余量，操作给出能理解的拒绝原因；如果通过，预约记录才正式改变。这样，“按钮已经点过”才有机会对应一个清楚的业务结果。

本节事实核查：官方资料 [4]官方资料 [5]官方资料 [6]官方资料 [7]官方资料 [20]

如果有两个方案，能不能先看看各自的影响？

四点场次虽然能容纳 20 人，但另一场四点半的导览路线更合适。阿宁想先比较：各自剩多少名额，会不会影响讲解员安排，其他预约是否需要调整。此时直接修改正式记录再改回来，会让“比较方案”和“已经执行”混在一起。

这里介绍的是 Workshop 旧版 Scenarios，与第 03 篇提到的 Ontology scenarios 是不同机制；本节有关场景创建后不能修改等限制，仅针对这一旧版功能。它的用途，就是保存一组假设修改，并利用相关逻辑试算影响。一个场景可以表示“假设把 A102 改到四点”，另一个表示“假设改到四点半”。它保存相对基础数据的改动，相关计算在这些假设下给出结果，工作人员再据此选择。

这种模拟依赖已经表达出来的因素。系统知道场次容量和讲解员排班，才有机会算出相应影响；如果没有接入某段路线正在维修的信息，试算也不会自动知道。一个 Scenario 创建后不能原地修改，换一组假设需要创建新的场景。

这项 Workshop 能力在当前官方文档中标为 Legacy，即旧版。单场景的操作与编辑数量也有限制，详见本页适用说明。这里最值得理解的机制是：把假设中的改变单独保存，用同样的业务逻辑比较方案，再决定哪些改变真正生效。

本节事实核查：官方资料 [8]

预约改好了，为什么还不能立即说“全办完了”？

阿宁提交以后，Foundry 中的预约已经改到四点。不过接待人员使用另一个系统，团体联系人还需要收到通知。要把这次决定送出去，需要向外部系统发请求，这种机制叫 Webhook。它把 Foundry 内的操作接到外面的实际工作。

Webhook 在 Action 中有不同执行方式。writeback 会先请求外部系统，失败时阻止后续对象修改，并向用户显示错误。side effect 会先修改对象，再发外部请求，页面可能已经显示成功，通知或外部同步却仍在进行。前一种也不能保证跨系统全部成功：外部请求成功以后，Foundry 后续编辑仍有可能失败。

因此这张工作台把过程显示清楚：先出现“预约已改期，接待系统待同步”，收到外部确认后再显示完成。若请求超时，工作人员能继续查询或交给相关人员处理。重试也要识别同一笔业务，以免重复发送或重复创建记录。

完成之后，Action log 可以在启用并配置后记录成功的操作，帮助回看谁提交了什么；它不覆盖失败操作和所有其他路径产生的对象编辑。需要保留哪些参数，也要明确配置。

如果阿宁立即发现选错场次，受支持的对象存储与操作配置可以提供即时撤销，但通常只允许提交者在成功提示中操作，对象此后已有新编辑等情况也会使撤销失败。更重要的是，撤销对象修改不会收回已经发出的通知或外部请求。真正的业务撤回流程，需要把这些后果一并安排。

本节事实核查：官方资料 [9]官方资料 [10]官方资料 [11]

把这个页面交给所有客服使用

团队先保存修改，再发布给客服使用。Workshop 支持保存版本与发布版本分开管理，也可以配置保存时自动发布。页面采用哪种方式，会决定阿宁何时看到新界面。出现问题时可以回退页面版本，但已经改期的预约属于业务数据，不会随着页面一起回到过去。

这张工作台的价值，最终体现在阿宁完成一件事所需的来回切换更少，而且能看清依据和结果。不同岗位的数据范围、较小屏幕上的布局、加载时间和常见误操作，都会影响这种体验。页面搭出来之后，团队还需要继续维护这些日常细节。

有的团队需要更自由的页面布局或前端交互，可以评估 Slate，它支持可视化搭建并用 HTML、CSS、JavaScript 定制；有的团队希望接入已有门户，可以使用 OSDK，通过开发工具包查询业务对象、调用操作。Workshop 本身也可以嵌入自定义组件。这些选择都在围绕同一份业务定义建设不同的使用界面。

到此，阿宁已经能在应用里办理一条改期请求。可博物馆每天还有许多重复动作：检查材料、提醒补充、等待确认、再次核对、发通知。如果每一步仍要工作人员自己记着点击，工作量很快又会上来。下一篇要解决的，就是怎样让这些已经说清规则的步骤由系统持续组织起来。

本节事实核查：官方资料 [12]官方资料 [13]

适用边界与容易误解的地方

术语速查

Workshop

在 Foundry 内配置业务操作界面的应用构建工具。

Action

有参数与规则约束的一次业务修改。

变量与事件

变量保存界面状态；事件表达用户操作后的行为。

Webhook

平台向另一个系统发出的接口请求。

来源与核查

对应原文

Rahul Garg · 2026-08-12 · Vanyar

1. Workshop 官方概览对象数据、Actions、Functions 与应用定位。
2. Workshop 事件界面联动、AI 事件与执行顺序。
3. Functions对象计算及界面中的函数用途。
4. 操作参数参数与表单配置关系。
5. 提交条件提交时的业务和身份检查。
6. 操作权限执行权限及通知数据可见性。
7. 参数默认值本地变量默认值的优先关系。
8. Scenarios 旧版概念与限制Legacy 标记、不可变更及数量限制。
9. Webhook 两种模式调用时机、错误提示与事务局限。
10. Action log成功操作、配置和历史覆盖范围。
11. 操作撤销撤销资格及外部副作用限制。
12. Workshop 发布与版本保存、发布及自动发布开关。
13. 应用开发概览Workshop、Slate 及自定义应用路径。
14. 组件与变量组件输入输出和变量联动。
15. Workshop 变量变量关系和界面数据流。
16. 嵌入分析成果Quiver 与 Vertex 的嵌入能力。
17. Quiver 官方概览对象、时序分析与可嵌入看板。
18. Vertex 官方概览关系图、模拟及影响分析。
19. AIP Assist 官方概览平台帮助与自定义内容。
20. Action 与 Action type 官方概览区分操作定义、一次提交及其参数、规则和对象修改。

资料核对日期：2026-09-15。本文用中文概括原文观点，结合一手资料独立讲解；分析、图解和教学示例由本指南编写。主题清单用于检查议题覆盖，不表示逐项复写原文全部细节。产品能力以所在部署的当前官方文档与实际配置为准。