1024程序員節(jié)當(dāng)天，實現(xiàn)需求小紅書技術(shù)副總裁風(fēng)笛受邀出席中國計算機(jī)學(xué)會舉辦的共創(chuàng)工程CCF中國工程師文化日（簡稱CED）五周年盛典，在大會上系統(tǒng)闡述了技術(shù)組織建設(shè)的價值核心轉(zhuǎn)型方向。當(dāng)天包括CCF秘書長唐衛(wèi)清、時代師團(tuán)百度首席技術(shù)官王海峰、實現(xiàn)需求螞蟻集團(tuán)平臺技術(shù)事業(yè)群副總裁周俊、共創(chuàng)工程并行科技董事長陳健等行業(yè)領(lǐng)袖，價值從技術(shù)創(chuàng)新、時代師團(tuán)行業(yè)生態(tài)、實現(xiàn)需求社會責(zé)任等維度，共創(chuàng)工程深度解讀了工程師文化宣言在AI時代的價值五維進(jìn)化。

 風(fēng)笛的時代師團(tuán)分享主要圍繞AI Native時代技術(shù)團(tuán)隊如何重構(gòu)協(xié)作模式，推動工程師角色從傳統(tǒng)執(zhí)行者向價值創(chuàng)造者轉(zhuǎn)變展開，實現(xiàn)需求回答了誰擠占了工程師寫代碼的共創(chuàng)工程時間、AI編程的價值能力邊界、AI時代技術(shù)團(tuán)隊的新的組織和協(xié)作模式等問題。

以下根據(jù)王曉博演講整理：

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

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

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

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

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

數(shù)據(jù)來自一線公司團(tuán)隊的訪談?wù){(diào)研，存在部分metric度量數(shù)據(jù)作為支撐。

這種現(xiàn)實情況不僅存在于互聯(lián)網(wǎng)研發(fā)團(tuán)隊，甚至存在于一些硬件公司、軟硬結(jié)合的公司。在此環(huán)境下，工程師的綜合能力發(fā)展持續(xù)受到傷害。具體呈現(xiàn)出幾個問題：

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

創(chuàng)新能力下降：沒有時間做“非業(yè)務(wù)驅(qū)動的技術(shù)性探索”

工程質(zhì)量難提升：短期上線優(yōu)先→ 測試不足 → Bug 多 → 修復(fù)時間反噬開發(fā)時間

心理疲憊 / 職業(yè)倦怠：工程師從“創(chuàng)造者”變成“需求翻譯機(jī)”，長期消耗創(chuàng)造力

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

業(yè)務(wù)強(qiáng)需求驅(qū)動下，以業(yè)務(wù)為中心而非技術(shù)，需求頻繁變動，研發(fā)僅被當(dāng)作 “實現(xiàn)工具”；

項目節(jié)奏高壓，需求壓縮開發(fā)時間，工程師陷入救火式開發(fā)，既沒時間思考重構(gòu)，還得耗費(fèi)精力修復(fù) “趕工產(chǎn)物”；

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

技術(shù)債積累，阻礙系統(tǒng)迭代，團(tuán)隊質(zhì)量下降、人員潰散，在“架構(gòu)孵化和對抗架構(gòu)腐化“中不斷循環(huán)；

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

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

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

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

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

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

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

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

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

 新的協(xié)作方式與組織變革：以任務(wù)導(dǎo)向的去中心化網(wǎng)絡(luò)型組織

基于我們對當(dāng)下AI編程能做與不能做的認(rèn)知，團(tuán)隊的組織和協(xié)作方式正在發(fā)生變化。

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

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

這會導(dǎo)致過去研發(fā)團(tuán)隊中關(guān)鍵節(jié)點上owner或leader的主要工作，變成解決人與人之間的協(xié)調(diào)、需求之間的沖突，以及彌補(bǔ)信息差。

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

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

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

從層級制向網(wǎng)絡(luò)化、任務(wù)制轉(zhuǎn)變：AI協(xié)作成為中間層，技術(shù)力量隨之轉(zhuǎn)變自己的定位

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

從職能型組織到流式組織：以任務(wù)組為最小協(xié)作單元，AI能力貫穿在整個生產(chǎn)過程中

團(tuán)隊會變得更小，呈現(xiàn)出“小團(tuán)隊”、“高算力”、“扁平化”的特點——由6-8人類似特種兵小隊的自組織小組，能夠調(diào)用、驅(qū)動強(qiáng)大的AI能力，整個團(tuán)隊結(jié)構(gòu)隨之變得更加扁平。

我們需要建設(shè)以任務(wù)導(dǎo)向、去中心化的網(wǎng)絡(luò)型組織，讓工程師逐漸從需求的實現(xiàn)者轉(zhuǎn)變?yōu)閮r值的共同創(chuàng)造者。當(dāng)生產(chǎn)力更強(qiáng)后，工程師能夠參與到價值創(chuàng)造過程，而不只是實現(xiàn)需求。

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

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