夜雨聆风一、这次他不讲产品，讲"踩过的坑"
去年这个时候，洪定坤在同一个舞台上介绍 Trae。今年他换了思路：与其再讲一遍新功能、新理念，不如让产品自己去说话，他来聊聊字节这一年在 AI 上真实的探索。
他先甩了两个数字：AI 代码采纳率和 Token 消耗量，过去一年都翻了五到六倍，甚至更多，而且还在快速涨。这说明 AI Coding 已经深深嵌进了字节的日常研发。但他紧接着补了一句很重要的话——数字涨得快，不代表这件事就做好了。
我挺欣赏这个开场。大部分大厂分享都止步于"我们增长了多少倍"，而真正有参考价值的，恰恰是用得越深、越能感受到的那些痛点。字节愿意把这部分讲出来，本身就值这张门票。
二、坑一：别把"AI 代码占比"当成 KPI
第一个坑是指标。把 AI 塞进研发流程后，大家自然会盯着几个最基础的数字看：AI 代码贡献率、采纳率、生成代码量。这些指标有参考价值，但只看它们，很容易把 AI Coding 简单理解成"我用 AI 生成了多少行代码"，甚至有团队直接把它做成 KPI 去冲。
Trae 团队自己就是例子。过去半年，他们的代码贡献率冲到了 90% 以上，听起来很激进。可同期人均需求吞吐率只提升了 60%，也就是 1.6 倍。问题来了：AI 写代码的速度比人快何止十倍，当 90% 的代码都是 AI 产的，效率提升却只有 1.6 倍，这中间的巨大落差，恰恰说明单一的代码贡献率根本衡量不了真实的效率。
写得多，不等于交付得快。这其实是古德哈特定律的老剧本：一旦某个指标变成目标，它就不再是好指标。我见过不少团队拿"AI 生成代码占比"对外宣传，听完这段大概要冒冷汗。
三、坑二：Vibe Coding 看着快，"正确"不等于"能上线"
AI 生成代码很快，第一眼也挺能用。但洪定坤说，真实世界的开发从来不是"把功能写出来"这么简单，企业要的是长期稳定、可维护、可运营的系统。他有句话我很认同：软件工程是一门平衡的艺术。
AI 写代码常见的几个毛病：过度设计，一个简单功能套上好几层；该改一个参数，它复制一大段重复逻辑；只顾局部能跑出结果，放到全局却不是最优解。
为了说清楚，他们拿豆包一个即将上线的视频编辑功能做了实验，这是个中等复杂度的需求。团队选了三个主流编码模型、三个主流 Agent 框架，组成九种组合，每种用同样的 Prompt 跑一百次。结果很有意思：单看"功能是否正确"，九种组合的正确率都超过 80%，五次里有四次能跑出结果。可一旦去看可用性、可靠性、可维护性、性能、兼容性这些维度（洪定坤把它们统称为"可交付性"），所有组合都出现了大幅下降，而且呈现出很强的随机性。
正确率 80% 听着很高，但企业要的是第五次也别崩。这个实验我觉得是全场最有分量的一块。它把"看着能用"和"真能交付"之间那道坎，用数据摆到了台面上。
四、Harness：从"能跑"到"能交付"的那段距离
怎么跨过那道坎？洪定坤的答案是 Harness，过去一年很火的一个词。但他的定义很务实：Harness 不是框架本身，而是框架之外、在真实业务里跑出来的工程实践和基建。比如上下文工程，比如规约约束，比如把团队过去的知识沉淀进流程里。
效果是实打实的。把 Harness 和各种基建结合进去之后，同样的九种组合，正确率从 80% 提到了 90% 左右，提升不算特别夸张；但可交付性从普遍只有 40% 一路拉到了 80%，这才是关键。
模型能力决定上限，工程基建决定下限，而真正卡住交付的，往往是下限。这一年大家都在追更强的模型、更新的框架，洪定坤却把重心放在"看不见但很重要"的基建上。这个判断我是站他这边的：花哨的演示谁都能做，能稳定交付的系统才是护城河。
五、坑三：人人都能写代码，但"野生 Vibe"上不了线
AI 带来的另一个变化是：代码生产被普及了，每个人都能把想法变成代码。洪定坤讲了个很真实的例子：一位产品经理自己 vibe 出了一个需求，页面能看、流程能跑，兴冲冲拿给研发，结果被告知还要排期。他很不理解：我代码都写好了，直接提交上线不就行了？
团队认真看了那段代码，问题不少：性能不行、没考虑扩展性、全链路安全是空的。这和前面用外部工具跑实验时遇到的情况一模一样。当系统的整体质量这么往下掉，洪定坤给它起了个名字：野生 Vibe Coding。
"能跑"和"能上线"之间，隔着一整套工程。但我想替这位产品经理说句话：他能自己跑通一个 demo，这件事本身极有价值，沟通成本一下子就降下来了。真正的挑战不是"除了工程师别人写的代码不能用"，而是怎么让更多角色合理、有效地参与进来，最后都汇进统一的架构、规范和交付里。这是组织问题，不是技术问题。
六、字节的解法一：用原型来开发，而不是用文档
讲完三个坑，洪定坤分享了字节的两个尝试。第一个是原型驱动的开发模式。
过去是文档驱动：产品经理写 PRD，设计师出图，研发做技术方案，最后才变成代码上线。问题是，文档和图看着都挺合理，做出来却分歧巨大，过程中冒出一堆问题。AI 改变了这一点，它把做原型的成本大幅降低了，原型可以是高保真、可交互、和真实场景高度一致的东西。
他甚至现身说法：这次大会前四天，他临时起意，让团队用原型把 Trae 里一个他一直觉得做得不好的反馈功能改了一版，现场演示了从第一版原型到第二版原型的迭代过程。
文档会骗人，原型不会。早把分歧暴露出来，永远比上线后返工便宜。这个道理其实不新，但 AI 第一次让"先做个真能用的原型再说"变得足够便宜，这才是它真正动人的地方。
七、解法二：让 AI 跑通从想法到上线的整条流水线
第二个尝试更进一步：让 AI 贯穿研发全流程。他放了一段两分钟的视频，完整走了一遍——在 Trae 上和 AI 共创想法、快速做出高保真原型、AI 按需求拆解 Spec、开发功能、用浏览器工具做需求验证和功能测试、进入"验证—修复—再验证"的循环，完成后提交合并请求，AI 自动做 Code Review、识别实现风险、补上测试覆盖不足的地方，最后正式发布上线。
更关键的是组织层面的思考。有人擅长写 Prompt，有人懂上下文管理，有人会拆任务，个体都能拿到很高的效率提升。但对组织来说，洪定坤更关心怎么把这些能力沉淀下来，变成标准化的工具和技能，去抬高整个团队的水位，而这些正在被产品化进 Trae。
真正难的不是某一步用上 AI，而是让 AI 把整条链路串起来还能稳。从工具到流水线，是个数量级的难度跳跃，也是我觉得这两个尝试里最值得长期看的方向。
八、写在最后：Trae 的成绩单，和一个还很早期的判断
最后他给 Trae 打了个广告，数字确实硬：Token 日均消耗量达到 5.6 万亿，同比去年增长 50 倍，已经是国内认知度最高的 AI 编程工具之一。用户也在泛化，越来越多非工程师背景的人开始用它处理日常工作。为此他们推出了新产品 Trae Work，未来会把 Trae Work、Trae IDE 和火山引擎一起集成进企业版。
但他的收尾很清醒：AI Coding 还是一个很早期的问题。想把它用好，得真正走进企业里，认真听大家遇到的问题和反馈，一起去改进。
整场看下来，我最大的感受不是那些倍数，而是这种肯讲"坑"的姿态。指标、治理、协作，他点出的这三个问题，几乎是每一个正在认真用 AI Coding 的团队都绕不开的。能把增长曲线背后的别扭和困惑讲清楚，比再多一个"翻了多少倍"都更有价值。
