前言¶

在 DeepSeek Harness（DSH）里做较大改动或合并前，常见做法是自己在主会话里逐文件看 diff，或临时写 prompt 让模型「帮忙 code review」。这类方式往往缺少稳定的范围边界、按目录聚合的结论，以及可回滚的修复入口；不同次对话的结论也难以对齐。

dsh-logistics 是社区维护的 DSH 工作流类插件：安装后注册一组 /logi-* 命令，先用插件内脚本做确定性的 git 与文件范围收集，再通过内置 subagent 拉起按模块分工的专家子代理写 handoff，最后由你当前的主会话模型担任主编，合并证据、定级并写出模块化报告。机器层只做事实收集与 contract 校验，不替你做质量裁决；0.2.0 起已移除健康分、基线与门禁，0.3.0 起进一步改为「主编模型 + 薄机器层」，并可按专家可选模型路由。维护者为 whitequeen306，源码与说明见 GitHub 仓库，社区目录页为 skillhub.cn/plugins/whitequeen306/dsh-logistics。目录站点与 DeepSeek / 幻方无官方从属关系，插件生态遵循 DSH「一切皆插件」的思路。

这是什么¶

一句话定位：面向 DeepSeek Harness 的项目后勤（project logistics）——模块化代码审查报告 + 可选的 direct 项安全修复。

插件纯 ESM、零运行时依赖，不 import @deepseek-ai/*；命令与 skill 由 DSH 宿主加载。项目自 CodeCortexLoop（MIT，原仓库留存于 master 分支） 迁移而来，当前 npm 版本为 0.3.0（许可证 MIT）。

核心功能¶

五个审查模块，默认跑四个¶

按后果分工的模块包括：正确性、安全、健壮性（错误处理 + 测试）、可维护性（简化 + 清理），以及可选的性能模块。默认 /logi 只跑前四个；性能仅在 diff 明确涉及热路径时由主编判断是否追加 /logi-perf，未覆盖时报告会写明「性能未覆盖」。

主编裁决，证据优先¶

工作流大致为：确定性事实写入 .logistics/runs/<runId>/scope.json → 主编派发专家子代理 → 各专家写 handoff/<expert>.json → collect.mjs / bundle.mjs 准备材料 → 主编写 verdict.json 与 report.md，verdict.mjs 只校验 schema（schemaVersion 为 2），不判断内容好坏。问题需有位置、证据、触发路径和影响；没有证据的严重项会被降级。每个 finding 有稳定 ID（如 COR-4F2A1），不含行号，便于跨提交跟踪。

按模块出报告¶

report.md 按 src、packages/api、apps/web 等模块聚合，包含模块总览、分组问题、未覆盖维度、建议修复顺序等。docs/logistics/latest.md 与 .logistics/latest.json 仅在默认四模块完整覆盖时更新；单模块或部分覆盖会保留上一份完整报告。

只读审查与 /logi-fix¶

/logi-* 审查阶段只读，不改源码、不提交。写操作唯一入口是 /logi-fix：列出最近完整 verdict.json 中的 direct ID，或用 --dry-run 看计划，或显式指定 ID 执行。执行前要求 git 仓库、干净工作区、判决后 HEAD 未变等；fixer 只改白名单文件、跑配置的测试命令，失败会回滚并留 fix-reverted.patch。不支持 --all；plan 类型与性能项不会自动执行。

与旧版文档的区别¶

dsh-logistics@0.1.0 对应旧的 7 专家/评分版本，勿与 0.2/0.3 混用。当前 0.3.0 的 npm 包已是「主编模型 + 薄机器层」；skill 收敛为 6 个（5 个专家 + fix），无独立 core/pipeline skill。没有 subagent 工具时插件会直接报告限制并停止，不会退化成单会话猜测。

安装与启用¶

环境要求：DeepSeek Harness 0.2.1 或更新，Node.js ^22.19.0 || >=24.0.0。

DSH Desktop：桌面版独占管理 desktop profile，命令行 dsh plugin --profile desktop add 会被拒绝。请打开 Settings → Plugins → 安装第三方插件（Add plugin），填入本机插件目录的绝对路径，例如：

C:\path\to\dsh-logistics

安装后刷新或重启，输入 /logi 应能看到命令补全。

CLI / 非桌面 profile（以 web profile 为例）：

dsh plugin --profile web add dsh-logistics@0.3.0
dsh plugin --profile web add "C:/path/to/dsh-logistics"   # 本地开发
dsh --profile web --dump-config | grep -A2 dsh-logistics

安装前请自行阅读仓库源码与 MIT 许可证；插件以当前 DSH 进程权限运行，等同于你在本机执行审查与修复流程。

典型用法¶

全模块或单模块审查¶

默认四模块：

/logi

只跑安全模块，并在命令后补充关注点：

/logi-security 只关注支付流程和退款状态机

其他单模块命令：/logi-correctness、/logi-reliability、/logi-maintainability、/logi-perf（可选）。

查看与执行修复¶

列出可执行的 direct ID：

/logi-fix

先看计划再改代码：

/logi-fix --dry-run COR-4F2A1

确认后执行：

/logi-fix COR-4F2A1

可选配置¶

在项目根创建 .logistics/config.json，例如指定忽略路径、文件上限、测试命令、模块显示名、按专家指定模型（仅在 DSH 允许子代理模型路由时生效）：

{
  "ignore": ["fixtures/**", "**/*.snap"],
  "maxFiles": 400,
  "maxFindingsPerPass": 12,
  "includeLastCommitWhenClean": true,
  "testCommand": "pnpm test",
  "modules": {
    "packages/api": "API 服务",
    "apps/web": "Web 前端"
  },
  "models": {
    "security": {
      "provider": "wb",
      "model": "glm-5.3",
      "reasoningEffort": "high"
    }
  }
}

非法配置会回退默认值并警告，不会让命令直接崩溃。

适用场景与注意¶

适合在 DSH 主会话里对当前仓库改动（或工作区干净时最近一次提交）做结构化审查，并希望对少量 direct 问题做带测试与回滚约束的修复。

需要注意的边界：

• 审查不是编译器；跨仓库、运行时才暴露的问题可能漏报。
• 部分覆盖不等于通过；单模块报告只代表该模块。
• 默认最多 400 个文件、单专家 12 条 finding；超大改动建议拆分或提高 maxFiles。
• 父代理每条消息最多派发 4 个子代理；审查阶段子代理只读。
• 性能项永远是 plan，不会通过 /logi-fix 自动改。

结尾¶

dsh-logistics 把「范围收集 → 专家 handoff → 主编报告 → 可选 fix」收成 DSH 原生命令，强调证据与模块化输出，而不是单一分数或门禁。若要安装或跟踪更新，可看 社区目录页 与 GitHub：whitequeen306/dsh-logistics。