迴圈：意圖 → 生成 → 審查 → 打磨
本書中的一切都回歸到一個迴圈。把它內化。
迴圈會一直轉，直到輸出達到你的標準——而審查是它每次都必須穿過的關口:
┌──────────────────────────────────────────────┐
│ │
▼ │
┌────────┐ ┌──────────┐ ┌────────┐ ┌──────────┐
│ 意圖 │ ─▶ │ 生成 │ ─▶ │ 審查 │ ─▶ │ 最佳化 │
│ 規格 │ │ (AI) │ │ 你 │ │ 你 │
└────────┘ └──────────┘ └───┬────┘ └──────────┘
│
通過? ▼
┌──────────┐
│ 交付 │
└──────────┘
- **意圖。**陳述你想要什麼以及關鍵的約束——輸入、輸出、邊界情況、技術棧、風格。模糊的意圖得到模糊的程式碼。
- **生成。**讓模型寫實現。別去手把手管語法；描述行為。
- **審查。**讀返回的內容。它真的做到那件事了嗎？它處理了空列表、null、失敗的網路呼叫嗎？它是能跑通的最簡版本嗎？
- **打磨。**指出哪裡不對，給出具體的修正，然後重新生成。重複直到它達到你的標準。
大多數新手會跳過第 3 步。他們生成，它能跑，他們就繼續往下走。然後它在生產環境裡、在他們從未描述過的那個情況上崩掉了。審查這一步，正是工程發生的地方。
下面是這個迴圈裡一個好的初始提示詞長什麼樣：
寫一個 TypeScript 函式 `parseDuration(input: string): number`，
把 "1h30m"、"45s"、"2d" 這樣的字串轉換為總秒數。
要求:
- 支援單位: d (天), h (小時), m (分鐘), s (秒).
- 多個單位可組合: "1h30m" = 5400.
- 對無效輸入(空, 未知單位, 負數)丟擲帶清晰訊息的
Error 予以拒絕。
- 不用外部庫。包含覆蓋邊界情況的 5 個單元測試。
只展示函式和測試。
注意它的結構：一個精確的簽名、明確的規則、點名列出的邊界情況、陳述清楚的約束，以及對測試的要求。你不是在指望模型猜對——你是在消除那些會導致糟糕猜測的歧義。
打磨這一步和第一條提示詞一樣是門手藝。模糊的反饋得到模糊的修正。比較下面這兩種修正：
差的: "這是錯的，修一下"
好的: "parseDuration('1h30m') 返回 90 而不是 5400 —— 你把數字
相加了，卻忽略了單位的倍率。在相加之前，把每個值乘以其
單位對應的秒數(d=86400, h=3600, m=60, s=1)。
另外為組合情況 '2d3h' 加一個測試。"
好的那條點名了症狀、原因和修法。你是在像評審同事的 那樣評審——而你指得越精確，花的回合就越少。每一圈迴圈都應當收斂。如果你發現自己在原地打轉，那是個訊號：你的意圖說明不足。停止重新生成，改去重寫規格。