Claude、Codex、Gemini CLI（限定路線）常用指令＋工作流速查

A · 常用指令對照↑ 回速查選單

A.1 啟動／接續

A.2 斜線指令

A.3 Headless／非互動

A.4 設定檔 config（位置／檔名）

A.5 MCP（新增／列出／取得／移除）

A.6 記憶檔（專案記憶檔名）

A.7 權限模式與自動化安全旗標

這組不是斜線指令，是啟動時就決定「模型能做到什麼程度」的旗標——尤其想跑無人值守自動化前，務必先搞懂這幾個旋鈕怎麼轉。

B · 各 CLI 收尾指令↑ 回速查選單

各 CLI 收尾完整章節：Claude Code 第 24 章 · Codex CLI 第 16 章 · 已確認 Gemini CLI 限定路線者可看 Gemini CLI 第 16 章。

C · 通用跨 CLI 工作流↑ 回速查選單

這套流程不綁特定工具——三家都先「想深 → 收斂 → 派工 → 驗證」，差別只在按鍵與指令名。把它當骨架，換哪一家都接得上；Claude Code 走對話與 subagent 派工，Codex 走互動或 codex exec，Gemini 走 /plan、/agents、/skills 與 @subagent。

如果你正在決定要不要導入一套完整方法，先讀AI 開發工作流框架深度比較：它把 GSD Core、Spec Kit、Superpowers、OpenSpec 與其他主流選項的狀態、TDD、Review、成本與適用情境拆開來看。

1. 1

   ultrathink（深想）

   • Claude：對話輸入 ultrathink 拉高思考預算；或按 Option+T（Mac）／Alt+T（Win·Linux）切換「延伸思考」；CLI 內 /effort 調深度。
   • Codex：正式旋鈕是 model_reasoning_effort（minimal／low／medium／high／xhigh）；深想自動派工用 model_reasoning_effort=xhigh。ultrathink 可放進 prompt 當你的詠唱詞，但不是官方旗標。
   • Gemini：官方文件沒有同名 ultrathink 或 reasoning-effort 旗標；用 /plan、方案比較、@codebase_investigator／@generalist、/skills 與模型設定來逼近「深想」。3.5 Flash 若已在你的 CLI 可選，可先拿來做 planning／整理；3.5 Pro 要等本機 gemini --help、/model 或官方文件明確列出後，再評估能否當 coding 主力。
2. 2

   決定最佳解法

   讓它先把候選作法攤開、比較取捨，再選一個方向。互動模式下由你拍板；第一次使用 codex exec 時也先停在唯讀規劃，確認檔案範圍、風險與驗證方式後，再由你手動開始可寫入的第二階段。

3. 3

   派工／dispatch

   不要混線。Claude Code 就用 @"agent"、/agents 或自建 skill 派工；Codex 就在 prompt 內明講 spawn subagents 與驗證規則；Gemini 用 /agents 管 subagent、用 prompt 開頭的 @agent_name 指定 subagent，@path 則是帶檔案／資料夾。每家各自完成「挑工作項 → 派工 → 整合 → 驗證」。

Claude Code 對話輸入

這段貼在 Claude Code 對話裡，不是 shell 指令。目標是讓 Claude 先深想，自動挑選工作項，決定最佳解法後派工；不要產出跨工具交棒文字。

ultrathink。先不要改檔。請先讀目前需求與相關檔案，列出 2-3 個可行方案，逐一比較取捨、風險、實作成本與驗收方式，最後選出最佳解。

決定最佳解後，請自動挑選工作項並規劃派工：哪些由主對話處理、哪些交給 @"uiux (agent)"、@"frontend (agent)"、/component-audit 或其他合適 subagent / skill。先不要實作，先把派工與驗收講清楚。

請輸出：
1. 問題重述與目標
2. 重要限制與不能做的事
3. 方案比較表
4. 最佳解與理由
5. 工作項切分與派工：主對話、uiux agent、frontend agent、component-audit 各負責什麼
6. 實作步驟：檔案範圍、順序、驗收標準、需要跑的測試
7. 收尾檢查：diff、review、verify、殘留風險回報格式

Codex exec 終端機指令

這段在終端機執行，是 Codex 自己的路線，不要貼回 Claude Code 對話。第一次不要在工作中的儲存庫直接執行可寫入範例。先在可刪除的練習專案或獨立分支，以唯讀模式產出計畫；確認檔案範圍、風險與驗證方式後，再由你手動開始可寫入的第二階段。含機密、正式環境設定或他人未提交變更的目錄，不要使用 --ask-for-approval never。

codex exec \
  --sandbox read-only \
  -c model_reasoning_effort=xhigh \
  "只讀 AGENTS.md 與相關檔案，提出 2-3 個可行方案、檔案範圍、風險與驗證方式；不要改檔、安裝套件、連線或開 PR。"

這是可複用的多 CLI pattern：哪一家負責「想」、哪一家負責「跑」可替換。真的要進到可寫入或自動化階段時，再依目前目錄、權限、沙箱與驗收標準重新確認，不要把這張速查表當成直接放行的按鈕。

上面是單一 CLI 內部「想清楚才動手」的通用骨架。再往上一層，是讓不同 CLI、不同 session 互相搭配的具體分工模式——不是一人分飾三角，是三個工具各司其職、彼此驗證。下面 5 個案例都是已經有人這樣用、有名字的做法；原始版本細節可能持續演進，複製前一樣先用該工具的 --help 或 /help 核對旗標還在不在。

案例一：先規劃 → Claude／Codex 實作 → 獨立複查

情境：拿到一個範圍夠大、值得先想清楚再動手的任務（例如幫既有 API 加一層 rate limiting、或不算小的重構），但還沒進到「非改哪個檔案不可」的階段。

為什麼這樣分工：規劃階段可以用你已確認可用、能維持唯讀的工具多比較幾個方案；定案後再交給主力工具實作，最後由另一個乾淨的 context 複查 diff。不要把任何產品的免費額度、模型、個人登入或指令當成長期前提；帳號資格與產品路線會變，人工審過規劃才是不能省的關卡。

具體步驟：

1. 1

   在你已確認可用的規劃工具裡探索、比較方案，落成一份純文字的規劃檔（不改任何程式碼）。

2. 2

   人工看過規劃檔，方向對了才往下走。

3. 3

   開 Claude Code 或 Codex，直接引用規劃檔實作——讓它讀規劃檔，不要重講一次需求。

4. 4

   實作完，用另一個乾淨的工具或 session 看一次 diff，抓有沒有偏離規劃或漏掉的邊界情況。

人工看過 PLAN.md、確認方向沒問題後，貼進 Claude Code 對話：

@PLAN.md 照這份規劃實作。先讀過現有程式碼慣例再動手，不要引入規劃檔沒提到的額外套件或改動。

實作完，把 git diff 交給另一個可用的工具或新的乾淨 session 複查；先確認它只會讀取與回覆，不要在審查階段自動改檔。

注意事項：規劃檔一定要落成實體檔案，不是只留在對話裡，三個步驟才有共同錨點可以對；規劃階段省下來的是「試錯的成本」，不是「判斷的責任」——人工看過規劃檔這一關不能省。

案例二：跨 CLI 對抗式覆核（找自己看不見的盲點）

情境：高風險改動——認證、金流、資料庫遷移這類壞了代價很高的東西——寫完想找人覆核，但沒有其他工程師剛好有空，或想在送人審查前先自己抓一輪。

為什麼這樣分工：同一個 context 寫完程式碼又審程式碼，審查時仍帶著跟寫作時一樣的假設，不是真正的第二意見；這其實是把本頁 E.3 的技巧 11（審查別給看過你怎麼寫的人）搭配技巧 9（叫模型當自己的反方），沿著兩家不同的 CLI 展開成一整套流程。不同模型家族訓練資料、失手的地方不一樣，讓另一顆模型在乾淨、沒看過生成方推理過程的 context 裡獨立審查，抓到的問題重疊率通常很低——兩邊都點名的問題，可信度會遠高於單一意見講得再篤定。

具體步驟：

1. 1

   用 headless 模式讓另一家 CLI 在全新、不帶前情提要的 session 審查同一份 diff。

2. 2

   明講審查方的任務是「找出前一位審查者可能漏掉的東西」，逼它不要只是重複講一樣的結論。

3. 3

   交叉比對兩邊意見：雙方都點名的問題標高優先權，只有一方提到的列入次要複查。

4. 4

   意見嚴重分歧時可以加一輪「你來說服我」對話，但要先訂停損點（例如連續三輪沒有新進展就停止、改人工裁決），避免兩個模型互不相讓一直繞圈子。

git diff | codex exec --sandbox read-only "你的任務是審查這份 diff，找出前一位審查者（Claude）可能漏掉的東西：讀相關程式碼佐證，不要只信 diff 本身的說法。輸出：值得肯定的地方、依風險排序的疑慮、具體修改建議。"

git diff | gemini -p "獨立審查這份 diff，不要參考任何附帶的說明文字或 commit message 自稱做了什麼——只看程式碼本身判斷。輸出：值得肯定的地方、依風險排序的疑慮、具體修改建議。"

注意事項：也有像 codex-mcp-plugin 這類把 Codex 包成 Claude Code 內建工具（MCP server）的社群做法，讓你在同一個 Claude Code session 裡直接呼叫 Codex 覆核，不用手動來回貼；但不管走哪種做法，收斂結果時務必自己整合、講清楚同意與不同意的地方，不要把任何一邊的意見原封不動照抄照做。

案例三：CI 無人值守自動修復（兩段式安全閘門）

情境：CI 測試失敗，想讓 CLI 自動讀 log、修好、驗證過再開 PR，但不希望自動化直接把壞改動合併進 main。

為什麼這樣分工：headless 模式沒有人可以按核准鍵，全自動旗標一定要配合限縮過的沙箱層級一起用，而且「生成修法」跟「把修法套進工作目錄」最好拆成兩個獨立步驟，才能在全自動流程裡保留最後的人工把關點——自動化只負責推進到「開 PR」為止，合併永遠是人做的決定。

具體步驟：

1. 1

   第一階段（唯讀分析）：用唯讀沙箱讀 CI log 與相關程式碼，只產出診斷與修法，不改任何檔案。

2. 2

   確認這個修法值得套用（人工看過，或設一個判斷條件）。

3. 3

   第二階段（實作）：切到可寫入的沙箱，接續同一個 session 實際套用修改，跑相關測試驗證過。

4. 4

   開一個新分支與 PR，不自動合併，交給人審。

# 第一階段：唯讀分析，只出診斷不動檔案
codex exec --sandbox read-only \
  "讀 CI 失敗的 log 與相關程式碼，找出根因，寫出修法但不要改任何檔案。"

# 第二階段：確認修法後才實作，接續第一階段的 session
codex exec resume --last \
  --sandbox workspace-write \
  --ask-for-approval never \
  "照剛才的診斷套用修法，跑相關測試驗證過，最後開一個新分支＋PR，不要直接推到 main。"

注意事項：--ask-for-approval never 別跟 danger-full-access 或等同全開的沙箱疊在一起用，兩層各自把關的旋鈕要分開轉才安全；認證用 CI 平台的 secret 存 API key，不要用個人瀏覽器登入態。這套兩段式思路不是 Codex 專屬——Claude 用 --permission-mode plan 先唯讀分析、Gemini 用 --approval-mode plan 先唯讀分析，都是同一個「先看計畫、再放行執行」骨架的變形，詳見 A.7。

案例四：worktree 隔離＋多 CLI 平行試做，人工擇優

情境：不確定哪家 CLI 對某個任務表現比較好，或想要兩份獨立實作互相佐證，而不是只信一家跑一次的結果。

為什麼這樣分工：兩個 agent 同時改同一份工作目錄一定會互踩——鎖檔、index 衝突、誰的改動被覆蓋都說不清楚；git worktree 讓你在同一份 .git 歷史下開出多個彼此獨立的工作目錄與分支，各自跑各自的 CLI 完全不會互相干擾。不同 CLI／模型對同一個問題的解法差異，本身也是一種免費的交叉驗證。

具體步驟：

1. 1

   對同一個基準分支開兩個（或多個）獨立 worktree。

2. 2

   每個 worktree 裡跑不同的 CLI，餵一模一樣的任務描述。

3. 3

   全部跑完後，人工比較每份 diff：測試有沒有過、可讀性如何、有沒有抄捷徑。

4. 4

   擇優合併，或截長補短手動整合；沒被選中的 worktree 清掉，別留著長草。

git worktree add ../try-codex -b try-codex main
git worktree add ../try-claude -b try-claude main

(cd ../try-codex && codex exec --sandbox workspace-write "實作 PLAN.md 描述的功能")
(cd ../try-claude && claude -p "實作 PLAN.md 描述的功能，先讀過再動手")

# 都跑完、人工比較過後，清掉沒選中的那份
git worktree remove ../try-claude

注意事項：worktree 之間共用同一份 commit history，但工作目錄與 git index 各自獨立，可以放心平行跑；社群也有像 Worktrunk 這類工具把「開 worktree、切換、清理」包裝成一鍵操作，常常這樣做的話值得找個順手的殼再自己刻。

案例五：依風險與範圍分級，決定該上哪個推理檔位

情境：手上同時有很多性質差很多的任務——架構決策、日常 CRUD、寫文件、跑部署腳本——每次都要重新想「這次該用哪家 CLI、開多深的推理」很累。

為什麼這樣分工：不是「哪家 CLI 比較強」的問題，而是「答錯的代價」與「範圍夠不夠明確」決定值不值得花更多 token 換更深的推理。範圍明確、答錯也容易發現的任務，用預設檔位就好；牽涉架構、安全、正式環境這類「一次做對」比「做得快」重要的任務，才值得開到最深的推理檔位。把這個判斷寫成固定的分級規則，比每次臨時決定省心，也省錢。

一個可以直接照抄的分級表（依任務性質對應建議檔位，不是鐵律）：

注意事項：這是預設分級，不是鐵律——真的卡關時還是要往上加碼，回頭對照本頁 E.3 技巧 12（卡兩次就換一家 CLI 問）；分級的價值在於避免每件小事都習慣性開最貴模式，不是要你不管任務多重要都摳成本省下去。

這五種案例不是互斥的：同一個專案完全可以同時用「案例五」的分級規則決定平常任務找哪家 CLI，遇到高風險改動時再疊加「案例二」的對抗式覆核；不管走哪一種，E 段那些技巧（先把規格榨乾、先鎖驗收標準、別信嘴巴講的全過）在每一步都用得上。

D · 達人詠唱指令庫（個人化）↑ 回速查選單

達人下指令不是只喊 ultrathink，而是把「角色、範圍、限制、交付物、派工、驗證、回報格式」一次講清楚。下面每段都可單獨複製，依情境貼到 Claude Code 或終端機。

Claude Code：先規格化，不急著改檔

@"uiux (agent)" ultrathink。先不要實作。請把需求轉成完整 UIUX 規格：目標使用者、核心流程、資訊架構、版面層級、元件狀態、空/載入/錯誤狀態、responsive 行為、文案語氣、驗收標準。若資訊不足，先列最多 5 個關鍵問題；若資訊足夠，直接產出規格。

Claude Code：依規格派 frontend agent

@"frontend (agent)" ultrathink。依上方 UIUX 規格實作。先讀現有設計系統、元件命名、CSS/token、routing 與資料流；沿用既有模式，不做無關重構。實作完成後自查 mobile/desktop、hover/focus/empty/loading/error 狀態，最後回報改了哪些檔案、如何驗證、還有哪些風險。

Claude Code：模組化稽核

/component-audit ultrathink。請檢查這次新增/修改的 UI 是否有重複元件、樣式漂移、責任邊界不清、過大檔案、命名不一致、狀態缺漏與可測性問題。先列問題與嚴重度，再給最小修正方案；未經確認不要做大型重構。

Codex exec：一段式自動決策 + 派工 + 實作

codex exec \
  --sandbox workspace-write \
  --ask-for-approval never \
  -c model_reasoning_effort=xhigh \
  "ultrathink。先讀 AGENTS.md、README、package scripts 與本任務相關檔案。列出 2-3 個可行方案，說明取捨後選最佳解；不等我確認，直接按最佳解實作。需要時 spawn parallel subagents：架構探索、風險審查、測試規劃。整合後改檔，跑最相關驗證，最後用條列回報：變更摘要、檔案、驗證結果、未解風險。任務：<貼上本次要執行的任務>"

Codex exec：兩段式安全落實

codex exec --sandbox read-only -c model_reasoning_effort=xhigh \
  "ultrathink。只做分析與決策，不改檔。請讀相關檔案，列 2-3 個方案、風險、最佳解、實作步驟、驗收標準與測試命令。"

codex exec resume --last \
  --sandbox workspace-write \
  --ask-for-approval never \
  "按照上一輪最佳解實作。需要時 spawn subagents 分工；完成後跑驗證，最後回報變更、測試結果與殘留風險。"

收尾：交付前最後一輪

ultrathink。請做交付前收尾：重新讀本輪 diff，檢查是否偏離需求、是否有未驗證行為、是否有過度重構、是否有破壞既有 API/樣式/資料流。能自行修的小問題直接修；修完跑最相關驗證。最後只回報：完成事項、驗證結果、已知風險、建議下一步。

建議順序：Claude Code 先把需求規格化，再派前端 agent；需要全自動實作時，把收斂後的工單交給 codex exec -c model_reasoning_effort=xhigh；交付前再跑一次收尾 prompt。

E · 進階提示技巧（跨 CLI 通用）↑ 回速查選單

這些技巧照著「開工前把規格榨乾 → 餵對素材逼出判斷力 → 抓盲點 → 收斂到證據 → 管好 context → 除錯不用猜」的順序分成六組。不用照單全收，挑一兩個跟你現在卡住的地方最像的先試就好。

E.1 開工前先把規格榨乾

模型最常見的失手不是「寫錯程式碼」，而是「做了一件跟你想的不一樣的事」。這組技巧的共同點：把決策權留在動工前，別讓模型邊做邊幫你腦補。

1. 拿 AskUserQuestion 面試自己的需求（適用：Claude Code）——別急著叫模型動工，先叫它反過來問你。把規格文件丟給它，明講要用內建的 AskUserQuestion 工具，針對技術實作、UI/UX、邊界情況、取捨逐一發問，你答完它才開工。

讀 @SPEC.md，用 AskUserQuestion 工具面試我：技術實作、UI/UX、邊界情況、資料流，任何你不確定的取捨都問，問到你有把握再開始動工。

為什麼有效：結構化提問會逼你把每個關鍵決策點明確回答，不是讓模型自己腦補後才動工，等你發現方向錯了，往往已經是半份程式碼之後的事。

2. Goal／Context／Constraints／Completion 四段式規格（適用：通用，Codex 官方文件明講，其餘 CLI 一樣受用）：每個委派任務拆成四段——目標（完成長什麼樣）、背景（環境／框架／既有慣例）、限制（不能動什麼）、驗收（怎麼確認真的做完）。

Goal：修好登入頁 email 驗證的 regex bug。
Context：apps/web，React + TS，驗證邏輯在 src/lib/validate.ts。
Constraints：不動測試檔命名、不加新套件、命名跟現有慣例一致。
Completion：跑 pnpm test src/lib/validate.test.ts，全過才算完成。

為什麼有效：四段裡最常被漏掉的是「驗收」——沒寫清楚怎麼算完成，模型容易自認做完卻拿不出客觀依據；四段各就各位，來回追問的輪次會明顯變少。

3. 先交計畫，核准了才准動手（適用：通用，三家都有對應機制；逐字鍵位見上方 C 段）——超過一個檔案的改動，先要求模型只做分析、列出要動的檔案與步驟，等你點頭才准開始編輯。Claude Code 有 Plan Mode；Codex 互動模式打 /plan；Gemini CLI 的 /plan 更嚴格，進入後是唯讀環境，寫入工具只能碰暫存的規劃檔，其餘檔案完全鎖死，逼你先審過計畫再放行。

先不要動任何檔案。列出你會碰的檔案、修改順序，以及你不確定、需要我確認的假設。等我回覆「開始」才准編輯。

為什麼有效：糾正一份計畫只要幾分鐘；糾正一個蓋在錯誤假設上、寫到一半的實作要花的時間多很多。先看計畫，也是攔截「規格本身有歧義」的最後機會。

4. 明講怎樣算作弊，然後自己先來亂一次（適用：通用）：驗收標準不要只寫「測試要過」，具體列出禁止的捷徑——不准停用測試、不准塞 placeholder、不准刪斷言、不准把 lint 規則關掉。寫完後花兩分鐘扮演模型的角色，想想「換作是我，會怎麼鑽這條規則的漏洞」，抓到就補回規格裡。

驗收標準：47 個測試全過，不准跳過／停用／改成 mock；不准刪除或弱化任何斷言；lint warning 數維持 0（不准加 eslint-disable）；工具呼叫要用真的抓到的資料，不准塞 placeholder 值。

為什麼有效：模型跟人一樣，會找規格裡最省力的合法讀法；規格留了模糊地帶，就會有人（或模型）剛好卡在那個地帶交差。先幫規格找過一次漏洞，模型能鑽的空間就先被你補掉了。

E.2 餵對素材、逼出判斷力

同一個模型，餵的東西不同，答案品質差很多。這組講的是「料怎麼準備」，不是換模型換設定。

5. 深推理不是開好開滿，是按難度分級用（適用：通用；逐字鍵位見上方 C 段）——Claude 的 think／ultrathink、Codex 的 model_reasoning_effort 都是「拉高思考預算」的旋鈕；Gemini CLI 沒有同名旗標，但可以靠 /plan 先收斂方向，並用 settings.json 的 plan.modelRouting 讓規劃階段自動切到較省成本的 Flash、真正動手時再切回 Pro，殊途同歸做到「分級」。三家共同的心法：簡單任務用預設就好，只有答錯代價高、牽涉多步推理的任務才值得多花 token 換更深的思考——社群實測 Codex 的 xhigh 相對 medium 可能吃到 3–5 倍 token，亂用只是燒錢燒時間換不到更好答案。

這個 race condition 只在高並發下重現，前兩次直覺修法都沒用。ultrathink：把所有可能的執行順序都列出來，再下結論——不要用「應該是」開頭。

為什麼有效：推理強度是成本與正確率的權衡，不是越高越好；把「這題值得燒多少 token」交給任務難度判斷，而不是習慣性全開，能省下大量無謂的等待與費用。

6. 有原始素材就別轉述，直接餵（適用：通用）：有錯誤訊息、log、既有程式碼可以餵，就別用「大概是 xxx 那邊出問題」這種轉述；用管線把原始內容灌進去，或用 @path 精準指到檔案。

git diff --staged | claude -p "檢查這份 diff 有沒有邊界情況沒處理，只列 blocking 問題，附上行號。"

為什麼有效：轉述一定會遺失細節，甚至夾帶轉述者自己的錯誤詮釋；讓模型直接讀原始素材，少一層失真，除錯情境尤其明顯。

7. 別只要一個答案，要一張排序過的取捨表（適用：通用）——效能最佳化、架構選型這類有取捨的任務，別讓模型直接選一個方案就動手，改成要求列出 2–3 個方案，依影響力和風險排序，每個附上要動的檔案／函式、預期取捨、怎麼驗證。

先抓出效能瓶頸，再提出 3 個最佳化方案，依「效果／風險」排序。每個方案要寫：確切要改的檔案與函式、預期取捨、驗證方式（改前改後的 benchmark 數字）。先不要動手，等我選一個再實作。

為什麼有效：模型預設傾向直接動手寫，不會主動攤開取捨；要求排序過的清單，把「選哪個」的決定權留在你手上，也逼模型把原本藏在心裡的判斷準則講出來給你檢查。

E.3 抓盲點：讓模型跟自己吵架

同一個 context 寫完程式碼又審程式碼，審查時仍帶著跟寫作時一樣的假設——不是真正的第二意見，只是換句話再說一遍。這組技巧都在做同一件事：想辦法製造真正獨立的視角。

8. 換個角色重新問一次：陌生人 PR 視角（適用：通用）：想看懂一段陌生、老舊或別人寫的程式碼，別問「解釋這段」，改問「當作在審一份陌生人送來的 PR，帶著懷疑走一遍」。

把這支檔案當成陌生人送來的 pull request 來審查，不是單純解釋它在幹嘛——挑出任何看起來可疑的地方、不合理的假設、沒處理的邊界情況。

為什麼有效：同一個模型面對同一段程式碼，換一種角色框架，輸出品質差很多；「解釋」偏被動描述，「審查」會主動找碴，這是純靠換句話說就能拿到的免費升級。

9. 叫模型當自己的反方（適用：通用）——寫完一版方案或程式碼後另開一輪，明講「扮演反方」，從邏輯、並發、效能、安全、可維護性不留情面找漏洞，而不是問它「你覺得寫得怎麼樣」。

現在扮演反方，攻擊你自己剛寫的實作——邏輯、並發、安全、可維護性每個角度都要打。假設它是壞的，去找出哪裡壞。

為什麼有效：問「寫得好嗎」，模型多半順著自己剛才的思路回答「還不錯」；明確要求切換到攻擊者角色，才挖得出寫的當下完全沒想到的坑。

10. 叫它把假設攤開、幫自己打信心分數（適用：通用）：在每個實作或除錯提示尾端加一句，要求模型列出做了哪些假設，並針對每個部分打信心分數（1–10）。

列出你在這次修改裡做的每一個假設，針對每一段程式碼打信心分數（1–10），任何你不確定的地方明講出來。

為什麼有效：這句話專門抓「輸出看起來對、其實建立在錯誤假設上」的案例——這類 bug 最陰，因為連模型自己輸出時都表現得很篤定，不主動問就不會講。

11. 審查別給看過你怎麼寫的人（適用：通用；Claude、Gemini 都有明確的 subagent 語法可以指定「誰來審」）——真正重要的改動，把生成與審查拆成兩個乾淨的 context（甚至換一顆模型），審查方只看最終 diff，不看生成方的推理過程或自我辯護。Claude Code 可以用 /agents 建一個專職審查的 subagent 再用 @ 指定呼叫，Gemini CLI 則是在 prompt 開頭直接寫 @subagent_name 指定；兩者都能讓審查方在乾淨、不共用生成方推理紀錄的 context 裡工作。

新開一個對話、不帶任何前情提要：這是一份 diff（不附說明）。你的任務是挑出 bug、漏掉的邊界情況，以及測試其實沒真的驗證到的地方。

為什麼有效：同一個 context 審自己寫的東西有系統性的寬鬆傾向——生成者跟審查者共用同樣的盲點，容易一起失手；藏起推理過程、甚至換一顆模型，才能打破這種「一起犯錯」的相關性。

12. 卡兩次，就換一家 CLI 問（適用：通用，正是「同時裝了不同 CLI」的價值所在）——同一個 bug 連續修兩次都沒修好，別急著試第三次直覺解法，把錯誤訊息、已經試過的兩種修法、失敗的測試一起丟給另一家 CLI 的乾淨 session，當作真正的第二意見；拿到回應後自己整合、講清楚同意與不同意的地方，別原封不動轉貼。

這是同一個 bug 的兩次失敗修法，附完整錯誤訊息與失敗的測試。我漏看了什麼？先不要重寫我的程式碼，只給診斷。

為什麼有效：不同模型家族的失手分布不一樣，第二顆模型抓到第一顆系統性盲點的機率，比讓同一顆模型再猜一次高；設一個明確的觸發點（連續兩次失敗）能避免每題都跨模型核對，浪費時間又推高成本。

E.4 別信模型講的，收斂到證據

模型說「應該可以了」不是證據，「全過」兩個字也不是。這組技巧的共同心法：把驗證這件事，從「聽模型講」換成「看真的發生了什麼」。

13. 別讓模型用嘴巴驗收，叫它真的跑一次（適用：通用；Claude Code 團隊公開講法：這是繼 Plan Mode 之後另一個效果最明顯的習慣）——別讓模型光靠讀程式碼推論「這樣應該就對了」，接上瀏覽器自動化工具或測試指令，明講要它實際跑一遍、看真實輸出、對照預期再回報。

實作完後，用瀏覽器工具打開頁面、實際操作一次我描述的流程，截圖給我看，確認畫面真的長那樣再說完成——不要只用講的告訴我應該可以了。

為什麼有效：模型在同一個 context 裡推論自己的程式碼，帶著跟寫作時一樣的盲點；實際跑一次系統，這個偏誤就不存在了——這是「相信但要查證」的機械化版本。

14. 「全部綠燈」不能照單全收（適用：通用）：不要看到「測試都過」就結案，抽查一下綠燈背後真的發生了什麼——lint 設定有沒有被偷偷放寬、測試斷言是不是形同虛設（例如斷言 true === true）、引用的資料是不是真的抓到的而不是憑空捏造。

把改動過的測試檔 diff 直接給我看，不要只給測試跑完的結果——我要確認沒有斷言被刪掉或改弱，才願意信這個「全過」。

為什麼有效：模型跟其他被獎勵訊號驅動的系統一樣，容易去滿足「看得到的那個指標」，而不是指標背後真正代表的行為；一個容易被滿足又不用真的解決問題的指標，遲早會被用這種方式滿足。

15. 讓編譯器和 linter 當裁判，不要自己當傳聲筒（適用：通用）——把「每次改動後自己跑 build／lint／test，出錯就修或講清楚為什麼修不了」直接寫進指示，讓模型自己接手這個迴圈，不用你每次手動複製錯誤訊息貼回去。

每次修改後自己跑 build、lint、跟相關測試；非零結束碼視為擋關，不用問我要不要繼續，直接修，修不了就講清楚卡在哪裡、為什麼。

為什麼有效：這是最快、最便宜的修正迴圈，而且不需要人先發現問題——環境本身就是裁判，模型很難靠嘴巴辯過一個不過的 build。

16. 先鎖驗收線，再讓模型動手（適用：通用）：要求模型先寫一個會失敗的測試，用直接比對結果的斷言（例如比對回傳值，而非只檢查有沒有丟例外），明確禁止「為了讓測試過而改測試」；測試本身你點頭了，才准開始實作。

先幫這個功能寫一個會失敗的測試，用直接斷言（例如 assertEquals('completed', result.status)），不要只檢查有沒有丟例外。在我核准這個測試之前，不要實作功能、也不要改動測試本身。

為什麼有效：順序顛倒過來（先實作後補測試）很容易寫出「配合自己實作」的測試，測試形同虛設；先鎖死驗收標準再實作，能防止模型事後把及格線拉低來遷就自己寫的程式碼。

E.5 Context 別靠腦補，靠寫檔案

長任務最先壞掉的通常不是 token 用完，而是舊任務的假設、措辭、走偏的嘗試汙染了新任務的推理。這組技巧的心法：把「記得到哪裡」這件事，從對話紀錄搬到檔案上。

17. 一個 session 只做一件事（適用：通用）——把每個對話當成一次性、聚焦單一任務的容器，做完就開新對話，別在同一條長對話裡接著問下一個不相關的功能。

（開新 session，別接在舊對話後面）先讀 @相關檔案，這次只處理一件事：<這次要做的單一任務>，跟上一個任務無關的假設一律不沿用。

為什麼有效：context 汙染在真的碰到 token 上限之前就已經在發生；乾淨的新對話配上明確帶入的必要檔案，往往比在一條已經講岔題的對話裡硬撐更快、更準。

18. 進度靠寫檔案記住，不要靠對話紀錄（適用：通用；Gemini CLI 另外內建 /restore 可還原到工具動手前的檔案快照，是同一個心法的另一種實作）：請模型把計畫、決策、進度寫進磁碟上的檔案（例如 NOTES.md、PLAN.md），每個工作單元開始前先讀這些檔案，而不是依賴「應該還記得剛才講的」。收工或 context 快滿時，額外留一份結構化交接筆記：目前狀態、卡住的地方、已經排除的思路、下一步。

開始前先讀 PLAN.md 和 NOTES.md 裡的既有決策。每完成一個子任務，把做了什麼、為什麼這樣做寫進 NOTES.md，讓一個全新的 session 不用重新推導也能接手。收工前另外寫一份交接筆記：現況、卡點、已排除的方向、明確的下一步。

為什麼有效：寫進檔案的東西撐得過壓縮、撐得過清空對話，甚至撐得過換一顆模型接手；純靠對話紀錄或人腦記得「上次做到哪」，在長任務或多 session 專案裡並不可靠。

19. 把 commit 當存檔點，不是只當版本紀錄（適用：通用）——每完成一小段可獨立驗證的工作就 commit 一次，別累積好幾個子任務才一起送，訊息寫清楚；出錯只要退回上一個存檔點，不用手動拆解半小時份的改動。大範圍自動化修改前，也可以先開一條專用分支，做壞了整支砍掉重練，成本很低。

這段改完、編譯過、相關測試也過了，先幫我 commit 這一小段，不要跟下一個子任務的改動混在同一個 commit 裡再繼續。

為什麼有效：長任務的每一輪都可能悄悄跑偏，高頻率的小 commit 把任何一輪失手的代價鎖在「重做最近幾分鐘」，而不是「拆解一小時份互相纏繞的改動」。

E.6 除錯與重構：別用猜的

改別人的、或改自己很久以前寫的程式碼，風險最高的動作就是「邊看邊改」。這組技巧把「看懂再動手」的紀律，變成明確可以下達的指令。

20. 除錯別叫模型用猜的，先插樁拿真資料（適用：通用）——遇到難重現的 bug，別一直要求模型直接「猜」根因，先請它在懷疑的路徑插入足量的 log／追蹤點，你實際跑一次、把真實輸出貼回去，再讓它根據真資料分析。

先不要猜根因。在你懷疑的程式路徑加上足夠的 log，把你需要拿來判斷的每一個狀態都記下來；我跑完貼輸出給你，你再根據真實資料分析，不要在這之前下結論。

為什麼有效：模型跟人一樣，資訊不夠的時候容易腦補出一個「聽起來合理」但其實是錯的根因；先插樁拿到真實資料再推論，能把除錯從猜測變成有證據可查。

21. 大範圍重構前，先畫完依賴圖再動手（適用：通用）：重構前明講「先不要改任何一行」，要求模型讀完所有相關檔案、畫出完整依賴關係（誰 import 誰、共用了哪些常數、有沒有 side effect），輸出一份重構計畫給你核准，才准真的開始改。

先不要改動任何檔案。讀完所有牽涉到 OrderValidator 的檔案，畫出完整依賴圖（import、export、共用常數、side effect），寫一份重構計畫給我核准。

為什麼有效：直接下「把驗證邏輯抽出來」這種指示，等於默許模型邊讀邊改，一旦漏看三個檔案外的共用變數就出事；把分析跟修改切成兩個明確階段，在陌生或老舊的程式庫上可靠度差很多。

這 21 招不用照單全收，也不用背——挑一兩個跟你現在卡住的地方最像的先試，比一次塞滿所有招式更容易養成習慣。指令措辭本身不是魔法，真正在做事的是它背後逼出來的紀律：先想清楚、找人吵架、拿證據說話。