#Workbench 业务应用示例方案

本页是待按企业实际环境配置与验证的示例设计，不代表已经部署或验收通过的客户成功案例。

#场景目标与输入

为销售或履约 team 创建一个可反复使用的业务工作台，让成员查看客户、商机或订单，筛选待处理事项，提交业务记录并交接数字员工任务。具体功能由企业流程确定，平台提供应用开发和托管底座。

开始前准备目标团队、账号、使用角色、已有数据结构、业务流程和维护人。一次性报告或已有页面的低频操作通常无需另建应用；先确认界面确实能改善反复发生的业务操作。

#CRIDO：从需求到应用交付

此表描述应用交付闭环；应用内每项业务操作还应按 CRIDO 分清触发、输入、执行与结果，不能用「应用已发布」代替全部业务验收。

#Team、前置条件与能力组合

在目标 team 中明确业务负责人、开发与维护人、使用成员及承接任务的数字员工。准备各角色的测试账号和真实样例记录，确认任务项目、业务表和成果工作区的访问权限。员工可用范围与应用使用者的访问范围分别验证，具体见 Team 方案设计。

使用 Workbench App Development Skill，执行步骤以其 SKILL.md 为准。它支持 Codex、Claude Code 和 WorkBuddy，方案组合 Vibe Coding、octopus-cli 和实际需要的客户端，不另造命令或参数。

不是每个应用都需要 Arcubase。已有数据应用先核对结构，新建时先明确字段、关系和访问范围；未接入真实数据前，演示数据只能用于界面讨论，不能作为业务已接通的证据。

#开发、确认与发布

1. 确认业务范围、团队、账号和数据来源；已有应用先检查当前实现。
2. 新应用使用官方脚手架；已有应用保留现有工程与改动，仅补充必要客户端和功能，再接入真实记录。
3. 在本地验证登录后返回业务页面、列表数据、搜索筛选及新增修改。
4. 将本地结果展示给交付负责人，确认后按开发 skill 构建并发布。
5. 检查发布状态，在最终地址直接打开并刷新业务路由，再次完成真实业务操作。

以新增一条客户跟进为例：页面提交后重新查询该记录，员工能读取并处理关联任务，成员返回工作台可看到一致结果。任务责任、状态与业务记录使用可关联的标识，避免出现页面完成而后台没有变化。

应用设置可维护信息与访问域名，调整后重验入口和登录。需要公开活动入口时，显式确定公开页面；公开页可打开，不代表访客可以访问团队数据或受保护操作。公开页面与登录后的业务页面分开验收。

#验收证据与失败测试

交付记录保留目标 team、选用能力、本地验收结果、项目和发布任务标识、最终地址及发布后验证结果。检查真实记录或真实空状态、写入后的回查、任务接收人及应用页面的一致性。仅有代码、截图或发布任务已提交，不构成交付完成。

测试未登录访问、用户越权、数据为空、写入失败、任务接收人无权限和发布失败；界面应如实呈现结果，不能在操作失败后显示成功。对公开页，用访客账号验证指定页面可打开，同时确认受保护页面和团队数据不可访问。详见 Workbench 平台能力、构建 Workbench 与 验收。