慢工出細活的耐心，是AI時代的新奢侈品
整理版優先睇
AI編程進入第二階段：與其快寫代碼，不如慢審代碼。真正嘅高手會故意用AI拖慢自己，確保質量。
呢篇文章係一位技術觀察者，睇完Mozilla老兵Nolan Lawson同Addy Osmani嘅觀點，加上自己管理Raphael AI嘅經驗，提出AI編程嘅玩法已經分代。第一階段係叫AI寫代碼，求快；第二階段係叫AI審查AI寫嘅代碼，求穩。整體結論係：軟件工程嘅瓶頸正從生產端搬到驗收端，未來最值錢嘅能力係組織AI互相審查，人類做最終裁判。
Lawson嘅做法好有意思：同一個PR，用Claude子代理、Codex、Cursor Bugbot三個AI獨立審查，按嚴重程度分級出問題清單，再交叉驗證篩走幻覺，最後合成報告。佢話幾乎零誤報，揾到嘅bug多到處理唔曬。Addy Osmani都講類似：不要讓模型一次過吐一個大而全嘅嘢；要先寫spec、拆成細塊、逐步實現、持續測試、永遠review。
作者自己嘅體會係，合夥人用兩個月慢慢打磨Raphael AI，重新梳理體驗、重做關鍵路徑、反覆改，上線後人均訪問頁面數從4.25升到9.13，提升115%。佢覺得真正有用嘅AI編程，唔係每日塞一堆半成品功能，而係令每次改動更確定、更乾淨、更少返工。慢工出細活，係AI時代嘅新奢侈品。
- AI編程進入第二階段：從「讓AI寫代碼」變成「讓AI審AI寫嘅代碼」，重點係審查而非生成。
- Nolan Lawson嘅方法：用三個AI代理獨立審查同一PR，按嚴重程度分級，交叉驗證過濾幻覺，幾乎零誤報。
- 新一代十倍工程師嘅能力：唔係寫得幾快，而係識得組織review，人類做最終裁判。
- 慢工出細活：前期規劃、拆分、審查、測試可以避免後續返工同技術債，真正嘅生產力係減少返工。
- 實際案例：合夥人用兩個月慢慢打磨Raphael AI，人均訪問頁面數提升115%，證明慢審查嘅價值。
AI編程嘅兩個階段
過去兩年，AI編程拼嘅係快。需求丟入去，代碼吐出來。一個人一日寫五百行嘅時代過咗，而家一個下午五千行起步。但係今年開始，有另一種玩法出現：故意用AI將自己拖慢。
AI編程嘅第二階段：讓AI審查AI寫嘅代碼
Mozilla老兵Nolan Lawson發咗篇文章《Using AI to write better code more slowly》，喺Hacker News衝到過千分。佢精準點出第一階段係讓AI寫代碼，第二階段係讓AI審AI寫嘅代碼。
點樣組織AI互相審查
Lawson嘅做法好值得參考：同一個PR，用Claude子代理、Codex、Cursor Bugbot三家分別獨立審查，按critical、high、medium、low分級出問題清單，再交叉驗證將幻覺篩走，最後合成一份報告。
幾乎零誤報
佢話揾到嘅bug多到處理唔曬。重點唔係AI更會寫代碼，而係AI更會挑刺。
Addy Osmani都畀出類似結論：不要讓模型一次過吐出一個大而全嘅嘢；先寫spec，拆成細塊，逐步實現，持續測試，永遠review。
慢工出細活嘅真實案例
作者將Raphael AI全權交畀合夥人之後，佢用咗兩個月做一個大版本。成個節奏唔算快，甚至可以話有啲慢——重新梳理體驗、重做關鍵路徑、反覆改、盯住數據睇完又睇。
人均訪問頁面數從4.25升到9.13，提升115%
上線之後效果立竿見影。作者體會到：真正有用嘅AI編程，唔係每日塞一堆半成品功能，而係令每次改動更確定、更乾淨、更少返工。
- 前期規劃同拆分，避免大亂鬥
- 逐步實現並持續測試，減少隱藏bug
- 永遠review，將技術債提前結清
未來工程師嘅核心能力
以前講「十倍工程師」，腦入面嘅畫面係一個人寫到十個人嘅代碼。呢個想象，先兩年，就已經過時。
新一代十倍工程師係最會組織review嘅人
一個AI寫，三個AI審，人類做最終裁判。如果你只係讓AI一口氣寫幾千行，自己都讀唔明，嗰啲唔係生產力提升，係技術債分期付款。
正向用AI係讓佢寫代碼，反向用AI係讓佢懟你寫嘅代碼
前者令你跑得快，後者保證你唔好一頭扎入坑。真正嘅高手反而會越來越慢，因為慢工出細活嘅耐心，已經成為AI時代嘅新奢侈品。
過去兩年，AI編程係鬥快。
需求掟入去，代碼就彈出嚟。一個人一日寫五百行嘅時代已經過咗，而家一個下晝五千行起跳。
舊年見到好多硅谷投資者同創業公司話，以後入會議室唔好俾原型圖我哋，直接上真Demo。好認同。
但今年我開始懷疑。AI編程更高階嘅玩法，可能反轉——係特登用AI將自己拖慢。。
前兩日見到Mozilla老兵Nolan Lawson出咗篇文章，標題就係《Using AI to write better code more slowly》。呢篇文章喺Hacker News上面衝到過千分。我睇完最大嘅感受係，AI編程嘅玩法已經分咗代。上一代係俾AI寫代碼，呢一代係俾AI審AI寫嘅代碼。
佢精準咁點出咗AI編程嘅第二階段。
第一階段叫：俾AI寫代碼。
第二階段叫：俾AI審AI寫嘅代碼。
Lawson嘅做法幾得意：同一個PR，俾Claude子代理、Codex、Cursor Bugbot三家各自獨立審，按critical/high/medium/low分級出問題清單，再交叉驗證將幻覺篩走，最後合成一份報告。佢話幾乎零誤報，揾出嚟嘅bug多到處理唔曬。
注意，呢度嘅重點唔係AI更識寫代碼。
重點係：AI更識捉錯處喇。
呢件事比表面睇仲麻煩。以前工程師最值錢嘅能力係寫代碼，邊個識寫邊個值錢。而家寫代碼越來越似扭水龍頭。
真正稀缺嘅係另一種能力：你睇唔睇得出呢段代碼幾時會炸。
邊個邊界條件冇覆蓋？邊個SQL冇建index？邊個異步順序有隱患？邊個註釋好似合理，但其實係誤導下一個維護者？
呢個先係展現真正實力嘅時候。
Addy Osmani最近講佢自己嘅LLM coding workflow，都畀出類似結論：唔好俾模型一次過吐出一個大而全嘅嘢；先寫spec，拆成細塊，逐步實現，持續測試，永遠review。
AI越強，流程反而越要保守。
強模型最危險嘅地方係，將垃圾寫到似真嘅。
呢個就係一個認知反轉：
所以AI唔係慳咗review，而係將review變成主戰場。
我哋以前講「十倍工程師」，腦入面嗰個畫面係一個人能夠寫十個人嘅代碼。
呢個想像，先兩年，就已經過時喇。
新一代十倍工程師，可能係最識組織review嘅人。一個AI寫，三個AI審，人類做最終裁判。
反轉，如果你只係俾AI一氣寫幾千行，自己都睇唔太明，嗰個唔係生產力提升，而係技術債分期付款。今日慳咗嘅兩個鐘，上線後變成二十個鐘覆盤。
軟件工程嘅瓶頸正在由生產端，移到驗收端。
粗糙賽道仍然係鬥速度。小工具、營銷頁、跑一次就丟嘅腳本，快就係優勢。但係但凡精品賽道——支付、風控、醫療、企業系統、基礎設施——代碼寫完先係開始，後面要俾現實拷打好多年。
呢件事我最近自己啱啱遇到咗。
我將Raphael AI完全交俾合夥人之後，佢用咗兩個月做一個大版本。成個節奏唔算快，甚至可以話有啲慢，有時睇佢操作電腦，感覺好似睇緊「閃電」一樣——重新梳理體驗，重做關鍵路徑，反覆改，睇住數據睇完又睇，過咗十分鐘返嚟，屏幕上面仲係同一頁。
但係上線之後，效果係立竿見影嘅：人均訪問頁面數由4.25做到9.13，差不多翻倍，提升115%。
有興趣嘅話，你可以打開Raphael AI睇嚇新版嘅變化 https://raphael.app
我嘅體會係：真正有用嘅AI編程，唔係每日塞一堆半成品功能，而係令每次改動更確定、更乾淨、更少返工。
我想，未來面試工程師，最應該問嘅可能得一道題：詳細講嚇，你係點樣組織AI互相打架嘅？
呢個係我認為接下來更值錢嘅能力——反向用AI。
正向用AI係俾佢寫代碼；反向係俾佢嚟懟你寫嘅代碼。
前者令你跑得快，後者保證你唔好一頭插落坑度。
真正嘅高手反而會越來越慢。慢喺前期嘅規劃、拆分、審查、測試上面。
呢種慢，係將後面嘅返工、事故、技術債提早結清。
我成日講一句話：慢就係快。
最快嘅進步係唔退步，最高嘅效率係唔返工。
舊年，AI編程嘅口號係：更快出demo。
下一階段嘅口號應該換成：更慢咁更好。
慢工出細貨嘅耐心，係AI時代嘅新奢侈品。
過去兩年，AI編程拼的是快。
需求丟進去，代碼吐出來。一個人一天寫五百行的時代過去了，現在一個下午五千行起步
去年看到很多硅谷投資人和創業公司說，以後進會議室不要給我原型圖了，直接上真Demo。深以為然。
但今年我開始懷疑。AI 編程更高階的玩法，可能反過來——是故意用AI把自己拖慢。
前兩天看到Mozilla老兵Nolan Lawson 發了一篇文章，題目就叫《Using AI to write better code more slowly》。這篇文章在 Hacker News 上衝到過千分。我看完最大的感受是，AI 編程的玩法已經分代了。上一代是讓 AI 寫代碼，這一代是讓 AI 審 AI 寫的代碼。
它精準點出了AI 編程的第二階段。
第一階段叫：讓 AI 寫代碼。
第二階段叫：讓 AI審AI 寫的代碼。
Lawson 的做法挺有意思：同一個 PR，讓 Claude 子代理、Codex、Cursor Bugbot 三家分別獨立審，按 critical / high / medium / low 分級出問題清單，再交叉驗證把幻覺篩掉，最後合成一份報告。他說幾乎零誤報，找出來的 bug 多到處理不完。
注意，這裏的重點不是 AI 更會寫代碼。
重點是：AI 更會挑刺了。
這件事比看起來麻煩。過去工程師最貴的能力是寫代碼，誰能寫誰值錢。現在寫代碼越來越像擰水龍頭。
真正稀缺的是另一種能力：你能不能看出這段代碼什麼時候會炸。
哪個邊界條件沒覆蓋？哪個 SQL 沒建索引？哪個異步順序有隱患？哪個註釋看似合理，其實在誤導下一個維護者？
這才是展現真正實力的時候。
Addy Osmani 最近講自己的 LLM coding workflow，也給出類似結論：不要讓模型一次性吐出一個大而全的東西；先寫 spec，拆成小塊，逐步實現，持續測試，永遠 review。
AI 越強，流程反而越要保守。
強模型最危險的地方是，把垃圾寫得逼真。
這就是一個認知反轉：
所以AI不是省掉 review，是把 review 變成主戰場。
我們以前講"十倍工程師"，腦子裏那個畫面是一個人能寫十個人的代碼。
這個想象，才兩年，就已經過時了。
新一代十倍工程師，可能是最會組織 review 的人。一個 AI 寫，三個 AI 審，人類做最終裁判。
反過來，如果你只是讓 AI 一氣寫幾千行，自己也讀不太懂，那不是生產力提升，是技術債分期付款。今天省的兩小時，上線後變成二十小時覆盤。
軟件工程的瓶頸正在從生產端，挪到驗收端。
粗糙賽道還是拼速度。小工具、營銷頁、跑一次就丟的腳本，快就是優勢。但凡是精品賽道——支付、風控、醫療、企業系統、基礎設施——代碼寫完才是開始，後面要被現實拷打很多年。
這事我最近自己正好遇到了。
我把 Raphael AI 全交給合夥人以後，她用了兩個月做一個大版本。整個節奏不算快，甚至可以說有點慢，有時候看她操作電腦，感覺在看“閃電”一樣 —— 重新梳理體驗，重做關鍵路徑，反覆改，盯着數據看了又看，過了十分鐘回來，屏幕上還是同一頁。
但上線之後，效果是立竿見影的：人均訪問頁面數從 4.25 幹到了 9.13，差不多翻倍，提升 115%。
感興趣的話，你可以打開Raphael AI看看新版的變化 https://raphael.app
我的體會是：真正有用的 AI 編程，不是每天塞一堆半成品功能，而是讓每次改動更確定、更乾淨、更少返工。
我想，未來面試工程師，最該問的可能只有一道題：展開講講，你是如何組織AI互相打架的？
這是我認為接下來更值錢的能力——反向用 AI。
正向用 AI 是讓它寫代碼；反向是讓它來懟你寫的代碼。
前者讓你跑得快，後者保證你別一頭扎進溝裏。
真正的高手反而會越來越慢。慢在前期的規劃、拆分、審查、測試上。
這種慢，是把後面的返工、事故、技術債提前結清。
我常常說一句話：慢就是快。
最快的進步是不退步，最高的效率是不返工。
過去一年，AI 編程的口號是：更快出demo。
下一階段的口號應該換成：更慢地更好。
慢工出細活的耐心，是AI時代的新奢侈品。