90% 的代碼交給 AI 之后，字節發現了一個反常識的真相

當一個團隊九成以上的代碼都由 AI 寫出，效率卻只漲了六成——這兩個數字之間，藏著 AI Coding 真正進入企業的全部難題。

作者｜鄭玄

過去兩年，AI Coding 的能力飛速進步，很快從小眾的極客群體破圈，成了全民狂歡。

但紅利人人可得，不等于企業都接得住。

當一家公司想把這種能力從個體投射到整個組織，往往會先撞上一個反常識的事實。在今年的火山引擎 Force 大會上，字節跳動技術副總裁洪定坤分享了一組來自 TRAE 團隊的內部數據：作為一個本身就在做 AI Coding 工具、又激進地使用的團隊，過去半年里，TRAE 超過 90% 的代碼是由 AI 寫出的。與此同時，團隊的人均需求吞吐率提升了 60%。

AI 寫代碼速度和效率提升倍率的對比丨來自：Force 2026

這個數字看上去有些反常識：AI 寫代碼的速度起碼是人的十倍以上，當九成代碼都由 AI 產出，效率的提升理應是幾倍，好像不該停在六成。

這恰恰是今天大多數團隊在 AI 落地上遇到的現實。這也說明，AI Coding 進入企業，從來不是「我用了 AI」「我用 AI 生成了多少代碼」這么簡單。先進企業之所以能把數字化走得足夠深，靠的從來不是更早地用上某個工具，而是更徹底地把一項新技術沉淀成組織自己的能力。

在 AI Coding 這件事上，企業到底該怎么把技術進步，真正變成自己的生產力？字節用一線實踐，給出了一份沒有標準答案、但足夠詳實的樣本。

01

從字節的實踐，

看 AI Coding 落地的真實挑戰

過去一年，字節的 AI 代碼貢獻率與 AI Coding 上的 Token 消耗增長了五六倍甚至更多，且仍在高速攀升，AI Coding 已經深度嵌入日常研發。但字節并沒有把這些數字當成成績——恰恰相反，正因為用得足夠深，他們才比大多數公司更早地看到了其中的問題。

首先是各種「指標」造成的錯覺。在推動 AI 落地的過程里，大部分團隊很自然會盯住直觀數字：AI 代碼貢獻率、采納率、生成代碼量。可一旦把這些數字和真實產出放在一起，前面那組「90% 對 1.6 倍」的反差就浮了出來——過度看重單一的代碼貢獻率，反而讓團隊沒找到全局優化的方法。

「我用了多少 AI」、「我用 AI 生成了多少代碼」，盯著單一指標蒙眼向前跑，以為是在狂奔，實際可能只是把「擺臂」這個動作做得更快。

比「過度盯指標」更麻煩的，是 Vibe Coding 自身的局限性。「Vibe Coding」在過去一兩年很火，這種「有想法就讓 AI 生成一版、跑通再說」的輕量開發方式，剛開始會很沒寫過代碼的人上癮。但真實世界里的開發，Coding 只是其中一部分，企業要的是長期穩定、可維護、可運營。

Vibe Coding 的問題不是寫不出代碼，而在于它容易只盯著眼前這段代碼「對不對、能不能跑」。但容易忽略兩件真實環境里很關鍵的事：一是「防御性編程」，也就是提前替意外情況做好準備，比如用戶填了不該填的內容、傳進來的數據是空的，程序能不能處理好這些情況；二是「異常處理」，當系統真的出錯時，比如文件讀不到、網絡連不上，代碼得有預案，能友好提示或安全退回，而不是當場崩潰。

這些 AI 都容易悄悄省掉，因為省掉之后Demo照樣跑得通，但這和能真正上線還差得遠。

TRAE 團隊做了個實驗：選三個主流 Coding 模型和三個主流 Agent 框架兩兩組合，用一個真實的中等復雜度需求、相同的 Prompt 各跑 100 次。只看「功能是否基本正確」，所有組合的正確率都超過 80%；可一旦看 UI 易用性、可靠性、可維護性、性能、兼容性這些維度，分數就斷崖式下跌，組合之間還表現出極強的隨機性。

增加 Harness 后，可交付性大幅提高丨來自：Force 2026

Harness 是解決這個問題的鑰匙。但一個很常見的誤區是：很多人一提 Harness 就把它等同于其中的 Agent 框架，扎進「Single 還是 Multi Agent、配哪些角色和工具」的討論里。但在真實業務中，決定 AI 能否落地的，還有大量更基礎、更工程化的東西。

更準確的理解，是把 Harness 當成「基建」——上下文工程、架構約束、團隊知識是否沉淀進 Memory，它不是白板上畫出的頂層框架，而是在真實業務里反復迭代跑出來的工程實踐。

當 TRAE 團隊把這些基建結合進去重跑那個實驗，「可交付性」明顯提升，從原本只有四五十分、勉強可用甚至不及格的程度，普遍被拉到了 80 分。換句話說，不把基建和 Harness 做扎實，Vibe Coding 看著快，實際未必快，甚至更慢。

解決了目標的對齊，解決了工程層面的問題，最后留給團隊的挑戰是：協作。AI 把寫代碼的門檻大幅拉低后，產品、設計、運營都能把想法直接變成代碼。洪定坤透露，字節內部就發生過這樣的一幕：一位產品同學拿著自己用 Vibe Coding 做出來的需求來找研發，頁面能看、流程能跑，她不理解為什么還要排期幾天、為什么不能直接給她倉庫權限自己上線。

顯然，代碼生成的門檻降了，系統復雜度卻沒降。從團隊協作的角度，這里的兩難在于：一方面不能因為「不是工程師寫的」就一概否定——讓更多角色直接把想法變成代碼，溝通更直接、驗證更快；另一方面也不能「誰寫出來誰就上線」，因為代碼要放進既有架構、和已有模塊配合。真正的挑戰，是讓更多人更合理地參與代碼生產，同時讓這些產出匯入統一的架構、規范與交付流程。

把這些挑戰連在一起可以發現，字節對 AI Coding 的關注點，其實已經從「用了多少 AI」悄悄挪到了三件更本質的事情上：找到更合理的指標，去衡量 AI 是否真的全局提升了交付效率；用更穩健的方式，讓 Vibe Coding 走向真正的軟件工程，處理好技術債；以及，圍繞 AI Coding，讓軟件開發上下游的各種角色更好地協作。指標、治理、協作——這不只是字節的課題，也是行業里大多數公司正在共同面對的挑戰。

02

想要用好 AI Coding 的企業，

該怎么做

意識到這些問題之后，字節這一年也在摸索對策。它趟出來的經驗，大致可以歸結為三個層層遞進的轉變——從怎么開始，到怎么貫通，再到怎么讓整個組織都接得住。

轉變從研發的最前端發生。過去的研發習慣是文檔驅動：產品先寫 PRD，設計再畫圖，研發再寫技術方案，最后才上線。問題是，文檔里讀著合理的東西，真做出來往往分歧很大。AI 的改變，是讓團隊能低成本地先做出一個能看、能交互的原型，團隊直接圍著它討論和體驗。

一個很典型的環節是「設計圖變代碼」。傳統流程里，設計師畫好視覺稿，還得由前端工程師照著一行行還原成代碼——洪定坤舉例，去年他做一個小應用，前端同學有六成時間都耗在這道「還原」工序上。而 AI Coding 讓這一步可以被壓縮：未來設計師產出設計稿時，對應的前端代碼就能同步生成，省去大量重復的人工還原。

但原型只是起點。要真正進入企業級研發，還得把共識沉淀成可復現、可驗證、可維護的流程——字節給這套做法起了個名字，叫「系統化的 AI Development」。簡單來說就是：AI 不該只在「寫代碼」這一段發力，而要進入研發的各個流程。

現實中常見的尷尬是——Coding 用了 AI，后面大量工作還是傳統流程、靠人介入。字節的探索，是讓 AI 基于當前 Context 編寫 Spec，功能實現后通過「Browser Use」自動打開瀏覽器驗證、自動修復 Bug，確認無誤后自動提交、協助上線，讓 AI 在全流程里發揮作用。

最后一層也是最容易被忽視的一層，是組織。早期的 AI Coding，效果往往依賴少數高水平個體——會寫 Prompt、懂上下文管理、知道怎么拆解任務和驗證結果的人，效率提升很高。但對組織而言，重要的不是個體多強，而是怎么把團隊整體能力提上來，讓散落在個人手里的實踐沉淀成組織的標準、工具與技能。

字節的做法，是把原型驅動開發、系統化 AI Development 這些經驗文檔化甚至產品化，直接沉淀進 TRAE 這樣的工具，開放給所有工程師共創。一個數字是：過去一年 TRAE 的 Token 日均消耗量達到 5.6 萬億，同比增長 50 倍。

中國銀河證券丨來自：火山引擎

這套從挑戰中長出來的方法論，并不只在字節成立，今天已經有企業使用這套方法論實現了業務提效。

最有代表性的是中國銀河證券。作為國內較早推進 AI Coding 工程化落地的金融機構，它的做法，是引入 TRAE 并系統性推行 SDD（規格驅動開發），讓 AI 嵌入從需求到實現的全流程，而非停在單點補全。

變革取得了顯著的成果：研發需求的整體交付周期縮短了三分之一到二分之一，AI 代碼采納率最高可達 87%，前端 UI 還原度穩定在 90% 以上。落到具體項目，一個 Oracle 數據庫遷移項目，過去整體交付要約 5 天，在 AI 介入下壓縮到 2.5 天，代碼采納率達 95%；一個原本評估需 3.5 人天的基金管理人系統模塊，在 SDD 模式下 1 人天就完成了。AI 改變的不是某個程序員敲鍵盤的速度，而是整個交付鏈條的運轉方式。

亞信科技和尚博信科技則從規模與深度兩個側面做了印證。

前者擁有數萬名研發工程師、數千個并行項目，它用三個月時間走完了「種子團隊試點—標桿擴散—全員普及」三步，把 AI 研發能力鋪到了數千名研發身上，關鍵動作是把企業自己的代碼、文檔、歷史決策私有化沉淀，讓 AI「懂亞信、懂內部 SDK」。

后者在一個大型供應鏈平臺項目里，把原計劃 18 個月、80 人的交付，壓縮到 10 個月、50 人，70% 以上的業務代碼由 AI 生成并實現零缺陷上線；與此同時，開發者的角色也從單純的 code writer，轉向 Reviewer、Architect 和 Problem-Solver。

03

從 AI Coding 到 AI Productivity

「企業怎么用好 AI」正在變成一個比 Coding 本身大得多的命題，今天一個判斷逐漸成為共識：這場競賽，拼的早已不只是模型。

火山引擎總裁譚待在 Force 大會接受采訪時談到，企業最終要解決的，從來不是「我要一個好模型」或「我要一個好 API」，而是「這一整套 AI 怎么在我的企業環境里落地，解決我具體的業務問題」。要做到這一點，需要的東西甚至超出了模型，也超出了 Harness——你要和企業的各種系統打通、和數據打通，要讓 Agent 能在企業里真實地運行和操作，還要做好安全、做好 Agent 的身份鑒權，滿足監管與合規的要求。這是一個比「模型能力」大得多的范疇。

這與海外巨頭的判斷一致。OpenAI 在推出面向團隊的 Workspace Agents 時表示：競爭的關鍵，越來越不在于誰有最聰明的獨立模型，而在于誰能把私有上下文、檢索、工具、治理與協作組合得最好。換句話說，當模型能力本身逐漸拉平，真正決定 AI 能不能在企業里跑起來的，是模型之外那一整套落地工程。

譚待還提到一個前提：讓 AI 真正走進生產，靠的是模型跨過了「生產力質變點」。他觀察到，在視頻生成模型成熟前，調用峰值出現在周末，說明大家更多是在休閑時拿它當玩具；而當模型真正可用之后，工作日的負載反而遠超周末——人們開始在辦公、在生產里用它。

Coding 同理：真正的生產級，是代碼能跑通測試、能真實上線、能承擔核心系統，而不是寫幾個能演示的 Demo。他給行業進度打的分數也很清醒——如果說去年整個行業跑了 500 米，今年也不過一公里多一點，但這一公里關鍵，因為它跨過了生產的質變點。

而這一程一旦跨過，AI 能做的事就不會停在代碼上。

這也是 TRAE 想回答的問題。當它的用戶從工程師擴展到產品、運營、市場甚至學生，AI 的價值就不再被「寫代碼」框住，而是進入更廣義的真實工作——這是 TRAE 推出 Work、并與火山引擎一起把這部分能力集成進企業版的背景。從 AI Coding 到 AI Productivity，TRAE 想做的，不再只是一個面向工程師的編程工具，而是同時承接 Coding 與 Work：既為企業里的個人提效，也為組織整體的效率負責。

TRAE Work丨來自：TRAE

這條從「寫代碼」延伸到「做工作」的路，恰恰是全球第一梯隊的 AI 玩家正在探索的方向。OpenAI 把 Codex 從一個寫代碼的工具，明確重新定義為覆蓋調試、部署、寫 PRD、改文案、用戶研究乃至做幻燈片、分析表格的通用 agent，稱其為「邁向通用 agent 的一步」；Anthropic 也從 Claude Code 延伸出面向更廣泛知識工作的 Claude Cowork。三家公司、三條產品線，指向的是同一個方向——AI 的下一站，是從「輔助人寫代碼」走向「替人完成工作」。

就像洪定坤在演講中提到的「設計圖變代碼」流程，在今天的TRAE Work里完全能夠一站式實現。你可以直接用「Work」功能以自然語言生成設計方案，在「Design」模式的畫布中繼續修改，并切換到「Code」模式銜接現有設計規范和開發流程。

洪定坤在演講結尾說，AI Coding 和 AI Working 都還是很早期的命題。早期意味著遠未塵埃落定，但跨過質變點，意味著這件事第一次真正可被度量、可被信賴、可被規模化地復制到不同行業。

它指向的不再是「AI 能不能寫代碼」這個已經被回答的問題，而是一個更大的命題：當 AI 能穩定地走進企業、走進真實工作現場，它對應的，將是一個遠比「工具」遼闊的市場。

*頭圖來源：視覺中國

本文為極客公園原創文章，轉載請聯系極客君微信 geekparkGO

極客一問

你認為 AI 該如何在企業中落地？