DSH插件测评:/simplify 只改你本次的改动

边界写清楚：修改范围靠提示词约束，不是文件写入隔离；一次上限 200 个变更文件、提示词 128KiB、累计 4,096 个离散行范围；二进制、超过 5MiB 的文件、纯删除、仅重命名、子模块都不进范围。

周五改完一个小功能，工作区留着 6 个文件没提交，你不想让 Agent 对着整个仓库重排。输 /simplify，回执给出「已提交 6 个文件的简化审查」，再 git diff 逐条决定收不收。依据：README 写明默认范围取 HEAD 到工作区的净改动，工作区干净时才回看上一次提交。

周一评审前，你想先把 diff 读薄再喊人。git add -A 后输 /simplify --staged，只收拾暂存区那批文件；要看整条分支相对主干的差异，换成 --ref=main。硬条件：所选暂存文件若还有未暂存改动，它直接拒绝，先把工作区清干净。依据：README 的 --staged 与 --ref 说明。

你不写代码，只让 Agent 帮你改发稿脚本、导表脚本这类小工具。改完在会话里输 /simplify src/，只让新增的那个循环收一收，再用 git diff 确认真的只动了这几行，然后才 push。别指望它判断业务对错：它只读 Git 与文件，不 add、不提交，交付物仍要你验收。依据：README 的只读 Git 与范围参数说明。

三条对照。跟「帮我重构整个项目」比，它把范围锁在一次改动里，好处是 diff 不变大，代价是范围外的问题它看不见。跟同作者的 /review 比，review 只出报告、它直接改代码，两个可以接力：先 review 找问题，再 simplify 收结构。跟手动改比，它替你找可简化的点，取舍还得你做。如果你想整仓做现代化改造，这条路线就不合适：它只按改动范围走，范围外的重复代码它不主动去翻。

版本对应：1.0.1 要求宿主是 0.2.0-rc.1、0.2.0-rc.2、0.2.1-rc.1、0.2.1-rc.2 之一，依赖 @deepseek-ai/cordis ≥4.0.4 且小于 5；0.1.x 请装 0.1.16；0.2.1-alpha.1 到 alpha.5 会被版本门拒绝；Node 需 ≥22.19.0。本机 dsh 0.2.1-rc.2 正好在名单里，门槛这一关是过的。

四个坑：输完命令输入框清空、看不到回话，先翻会话区有没有「已提交 N 个文件」。整仓新增文件容易撑爆 128KiB 提示词上限，先指定目录。--ref 不支持 a..b 区间，也不能和 --staged 同用。不在 Git 仓库里它会直接报错，不会替你 git init。再加半个坑：工作区干净时它会回看上一次提交，你以为没改动，它其实在审上次那笔。

三步：