当一个团队九成以上的代码都由AI写出，效率却只涨了六成——这两个数字之间，藏着AI Coding真正进入企业的全部难题。在今年的火山引擎Force大会上，字节跳动技术副总裁洪定坤分享了一组来自TRAE团队的内部数据：过去半年里，TRAE超过90%的代码是由AI写出的，但团队的人均需求吞吐率仅提升了60%。这个反差看似反常识，因为AI写代码的速度起码是人的十倍以上，但效率提升却没有达到数倍。这恰恰是今天大多数团队在AI落地上遇到的现实：AI Coding进入企业，从来不是“我用了AI”或者“我用AI生成了多少代码”这么简单。

字节的实践暴露了第一个陷阱：过度盯住单一指标。很多团队在推动AI落地时，自然盯住AI代码贡献率、采纳率、生成代码量这些直观数字。但字节发现，这些数字和真实产出之间存在巨大落差。过度看重代码贡献率，反而让团队没找到全局优化的方法，就像只顾着“摆臂”动作更快，却忽略了整体奔跑效率。更麻烦的是Vibe Coding自身的局限性。这种“有想法就让AI生成一版、跑通再说”的轻量开发方式，容易忽略两件关键事：一是防御性编程，比如用户输入异常数据时程序能否妥善处理；二是异常处理，当系统出错时能否友好提示或安全退回，而不是当场崩溃。TRAE团队做了一个实验：选三个主流Coding模型和三个主流Agent框架两两组合，用一个真实的中等复杂度需求、相同Prompt各跑100次。只看“功能是否基本正确”，所有组合正确率超过80%；但一旦评估UI易用性、可靠性、可维护性、性能、兼容性等维度，分数就断崖式下跌，组合之间还表现出极强的随机性。

解决这个问题的钥匙是Harness。但很多人一提Harness就把它等同于Agent框架，扎进“Single还是Multi Agent、配哪些角色和工具”的讨论里。字节的实践表明，更准确的理解是把Harness当成“基建”——上下文工程、架构约束、团队知识是否沉淀进Memory。它不是白板上画出的顶层框架，而是在真实业务里反复迭代跑出来的工程实践。当TRAE团队把这些基建结合进去重跑那个实验，“可交付性”从原本只有四五十分、勉强可用甚至不及格的程度，普遍被拉到了80分。这说明，不把基建和Harness做扎实，Vibe Coding看着快，实际未必快，甚至更慢。

解决了目标对齐和工程问题，最后留给团队的挑战是协作。AI把写代码的门槛大幅拉低后，产品、设计、运营都能把想法直接变成代码。字节内部就发生过这样的场景：非技术人员用AI生成了大量代码，但这些代码在可维护性和系统性上存在隐患，反而给工程团队带来了额外的Review和重构负担。未来，企业需要重新定义研发流程中的角色分工和协作模式，把AI Coding真正沉淀为组织能力，而不是简单地追求代码生成量。对于AI从业者的建议是：不要被单一的采纳率或生成量指标迷惑，要建立从代码生成到可交付产品的全链路评估体系，同时重视工程基建和团队协作的重构，才能把AI的速度优势转化为真正的生产力提升。