dsh 自動程式碼審查：審查預設、工作臺體檢與修復派發
看一套真實的 DeepSeek Harness 環境怎麼審自己的外掛倉庫：唯讀審查 Agent 按清單技能逐項過，變更必須過守衛腳本和測試才算完，工作臺還能當場抓 README 與執行時行為的出入。
最近更新: 2026-09-29
大多數「AI 程式碼審查」演示到「模型給我的 diff 寫了評論」就停了。這段 16 分鐘的螢幕實錄（Ubuntu 虛擬機裡跑 dsh Web UI，模型 DeepSeek-V4-Flash）展示了一套更有想法的做法：審查是獨立的唯讀 Agent；任何變更都要過 37 條可攜性守衛、19 個測試套件、1347 條斷言才算數；還有一個工作臺介面，專門核對每個外掛的 README 承諾和執行時實際註冊的東西是否一致。
影片裡的工作臺和預設都是作者的自研外掛（發布在 Gitee 的 hecong_dsh_plugins 倉庫），不是 dsh 內建功能——但整套模式用標準的預設體系就能復刻，預設基礎看 Agent 預設實戰
20 秒看懂這套打法
- ▸單獨建一個唯讀審查預設（風控），按 code-risk-audit 清單審程式碼風險——輸入邊界、路徑與權限、端點與憑證、資料一致性、測試品質——產出帶 file:line 和重現方式的發現。
- ▸編碼預設自帶紀律：先讀域約定與技能，改完必跑預檢與測試——演示報告裡是 37 條守衛通過、預檢 exit 0、19 套件 / 1347 條斷言。
- ▸編碼預設的 PTC（Code Mode）雙胞胎版適合批次巡檢：模型寫一段 TypeScript 程式組合多步呼叫，不用一輪輪地追問。
- ▸外掛工作臺整倉稽核——158 個外掛按 7 層依賴排卡，還能當場標出 README 與執行時不一致；修復以「開發任務」派發回去。
審查閉環，一步一步
先搭好審查者和被審者
- 1
給審查者單獨建一個唯讀預設
設定 → Agent 預設裡，作者把審查這件事單獨放在一個叫「風控」的自訂預設裡，描述就是完整規格：唯讀的審查 Agent，按技能 code-risk-audit 的清單審程式碼風險（輸入邊界、路徑與權限、端點與憑證、資料一致性、測試品質），產出帶 file:line 和重現方式的發現，用 agent_ask 把修復交給編碼 Agent，自己審不改。旁邊是兩個編碼預設：外掛編碼（先讀域約定與技能，改完必跑預檢與測試）和它的 PTC 雙胞胎版——本工作階段掛的就是後者。
設定 → Agent 預設：唯讀審查、編碼預設和 PTC 雙胞胎版同螢幕。看 12:30 處 - 2
確認預設到底掛載了什麼
Agent 工作臺是一張唯讀地圖：預設 → 外掛流 → 會話。選中編碼預設能看到它的兩張身分卡（plugin-dev 和 plugin-dev-ptc）、各自拖進來的 16 個對話級外掛，以及底下的 L3 能力提供者——fs-sandbox、subprocess、jobs、skill、goal、web、settings、會話持久化。右側的掛載會話面板把每個會話對應到工作區路徑和模式，放人幹活之前先確認審查者和編碼者不在同一個上下文裡。
Agent 工作臺把預設 → 外掛流 → 會話畫成一張唯讀地圖。看 13:00 處
跑審查，讀懂三層報告
- 3
跑審查，把三層報告都讀一遍
實錄開場就是一輪跑完的倉庫審查，報告讀起來像發布清單。發現層：Agent 自己寫出的檔案權限是 600，被 chmod 成 644；同時報告點出倉庫裡既有 59 個 600 檔案是本機 umask 的舊狀態，git 只記可執行位元，不該順手改。驗證層：37 條可攜性守衛通過、預檢 exit 0、全套自我測試 19 套件 / 1347 條斷言。邊界層：Agent 提醒署名和授權要作者自己定，並明確說自己沒有 git commit——提交這一步留給人。
報告分三層：發現、機器驗證、明說的邊界。看 0:30 處 - 4
用工作臺做整倉體檢
外掛工作臺把倉庫裡每個外掛渲染成一張卡：158 個執行級外掛按 7 層依賴排開（L0 底座：credentials、isolate、loader、locale、storage；L1 傳輸：api-gateway、webserver），每張卡帶提供/呼叫/傳送徽章和違反計數。切到功能域檢視，同一批外掛按媒體生成、音訊、視覺、小說、直播、平臺分域——停止級的標紅，事故級的打標。分層和分域的計數是活的：卸載一個外掛，它就在檢視之間移動。
功能域檢視：紅色是停著的外掛，平臺域裡放觀測工具。看 9:10 處 - 5
抓出 README 和執行時對不上的地方
點開任意外掛卡，工作臺會並排給出「宣告 vs 事實（README 與執行時不一致）」：拿 audio-player 這個例子來說，consumes/listen 有些條目只寫在 README（webServer「註冊路由，提供託管」）、有些只在執行時存在、有些兩邊都有——這類文件漂移靠肉眼永遠看不出來，但整合的時候準出問題。描述本身就地可改，來源是外掛的 README，檔案路徑就標在旁邊。
宣告 vs 事實：工作臺把每份 README 和執行時註冊逐項對帳。看 6:30 處
派發修復，複檢，發布
- 6
把修復派發成任務，而不是一句聊天訊息
同一個對話框直接把發現變成工作：在描述裡寫下你想要的行為（「我想讓你負責 xxxxx 功能」），工具列上就有儲存並 AI 研發、藍圖版派發「開發」任務、重新檢查會話三個動作。對話框自己維護「已變更，未儲存」狀態，還標出會話的工作目錄——變更就落在編碼 Agent 之後要跑的那個工作區裡。
發現變成任務：改描述、派發，不用往聊天框裡貼上。看 11:00 處 - 7
讓 bootstrap 和 preflight 把守最後一道門
實錄結尾停在作者發布到 Gitee 的倉庫（hecong_dsh_plugins，MIT），README 把這套紀律收成兩條命令：bootstrap 裝建置依賴、修軟連結、建置產物、自我檢查；preflight 結束代碼 0 才談啟動 dsh。前置條件表寫明 Node.js 18+（實測 v22/v24 都行）、npm 任意版本、首跑需要連網裝 esbuild 和 winbox——之後可離線。這就是審查閉環的最後一條性質：機器驗證的那道門放在倉庫裡，不放在任何人的記憶裡。
$node scripts/bootstrap.mjs$node scripts/preflight.mjs
發布出去的倉庫把紀律收成兩條命令：bootstrap，然後 preflight。看 15:50 處
常見問題
哪些是內建的，哪些是作者自研的，該抄什麼。
外掛工作臺和風控審查是 dsh 官方功能嗎？
不是。工作臺、風控審查預設和外掛編碼預設都是影片作者的自研 Cordis 外掛，發布在 Gitee 的 hecong9402/hecong_dsh_plugins 倉庫（MIT）。dsh 本身內建四個預設（標準、PTC、極簡、創造）。影片演示的是一套模式——唯讀審查預設、放在倉庫裡的驗證腳本、執行時巡檢介面——每一樣都能用 dsh 文件化的機制復刻。
code-risk-audit 清單都查什麼？
按影片裡的預設卡：輸入邊界、路徑與權限、端點與憑證、資料一致性、測試品質。發現帶 file:line 定位和重現方式。它是作者機器上的自訂技能——你完全可以把自己的清單寫成技能，再讓你的審查預設指向它。
為什麼審查者要唯讀？
這樣裁判就永遠不是運動員。預設描述的結尾是「審不改」：發現透過 agent_ask 交回編碼 Agent。這套分工還讓你天然拿到兩路報告——編碼者的「做完了」和審查者的「還有這些問題」——第 3 步那份報告就是這個結構。
批次巡檢為什麼用 PTC 版？
PTC 預設卡自己寫了：它以 Code Mode 呈現工具——模型寫一段 TypeScript 程式組合多步呼叫——適合「多次往返」的活，比如掃一遍倉庫、反覆跑驗證。逐步改程式碼仍然走普通編碼預設，每一步都盯得住。
相關攻略
用文件化的零件搭出同一套閉環。
來源與署名
本文 8 張截圖全部來自下方 Bilibili 影片（1080p，無任何字幕軌；畫面文字逐格核對），每張深連結到原片時間點。影片裡的工作臺與預設是作者自研外掛，發布在 Gitee 的 hecong9402/hecong_dsh_plugins 倉庫（MIT），README 已於 2026-09-29 與影片互證。頁面文字全部原創，未搬運影片字幕。