社群在講 prompt engineering 的時候，主流敘事都是「反覆 iterate」——
- 第一版 prompt 拿到爛結果
- 改 prompt（加 example、調 temperature、改順序）
- 再試
- 結果好一點點，但其他面向退步
- 再改 prompt
- 這個 loop 不斷
我自己很少有這樣的經驗。寫到這裡我自己也很困惑——為什麼大家在勤奮 iterate prompt 的時候，我卻覺得這個動作很少需要做？
想了一陣子我覺得是兩件事：程式需求定義本身就清楚、Skill 系統化把 prompt iteration 替換掉了。
這篇是反直覺立場文。如果你是「我每天都在 iterate prompt」的人，可以看一下我這個論點是不是 raise 出你忽略的東西。
程式定義夠清楚 → AI 給的結果就準
寫 code 的 prompt 跟一般對話 prompt 有一個本質差異：程式 task 是高度 codify 的。
「寫一個 function 把這個輸入 transform 成那個輸出」、「重構這段 code 讓它符合 X pattern」、「修這個 test 失敗的 case」——這些 task 都有清楚的成功標準（test 過、type check 過、邏輯對），不像「幫我寫一篇 blog 文」那樣主觀模糊。
當你的需求本身定義清楚——
- 輸入是什麼（具體的 type / schema / 範例）
- 輸出該長什麼樣（具體的 type / schema / 預期行為）
- 約束是什麼（不能改 X 檔、要 follow Y pattern）
- 成功怎麼驗證（test pass、type check、執行對應結果）
——AI 給出來的東西基本上就準，不需要 iterate。
我用 Claude Code 寫 code 的失敗率不高。失敗時通常不是「prompt 寫得不夠好」，是「需求本身定義模糊」。修法不是 iterate prompt，是 iterate 需求拆解。
Skill 系統化讓 iteration 更不需要
Claude Skill 出來之後，prompt iteration 在我這邊出現的頻率又掉了一個級距。
原因：重複的 prompt 不再是 prompt，是 skill。
舉例——以前我每次想做 PR review 都要寫一段「請你 review 這個 PR、check 這幾項、用 X 格式回」的 prompt。如果哪次回得不滿意，下一次我就 iterate 那個 prompt。
現在這個動作變成 Skill。我寫一次 SKILL.md，定義好 review 流程、check 清單、回應格式——之後每次 trigger 都是同一套穩定行為。沒有「prompt 這次寫法 vs 上次寫法」的差異，自然也沒有 iterate 的空間。
對於穩定的、重複的 task，Skill 把 prompt 從「each-time 動作」變成「one-time 設定 + each-time trigger」。這層抽象殺掉了 prompt iteration 的大部分需求。
那 iteration 跑去哪？
不是「iteration 消失了」——是 iteration 從 prompt 層往上一層走，變成 skill iteration。
我自己一直在想：
- 這個 skill 設計成這樣 trigger 對嗎？（auto-load 觸發條件）
- 這個 skill 該拆成兩個還是合一個？
- skill 裡的 instruction 該寫多細？太細模型會 over-fit、太粗模型會偏題
- skill 跟 subagent 的邊界在哪？什麼該放 skill、什麼該放 subagent？
這些都是真實的 iteration——但在 skill 設計層，不是在每次 prompt 寫法上。
這個轉移很重要——它代表「prompt engineering 的精力該花在哪」這個問題的答案變了：
- 舊範式：每次寫 prompt 時調整字句、加 example、調 temperature
- 新範式：建構穩定的 skill 系統，讓重複 task 不再需要寫 prompt
那「一直 iterate prompt」的人在做什麼？
我猜兩種情況之一：
情況 1：需求本身沒拆清楚
如果你 iterate prompt 時調整的是「描述需求的字句」——加 example、改順序、加約束——那其實是在補需求拆解的不足。
這個動作應該往上一層做：先把需求拆清楚再寫 prompt。需求清楚了之後，prompt 寫得簡潔通常就 work。
這件事跟需求拆解這個基本功有關，不是 prompt engineering 的事。需求拆解詳見 01-requirements-decomposition。
情況 2：重複 task 沒系統化成 Skill
如果你發現自己「同樣類型的 task 每次都在重新寫 prompt」——那是 Skill 在呼喚你。把那個 prompt 寫成 SKILL.md，下次 trigger 自動跑。
不要每次都從頭寫一個 prompt 然後抱怨它「跟上次的版本不一致」——那不是 prompt 問題，是你還沒抽象到 skill 層。
我的「prompt」其實長什麼樣
我給 Claude Code 的 prompt 大致就是：
「在 [檔案 X] 改 [行為 Y]，保持 [pattern Z] 一致。改完跑 [test 指令]。」
短、明確、可驗證。沒有什麼 role play、沒有 chain-of-thought 提示、沒有 few-shot examples。
如果這個 prompt 給出來的結果不好——我會回頭看「需求 Y 是不是定義模糊」、「pattern Z 在 codebase 裡是不是其實有兩種寫法」。問題在需求那層，不在 prompt 字句。
修法：把需求重新拆清楚，重給一次。不會反覆 iterate 同一個 prompt。
反思一句話
「Prompt Engineering 要反覆 iteration」這個說法在程式 task 上不太對。真正的功夫在需求拆解 + Skill 系統化。
需求清楚了，prompt 簡潔就夠。重複 task 抽成 Skill，prompt 連寫都不用。剩下需要 iterate 的場合很少——而且該 iterate 的也不是 prompt 字句，是更上層的 skill 設計或需求拆解。
如果你發現自己每天都在 iterate prompt——往上看一層，可能你在處理的問題不在 prompt 那邊。