#Workbench 场景工作台

#给业务一个可反复打开的入口

Workbench 是团队托管的 Web 应用层，适合固定流程、多人协作、看板、控制台和现场投屏。企业可以围绕自己的业务装配或开发应用，让人类在界面中操作，让数字员工承接后台工作。

应用与数字员工共享业务数据、任务对象和组织上下文。人在界面上登记信息，员工可以读取并处理；员工回写业务结果后，应用再展示对应状态。这个闭环需要开发者明确设计数据和交接规则。

#选择交互形态与构建路径

开发者路径提供 React 脚手架和认证支持，可按需要选择平台对象、Taskboard 与 Arcubase 能力。涉及业务数据时，应明确目标应用并生成对应类型，避免猜测字段和标识。详细流程见 构建 Workbench。

#官方开发入口与能力选择

创建、扩展和发布应用统一使用 Workbench App Development Skill，具体命令、验收和排错以仓库中的 SKILL.md 及引用文档为准。它支持 Codex、Claude Code 和 WorkBuddy；这里说明团队业务准备，不另造一套发布命令。

开发前确认目标 team、账号、使用者、业务对象、数据来源和维护人。需要团队、成员、员工、会话或文件时选择 Octopus 客户端；处理任务和项目时选择 Taskboard 客户端；需要持久化业务记录时选择 Arcubase 及生成的强类型客户端。不是每个应用都必须接入 Arcubase；使用已有应用时先核对结构，新建时先确定字段、关系和访问范围。

已有应用先检查现状，新应用使用官方脚手架。接入选定的真实数据后，本地验证登录、页面和业务操作；向交付负责人展示本地结果并确认后再构建、发布。发布任务的发起与完成分别记录，最终还要在发布地址重验业务闭环。

#示例：销售跟进工作台

工作台展示客户、商机和待跟进任务，业务人员选择目标并补充跟进信息。销售助理读取同一组数据、检查必填字段、更新商机状态并创建后续任务；管理人员查看汇总与异常。

设计前应明确四件事：用户反复查看和操作什么，应用读写哪些表，哪位员工承接任务，以及谁长期维护应用。表与任务都应使用同一业务标识，避免界面和员工各自保存一份状态。

#权限、发布与验收

应用默认需要登录，使用平台账号体系。应用设置可维护应用信息与访问域名，修改后应重新打开实际业务页面并验证登录流程。可以明确指定公开页面，例如活动入口；公开页面可访问，不代表访客能访问团队数据或执行受限操作。公开页和登录后的业务页面应分别设计与验收。第三方密钥通过团队受控配置绑定，不写进源代码或构建产物；SDK 中存在方法也不代表当前用户有调用权限。

发布是异步过程，提交构建产物后仍需确认部署已生效。验收应核对用户身份、数据读写、任务交接、权限失败与最终应用地址，同时验证界面显示与业务表一致。验收中应直接打开并刷新业务路由，确认登录后回到目标页面；搜索、筛选、创建和修改必须真实生效，写入后可重新查询。页面应展示真实记录或真实空状态，不能用演示数据冒充接入结果。另用访客测试指定公开页可打开、受保护页和团队数据不可访问。

交付记录保留目标 team、选用能力、本地验收结果、项目与发布任务标识、最终地址及发布后验证结果。企业获得的是可开发和托管场景应用的底座，具体功能、数据与维护责任需随项目确定。参见 Workbench 示例方案、执行与应用工具 和 文档依据与边界。