# Dsh Outsource

> 直接操作 DeepSeek harness(dsh,web UI 通常跑在本機某個 port,例如 http://127.0.0.1:3080/)透過 browserclaw MCP 瀏覽器,把 coding 子任務、code review、simplify(簡化清理)、翻譯/內容產出,或純研究/調查任務(上網搜尋+整理,不碰 code)分包給 DeepSeek——coding 類任務會在獨立的 git worktree 裡跑,監控進度,並獨立驗收(coding 類另外還要負責 merge)結果。「丟給 DeepSeek 跑」「分包給 DeepSeek」「叫 DeepSeek 去改」「交給 deepseek 整理/查」「outsource this to deepseek」「delegate this to deepseek」「dsh 那邊處理一下」這類說法都會觸發,即使使用者沒提到 worktree、browserclaw 或 dsh 本身。不要用在 Claude Code 自己就該做的任務。

- Skill: `naive000/dsh-outsource` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add naive000/dsh-outsource`
- Raw SKILL.md: https://api.skillmd.com/api/skills/naive000/dsh-outsource/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: naive000 (https://skillmd.com/u/naive000)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/naive000/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 步照舊詢問

### 五種任務類型

| 類型 | DeepSeek 做什麼 | 產出 | CC 的驗收方式 |
|---|---|---|---|
| **一般任務**(開發/修復) | 直接在 worktree 裡改 code、commit | 一串 commits | 逐 commit 讀 diff + typecheck/lint/build + 專案特定檢查,必要時瀏覽器實測 |
| **Code Review** | 只看 code,寫報告,**不改任何檔案** | `FINDINGS.md` | 抽查具體發現是否對照真實資料/行為屬實,不照單全收;使用者/CC 決定要不要採納,**不自動合併任何東西** |
| **Simplify** | 在白名單範圍內清理過度設計,行為不變 | 獨立小 commits | 逐 commit 確認外部行為真的沒變 |
| **翻譯/內容產出** | 產出新內容檔案(如多語言 JSON),重點是格式規則+來源對照+key 對稱 | 新增/修改的內容檔 | 對稱檢查(key 是否一一對應)+品質抽查 |
| **純研究/調查** | 上網查資料、整理、寫成報告,**不碰任何 code repo** | 一份 MD(或其他文字格式)報告 | CC 抽查一定比例的來源條目是否真實存在、內容有沒有對得上;檢查數量/日期範圍等硬指標是否達標;達標後 CC 用白話文幫使用者摘要重點 |

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

### 模式判定(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範圍/這次要聚焦的重點),不用每次從零設計任務書:

| 情境 | 模板檔 | 何時用 |
|---|---|---|
| 複審 | `assets/brief-chained-review.md` | 上面「複審層級選擇」選外包複審時用這份 |
| 安全視角 | `assets/brief-security-review.md` | 這次改動碰敏感面時,**併入同一次複審**帶著跑,不用另開一趟任務 |
| 簡化清理 | `assets/brief-chained-simplify.md` | merge 之後想清理、或使用者主動要求時用,任務書白名單沿用原任務的白名單 |
| 跑起來驗證 | `assets/brief-run-verify.md` | 原任務書漏寫自查清單裡的實測步驟時事後補一趟 |

### 第 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 自己的介面就夠了。