前言¶
用 DSH 做编码任务时，最常出现的情形是：Agent 说做完了，但你看不到它到底跑了什么、结果是什么。信号是一句 done，代价是一次人工复核。dsh-done-check 针对的是这个环节：把任务约定好的检查项写成 done-check.yaml，插件通过 DSH 真的把命令跑一遍，记录退出码、输出、耗时和文件指纹；代码一变，旧结果自动标记为需要重验。没有执行记录的「通过」不算通过。
下面介绍这个插件的来源、安装、用法和结果语义。
这是什么¶
dsh-done-check 是一个 DSH 插件，由 BeforeLanding 维护，属于工作流类。它把验收清单变成可执行、可追溯的对象：
- 清单写在项目的 git 根目录
done-check.yaml。 - 插件通过 DSH 的 shell 工具执行清单里的命令，记录命令和结果。
- 清单确认、人工项结论必须由你来做，Agent 不能代替。
- 被监控的文件变化后，旧结果失效并提示重新检查。
仓库地址：https://github.com/BeforeLanding/dsh-done-check ，目录页：https://www.skillhub.cn/plugins/BeforeLanding/dsh-done-check ，npm 包 dsh-done-check。
安装与启用¶
要求 DSH >=0.1.5-rc.1 <0.3.0、Node.js >=22.19，并且项目是一个 git 项目。
安装命令来自 README：
dsh plugin --profile web add dsh-done-check
使用其他由 CLI 管理的 profile 时，把 web 换成对应名称。装完按宿主提示重新加载或重启。
需要留意一点：初始化与英文输出是 v0.2.1 源码中的新功能，npm 尚未发布该版本，所以当前要按源码安装方式体验。项目 development 状态标注为 v0.2.1 源码，npm 待发布。
快速开始¶
下面三步复现一遍完整流程。
第一步，在 git 根目录生成清单草稿。 在 DSH 对话里依次发送：
/done-check lang en
/done-check init
第一条把当前会话输出切到英文；第二条让 Agent 探测项目脚本并起草 done-check.yaml。初始化不会执行命令、不会确认清单，也不会覆盖已有的清单文件。你也可以直接让 Agent 起草：
Draft and save done-check.yaml for this task. Use the project’s actual test commands and name what each one verifies. Add a manual item with instructions for anything I need to inspect myself.
第二步，预览、确认、执行。 分三条消息发送：
/done-check
/done-check confirm
/done-check
第一次只展示清单和将要执行的命令，不运行任何东西。confirm 记录你接受的是刚预览的那份内容。再发一次 /done-check 才真正执行自动检查项。
第三步，按结果处理。 测试失败时查看 Agent 给出的报告，让它修复后重跑 /done-check。人工项由你自己按说明验证，然后记录结论：
/done-check ok [n]
/done-check no [n] [note]
只有一项待人工确认时可以省略 n。
默认输出是中文，用 /done-check lang en 或 /done-check lang zh 切换当前会话。命令接受中英文别名，例如 确认 / confirm、详情 / details。
试用示例¶
仓库里的 CSV 导出示例包含一个故意留了缺陷的导出函数、两项自动检查、一项人工检查和一份现成修复。运行测试只需 Node.js 和 git，不需要安装依赖或配置 API key。setup 命令会新生成一个独立 git 目录：
git clone https://github.com/BeforeLanding/dsh-done-check.git
cd dsh-done-check
node examples/csv-export/demo.mjs setup
在生成的目录打开 DSH 会话，按示例 README 可以复现 失败 → 修复 → 通过 → 过期 的完整链路。
结果说明了什么¶
插件把结果分成四类，这四类是判断能不能相信报告的关键：
- 通过或失败：命令真的执行了，退出码、输出、耗时和文件内容指纹一起记录。
- 没能运行：权限拒绝、超时或执行器问题导致没有可用结果。它既不算通过也不算失败。
- 等待你确认：人工项需要你的结论，Agent 不能确认清单或记录人工决定。
- 需要重新检查：被监控的文件已不同于保存结果时的版本；修改检查定义或清单结构则需要重新确认。
有一点要说清楚：通过只代表约定的检查通过了，不代表需求的每一部分都被覆盖。插件不提供完成度百分比，也不做需求追踪。
文件指纹的范围分两种情况。不写 watch 时，指纹覆盖已跟踪和未被忽略的未跟踪文件，清单本身除外；写了 watch，就只覆盖声明匹配到的文件。相关的配置和锁文件要自己纳入，插件不会推断依赖。
命令参考¶
常用命令如下：
/done-check status # 只看当前状态，不运行检查
/done-check details [n] # 查看命令、输出和变化的文件
/done-check run # 强制重跑全部已确认的自动项，包括内容未变的失败项
/done-check init # 起草清单，不执行、不覆盖
/done-check confirm # 记录你接受刚预览的清单
/done-check ok [n] # 记录人工项结论为通过
/done-check no [n] [note] # 记录人工项结论为不通过
适用场景与注意¶
适合的场景：单个任务的验收边界明确，有真实可跑的测试命令，且你愿意把「约定检查」写成清单。它本质上是对既有测试的封存和留痕，不是替代测试框架，也不是需求管理工具。
使用前要注意：
- 插件在当前 dsh 进程权限下运行，检查经由已注册的 shell 工具执行，本地执行器不提供隔离。确认清单不会绕过 DSH 命令权限。
- 它防的是随手修改检查和结论，不防拥有不受限 shell 的 Agent。
- 安装第三方插件前，应打开仓库核对源码与许可证。本项目许可证为 MIT。
- 项目较新，GitHub 仓库创建于 2026-11-04，当前 star 为 0，README 标注 npm 尚未发布 v0.2.1。在升级前建议先看 changelog 和设计文档。
小结¶
dsh-done-check 的价值在于把「做完了」变成可核对的证据：每一项检查都有实际执行记录，代码变化后旧结果自动失配。它不替开发者判断需求覆盖度，只忠实报告约定检查的结果。
目录页：https://www.skillhub.cn/plugins/BeforeLanding/dsh-done-check
GitHub：https://github.com/BeforeLanding/dsh-done-check
