写在前面：这不是我的原创观察，是一篇研读。原始分享来自字节跳动技术副总裁洪定坤关于 AI Coding 的演讲，我读的是公众号「小盖fun」的整理稿。下面保留他给的数据和例子，夹带一些我自己的体感；想看原话去找演讲全文。
字节在 AI Coding 上的实践挺有代表性，做研发的大概率会有共鸣。洪定坤这次讲的三点，我觉得更像字节的一次真实反思，甚至有点「拨乱反正」的意思——因为过去一年，「我用了多少 Token」「我 90% 代码是 AI 写的」这类话说得太多了。
反思一：AI 代码贡献率不该当 KPI
先看一组把人拉回地面的数字。TRAE 团队自己就是做 AI 工具的，用 AI Coding 最积极，过去半年 94% 的代码由 AI 贡献——但人均需求吞吐率只涨了 60%，也就是 1.6 倍。
这就别扭了。AI 写代码起码是人的十倍速，九成代码都它写的，效率不该翻五倍十倍吗？为什么只有 1.6 倍？
字节的结论是：单一指标（比如 AI 代码占比）代表不了真实生产力。你把它当 KPI，大家就会去冲 AI 的生成量，而不是冲交付能力——看着 AI 用得很猛，系统效率其实没变好。
原因也不玄：写代码只是研发链条里的一环。写之前要理解需求、写 Spec，写完要验证、提交、发布。这些环节还用老办法，只把「写」加速了，整体自然提不上来。洪定坤把字节的方向叫系统化的 AI Development——让 AI 进到更多环节，整条链路跑通，效率才真上得来。
我的体感：现在还有不少团队在盯员工烧了多少 Token，这是在盯过程。该盯的是结果——用了工具之后，交付到底有没有更快、更可靠。一个团队天天说自己 AI 玩得溜、Token 消耗惊人，却没什么有效产出，这算好事还是坏事？值得每个管理者想想。
反思二：功能正确 ≠ 工程可用
Vibe Coding 的理想态是：像聊天一样用自然语言提需求，做出想要的产品，哪里不对再用自然语言让它改。做小项目、验证想法，这套完全够用，我自己不少小东西就是这么跑出来的。
但只要做生产级软件，无论公司大小，流程都不长这样。因为公司里必然有老代码、有一套约束：怎么复用已有组件，安全权限怎么办，性能怎么保证，还有兼容性、可维护性。写过工程代码的人都清楚，理想态更适合小项目。
字节做了个实验验证：3 个模型 × 3 个 Agent 框架 = 9 种组合，同一个需求每组跑 100 次，共 900 次。结果是——功能正确率所有组合都过 80%，把功能写对这件事，AI 已经过了及格线；但工程质量普遍不行：UI 不对、不复用组件、性能有问题、结构不合规范。这些坑用 AI 写过代码的都踩过。
洪定坤有个判断我很认同：上牌桌的 Coding 模型都过了 Opus 4.6 那个临界点，能自主写代码了，这时候决定成败的不是裸模型，是裸模型加 Harness。
最触动我的是字节对 Harness 的理解。行业还习惯把 Harness 等同于 Agent 框架——single agent 还是 multi agent、有哪些角色、怎么配合。这些当然重要，但字节发现，真正决定能不能落地的是更基础、更工程化的东西，洪定坤叫它基建：上下文工程做没做好、架构约束清不清晰、团队知识能不能沉淀、技术债有没有梳理清楚。
数据也撑得住：同样的模型和框架，把基建结合进去后，功能正确率从 80% 提到接近 90%，工程质量得分从 40–60 分的不及格，普遍提到 80 分左右。基建做不好，Vibe Coding 感觉快了，整体可能更慢——工程的债，迟早得还。
反思三：代码门槛降了，团队怎么协同
分享里有个例子我印象很深。产品经理有个需求，等不及研发排期，干脆自己用 AI 三下五除二实现了——功能不复杂。做完把代码丢给研发：我写完了，你帮忙上线就行。研发一看：不行，能跑，但不符合上线规范，有权限、安全问题。产品经理很委屈：你们没空做，我做完了又不让上。研发看到的却是代码质量。
这里有件所有人都得正视的事：代码的生成门槛降了，系统的复杂度没降。真实业务系统里，代码要放进已有架构、跟已有模块配合、考虑一堆问题，不是谁写出来就能直接上线。
所以下一道题是：怎么让不同角色用同一套工具和规范，做出符合要求的代码。字节的思路是工具化——把内部实践直接产品化，沉淀进 TRAE，开放给所有人。
我读完的一句话
这次分享值钱的地方，不在于又秀了多少 AI 战绩，而在于把话说回了地面：Token 消耗、代码占比都是过程指标，交付才是结果。门槛降了不等于复杂度降了，基建和协同才是硬骨头。做研发的看完，大概会点头。
信息来源
一手 / 外部资料
- 原始分享：字节跳动技术副总裁 洪定坤关于 AI Coding 的演讲（TRAE 数据、900 次实验、Harness 与基建等判断均出自该分享）。
- 整理来源：公众号 小盖fun（本篇据其整理稿研读，数据与例子以原分享/整理稿为准，未逐一独立核验）。
站内交叉（同主题延伸阅读）
- Vibe Coding 真香也真险：一次幻觉漂移，足以吃掉全部效率红利 —— 本篇「功能正确≠工程可用」的另一面：Vibe Coding 的效率红利怎么被工程质量吃掉。
- 多 Agent 框架横向对比调研 —— 对照「Harness ≠ Agent 框架」这个判断，看框架层到底解决什么、不解决什么。
- 轻量化技术创业中的自害型技术债 —— 「工程的债迟早得还」的具体案例。
- 豆包手机 App 技术架构调研：一次 LLM 原生应用的分层猜想 —— 同样从字节视角看 AI 工程化的另一条线。
Discussion
讨论
还没有讨论