作者｜郑玄
过去两年，AI Coding 的能力飞速进步，很快从小众的极客群体破圈，成了全民狂欢。
但红利人人可得，不等于企业都接得住。
当一家公司想把这种能力从个体投射到整个组织，往往会先撞上一个反常识的事实。在今年的火山引擎 Force 大会上，字节跳动技术副总裁洪定坤分享了一组来自 TRAE 团队的内部数据：作为一个本身就在做 AI Coding 工具、又激进地使用的团队，过去半年里，TRAE 超过 90% 的代码是由 AI 写出的。与此同时，团队的人均需求吞吐率提升了 60%。
这个数字看上去有些反常识：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 是解决这个问题的钥匙。但一个很常见的误区是：很多人一提 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：既为企业里的个人提效，也为组织整体的效率负责。
这条从「写代码」延伸到「做工作」的路，恰恰是全球第一梯队的 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 该如何在企业中落地？
