AI代码慢写才是正確姿勢

大部分人覺得AI編碼的目的，就是極限產出爛代碼。狂噴代碼，開大PR，不審核就直接Merge。乾就對了。

但問題是，LLM非常靈活。你完全可以用它來高品質代碼，只是慢一點。

這話听起来像廢話，但足以讓很多人清醒。因為他們堅信LLM只能是「爛代碼生成器」。

被忽視的超能力

如果 Mythos 教會我們什麼，那就是：LLM非常擅長找Bug。

把LLM扔進一個代碼庫足夠多次，它能找到的Bug會多到你不知道該處理哪個。

我自己也發現，不只是 Mythos，很多公開模型都能找到大量Bug。Anthropic和OpenAI的最新模型 Find Bug能力已經足夠強。

問題不在於找到Bug，而是在於：優先級排序和驗證。

為此，我設計了一個 Claude Skill，核心洞察是：丟給代碼審查的模型越多，得到幻覺或假陽性的概率就越低。

我的工作流是這樣的：

就這樣。用這個方法，每次都能找到海量的Bug，而且假陽性率接近零。找到的Bug從critical安全漏洞，到medium性能問題，再到「這條評論會誤導人」的low級問題，應有盡有。

我的典型流程是：

用這個方法，我的開發速度並沒有變快。如果說有什麼變化，那就是審代碼的過程經常發現既有的Bug，結果去修了一些比當前PR還早的 subtle問題。這是「10倍程式設計師」風格的對立面，但我發現這種慢節奏更有成就感。

這是一種大幅提升代碼庫健康狀態的方式，同時讓你了解各種奇怪的角落。

如果你覺得AI編碼只能產爛代碼，這篇文救不了你。但如果你是那種用Agent一次寫幾百行代碼、自己都看不懂的開發者，我邀請你慢下來，試試這種更慢的「vibe coding」。

讓Agent告訴你這個PR是怎麼運作的、它可能在哪裡失敗。必要時讓它寫Mermaid圖表來解釋。用Matt Pocock的 /grill-me skill，直到你從頭到尾理解整個PR。

你可能不會在代碼行數上更「高效」。你可能會燒掉大量tokens，最後發現你的整個思路一開始就錯了。

但我發現這種編程風格，是我之前在LLM時代之前就想嘗試的超級版本：仔細、系統性、質量导向、為下一個開發者著想。

所以，深呼吸，慢下來，試試這個技術，看看能不能享受「更慢地寫出更好代碼」的過程。