前言¶
在 DSH 里用深鲸守护类插件做安全或合规自查时，常见流程是：扫一遍、按提示改代码、再扫一遍。第二次「全绿」或命中数变少，并不自动等于「当初报的那几条都修掉了」——行号漂移、改 A 带出 B、规则集没变但目录换了，都可能让肉眼对比两次终端输出变得不可靠。
下面介绍的是工作流类插件 dsh-fix-verify（仓库 feely0208/dsh-fix-verify，维护者 feely0208）。它不做新的扫描判据，而是对改前与改后两份代码快照各跑一遍完全相同的规则，再按固定键做逐条对照，把「已修复 / 遗留 / 新增回归」分开统计，适合整改复核、CI 门禁和后续交给合规文档插件出交付物。
这是什么¶
一句话：别的插件负责「查这次有没有问题」；dsh-fix-verify 负责「改前 → 改后，同一套规则下问题到底少了没有、有没有新增」。
它是比对器，不是扫描器本身。规则来自你已经装好的深鲸守护插件（例如 SBOM、密钥、日志、PII 等）；它不评价「改得好不好」，也不下安全或合规结论，只对照两次扫描结果是否对得上。未覆盖的规则域、未命中的项，不能等同于「没有问题」。
npm 包名为 @deepwhale-cn/dsh-fix-verify（当前资料中版本 0.1.0），许可证 MIT。在 SkillHub 等社区目录中归类为工作流；与 DeepSeek / 幻方无官方从属关系，安装前仍建议自行查看源码与许可证。
比对逻辑与四个结果桶¶
工作流程可以概括为三步：
- 自动发现已安装的守护插件规则（见下文「规则从哪来」）；
- 对
--before与--after两个目录各执行同一套规则； - 以
ruleId + 文件相对路径为比对键（不含行号），避免「只加了一行注释、行号变了」被误判为已修复。
输出分为四类：
| 类别 | 含义 |
|---|---|
| 已修复 | 改前报、改后不报 |
| 遗留 | 改前改后都报 |
| 新增回归 | 改前不报、改后报 |
| 新增文件 | 改后多出的文件（仅统计，不参与问题判定） |
若没有发现任何规则源，工具会 exit 2 并提示如何指定规则，不会把「没检查」伪装成「0 命中」。
与系列内其它插件的分工（资料原文表述）：
dsh-sbom / dsh-cn-log-retention ... = 查【这次】有没有问题
dsh-fix-verify = 查【改前 → 改后】问题到底少了没有
dsh-compliance-doc = 把结果变成能交出去的自查表 / 整改说明 / 合规证明
安装与运行环境¶
在 DSH 中安装（命令以 README 为准）：
dsh plugin --profile web add @deepwhale-cn/dsh-fix-verify
package.json 要求 Node >= 18，DSH 引擎 >=0.1.0-rc.6 且 <0.3.0。插件以当前 dsh 进程权限读取你指定的目录并执行规则，安装与运行前请确认权限范围可接受。
安装后可通过 CLI dsh-fix-verify 调用（bin/cli.mjs）。
典型用法¶
改前 / 改后两份快照对比（最常用）：
dsh-fix-verify --before ./snapshot-old --after ./snapshot-new
CI 只看结论行：
dsh-fix-verify --before old --after new --quiet
输出 JSON，便于交给 dsh-compliance-doc：
dsh-fix-verify --before old --after new --json > fix-verify.json
额外生成 Markdown 复核报告：
dsh-fix-verify --before old --after new --md 复核报告.md
同一目录兼作改前改后（兼容部分门禁脚本）：
dsh-fix-verify --root .
手动指定规则源目录（目录下可以是 dsh-*/rules，也可以是插件根目录）：
dsh-fix-verify --before old --after new --rules-from /path/to/plugins
怎么准备两份快照¶
资料中给出三种方式，任选其一即可复现：
# 方式 1：git worktree（推荐）
git worktree add /tmp/before HEAD~1
dsh-fix-verify --before /tmp/before --after .
# 方式 2：从旧 commit 导出
mkdir -p /tmp/before && git archive HEAD~1 | tar -x -C /tmp/before
dsh-fix-verify --before /tmp/before --after .
# 方式 3：两个普通目录（不要求是 git 仓库）
dsh-fix-verify --before ./backup --after ./project
输出、退出码与 JSON 字段¶
终端会汇总规则源数量、扫描文件数，以及「修复 / 遗留 / 新增回归 / 新增文件」计数，并分表列出条目（含严重度、规则 ID、文件、旧行号 → 新行号等，行号仅供人读，不参与判定）。
| 退出码 | 含义 |
|---|---|
0 |
遗留为 0 且新增回归为 0（可放行） |
1 |
仍有遗留或新增回归 |
2 |
参数错误、目录不存在，或未发现任何规则源 |
使用 --json 时，各桶条目包含 ruleId、title、severity、source、advice、file、beforeLine、afterLine 等字段，可直接对接 dsh-compliance-doc。
规则从哪来¶
按顺序自动发现，同目录按 realpath 去重：
--rules-from指定目录（可重复）；- 本插件
node_modules/@deepwhale-cn/dsh-*/rules； - 与本插件并排安装的
dsh-*/rules； - 环境变量
DSH_GUARD_PLUGINS（冒号分隔）。
只认「含 rules/*.json 且至少一条合法规则」的目录。插件未装、规则未找到 → exit 2。
适用场景与注意¶
适合：整改后需要客观复核「当初那几条是否还在」；在 CI 里用退出码做门禁；需要 JSON / Markdown 留痕，再交给合规文档插件出表。
不要这样用：
- 用它替代扫描插件——它不产生新判据；
- 把「遗留 0」当成「项目没问题」——仅代表当前规则集在这两个快照上未再报；
- 用行号判断是否修好——以规则 ID + 文件路径为准；
- 在规则源为空时相信输出——应先安装守护插件或
--rules-from。
链接¶
- 社区目录页：feely0208/dsh-fix-verify
- 源码与完整说明：GitHub — feely0208/dsh-fix-verify
