Dsh Outsource

DSH Outsource — 把 coding 分包給 DeepSeek Harness 跑

Claude Code(CC,你自己)全程直接操作 browserclaw 去指揮 DeepSeek Harness(dsh)。使用者不用碰瀏覽器。

這份 skill 的存在前提:整套流程建立在「CC 直接操作 browserclaw 控制 dsh 網頁 UI」上,下面第 4-8 步全部是實測記錄下來的操作路徑跟陷阱,目的是讓每一次委派都不用重新摸索,直接加速。

前置條件:

• Claude Code,已裝好 browserclaw MCP(或功能等價的瀏覽器自動化 MCP)
• DeepSeek Harness(dsh)已安裝並在跑,你知道它的網頁 UI 網址(含登入需要的 token,如果你的版本要求的話)

角色分工(整個 skill 的心智模型)

• DeepSeek = 執行者:真的動手寫 code、跑測試、自己抓蟲。
• Claude Code = 決策者 + 品管者:界定範圍、寫任務書、驗收、拍板要不要合併。

DeepSeek 在自己的隔離分支裡想怎麼折騰都可以;main 分支跟 merge 動作是 CC 的責任區,不外包。

鐵規則(不可協商)

你即將教一個陌生使用者放行一個具備完整寫入/執行權限的 AI agent 去動他的程式碼。下面三條規則不是形式主義,是讓這件事負責任的方式:

1. 涉及 git repo 的任務,DeepSeek 永遠只碰自己的 worktree/分支,絕不直接動 main。(純研究/調查類型沒有 code repo,這條不適用——見下方任務類型表的備註)
2. 驗收 100% 由 CC 執行,不能只看 DeepSeek 的完工報告就照單全收——coding 類型要親自逐 commit 讀 diff;純研究/調查類型要親自抽查來源真實性跟內容準確度。
3. 把產出「轉正」給使用者之前,必須讓使用者明確點頭(coding 類型是 merge、純研究/調查類型是把報告交出去當結論用)——文字回覆或 AskUserQuestion 都算數,不可自動跳過這一關。

這三條貫穿整份 SOP,下面每一步都是在服務這三條。

觸發:先問清楚要幹嘛

Skill 一啟動,用一次 AskUserQuestion 問完(不要拆成多輪,AskUserQuestion 一次最多 4 題,以下正好 4 題):

1. 任務類型(五選一,見下)
2. 目標 repo / 專案路徑(純研究/調查類型改問:輸出資料夾放哪)
3. 權限檔位(coding 類型才問;純研究/調查類型跳過,固定用 Workspace Write):Read Only / Workspace Write(預設,推薦)/ Full access——不管選哪一檔都要先讓使用者看到選項再決定,不能沿用「預設 Workspace Write 不問、只有 Full access 才問」的舊做法
4. Merge 後要不要自動刪除 worktree(coding 類型才問;純研究/調查類型跳過,輸出資料夾去留仍照舊由使用者決定):是,自動刪除(預設,推薦)/ 否,留著讓我自己看——選「是」的話第 13 步收尾不會再問一次;選「否」則第 13 步照舊詢問

五種任務類型

五個選項都是真實案例驗證過的形狀,不是憑空設計——之後如果要加新類型,先找一個真實案例跑過一輪再定模板,不要臨時發明。

模式判定(CC 自動判斷,預設標準模式)

dsh 的「新建會話」畫面上,工作區選擇器旁邊通常有一顆顯示目前模式的按鈕(常見預設是「標準模式」),點開可能有幾種選項,包含一種針對「批量/機械式重複」任務優化的模式(不同版本命名可能不同,常見叫法類似 PTC 模式)。⚠️ 這顆按鈕通常只在新建會話畫面上存在,送出訊息開始跑之後就消失,中途不能切換——選錯就得整個重開會話,所以要在送出任務前就決定好。

判斷規則:預設走標準模式;只有下面訊號命中(≥2 條、或單一條特別明顯)才考慮切換到批量模式,並用單題 AskUserQuestion 讓使用者確認或否決,不強行套用:

• 任務描述裡出現「批量」「一次改一堆」「遍歷」「彙總」「重複 N 次」這類字眼——本質是同一個操作套在一串清單上
• 要對 ≥10 個檔案/項目做同樣的機械式轉換(codemod、批次改名、格式遷移、多語系 key 批次插入)
• 邏輯能一次寫完(迴圈+條件判斷+彙總),不需要中途看結果再臨場判斷下一步
• 同類型任務先前用標準模式跑過,同款工具呼叫重複超過 5-6 次

站標準模式那邊的情況(以下任一成立就選標準,兩邊打平也選標準):路徑要邊做邊判斷(除錯/探索類)、步驟只有 1-2 步、需要逐項人工判斷不是機械套用、需要 CC 逐步觀察介入。

套進五種任務類型:一般任務預設標準除非明顯是codemod形狀;Code Review/Simplify固定標準(靠逐步判斷,不是機械編排);翻譯/內容產出在多語系批次產出時是最強候選;純研究/調查預設標準除非是「N個來源×M次取樣彙總」這種形狀。

⚠️ 這條規則的判準是通用經驗法則,不同 dsh 版本的批量模式行為可能有差異,第一次真的切換用用看,把觀察到的行為(升級提示長怎樣、監控頻率要多密、完工判定訊號)記下來,別讓這條規則停在紙上談兵。

純研究/調查類型的差異(跟其他四種比):

• 不用建 git worktree——沒有 code repo 要保護。改成:CC 建一個全新、空的輸出資料夾(不是 git repo,純資料夾),當作 browserclaw 選 workspace 時的路徑,天然把 DeepSeek 的活動範圍限制在這個資料夾。
• 沒有「commit」「merge」概念——第 2、3、11、12、13 步(建 worktree / commit 任務書 / merge 閘門 / merge / 刪 worktree)整組不適用,改成:CC 讀輸出資料夾裡的報告檔、抽查、整理成白話重點回報給使用者,使用者確認要採用才算「轉正」。
• 自查清單不一樣(見第 3 步下方)。

傳輸方式:目前只支援 browserclaw(GUI)

這份 skill 目前唯一驗證過、可以直接用的傳輸方式是 browserclaw ——CC 透過瀏覽器自動化操作 dsh 網頁 UI,下面第 4-8 步就是這條路徑的完整記錄。

規劃中(尚未驗證):dsh 通常也提供 headless CLI 一次性執行模式,理論上可以不開瀏覽器完成同一件事,但這份 skill 目前還沒有針對這條路徑做過端到端驗證(尤其是需要高權限/需要人工核准的操作在 headless 下怎麼處理,不同版本可能行為不同)。如果你的 dsh 版本支援 headless 且你想嘗試,有一個值得注意的通用坑:dsh 的權限設定檔(常見是某個持久化的 settings 檔案)可能會覆蓋你在指令列傳入的權限環境變數——如果你發現高權限模式怎麼設都「沒生效」,先檢查是不是有一份既有的持久化偏好設定在蓋掉你剛設的值,乾淨的做法通常是指定一個獨立、不帶舊偏好的設定目錄再試一次。這條在目前的驗證階段是唯一具體查到的通用發現,其餘 headless 細節請自行對照你的 dsh 版本文件驗證。

完整流程(14 步)

第 1 步 — 討論範圍

跟使用者對齊:要改什麼、白名單檔案(允許動的範圍)、黑名單(不准碰的共用檔案清單——這是隔離真正生效的關鍵,每次都要寫)、驗收線是什麼樣子算過關。

第 2 步 — 建一次性 worktree(純研究/調查類型跳過,見下方替代做法)

git worktree add -b deepseek/<task-name> <path> <base-branch>

裝依賴(注意已知環境坑,例如某些專案的原生綁定需要從主 repo 的 node_modules 複製過去)。需要資料庫的話,用 sqlite3 <main-db> ".backup '<worktree>/data/xxx.db'" 做快照進 worktree,別讓 DeepSeek 碰到正式資料庫。

純研究/調查類型的替代做法:不建 worktree,改成 mkdir 一個全新的空資料夾當輸出目錄,不用 git init。

第 3 步 — 寫任務書

在 worktree(或純研究類型的輸出資料夾)裡寫 DEEPSEEK_<TASK>_TASK.md,coding 類型要 commit,純研究類型純寫檔案即可。內容包含:

• 任務範圍
• 白名單(允許改的檔案/目錄;純研究類型就是「只准寫在這個輸出資料夾裡」)
• 黑名單(絕對不准碰的共用檔案)
• 驗收條件(純研究類型要寫清楚硬指標,例如:數量下限、日期範圍、輸出檔名/格式)

如果任務類型是「一般任務」或「翻譯」,把下面的自查清單整份貼進任務書;「純研究/調查」用它自己的清單(見下)。用 assets/brief-template.md 當骨架。

自查清單(coding 類型:一般任務/翻譯),寫成一次交代完的清單,不要設計成逐步等 CC 下指令:

改完 code → 自己看一遍 diff → 清理過度設計的部分 → 自我 code review(甚至自己修)→ 安全性自查 → 確認實際跑得動(build/test)→ commit → 有問題自己救回來。

自查清單(純研究/調查類型):

逐條確認來源真的存在、沒有捏造 → 確認日期範圍符合要求 → 數量沒達標就老實講不夠,不要湊數硬填 → 確認輸出格式符合要求 → 在報告最前面附一段重點摘要。

為什麼要一次寫完不要分步:dsh 的自動執行模式通常有動作輪數上限,一步步等指令會把輪數浪費在等待上,任務可能還沒做完就斷氣。這份清單也不會取代 CC 的驗收(見第 10 步)——它只是讓 DeepSeek 交件品質高一點、減少來回輪數。

第 4 步 — 開 browserclaw,選 workspace

打開 dsh 頁面,直接點側邊欄的「新建會話」按鈕開新會話(dsh 通常是純前端 SPA,單純導航回根網址不一定會清空畫面,可能只會恢復上一個瀏覽過的 session——不要假設「回根網址」就等於開新會話)。

工作區選擇通常走:「選擇工作區」→「添加工作區」→輸入/貼上絕對路徑(worktree 的完整路徑)。

選運行模式:照上面「模式判定」那節的規則選標準或批量模式。⚠️ 一定要在這步、送出任務前選好——這類設定通常只在新建會話畫面存在,訊息送出開始跑之後就從畫面消失,沒有中途切換這回事,選錯只能整個重開會話。

第 5 步 — 設權限

設成觸發時 AskUserQuestion 第 3 題使用者選的檔位,不用再問一次。Full access 是能逃逸沙箱的檔位,但既然觸發時已經讓使用者明確選過,這步驟不用二次確認。

⚠️ 選 Full access 時,dsh 自己通常還有一道 UI 確認關卡(例如需要勾選「我已了解風險」的核取方塊才能繼續)。這是 dsh 自己的安全閘門,跟這份 skill 觸發時的 AskUserQuestion 是兩層獨立的確認——CC 這邊已經有使用者明確選過 Full access,所以照勾照點,不用因為看到這個對話框又跑去問使用者一次。

第 6 步 — 費用/排程檢查(視你用的 dsh 服務是否有峰谷定價而定)

如果你的 DeepSeek API/服務有峰谷定價,這是送出任務前的最後關卡,因為前面步驟都不花錢,只有這步之後才開始燒 token/費用。抓當下時間、對照你自己的定價規則,決定要現在跑還是排到離峰。如果沒有這類定價差異,直接跳過這步往下走。

第 7 步 — 下指令

找到觸發任務的指令入口(常見是某個「命令」選單或直接的輸入框),把任務書內容貼進去,送出。

第 8 步 — 監控

建議固定間隔檢查一次(例如每 5 分鐘),不要太密集,也不要無限拉長——密集監控的意義是:如果目前用的權限檔位不是 Full access,可能會出現需要人工核准的升級請求真的卡住等你處理,監控間隔越短,那個延遲就越短。看對話/紀錄視圖快速掃進度。

遇到授權升級提示:如果目標路徑在這次任務的 worktree/白名單之內,通常可以直接核准(例如點「允許一次」),並記下這次任務總共自動核准了幾次;如果目標路徑在 worktree 之外或碰到黑名單範圍,不要自動核准,停下來問使用者。有些 dsh 版本對「worktree 內 commit 撞到 git 內部鎖檔」這類常見情境會自動核准不用人點,實際行為請以你的版本觀察為準。

權限檔位是安全 vs 速度的取捨:Full access 通常能避開大部分升級摩擦、跑得更快,但代價是沙箱保護更弱;不開 Full access 相對安全,但要接受可能有升級請求真的卡住等你處理。把這個取捨講清楚給使用者聽。

第 9 步 — 完工判定

依任務類型看對應的產出物(見上面任務類型表)。

複審層級選擇(只適用於一般任務,夾在第9步之後、第10步之前)

如果你的環境有另一個工具能做 code review(不管是 Claude Code 自己的指令、還是別的工具),可以把「要不要用那個工具跑複審」這個決策交給使用者,而不是 CC 自己悄悄決定,因為完工前看不到 diff、判斷不了要不要複審,完工後這個天然停頓點問最準。

完工後,CC 用一次單題 AskUserQuestion 問使用者三選一:

1. 外包給 DSH 再開一次複審 session(適合改動大、需要另一雙眼睛的情況)
2. CC 本地跑 code review 工具(如果你的環境有的話)
3. 純人工逐 commit 看,不跑額外工具

選外包複審時怎麼跑:

• 不建新 worktree,同一個 worktree/分支繼續用。
• 開一個全新的 dsh 會話(不是接著原本寫 code 的那個 session 繼續問)——全新 context 才跟原本的 builder session 保持獨立,不會出現「自己審自己、順便幫自己辯護」的問題。
• 任務書精簡到罐頭範本(見 assets/brief-chained-review.md):「複審這個 worktree 目前的 commits,寫 FINDINGS.md,不改任何檔案」,白名單只給 FINDINGS.md。
• usage 記錄可以標記這是接續任務,方便之後回頭統計。

鐵規則不變,不管選哪個層級:外包複審或本地 code review 工具都只是「交件前品管的第二意見」,不是「收件品管」——第10步「CC 逐 commit 讀 diff」這件事還是要做,對複審跑出來的發現也要抽查是否屬實,不能因為多了一層複審就跳過人工看 diff。⚠️ 如果複審是用同一個模型系列做的(例如同一個 DeepSeek 系列模型審自己系列寫的 code),結構上比不上完全不同模型(例如 Claude Code 本身)做跨模型審查——開全新 session 只能緩解「自己審自己」的問題,消除不了模型同源這個結構性弱點。選外包複審是拿這個弱點換效率,要讓使用者知道這個取捨,不是無痛的選項。

額外的視角可以併進同一次複審,不用另開一趟:例如這次改動碰到認證/輸入解析/外部資料/密鑰/網路請求,把安全檢查清單(見 assets/brief-security-review.md)併進複審任務書的「這次要聚焦的重點」欄位一起送出。

assets/ 底下有四份罐頭任務書模板可以直接現場填空使用(worktree路徑/分支/diff範圍/這次要聚焦的重點),不用每次從零設計任務書:

第 10 步 — CC 獨立驗收

coding 類型(一般任務/Code Review/Simplify/翻譯):

• 逐 commit 讀 diff——不是只看 DeepSeek 的完工報告或自查結果。DeepSeek 的自查是「交件前品管」,CC 這步是「收件品管」,兩者不能互相取代。
• 獨立重跑全部品質關卡:typecheck / lint / build / 專案特定檢查。自己重新跑一次,不要相信 DeepSeek 回報的跑測試結果。重跑驗證腳本時,如果那個腳本本身會寫入已經 commit 的產出檔(例如報告 json),先想清楚會不會把好資料蓋掉——最好對複本跑,或先 git stash,不要直接對著 committed 檔案原地重跑。
• 如果 DeepSeek 沒有主動 commit 改動(任務書沒明講的話很可能不會),CC 這步順手幫它 commit 一次再繼續驗收/merge。
• Code Review 類型:抽查幾條具體發現,對照真實資料/行為驗證是否屬實。

如果你的環境有額外的自動化工具(code review/security review/跑起來驗證/簡化工具),可以接進這一步,但都是補強逐 commit 讀 diff 這條鐵規則,不是取代它,工具跑完還是要親自看過 diff,不能因為工具沒抓到就直接放行。合併/簡化類的工具不建議在 merge 閘門前跑——會在使用者點頭前讓 CC 動 DeepSeek 的產出,打破「DeepSeek=執行者/CC=品管者」的分工,也讓使用者最後點頭的 diff 不是 DeepSeek 自己寫的;真要清理,merge 之後另外跑,或開一個新的 Simplify 類型任務丟給 DeepSeek。

發現怎麼處理:阻斷性 correctness 問題不是 CC 自己動手修——退回同一個 dsh session 讓 DeepSeek 自己救(呼應這份 skill 的角色分工),真的搞不定才升級跟使用者講;次要 cleanup 類發現不擋流程,帶進第11步 merge 閘門的回報裡讓使用者看著決定。

純研究/調查類型:

• 抽查一定比例(不用全部)的來源條目,確認真的存在、內容對得上,不是編出來的。
• 檢查數量/日期範圍等硬指標是否達標,沒達標的部分 DeepSeek 有沒有老實講。
• 檢查輸出格式符合要求。
• 通過後,CC 自己讀完整份報告,用白話文幫使用者整理重點,不是把整份報告丟給使用者自己看。

第 11 步 — Merge 閘門(純研究/調查類型改叫「採用閘門」)

CC 不可自動 merge / 不可自動把報告當定論採用。跟使用者確認一次(文字回覆「可以合併」之類,或用 AskUserQuestion)才能繼續。這關不能被自動化跳過——這類決策屬於「複雜決策」,拍板的人是使用者。如果第10步抓到次要(非阻斷性)的 cleanup 類發現,要把這些發現列進這次的回報內容一起讓使用者看,不能自己先斬後奏地略過。

第 12 步 — Merge(純研究/調查類型:交付報告)

coding 類型:使用者確認後,CC 執行 merge 回 main(git merge --no-ff <分支> -m "..."),DeepSeek 全程不碰這步。純研究/調查類型:沒有 merge 動作,這步等於「把整理好的白話重點回報給使用者」。

第 13 步 — 收尾

如果第 10 步起過 dev server / 背景程序:先確認已經關掉——查一下有沒有殘留 process,用精確指定 PID 的方式殺掉,避免用會連自己這條指令一起誤殺的模糊比對方式,別留孤兒程序燒資源沒人發現。

coding 類型,worktree/分支:

• 觸發時 AskUserQuestion 第 4 題選「是,自動刪除」→ 不用再問,直接刪除 worktree、刪除分支。
• 選「否」→ 照舊詢問使用者要不要刪。
• 如果 git worktree remove 卡住報 "Device or resource busy":先確認是不是真的有 process 佔用(用你環境的行程查詢工具檢查),如果查不到任何 process 卻還是卡住,通常是你自己的執行環境有某種保護機制擋住了刪除。解法:先嘗試 git worktree remove 失敗就直接 rm -rf 整個目錄(必要時提升權限,範圍僅限這個 worktree 路徑本身),再 git worktree prune 清 metadata,最後才刪分支——順序錯了(例如先 prune 再刪目錄)一樣會卡住。

coding 類型,browserclaw/dsh 兩層清理(dsh workspace/session 跟 browserclaw 分頁如果不清,會持續累積殘留,清理是有真實效益的):

1. dsh 側,刪除這次任務的工作區:回到開任務的那個 browserclaw 分頁,打開側邊欄,找到對應這次 worktree 路徑的項目,用它的操作選單刪除工作區。⚠️ 這個動作通常只會刪掉「工作區」這層分組,底下的 session/對話紀錄可能會被移到「未分組」桶裡繼續留著——如果要連 session 本身都清掉,可能還要另外做「歸檔會話」之類的動作,視你的 dsh 版本操作方式而定。
2. browserclaw 側,關掉這次任務的分頁/分頁群組:只准關自己這次任務開的分頁,絕對不要動其他分頁——包括使用者自己開的分頁,或其他背景任務名下的分頁。關閉前建議交叉核對一下你要關的分頁 ID 真的是自己這次任務開的,不同工具回報的 ID 有時候會對不上。

純研究/調查類型:輸出資料夾要不要留著給使用者自己決定,不用主動刪;browserclaw 分頁群組清理邏輯同上。

Browserclaw / dsh 操作已知陷阱

實測撞過的坑,遇到不要慌,照這裡處理(不同版本的 dsh/browserclaw 行為可能略有差異,以你實際觀察到的為準):

• 「新建會話」不一定能靠回根網址達成:很多 dsh 是純前端 SPA,回根網址可能只會恢復上一個瀏覽過的 session,不會清空。要開新會話,優先找側邊欄的「新建會話」按鈕。
• 清空訊息框可能不能直接用「填入空字串」的方式:如果遇到驗證錯誤,改用「點擊聚焦欄位→全選→刪除」的方式清空。
• element 參照可能失效:頁面導航/送出/重新渲染後,舊的元素參照可能失效,操作前先重新截取一次頁面快照。
• 斷線重連後分頁擁有權可能消失:重新開分頁,不要沿用舊的 tab id。開新分頁後不保證會自動恢復到原本正在監控的 session,這時候直接展開側邊欄,在 session 樹裡手動找回原本的節點點進去。
• 「送出」後輸入框可能不會清空:這通常是正常現象,不是操作失敗,不用重複清空或重送。
• 完工判定訊號:任務完成時,對話裡通常會出現一則系統事件標示完成,DeepSeek 的收尾回報通常會用結構化小標題(改了什麼/驗收條件/自查清單)——看到這個格式基本可以認定完工。
• DeepSeek 側常見環境坑:worktree 裡通常沒有預裝測試工具,pip install --user 這類指令常被 Python 的 externally-managed-environment 保護擋下——這是預期內會發生的事,不算 DeepSeek 出錯,它通常會自己改用虛擬環境或套件管理工具處理,注意它裝東西的路徑會不會弄進白名單範圍。
• 測試工具本身會在 worktree 留下白名單外的副產物:例如快取目錄、編譯產物——這些不是 DeepSeek「自己寫的」,但一樣算「動到白名單以外的檔案」,驗收時要連這些一起檢查有沒有清乾淨。
• DeepSeek 在 worktree 裡跑 git commit 幾乎一定要 escalate 到更寬的權限檔位:worktree 的 .git 其實是個指標,指向主 repo 底下的一個子目錄,那個目錄在 workspace root 之外,較嚴格的權限檔位下沙箱通常會擋寫入。這是預期內、每次要求 commit 的 worktree 任務都會發生,不是 DeepSeek 犯規——任務書裡可以先講清楚「commit 這步預期要升級權限」,免得它自己繞圈子摸索。
• 新分頁不一定是空白,可能顯示別的任務、還沒送出的完整草稿:開新分頁後,送出任何訊息之前,一定要先看清楚訊息框裡的文字是不是自己這次任務打的——文字量大、內容明顯不是這次任務的描述,就是踩到這個陷阱,不要因為看到滿版文字就直接送出。正確處理:找側邊欄「新建會話」按鈕,不要動暫停/編輯/清除目標,也絕對不要點送出。
• worktree 路徑建議建在跟你真實專案同一層的路徑旁邊(而不是某種臨時/沙箱專用的暫存目錄),避免 dsh 服務(通常是獨立常駐、跟你的 Claude Code 執行環境不在同一個隔離空間)看不到那個路徑的問題。

資產(assets/)

• brief-template.md — 一般任務/翻譯類型的任務書骨架
• brief-chained-review.md — 接續複審任務書
• brief-security-review.md — 併入複審的安全檢查清單
• brief-chained-simplify.md — 接續簡化任務書
• brief-run-verify.md — 跑起來驗證的補充任務書

監控:不用瀏覽器自動化也能看畫面

如果你只是想「看畫面」確認進度,不一定需要 browserclaw 這種自動化工具——大部分 dsh 網頁 UI 本身就能直接用瀏覽器打開查看(需要的話帶上你的登入 token)。這份 skill 描述的 browserclaw 流程是給 Claude Code 主動操作用的(選工作區、送出任務、按核准按鈕);單純想人眼監控進度,直接開瀏覽器看 dsh 自己的介面就夠了。