1024程序員節當天，小紅書技術副總裁風笛受邀出席中國計算機學會舉辦的CCF中國工程師文化日(簡稱CED)五周年盛典，在大會上系統闡述了技術組織建設的核心轉型方向。當天包括CCF秘書長唐衛清、百度首席技術官王海峰、螞蟻集團平臺技術事業群副總裁周俊、并行科技董事長陳健等行業領袖，從技術創新、行業生態、社會責任等維度，深度解讀了工程師文化宣言在AI時代的五維進化。

風笛的分享主要圍繞AI Native時代技術團隊如何重構協作模式，推動工程師角色從傳統執行者向價值創造者轉變展開，回答了誰擠占了工程師寫代碼的時間、AI編程的能力邊界、AI時代技術團隊的新的組織和協作模式等問題。

以下根據王曉博演講整理：

從上一次參加活動到現在，已經是第五屆了。相比幾年前，最大的變量就是AI。今天要跟大家分享的是：如何能夠把AI新時代的工程師更好地組織起來。

誰擠占了工程師的編碼時間?

這張圖反映的正是工程師的卷積問題。傳統開發模式中，工程師沖在生產交付最前面，但整個交付流程要兼顧速度和質量，就得頻繁直接對生產環節做溝通協調。這導致工程師的受累：會議占滿白天，真正能沉下心寫作代碼的時間，反而被擠壓到了夜晚。我們調研過一些反饋，工程師表示自己寫代碼最快樂的時間，就是夜晚無人打擾的時候。我們曾統計過公司提交代碼的峰值時段：小高峰是零點前后到凌晨一點，最高峰是晚上十點鐘。可以看到，工程師確實是非常辛苦的行業。

那么，工程師的時間都去哪兒了?很多剛從學校畢業的同學，會覺得工程師的時間安排像下圖所示。從研發組織和公司的視角來看，整個工程師團隊的實際生產力遵循這個公式：勞動效率 x 有效的勞動時間(在研發排期里常被稱為PD日，即有效工作時間) x 需求命中率。

然而，實際情況是：大部分工程師的編碼時間只占到1/3，其余都在對齊、解釋、救火和應付流程。在像雙11大促等不確定性更高的項目中，被更高占比的溝通協作時間所擠壓的編碼時間甚至降到1/4及以下。對比兩張表格，我們可以看到差距之大。

數據來自一線公司團隊的訪談調研，存在部分metric度量數據作為支撐。

這種現實情況不僅存在于互聯網研發團隊，甚至存在于一些硬件公司、軟硬結合的公司。在此環境下，工程師的綜合能力發展持續受到傷害。具體呈現出幾個問題：

技術成長斷層：工程師在工作3–5 年后受晉升影響，逐漸遠離代碼生產，寫代碼的手感生了，倒是溝通技巧練得更溜了

創新能力下降：沒有時間做“非業務驅動的技術性探索”

工程質量難提升：短期上線優先→ 測試不足 → Bug 多 → 修復時間反噬開發時間

心理疲憊 / 職業倦怠：工程師從“創造者”變成“需求翻譯機”，長期消耗創造力

理想與現實為何總是存在差距?核心源于以下幾方面：

業務強需求驅動下，以業務為中心而非技術，需求頻繁變動，研發僅被當作 “實現工具”;

項目節奏高壓，需求壓縮開發時間，工程師陷入救火式開發，既沒時間思考重構，還得耗費精力修復 “趕工產物”;

無法避免的層級化管理，管理者實際在“管理情緒”，安撫工程師使其花更多時間把事情做好

技術債積累，阻礙系統迭代，團隊質量下降、人員潰散，在“架構孵化和對抗架構腐化“中不斷循環;

效率工具投入不足，在數以千萬行代碼的大型代碼庫中，高效探索開發變得非常困難。

全棧多面手?理性識別AI Coding的能力邊界

下圖是大家比較熟悉的敏捷開發示意圖。現在有一種新興方式叫AI編程、甲板編程。這種編程方式和傳統的編程方式對比有一個很大的區別：快。 快到一個人能夠成為全棧多面手，涉及前端、客戶端、服務端甚至算法。

但有趣的問題是：待你最后交付，會發現"車"上長出一堆莫名其妙的東西。目前這類快速開發方式通常不會告訴你，大家都是在做demo、做快速原型，反正能跑就行。然而現實情況里，沒有人會拿一個demo直接上線。

當我們討論AI編程時，一般可以分成以下三類：

來自"未使用者"的分享：他們沒用過AI編程工具，主要信息來源是投資人的文稿和公眾號的焦慮營銷;

來自效率工具的研發團隊：他們制造“錘子”，肯定只講工具能解決什么問題。看完后你會覺得世界似乎更美好了;

來自實際應用者的分享：他們實際使用了工具，能夠告訴你功能的邊界，“誰用誰知道”

下圖是我們對于AI Coding的能力評估，紅綠黃代表我們在實踐中的評估結果。這個評估會隨著使用深入而變化，特別是當企業代碼庫接入、做了后訓練之后，表現會截然不同。

新的協作方式與組織變革：以任務導向的去中心化網絡型組織

基于我們對當下AI編程能做與不能做的認知，團隊的組織和協作方式正在發生變化。

過去的協作方式是串行的：從產品、技術負責人、模塊負責人，再到開發、測試、運營、上線，類似施工工序的層層轉包。其中最關鍵的環節是技術負責人到模塊負責人的任務分解。技術本身的實踐和生產不是大問題，但溝通是瓶頸、流程是核心。很多公司的研發流程里做了大量這樣的環節。

新范式下情況則完全不同。Agent coding可以產生很多自動化能力，可以成為一種協調者。在這個過程中，一個工程師能夠調用指揮大量agent。需要強調的是，不要把agent理解成"搞定一切"的銀彈，也不要指望一個agent就能代替你上班，也許未來有可能，但現在還是不現實的。

這會導致過去研發團隊中關鍵節點上owner或leader的主要工作，變成解決人與人之間的協調、需求之間的沖突，以及彌補信息差。

喬布斯曾經說過：“最好的管理者是偉大的貢獻者，他們從來沒想過要成為管理者。在蘋果我們認為聘請職業經理人只會讓我們成為一家大公司。這招沒用，因為大部分人只會管管事，不會做其他事。

我發現最優秀的人才是那些真正理解業務核心的人。(這里的“業務核心”指的是推動業務成果的關鍵因素。)管理他們可能會很棘手。但正因為他們在核心業務上的卓越表現，你愿意忍受這一切。正是這種對核心業務的深刻理解造就了偉大的產品。不是流程，而是核心內容。”

所以在新范式下，組織將面臨三大核心轉變：

從層級制向網絡化、任務制轉變：AI協作成為中間層，技術力量隨之轉變自己的定位

從授權到專精：未來越來越多的技術leader會在自己非常熟悉、知道怎么做的事情上花更多時間。正如喬布斯所說，優秀的leader應該是知道怎么做，而不是主要做任務分解然后安排流程。

從職能型組織到流式組織：以任務組為最小協作單元，AI能力貫穿在整個生產過程中

團隊會變得更小，呈現出“小團隊”、“高算力”、“扁平化”的特點——由6-8人類似特種兵小隊的自組織小組，能夠調用、驅動強大的AI能力，整個團隊結構隨之變得更加扁平。

我們需要建設以任務導向、去中心化的網絡型組織，讓工程師逐漸從需求的實現者轉變為價值的共同創造者。當生產力更強后，工程師能夠參與到價值創造過程，而不只是實現需求。

和大家分享一個小紅書的實戰案例。2025年初，我們在48小時內全球上線翻譯功能。決策階段，我們花了一個小時決定要做這個功能;上線階段，采用新的協作方式，整個工期連起來只用了48小時;最終將如此復雜的功能在極短時間內交付給全球用戶。這個例子充分展示了新協作模式的威力。

在未來，AI 會越發強大，但它并不會取代研發工程師，而是會把對工程師的要求提升到一個新的水位。未來不再需要大量的、處于初級水平的"代碼翻譯員"，需要的是能夠把人的創造力在過程中充分發揮出來，把AI作為協作者，能夠定義系統、治理復雜性、確保可靠性的工程師。