運營一個AI原生工程組織 – Claude

在2026年舊金山舉行的Code w/ Claude大會上，Claude Code和Claude Cowork工程總監Fiona Fung詳細介紹了團隊在採用代理編碼作為預設工作方式後，其流程和結構發生的根本性變化。

Fung指出，過去軟體規劃和交付的所有流程——無論是瀑布式還是敏捷式——都是圍繞工程頻寬這一昂貴資源設計的。但隨著代理編碼消除了實際編寫程式碼的需要，瓶頸並未消失，而是轉移到了驗證、程式碼審查和安全領域。工程領導者們最常問的問題之一是：“人類如何跟上你們進行程式碼審查的速度？”

為了應對這些變化，Claude Code團隊重寫了一系列規範。在規劃方面，他們從六個月的產品路線圖轉向即時（JIT）規劃：快速原型，讓內部使用者試用，並根據反饋採取行動。在上下文收集上，新規範是首先詢問Claude，而不是尋找程式碼作者，並考慮是否可以將問題自動化。例如，Fung每天早晨讓Claude自動總結客戶反饋渠道。

程式碼審查方面，Claude負責所有樣式、程式碼風格、錯誤捕獲和測試新增，而人類則專注於需要領域專業知識的領域，如法律審查、信任邊界和安全敏感程式碼。產品經理和設計師也參與產品直覺和品味的把關。

團隊構成也發生了變化。非傳統編碼人員現在能夠做更多工程工作，而工程師則承擔內容設計等傳統上非技術性的任務。Fung特別關注兩類人才：具有產品直覺的創意建設者和具有深厚系統專業知識的工程師。她不再強調原始吞吐量，因為模型已經處理了這一點。

新規範的推出結合了強制性的團隊原則和子團隊（pods）的自主權。核心原則包括：無條件地親身使用產品、保持團隊扁平化（管理者從IC做起）、以及毫不猶豫地淘汰不再有效的流程。每個pod可以自主調整使用Claude進行分診、規劃儀式和站會的方式。

為了衡量新流程是否紮根，Fung建議工程領導者跟蹤三個指標：入職時間縮短（新成員更快生效）、PR週期時間縮短（注意CI可能成為瓶頸）、以及Claude輔助提交的比例上升。但她警告不要將吞吐量與成功混淆：真正的指標是衡量你試圖解決的問題。

最後，Fung鼓勵每個團隊找出最嘈雜的工作流——那個最昂貴或令人畏懼的——並問自己：它還在服務於其目的嗎？如果是，你能自動化它嗎？她分享了一個例子：一個昂貴的週會，所有人都低頭看筆記型電腦，只有輪到報告時才抬頭。一個簡單的問題“我們為什麼還要開這個會？”讓團隊意識到不再需要，從而取消了會議。