Claude Code 實戰心法：怎麼下指令、怎麼驗收

上一篇我們把 Claude Code 裝起來、跑了第一個任務。但「能動」跟「好用」之間有一段距離：同一個工具，有人拿到的是靠得住的開發夥伴，有人拿到的是需要一直善後的實習生。差別幾乎都不在工具，在怎麼下指令、怎麼驗收。

這篇整理我認為最值得先養成的三個習慣：plan mode、CLAUDE.md、測試驗收。三個都不難，但合起來會讓你的成功率完全不同。

先規劃再動手：plan mode

Claude Code 有一個規劃模式（plan mode）：在這個模式下它只能讀、不能寫。它會搜尋專案、讀相關檔案、思考做法，最後交出一份完整的實作計畫給你看；你核准了，它才切回一般模式開始動手。

為什麼這很重要？因為 AI 開發最貴的錯誤不是「改錯一行」，而是「往錯的方向改了二十分鐘」。plan mode 把「想法對不對」這件事提前到動工之前確認。

我自己的習慣是：小修小補直接做，牽涉三個檔案以上或要動資料結構的任務，一律先進 plan mode。看到計畫裡有你不同意的地方，直接在對話裡修正它的方向，改計畫永遠比改程式便宜。

把專案知識寫進 CLAUDE.md

你有沒有發現，每次開新對話都要重講一樣的話？「我們用的測試指令是這個」「commit 訊息要照這個格式」「那個資料夾是舊程式不要動」。CLAUDE.md 就是解法：在專案根目錄放一個這個名字的檔案，Claude Code 每次啟動都會自動讀進來，當成這個專案的長期背景知識。

一份實用的 CLAUDE.md 大概長這樣：

# Project notes for Claude

## Commands
- Run tests: npm test
- Start dev server: npm run dev
- Type check: npm run typecheck

## Conventions
- Use TypeScript strict mode
- All API handlers live in src/api/
- Never edit files under legacy/

## Definition of done
- Tests pass and type check is clean

下指令的訣竅：目標加驗收條件

好的指令有一個固定配方：目標、脈絡、限制、驗收條件。比較這兩種下法：「幫我改一下上傳功能」對上「上傳超過 10MB 的檔案會失敗，幫我查出原因並修好；不要動到既有的 API 介面；修完把上傳相關的測試跑一遍，全綠才算完成」。

前者它得用猜的，後者它清楚知道做什麼、邊界在哪、怎樣叫做好。

• 目標講結果：要解決什麼問題，而不是要按哪些鍵。
• 脈絡給線索：錯誤訊息、重現步驟、相關檔案名稱，有什麼給什麼。
• 限制畫邊界：哪些東西不能動、要維持哪些相容性。
• 驗收條件給終點：怎樣算完成，最好是可以執行驗證的標準。

另外，除錯類任務有一個高價值素材：錯誤原文。把終端機裡完整的錯誤訊息與重現步驟直接貼進對話，勝過任何轉述；它能從堆疊追蹤直接定位到出事的檔案與行號，少走很多彎路。你轉述「好像跟資料庫有關」，它就只能跟著你的猜測走。

讓它自己驗證：跑測試

Claude Code 跟聊天式工具最大的差別，是它能執行指令，也就是能自己驗證自己的成果。這是實戰裡最值得利用的一點：把「跑測試」寫進任務裡，它就會改完自己跑、看到紅燈自己修、再跑一次，直到綠燈才回報完成。你驗收的不是它的說法，是測試結果。

沒有測試的專案怎麼辦？兩個做法：一是請它先幫要改的功能補上基本測試再動工，二是至少要求它「改完實際執行一次並貼出結果」。核心原則不變：驗收要靠證據，不靠信心。

小步前進，常常驗收

還有一個節奏上的心法：任務切小，驗收切勤。與其一口氣說「幫我把整個會員系統重構掉」，不如拆成「先抽出驗證邏輯」「再換掉資料存取層」這樣的小任務，每完成一段就看一次 git 差異、跑一次測試、commit 一次。

小步前進有兩個好處：方向偏了能早發現，付出的成本只有一小步；而每一個 commit 都是一個可以安全退回的存檔點，你會更敢放手讓它嘗試。

把三件事串成一個流程

實戰裡這三個習慣是一條流水線：CLAUDE.md 讓它一開場就懂你的專案，plan mode 讓方向在動工前對齊，驗收條件與測試讓成果有客觀標準。你的角色也跟著升級：從「逐行看程式的人」變成「定目標、審計畫、驗成果的人」。這正是用 AI 開發該有的樣子：它多做，你把關。