慢下來：利用 AI 提升程式碼品質而非追求速度

關於 AI 輔助開發的主流論述往往集中在原始速度上——即在幾秒鐘內生成數百行程式碼的能力。這種「slop-cannon」式的做法鼓勵開發者提交大量且未經審核的 pull requests (PRs)，寄望於產出的數量等同於生產力。然而，這種對速度的追求往往是以犧牲架構完整性與長期可維護性為代價。

有一個強大的替代方案：不使用 LLMs 來寫程式碼寫得「更快」，而是寫得「更好」且更「慢」。透過將重心從生成轉向驗證與精煉，開發者可以利用 AI 來增強其工藝水準，而非將思考外包。

AI 驅動的審查迴圈

利用 LLMs 最有效的方法之一是將其作為嚴謹的漏洞尋找工具。雖然模型在沒有引導的情況下可能難以從零開始構建複雜系統的架構，但它們在尋找現有程式碼中的邊際案例 (edge cases)、安全性漏洞與邏輯錯誤方面表現得非常出色。

為了減少幻覺與誤報，採用多模型「辯論」或審查策略非常有效。與其依賴單一提示詞，不如實施結構化的工作流：

1. 多代理人審查 (Multi-Agent Review)： 部署多個專業代理人 (例如 Claude、Codex 與專門的 bug-bots) 來分析一個 PR。
2. 分類： 要求代理人按嚴重程度 (Critical, High, Medium, Low) 對發現的問題進行排名。
3. 驗證： 由主要代理人或人類開發者審查這些發現，排除誤報，並綜合出一份最終報告。
4. 迭代修復： 先修復 Critical 與 High 嚴重程度的問題，重複此迴圈直到程式碼庫穩定為止。

這個過程通常會揭示早於當前 PR 存在的既有漏洞，將開發過程轉化為一場提升整體程式碼庫健康度的「旁支任務」。雖然這可能會降低即時速度，但能顯著減少長期的技術債負擔。

範式轉移：從生成轉向增強

將 AI 整合進高品質的工作流中，需要改變我們對工具的認知。不應將 AI 視為開發者的替代品，而應將其視為一個功能強大的協作者。

快速原型設計與捨棄

AI 允許開發者快速探索多種實作路徑。正如一位開發者所言，能夠「快速地隨手寫出 4 種功能的變體」可以實現一種若手動操作則成本過高的實驗程度。這裡的價值不在於交付的程式碼，而在於排除法的過程——在決定最終設計之前，先找出那些「行不通」的版本。

「導師」模型

對於正在挑戰陌生領域的人來說，LLMs 可以擔任不知疲倦的導師。透過盡可能寫出最好的程式碼——即使是壞掉的——並要求 AI 解釋「為什麼」它無法運作，開發者可以維持其閱讀理解能力與對系統的心理模型。這種緊密的反饋迴圈確保了開發者仍是邏輯的主要驅動者，防止了當 AI 直接寫出解決方案時所產生的「技能退化」。

組件級監督

與其採用往往導致架構「slop」的由上而下生成方式，不如專注於組件級的範圍，並強調品質控制 (回歸測試、基準測試與效能測試)，這往往能產生更優異的結果。這種方法將 AI 視為實作細節的高階工具，而人類則保留對微架構決策的控制權。

「慢速」AI 編碼的權衡

採用品質優先的方法涉及幾項自覺的權衡：

• 局部效率低下 vs. 全局效益： 就像傳統的程式碼審查一樣，這個過程對個別開發者而言在局部是較慢的，但對團隊與專案而言在全局是受益的。它能防止那種「代理人編碼」的幻覺——功能交付得很快，但對邊際案例的信心度極低。
• Token 成本 vs. 技術債： 你可能會消耗更多 tokens 並花費更多時間進行迭代，但結果是將「版本 3」的實作交付為「版本 1」。
• 認知負荷： 存在過度依賴 AI 的風險。一些開發者建議使用「較笨」或本地模型來強迫進行更高程度的個人驗證，並以更具描述性的方式來下達任務。

結論：工藝精神的回歸

隨著 AI 變得無處不在，軟體工程的差異化關鍵將不再是生成程式碼的能力，而是辨別品質的能力。目前存在一個「神奇的交集」：經驗豐富且能手動編碼的專業人士，能熟練地運用 AI 來放大其嚴謹性。

透過慢下來，並將 AI 視為批判、精煉與探索的工具，開發者可以超越「vibe coding」，回歸到對工藝精神的關注——為下一位開發者提供更好的東西，並確保他們交付的軟體是穩健、有意識且可維護的的。