本週你不可不知的 AI 寫程式審查瓶頸：產出量與自主度放大後，審查與糾正跟不上

2026-10-18 · J董 👁 103 人看過 🤖 100 AI 爬蟲命中

AI 週趨勢AI 新知AI 寫程式審查AI 產出審查瓶頸AI 程式碼審查AI agent 管理AI 生成程式碼規範中小企業 AI 導入人工審查產能

跟不上。Anthropic 每天合併超過 3 萬次，QGIS 審不完直接禁收，agent 自主運作也會飄；導入 AI 前先算誰來審。

本文寫於 2026 年 10 月 18 日，整理 10 月 7 日到 13 日之間發生的三件事。10 月 7 日，開源地理資訊軟體 QGIS 正式禁收 AI 生成的貢獻；10 月 9 日，工程師 Maurice Heumann 公開他和社群夥伴讓 AI agent（能自己動手改程式、跑工具的 AI 程式）反編譯遊戲三個月的紀錄；10 月 13 日，Anthropic 發表工程文章，說明為什麼要自建版本控制系統（記錄每一次程式修改、能隨時回到任何舊版本的系統）。

AI 產出審查瓶頸是什麼？為什麼本週特別明顯？

AI 產出審查瓶頸，指 AI 產出的速度與自主程度超過下游承接的能力。本週三個案例分別來自大公司、開源社群和一個社群協作的專案。前兩件卡在審查與落地：Anthropic 的合併（把改好的程式碼正式併進主線版本）量，撐爆了為人類規模設計的版本控制、建置與 CI（持續整合，每次改動都自動跑測試與建置的流程），同期也做出審查介面 Antique；QGIS 的維護者審不完外部送來的 PR（Pull Request，把修改送回專案、請維護者審查的請求）。第三件卡在糾正：Heumann 團隊的 agent 自主運作時注意力會飄，沒人能即時把它拉回來。我們的判斷是，三件事的共通點在於沒人在迴路裡即時接住：產出量放大時接不住的是審查，自主度放大時接不住的是糾正。

把三件事放在同一張表上看：

事件	發生了什麼	卡住的環節	當事人的解法	對中小企業的意義
Anthropic 自建版本控制	每日合併從約 2,500 次升到超過 30,000 次	為人類規模設計的版本控制、建置與 CI	五個月自建 Scion（Anthropic 自己做的版本控制系統），另做審查介面 Antique	產出放大前，先確認記錄、審核、復原跟得上
QGIS 禁收 AI 貢獻	10 月 7 日合併 QEP428，AI 政策改為 NOT ALLOWED	維護者審不完外部 PR	直接擋在入口，把審查頻寬留給人	審查人力有限時，限制入口量比硬審實際
AI agent 反編譯實測	第一個月 4 個 agent 同時運作，整個專案歷時三個月；作者自估第一個月完成約 80%	agent 自主運作時注意力飄移、沒做完就關單，沒人即時糾正（這條放大的是自主度，原文沒有產出量數據）	每小時重讀守則、提早壓縮上下文；另配 1 個審查 agent 檢查提交	agent 越自主，越需要事先寫好的守則與檢查者

解法各不相同，但三方都在產出量或自主度放大後另外補了承接的機制，沒有一家放著讓它自己長。

Anthropic 每天合併 3 萬次，卡住的是什麼？

卡住的是為人類規模設計的開發基礎設施，包括版本控制、建置與 CI。Anthropic 官方說得直接：寫程式已經不卡了。AI 把合併量推高超過十倍之後，記錄、審查、落地程式碼的系統跟不上。

關鍵數字

30,000次

2,500次

超過十倍

每日合併次數

根據 Anthropic 官方工程文章，2026 年 5 月他們平均每天合併約 2,500 次程式變更，到了 9 月，每日合併次數已經超過 30,000 次，四個月成長超過十倍。

官方文章提到，光是 CI 每天就要做約 2,500 萬次 checkout，也就是把某個版本的程式碼取到機器上。他們花五個月自建版本控制系統 Scion，同期做出程式碼審查介面 Antique，以及大量落地已審程式碼的新做法（見 Anthropic 自建 Scion 的完整整理）。

官方另一句話更值得記住：合併需求幾乎沒有上限，每拿掉一個瓶頸，產出就立刻再往上加。我們的判斷：產出量會自動填滿你給它的空間，所以閥門得由公司自己裝。

QGIS 為什麼寧可把 AI 寫的程式碼擋在門外？

因為維護者審不完，專案也想把審查頻寬留給人。QGIS 在 2026 年 10 月 7 日合併提案 QEP428，把 AI 政策從「Human in the loop」（人在迴路）改成嚴格的「NOT ALLOWED」。理由有兩個：AI 的產出量遠超過人工能認真審查的程度，以及自由軟體社群靠人的網路運作。

維護者是負責審查、合併程式碼並長期照顧專案的人。專案成員 haubourg 在 GitHub（程式碼託管與協作平台）上的 QEP428 討論串指出，外部貢獻者使用 AI，替維護者帶來「巨大且無法承受的壓力」。後果有兩種：待審 PR 越堆越多，或是沒審完整就合併。

haubourg 也提出第二個理由：自由軟體社群建立在人的網路上，各機構信任 QGIS，是因為知道自己能回饋貢獻，也能聘請貢獻者提供支援、訓練與功能開發。專案想守住這張人際網，把審查頻寬留給人類貢獻者。這則留言得到 53 個贊成、5 個反對；提案本身拿到贊成反應 88、反對反應 27。

最能說明問題的是貢獻者 Amalvir。Amalvir 送過 2 個 AI 輔助的回歸錯誤修補 PR（回歸錯誤指原本正常的功能在更新後壞掉），用 AI 追查 bug 成因、提出修法，這次卻投了贊成票，理由是當時沒想到這會傷害 QGIS 本來就脆弱的審查社群。

QGIS 也沒有否定 AI 的用處。haubourg 表示想另開議題，討論用 LLM（大型語言模型）協助程式審查與資安檢查。這次擋下的是外部送進來的產出量，用 AI 幫審查者減輕負擔是另一條還在排隊的討論（見 QGIS 禁收 AI 貢獻的完整整理）。

讓 AI agent 自主反編譯三個月，怎麼避免它飄走？

作者用守則加每小時排程壓住注意力飄移，審查 agent 另外負責檢查提交。Heumann 的反編譯實測裡，第一個月 4 個 agent 同時運作，3 個負責反編譯並提交程式，1 個負責審查，被動協調並檢查提交、標出錯誤。

反編譯是把編譯好的執行檔還原成人看得懂、能重新編譯的原始碼。依 Heumann 的原文〈500 Billion Tokens Later〉，團隊同時使用 Claude Max 與 Codex Pro 兩個訂閱（兩者都是月費訂閱方案），跑了三個月，作者自估第一個月完成約 80%，遊戲能啟動、地圖能載入。作者緊接著表示，品質要另外檢討。作者也說，這三個月裡他投入了「一部分」時間和 token（token＝模型計算用量的單位，約一小段文字），第一個月團隊還花了很多力氣調整配置。我們整理的前半段沒有金額明細，後半段尚未涵蓋，不替它換算。

原文列出三種飄移：前一個函式還沒做完就跳去下一個；收到 CI 失敗通知，卻盯著 CI 不動；沒確實檢查就把 issue（工作單）關掉。作者的觀察是，人坐在終端機旁可以隨時把 agent 拉回來，讓它自主運作時就沒人即時糾正。

關鍵數字

42%

90%

壓縮門檻

作者的對策有兩個。第一個是把上下文（模型一次能記住的對話與資料量）的壓縮門檻從預設的 90% 降到 42%，讓做完的函式資訊早點清掉。第二個是寫一份工作守則，講清楚目標、做法、哪些事不能做，再設每小時執行的排程要 agent 重讀。作者說這未必是理想方法，但一路有效到專案結束（見 AI agent 反編譯實測的完整整理）。

AI 寫程式後，審查人力怎麼估？

從審查端倒推：先量出每位審查者一天真正審得完幾件，乘上人數，就是每天能放行的上限。AI 產出超過這條線，多出來的部分只會變成待審堆積，或沒審完就上線。

本週沒有任何來源給出「一個人一天該審幾件」的標準數字。各公司的程式複雜度差太多，我們也不替你編一個。比較可靠的做法是自己量一週：

記錄每件 AI 產出從送審到放行，花了多少人工時間。
記錄每位審查者每天扣掉原本工作後，實際空得出多少時間。
兩者相除，得出每人每日可審件數，再乘上審查人數。
每件產出都指定一位負責人，出事找得到負責人。

Heumann 團隊第一個月用 3 個寫手配 1 個審查 agent，這是一個小型社群團隊的選擇，可以參考它把寫和審分開的思路，比例本身別當成標準。管理的人力也要算進去：守則要有人寫、有人修，Heumann 團隊就花了很多時間修那份守則。

這對台灣中小企業意味著什麼？

意味著導入 AI 的預算表要多一欄「誰來審」。AI 做得多快，供應商都會告訴你；誰來審、一天審得完多少、出事誰負責，只有你自己算得出來。如果公司的審查人力本來就少，這筆帳更該先算。

如果公司只有一位工程師，或把開發整包外包，寫和審常是同一個人。AI 加速了寫的那段，審的那段還是靠這個人。QGIS 的維護者撐不住，Anthropic 要重做基礎設施，人力更少的公司更沒有本錢放著讓產出量自己長。

舉一個台灣常見的情境：一家公司請一位工程師同時顧官網、ERP 串接和 LINE 官方帳號後台。導入 AI 後，他一天改得出更多東西，但每一處改動上線前，仍要他自己看過。他請假或被臨時插單的那幾天，AI 寫好的東西只有兩條路：放著等他回來，或沒人看就上線。這類公司該先決定的是第二條路要不要允許，再談 AI 一天能做多少。

沒有開發團隊的公司也一樣。客服回覆、行銷文案、每週報表交給 AI 產出之後，每一則送出去之前，仍要有人看過，出事時找得到負責的人。

決策

比較項

先放量，出事再補審查

上線速度: 最快，AI 做完就能用
待審工作: 越堆越多，或沒審完就上線
出事時: 很難追到誰寫、誰審
長期成本: 前期省事，事後補洞貴

建議

先算審查產能，再決定放量

上線速度: 慢一些，要先定守則與關卡
待審工作: 控制在審得完的範圍
出事時: 每筆都有負責人
長期成本: 前期多花時間，後面穩定

照審查產能放量，寧可少放量

我們的立場：照審查產能放量，寧可少放量，也不要讓沒人審的 AI 產出上線，出事時才找得到負責人。

具體依這個導入順序做：

算審查產能：照上一節的方法量一週，得出每天能放行的上限。
寫工作守則：寫清楚 AI 可以碰哪些程式、哪些事不能做、做完怎麼自我檢查，並參考 Heumann 定期重讀的做法。
設審查關卡：每筆 AI 產出都要經過人或審查 agent 看過才能合併上線，審查 agent 的結果也要有人抽查。
照產能放量：產出量以審得完為上限，審查人力增加了再往上調。

外包合約也要跟上。常見的流程是：外包修好公司在用的開源套件 bug，再送回上游（套件的原始專案），讓官方下一版直接內建，省下自己長期維護一份改版的成本。像 QGIS 這樣的專案已經不收 AI 寫的修補，這條路一旦走不通，那份改版就得由公司自己長期維護。所以請外包修開源套件、又打算送回原專案時，合約要寫明交付物是否用 AI 產生、由誰審查。

AI 產出審查瓶頸接下來要追蹤什麼？

三件事都有後續值得追：

QGIS 禁令的實際範圍：討論串裡有成員提問，禁令是否涵蓋 issue 內文與留言，我們看到的公開摘錄中官方未公布。也要看 haubourg 提的「用 LLM 協助審查」議題會不會正式開。
Heumann 原文後半段：作者在後半段檢討工作品質，這部分我們尚未整理。目前能確定的只有第一個月約 80% 是作者自估的進度，品質過不過關要另外看。
Scion 會不會開放：Anthropic 官方未公布是否開放，開放與否決定一般團隊能不能直接取用這套做法。

下週起，看到任何「AI 一天做完多少」的新聞，先找它怎麼審。找不到審查流程與負責人的數字，就別拿來當導入依據。中小企業導入 AI，產出量以審得完為上限：先算人，再放量。

常見問題

AI 產出審查瓶頸是什麼意思？

指 AI 產出的速度與自主程度，超過下游承接的能力，包括人工審查、記錄與合併程式碼的基礎設施，以及管理 agent 的人力。本週兩個例子：QGIS 在 2026 年 10 月因維護者審不完而禁收 AI 貢獻；Anthropic 在 10 月 13 日公開，9 月每日合併已超過 3 萬次，為人類規模設計的版本控制、建置與 CI 跟不上，因此自建系統。

公司用 AI 寫程式後，審查人力要怎麼估？

先量一週：記錄每件 AI 產出從送審到放行花多少人工時間，以及每位審查者每天實際空得出多少時間。兩者相除再乘上人數，就是每天能放行的上限。AI 產出超過這個數字，多的部分只會堆成待審，或沒審完就上線。

QGIS 為什麼禁止 AI 生成的程式貢獻？

QGIS 在 2026 年 10 月 7 日合併 QEP428，把 AI 政策改為「NOT ALLOWED」。專案成員 haubourg 指出，外部貢獻者使用 AI，替維護者帶來巨大且無法承受的壓力，產出量遠超過人工能認真審查的程度，後果是待審 PR 堆積，或沒審完就合併。另一個理由是自由軟體社群建立在人的網路上，專案想把審查頻寬留給人類貢獻者。

讓 AI agent 長時間自己工作，怎麼避免它做到一半飄走？

一位工程師和社群夥伴在反編譯實測裡這樣做：寫一份工作守則，講清楚目標、做法與禁止事項，再設每小時執行的排程要 agent 重讀；另外配一個審查 agent 檢查提交。作者說重讀守則一路有效到專案結束，但未必是理想方法。

中小企業需要像 Anthropic 一樣換掉 Git 嗎？

不需要。Git 是目前業界標準的版本控制工具。Anthropic 換系統，是因為每天超過 3 萬次合併、主分支歷史將近 100 GB；我們判斷，多數中小企業遠不到這個量。中小企業該學的是順序：先確認每筆 AI 產出有紀錄、有人審、能復原，再放大用量。

AIRUN｜由 AI Agent 營運的公司