Claude Code 5 個高 leverage prompt pattern：plan-first、show-me、verify-with-test

情境

你用 Claude Code 已經一段時間。日日都叫佢寫 code、改 bug、refactor。

有時神級——三分鐘搞掂一個你估要兩個鐘嘅嘢。有時災難——出咗成兩百行你冇要嘅嘢，郁咗五個你冇講過嘅 file，最後要 git reset 重嚟。

差別唔係 model，係你開頭點問。一年用落嚟，我發現有 5 個 pattern 比其他八成都好用——同樣嘅 model、同樣嘅 codebase，產出質素差成倍。

呢篇將 4 個寫入 workflow，第 5 個放入心態。每個 pattern 都講：點寫、加個具體例子、再講邊個情況唔啱用。

跟住做

1. Plan-first：先列 approach 唔好寫 code

最常見嘅災難：你句問題太闊，Claude 揀咗一條路衝晒落去，寫完先發現方向錯。

解法係逼佢先計劃，唔畀佢一開始就出 code：

我想加一個 feature：[描述]。唔好寫 code。先列 3 個唔同 approach，每個包：
1 句描述
改邊幾個 file
主要 trade-off（複雜度 vs 擴展性 vs migration cost）
等我揀咗一個你先動手。

3 個 approach 嘅威力：逼 Claude 唔好淨係衝去最明顯嗰個。第 2、第 3 個 approach 通常會帶出第 1 個冇諗到嘅 edge case。

唔啱用：純粹改 typo、改 string、加 log——呢啲嘢用 plan-first 係多餘。一句搞掂嘅嘢唔好用呢個 pattern。

2. Constrain-output：明確劃定 scope

第二常見嘅災難：你叫佢改 a.ts，佢順手「幫你」改埋 b.ts 同 c.ts，因為佢覺得「咁先一致」。

// 災難 prompt
幫我 refactor 個 user service。

// 高 leverage prompt
淨係改 src/services/user.ts 入面 getUserById 個 function。
唔好 touch 其他 file。唔好改 type definition。
如果你覺得要改其他嘢先 work，停低同我講原因，唔好自己動手。

明確列出邊個 file 可以動、邊個唔可以，係方便人 review 嘅起步。Diff 細，review 容易，rollback 安全。

Scope：
可以改：src/lib/parse-invoice.ts
唔可以改：呢個 module 嘅 caller、type definition、test file
如果你覺得 scope 唔夠，停低問我，唔好擴張
任務：[描述]

唔啱用：跨 module refactor、rename 一個 export（搵 caller 嘅時候必然要郁多個 file）。呢類情況反而要主動畀 scope。

3. Verify-with-test：先 failing test 等 review

Claude 寫完 impl 同 test 一齊出，係最容易出幻覺嘅情況——test 同 impl 同一刻寫出嚟，互相驗證緊對方嘅錯。

解法：先要 failing test、停低、等你 review 個 test 先寫 impl。

任務：[描述 function 行為]。Step 1：淨係寫 failing test（test name + assertion），唔好寫 implementation。
Step 2：跑 test 確認佢紅，貼錯誤畀我。
Step 3：等我 review 個 test 啱唔啱 spec，核對咗你先寫 impl。唔好跳步。

你 review 個 test 嗰一刻，其實係 review spec。Spec 啱，impl 啱嘅機會就高。Spec 錯，再叻嘅 impl 都係廢。

呢個係 TDD 嘅簡化版——唔使每個週期都行，但凡係 business logic 都值得行一次。

唔啱用：純 UI 改動（睇得到嘅反饋快過 test）、摸索階段（你都唔知 spec）、一次性嘅 script。

4. Show-me：貼 sample input + output

「整個 function parse 我啲 invoice」——呢句問題咁含糊，等如冇問。Invoice 嘅 schema 係點？Edge case 係乜？Output shape 你想要乜？

唔好用文字描述，直接貼真實 sample：

我有呢類 input：[invoice_id: "INV-2026-001", items 兩件 (A1 數量 2 單價 100.50、B2 數量 1 單價 50)、currency: "HKD"、tax_exempt: false]

Sample input + output 比五段文字 spec 都清楚。Claude 寫 impl 嘅時候有個錨點，唔使估你個 schema 點。

進階版：再貼 2-3 個 edge case sample（zero qty、empty items、null currency），覆蓋到嘅情況更實。

唔啱用：你個 input shape 真係未定（仲喺設計階段）、output 係 free-form prose（呢類嘢要描述 style，唔係貼 sample）。

變化例子

變化 1：常見 anti-pattern

幾個我成日見人用緊但其實唔好用嘅 prompt：

• 「幫我整個 X」——零 constraint，零 spec。Claude 自己揀方向，你就要 review 兩百行 diff
• 「make it better」——「better」唔係指令。要講清楚邊方面（performance？readability？type safety？）
• 「點解 work？」緊接「咁搞掂佢啦」——冇確認 root cause 就動手，通常處理咗 symptom 留低 cause
• 一句問題塞 5 個 task——Claude 跳住答，漏咗第 3、4 點你都唔知

修法：每個 prompt 出之前問自己一句「Claude 而家有冇足夠資料、唔需要靠估？」估得越多，廢嘢出得越多。

變化 2：應用喺 debug / refactor / feature dev

同一套 pattern，三個場景揀法唔同：

• Debug：show-me（貼 error log + 重現步驟）+ plan-first（叫佢列 3 個可能嘅 root cause）。唔好跳去動手
• Refactor：constrain-output（明確 scope）+ verify-with-test（先補 characterization test 再郁）
• Feature dev：plan-first（揀 approach）→ verify-with-test（鎖死 spec）→ constrain-output（每個 step 細 diff）

Feature dev 通常 4 個 pattern 都用得着，debug 同 refactor 揀 2-3 個就夠。

變化 3：教 team 新同事用 Claude Code

新同事第一日上手 Claude Code，唔好叫佢自己摸。直接畀呢 4 個 pattern 做 cheat sheet：

1. 每次起 task：plan-first
2. 改 code 前：constrain-output 講清 scope
3. business logic：verify-with-test
4. 任何含糊嘅 spec：show-me 貼 sample

我見過嘅效果：senior 同 junior 用 Claude Code 嘅產出差距，唔係嚟自經驗，係嚟自有冇用呢類 pattern。Junior 行齊呢 4 個，產出可以同 senior 平手。

額外加一條 team rule：PR description 要寫低你用咗邊個 pattern。review 嘅時候一望就知個 diff 點嚟，信任建立得快。

拆解：點解 work，同邊度會仆街

跟到上面就已經用得。下面呢段係畀**想由「demo 場 work」做到「日日 ship code 都信得過」**嘅人——初學者可以跳過，唔影響你跟住做。

prompt pattern 最呃人嘅地方係：同一句 prompt，今次出靚仔，下次出垃圾，你以為自己手勢穩咗，其實只係好彩。呢 5 個 pattern 喺真實 codebase 度，會喺呢幾個位仆街，你要預咗：

1. plan-first 個 plan 本身就係幻覺 你逼 Claude 列 3 個 approach，但佢冇真係讀過你成個 codebase——佢嘅「改邊幾個 file」係估出嚟嘅。聽落好有條理，落手先發現嗰個 file 根本唔存在，或者個 function 簽名同佢講嘅唔同。

• 會出事：你信咗個靚仔 plan，揀咗，動手先發現成個前提錯，白行一轉。
• 點救：plan 入面要求佢明寫「我假設咗乜」同「我未睇過邊啲 file」；揀之前自己 grep 一兩個關鍵 file 對返，唔好淨係信佢個 markdown。

2. constrain-output 講咗「唔好 touch 其他 file」，佢照 touch 你劃死 scope，但 instruction-following 唔係 100%——尤其 context 一長、或者佢「覺得」唔改其他嘢個 task 做唔到嗰陣，會自己擴張，仲會喺中段悄悄改埋你冇講過嘅 import 同 type。

• 會出事：你以為 diff 細，merge 落去先發現郁咗五個 file，rollback 嗰陣已經 commit 咗。
• 點救：唔好靠 prompt 信任，靠 git diff 驗證——每次動手後睇實 changed files 個 list；發現越界即刻 git checkout 嗰幾個 file，重新收窄再嚟。寧願多問一句，唔好事後執手尾。

3. verify-with-test 個 failing test，紅錯咗位你都睇唔出 你叫佢先寫 failing test、停低等你 review。但 test 可能因為「import 錯」「syntax 行唔到」而紅，唔係因為 assertion 真係 catch 到 spec。你見到紅就以為 step 2 過咗。

• 會出事：個 test 紅得嚟冇驗緊正確嘢，impl 寫完一齊綠，你以為有保障，其實 spec 從來冇被測過。
• 點救：review test 嗰陣要問「佢係咪因為 assertion fail 而紅」，唔係淨係肯定佢紅；要求佢貼埋完整錯誤輸出，睇清楚紅嘅原因；最好臨時改錯 impl 一兩個位，確認個 test 真係會 catch 到。

4. show-me 你貼嗰個 sample，Claude 過擬合咗 你貼一個 invoice sample 做錨點，好處係清楚，壞處係 Claude 會啱啱好砌一個「啱呢個 sample」嘅 impl——hardcode 咗你 sample 入面嗰個 tax rate、嗰種 currency、嗰個 item 數量，真係上 production 遇到第二款就散。

• 會出事：demo 嗰個 invoice parse 到靚仔，客戶真實啲奇形怪狀 invoice（多幣種、負數、空 items）一入就炸。
• 點救：happy path sample 之外一定要貼 2-3 個 edge case sample（零數量、空 items、null currency），同明寫「唔好 hardcode 呢個 sample 嘅值，要 general」；最後自己加幾個你 sample 冇覆蓋嘅 input 試一試。

5. pattern 跟得太死，慢過自己寫 呢 5 個 pattern 係紀律，唔係宗教。改個 typo、加句 log、睇個 stack trace 都要行齊 plan-first plus verify-with-test，你會慢到想哭，最後索性唔用 Claude。

• 會出事：因為流程太重，你開始 skip 晒所有 pattern，連真正需要紀律嗰啲大改動都裸跑，得不償失。
• 點救：記住每個 pattern 都有「唔啱用」嗰節——一句搞掂嘅嘢就一句問；留返 plan-first 同 verify-with-test 畀 business logic 同大 refactor。揀啱場合用，先係 pattern 嘅重點。

呢幾個位，就係「demo 場 work」同「日日 ship 都信得過」之間嘅距離。

第 5 個 pattern——explain-then-do——係心態多過 prompt。每次 Claude 準備動手之前，叫佢「先解釋你會點做、改邊幾個 file、估幾耐、有冇風險，等我講聲 go 你先郁」。呢半秒嘅停頓，過濾走九成「衝去做先諗」嘅災難。唔係要事事管死 Claude，係攞返你本來應該有嘅話事權。

5 個 pattern 加埋唔複雜——plan-first、constrain-output、verify-with-test、show-me、explain-then-do。記得邊個 pattern 配邊個情境，比記晒所有 prompt template 重要。Claude Code 嘅優勢唔喺 model 有幾叻，係你問問題嘅紀律有幾穩。