# 工作台开发：六步速览

版本：2026-10-08 · 详细规则见[工作台开发规范](https://dshdesktop.com/workbench/docs/development/)；投稿见[工作台市场验收规范](https://dshdesktop.com/workbench/docs/market-acceptance/)。

1. **确认需求**：从用户本次请求及已确认的上下文写明业务场景、目标用户和用户完成一次任务的核心流程。通用开发指令、目录名和现有代码不能代替用户确认；缺任一项时只问一个合并问题，等答复后再设计业务功能。
2. **检查项目**：查看 `pwd`、目录内容、`git status --short`（若为 Git 仓库）、现有脚本、包管理器及 Desktop 版本；保留未提交改动。
3. **确定最小业务流程与布局**：定入口、主要动作、完成状态和失败恢复；明确选择标准分栏或 `customFrame`，以及首次无会话时的入口。紧凑的会话伴随工具适合分栏；报表、看板和宽表格作为主任务时考虑整页布局。
4. **实现**：按开发规范第 3 节制作插件包和业务面板；按第 4–7 节处理实际使用的会话、工作区和界面能力。业务区按自身容器宽度重排，不只依赖整窗断点。
5. **包校验**：运行 `pnpm pack`；检查 `.tgz` 内有声明的服务端/客户端入口和 `cordis.patch.yml`，没有凭证或用户数据。
6. **本机安装实测**：按开发规范 3.6 探测当前 Desktop 可用的本地安装方式并安装该包；完成所需重启后，从“已安装的工作台”和左侧入口打开，按第 8 节记录实际结果。无法安装时交付校验过的包，并列出未实测项。

**在目标 DSH Desktop 内开发时**：Agent 不要自行关闭或重启 DSH Desktop、Harness，也不要用 `ps`、`pgrep` 等进程探测来尝试管理重启。请用户完整退出并重新打开 DSH Desktop；用户回来确认已重开后，再做加载与界面验收。在此之前将这些项目标为待验证。应用外的 Agent 按正常重启流程操作。

**界面验收**：分别检查首次无会话、已关联会话、侧栏展开/收起及较窄窗口。标准分栏要看宿主通用引导与业务面板并列时是否可用；`customFrame` 要提供自己的首次使用入口。用真实长度的中英文内容检查，不能出现单字竖排、控件裁切或整页横向溢出；保留宿主公共入口。

**空目录示例**：用户只粘贴 Desktop 的通用开发指令，目录为空，也没有业务目标。Agent 下一步是一个合并问题：“这个工作台要服务谁、解决什么业务场景？用户从进入到完成任务的核心步骤是什么？”等待答复时可运行 `pwd`、`ls`、`git status` 或探测 Desktop 版本；答复前不得创建 `package.json`、业务代码或界面，也不得构建、安装或投稿。