#开发 Workbench 应用

Workbench 为企业场景提供固定入口和持续维护的页面。它适合列表、筛选、表单、任务处理和多人反复使用的业务操作。一次性报告或低频操作可以先用现有界面；临时结构化确认可用 A2UI。

第一次构建完整场景时，从快速开始跟做 CRM 工作台与销售助理；环境准备见连接 WorkBuddy 或 Codex。

#使用官方维护的开发入口

开发团队已将创建、扩展、验收与发布流程统一维护在 Workbench App Development Skill。它支持 Codex、Claude Code 和 WorkBuddy。按该仓库首页安装后，开始新会话或重新加载技能，再使用 workbench-app-development。

原 workbench-vibe-coding-flow 仅保留迁移说明，已不再维护开发步骤。本站说明业务准备与交付要求；执行时阅读官方 SKILL.md 及其引用的命令契约，避免从多个版本拼接命令。

#选择需要的能力

不是每个应用都需要 Arcubase，本地对象和静态素材不构成创建数据库的理由。使用 Arcubase 时，先明确复用已有应用还是新建：前者核对应用标识、结构和稳定字段 key；后者先确认字段、关系和访问模型。不得静默创建存储或按名称猜标识。

#开发前准备

用CRIDO写清页面的业务入口、规则、输入、动作和结果，再确定：

• 当前账号、Profile、Host 与目标 Team。
• 用户查看和操作哪些业务对象，数字员工承担哪部分任务。
• 哪些资源已有，哪些需要创建，谁负责授权和确认。
• 页面清单、正常及失败状态、维护责任人。

创建新应用使用官方 React 脚手架；已有项目先检查当前工程与改动，不覆盖重建。保留 @syngy/workbench-auth 和生成的认证访问层，不自行增加另一套 token 存储或登录系统。

#本地验证必须接到真实业务

按官方 Skill 启动项目声明的开发服务，完成本地 Workbench 登录。团队范围的资源发现以及外部写入前，都要用 CLI 核对身份和团队；不匹配时先纠正环境。

检查页面展示的数据来自选定后端。确实没有记录时显示真实空状态，不用演示记录冒充接入成功。可见的搜索、筛选、创建和修改控件应实际生效；写入后独立回读记录验证。涉及 Arcubase 的业务数据通过其生成的强类型客户端访问。

本地验收记录应包含本地 URL、所选 Feature、数据应用标识（如有）、已验证账号和团队、操作证据及未解决问题。发布前按官方流程向开发负责人展示结果并取得明确确认。

#发布与交付证据

本地验收通过后，按项目声明执行必要检查和生产构建，确认产物再使用 octopus-cli 创建或选择 Workbench 项目、发布并跟踪任务。具体命令以官方命令契约与当前 CLI 帮助为准。

交付记录保留 projectId、taskId、status=active、workbenchUrl 以及已核验的 Profile、Host、Team。Arcubase 的 appId 是数据应用标识，不能替代 Workbench 项目或发布任务标识。

#应用设置与访问范围

应用信息和访问域名可在应用设置中维护，变更后重新检查真实入口与登录。需要公开页面时明确列出公开路径，并分别验收访客和登录用户：访客可打开指定页面，不代表能读取团队数据或调用受限操作。

第三方凭据由受控配置管理，不写入前端源码或构建产物。最终验收要覆盖直接打开业务路由、刷新、真实数据读写、权限不足、任务交接和公开页隔离。参考Workbench 场景方案及验收标准。