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

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

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

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

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

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

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

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

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

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

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

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

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

心理疲憊 / 職業倦?。汗こ處煆?ldquo;創造者”變成“需求翻譯機”，長期消耗創造力

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

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

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

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

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

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

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

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

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

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

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

來自效率工具的研發團隊：他們制造“錘子”，肯定只講工具能解決什么問題?？赐旰竽銜X得世界似乎更美好了；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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