代码 90% 都是 AI 写的，然后呢？

AI Coding / 组织生产力 / 真实交付

代码 90% 都是 AI 写的，然后呢？

AI 写代码很快，和团队交付变快，不是一回事。

林万劲的AI思考 / 2026.06 / 约 5000 字

今天看到一组特别拧巴的数据。

字节跳动 TRAE 团队，过去半年，超过 90% 的代码是 AI 写的。

然后，人均需求吞吐率提升了 60%。

你没看错。

90%。

60%。

我第一反应是，啊？

漂亮的数字告诉你 AI 已经来了，诚实的数字提醒你，真正的改造才刚开始。

不是哥们，代码都 90% 交给 AI 了，怎么效率才提升 60%？

这事儿最有意思的地方就在这里。

我们这一年聊 AI Coding，聊得最多的是什么，Claude Code 有多强，Codex 能不能自己改仓库，TRAE 能不能把需求一路写到 PR，哪个模型 SWE-bench 又涨了几分。

大家很容易被一种画面带着走。

一个需求丢进去，AI 哗哗写代码，一会儿文件改完了，一会儿测试跑过了，一会儿 PR 提了。

这种感觉太爽了。

爽到你会有一种错觉，软件工程好像马上就要被压缩成一句 Prompt。

但字节这组数据，给这件事泼了一盆挺有价值的冷水。

不是冷水，是冰镇酸梅汤。

醒脑。

01

漂亮的数字，和诚实的数字

洪定坤在火山引擎 FORCE 大会里讲到，过去一年，字节 AI 代码贡献率增长了 6 倍多，AI Coding 上的 token 消耗增长了 5 倍，代码合入率也增长了超过 2 倍。

单看这些数字，非常漂亮。

如果我是团队老板，看到这种 dashboard，估计嘴角都压不住。

但是他后面说的那个 90% 和 60%，才是整场分享里最值钱的地方。

因为它把一个特别残酷的问题摆到了台面上。

AI 写代码很快，和团队交付变快，不是一回事。

这句话听着有点刺耳，但我觉得它特别重要。

我们过去太容易把 AI Coding 理解成一件很局部的事情，代码是谁写的，写了多少，被采纳了多少，贡献率有多高。

这些指标当然有用。

但如果只盯着这些指标，就会出现一种很荒诞的场面，团队开始为了提高 AI 代码贡献率而提高 AI 代码贡献率。

今天多让 AI 写一点，明天多采纳一点，后天 dashboard 更好看一点。

然后呢？

需求有没有更快上线，线上问题有没有更少，返工有没有下降，Review 有没有变轻，产品和研发之间的沟通有没有更顺，没人问了。

这就像一个健身的人，天天盯着自己今天举了多少公斤铁。

铁是举起来了。

但跑两步还是喘。

那你练的是健康，还是练的是朋友圈截图？

AI Coding 也是一样。

代码贡献率是一个很容易让人兴奋的数字，因为它直观，性感，好传播。

但是软件工程最麻烦的地方，从来不只是写代码。

写代码只是冰山露出水面的那一点点。

水面下面是什么？

是需求理解，是老代码的上下文，是团队约定俗成的工程规范，是历史技术债，是异常处理，是组件复用，是不能把上个月刚修好的功能又干碎，是上线前那一堆很烦但必须做的验证。

这些东西，才是真正消耗团队生命的地方。

而 AI 最开始进入研发的时候，最容易做的事情，恰恰是绕开这些东西。

它特别会写。

但它不一定真的懂这个团队怎么活着。

02

写对了，不等于可交付

字节做了一个挺有意思的实验。

他们选了 3 个主流 Coding 模型，3 个主流 Agent 框架，用真实业务需求和相同 Prompt 两两组合，总共跑了 900 次。

这个实验很妙。

因为它不是问模型会不会写一个玩具 demo，而是问它能不能在真实业务里交付一个能上线的东西。

结果也挺扎心。

功能正确率看起来还不错，主流组合普遍能到 80% 以上。

但一看可交付性，就掉下来了。

很多结果只有 40 分到 60 分。

也就是说，AI 可能把功能写对了，但离真的能交付，还差一大截。

AI 能写出功能，但异常处理、组件复用和历史功能影响，才是上线门前的真实阻力。

有的异常处理不规范。

有的没有复用仓库里已有组件。

有的改动影响了历史功能。

有的实现方式不符合团队工程规范。

看到这里我真的有点绷不住。

因为这太像现实里的实习生了。

不是那种贬义的实习生，而是一个非常聪明、手速极快、学习能力很强，但刚进公司，对你们祖传代码、祖传规范、祖传锅都不了解的实习生。

你让他做一个功能，他可能真能做出来。

但他不知道这个组件三年前为什么写成这样。

他不知道这行看起来很丑的 if，其实挡过一次凌晨 3 点的线上事故。

他不知道你们团队有个不成文规定，某个接口不能这么调。

他更不知道，有些代码不是技术选择，是历史遗留，是组织记忆，是一群人被现实毒打之后留下来的疤。

AI 最大的问题不是不会写代码。

是它没有被你们这个组织毒打过。

所以它不知道什么地方疼。

这也是为什么洪定坤后面重点讲到了 Harness。

这个词这两年很火，很多人一说 Harness，就会想到 Agent 框架、工具调用、自动执行、Browser Use 之类的东西。

这些当然重要。

但字节这次讲的角度，我觉得更接近真实世界。

03

Harness 不是框架，是地基

他们说 Harness 更像基建。

上下文工程，架构约束，团队知识沉淀到 Memory 里，过去技术债的梳理，验证流程，工程规范，这些看起来不酷的东西，才决定 AI 能不能真的进入生产。

这话我非常认。

因为 Vibe Coding 最大的爽点，是让你感觉自己在飞。

但企业研发最需要的，不是飞。

Vibe Coding 看起来在地面上跑得很快，但真正让它稳住的，是下面那些不酷的基建。

是落地的时候别摔死。

更关键的是，当他们把这些 Harness 基建接进去之后，结果真的变了。

原来那些模型和框架组合，正确率大概从 80% 提升到接近 90%。

但更明显的是可交付性。

从之前 40 分到 60 分的不及格水平，提升到了 80 分左右。

这一下就很有说服力了。

因为它证明了一件事。

AI Coding 的天花板，不只在模型。

也在组织。

你组织里的上下文越清楚，规范越可复用，知识越能被机器读取，流程越能被自动验证，AI 就越像一个真正的团队成员。

反过来，如果一个团队自己都乱成一锅粥，文档没人写，规范没人守，测试没人补，需求天天靠吼，历史决策全靠老员工脑子里存着。

那 AI 进来以后，只会把这个混乱放大。

它不是来拯救混乱的。

它是来加速混乱的。

这可能是很多公司接下来会遇到的真实问题。

老板看到 AI Coding 很兴奋，觉得开发成本要下来了。

工程师看到 AI Coding 也很兴奋，觉得终于不用写那些重复代码了。

产品看到 AI Coding 更兴奋，觉得需求是不是可以明天就上。

大家都兴奋。

然后三个月后发现，代码量暴涨，Review 更累，线上问题更隐蔽，系统里多了一堆没人敢碰的 AI 生成代码。

一时间无语凝噎。

这不是 AI 不行。

是我们把写代码这件事，误认为是软件工程本身。

04

不是让高手更爽，是让组织长出神经

突然想到 1880 年代电力进入工厂的那段历史。

当时很多工厂主买了发电机和电动机，把蒸汽机换掉，觉得新时代来了。

结果一开始，效率提升并不明显。

为什么？

因为他们只是把动力源换了，但工厂布局、生产流程、管理方式，还是老样子。

真正吃到电力红利的，是后来那些重新设计工厂的人。

他们不只是把蒸汽机换成电动机。

他们围绕电，重新组织生产。

AI Coding 现在也有点像这个阶段。

一开始只是换马达，真正的变化，是围绕新的动力重新画工厂。

很多团队现在做的事情，是把人写代码，换成 AI 写代码。

但真正的变化，可能不是谁来敲键盘。

而是围绕 AI，重新组织软件生产。

这就是我觉得字节这次分享最值得写的地方。

它没有停在模型能力炫技上，而是在讲一个更底层的问题。

一个团队怎么让 AI 参与需求，参与 Spec，参与实现，参与浏览器验证，参与 Bugfix，参与提交，甚至参与发布。

一个产品原型怎么从静态页面，变成动态可交互的东西，让产品、设计、研发更早围着一个真实对象讨论。

一个组织怎么把少数高手的 Prompt 技巧、上下文管理能力、任务拆解方法，沉淀成所有人都能复用的标准、工具和技能。

这才是 AI Coding 真正难的部分。

不是让一个高手更爽。

是让一群普通人都变强一点。

真正的组织能力，是把藏在脑子里的规则、记忆和反馈，变成 AI 能调用的上下文。

很多朋友可能会觉得，这事儿离自己很远。

你不是程序员，不写代码，不管研发团队，听什么 AI Coding、Harness、TRAE，好像都是技术圈自嗨。

我非常理解这种感觉。

但我反而觉得，这件事离每个人都很近。

因为 AI 进入任何一个行业，都会经历类似的阶段。

一开始，大家都会盯着那个最显眼的动作。

写作者盯着 AI 写了多少字。

设计师盯着 AI 出了多少张图。

销售盯着 AI 生成了多少拜访纪要。

程序员盯着 AI 写了多少代码。

这些都是代码贡献率的变体。

它们都很容易统计，也很容易让人产生一种正在进步的错觉。

但真正的问题永远在后面。

这篇文章有没有真的打动读者。

这张图有没有真的解决沟通问题。

这份纪要有没有真的推动客户进入下一步。

这段代码有没有真的稳定上线。

产出，不等于交付。

生成，不等于完成。

05

真正拉开差距的笨功夫

AI 让产出变得太容易了，所以交付反而变成了更稀缺的能力。

说真的，这可能是未来几年最重要的分水岭。

一类人会沉迷于生成量。

今天生成 10 篇文章，明天生成 100 张图，后天生成 1000 行代码。

另一类人会开始搭自己的 Harness。

写作的人，会沉淀自己的选题标准、素材库、审稿规则、读者反馈机制。

设计的人，会沉淀自己的风格规范、组件资产、品牌约束、可复用提示词。

销售的人，会沉淀客户画像、跟进节奏、异议处理、复盘模板。

工程团队，会沉淀上下文、规范、测试、发布和责任链。

前者看起来很快。

后者一开始很笨。

但几个月之后，差距会非常大。

因为真正能放大的，不是你今天临时敲进去的那句 Prompt。

是你背后那套可复用的系统。

这也是为什么我看到 TRAE 日均 token 消耗 5.6 万亿，增长 50 倍的时候，第一反应不是，哇，好大的数字。

而是，接下来真正要看的，不是 token 还会涨多少。

而是这些 token，有多少变成了组织能力。

如果只是更多人让 AI 写更多代码，那当然也有价值。

但如果这些使用痕迹，能反过来沉淀成更好的流程、更清楚的上下文、更稳定的交付标准，那就完全是另一件事了。

那不是工具使用量增长。

那是组织在长出新的神经系统。

大时代啊，朋友们。

以前一个团队的能力，藏在少数老员工脑子里，藏在会议室的争吵里，藏在飞书群的聊天记录里，藏在某个没人敢删的老文档里。

AI 时代，这些东西如果不能被结构化，不能被调用，不能被验证，它们就很难变成生产力。

你会发现，AI 最后逼着大家补的课，不是技术课。

是组织课。

你有没有把话说清楚。

有没有把规则写下来。

有没有把经验沉淀出来。

有没有把验证链路搭起来。

有没有把成功和失败都变成下一次可复用的上下文。

这些东西以前也重要。

只是以前人可以靠默契、经验和加班硬扛。

现在 AI 一进来，所有模糊的地方都会变成成本。

所有没写下来的知识，都会变成模型不知道的坑。

所有没有验证的流程，都会变成随机性。

所以我现在越来越觉得，AI Coding 这件事，表面上是在改变程序员。

往深处看，它是在审计一个组织。

审计你的知识有没有沉淀。

审计你的流程有没有闭环。

审计你的指标是不是自欺欺人。

审计你到底是在追求更多代码，还是更好的交付。

这也是为什么 90% 和 60% 这两个数字，会让我一直想。

90% 是一个很漂亮的数字。

60% 是一个很诚实的数字。

漂亮的数字告诉你，AI 已经来了。

诚实的数字提醒你，真正的改造才刚开始。

别只问 AI 写了多少。

多问一句，写完之后，然后呢？

能不能被理解。

能不能被维护。

能不能被验证。

能不能上线。

出了问题，能不能找到责任和原因。

如果这些问题没有答案，那 AI 写得越快，可能只是让你更快地抵达混乱。

如果这些问题慢慢有了答案，那 AI Coding 才真的从玩具，变成生产力。

我自己也还在摸索，也不敢说已经想清楚了。

但至少这次字节这组数据，让我更确定了一件事。

AI 时代最值得投资的，不只是模型，不只是工具，也不是某个神奇 Prompt。

而是把自己的工作，整理成能被 AI 理解、参与、验证和复用的系统。

这个过程一开始一定很麻烦。

甚至可能比你自己手动做还慢。

但你相信我，这个笨功夫，可能才是接下来几年真正拉开差距的地方。

因为电力刚进工厂的时候，大家也只是换了个马达。

后来，整个工厂都变了。

AI Coding 也是一样。

一开始，我们只是让 AI 写代码。

后来，变的会是整个软件工程。

以及，所有人的工作方式。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

林万劲的AI思考

不是抢先知道更多，而是更早看清真正重要的变化