跳到正文

omdsh-dev/dsh-inspect

51最近提交 2026年8月12日

dsh-inspect DSH 插件

dsh-inspect 提供 checkup、fix、review 三个工具，通过闭环反馈机制协同工作。它使用对抗式代理验证问题，沿数据流追踪根因，并在交付前验证修复。该插件面向需要自动化、可验证代码质量工作流的开发者和质量保证团队。

developer-toolsskills-workflows

如何安装 dsh-inspect DSH 插件

dsh plugin --profile <profile> add git+https://github.com/dsh-external/dsh-inspect.git

来源命令需要人工核对。复制不会执行命令。

dsh-inspect DSH 插件数据来源

dsh-inspect DSH 插件快照日期：2026年8月16日

discovered

dsh-inspect DSH 插件能做什么

  • 运行对抗式 checkup，通过红队验证（尝试推翻每个问题声明）找出问题
  • 执行修复交付，包含沿数据流的根因分析、实施和复现验证
  • 进行质量复查，使用对抗式审查员，可选逐条重跑验证修复是否消失
  • 支持自定义检查角度（angles）和复查维度（dimensions）
  • 支持角色级模型分层（planner、worker、checker、reviewer、merger、redteam）
  • 可单独使用，也可串联成 checkup→fix→review 完整流程
  • 集成 DSH 官方工作流引擎和工具注册服务

dsh-inspect DSH 插件适合哪些场景

  • 对代码仓库运行 checkup，获取带证据的优先级问题清单
  • 将 checkup 结果喂给 fix，自动修复问题并验证消失
  • 使用 review 复查修复质量，确认问题已解决后再合并
  • 迭代 fix 和 review，直到所有问题关闭或人工通过
  • 在 CI 管道中嵌入 checkup，作为拉取请求前的质量门禁
  • 对特定角度（如安全、性能）进行针对性检查

dsh-inspect DSH 插件适合谁

  • 寻求自动化代码审查和修复的开发者
  • 需要可验证质量门禁的技术负责人和 QA 工程师
  • 使用 DSH 官方工作流引擎和工具服务的团队

dsh-inspect DSH 插件的限制

  • 需要提供官方工作流引擎（ctx.workflows）和工具注册服务的 DSH profile
  • 仅支持 erasable TypeScript 语法（无 enum、命名空间等）
  • 运行时需要 Node.js ≥22.18 的原生类型剥离或 tsx hook
  • 不通过 ctx.skills 注册，仅通过工具描述触发
  • 子代理失败会如实标注，不会掩盖
  • 不支持 TUI；取消传播仅通过 exec.signal

dsh-inspect DSH 插件的仓库 README 摘录

以下文字摘自 dsh-inspect DSH 插件的上游仓库 omdsh-dev/dsh-inspect 的 README，版权归原作者，仅作引用。

**发现问题 → 修复交付 → 质量复查** 的简单闭环插件。 三个朴素工具，共享同一套"对抗式检查"机制： | 工具 | 干什么 | 核心机制 | | --------- | ---- | ------------------------------------------------------------------------------------ | | `checkup` | 找问题 | 对抗式检查员（各看一个角度）→ **红队攻击验证**（尝试推翻问题声明，推不翻的才保留）→ 汇总分级（严重/一般/建议） | | `fix` | 修复交付 | 拆解 → 并行实现（每个实现员按**找根因**（沿数据流找偏离源头）→ 实施 → **重跑复现验证**（反馈闭合））→ **对抗式检查** → 修复轮收敛 → 交付报告 | | `review` | 质量复查 | 对抗式审查员（各看一个角度）→ 汇总分级；可传 `fixed_issues` 逐条**重跑复现确认问题真的消失** | ## 理论内核：控制论的反馈机制 - **发现是怀疑，验证是定罪**：检查员/审查员一律对抗式（默认怀疑、找反例、只认可当场验证的证据）； checkup 的红队环节就是负反馈——问题声明必须经受住攻击，推不翻才成立。 - **根据数据流定向判断状态**：判断问题前先按数据流理清系统（输入 → 处理 → 存储 → 输出， 谁写谁读）；**问题 = 数据流某处状态偏离预期**，而不是静态读代码猜。 - **互相校验**：每个问题必须给出可互相校验的验证方式（重跑复现 / 日志对照 / 输入输出对照 / 双路径对照），并写明预期状态与实际观测——**无法通过系统反馈验证的，不许报**。 - **修复要证伪**：先沿数据流找到状态偏离的**源头**（不许修表面）；修复后重跑原复现， 观测输出与预期比较（反馈闭合）——问题没消失 = 根因没找对，重新分析。 - **根据数据判断直接定方案**：根因找到后，方案由数据自然决定——实现员按"找根因 → 实施 → 验证" 三步直接做（根据数据判断选择最合理的方案，不空谈不犹豫，实施保持改动最小）。 - **闭环**：checkup 的问题清单 → fix 修复任务 → review 把关（可逐条验证修复是否真消失）； 复查不通过或人的反馈重新进入 fix。三个工具可单独用，也可串起来。 ## 结构 ``` dsh-inspect/ ├──

阅读完整 README仓库许可: MIT

dsh-inspect DSH 插件常见问题

如何安装 dsh-inspect？

运行 `dsh plugin --profile <profile> add git+https://github.com/dsh-external/dsh-inspect.git`，将 `<profile>` 替换为 `tui`、`headless`、`web` 或自定义 profile。如果 pnpm 将 URL 重写为 git+ssh，请使用上述 `git+https://` 格式。如果提示需要 `allowBuilds`，请按提示在 profile 的 `pnpm-workspace.yaml` 中添加。

checkup、fix 和 review 可以单独使用吗？

可以。每个工具都可以独立使用。例如，你可以单独运行 checkup 检查代码，单独运行 fix 交付修复任务，或单独运行 review 验证修复清单。不过它们设计为协同工作：checkup 产生问题清单，fix 消费它，review 验证修复。推荐使用闭环流程以获得最佳效果。

如何更新或卸载 dsh-inspect？

更新：运行 `dsh plugin --profile <profile> update`。卸载：运行 `dsh plugin --profile <profile> remove @dsh-external/dsh-inspect`。或者，手动从 profile 的 package.json 中移除依赖，然后运行 `dsh plugin --profile <profile> update`。

dsh-inspect 对 profile 有什么要求？

profile 必须提供官方工作流引擎（`ctx.workflows`）和工具注册服务。DSH 官方 base profile 默认包含这些。部分 Web profile 可能没有 workflows provider，导致插件保持 pending 状态。此时需要注册 workflows provider 或改用兼容的 profile。

可以为不同角色（如规划器 vs 检查器）使用不同模型吗？

可以。通过插件选项配置：`plannerModel`、`workerModel`、`checkerModel`、`reviewerModel`、`mergerModel` 和 `redteamModel`。每个默认继承父配置。为对抗角色使用不同模型，通过提供多样化视角可以提升检测效果。