Fiona Fung 管理著 Anthropic Claude Code 與 Cowork 背後的整個工程與產品團隊，Boris Cherny（Claude Code 之父）與 Catherine Wu 都向她匯報。最近一兩個月，她的團隊裡出現了一個新問題：隨著 Routines 上線、工作方式轉向非同步，團隊成員同時運行的 Agent 越來越多，有人一次跑二十個，checking in 和 review 的負荷肉眼可見地在上升。
在 Lenny's Podcast 的一期訪談裡，主持人問她有沒有解決方案，她的回答很直接：我還沒搞定。
過去一年，關於 AI 提升工程效率的敘事，大多停留在"變得多快"這個層面。Anthropic 自己公佈的資料是，工程師人均每季度程式碼產出已經漲到 2025 年同期的 8 倍。但更有意思的問題其實是：當一個人可以同時指揮十個、二十個 Agent 幹活，人和 Agent 之間、人和人之間的協作方式，要重新設計成什麼樣？這也是團隊自己還沒完全想清楚的部分。
這篇文章梳理的，就是 Fiona Fung 在訪談裡透露的這套協作方法論：包括已經跑通的部分，也包括她自己承認還沒解決的部分。
一、驗證，正在取代編寫，成為核心動作
過去，工程時間是稀缺資源，團隊必須在硬性死線前把所有事情規劃到位。如今編碼不再是瓶頸，團隊面對的最大變數變成了"能有多大野心"。隨著更多背景各異的人，不止工程師，還有設計師、產品經理，都一起提交程式碼，吞吐量上升，一個新問題隨之出現：怎麼讓每個人都對程式碼質量有足夠的信心？
Fiona Fung 提到一個具體做法：把"什麼算好"寫成一份 spec，直接檢入程式碼倉庫，並保證 spec 隨程式碼同步更新。程式碼審查因此變成了核對程式碼是否仍然符合當初設定的目標，而不是逐行人工過一遍。她的說法是，只要把這件事寫清楚放進倉庫裡，Claude 做 code review 時就能對照 spec 校驗。
這也讓一個由來已久的工程方法論：測試驅動開發（TDD），重新變得容易堅持。她坦言自己過去一直不太擅長這套流程，感覺像是必須先吃掉那盤西蘭花，而她真正享受的是直接把產品做出來的那份快感。
但她記得自己在 Claude Code 上修復的第一個 bug，做法正是先對 Claude 說：我想做測試驅動開發，幫我先把測試寫出來，確保它先失敗，然後再做真正的修復。她認為，這類原本正確、卻因為"太麻煩"被工程師繞開的好方法論，如今因為有模型分擔了大量執行工作，反而比以前更容易被堅持下來。
二、同一條規律，不止發生在工程師身上
Fiona Fung 認為，PM 是目前受 AI 衝擊第二大的角色。原因很直接：PM 不再受限於工程頻寬，一旦有想法，很多時候可以自己動手實現，不用排隊等工程師有空。
這個變化在資料科學團隊體現得更明顯。她提到一位朋友的經歷：現在很多人會自己用 AI 做一版資料分析，再拿給資料科學家"過目把關"，而這些分析往往有一半時候是錯的。資料科學家的工作因此變成了不斷稽核別人用 AI 生成的分析結果，而不是自己動手做分析。
這兩件事說明，"驗證取代編寫"並不是工程師這一個群體的特殊情況，而是一條正在跨角色重複出現的規律。不管產出的是程式碼、產品方案還是資料分析，核心動作都在從"做出來"變成"判斷做得對不對"。
三、自由和責任綁在一起：Agency、Accountability，與"別把動作當成進步"
Agency（自主行動力）是 Fiona Fung 反覆強調的團隊文化關鍵詞。團隊信奉的原則是：遇到問題，每個人都可以有自己的解法，給予充分自由去大膽嘗試。但她緊跟著補一句：高 Agency 意味著高 Accountability，你解決問題的假設是什麼，做完之後效果如何，都要說得清楚。
她提出過一個管理原則，叫"犯新的錯誤"。允許犯錯是必要的，只要每次犯的是新錯誤，因為如果目標是零錯誤，往往意味著團隊推進得不夠快，或者過於謹慎。
在質量管理上，團隊摸索出一套簡單的分級框架："Bad"指嚴重、不可恢復的錯誤，比如 CLI 崩潰、丟失工作進度；"Sad"則是可恢復但影響體驗的問題，比如介面閃爍。這套分類的具體定義權被下放給各個小組，讓他們根據自己負責的介面或服務自行判斷"什麼算 Bad、什麼算 Sad"，因為不同產品面的儀表盤數字很難直接比較。
責任的另一面，是不要被"動作量"騙過去。團隊內部有過一次關於程式碼行數的爭論：曾有工程師提交了巨量程式碼行數，後來發現只是把一個現成的庫搬運了過來；也有相反的情況：團隊升級了底層框架後，同樣的產出反而生成了更少的程式碼。她的結論是：不要把動作誤當成進步。如果只是在衡量工具的使用量，衡量的是"行動"，但這真的在推動你想要的結果嗎？
這條經驗她在更早的 Facebook Marketplace 時期就吃過虧。當時團隊按區域逐步上線產品，盯著的核心指標是賣家數量，而第一個上線的地區賣家數量偏低，使用者卻依然能順利找到想要的商品。後來發現，這個地區雖然賣家總數不多，卻聚集了不少"超級賣家"。如果當時機械地按賣家數量這一個指標決定是否擴張，很可能會得出錯誤結論。這次經歷讓她此後始終提醒自己：任何指標，那怕曾經很合理，都要不斷追問它是否仍然服務於最初想要達成的結果。
四、從手動巡查到自動調度：協作是怎麼被自動化的
Fiona Fung 描述了自己作為管理者，工作方式的一次顛覆性轉變。她現在會在團隊維護的所有程式碼倉庫裡常駐一個 Claude Code 遠端會話，這個實例同時能訪問團隊的 Slack 頻道和各類指標儀表盤。每個月，她會和團隊成員一起打開這個會話，共同回顧：這個月聚焦做了什麼？上線了那些產品？市場反饋如何？有沒有引發什麼問題？用她自己的話說：以前可能只會用這些會話生成 PR 和修復 bug，現在用它們來和自己支援的人展開對話。
過去一兩個月，這套流程又被一次新功能：Routines，徹底改變了。過去每天早上喝咖啡時，她會人工瀏覽各個反饋管道，判斷當天有沒有時間去修一些小問題；現在她設定了一個每天固定時間運行的 Routine，自動幫她掃描反饋管道、提煉主題，甚至直接生成可供稽核的 PR。她的說法是：以前可能還會自己生成一些 prompt，但現在有了 Routines，幾乎是在讓一個 Agent 幫她生成 prompt 和 PR。
她把這種變化理解為工作方式正在朝更"非同步"的方向演進——過去需要同步地寫一個 prompt、等它跑完，再決定下一步要不要再起幾個任務；現在 Routines 能按她設定的節奏自動生成 prompt、派發給多個 Agent 去執行，等她第二天早上醒來，成果已經以 PR 的形式擺在她面前，供她審閱、決定是否合入。
五、沒被解決的代價：切換負荷與新型孤獨感
協作方式變了，代價也隨之出現，而且團隊自己承認，其中一部分目前還沒有解決方案。
第一個代價是孤獨感。過去的工程協作是"N 個人一起搭一套系統"，有人做後端、有人做前端、有人做 iOS，彼此之間自然產生大量互動；而現在，一個人可能同時運行著十個平行工作的 Claude 實例獨自推進項目，團隊成員之間的互動反而變少了。Fiona Fung 坦承，過了一段時間之後，團隊開始感覺這變成了一種孤獨的體驗，因為大家都在和自己的 Agent 工作太多了。
為此，團隊最近開始組織"結伴程式設計午餐"，也保留駭客馬拉松這樣的集體創作時段。但她自己把這種狀態形容為一種類似孩子"平行遊戲"的狀態：各自在做自己的項目，卻因為並肩工作而彼此受益。但這更像是緩解，而不是真正意義上把協作方式改回從前。
第二個代價是切換負荷。隨著 Routines 和非同步工作方式的普及，團隊成員需要同時跟進的平行 Agent 越來越多，有人一次跑二十個，需要不斷檢查進度、記住每一路任務做到那一步。Fiona Fung 自己也遇到這個問題，她的原話很直接：這方面我們還沒搞定。這也是這次訪談裡少有的、沒有給出解決方案的坦誠時刻。
六、管理者怎麼參與 AI 協作：先做 IC，再談管理
Fiona Fung 在團隊裡推行了一項做法：每一位新晉管理者在正式承擔管理職責之前，都要先以個人貢獻者（IC）身份工作一段時間，此後也要持續保持部分 IC 工作。
這項制度來自她加入團隊後做的一輪內部傾聽巡迴。她在與團隊成員的交流中，聽到不少關於"審批層級太多""希望有更清晰的優先順序"的真實反饋，才決定從制度層面做出調整。她的判斷是：如果一個管理者一上來就急著打開管理工具箱、做管理該做的事，反而容易造成過多的審批層級；而如果先花時間深入程式碼庫和產品本身，往往能和團隊建立起真正的信任關係。
她自己也延續了這個習慣。加入 Claude Code 團隊的第一周，她原本準備走老路，請每位工程師喝咖啡聊需求，後來卻改成向 Claude 提問瞭解程式碼庫。她認為，那怕模型再強，工程師依然要花時間"連按兩下"自己所依賴的那一層。因為只有理解依賴關係，才能真正意識到底層發生了什麼變化，也才能更好地利用這些變化。
寫在最後
回到開頭那個問題。Anthropic 工程師人均程式碼產出漲到 8 倍，靠的不只是模型變強，還有一整套配套的協作方法論：把"什麼算好"寫進 spec，把自由和責任繫結在一起，把管理者的日常判斷範本化成可以自動運行的 Routine，把新晉管理者先按回 IC 的位置。
但這套方法論並不完整。協作中的孤獨感，團隊用結伴程式設計午餐和駭客馬拉鬆去緩解，卻沒有真正解決；平行 Agent 帶來的切換負荷，Fiona Fung 自己的說法是"還沒搞定"。
這大概才是這輪變化更真實的樣子：不是一套已經跑通、可以直接複製的完美方案，而是一個團隊在真實壓力下，一邊搭方法論，一邊承認那些地方暫時沒有答案。 (Datawhale)