三個真正留存下來的 AI 程式設計工作流

關於 AI 程式設計的建議大多像釋出會：演示驚豔，週五就忘。經過幾個月的日常使用，真正留下來的工作流只有幾個。這篇講三個。

1. 規格先行（Spec-first）

生成任何程式碼之前，先寫一小段規格——路由、資料結構、邊界情況——再讓模型照著寫。規格很短（一屏以內），但它逼著我先做決定，否則這些決定會被 AI 的套話糊弄過去。

經驗法則：規格能寫進一屏，生成的程式碼通常靠譜；寫不進一屏，說明任務該拆了。

2. 測試錨定的重構

重構按這個節奏走：

1. 先用幾個特徵測試（characterization tests）凍結現狀。
2. 讓模型放開手腳重寫。
3. 迭代到測試全綠，而且斷言一個字都不用改。

測試是契約，不是提示詞。模糊的提示詞產出模糊的重構；一個失敗的測試能帶來目標明確的對話。

3. 評審即提示詞

AI 槓桿率最高的時刻不是生成，而是評審。把 diff 貼過去問一句"上線後哪裡會炸"，總能抓到我剛寫完程式碼時看不見的那類問題：錯誤分支、時區運算，還有那個會變成雪崩的重試邏輯。

沒有留存下來的

• 全自主的多檔案 agent 寫真實產品程式碼——review 的成本超過了省下的打字時間。
• AI 生成 commit message，和我不自動生成檔案的理由一樣：寫作本身就是思考。
• 提示詞庫。好的提示詞已經變成肌肉記憶，剩下的都爛在了收藏夾裡。

三個工作流的共同點：AI 在錨定於一個我可控的產物時效果最好——一份規格、一套測試、一個 diff——而不是錨定在我的意圖上。