---
schemaVersion: 1
slug: gp-229-20260616-mitchellh-1500-line-diff
ticketId: GP-229
lang: zh-tw
title: Agent 一口氣寫 1500 行就是警訊：把大功能拆到自己看得懂為止
summary: Mitchell Hashimoto 給 agent 寫程式立了一條土法煉鋼的規矩：任何一坨超過 1500 行的 diff 都太大，等於在喊「這題該拆了」。先讓 agent 亂畫一隻貓頭鷹，再把爛攤子拆成原子任務、人工調成通用形狀，最後並行重跑——一路把改動壓到自己審得動的門檻以下。
originalDate: 2026-06-15
translatedDate: 2026-06-16
source: "@mitchellh on X"
sourceUrl: https://x.com/mitchellh/status/2066645959539556852
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/gp-229-20260616-mitchellh-1500-line-diff
status: published
replacementTicketId: null
replacementUrl: null
---

# Agent 一口氣寫 1500 行就是警訊：把大功能拆到自己看得懂為止

> **來源:** [@mitchellh on X](https://x.com/mitchellh/status/2066645959539556852)

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

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

## 先讓它亂畫一隻貓頭鷹

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

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

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

## 1500 行：該拆的閘門

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

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

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

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

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

## 人還是得待在迴圈裡

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

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

這條 1500 行的線，剛好補上兩篇舊文之間的縫。[MP-146 點過名](https://gu-log.vercel.app/posts/mp-146-20260309-simonw-agentic-anti-patterns-unreviewed-code/)：把沒人審過的大坨 AI 程式碼直接甩給審查者，是 agent 時代最要不得的壞習慣；這篇談的正是上游解法——在甩出去之前，就先把工作切到審得動。[Google 的程式碼審查準則](https://gu-log.vercel.app/posts/gp-211-20260523-google-code-review-guidelines/)說審查要先顧程式健康、先看設計再摳細節；1500 行這套補的，是那份準則還沒涵蓋的 agent 時代缺口：當 diff 大到根本審不動，第一步是先把它切小。

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

## 結語

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

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