夜雨聆风
字节技术副总裁洪定坤有个分享，我来回看了好几遍，挺扎心的。
先把结论摆前面，省得你错过：现在 AI 写代码这事，模型已经不是瓶颈了。真正卡住人效的，是那些没人爱干的工程基建。
凭啥这么说？看字节内部做的一组实验。
先看一组反差数据
字节挑了三个模型、三个 Agent 框架，两两组合成 9 种方案，针对同一个需求，每组跑 100 次，总共 900 次。
结果很说明问题：
• 功能正确率：所有组合都超过 80%。也就是说，AI 把功能写对的能力，已经过了及格线。 • 工程质量：全军覆没。UI 不对、不复用组件、性能有问题、结构不符合规范——所有组合都不及格，普遍只有 40 到 60 分。
但只要把这些「不性感的基建」补上去——上下文工程做好、架构约束理清楚、团队知识沉淀下来、技术债梳理掉——同样的模型和框架组合：
• 功能正确率：80% → 接近 90% • 工程质量：40~60 分 → 80 分左右
模型一个没换，框架一个没换，光补基建，分数就上去了。 这就是为什么我说模型早不是瓶颈。
那大家到底看错了什么方向
最容易看错的，就是盯着「AI 写了多少代码」这个数。
洪定坤举了字节 TRAE 团队的例子。TRAE 本身就是做 AI 工具的，对 AI Coding 用得最狠。过去半年，他们 94% 的代码都是 AI 贡献的。
按直觉，AI 写代码至少比人快 10 倍，94% 都是 AI 写的，人效怎么也得翻 5 倍、10 倍吧？
实际呢？人均需求吞吐率只提升了 60%，也就是 1.6 倍。
94% 的代码归 AI，人效才涨 1.6 倍。 这中间的落差去哪了？
答案很简单：写代码只是研发流程里的一环。写之前要理解需求、写 Spec，写完要验证、要提交发布。光把「写」这一步加速，前后环节还按老办法来，整体快不起来。
所以字节得出一个判断：单一指标——比如 AI 代码占比——根本代表不了真实生产力。 把它当 KPI，结果就是大家一起刷量，AI 看着用得多，系统效率没真变好。
现在还有不少公司在追踪员工到底用了多少 Token。说白了，这是在追过程。真正该追的是结果：用了这工具，交付有没有变快、变可靠？一个团队天天说自己 AI 用得贼溜、Token 烧了多少，但没有效产出，这到底是好事还是坏事？
洪定坤管字节的这套做法叫「系统化的 AI Development」——AI 不能只管写代码，得让它进更多研发环节，整条链路跑通，效率才真上来。
缺基建会怎样？一个真实场景
光说道理不痛，看个例子你就懂了。
产品经理有个需求，等研发排期等不及，说「那我自己来」，用 AI 三下五除二把功能写完了，丢给研发：「代码我写好了，你帮我上线就行。」
研发一看：不行。你这代码能跑，但有权限问题、有安全问题，不符合上线规范。
产品经理委屈：你们没空做，我自己做完了又不让上。
研发看到的是代码质量。
代码生成的门槛是降了，但这不代表系统复杂度也降了。 真实业务里，代码要塞进已有架构、要跟老模块配合，要管权限、安全、性能、兼容。不是谁写出来就能直接上线的。
这也就是为什么 Vibe Coding 那套「像聊天一样把需求说出来」的玩法，只适合小项目和验证想法。生产级软件，流程不是这样的。
所以，到底谁决定 AI Coding 能不能落地
行业里还在把 Harness 等同于 Agent 框架——用 single agent 还是 multi agent、有哪些角色、怎么配合。这些当然重要。
但字节在实践中发现，真正决定能不能落地的，是更基础、更工程化的东西——基建。 上下文工程做没做好、架构约束够不够清晰、知识能不能沉淀、技术债有没有梳理。
这些活儿一点不性感，但直接影响效果。
基建做不好，后果就是：Vibe Coding 看着快了，实际整体更慢。工程的债，迟早得还。
那明天该先补哪块
这次分享我最大的收获，是它把方向拨正了。过去一段时间确实有不少离谱言论——疯狂炫耀自己烧了多少 Token，就觉得自己是 AI Native。
但真要落地 AI Coding，别再盯着代码占比和 Token 了。先回头看看：你团队的上下文工程做了吗？架构约束写清楚了吗？过去的技术债梳理过吗？知识沉淀下来了吗？
先把这些补上，比换最新的模型管用得多。
强烈推荐去看原文，字节跳动的公众号就有。
原文：https://x.com/xiaogaifun/status/2070053162619466219作者：小盖 @xiaogaifun发布时间：2026-06-25
