AI 時代到底該怎麼管一個工程團隊
整理版優先睇
AI時代嘅工程管理：砍流程、用AI評審、讓代碼變成唯一事實來源
呢篇文章係Anthropic旗下Claude Code同Cowork嘅工程與產品負責人Fiona Fung喺Code with Claude 2026大會上嘅演講整理。佢之前喺微軟做咗十二年（由Visual Studio做起），後來去Meta帶過Facebook Marketplace同Instagram嘅工程團隊，2025年9月加入Anthropic。佢想解答嘅問題係：當寫代碼成本幾乎變零嘅時候，工程團隊嘅管理點樣徹底改革？整體結論係：過去所有基於「寫代碼好貴」呢個假設建立嘅流程（例如半年路線圖、繁瑣嘅設計文檔、馬拉松式嘅代碼評審）都需要被砍掉，新嘅瓶頸係驗證、評審、跨職能協作同安全。
佢提出咗一系列具體做法：唔再做六個月路線圖，改用即時規劃（jit planning）；將討論媒介由「寫文檔」變成「直接發PR」；將質量保障推前（shift left），靠自動化接住高產出；將大部分代碼評審交畀Claude（風格、lint、補測試），人只保留法律安全同產品感覺嘅審批。團隊內部要求所有人用Claude Code，盡量claudify everything，同時明確授權大家殺掉過時流程，例如用Claude自動總結每日狀態取代站會或填表。
組織層面，佢堅持儘量扁平，所有小組共享一個mission，避免對齊損耗。經理一定要從一線IC做起，唔肯就唔請。佢仲提到一個關鍵轉變：代碼成為唯一事實來源，設計文檔可以廢除；如果真係要保留s…
- 寫代碼成本接近零之後，瓶頸由「編碼慢」變成「驗證、評審、協作、安全」，所有舊流程要重構。
- 用即時規劃（jit planning）取代半年路線圖；先發PR再討論，取代先寫文檔再開會。
- 質量保障要左移（shift left）：將測試同驗證推前，靠自動化（Claude）接手高產出。
- 代碼評審中，Claude負責風格、lint、補測試；人保留法律安全同產品感覺（sense）嘅審批。
- 組織保持扁平，經理必須由IC做起；用「程式碼係唯一事實來源」取代傳統文檔，減少同步損耗。
時代轉變：由CD到AI，編碼唔再係瓶頸
Fiona Fung將時間線拉返去2000年代初，佢喺微軟做Visual Studio 2005，當時軟件仲靠CD發行，每個版本有雷打不動嘅發佈主線。後來互聯網改變咗發行節奏，而家輪到AI打爛「寫代碼」本身嘅成本結構。佢反覆強調一句：「過去管用嘅老經驗，而家未必行得通。」
多年嚟工程節奏都係圍繞「寫代碼好貴」呢個假設建立，由瀑布到敏捷，每種方法論都係喺分配呢塊稀缺資源。
Claude Code團隊而家嘅瓶頸係驗證、評審、跨職能協作同安全。代碼量提升後，其他工程負責人最常問佢嘅問題係：「啲代人點審得曬？」佢話維護成本唔會跟住生成成本歸零，呢個係新常態。
- 正在失效嘅舊流程清單：半年路線圖、排期會議、代碼所有權劃分、馬拉松式評審、傳統團隊結構、知識庫分享、長時間onboarding。
- 佢列出呢啲全部都係因為「開發成本太高」而被現實逼出來嘅歷史產物，而家應該砍掉。
少做乜、多做乜：用PR取代文檔，質量向左移
Fiona分享咗佢啱啱加入Claude Code時仲問：「唔需要做六個月路線圖？」寫出嚟前三個月仲用得，過完新年已經變咗大半。佢改用jit planning（即時規劃），原型成本趨零嘅時候，「提前規劃」嘅槓桿消失曬。
設計文檔大量減少，Claude Code團隊嘅默認討論媒介由「先寫份doc」變成「先發個PR」，有諗法直接做出嚟。
產品評審會同樣開得少，因為產品形態變得太快。佢將內部版本推畀Anthropic全員（叫「ant-fooding」），再推畀外部用戶，聽佢哋點用。
Fiona仲講咗個真實小焦慮：佢有次修咗個履歷相關嘅bug，第二日見到有人喺羣組@Boris報新bug，佢形容「心跳都漏咗半拍」，生怕係自己搞嘅。呢種心理負擔喺高吞吐量環境下好常見。
代碼評審：AI做乜，人做乜
Fiona講到技術辯論嘅方式變咗。佢啱入團隊時想重構，同Boris有分歧，差點習慣性話「走去白板房畫一下」。但佢即刻諗到：不如叫Claude一嘢搓三個PR，直接對比完整實現，仲可以拉出對所有調用方嘅影響。
當寫代碼變得輕而易舉，無休止嘅爭論就顯得極其昂貴。
佢提醒：正因為生成代碼成本低，團隊文化同底線共識反而更關鍵。決唔可以變「最後一個commit嘅人贏」，例如有人凌晨三點偷偷交代碼。
- 1 交畀Claude做嘅：風格檢查、lint去重、回應代碼評審意見、捉常規bug、補單元測試。
- 2 留畀人做嘅三類：法律合規審核、安全敏感代碼邊界確認、產品體驗嘅sense同品味（例如佢將Claude終端扮雪人嗰次，設計師話似Mr. Peanut）。
佢話Claude非常擅長「打理」PR，通常人接手之前就已經搞定大部分粗重嘢。
組織形態：扁平、經理由IC做起、代碼係事實來源
Anthropic原本想用「10個IC配1個經理」嘅結構，Fiona直接拒絕。佢要儘量扁平，Claude Code同Cowork兩條線只共用一個團隊mission，唔畀每個小組各自定mission，因為mission一變多層級就要花時間對齊。
佢堅持Claude Code團隊所有經理都要先做IC（一線工程師），招聘官一開始話佢「癲咗」，話冇經理肯咁做。佢回應：「唔願意就早啲好聚好散。」
佢自己都係例子：上一次push代碼係2017年，加入Anthropic之後先重新寫起。佢話而家連git命令都唔記得，全靠Claude幫手。
- 必須統一嘅核心準則：個個用Claude Code；盡可能claudify everything；明確授權殺掉過時流程。
- 放權畀小組自己話事嘅嘢：bug triage、排期節奏、值班安排、邊啲工作流優先上Claude。
三個可觀察指標，同三個未諗清嘅嘢
Fiona冇透露具體數字，但指出三個衡量方向：新人爬坡時間顯著下降、PR生命週期明顯變短（呢個指標會反映下游基建，例如CI管線食唔食得住）、Claude介入提交嘅比例越來越高。佢話已經差唔多四個月冇見過一次非Claude輔助嘅提交。
佢警告：咪死𥄫「代碼有幾多由AI生成」，嗰啲係虛榮指標，關鍵係產品質素同可靠性。
- 1 工程師能跨平台流轉之後，「iOS團隊+Android團隊」分隊仲有冇意義？
- 2 自動化評審要推到幾遠？「信任但驗證」嘅邊界會隨模型能力移動。
- 3 角色模糊之後，點樣令所有人感覺有產出感？
Fiona Fung 喺 Anthropic 大會上講咗 28 分鐘，傾嚇 AI 時代到底應該點樣管理一個工程團隊。
佢整呢套簡報嗰陣，Anthropic 仲未推出 Routines 功能。
三個禮拜之後，Routines 就上咗線。呢個功能係俾 Claude Code 喺雲端按計劃自動執行任務，唔使喺本地長開終端機。等佢真正企喺 Code with Claude 2026 大會講台嗰陣，簡報入面有幾張已經過時咗。
Fiona Fung 係 Anthropic 旗下 Claude Code 同 Cowork 兩條產品線嘅工程與產品負責人。佢之前喺微軟做咗十二年（由 Visual Studio 做起），後尾去 Meta 帶過 Facebook Marketplace 同 Instagram 嘅工程團隊，喺 2025 年 9 月加入 Anthropic。呢次演講唔夠三十分鐘，主題聽落好普通：「AI 時代點樣管一個工程團隊」，但佢講嘅全部係呢一年嚟喺 Claude Code 團隊踩過嘅坑、打爛嘅舊規矩，同埋仲未諗通嘅現實挑戰，一啲都唔講抽象嘅空話。
影片原連結：https://www.youtube.com/watch?v=igO8iyca2_g
• 軟件工程嘅瓶頸以前係「寫 code 慢」，而家就轉移咗去驗證、評審、跨職能協作同埋安全性。 以前嘅各種流程都係基於「寫 code 好貴」呢個假設設計嘅，既然而家「寫 code 幾乎免費」，流程就一定要全部重構。 • 流程好少自然消失，組織只會一層層咁疊加 SLA、規章制度同評審。用 AI 改造工程團隊嘅第一步，其實就係明確容許大家斬啲過時嘅流程。 • 技術辯論嘅方式變咗。以前係拉人去白板房畫架構圖，而家係叫 Claude 同時整三個 PR 出嚟，連埋對 API 嘅實際影響範圍一齊對住 code 討論。 • 喺 Claude Code 團隊，所有 PR 都有 Claude 嘅參與。「段 code 到底係邊個寫嘅？」呢個問題已經慢慢變到冇意義。 • 經理一定要由前線 IC（個人貢獻者）做起。Fiona 請人嗰陣死咬住呢條規矩，負責招聘嘅同事一開始甚至唔明：「而家邊有經理肯倒返轉頭寫 code㗎」。佢嘅回應好乾脆：「唔願意就趁早好嚟好去」。 • 組織盡量扁平、所有小組共用一個團隊目標（mission）。理由好簡單：目標一變，層級越多越容易產生對齊損耗，扁平就係靈活。 • Code 就係唯一嘅「事實來源」（source of truth），而唔係設計文件。 如果一定要保留 spec，就將 spec 提交入 code base，叫 Claude 去驗證 code 同文件係咪一致。 • 衡量效果睇三個指標：新人上手時間、PR 嘅生命週期、Claude 輔助提交嘅比例。但佢亦警告，唔好死睇「有幾多 code 係 AI 寫嘅」，嗰啲只係虛榮指標，關鍵係睇產品質量同可靠性。
【1】二十年裏面，行業被重塑咗兩次
演講一開始，Fiona 將時間線拉返去 2000 年代初。佢當時喺微軟做 Visual Studio 2005——全球其中一個主流開發工具。嗰陣時軟件仲係用 CD 發行嘅（再早啲係用磁碟）。因為軟件要送去生產線刻碟、裝盒、鋪貨去舖頭，每個版本都有雷打唔動嘅發佈主線。
後尾互聯網嚟咗，將發行方式由 CD 變成網上分發，工程節奏跟住被顛覆。而家輪到 AI，但今次變嘅唔單止係發行節奏，而係「寫 code」呢件事本身。
以前有用嘅老經驗，而家唔一定行得通。
（「What served you prior may not serve you any longer.」）
佢喺演講入面成日返返去呢句。多年嚟工程節奏圍繞一個假設搭建：寫 code 貴、寫測試貴、重構貴。由瀑布到敏捷，每一種方法論都係喺度分配呢塊稀缺資源。
舊年佢仲喺度鬧 vibe coding（憑感覺編程，由 OpenAI 聯合創辦人 Andrej Karpathy 喺 2025 年初提出）：「點解周圍都用常量，工程實踐咁差。」一年之後，模型變得勁咗好多。呢種突破已經遠遠超出單純嘅「提速」範疇，而係整體吞吐量直接升咗一個數量級。
【2】當編碼唔再係瓶頸，新嘅卡點出現喺邊度
Claude Code 團隊而家嘅瓶頸係驗證、評審、跨職能協作、安全。
Code 量提升之後，佢俾其他工程負責人問得最多嘅問題係：「呢啲 code 人哋點審得曬？」佢都想知道維護成本點計。生成 code 嘅成本幾乎係零，但維護成本唔會跟住歸零。
注： 演講提到嘅「用 Claude Code 構建 Claude Code」係 Anthropic 公司層面嘅公開做法。Boris Cherny 之前喺多次訪問入面講過，自己用 Claude Code 喺 10 日內構建咗 Cowork 呢個面向非技術用戶嘅桌面 Agent。呢個係工程現實，唔係修辭。
佢列咗一份「正在慢慢失效」嘅舊流程清單：長達半年嘅產品路線圖、繁瑣嘅排期會議、對 code 嘅所有權劃分、馬拉松式嘅 code 評審會議、按部就班嘅傳統團隊結構、知識庫分享，同埋漫長嘅新人入職培訓（onboarding）。呢啲全部都係因為當初「開發成本太高」而被現實逼出嚟嘅歷史產物。
流程好少自然消失。我哋習慣嘅做法係不斷咁疊加新流程。
（「Rarely do processes kill themselves, we tend to just layer more and more and more processes on.」）
佢舉咗個痛點例子：之前喺某個團隊，SLA（服務級承諾）多到要拉個大表格強制排序，工程師先搞得清邊條需要優先處理。佢一早覺得呢種過度堆砌要清理，但真正下定決心鬱手，係去到 Anthropic 之後。
【3】少做啲咩：六個月路線圖、設計文件、產品評審
啱啱加入 Claude Code 嗰陣佢仲問：「唔需要做六個月路線圖咩？」
寫咗出嚟，頭三個月仲用得，過完新年再睇，已經變咗大半。佢而家用一個詞：jit planning（即時規劃），借用編程概念裏面嘅 just-in-time 編譯，意思係是但需要嘅時候先做，因為原型成本已經接近零，「提早規劃」嘅槓桿消失咗。
設計文件都大量減少。Claude Code 團隊嘅默認討論媒介由「先寫一份 doc」換成「先發一個 PR」，有想法直接做出嚟。產品評審會同樣開得少，因為產品形態變化太快，與其評審 mock，不如將內部版本推俾 Anthropic 全員（佢叫呢個做 ant-fooding，因為公司名 Anthropic 有「ant」），再推俾外部用戶，聽佢哋點用。
【4】多做啲咩：驗證，將質量保障推返去源頭
佢希望團隊喺驗證方面加倍投入，叫 shift left（左移）。傳統軟件 pipeline 左邊係源頭右邊係交付，將質量保障由靠近交付端嘅人手測試，推返去靠近源頭嘅自動化。
點解呢件事變重要？因為角色邊界開始模糊。佢嘅設計師同事而家都會提交 code。Fiona 順便講咗個真實嘅小焦慮：佢有一次整咗個有關求職履歷嘅 bug，第二日睇到 Boris 嘅訊息串，見到有人喺 group 度 @ 佢報告新 bug。佢形容自己當時嘅感覺係「心跳都漏咗一拍」，驚係自己搞出嚟嘅問題。
每個人唔希望因為自己嘅提交搞到服務跪低。喺呢個高吞吐量嘅環境下，呢個係好真實嘅心理負擔。傳統嘅人手 QA 根本接唔住咁高嘅 code 產出率，所以質量保障一定要更早依賴自動化機制。
【5】技術辯論嘅方式變咗：由白板到三個 PR
啱啱加入 Claude Code 團隊嗰陣佢想做一次重構，順便熟習 code base。同 Boris 喺技術方案上有分歧，佢差啲習慣性咁拍膊頭話「行，去白板房畫嚇」。
下一秒佢即刻意識到，其實完全可以叫 Claude 同時整三個版本嘅 PR 出嚟，直接對比完整嘅 code 實現，甚至可以拉曬所有調用方嘅影響出嚟。白板上面畫唔出咁直觀嘅全局視角，但 code 就可以。
當寫 code 變得輕而易舉，無休止嘅爭論就顯得極之昂貴。
（「When building is cheap, arguing is expensive.」）
拋出呢個判斷嗰陣，佢嘅語氣特別嚴肅。佢隨即提醒聽眾：正因為生成 code 嘅成本接近零，團隊文化同底線共識反而變得越嚟越關鍵。
絕對唔可以淪為「邊個最後 commit 邊個贏」。例如有人捱到凌晨三點偷偷提交 code，或者 set 個定時任務搶喺上線前壓哨操作，呢啲絕對唔得。正正因為 code 唔值錢，團隊橫向對齊反而更需要明確嘅底線。
【6】Code 評審：Claude 接手啲咩，人保留啲咩
Cat Wu 喺大會上午嘅 keynote 已經講咗 Claude 自動評審 PR 嘅能力。Fiona 呢度嘅視角更加具體：咩交俾 Claude，咩繼續留俾人。
注： Cat Wu 係 Claude Code 嘅產品負責人，同 Boris Cherny 同台主理 Claude Code 產品方向。
交俾 Claude 去做嘅：風格檢查、lint 去重、回應 code 評審意見、捉常規 bug，同埋補全單元測試。佢話 Claude 而家好擅長「打理」PR，通常喺人手接手之前就已經將大部分 dirty work 做曬。
依然需要人手介入嘅有三類：法律同合規層面嘅審核，因為牽涉風險口徑；安全敏感 code 嘅邊界確認，因為出漏洞嘅代價太高；針對產品體驗嘅 sense（直覺）同品味，呢個都係而家大模型相當難跨越嘅一道門檻。
第三類佢講咗個輕鬆嘅例子。佢有個小嗜好：按節日裝飾 Claude 嘅終端形象。聖誕節嗰次佢想將 Claude 變成雪人，叫 Claude 用 ASCII 字符畫。佢將結果 send 俾設計師同事徵求意見，對方一句話：「你將佢畫成 Mr. Peanut 咗。」
注： Mr. Peanut 係美國知名零食品牌 Planters 嘅吉祥物，戴禮帽同單片眼鏡，個樣同雪人嘅輪廓有啲似。
佢最終採用咗簡單方案：冰藍色加雪花。呢個故事佢用嚟說明產品 sense 嘅意義：抽象判斷好難自動化。
【7】Code 邊界慢慢模糊，角色分工亦重新洗牌
喺 Claude Code 團隊，幾乎所有 PR 都有 Claude 參與。「段 code 到底係邊個寫嘅？」呢個問題開始變得荒誕甚至冇意義。
Fiona 建議唔好糾結呢種表象，而係深挖你真正想搞清嘅係咩：係邊個嘅修改引爆咗 bug？邊個有足夠嘅背景知識去同客解釋技術細節？邊個對呢塊 code 模組嘅來龍去脈比較清楚？如果你問嘅係後面呢幾個細分問題，就會發現往往有更好嘅自動化路徑去回答。例如佢以前有個習慣：每日朝早沖杯咖啡，用 Claude Code 對接客戶反饋頻道去行一次信息彙總摘要；而家呢個動作已經編排咗入 Routines 自動化任務，連手動打 command 都慳返。
注： Routines 係 Claude Code 嘅一個功能，可以設定定時或觸發式嘅自動化任務。Fiona 喺準備呢個演講嘅一個月期間，呢個功能先啱啱上線，連佢自己嘅簡報內容都要因此更新。
呢種角色模糊化係雙向發生嘅。一面係非技術背景嘅人都開始捲起衫袖寫 code，Claude Code 團隊裏面嘅 PM 就係咁提交 PR。另一面係叫工程師跳出自己嗰範疇，去搶傳統上屬於其他崗位嘅嘢做。Fiona 用自己舉例：佢本來想優化 Claude Code 嘅用戶問卷調查，但又揾唔到內容設計師。以前佢可能要拉住內容團隊嘅人不斷改文案字眼，而家佢直接揾 Claude 做文案拍檔。佢自嘲作為一個典型嘅工程師，「喺將文案寫得精煉呢件事上可謂一塌糊塗」。
喺招聘上，Claude Code 團隊重點睇兩類人。一類係有產品感覺嘅創意建造者：好奇心強，見到問題就想做產品去解決，會不斷打磨體驗。另一類係深度系統專家：團隊搭建 Claude Code Remote 嗰陣發現欠缺有分佈式系統經驗嘅人。佢唔再重視嘅係原始編碼吞吐量，模型已經將呢部分拉平咗。
【8】組織形態：盡量扁平，經理由 IC 做起
Anthropic 請佢入 Claude Code 嗰陣，對方默認按「10 個 IC 配 1 個經理，再向下嵌套」嘅結構嚟請人。Fiona 唔要呢種。
佢想要嘅係盡量扁平。Claude Code 同 Cowork 兩條線只共用一個團隊 mission，唔俾每個小組各自定 mission。理由好實際：mission 一變，多層級要花好多時間向下對齊，扁平等於靈活。
佢仲堅持一條：Claude Code 團隊裏面所有經理都要先做 IC（individual contributor，前線工程師）。
招聘官最初嘅反應係「你癲咗」，意思係冇經理肯先做 IC。
我希望 Claude Code 團隊嘅每個經理都由 IC 起步，呢個係我對團隊嘅期望，唔接受就早啲分開。
（「This is what dogfooding on the Claude Code team's about, this is what I expect and if someone's not interested it's better for us to do earlier separation.」）
呢條對佢自己都係。佢上一次 push code 去生產環境係 2017 年，加入 Anthropic 之後先重新寫返 code。佢話自己喺 Meta 嗰陣每年仲試嚇提交一次 PR，但內部工具變得太快，一年學一個 command 第二年就過期。
而家我連 git command 都唔記得曬，全靠 Claude 幫我搞掂。
（「Nowadays I don't even remember git commands, I just always ask Claude to help me out with all of that.」）
【9】由文檔退位，叫 code 做「唯一事實來源」
Claude Code 團隊而家將 code 視為最終嘅 source of truth（唯一事實來源）。例如 Fiona 而家係點答覆技術客訴？佢會直接開桌面版 Claude Code，掛載本地 repo 之後叫大模型直接由 code 度揾邏輯去回答。呢種做法徹底消滅咗軟件行業一個千年遺留問題：開發文檔永遠唔同 code 同步。
但佢特意補充：呢條經驗唔係放諸四海而皆準。如果你哋團隊業務要求一定要有完備嘅需求文檔，就順理成章將 spec 都放入 code base，叫 Claude 交叉驗證嚇最後行出嚟嘅 code 同文檔寫嘅係咪吻合。
喺推行呢啲變化嗰陣，Fiona 區分咗「必須統一」同「交俾小組」兩層。必須統一嘅幾條核心準則：每個團隊成員都要用 Claude Code（包括跨職能夥伴，Cowork 都係）；盡可能將可以自動化嘅工作 Claude 化（團隊內部叫「claudify everything」）；明確容許殺咗已經唔再服務於人嘅舊流程。
最後一條佢俾咗個具體例子。Claude Code 團隊曾經搞過站會，團隊變大之後改咗喺共享表格度填週進度。某日佢睇住呢張大表覺得索然無味：因為資訊明明喺 Claude 讀得到嘅地方，其實叫 Claude 寫個總結 script 放喺嗰度，任何人隨時去拉嚇其他人嘅狀態摘要，呢個唔係好過催人填表咩。
不過俾小組自行拿捏嘅空間亦都好清晰：例如 bug 嘅 triage（分流）機制、排期嘅節奏、邊個當值點樣當，甚至邊啲 workflow 優先級較高要率先上 Claude，全部放權俾小組自己話事。
【10】三個可以觀察嘅指標，同一個警告
佢冇透露具體數字，但點咗三個方向：
新人上手時間明顯下降。工程師、設計師、PM 喺新團隊產生有效產出嘅速度快咗好多。
PR 所需嘅週期明顯短咗。佢順帶一提，呢個其實係個值得深挖嘅指標，因為佢嘅變化折射出嚟嘅唔單止係你個團隊對 AI 工具嘅接受度，有時都會暴露下游基建嘅問題，例如 CI（持續集成）pipeline 或者產品基礎設施環境根本應付唔到工程師而家暴增嘅提交速度。
Claude 介入提交嘅覆蓋比例越來越高。喺 Claude Code 團隊嘅氛圍入面，每一次 commit 有 Claude 幫手先係默認嘅常規操作：
我大概已經四個月冇見過一次冇 Claude 輔助嘅提交喇。
（「I don't think I've seen a non-Cloud assisted commit probably in the last four months or so.」）
但佢喺指標呢一段明確加咗警告：唔好淨係睇「code 有幾多係 AI 生成」。各家公司新聞稿入面呢個比例越講越高，但吞吐量本身唔係目的，要返轉頭睇你究竟喺度解決咩問題、產品質量同可靠性仲守唔守得住。
【11】佢自己都未諗通嘅三件事
Fiona 喺演講最後承認，有三個問題佢仲未有答案：
第一，工程師能夠跨平台流轉之後，傳統嘅「iOS 團隊 + Android 團隊」分隊仲有冇意義。
第二，自動化評審要推到幾遠。「信任但驗證」嘅邊界喺邊度，會隨模型升級再次移動。佢提到當日較早一場關於模型能力嘅演講，意思係評審交俾 Claude 做幾多，唔係一次定落嚟嘅決定。
第三，角色模糊之後，點樣令所有人同樣覺得有產出感。當工程師做到內容、PM 寫到 code、設計師整到 bug，傳統嘅產出歸屬變模糊，公平感嘅設計係新課題。
佢俾聽眾嘅最後建議其實好樸素直接：
揀出極之折騰人、尤其嘮叨嗰條 workflow，重新審視嚇佢到底仲為邊個做嘢。
（「Pick your noisiest workflow … is it still really serving, what's the purpose of there.」）
佢用自己嘅親身經歷做反面教材。以前帶某個團隊嗰陣有個雷打唔動嘅週例會，五十幾個人逼喺一個大房入面。但 Fiona 細心睇發現，除咗俾點名叫起身匯報狀態嘅人會裝嚇抬起頭，其他人全部不約而同低頭打字。後尾佢只係問咗句「我哋到底為咩仲開呢個白痴會」，瞬間全票通過順便就地解散。
影片原連結：https://www.youtube.com/watch?v=igO8iyca2_g
Fiona Fung 在 Anthropic 大會上講了 28 分鐘，聊了聊 AI 時代到底該怎麼管一個工程團隊。
她做這套幻燈片時，Anthropic 還沒有推出 Routines 功能。
三週後，Routines 上線了。這是一個讓 Claude Code 在雲端按計劃自動跑任務的功能，不需要在本地一直開着終端。等到她真正站上 Code with Claude 2026 大會的講台時，幻燈片裏好幾張就已經過時了。
Fiona Fung 是 Anthropic 旗下 Claude Code 和 Cowork 兩條產品線的工程與產品負責人。她之前在微軟幹了十二年（從 Visual Studio 做起），後來去 Meta 帶過 Facebook Marketplace 和 Instagram 的工程團隊，在 2025 年 9 月加入了 Anthropic。這次演講不到三十分鐘，主題聽起來很普通：“AI 時代怎麼管一個工程團隊”，但她講的全是這一年來在 Claude Code 團隊踩過的坑、砸碎的舊規則，以及還沒想明白的現實挑戰，一點也不講抽象的空話。
視頻原連結：https://www.youtube.com/watch?v=igO8iyca2_g
• 軟件工程的瓶頸過去是“寫代碼慢”，現在則轉移到了驗證、評審、跨職能協作和安全性上。 過去的各種流程都是基於“寫代碼很貴”這個假設設計的，現在既然“寫代碼幾乎免費”，流程就必須全部重構。 • 流程極少會自然消亡，組織只會一層層地往上疊加 SLA、規章制度和評審。用 AI 改造工程團隊的第一步，其實就是明確允許大家砍掉陳舊流程。 • 技術辯論的方式變了。過去是把人拉到白板房裏畫架構圖，現在是讓 Claude 同時搓出三個 PR，連着對 API 的實際影響範圍一起對着代碼討論。 • 在 Claude Code 團隊，所有的 PR 都有 Claude 的參與。“這段代碼到底是誰寫的？”這個問題已經漸漸失去意義。 • 經理必須從一線 IC (個人貢獻者) 做起。Fiona 在招人時死死咬住這一條，負責招聘的同事一開始甚至不能理解：“現在哪有經理願意倒回去先寫代碼的”。她的回應很乾脆：“不願意就趁早好聚好散”。 • 組織儘量扁平、所有小組共享一個團隊目標（mission）。理由很簡單：目標一變，層級越多越容易產生對齊損耗，扁平意味着靈活。 • 代碼就是唯一的“事實來源”（source of truth），而不是設計文檔。 如果非要保留 spec，就把 spec 提交進代碼庫，讓 Claude 去校驗代碼與文檔是否一致。 • 衡量效果看三個指標：新人上手時間、PR 的生命週期、Claude 輔助提交的比例。但她也警告，別死盯着“有多少代碼是 AI 寫的”，那只是虛榮指標，關鍵要看產品質量和可靠性。
【1】二十年裏，行業被重塑了兩次
演講一開始，Fiona 把時間線拉回了 2000 年代初。她當時在微軟做 Visual Studio 2005——全球主流的開發工具之一。那會兒軟件還是靠 CD 發行的（再早點是軟盤）。因為軟件要送到流水線上刻盤、裝盒、鋪貨到店裏，每個版本都有雷打不動的發佈主線。
後來互聯網來了，把發行方式從 CD 變成了在線分發，工程節奏隨之被顛覆。現在輪到 AI，但這次變的不只是發行節奏，而是“寫代碼”這件事本身。
過去管用的老經驗，現在未必行得通了。
（“What served you prior may not serve you any longer.”）
她在演講裏反覆回到這一句。多年來工程節奏圍繞一個假設搭建：寫代碼貴、寫測試貴、重構貴。從瀑布到敏捷，每一種方法論都是在分配這塊稀缺資源。
去年她還在抱怨 vibe coding（憑感覺編程，由 OpenAI 聯合創始人 Andrej Karpathy 在 2025 年初提出）：“為什麼到處用常量，工程實踐不好。”一年之後，模型變得能幹太多。這種突破已經遠超單純的“提速”範疇，而是整體的吞吐量直接躍升了一個數量級。
【2】當編碼不再是瓶頸，新的卡點出現在哪裏
Claude Code 團隊現在的瓶頸是驗證、評審、跨職能協作、安全。
代碼量提升後，她被其他工程負責人問得最多的問題是：“這些代碼人怎麼審得過來？”她也想知道維護成本怎麼算。生成代碼的成本幾乎為零，但維護成本不會跟着歸零。
注： 演講提到的“用 Claude Code 構建 Claude Code”是 Anthropic 公司層面的公開做法。Boris Cherny 此前在多次訪談中講過，自己用 Claude Code 在 10 天內構建了 Cowork 這個面向非技術用戶的桌面 Agent。這是工程現實，不是修辭。
她列出了一份“正在悄然失效”的舊流程清單：長達半年的產品路線圖、繁瑣的排期會議、對代碼的所有權劃分、馬拉松式的代碼評審會議、按部就班的傳統團隊結構、知識庫分享、以及漫長的新人入職培訓（onboarding）。這些統統都是因為當初“開發成本太高”而被現實倒逼出來的歷史產物。
流程極少會自然消亡。我們習慣的做法是不斷地往上疊加新流程。
（“Rarely do processes kill themselves, we tend to just layer more and more and more processes on.”）
她舉了個痛點例子：之前在某個團隊，SLA（服務級承諾）多到需要拉個大表格強制排序，工程師才能弄清楚哪條需要優先響應。她早就覺得這種過度堆砌該清理了，但真正下決心動手，還是到了 Anthropic 之後。
【3】少做什麼：六個月路線圖、設計文檔、產品評審
剛加入 Claude Code 時她還在問：“不需要做六個月路線圖嗎？”
寫出來了，前三個月還能用，過完新年再看，已經變了大半。她現在用一個詞：jit planning（即時規劃），借編程概念裏的 just-in-time 編譯，意思是什麼時候需要再做什麼，因為原型成本已經趨零，“提前規劃”的槓桿消失了。
設計文檔也大量減少。Claude Code 團隊的默認討論媒介從“先寫一份 doc”換成了“先發一個 PR”，有想法直接做出來。產品評審會同樣開得少，因為產品形態變化太快，與其評審 mock，不如把內部版本推給 Anthropic 全員（她管這個叫 ant-fooding，因為公司名 Anthropic 含“ant”），再推給外部用戶，聽他們怎麼用。
【4】多做什麼：驗證，把質量保障往源頭推
她希望團隊在驗證上加倍投入，叫 shift left（左移）。傳統軟件流水線左是源頭右是交付，把質量保障從靠近交付端的人工測試，往靠近源頭的自動化推。
為什麼這件事變重要？因為角色邊界正在模糊。她的設計師同事現在也在提交代碼。Fiona 順帶講了一個真實的小焦慮：她有次修了個跟求職簡歷相關的 bug，第二天掃了一眼 Boris 的消息流，看到有人在羣裏 @ 他報新 bug。她形容自己當時的感觸是“心跳都漏了半拍”，生怕是自己捅的婁子。
每個人都不希望因為自己的提交把服務搞掛。在這個高吞吐量的環境下，這是非常真實的心理負擔。傳統的人工 QA 根本接不住這麼高的代碼產出率，所以質量保障必須更早地依賴自動化機制。
【5】技術辯論的方式變了：從白板到三個 PR
剛加入 Claude Code 團隊時她想做一次重構，藉機熟悉代碼庫。和 Boris 在技術方案上有分歧，她差點習慣性地拍肩膀說“走，去白板房畫一下”。
下一秒她馬上意識到，其實完全可以讓 Claude 同時搓出三個版本的 PR，直接對比完整的代碼實現，甚至能拉出對所有調用方的影響。白板上可畫不出這麼直觀的全局視角，但代碼可以。
當寫代碼變得輕而易舉，無休止的爭論就顯得極其昂貴。
（“When building is cheap, arguing is expensive.”）
拋出這個判斷時，她的語氣尤為嚴肅。她隨即提醒聽眾：正因為生成代碼的成本趨於零，團隊文化和底線共識反而變得越發關鍵。
決不能淪為“誰最後一個 commit 誰贏”。比如有人熬夜到凌晨三點偷偷交代碼，或者設個定時任務搶在上線前壓哨操作，這絕對不行。恰恰是因為代碼不值錢了，團隊橫向對齊反而更需要明確的底線。
【6】代碼評審：Claude 接什麼，人保留什麼
Cat Wu 在大會上午的 keynote 已經講了 Claude 自動評審 PR 的能力。Fiona 這裏的視角更具體：什麼交給 Claude，什麼繼續留給人。
注： Cat Wu 是 Claude Code 的產品負責人，與 Boris Cherny 同台主理 Claude Code 產品方向。
交給 Claude 去做的：風格檢查、lint 去重、回應代碼評審意見、抓常規 bug，以及補全單元測試。她說 Claude 現在非常擅長“打理”PR，通常在人工接手之前就把大部分髒活累活幹完了。
依然需要人工介入的有三類：法律和合規層面的審核，因為涉及風險口徑；安全敏感代碼的邊界確認，因為出漏洞的代價太高；針對產品體驗的 sense（直覺）和品味，這也是當前大模型相當難跨越的一道門檻。
第三類她講了個輕鬆的例子。她有個小愛好：按節日裝飾 Claude 的終端形象。聖誕節那次她想把 Claude 變成雪人，讓 Claude 用 ASCII 字符畫。她把結果發給設計師同事徵求意見，對方一句話：“你把它畫成了 Mr. Peanut。”
注： Mr. Peanut 是美國知名零食品牌 Planters 的吉祥物，戴禮帽和單片眼鏡，長得跟雪人在輪廓上有點像。
她最終採用了簡單方案：冰藍色 + 雪花。這個故事她拿來說明產品 sense 的意義：抽象判斷很難自動化。
【7】代碼邊界日漸模糊，角色分工也在重新洗牌
在 Claude Code 團隊，幾乎所有的 PR 都有 Claude 參與。“這段代碼到底是誰寫的？”這個問題正在變得荒誕甚至沒有意義。
Fiona 建議不要糾結於這種表象，而是深挖你真正想搞懂的是什麼：是誰的修改引爆了 bug？誰有足夠的背景上下文去跟客戶解釋技術細節？誰對這塊代碼模塊的來龍去脈更清楚？如果你問的是後面細分的這幾個問題，就會發現往往有更好的自動化路徑來回答。比如她原來有個習慣：每天早上泡一杯咖啡，用 Claude Code 對接客戶反饋頻道去跑一遍信息彙總摘要；現在這個動作已經被編排進了 Routines 自動化任務裏，連手動敲命令都省了。
注： Routines 是 Claude Code 的一項功能，可以設置定時或觸發式的自動化任務。Fiona 在準備這個演講的一個月期間，這個功能才剛上線，連她自己的幻燈片內容都因此需要更新。
這種角色的模糊化是雙向發生的。一面是非技術出身的人員也開始捲起袖子寫代碼，Claude Code 團隊裏的 PM 就在實打實地提交 PR。另一面則是讓工程師跳出自己的一畝三分地，去搶傳統上屬於其他崗位的活兒。Fiona 拿自己舉了個例子：她原本想優化一下 Claude Code 的用戶問卷調查，又找不到內容設計師。過去她可能要拉着內容團隊的人反覆摳文案字眼，現在她直接用 Claude 作為文案搭檔。她自嘲作為一個典型的工程師，“在把文案寫得精煉這件事情上可謂是一塌糊塗”。
在招聘上，Claude Code 團隊重點看兩類人。一類是有產品感覺的創意建造者：好奇心強，看到問題就想做產品來解決，會反覆打磨體驗。另一類是深度系統專家：團隊搭建 Claude Code Remote 時發現缺少有分佈式系統經驗的人。她不再看重的是原始編碼吞吐量，模型已經把這部分拉平了。
【8】組織形態：儘量扁平，經理從 IC 做起
Anthropic 招她進 Claude Code 時，對方默認按“10 個 IC 配 1 個經理，再向下嵌套”的結構來招人。Fiona 不要這種。
她想要的是儘量扁平。Claude Code 和 Cowork 兩條線只共用一個團隊 mission，不讓每個小組各自定 mission。理由很實在：mission 一變，多層級要花很多時間向下對齊，扁平等於靈活。
她還堅持一條：Claude Code 團隊裏所有經理都要先做 IC（individual contributor，一線工程師）。
招聘官最初的反應是“你瘋了”，意思是沒有經理願意先做 IC。
我希望 Claude Code 團隊的每個經理都從 IC 起步，這是我對團隊的期望，不接受就早點分開。
（“This is what dogfooding on the Claude Code team's about, this is what I expect and if someone's not interested it's better for us to do earlier separation.”）
這一條對她自己也是。她的上一次 push 代碼到生產環境是 2017 年，加入 Anthropic 之後才重新寫起代碼。她說自己在 Meta 時每年還試着提交一次 PR，但內部工具變得太快，一年學一個命令第二年就過期了。
現在我連 git 命令都不記得了，全靠 Claude 幫我搞定。
（“Nowadays I don't even remember git commands, I just always ask Claude to help me out with all of that.”）
【9】從文檔退位，讓代碼成為“唯一事實來源”
Claude Code 團隊現在把代碼視作最終的 source of truth（唯一事實來源）。比如 Fiona 現在是怎麼答覆技術客訴的？她會直接啓動桌面版 Claude Code，掛載本地 repo 後讓大模型直接從代碼找邏輯去回答。這種做法徹底幹掉了軟件行業的一個千年遺留問題：開發文檔總是不和代碼同步。
但她特意補充說明：這條經驗並不是放之四海而皆準的。如果你們團隊業務要求必須有完備的需求文檔，那就順理成章把 spec 也提到代碼庫裏，讓 Claude 交叉校驗一下最後跑出來的代碼跟文檔寫的是否吻合。
在推行這些變化時，Fiona 區分了“必須統一”和“交給小組”兩層。必須統一的幾條核心準則：每個團隊成員都要用 Claude Code（包括跨職能夥伴，Cowork 也是）；儘可能把能自動化的工作 Claude 化（團隊內部叫“claudify everything”）；明確允許殺掉已經不服務於人的舊流程。
最後一條她給了個具體例子。Claude Code 團隊曾經搞過站會，團隊變大後改成在共享表格裏填周進度。某天她看着這張大表覺得索然無味：因為信息明明都在 Claude 能讀到的地方，其實讓 Claude 寫個總結腳本丟在那裏，任何人隨時去拉一下其他人的狀態摘要，這不比催人填表高到不知道哪裏去了。
不過給小組自行拿捏的空間也非常清晰：諸如 bug 的 triage（分診）機制、排期的節奏、誰值班怎麼值，乃至哪些工作流優先級較高需要率先上 Claude，統統放權讓小組自己說了算。
【10】三個可觀察的指標，和一個警告
她沒透露具體數字，但點了三個方向：
新人爬坡時間顯著下降。工程師、設計師、PM 在新團隊產生有效產出的速度明顯更快。
PR 所需的週期明顯變短了。她順帶一提，這其實是個值得深挖的指標，因為它的變化折射出的不僅僅是你這團隊對 AI 工具的接受度，有時也會暴露下游基建拉胯的弊端，比如 CI（持續集成）管線或產品基礎設施環境根本吃不消工程師當前暴增的提交速率。
Claude 介入提交的覆蓋比例越來越高。在 Claude Code 團隊的氛圍裏，每一次 commit 帶上 Claude 才是被默認的常規操作：
我已經差不多四個月沒看到一次非 Claude 輔助的提交了。
（“I don't think I've seen a non-Cloud assisted commit probably in the last four months or so.”）
但她在指標這一段明確加了警告：不要只看“代碼有多少由 AI 生成”。各家公司新聞稿裏這個比例越說越高，但吞吐量本身不是目的，要回頭看你究竟在解決什麼問題、產品質量和可靠性還守不守得住。
【11】她自己也沒想清楚的三件事
Fiona 在演講最後承認，有三個問題她還沒答案：
第一，工程師能跨平台流轉之後，傳統的“iOS 團隊 + Android 團隊”分隊還有沒有意義。
第二，自動化評審要推到多遠。“信任但驗證”的邊界在哪兒，會隨模型升級再次移動。她提到當天稍早一場關於模型能力的演講，意思是評審託管給 Claude 多少，不是一個一次定下來的決定。
第三，角色模糊之後，怎樣讓所有人感覺同樣有產出感。當工程師能做內容、PM 能寫代碼、設計師能修 bug，傳統的產出歸屬變模糊了，公平感的設計是新課題。
她給聽眾的最後建議其實非常樸素直接：
挑出極其折騰人、尤為囉嗦的那條工作流，重新審視一下它到底還在為誰幹活。
（“Pick your noisiest workflow … is it still really serving, what's the purpose of there.”）
她拿自己的親身經歷當了反例。以前在帶某個團隊時有個雷打不動的周例會，五十多號人擠在一個大屋子裏。但 Fiona 細看發現，除了被點到名字起來彙報狀態的人會假裝抬一下頭，其他人全都不約而同在低頭敲鍵盤。後來她只問了一句“我們到底圖什麼還在開這破會”，瞬間全票通過順帶原地解散了。
視頻原連結：https://www.youtube.com/watch?v=igO8iyca2_g