審查程式碼的人有個沒講出口的極限：超過某個行數，眼睛就只是在「滑過」diff，不是在「看」diff。Mitchell Hashimoto 把這條極限量化了——任何一坨 agent 生出來、超過大約 1500 行的改動，都太大。它不是「要再加把勁審」的訊號，是「這題從一開始就該拆」的訊號。

這個數字的用處，是把一個模糊的直覺變成一道明確的閘門。沒有閘門時，過大的 diff 只能靠意志力硬審；有了閘門，「超過 1500 行」就直接觸發一套固定動作——停下來，把問題拆掉——而不是硬著頭皮放行。

先讓它亂畫一隻貓頭鷹

有個老梗圖：教畫貓頭鷹的教學只有兩步，第一步畫兩個圓圈，第二步「把貓頭鷹其餘部分畫完」。中間那一大跳，就是所有痛苦的來源。

功能開發的第一步，是一個叫「畫貓頭鷹」的 prompt：鬆鬆地給個方向，叫 agent 把整個功能一口氣實作出來。指令裡就把醜話講在前面——預期會拿到垃圾，而且真的就會拿到垃圾。這一步不是要成品，是要一具骨架：一個能讓人看清「這題到底長什麼形狀、會卡在哪、哪裡接不起來」的草稿，好知道接下來該怎麼拆。

Mogu 插嘴：

「預期會拿到垃圾」這六個字才是整套心法的地基。多數人對 agent 失望，是因為偷偷期待第一槍就中靶——結果端回三千行漂亮又危險的東西，審到一半就開始放水。把第一槍當探照燈、不當交付物：便宜地錯一次，遠比埋頭空想半天划算。心態對了，垃圾就變情報 (⁠•⁠̀⁠ω⁠•⁠́⁠)

1500 行：該拆的閘門

草稿回來，量一下行數。低於 1500 行，就照平常那樣審、那樣來回修，沒事。高於 1500 行，就停手——不要硬審，改成下一道指令：叫 agent 把這題拆成一個個原子的、可增量交付的、審得動的小任務。而且同一時間，人自己也拆一遍。

兩邊各拆一份，不是浪費。agent 拆出來的清單，幾乎一定太貼著它剛剛湊出來的那個解法的形狀——它把「自己這次怎麼解的」誤當成「這題本來該怎麼分」。人手上那份，是用來把它的清單揉回正確的通用形狀。哪一塊其實是兩件事、哪兩塊根本是同一件、哪個介面被它畫歪了——這些都得人去喬。

並行重跑，再畫一次貓頭鷹

形狀喬好之後，把這些增量小任務丟給新的 agent 去做，能並行就盡量並行。每一個小任務，套用一模一樣的規矩：先畫貓頭鷹、量 diff、超標就再拆。到某個點，對著縮小過的子題再下一次「畫貓頭鷹」，改動就會掉到審得動的門檻以下。

最前沿的模型開到 xhigh 等級的思考時，單個 agent 慢到一種程度，反而剛好——慢到可以同時養好幾個。一邊有 agent 在跑，一邊審別人的產出、一邊自己動手寫，三條線交錯著走。比起「agent 開 agent、無限迴圈自走」那一派，這套對他來說才是目前回報最高的日常「把事做完」打法（那一派他也玩，但那是另一篇的事）。這套一直有 agent 在跑的底氣，正是建立在改動夠小、人盯得住的前提上。

人還是得待在迴圈裡

功能開發特別不能把人踢出去，理由很具體：功能會碰到人的邊界——介面長相、API 的形狀、別人要怎麼接。這些地方沒有「客觀正確」，只有「人覺得對不對」，agent 自己對著規格猜不出來。

更危險的是，全新的東西會在架構裡埋下違反既有約束的病灶。理想上這些約束都該寫進規格或測試，讓機器自己擋下來——但沒有人的規格是完美的，總有幾條隱形規矩只活在維護者的腦袋裡。這就是為什麼把人留在迴圈裡對功能開發依然關鍵：1500 行的閘門負責把改動切到審得動，而審的那雙眼睛，得是知道「這個專案不能變成什麼樣」的那個人。

這條 1500 行的線，剛好補上兩篇舊文之間的縫。CP-146 點過名：把沒人審過的大坨 AI 程式碼直接甩給審查者，是 agent 時代最要不得的壞習慣；這篇談的正是上游解法——在甩出去之前，就先把工作切到審得動。Google 的程式碼審查準則說審查要先顧程式健康、先看設計再摳細節；1500 行這套補的，是那份準則還沒涵蓋的 agent 時代缺口：當 diff 大到根本審不動，第一步是先把它切小。

Mogu 內心戲：

注意這套的分工：閘門是死的、可量化的（1500 行），負責把問題切小；判斷是活的、靠人扛的，負責決定切對沒。很多人想把後者也外包給 agent，結果就是一坨過了所有測試、卻把架構悄悄帶歪的程式碼。機器擋行數，人擋走味 (⁠¬⁠‿⁠¬⁠)

結語

這套流程跑下來，落地的是一塊塊小到審得動、好維護的程式碼，交接點也乾淨——要嘛直接合併，要嘛人接手再磨一手。

Mogu 想補充：

整套沒有一個環節在拼更聰明的模型，拼的是紀律：承認自己審 1500 行以上會放水、承認第一槍一定是垃圾、承認 agent 摸不透這專案的隱形規矩。三件事認了，剩下的就是按表操課。土法，但煉得出鋼 (⁠＾⁠▽⁠＾⁠)