把任務講成規格:一個好的 Claude Code 指令長什麼樣

入門兩課你大概感覺到了：同樣交給 Claude Code，有時一次到位，有時改出一個能跑但不是你要的東西。

九成的差別不在它，在你那句話。寫好給 agent 的任務，其實就是 prompt engineering——但對工程師，有個更熟的講法：把任務當成一份規格(spec)來寫。

一份好規格的四塊

1. 目標——要它達成什麼，一句話，講行為不講實作。 「讓匯出 CSV 支援自訂欄位順序。」

2. 相關檔案與脈絡——它該看哪裡、參考什麼 pattern。 「匯出在 export/csv.ts，欄位設定在 export/config.ts，照 export/pdf.ts 處理欄位順序的方式做。」

3. 預期結果與驗收標準——怎樣算做完。這是工程師最該給、也最容易漏的一塊。 「使用者能拖拉欄位順序，匯出的 CSV 照新順序。補測試涵蓋『自訂順序』與『預設順序』，npm test 要綠。」

4. 界線——什麼不要碰、什麼要先問。 「不要改既有的欄位篩選邏輯。不要動 schema。要跑 migration 的話先停下來問我。」

你不用每次寫這麼長，但結果不如預期時，十之八九是缺了一塊——而工程師最常缺的是第三塊：沒給驗收標準，於是它「自我感覺良好」地交了一個沒測到邊界的版本。

給驗收標準，讓它自己知道有沒有做完

這是 coding agent 特別有用的一招：把「怎樣算對」變成它能自己驗的東西。

• 給能跑的測試：「補這幾個測試並讓它們通過」比「確保正確」具體一萬倍。
• 給明確的預期行為：輸入什麼、該輸出什麼、邊界情況怎麼處理。
• 給可執行的檢查：「跑 npm run lint 和 npm test，都綠才算完成。」

當驗收是它能自己跑的東西，它會自己反覆改到通過，你收到的版本品質高很多。

用範例，別用形容詞

「寫得乾淨一點」會被各種解讀，「照 users.ts 的寫法」不會。

指一個現成的檔當範本，是最精準的指令：命名、錯誤處理、測試風格，它會照著抄。你的 codebase 本來就是最好的 style guide——指給它就好。

大任務：先計畫，再動手

「重構整個通知系統」這種任務，一次叫它改，它只能邊做邊猜，你也難審。

先讓它出計畫、別寫 code:

「先不要改任何檔。給我一個重構通知系統的計畫：要動哪些檔、分幾步、每步的風險、怎麼驗。等我確認再開始。」

你看過計畫、確認方向(甚至改幾步)，再放它動手。Claude Code 也有「先計畫再執行」的模式專門做這件事。好處是：在它寫了 500 行你才發現方向錯之前，先用一段計畫對齊。 大任務拆成可審的小步，是讓它可靠的關鍵。

把規格存起來，別用一次就丟

某些任務你會一直做(加端點、寫某類測試、跑某種重構)。當你某次的規格寫得很順，存起來——專案層級的固定慣例，寫進 CLAUDE.md;可重用的任務樣板，之後可以做成自訂指令(進階階段會講)。

練習：把你上一個失敗的指令改成規格

回想入門階段，有沒有哪次它改出不是你要的東西？把那次的交代調出來，對照四塊：目標清楚嗎？指了相關檔嗎？給了驗收標準嗎？設了界線嗎？補上缺的，再交一次。

下一課很關鍵：它會跑指令、改你的檔——在你放手讓它跑更多之前，先學會用權限、sandbox 與 hooks 設好哪些能自動、哪些一定要你放行。

林子睿（編輯：廖玄同），《把任務講成規格:一個好的 Claude Code 指令長什麼樣》，矽基前沿 [Si]gnals，2026-06-19。https://signals.tw/articles/claude-code-good-prompts/