當程式碼不再是瓶頸：Anthropic 視角下的 AI 原生工程與團隊管理藍圖
title: “當程式碼不再是瓶頸：Anthropic 視角下的 AI 原生工程與團隊管理藍圖” date: 2026-06-24 description: “Anthropic Claude Code 團隊的完整管理方法論拆解。工程師每季產出 8 倍，但瓶頸從寫程式轉移到驗證與安全。軟體工程經歷四代演進，工程師從寫語法變成編排 AI Agent。PM 和設計師都在提交程式碼，全員皆為建造者。TDD 2.0 讓 AI 寫測試、AI 修復、人類只做架構驗證。管理者用 Routines 取代微觀審查，用 Bad vs. Sad 框架授權團隊自定品質底線。新主管先當 IC 寫 code 一個月。JIT Planning 一張試算表取代六個月路線圖。高能動性配高當責的雙軌平衡。刻意對抗 AI 開發的孤獨感。三根支柱：無懼的建造者、非同步的管理、連結的文化。” author: Wisely Chen categories: [AI Coding, Agent Engineering, 企業 AI 轉型] image: images/ai-native-engineering-org-blog-cover.png —
我之所以寫這個題目，其實是我最近這半年來所做的一些實踐，也是在努力將我們團隊打造為 AI Native Organization。這過程中有非常多的「坑」跟「雷」，我們都親自踩過，也因此產生了一些相關的想法與方向。但我個人認為，這不見得每個東西都得百分之百照做，我也不是對每一點都百分之百贊成，不過這確實是世界頂尖團隊相關的 Best Practice，所以我們可以先針對這些來做討論。
本文內容整理自兩個公開來源：
- Lenny’s Podcast 訪談：與 Anthropic Claude Code 團隊工程主管的一小時深度對話
- Running an AI-Native Engineering Org：Anthropic 官方 Blog 發表的結構化文章
Podcast 有故事和人味，Blog 有框架和數據。合在一起看，這可能是目前公開資料中，對「AI 原生工程團隊怎麼運作」描述最完整的第一手資料。
AI 原生組織的三根支柱
在展開所有細節之前，先看全貌。一個 AI 原生組織（AI-Native Organization）的運作，建立在三根支柱上：
支柱一：無懼的建造者（The Builder） — 利用 AI 擴展能力，專注產品直覺或深層系統驗證。不再被「會不會寫某種語言」限制，而是被「能不能定義問題」和「能不能驗證解法」決定價值。
支柱二：非同步的管理（The Manager） — 採用 JIT 敏捷規劃，依賴驗證框架而非微觀審查。用 Routines 取代逐行 review，用 Bad vs. Sad 授權團隊自定底線，用 impact 取代 output 作為績效指標。
支柱三：連結的文化（The Culture） — 堅持高當責，擁抱平行遊玩，刻意創造人際交流。在所有人都平行操作多個 AI Agent 的時代，人與人的連結從 nice-to-have 變成了必要的管理行為。
以下按這三根支柱展開。
支柱一：無懼的建造者（The Builder）
數字會說話：8 倍產出的現實
Anthropic 工程師現在每季度交付的程式碼量，是 2021 到 2025 年平均的 8 倍。
過去 100% 的程式碼由人類手寫，如今生成程式碼的成本趨近於零。開發速度的物理限制已被解除。
但重點不在這個數字本身。寫程式已經不再是瓶頸了。現在的關鍵在於，你的野心能有多大（How ambitious can you be）。
天花板被打破了。問題不再是「能不能寫出來」，而是「你敢不敢想更大的東西」。
瓶頸轉移：驗證成為新的戰場
當產出不再稀缺，工程的難題從「如何生出程式碼」轉變為「如何驗證 AI 產出的正確性與產品價值」。
“Writing code, writing tests, and refactoring rarely slows us down anymore. But the bottlenecks didn’t go away when agentic coding took away the actual need to type code. Verification, code review, and security took their place.”
過去的痛點： 產能不足、開發資源排擠。你有 10 個需求但只有 3 個工程師，所以永遠在排優先順序。
現在的挑戰： 建立「什麼叫做好」的標準（Framework for what good looks like）、信任與驗證（Trust but verify）。AI 可以一天生出以前一個月的量，但誰來確認這些東西是對的？
人類的新瓶頸是：架構驗證與產品對齊。
這跟我自己用 Claude Code 的體感完全一致。我花最多時間的不是寫代碼，而是想清楚「到底要做什麼」和「怎麼驗證做對了」。這也是我在 ATPM 框架裡一直強調的：AI 時代最值錢的不是會寫程式的人，而是懂需求、會驗收的人。
軟體工程的四代演進
軟體工程的歷史就是一部抽象層級不斷升高的歷史。每一代都把工程師的「專注點」往上推了一層：
第一代：Vim 與終端機（IBM 時代） — 專注於語法。你的腦力花在記住語法、手動編譯、看 log 找錯。
第二代：IDE 與實體發布（Microsoft 時代） — 專注於編譯與週期。有了斷點、有了 debug 工具，但軟體燒在 CD 上發布，死線就是真的死線，miss 了就等下一個發行週期。
第三代：雲端部署與擴展（Meta 時代） — 專注於架構。不再需要等發行週期，但要處理分散式系統、大規模擴展、全球部署。
第四代：非同步代理艦隊（Anthropic 時代） — 專注於編排（Orchestration）。工程師不再只是編寫邏輯，而是「編排」AI 代理來執行非同步任務。
從關心語法，到關心架構，到現在關心如何指揮一群 AI Agent 高效協作。每一代的技術門檻在降低，但判斷門檻在升高。
AI 時代的兩種核心人才畫像
面對 AI 的快速發展，哪些特質能讓工程師脫穎而出？答案很明確，現在最值錢的是兩類人：
創意產品建造者（Creative Builders）： 擁有極強的產品直覺，像夢想家般負責端到端體驗。AI 的角色是幫他們補足全端或底層技術的不足。這種人不只是寫 code，他理解用戶要什麼、體驗的細節在哪裡。
深度系統專家（Deep Systems Experts）： 專注於分佈式系統與底層架構——困難的部分（Hard Parts）。AI 的角色是負責深度審查、信任並「驗證」AI 所生成的複雜邏輯。
注意這裡沒有「會寫 prompt 的人」或「會操作 AI 工具的人」。因為那些是所有人都該會的基本功，不是差異化能力。
真正稀缺的是：能定義問題的人，和能解決最難問題的人。 中間那層「把明確需求轉換成代碼」的工作，AI 正在快速接管。
TDD 2.0：將痛苦的苦工自動化
過去工程師覺得先寫測試就像被強迫吃花椰菜（broccoli）一樣痛苦。測試驅動開發（TDD）的原理依舊偉大，但過去寫測試的沉沒成本極高。
現在，將這項工作交給 AI，人類只負責驗證。
舊 TDD（人工吃苦）： 人寫測試 → 測試失敗 → 人寫程式碼 → 通過。每一步都是人力，每一步都痛苦。
TDD 2.0（極速驗證）： AI 寫測試 → 測試失敗 → AI 生成修復 → 人類專注架構驗證。
整個循環的速度跟以前完全不在同一個量級。人類從「寫測試和寫代碼」的苦工中解放出來，專注在最高價值的環節：判斷這個架構對不對、這個行為是不是我們要的。
這跟 OpenAI 的 Harness Engineering 實踐完全呼應。之前 OpenAI 那個 3 人團隊 5 個月產出 100 萬行代碼的做法也是：先讓 Agent 寫測試，再讓 Agent 寫實現。
我自己的體感是：AI 生成代碼的品質，80% 取決於測試覆蓋率，20% 才是 prompt 寫得好不好。測試是確定性的護欄，prompt 是模糊的意圖。
角色邊界的消融：全員皆為建造者
過去設計（Design）、產品經理（PM）、工程（Engineering）是三個分開的圈。現在這三個圈正在交疊，中間的交集就是「建造者（Builder）」。
「什麼是職位？職位只是你大部分時間在做的事情的平均值。」
具體來說：
- PM 不再因工程資源不足而成為瓶頸——他們可以自己動手實現想法
- 設計師與 PM 開始直接提交程式碼
- 工程師必須肩負產品體驗的成敗——不能再說「我只負責後端」
PM 可以提交 code 這件事，本身就證明了寫程式的技術門檻正在被壓平。但判斷「什麼該做、什麼不該做」的能力門檻，反而在升高。
支柱二：非同步的管理（The Manager）
新管理範式：讓 AI 擔任管理副駕
面對暴增的產出，管理者無法再逐行審查程式碼。解法是透過設定非同步 AI 例程（Routines）來梳理每日進度與回饋。
Anthropic 內部的實際做法：每天早上，Claude 已經自動掃過所有內部回饋頻道，整理出重點，甚至生成了修復 Bug 的 Pull Requests 供審查。不是「幫你讀信」那種程度，而是直接生成可以 review 的 PR。
整個管理信號流是這樣的：
- Slack 顧客反饋 → 自動化例程（Routines）→ 管理者
- PR（程式碼合併）總結 → 自動化例程（Routines）→ 管理者
- Bug 趨勢追蹤 → 自動化例程（Routines）→ 管理者
- 管理者消化信號後 → 自動化例程（Routines）→ 後續行動
管理者的核心任務變了：數據追蹤交給 AI，省下的時間用來引發有意義的 1-on-1 深度對話。
不要把產出量跟成功搞混了。產出量只是一個指標，真正的指標是你要解決的那個問題有沒有被解決。
我在做顧問的時候跟企業講這件事，大部分人會點頭，但回去之後還是繼續用行數和 PR 數量考核。Routines 的做法等於是給了一個具體的替代方案：追蹤專案 impact，而不是 output。
IC 優先的主管與深度內部測試
在指導他人之前，管理者必須先作為獨立貢獻者（IC）活在產品中。新主管的前兩個月分成兩個階段：
第一個月：Maker Time（創造者時間）
- 無帶人壓力
- 運用 AI 熟悉 Codebase
- 親自提交 PR（Pull Requests）
- 深度內部測試（Dogfooding）
第二個月起：Manager Time（管理者時間）
- 承擔團隊管理責任
- 開啟 1-on-1 對話
- 帶領團隊驗證架構
核心信念是：「不要在沒有親自使用過自家產品的情況下，盲目迷信儀表板與數據。」
Dashboard 會告訴你「crash rate 是 0.3%」，但它不會告訴你「用戶在某個流程裡需要等 3 秒鐘，然後不確定系統是不是掛了」。這些體驗層的問題只有自己用才會發現。數據是後視鏡，體驗是擋風玻璃。
這跟我在顧問工作裡看到的問題一樣。大部分管理者對 AI 的理解停留在 demo 層級，不是日常使用層級。他們看到 demo 很厲害就以為導入很簡單，結果團隊在實際使用中遇到的問題，他們一個都回答不了。
拋棄繁文縟節：即時敏捷規劃（JIT Planning）
傳統 6 個月的路線圖已經失效了。到第三個月就過時了，後面三個月都在做已經不重要的事。
現在採用雙迴圈的 JIT Planning：
大迴圈（Monthly）： 每月使用極輕量級的試算表對齊團隊優先事項。沒有 Jira，沒有複雜的專案管理工具。一張表、一個月。
小迴圈（Weekly）： 每週檢視這些優先事項是否仍然適用於當前環境。上週決定的事，這週可能因為模型能力升級而需要調整。
行動綱領：
- 拋棄僵化的 6 個月產品路線圖
- 賦予團隊「明確的許可權」去砍掉那些不再服務目標的舊流程與會議
一個具體的行動建議：找出你的「最吵的工作流」（noisiest workflow）——最貴的、最讓人頭痛的、最花時間的流程——然後問兩個問題：它還有必要嗎？能不能自動化？光是這一個問題，就能揪出很多其實早該被砍掉的冗餘流程。
我自己帶團隊的體感也是這樣。AI 讓開發速度快了，但也讓需求變化的速度快了。計畫趕不上變化的時候，你需要的不是更好的計畫，而是更快的調整能力。
重新定義品質：Bad vs. Sad 框架
面對 8 倍的代碼產出，品質怎麼守？不再依賴單一的全局指標。授權各子團隊擁有高能動性，自行定義各自模組的底線，主動防護而非被動看報表。
Bad（糟糕）： 不可挽回的嚴重性錯誤。例：系統崩潰、資料遺失。這些是零容忍的紅線。
Sad（悲傷）： 可復原的體驗痛點。例：畫面閃爍、加載緩慢。這些需要改善但不是緊急。
這個框架的兩個維度是嚴重性（Severity）和發生頻率（Frequency）。Bad 佔據高嚴重性區域，Sad 佔據高頻率但低嚴重性區域。
關鍵在執行方式：不是主管從上面規定什麼是 Bad 什麼是 Sad，而是每個團隊根據自己負責的領域自己判斷。區分「絕對不能錯」和「錯了可以補」，是規模化品質管理的前提。
支柱三：連結的文化（The Culture）
怎麼在 AI 時代建立團隊文化？
AI 讓開發變孤獨了。這是一個很少有人公開談，但每個 AI-native 團隊都在面對的問題。
當每個人都專注於指揮自己的 AI 代理艦隊時，開發變得異常孤獨。以前工程師會一起 pair programming、一起 debug、一起在白板前討論架構。現在大多數時候是一個人平行操作好幾個 AI Agent——像是幼兒園裡的「平行遊玩（Parallel Play）」，每個孩子各玩各的積木，雖然在同一個空間但沒有真正的互動。
解法不是忽略這個問題，而是刻意製造人際連結：
- 結對程式設計午餐（Pair-wise Lunch）：讓大家一邊吃飯一邊觀摩彼此怎麼用 Claude 的工作流，互相學習。重點不是技術分享，是重新建立「一起做東西」的感覺。
- 黑客松（Hackathons）：定期舉辦，重新建立團隊連結。讓人們離開自己的 Agent 艦隊，回到跟真人協作的模式。
「用機器放大產出，用人際互動對抗孤獨。我們比以往任何時候都需要刻意創造人際連結。」
這個觀察很真實。我自己在用 Claude Code 的時候也有類似的感覺——效率飆高，但少了跟人討論的環節。你跟 AI 的互動很高效但不會產生歸屬感。長期來看，工程團隊的凝聚力可能會是 AI 時代最被低估的管理挑戰。
高能動性與高當責的雙軌平衡
AI 原生團隊的文化核心是一組配套的價值觀，像天秤一樣，兩邊等重才能平衡：
高能動性（High Agency）： Freedom to Cook——給予自由去創造與嘗試。工程師可以自主決定用什麼工具、走什麼技術路線、嘗試什麼新做法。
高當責（High Accountability）： Accountability for Hypothesis & Results——對解決假設與最終結果負責。你有自由，但你必須對你的假設和結果負全責。
表現最好的人擁有最強的主動性。給予團隊最大的自由度去運用 AI 工具，但前提是必須對業務假設的驗證負起全責。
很多團隊只給自由不要求責任，結果就是混亂。或者只要求責任不給自由，結果就是僵化。AI 原生團隊的做法是兩個都要，而且是同等程度地要。
成長心態：從恐懼走向掌控
面對 AI 取代技能的恐懼是演化本能。破解之道不在於抵抗，而在於專注「可控之事」，並主動學習新工具。
這是一個四步階梯：
- 恐懼（Fear）：感受到威脅，這是正常的
- 評估可控範圍（What is within my control?）：問自己能做什麼
- 採取行動（Take Action）：開始學、開始用
- 掌控局勢（Agency）：從被動變主動
「你所恐懼的洞穴中，藏著你所尋找的寶藏。（The cave you fear contains the treasure you seek.）」
不是等環境改變，不是等別人來教你，而是問自己「在這個情境下，我能做什麼？」
寫在最後
回到三根支柱：
無懼的建造者 — 利用 AI 擴展能力，專注產品直覺或深層系統驗證。
非同步的管理 — 採用 JIT 敏捷規劃，依賴驗證框架而非微觀審查。
連結的文化 — 堅持高當責，擁抱平行遊玩，刻意創造人際交流。
這三根支柱缺一不可。光有建造者沒有管理框架，就是混亂。光有管理框架沒有文化，就是冰冷的機器。光有文化沒有建造者，就是空談。
「在一個你可以成為任何事物的世界裡，選擇保持善良與好奇。」