前言¶
用 Agent 做功能开发时，常见收尾是「跑一遍、感觉没问题就合并」。需求往往是一段自然语言，验收却散落在对话、终端输出和临时截图里，事后很难回答：某条原始需求到底有没有被证据支撑、证据对应哪一版代码、返修了几轮。DSH 生态里已有测试执行、代码审查等能力，但它们各自产出的是过程或结论片段，不一定按「任务契约 + 逐条验收项 + 可寻址证据」组织。
下面介绍 PolinniZhong 维护的 dsh-acceptance（GitHub：PolinniZhong/dsh-acceptance）。它是 DeepSeek Harness（DSH）的 conversation.view 全页面插件：装好后，对话上方多一个「验收台」页签。产品定位是任务级的凭证工作台——管理任务契约、验收项、执行证据、返修轮次与用户的最终决定；不是代码审查器，也不是全自动测试平台。当前版本 0.2.0，契约 schemaVersion = 1，与 DSH 0.2.x 桌面端配套（0.2.1-alpha.2 起）。
这是什么¶
一句话：把 AI Coding 的交付验收做成可导出、可审计的凭证链——逐条原始需求与证据映射，证据绑定代码版本（取不到快照则如实标「版本未知」），不做汇总分数。
插件在宿主侧用纯函数做状态派生与合法性校验；客户端只渲染、只提交操作。仓库内用 100 项行为断言和 11 条守卫（npm run verify 的 G1–G11）约束上述产品承诺，例如：无证据不得判通过、每条证据必须可寻址、不做 score / passRate 类汇总评分等。
五态与三件事¶
验收项与证据结论用五态并列呈现（不折算成通过率）：
| 键 | 界面显示 | 含义 |
|---|---|---|
pending |
待验收 | 还没验，或验了没给结论 |
pass |
通过 | 有本轮证据支撑的通过 |
fail |
未通过 | 有证据证明不符合 |
unknown |
无法判断 | 证据不足以判断——不是通过 |
blocked |
环境阻塞 | 环境/依赖挡住了取证，不是代码问题 |
「证据采集状态 / 验收项判断 / 任务最终决策」在模型里分开，界面与导出也不混成一种状态。
核心功能¶
任务与验收项¶
- 新建验收任务：粘贴最初交给开发 Agent 的原始需求（可选任务名）。
- 逐条添加验收项：标题 + 通过条件；未写通过条件仅提醒，不强制拦截。
- 「确认验收标准」后，未确认的项不会由插件自动补全。
凭证里 origin 区分 original（原始需求）与 suggested（建议补充）；验收项 id 单调递增，已删除的 id 不复用。
两种取证方式¶
| 模式 A：委派取证 | 模式 B：验收包导入 | |
|---|---|---|
| 谁执行 | 宿主调 ctx.subagents.start()，用 outputSchema 钉死验收项 id |
在外部完成检查，把结构化 JSON 贴回 |
| 失败处置 | 承诺点之前失败 ⇒ 4xx 且不写轮次；之后失败 ⇒ 写一轮 blocked（HTTP 仍 200） |
任意一条不合格 ⇒ 整轮拒收 |
| 共同点 | 证据与结论同批落库；无证据的通过一律拒收 | 同左 |
界面上主流程对应「让独立 Agent 帮我验证」与「我已经有检查结果」。插件不调用模型自动生成验收项；「复制验收项整理提示词」只是可复制文字。
决定与导出¶
底部根据当前结果给出单处指引（例如仍有 unknown、blocked 或 fail 时的下一步）。「生成修复说明」把未通过、尚未确定、环境阻塞等分四类列出；「导出验收记录」导出当前凭证，不会触发新验证。
最终决策：接受交付 / 要求修复 / 暂缓验收。只要还有一项不是「通过」，「接受交付」不可点，并列出剩余项；全部通过后仍须显式确认。
安装与启用¶
插件是本地 link: 包，需同时改 profile 依赖、bundles 列表，并在 node_modules 建立符号链接——缺一处会静默跳过（页签不出现或路由 404）。
1. 编辑 profile 的 package.json
路径：~/.dsh/profiles/<当前 profile>/package.json
// ~/.dsh/profiles/<当前 profile>/package.json
"dependencies": {
"dsh-acceptance": "link:/绝对路径/到/acceptance-console"
},
"dsh": { "profile": { "bundles": [ /* … */ "dsh-acceptance" ] } }
2. 建立符号链接
cd ~/.dsh/profiles/<当前 profile>
ln -sfn "/绝对路径/到/acceptance-console" node_modules/dsh-acceptance
<当前 profile> 随 DSH 版本变化：0.2.1-alpha.2 桌面端常用 desktop，更早版本可能是 tauri。可查看正在运行的进程参数定位 profile：
ps -Ao command= | grep -E "dsh-desktop-host|dsh web"
3. 重启 DSH
新 bundle 不会热加载，装完须重启 App。
4. 健康检查
curl -s "http://127.0.0.1:<端口>/api/acceptance.health?sessionId=probe"
典型用法（最小闭环）¶
按验收台界面文案走一遍即可，无需先学内部模式名。
- 开始 —— 打开「验收台」。无任务时首页为「开始一次交付验收」；已有任务未选中时提示「选择一个任务继续」。
- 写下需求 —— 「新建验收任务」，粘贴原始需求，点「创建并设置验收项」。失败会显示宿主真实错误。
- 确认验收项 —— 逐条填写标题与通过条件，点「确认验收标准」。
- 拿到证据 —— 委派独立 Agent 验证，或在外部检查后导入验收包 JSON。
- 看结果 —— 逐项查看状态、观察结果与证据定位；根据底部指引决定是否补验。
- 修复或决定 —— 必要时生成修复说明交回开发 Agent；导出记录后选择接受、要求修复或暂缓。
「版本未知」表示当前未取得可靠代码版本快照，插件不会用变更文件列表伪造指纹。
适用场景与注意¶
适合谁： 需要把 Agent 交付从「口头 OK」变成逐条可核对凭证的团队或个人；已有外部测试或人工检查结果，希望按验收项 id 结构化落库并与任务决策绑定。
明确不做： 汇总分数、进度条、通过率；替代 DSH 里已有的测试执行、代码审查、任务看板——只导入它们的证据；解析委派自由文本（缺 structured 则记 blocked）。
安全与权限： 插件以当前 DSH 进程权限运行，宿主路由与会话上下文读写本地凭证存储。安装前请阅读 MIT 许可证 与源码（src/dsh/host/、src/dsh/client/），确认路径与 profile 配置符合你的环境。
开发与自检（维护者/二次开发）：
npm test # 100 项行为断言（pretest 会先重建客户端产物）
npm run verify # 守卫 G1–G11，11/11 才算过
npm run build:client # 重建 dist/client.js
浏览器加载的是 dist/client.js 而非源码；改宿主逻辑后须重启 DSH。Node 要求 >=22.19（见 package.json）。
结尾¶
dsh-acceptance 把交付验收收敛到「需求 ↔ 验收项 ↔ 可寻址证据 ↔ 用户最终决定」一条链上，用五态和守卫约束结论可信度，而不是用自动化比例代替判断。社区目录页：skillhub.cn/plugins/PolinniZhong/dsh-acceptance；源码与 README：github.com/PolinniZhong/dsh-acceptance。DSH 插件生态独立维护，目录站点与 DeepSeek / 幻方无官方从属关系。
