前言¶
DSH 的插件生态强调「一切皆插件」。在实际使用 DSH 做代码检查、修复和交付时，常见的问题是：检查依赖单次提示词，修复后缺少统一复查，问题是否真的消失也缺少可复跑的验证。
下面介绍 @dsh-external/dsh-inspect。它是一个 DSH 插件，提供 checkup、fix、review 三个工具，用于把“发现问题 → 修复交付 → 质量复查”组织成简单闭环。
这是什么¶
@dsh-external/dsh-inspect 是一个面向 DSH 的闭环检查插件。它的核心能力是提供三个工具：
checkup：检查问题并输出分级问题清单。fix：根据任务或问题清单进行修复，并输出交付报告。review：对交付物进行复查，并可对修复项逐条重跑验证。
资料中的 owner 线索为 omdsh-dev；包名与安装地址使用 dsh-external。两者路径不一致，安装前请以实际仓库、许可证和源码核对为准。
该插件基于 DSH 官方 workflow 引擎编排，并运行时依赖 schemastery。它不注册进 ctx.skills，也不碰 TUI；工具触发主要依靠工具描述。
核心功能¶
checkup：检查问题并输出分级清单¶
checkup 用于检查目标代码或目录。
输入参数：
target：必填，检查目标。angles：可选，检查角度，可指定多个角度。context：可选，背景信息。
输出为分级问题清单，分为严重、一般、建议，并包含证据与验证方式。
其机制是：检查员按角度检查，红队环节尝试推翻问题声明；推不翻的问题才保留。这样可以让问题清单更贴近可验证的证据，而不是只靠静态阅读产生结论。
fix：修复任务并输出交付报告¶
fix 用于执行修复和交付。
输入参数：
task：必填，修复任务。issues：可选，可传checkup输出的问题 JSON 数组。acceptance：可选，验收标准。
输出为交付报告，包括完成情况、检查记录和交付说明。
其机制是：先拆解任务，再并行实现，随后进行对抗式检查和修复轮收敛。每个实现环节要求找根因、实施修改，并重跑复现验证。修复后若问题没有消失，就继续分析，而不是直接标记通过。
review：复查交付物并验证修复是否消失¶
review 用于复查交付物。
输入参数：
target：必填，复查目标。dimensions：可选，复查角度。context：可选，背景信息。fixed_issues：可选，需要逐条验证的修复清单。
输出为分级复查报告和 passed 结果。
如果传入 fixed_issues，review 会对这些问题逐条重跑验证，确认问题是否真的消失。对于未消失的修复项，可以按严重问题反馈给后续流程。
可单独使用，也可串联成闭环¶
三个工具可以单独使用：
1、checkup：只检查，不修复。
2、fix：只执行修复和交付。
3、review：只对交付物复查。
也可以串联为闭环：
1、先用 checkup 找问题。
2、把问题清单交给 fix 修复。
3、用 review 复查交付物。
如果 review 不通过，或者人工对交付不满意，可以把反馈作为新问题再次进入 fix，直到收敛。
安装与启用¶
安装命令如下，<profile> 需要替换为具体 profile，例如 tui、headless、web 或自建 profile：
dsh plugin --profile <profile> add git+https://github.com/dsh-external/dsh-inspect.git
安装后重启对应 profile：
dsh --profile <profile>
重启后，checkup / fix / review 会随 profile 注入。
如果 dsh plugin 提示需要 allowBuilds，按提示在：
$DSH_HOME/profiles/<name>/pnpm-workspace.yaml
中添加对应配置即可。
更新命令：
dsh plugin --profile <profile> update
卸载命令：
dsh plugin --profile <profile> remove @dsh-external/dsh-inspect
典型用法¶
闭环用法¶
可以用一句话触发完整闭环：
用 checkup 检查 ./src，把问题清单喂给 fix 修复，修完 review 把关
执行路径大致是：
1、checkup 检查 ./src，输出严重、一般、建议三级问题清单。
2、fix 接收问题清单，执行拆解、修复和检查。
3、review 复查交付物，并输出是否通过。
如果 review 发现修复项未消失，可以把这些问题作为新的 fix 输入继续处理。
单用 checkup¶
示例：
用 checkup 检查 ./src，重点看错误处理和状态同步
对应参数重点是：
target：./srcangles：错误处理、状态同步等检查角度context：可选背景
单用 fix¶
示例：
根据 checkup 输出的问题清单修复 ./src，验收标准是主要接口不再出现未捕获异常
对应参数重点是：
task：修复任务issues：checkup输出的问题 JSON 数组acceptance：验收标准
单用 review¶
示例：
用 review 复查 ./src，重点验证刚才修复的问题是否真的消失
对应参数重点是：
target：./srcdimensions：复查角度fixed_issues：需要验证的修复清单
配置与依赖¶
可选配置¶
插件支持以下可选配置：
subagentProvider
maxTotalAgents
plannerModel
workerModel
checkerModel
reviewerModel
mergerModel
redteamModel
这些配置用于调整子代理 provider、子代理总数上限，以及规划、实现、检查、复查、汇总、红队等角色使用的模型。
运行时依赖¶
插件运行时依赖 DSH 官方 workflow 引擎和 schemastery。
peerDependencies 声明包括：
@deepseek-ai/dsh-agent
@deepseek-ai/dsh-tools
@deepseek-ai/dsh-workflow
cordis
schemastery 已从 peer 移入 dependencies。官方 Profile 的 autoInstallPeers: false 不会自动安装 peer，因此插件需要安装到能提供 workflows provider 的 profile 中。
官方 base 组合自带所需能力，通常无需额外安装。如果 profile 组合缺少 workflows provider，例如标准 web 组合，插件仍可照常加载；但调用 checkup、fix 或 review 时，会抛出带指引的清晰错误，而不是挂起整个 profile。
运行环境¶
Node 引擎要求为：
^22.19.0 || >=24.0.0
并要求使用 erasable-only TypeScript 语法。
适用场景与注意¶
适合的场景¶
这个插件适合需要把 DSH 的使用流程从“单次生成”推进到“检查、修复、复查”闭环的场景，例如：
- 检查某个目录或模块的问题。
- 根据问题清单执行修复。
- 对修复后的交付物做复查。
- 对修复项逐条验证是否消失。
- 在 review 不通过时，把反馈重新交给 fix。
使用前注意¶
1、插件以当前 dsh 进程权限运行。安装前请检查源码、依赖和许可证。
2、资料中的许可证为 MIT；package.json 中声明 private: true。实际安装前仍建议核对仓库源码。
3、资料中给出的 GitHub 仓库线索为 https://github.com/omdsh-dev/dsh-inspect；包名与安装地址为 @dsh-external/dsh-inspect。两者路径不一致，安装前请核对最终仓库地址。
4、DSH 社区目录是独立站点，与 DeepSeek / 幻方无官方从属关系，不应写成官方应用商店。
5、资料未提供可用的目录页 URL，因此本文不提供目录页链接。
短结尾¶
@dsh-external/dsh-inspect 的价值，是把 DSH 中常见的检查、修复和复查流程放到同一组工具里：checkup 找问题，fix 修问题，review 验问题是否消失。
适合安装到提供 workflows provider 的 profile 中使用。使用前建议先核对源码、许可证和仓库地址。
