AI 正在徹底改寫技術行業的工作範式。AI 大幅提升效率的同時，也帶來協作疏離、質量把關難等全新問題。本文結合一線高管經驗，解讀 AI 時代工程師與管理者的能力轉型趨勢。

如果有一天，工程師寫代碼的時間只佔工作的一小部分，那工程師還算不算工程師？這聽起來像是個遙遠的假設，但在 Anthropic 的 Claude Code 和 Cowork 團隊裡，這已經是正在發生的現實。Fiona Fung 是這兩個團隊的負責人，她最近在 Lenny’s Podcast 上分享了一組數據，Anthropic 的工程師平均每個季度交付的代碼量，是幾年前的八倍。不是緩慢爬升的曲線，是一條一直很平的線突然衝上了天。

聽完這期Podcast，我腦子裡冒出來的第一個念頭是，寫程式這件事情可能真的變了，而且變得比我們大多數人意識到的還要徹底。Fiona的經歷很有說服力，她當工程師超過25年，從IBM寫底層作業系統服務起步，到微軟做Visual Studio和TypeScript整整11年，再到Meta從零打造Facebook Marketplace，現在這個產品每年的GMV超過1000億美元。她還參與過Meta第一代智慧眼鏡和AR眼鏡專案，在Instagram帶過500人的團隊。這樣一個人來談AI怎麼改變工程師的工作方式，分量是不一樣的。

寫程式不再是稀缺資源

Fiona講了一個讓我印象很深的對比。她說自己當年在微軟做Visual Studio的時候，軟體是刻在CD上發行的，每一次發布都有硬性截止日期，工程師的時間被當成最稀缺的資源，團隊會花大量精力做計劃，確保在有限的時間窗口裡把事情做對。但現在情況完全反過來了，coding不再是瓶頸，反而把每個人能做的事情的天花板都給掀開了。

這句話我反覆琢磨了好幾遍。以前的限制是人手不夠、時間不夠，所以一個想法好不好，往往要先問值不值得投入工程資源去做。現在限制變了，理論上什麼都能做，問題變成了你敢不敢想得更大。Fiona提到團隊裡一個工程師的真實經歷，他本來不是做移動端的，但當產品需要補上移動端功能時，他直接說沒關係，現在有Claude幫我一起做這件事。這種心態的轉變，比八倍的程式碼產出數字本身更值得注意。產出是結果，敢於伸手去做以前覺得超出能力範圍的事情，才是原因。

我自己在做內容創作和產品的過程中，也越來越能體會到這種感覺。以前覺得某個想法太複雜，需要專門去學一項新技能才能落地，常常因此放棄。現在反而會先問一句，這件事真的需要我親自掌握所有細節嗎，還是說我可以藉助工具，把精力放在判斷方向對不對上。這其實是把人的角色從執行者往前推到了決策者的位置，這個轉變對很多人來說是機會，但對還停留在舊思維裡的人來說，可能就是一種被甩在後面的焦慮。

Agency 和 accountability 要綁在一起

Fiona 提到一個詞，agency，中文大概可以理解為主觀能動性，或者說自主決策的能力。她說在 Claude Code 團隊裡，遇到一個問題，不是等著被分配任務，而是每個人都會主動想辦法去解決，這是團隊最看重的特質之一。但她馬上補了一句，高 agency 必須配上高 accountability，也就是高問責。給你足夠的自由去發揮，但你也要清楚地說明你想解決的問題是什麼，你的假設是什麼。

我覺得這句話點出了一個很容易被忽略的陷阱。很多人理解 AI agent 帶來的變化，只看見了自由度變大這一面，覺得反正有工具兜底，做錯了重新生成就好，膽子可以放得更大。但 Fiona 強調的是，自由和責任是一體兩面的，agency 越高，越要能講清楚自己在為什麼目標負責，而不是把責任都甩給工具。這其實跟以前管理團隊的邏輯沒有變，變的只是行動的速度和門檻。門檻降低了，反而對判斷力和說清楚動機的能力要求更高了。

這一點對我自己的工作方式也有啟發。以前做一件事，流程本身會過濾掉很多不靠譜的想法，因為光是執行成本就足夠讓人三思。現在執行成本幾乎消失了，真正能區分一個人做得好不好的，變成了他有沒有能力提前想清楚要解決的問題是什麼，做完之後能不能講明白這個結果到底解決了什麼。換句話說，思考的權重在上升，執行的權重在下降。

非同步和常規流程改變了管理者的一天

Fiona分享了她自己工作方式的變化，這部分我覺得特別真實。以前她每天早上喝咖啡的時候，會去看團隊的回饋渠道，自己判斷哪些問題值得花時間處理。現在她設置了routines，可以理解成自動化的工作流程，每天早上自動掃描所有回饋渠道，總結出主題，甚至直接生成可以審查的PR。她說這就像是從自己生成prompt，變成有一個agent幫她生成prompt和PR，抽象的層級又往上提了一層。

她還提到自己保留了一個Claude Code的遠端會話，接入公司所有的程式碼倉庫，也接入所有的Slack頻道，這樣她對團隊在做什麼有完整的可見度。每個月她會和團隊一起回顧，過去這段時間聚焦在哪些方向，產品上線後效果怎麼樣，回饋渠道裡都說了什麼。她說以前這些會議大部分時間用來生成PR和修bug，現在這些會議變成了真正意義上跟人對話的時間，聊的是影響力，而不只是產出了多少。

這一段讓我重新理解了管理者這個角色在AI時代應該往哪個方向走。管理的核心從來不是盯著任務清單，而是幫團隊判斷方向對不對、資源該往哪裡投。以前因為資訊獲取成本高，管理者不得不花大量時間做資訊整理這種體力活，真正花在判斷和對話上的時間反而被擠占了。現在工具把資訊整理這一層接管過去了，管理者被還原成了它本來該有的樣子，一個負責判斷和溝通的人，而不是一個資訊搬運工。我覺得這才是Cowork這類工具真正厲害的地方，它解放出來的不是工作量，而是注意力。

Trust but verify，驗證比寫程式碼更難

產出漲了八倍，品質怎麼保證，這是我聽這期Podcast時最關心的問題。Fiona給出的答案是trust but verify，也就是信任但要驗證。她說Claude在有明確框架可以對照驗證的時候表現非常好，所以她們的做法是把什麼叫好的標準寫成spec，放進程式碼倉庫裡，跟隨程式碼一起更新，這樣Claude做程式碼審查的時候，就有一個清晰的標尺可以對照。

她還分享了一個很形象的框架，叫bad和sad。bad是指那種不可恢復的嚴重錯誤，比如程式崩潰導致工作丟失。sad是那種可以恢復、但體驗不好的小問題，比如介面閃爍了一下。她說sad堆得多了，也會慢慢演變成bad，所以團隊會主動盯著sad的數量，而不是等它惡化成真正的事故才處理。這種分級方式比單純看一堆效能指標儀表板有用得多，因為指標太多太碎的時候，人反而很難判斷一個數字到底好不好。

我覺得這套思路的價值，遠遠超出了軟體工程的範疇。任何依賴AI agent去批量產出內容或者執行任務的場景，都會遇到同樣的問題：產出快了，誰來把關品質。Fiona給出的解法，本質上是把人的精力從逐條檢查，轉移到了設計驗證標準和監控體系上。人不再是品檢流水線上的一環，而是定義什麼叫合格的那個人。這個角色轉變，我覺得比單純討論AI agent能不能寫好程式碼，更值得每個用AI做內容或者做產品的人認真想一想。

一個人對著agent幹活，會孤獨

這一點是我完全沒想到、但聽完覺得特別真實的細節。Fiona說團隊最近發現，大家因為太頻繁地各自跟自己的agent協作，工作開始變得孤獨。以前團隊協作是真正意義上的協作，有人寫後端，有人寫前端，大家互相依賴、互相討論。現在每個人都可以獨立完成一整條任務鏈，人和人之間的交集反而變少了。

團隊的應對方式是搞了一個配對程式設計午餐，也就是結對程式設計午餐，大家一起觀察彼此是怎麼用克勞德程式碼（Claude Code）和協同工作（Cowork）的，互相學習不同的使用方式。費歐娜（Fiona）說每個人用這些工具的方式都很不一樣，光是看別人怎麼操作，自己就能學到東西。她們還會專門安排駭客松（hackathon），確保團隊還有一起做事的時間。

這讓我意識到，效率的提升和人的連接感，有時候是兩件需要分別花心思維護的事情，不會自動同步發生。工具讓單個人的能力邊界擴大了，但團隊作為一個整體的粘性，不會因為每個人都變強而自動變強，反而可能因為大家各自為戰而被稀釋。我覺得這對任何團隊都是一個提醒，效率工具帶來的孤獨感是真實存在的副作用，需要主動設計一些機制去對沖，而不是假設它會自己消失。

管理者也要先做執行者，也要持續用自己的產品。

Fiona提到她們招管理者有一個原則，新管理者入職之後，會先有一段時間純粹做IC，也就是個人貢獻者，先深入程式碼和產品本身，再去承擔帶人的責任。她說如果一上來就急著扮演管理者的角色，反而很難真正跟團隊建立信任。先花時間理解產品和程式碼，再去支持別人，這個順序很重要。

她自己也是這麼做的，即便帶著幾百人規模的團隊，她仍然會自己寫一點程式碼，自己用團隊做出來的產品處理日常工作，比如報銷出差費用。她說這不是為了證明自己還能寫程式碼，而是為了保持對產品的真實體感，不讓自己變成只看儀表板和PPT的管理者。她提到一個細節，賣二手MacBook的時候在Facebook Marketplace上差點被騙，這種第一手的踩坑經歷，比任何數據報表都更能告訴你產品哪裡出了問題。

我認為這是一種很樸素、但極容易被忽略的紀律。職位越高，離產品的真實使用場景往往越遠，聽到的回饋也越容易被層層過濾和包裝。Fiona（Fiona）提到的這個習慣，本質上是逼著自己始終站在用戶的真實體驗裡，而不是活在彙報材料建構出來的那個版本的現實裡。這一點不管是不是在做軟體，放到任何管理崗位上都成立。

留意潛在需求（latent demand），別人使用產品的方式，常常超出你的設計

Fiona（Fiona）講了一個我特別喜歡的例子。她身邊有朋友開餐廳，生活很辛苦，經常坐在吧檯前對著一堆帳單算到很晚。她自己用Cowork（Cowork）處理出差報銷的時候，發現這個工具對處理票據和表格特別擅長，於是想，如果這對我這麼有用，對這些小生意主肯定也很有用。她幫朋友們上手之後，發現大家用的方式完全超出她的預期，有個開餐廳的朋友直接讓Claude（Claude）去比較同地區同類菜系的定價水準，得到的結果像一份市場分析報告。

這就是latent demand，也就是潛在需求，指的是用戶已經在用某個產品做一些你沒設計過、但其實很有價值的事情，只是你沒注意到。Fiona說團隊一直會留意這種信號，Cowork後來專門為小企業做了一個功能打包，就是從這些觀察裡長出來的。她總結的方法論是，當你看到有人為了讓某個東西work而拼命想辦法繞彎路，這時候就值得問一句，能不能把這條彎路直接鋪成一條直路。

這個觀察方式我覺得特別值得借鑒。很多產品決策依賴的是用戶調研和需求文檔，但真正有價值的信號，往往藏在用戶自己都沒意識到要主動反饋的那些邊緣行為裡。要捕捉到這些信號，前提是你自己也在真實地使用產品，或者真的花時間去看身邊的人怎麼用，而不是坐在辦公室裡猜。

Context switching，一個還沒人解決的新問題

播客接近尾聲時，Fiona被問到現在還有哪些問題是團隊沒想明白的。她提到一個我特別覺得值得深入討論的點，因為例行工作（routines）與非同步工作變得普遍，大家同時關注的事情變多了，context switching，也就是注意力在不同任務之間切換的負擔，正在變得越來越重。她說自己也會同時啟動好幾個代理（agent）去處理不同任務，結果發現自己反而需要專門留出一段時間，來消化所有這些非同步任務產出的結果。

她坦言這個問題自己也還沒想清楚怎麼解決。聽到這裡我反而鬆了一口氣，因為這說明AI帶來的不全是單方面的解放——它解決了一類問題，同時也製造了一類新問題。過去的瓶頸是產出速度，現在產出速度不再是瓶頸了，瓶頸變成了人的注意力頻寬（attention bandwidth）是否足夠支撐這麼多並行的進展。

我自己最近寫東西、做內容的過程中也有類似的感受。借助工具之後，可以同時推進的事情變多了，但腦子裡要同時裝著的線頭也變多了。這讓我覺得，接下來真正值錢的能力，可能不是怎麼用好某個具體工具，而是怎麼設計自己的工作節奏，讓自己不被這麼多並行的進展壓垮。這是一個新問題，Fiona沒有答案，我自己也沒有，但至少現在知道這是一個值得認真對待的問題，而不是簡單歸結為不夠自律或者工具用得還不夠熟練。