別人在用AI批量"生產(chǎn)"代碼，為什么我勸你用AI寫得更慢？
2026年5月，一個程序員的博客在Hacker News上炸了。
帖子標(biāo)題毫不吸引眼球：《用AI寫更好的代碼，但速度更慢》（Using AI to write better code more slowly）。
沒有震驚體，沒有"AI將取代你"的焦慮鉤子。
就是這樣一篇"反直覺"的文章，拿下了HN當(dāng)周最高分。
作者Nolan Lawson的核心觀點只有一句：
"AI寫代碼，不應(yīng)該是往GitHub上狂扔PR的slop cannon。用對了，AI反而讓你慢下來——但代碼質(zhì)量高到離譜。"
這話聽起來很反常識。
慢，怎么反而是快？
01 別人在卷速度，他在"故意"慢下來
先說個背景。
Nolan Lawson不是普通開發(fā)者，他是前微軟工程師，做過瀏覽器內(nèi)核開發(fā)，寫過知名的開源項目。他描述了一個真實的場景：
現(xiàn)在的主流觀點是：AI來了，代碼要寫得越快越好。復(fù)制粘貼，批量生成，快速合并，slop cannon——字面意思就是"霰彈槍式"輸出。
但他的方法論完全不同：
用多個AI agent（Claude、Codex、Cursor Bugbot）同時審查同一個PR，然后由他來綜合判斷。
流程是這樣的：
- 提交一個PR
- 三個AI agent同時掃描，各自找bug
- 人工合并三份報告，去除誤報
- 只處理真正重要的bug
結(jié)果是：他幾乎不再漏掉bug，代碼質(zhì)量穩(wěn)定提升。
代價是：review時間變長了。
但他算了一筆賬：開發(fā)時間沒變慢，因為bug少了，后期維護(hù)成本大幅下降。
02 一個反直覺公式：慢 = 質(zhì)量 = 快
很多人對"高效"的理解是：單位時間內(nèi)產(chǎn)出更多代碼。
這是工業(yè)時代的思維。代碼行數(shù) ≠ 價值。
真實工程中的"快"，是：
- 上線后不爆bug
- 三個月后自己還能看懂
- 新人接手不需要"考古"
一個經(jīng)典的軟件工程數(shù)據(jù)：
修復(fù)生產(chǎn)環(huán)境的bug，平均成本是開發(fā)階段修復(fù)的 6-15倍。
越往后發(fā)現(xiàn)問題，成本指數(shù)級上升。
所以，"用AI慢下來寫代碼"這件事，本質(zhì)上是一個投資回報前置的策略：
- 開發(fā)階段多花1小時用AI審查
- 省掉的可能是一次P0事故、一次凌晨2點的on-call、一整天的hotfix
這不是慢。這是聰明地快。
03 三個立刻能用的AI代碼審查技巧
好，說了這么多理論，怎么落地？
以下是Nolan Lawson實踐驗證過的三個技巧，任何開發(fā)者今天就能用：
技巧一：多模型交叉審查
不要只用單個AI寫代碼。至少用兩個不同的模型做代碼審查。
原因是：不同模型的幻覺率和誤報模式不同。Claude擅長找安全漏洞，Codex可能更擅長找邏輯問題，Cursor Bugbot擅長找邊緣case。
操作方法：
提交PR → 讓Claude掃描 → 讓Codex掃描 → 合并報告 → 人工去重 → 只處理高置信度問題
不要試圖修復(fù)AI找到的所有問題。設(shè)定優(yōu)先級：Critical/High優(yōu)先，Medium按ROI酌情處理，Low直接忽略。
技巧二：讓AI專門找"不對勁"的地方
在給AI的指令里，明確告訴它你的"bug定義"。
比如：
- 不符合KISS原則（Keep It Simple, Stupid）的代碼
- 不符合DRY原則的重復(fù)邏輯
- 可能有SQL注入風(fēng)險的用戶輸入
- Accessibility不達(dá)標(biāo)的HTML/JSX
- 缺少索引的SQL查詢
不是讓AI幫你寫代碼，是讓AI幫你做質(zhì)檢。
技巧三：AI發(fā)現(xiàn)bug太多？這時要停下來
這是最反直覺的一條。
如果一次PR review，AI找出了20個bug——不要全部修。
停下來，重新審視這個PR的設(shè)計本身。
"bug太多"往往是信號，說明這個方向的架構(gòu)可能有問題。這種情況下，與其修修補補，不如重新設(shè)計。
代碼健康度的本質(zhì)，不是"沒有bug"，而是架構(gòu)合理、易于維護(hù)。
04 編程書正在消失這件事，說明了什么？
文章開頭提到的那個故事，還有一個背景：
2025年，美國"專業(yè)書籍"品類銷售額下跌22.3%。出版商干脆不再單獨報告"電腦圖書"這個子類目——因為數(shù)據(jù)太難看。
技術(shù)書籍的消失，不是因為沒人學(xué)習(xí)了。是因為學(xué)習(xí)方式變了。
以前：買書→照著敲→理解原理→舉一反三
現(xiàn)在：直接問AI→拿到答案→快速驗證→邊用邊學(xué)
這個變化，對程序員來說，是巨大的范式轉(zhuǎn)換。
但問題來了：純靠AI給答案，你獲得的是"術(shù)"，失去的是"道"。
知道怎么調(diào)用API，不等于理解底層原理。
當(dāng)AI給了一個錯誤的答案，你能識別出來嗎？
這個時代最稀缺的能力，不是調(diào)用AI的技巧，而是判斷AI輸出質(zhì)量的能力。
而這種能力，恰恰需要慢下來——理解原理，看清全局，才能不被AI帶著走。
05 給所有程序員的一句話
AI不會取代你。
但會用AI的程序員，會取代不會用AI的程序員。
而更關(guān)鍵的是：
會用AI慢下來寫代碼的程序員，會取代那些只會用AI加速"生產(chǎn)"的人。
代碼不是打字比賽。質(zhì)量永遠(yuǎn)比速度重要。
慢下來，用AI做更好的質(zhì)檢，而不是更多的輸出。
這才是AI時代，程序員的正確打開方式。
06 一個行動清單（今天就能用）
- ? 在你的下一個項目里，試著用兩個AI模型同時review代碼
- ? 給AI一份你的"bug定義"（可以是編碼規(guī)范文檔），讓它按圖索驥
- ? 如果一個PR被AI標(biāo)了超過10個bug，先別急著修——重新想一下設(shè)計
- ? 每周抽30分鐘，不靠AI，純讀自己寫的代碼——鍛煉"代碼感"
你用過AI做代碼審查嗎？效果如何？歡迎留言分享。
參考資料
- Nolan Lawson: "Using AI to write better code more slowly" (Read the Tea Leaves, 2026-05-25)
- Cyrus: "Nobody Cracks Open a Programming Book Anormore" (unix.foo, 2026-05-25)
- Circana BookScan / Publishers Weekly: U.S. Book Sales Data 2023-2025
- American Association of Publishers: Professional Books Segment Report, 2025
