前言¶

在 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。