Anthropic 在 2026 年 6 月 4 日發表一篇很重的文章：When AI builds itself。
這篇不是一般產品更新，也不是單純宣傳 Claude Code。它真正丟出來的問題是：
如果 AI 已經開始大幅加速 AI 研發，那人類還剩下多少時間建立治理、安全與驗證機制？
最容易被拿來當標題的數字，是 Anthropic 說截至 2026 年 5 月，合併到 Anthropic codebase 的程式碼中，超過 80% 是由 Claude 撰寫。
這個數字很驚人，但不能粗暴解讀成「Claude 已經自己打造下一代 Claude」。更準確的說法是：
AI 還沒有完整自我改進，但它已經開始把 AI 研發流程裡大量的實作、測試、除錯、實驗迭代自動化。
這就是 recursive self-improvement 討論重新升溫的原因。
先把三件事分清楚
談這題最容易混在一起，所以先分三層。
| 層級 | 現在到了嗎？ | 意思 |
|---|---|---|
| AI 協助工程師寫程式 | 已經到了 | Claude Code、Codex、Cursor 這類 agent 寫 code、改檔、跑測試 |
| AI 加速 AI 研發流程 | 正在發生 | AI 幫 AI lab 寫基礎設施、跑實驗、分析錯誤、提升研究吞吐量 |
| 完整 recursive self-improvement | 還沒到 | AI 能自主設計、開發、訓練、驗證自己的下一代模型 |
Anthropic 這次真正重要的不是第三層已經發生，而是第二層正在變得非常明顯。
以前 AI lab 的進步主要靠人：研究員想實驗、工程師寫基礎設施、團隊跑訓練、再由人分析結果。
現在變成：人類仍設定方向，但大量「把想法變成可跑實驗」的工作，正在交給 agent。
這會改變 AI 產業的速度。
Anthropic 公開了哪些數字？
這篇文章最值得看的，是 Anthropic 把一些內部資料攤出來。
| 指標 | Anthropic 公布的說法 | 該怎麼解讀 |
|---|---|---|
| Claude 撰寫合併程式碼 | 2026 年 5 月，超過 80% 合併到 Anthropic codebase 的程式碼可歸因於 Claude | 這是「合併程式碼行數歸因」，不是完整生產力，也不是完全無人研發 |
| 工程師 code 產出 | 2026 年 Q2 的典型工程師合併 code 量約為 2024 年的 8 倍 | Anthropic 自己也提醒，lines of code 不是品質指標，8 倍很可能高估真實生產力 |
| 複雜 open-ended task | Claude 在最開放、最不明確的任務成功率，2026 年 5 月達 76% | 這表示 coding agent 不只做小修補，已經能處理較模糊的工程問題 |
| 自動 review | Anthropic 說自動 Claude reviewer 回顧過去 incident 時，約可抓出三分之一相關 bug | 代表 review 也開始被 agent 化，但不能因此取消人類審查 |
| 實驗優化 | 固定訓練程式優化測試中，Claude Opus 4 約 3 倍，Mythos Preview 約 52 倍 | 在明確目標與檢查條件下，AI 做迭代優化已經非常強 |
| AI safety 研究實驗 | Agent 在一個開放安全研究任務中，用約 800 小時計算、約 18,000 美元 compute，追回 97% 指標差距 | 這是強訊號，但 Anthropic 也說結果沒有乾淨轉移到 production-scale 模型 |
我認為最重要的不是 80% 這個單一數字，而是整組訊號指向同一件事：
AI 正在把「做事」變便宜，把「判斷什麼值得做」變成新的稀缺資源。
80% code 到底代表什麼？
「Claude 寫了 80% 以上合併程式碼」很容易被誤讀。
它不代表：
- Claude 自己決定公司產品策略。
- Claude 自己設計下一代模型。
- Claude 自己負責所有架構取捨。
- 人類工程師已經不重要。
- Anthropic 的 code quality 自動變好 8 倍。
它比較像代表：
- 工程師打字的比例正在下降。
- Agent 變成執行與探索的主力。
- 人類更多在下目標、看 diff、判斷取捨。
- code review、測試、CI、incident analysis 變得比以前更重要。
- 好的工程師會從「親手寫最多 code」變成「設計最好的問題與驗證邊界」。
這和我自己用 coding agent 的體感一致。
Claude Code、Codex 這類工具最有價值的地方，不是幫你補一段 function，而是你把任務交給它後，它能自己讀檔、改檔、跑測試、根據錯誤再修。
一旦這件事穩定，工程師的工作就會變形。
以前的瓶頸是「誰來寫」。
現在的瓶頸會變成「誰來確認這樣寫是對的」。
真正的瓶頸變成 review
Anthropic 文中有一個比 80% 更值得注意的觀察：當 AI 產生 code 的速度變快，人類 review 會變成新的瓶頸。
這點對所有工程團隊都很現實。
如果 coding agent 讓每個工程師一天能產出原本數倍的 diff，團隊不會自動變快。因為你很快會卡在：
- PR 太多，看不完。
- 測試跑太慢。
- CI 容量不夠。
- reviewer 不知道哪些變更高風險。
- agent 改太多檔，沒人完整理解。
- 文件和架構決策追不上。
- bug 不是少了，而是更快被送進 production。
所以 AI coding agent 的成熟，不是讓 review 消失，而是讓 review 變成核心能力。
未來工程團隊會需要更嚴格的分層：
| 變更類型 | 可以怎麼管理 |
|---|---|
| 低風險文字、文件、測試補充 | Agent 可先做，簡化人工 review |
| 單一模組 bug fix | 必須有測試、diff summary、人工抽查 |
| 跨模組重構 | 要有設計說明、回滾策略、完整 CI |
| 權限、資安、付款、資料庫 schema | 不應讓 agent 自動合併 |
| production 設定與憑證 | Agent 原則上不該碰，至少要硬性隔離 |
這也是為什麼我一直認為，AI coding agent 對企業的真正挑戰不是「買哪個工具」，而是「你的工程流程有沒有準備承接 5 倍到 10 倍的變更量」。
AI 研發正在被 AI 加速
Anthropic 把 AI 開發拆成兩大類：工程與研究。
工程比較容易理解：寫 code、架基礎設施、跑訓練、修 bug。
研究更難，因為它牽涉到：
- 哪些實驗值得跑？
- 什麼結果可信？
- 失敗是模型不行、資料不行、指標不行，還是實驗設計錯？
- 哪條路線該停？
- 哪個意外訊號值得追？
今天的 Claude 最強的是「已經有人設定目標後，把事情做完」。
例如：給它訓練程式、固定 correctness checks，要求它把速度優化到最好。這種任務有明確目標、明確 feedback loop，AI 很適合反覆試、跑、量測、再改。
但完整的研究判斷還沒被取代。
Anthropic 也承認，今天人類仍然在「看大局、選方向、判斷哪些問題值得做」上有比較優勢。
這一點非常關鍵。因為 recursive self-improvement 真正需要的不是會寫 code，而是會決定自己該怎麼變強。
什麼才叫完整 recursive self-improvement？
Recursive self-improvement 可以白話理解成：
AI 不只是幫人類寫下一代 AI，而是它自己能設計、開發、訓練、評估、修正自己的下一代版本。
這比 coding agent 高很多層。
完整 recursive self-improvement 至少需要：
- 能理解現有模型與訓練流程。
- 能提出新的模型、資料、訓練、推論或工具架構。
- 能判斷哪些實驗值得跑。
- 能執行大規模實驗。
- 能解讀結果，避免被錯誤指標欺騙。
- 能處理安全與對齊問題。
- 能驗證新系統真的比舊系統更好且更安全。
- 能在下一輪繼續重複這個流程。
Anthropic 的立場是：我們還沒到，但如果目前趨勢延續，它可能比多數制度準備得更早到。
這句話可以不用完全相信，但不能忽略。
因為就算完整自我改進沒有到來，第二層的「AI 加速 AI 研發」也已經足以改變產業節奏。
Anthropic 為什麼提到暫停？
這次最有爭議的一段，是 Anthropic 主張世界應該保留一個選項：
如果 frontier AI 發展速度快到社會、安全研究與治理追不上，應該有可驗證的機制，讓主要實驗室共同放慢或暫停。
重點有三個。
第一，Anthropic 不是說自己要單方面停下來。它說如果只有一家公司停，可能只是讓比較不謹慎的競爭者追上，整體不一定更安全。
第二，它強調要「可驗證」。也就是不是大家口頭說停，而是能確認其他主要 lab 真的有停或放慢。
第三，它承認這非常難。訓練 run 不像飛彈井那樣容易被看見；模型訓練用的是通用硬體、資料中心、雲端資源；而且偷偷繼續跑的人有巨大誘因。
所以這不是一個簡單政策口號。
真正問題是：
當 AI 研發速度被 AI 自己加速後，人類能不能建立一套可信的煞車系統？
OpenAI 的角度不同
這幾天另一個值得一起看的文件，是 OpenAI 在 2026 年 6 月 3 日發布的 frontier AI governance blueprint。
OpenAI 的重點不是由 AI lab 自行決定暫停，而是主張美國需要建立更穩定的聯邦治理框架，包含：
- 建立全國性 frontier AI safety 框架。
- 強化 CAISI 作為美國政府 frontier AI safety 的主要機構。
- 讓政府建立更完整的韌性計畫，處理國安與公共安全挑戰。
AP 報導也指出，OpenAI 的立場更偏向「民主政府，而不是私人公司單方面，應該決定 AI 規則、保障與問責機制」。
這讓兩家公司形成一個有趣對照：
| 公司 | 核心語氣 | 背後問題 |
|---|---|---|
| Anthropic | Frontier labs 應研究可驗證的共同放慢或暫停機制 | 如果速度太快，怎麼保留煞車能力？ |
| OpenAI | 民主政府要建立持久 frontier AI 治理制度 | 誰有正當性決定 AI 速度與規則？ |
兩邊其實不完全衝突。
Anthropic 講的是「如果真的要停，要怎麼驗證」。
OpenAI 講的是「誰有權決定要不要停」。
真正困難的是，這兩個問題都還沒有成熟答案。
對一般公司代表什麼？
一般公司不會自己訓練 frontier model，也不會面臨完整 recursive self-improvement。
但這篇對一般公司仍然重要，因為它揭露了一個很快會下放到所有知識工作團隊的現象：
產出變快後，管理系統會先壞掉。
工程團隊會先遇到：
- PR 數量暴增。
- 低品質 diff 淹沒 reviewer。
- 測試與 build 成本上升。
- Agent 產生的變更難以歸責。
- Code ownership 變模糊。
- 安全審查跟不上。
內容團隊會遇到：
- 草稿暴增，但品質不穩。
- 事實查核跟不上。
- 站內重複內容增加。
- 圖片、alt、內鏈、更新日期管理失控。
客服與營運團隊會遇到：
- Agent 能回更多訊息，但錯誤回覆也更快擴散。
- 工作流自動化變多，但權限邊界不清。
- 主管看不到 agent 到底做了哪些動作。
所以這篇的實務意義不是「大家都要研究 AGI」，而是：
當 agent 讓每個人像帶著一個小團隊工作，公司必須先升級 review、稽核、權限、測試與責任分配。
對工程師代表什麼？
工程師最直接的變化，是價值重心正在移動。
以前你最重要的能力可能是：
- 寫 code 很快。
- 熟框架。
- 熟語法。
- 能修 bug。
- 能看 log。
這些還重要，但 coding agent 會把它們部分商品化。
接下來更稀缺的是：
- 會拆任務。
- 會設驗收標準。
- 會看 agent diff。
- 會判斷架構風險。
- 會設計測試與回滾策略。
- 會限制 agent 權限。
- 會把重要決策寫成文件，而不是只留在對話裡。
- 能分辨「看起來完成」和「真的可上線」。
換句話說，工程師不是被 code generator 取代，而是被迫往 tech lead 和 reviewer 的方向移動。
你不一定要管理人，但你會越來越常管理 agent。
對台灣團隊的具體建議
如果你的團隊已經在用 Claude Code、Codex、Cursor、GitHub Copilot 或其他 coding agent，我會建議先做這幾件事。
1. 把 agent 產出分級
不要把所有 AI diff 都當同一種東西。
| 等級 | 例子 | 管理方式 |
|---|---|---|
| L1 低風險 | 文件、註解、測試資料、排版 | 可快速 review |
| L2 中風險 | 單檔 bug fix、元件改寫 | 要測試和人工 review |
| L3 高風險 | 跨模組重構、資料模型、權限邏輯 | 要設計說明、完整 CI、owner approve |
| L4 禁區 | credentials、production secrets、付款、刪資料 | 預設不讓 agent 直接碰 |
這比單純規定「AI 寫的 code 都要審」更可行。
2. 每個任務都寫驗收條件
不要只說「幫我修好」。
比較好的交辦方式是：
修正登入錯誤。
驗收條件：
1. 現有 auth 測試要通過。
2. 新增一個覆蓋 refresh token 過期的測試。
3. 不改動資料庫 schema。
4. 不碰 production env 檔案。
5. 最後列出改了哪些檔案、跑了哪些測試、還有哪些風險。這種任務格式比單純讓 agent 自由發揮安全很多。
3. 建立 agent review checklist
至少檢查：
- 有沒有改到任務外檔案？
- 有沒有新增不必要依賴？
- 有沒有把錯誤吞掉？
- 有沒有為了讓測試過而降低測試品質？
- 有沒有改動權限、認證、付款或資料刪除邏輯？
- 有沒有把敏感資訊寫進 log？
- 有沒有留下無法回滾的狀態？
4. 把決策寫進 repo，不要只放在對話裡
Agent 的對話上下文會壓縮、遺忘、斷線，也可能在不同工具間無法共享。
真正重要的事要寫進：
READMECONTRIBUTINGAGENTS.mdCLAUDE.md- ADR 文件
- 測試說明
- 部署 runbook
如果你希望 agent 長期可靠，就不要讓它只靠聊天記憶。
5. 控制 CI 和雲端成本
Agent 產生更多 diff，也會跑更多 build、test、preview、deployment。
如果沒有預算與速率限制，成本會比人力更早爆。
這點在多 agent 並行任務中特別明顯。
我對這篇新聞的判斷
這不是「AI 已經活過來」的新聞。
但它也不是普通 PR。
我認為它真正重要的地方有三個。
第一，frontier lab 已經開始公開承認：AI 正在加速 AI 研發，而且不是小幅加速。
第二，產出加速後，最先出現的不是完美自動化，而是 review、治理、算力、資安、責任歸屬的新瓶頸。
第三，AI safety 討論正在從抽象原則，進入非常具體的制度問題：誰有權按煞車？怎麼確認別人也按了？如果不能確認，誰會願意先停？
對一般讀者來說，這篇最值得帶走的一句話是：
AI 的下一個階段，不是只讓你寫得更快，而是讓整個組織產生、修改、驗證知識工作的速度都改變。
如果管理系統沒有跟上，速度本身就會變成風險。
FAQ
Claude 已經能自己打造下一代 Claude 了嗎？
還不能。Anthropic 這次說的是 AI 正在加速 AI 研發，尤其是 coding、除錯、實驗迭代與部分研究流程。完整 recursive self-improvement 指的是 AI 能自主設計、訓練、驗證自己的下一代系統，Anthropic 明確說目前還沒到。
80% code 是不是代表工程師快沒用了？
不代表。它代表工程師的工作重心正在從親手打 code，移到設定目標、拆任務、看 diff、審查架構、設計驗收與控制風險。工程師不一定少做事，但做的事會變。
Anthropic 說的 8 倍生產力可信嗎？
要保守看。Anthropic 自己也提醒 lines of code 不是品質指標，8 倍 code 量幾乎一定高估真實生產力。不過即使打折，方向仍然重要：AI 已經明顯提高工程與研究吞吐量。
為什麼 Anthropic 說暫停需要可驗證？
因為如果只有一家 AI lab 暫停，其他競爭者繼續跑，整體風險不一定降低。要有意義，必須多個 frontier labs 在相同條件下停或放慢，而且能確認彼此真的照做。但訓練 run 很難監測，這也是最大難題。
一般公司現在要做什麼？
先不要幻想全自動研發。比較實際的是建立 agent 使用規範：任務分級、最小權限、review checklist、測試要求、CI 成本控制、敏感檔案禁區，以及把重要決策寫進 repo 文件。