主要能力
| 阶段 | 输出 |
|---|---|
| 选择 Skill拖入 Session 或从会话菜单打开 | 识别会话实际调用过的 Skill，不需要手工填写 Skill 路径。 |
| 执行审计由 Bundle 独立准备运行时 | 生成 audit report，并读取 coverage.sections.instructions、finding、verdict 和 evidence。 |
| 反标原文coverage status 与 #seq 锚点 | 把已覆盖、未覆盖、未知直接标注到源码行；同一行多条声明分别保留自己的锚点。 |
| 审阅证据筛选、点击片段、打开历史 | 右侧查看 transcript、verdict、method、evidence 与 turn_refs；历史审计跨 Session 汇总。 |
为 Skill 审阅设计
覆盖率优先
总分使用 covered / total 口径；未覆盖和未知单独显示，不与 PASS/FAIL 混成一体。
finding 锚点
每个 #seq 都关联原始 transcript 和 evidence，点击即可回到对应声明判定。
原文内标注
状态、锚点和重点片段落在 Skill 原文行内，不需要在长报告和源码之间反复跳转。
多状态筛选
已覆盖、未覆盖、未知可以任意组合；源码标注、重点片段和右侧证据同步变化。
适合哪些场景
- Skill 作者：检查哪些声明从未被实际触发，优先精简无证据的要求。
- Agent 评测与治理：在同一条 Skill 原文上核对覆盖状态、finding 和 transcript 证据。
- 会话复盘：从 DSH Session 直接进入 Skill 审阅，不需要手工执行命令、查找报告和定位源码。
- 历史追踪：按 Session 和 runId 保存审计结果，后续对比同一 Skill 的不同运行。
使用前后对比
直接阅读审计报告
使用 Redundancy Check
判定口径
- 已覆盖：该 instruction 在任一 transcript 中至少出现一次 PASS 或 FAIL。
- 未覆盖：所有 transcript 均为 N/A，表示规则存在但场景从未触发。
- 未知：N/A、UNRESOLVED、INDETERMINATE 混合，或因判据不足无法归入前两者。
页面截图为 v1.2.0 真实运行界面，示例 Skill 为 archify；截图中已隐藏本地绝对路径，数值来自对应审计报告，不代表所有会话的固定结果。
1. 准备运行环境
| DSH | ^0.2.1-rc.2 |
|---|---|
| Node.js | >=24 |
| Python | >=3.10，用于首次自动准备 SIFT 运行时。 |
| Provider Auth | Bundle 自带；审计时会使用当前 DSH Provider 配置。 |
| SIFT | Bundle 自带环境准备能力；缺少且 Python 满足版本要求时按提示自动安装。 |
2. 安装 Redundancy Check Bundle
实际使用中，您只需要一键安装 Redundancy Check Bundle：
dsh plugin --profile web add @fuxi-ailabs/dsh-redundancy-check-bundle@1.2.0@fuxi-ailabs/dsh-redundancy-check-bundle@1.2.0安装完成后重启 DSH Web。无需再安装独立 Runtime Bundle。
3. 完成第一次声明覆盖检查
打开 Skill 审计
从 DSH 左侧“冗余度检查”进入，或在 Session 行的“...”菜单中选择“检查 Skill 冗余度”。
选择 Skill
拖入会话或直接使用当前 Session，选择调用过的 Skill。插件会独立执行审计并生成报告。
审阅覆盖标注
使用已覆盖、未覆盖、未知筛选；点击源码中的重点片段，右侧会显示对应声明和 finding 证据。
核对历史
在“历史审计”中跨 Session 查找已保存的报告；打开历史记录不会重新执行审计。
4. 功能演示
scripts/check-update.mjs 可查看 #4、#69、#137、#203 及其对应证据。审阅工作流
先看覆盖率
确认总体覆盖率、未覆盖和未知数量，再判断是否需要逐条核查。
定位 Skill 行
滚动源码时当前章节同步切换；状态和 #锚点直接显示在相关行下方。
打开声明证据
点击整行查看该行全部声明；点击行内代码或路径片段，只筛选相关声明。
核对 finding
查看右侧 transcript、verdict、method、evidence 和 turn_refs，确认覆盖状态是否与实际执行一致。
状态与锚点
| 显示 | 含义 |
|---|---|
| 已覆盖 | 至少一条 transcript 对该 instruction 给出 PASS 或 FAIL。 |
| 未覆盖 | 所有 transcript 都是 N/A，场景没有触发该 instruction。 |
| 未知 | 缺少足够判定，或 N/A、UNRESOLVED、INDETERMINATE 混合。 |
#4 | finding 序号，可关联到原始 transcript、verdict、evidence 和 turn_refs。 |
FAQ
它和 Session Audit 有什么区别？
Session Audit 面向整段会话轨迹；Redundancy Check 以 Skill 声明为中心，把审计结果反标到 Skill 原文，并按已覆盖、未覆盖、未知筛选。
它和 SIFT 原报告是什么关系？
插件独立执行审计并复用报告中的 coverage.sections.instructions 与 finding 锚点。它不复制报告，而是把同一份判定映射到 Skill 原文。
没有 PASS，只有 FAIL，会显示未覆盖吗？
不会。PASS 或 FAIL 都表示该 instruction 被触发过，因此会显示“已覆盖”；没有 PASS/FAIL 且全部为 N/A 时才显示“未覆盖”。
同一源码行出现多条声明怎么办？
同一行会分别显示每条声明的状态与锚点。点击整行查看全部 finding；点击行内重点片段则只查看相关声明。
打开历史报告会重新调用审计吗？
不会。历史记录按 sid + runId 加载已有报告；只有主动开始新的检查才会重新执行审计。
使用条件与限制
- 需要可以读取的 DSH Session，以及该 Session 实际调用过的 Skill。
- 覆盖率来自本次审计的 transcripts；“已覆盖”表示触发过，不等于执行正确。
- 本地报告保存于
~/.dsh-redundancy-check/audit/，历史列表跨 Session 汇总。