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