> For AI agents: the complete documentation index is available at https://docs.danqiuos.com/llms.txt, the full documentation bundle is available at https://docs.danqiuos.com/llms-full.txt.

# 开发 Workbench 应用

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

第一次构建完整场景时，从[快速开始](https://docs.danqiuos.com/start/quickstart.md)跟做 CRM 工作台与销售助理；环境准备见[连接 WorkBuddy 或 Codex](https://docs.danqiuos.com/start/connect-ai.md)。

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

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

原 `workbench-vibe-coding-flow` 仅保留迁移说明，已不再维护开发步骤。本站说明业务准备与交付要求；执行时阅读官方 [SKILL.md](https://github.com/syngy-ai/workbench-app-development-skill/blob/main/skills/workbench-app-development/SKILL.md) 及其引用的命令契约，避免从多个版本拼接命令。

## 选择需要的能力

| 业务需求                | 所选 Feature  | 判断依据                          |
| ------------------- | ----------- | ----------------------------- |
| 仅需要登录后的应用界面         | 空           | 认证由官方脚手架保留，不因业务 Feature 为空而关闭 |
| 团队、成员、员工、会话、文件等平台能力 | `octopus`   | 需要调用平台用户 API；仅展示已登录用户不需要额外选择  |
| 查询和处理项目、任务          | `taskboard` | 页面要读写真实任务与项目                  |
| 持久、共享、可查询的业务记录      | `arcubase`  | 使用真实数据应用及生成的强类型客户端            |

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

## 开发前准备

用[CRIDO](https://docs.danqiuos.com/build/crido.md)写清页面的业务入口、规则、输入、动作和结果，再确定：

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

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

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

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

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

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

## 发布与交付证据

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

| 发布状态或证据                     | 应如何判断                          |
| --------------------------- | ------------------------------ |
| `queued` / `processing`     | 仍在进行，继续有界地跟踪                   |
| `failed`                    | 停止，记录 `errorMessage` 和可执行的处理方法 |
| `active` 且返回 `workbenchUrl` | 发布任务成功，继续验证最终页面和业务操作           |
| 创建请求结果不确定                   | 先查询项目以消除不确定性，不重复创建             |

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

## 应用设置与访问范围

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

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