在 diff 上迭代，而不是重寫
一旦程式碼存在了，就要抵住把整個東西重新要一遍的衝動。像"把它弄好一點"這種模糊的追問會扔掉能用的程式碼，並重新引入你早已修過的 bug。指向你想要的那個具體改動。
這不對，把整個東西重寫一遍。
函式能用，但有兩個問題：
1. 那行 `throw new Error` 的錯誤應當返回一個
Result 型別，而不是丟擲——和上面 validateUser
函數里的模式保持一致。
2. 迴圈每次迭代都重新讀 `items.length`；把它提到迴圈外。
只給我看這兩處改動的 diff。
健康的迴圈是一個緊湊的迴路：向模型提示，讀取輸出，然後用一個小而有針對性的 diff 來打磨——絕不整體重寫——直到它對為止：
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 提示 │ ──▶ │ 模型 │ ──▶ │ 輸出 │
└─────────┘ └─────────┘ └────┬────┘
▲ │
│ ▼
│ ┌─────────┐
│ 好嗎? │ 審查 │
│ 是 ◀───────────────────┤ diff │
│ └────┬────┘
│ │ 否
│ 最佳化 (小 diff) │
└───────────────────────────────┘
偏移? ▶ 重置到上一個好版本
要一份 diff（而不是一次完整的重寫）能讓改動保持可審查，並保住那些已經能用的部分。把 AI 的輸出當作一位同事的 ：對具體的行做評論，要求有針對性的編輯。當一個改動跑偏，程式碼隨著每次回覆離你想要的越來越遠時，別再一味打補丁——回退到你信得過的上一個版本，再用一段更鋒利的描述從那裡重新提示。在一個壞掉的基礎上一路向前迭代，只會把爛攤子越疊越大。