工作台开发：六步速览

版本：2026-10-27 · 详细规则见工作台开发规范；投稿见工作台市场验收规范。

本地开发、安装和使用不需要 GitHub 账号或仓库 URL；默认调用 register({ title }, BusinessPanel)，省略 repository 且不要填写 id。宿主从真实客户端 npm 包名派生 local:<npm 包名>（scoped 包为 local:@scope/name）。版本或目录变化不改身份，包名变化生成新身份。市场投稿另用真实仓库，不会自动迁移本地会话。注册失败时检查工作台管理中的包名、阶段和原因；修复重载成功后诊断清除。使用当前版本支持的原生插件安装界面或 CLI，不依赖未提供的本地安装 API。

面向用户的沟通：需求引导、布局建议、确认选项以及安装和完成状态都使用业务语言，例如“整页展示业务内容，需要时再打开 AI 对话”或“边对话边查看辅助资料”。不要要求普通用户确认 customFrame、register()、repository、dshHomePath、reconcileLocalProviders 等代码字段、内部身份或占位仓库地址，也不要大段呈现内部实现后让用户选择。技术字段由 Agent 在开发执行时按本规范处理；缺少发布身份不能阻断已明确的本地开发，不得捏造真实仓库。确实需要用户提供信息时，只询问影响业务或安装的实际问题，例如“要保存在哪个文件夹？”；用户主动询问技术细节时再简短解释。完成汇报先说明能做什么、哪些操作已实测和哪些仍待验证，修改文件与技术检查作为简短附录，最后按下方要求提示用户如何开始使用。

每次完成工作台开发后，最终回复必须以醒目的「接下来怎么用」三点提示收尾，放在所有修改说明、自测结果、文件链接和技术附录之后；不能只在开头提醒，也不能在这三点之后追加内容：

  1. 开发结果：用工作台实际名称说明已完成的开发和安装状态。只有确实完成开发并安装后才能说“已开发好并安装到本机”；未完成或安装失败时如实说明卡在哪里，不得声称已加载或全部验收通过。
  2. 如何重启：安装成功且需要重启时，请用户等当前任务结束后，点击顶部提示中的「立即重启」，或使用菜单「Harness → 重启 Harness」；通常只需重启 Harness，无需退出 DSH Desktop。只有重启 Harness 后仍未正常加载且排查确认需要时，才建议完整退出并重新打开 DSH Desktop。不得自行关闭或重启用户正在使用的应用；无需重启或安装未完成时如实说明，不把重启当作安装失败的解决办法。
  3. 去哪里打开：重启后，展开左侧栏，在左上角「工作台」右侧的当前名称／切换区域，选择刚制作的工作台（写出实际名称）。若没看到，进入「工作台市场 → 已安装」查找带「本地」标识的条目并检查运行状态，加载或启用成功后再切换。用户可以直接试用；如需继续验收，也可以回到原对话说「重启好了」，不必返回对话才能使用。安装未完成时明确此入口仍待安装和加载后确认。
  1. 确认需求：渐进对话，每次只问一个必要问题，不重复已知信息。名称未知时先问“这个工作台想叫什么名字？”，允许暂定名；再根据上下文补问目标使用者、主要功能或场景。核心流程可以根据回答建议并确认，不要求用户填全需求表。业务目标和最小范围足够明确后开始；通用指令、目录名和已有代码不能自行代替用户意图。
  2. 检查项目：查看 pwd、目录内容、git status --short（若为 Git 仓库）、现有脚本、包管理器及 Desktop 版本；保留未提交改动。
  3. 确定最小业务流程与布局：定入口、主要动作、完成状态和失败恢复；明确向用户建议业务整页或对话配辅助资料，并由 Agent 按第 4 节选择对应实现，以及首次无会话时的入口。不要把常驻会话区当作默认产品设计：内容审核、装修管理、报表、看板等优先建议业务整页，用户主动请求 AI 协助时才显示会话；对话主导或紧凑伴随工具适合标准分栏。需求不明确时，先给用户布局建议并确认主任务。
  4. 实现：按开发规范第 3 节制作插件包和业务面板；按第 4–7 节处理实际使用的会话、工作区和界面能力。业务区按自身容器宽度重排，不只依赖整窗断点。
  5. 包校验：运行 pnpm pack；检查 .tgz 内有声明的服务端/客户端入口和 cordis.patch.yml，没有凭证或用户数据。
  6. 本机安装实测：按开发规范 3.6 探测当前 Desktop 可用的本地安装方式并安装该包；完成所需重启后，通过下方两条可选路径试用或继续 Agent 验收，按第 8 节记录实际结果。无法安装时交付校验过的包，并列出未实测项。

模型完成构建和包校验后，直接调用 install_local_workbench({ path: "<本机 .tgz 绝对路径>", replace: false })，内部统一使用 Plugin Manager 的 installBundle，无需用户填写路径或操作安装页面。更新用户已授权修改的同名工作台时传 replace: true。读取 application：applied 时直接核验界面，只有 restart-required 才提示用户重启 Harness；失败、取消和 overridden 不算已生效。

在目标 DSH Desktop 内开发时：Agent 不要自行关闭或重启 DSH Desktop、Harness，也不要用 ps、pgrep 等进程探测管理重启；请用户手动重启。用户重启 Harness 后，给用户两条可选路径：① 直接试用：展开左侧栏，点击左上角「工作台」右侧的当前工作台名称／切换区域，选择新工作台；若未显示，进入工作台市场的「已安装」检查条目和运行状态，加载或启用成功后再切换。新本地工作台加载后会自动加入切换菜单，不存在单独的「添加」按钮。② 继续 Agent 验收：回到原开发对话告诉 Agent「重启好了」，由 Agent 按第 8 节继续检查加载、已安装列表、切换入口和真实业务界面。用户可自行试用，不必返回对话；Agent 尚未实测的项目仍标为待验证，安装成功不能表述为全部验收通过。运行在目标应用之外的 Agent 可按正常重启流程操作。

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

空目录示例：目录为空且用户只粘贴通用“开发指令”或说“做个工作台”时，先复用对话中已有的信息。名称未知就只问“这个工作台想叫什么名字？”，并允许暂定名；下一轮再按回答补问一个最影响开发的业务问题，例如“它主要想帮你完成什么事？”。若用户已经说明用途，则跳过这类提问，根据现有信息建议最小流程并确认。可以只读检查目录与 Desktop 能力；业务目标及范围足够明确前，不创建包文件、业务代码或页面，也不构建、安装或投稿。不要把名称答复当作完整的业务需求。