AI效率提升10倍，为何你的下班时间仍未提前？

近一年来，我在与AI合作的过程中，始终在关注一个现象：模型运行日益迅捷，但我们的工作节奏真的同步加快了吗？

起初，我主要在意模型能否完成任务。

它能否编写程序，能否解析一份文件，能否根据一段指令实现某个目标。

这几年，每当看到模型将原本耗时数小时的工作缩短至几分钟，我依然会感到振奋。亲眼见证某些能力从“偶尔亮眼”进化为“基本可靠”，是这个领域最令人沉醉的环节。

但随着大模型应用实践的深入，我越来越重视另一个疑问：

近期看到字节跳动技术副总裁洪定坤在2026年火山引擎FORCE原动力大会上的演讲，这个疑问再次被推到聚光灯下。

他公布了一组颇具震撼性的数字：过去半年，TRAE团队超过90%的代码由AI生成；同时，人均需求处理效率提升了60%，达到原先的1.6倍。

此处需要先厘清统计标准。

根据演讲披露的内部标准，超过90%指的是TRAE代码中AI编写的占比；提升60%则指人均需求吞吐量的增幅。公开信息未说明这两项指标的详细计算方法。它们并非同一衡量尺度，不能简单相减。

这组数据吸引我，不仅因为“90%”足够抢眼，更因为它首次用两个数字，将我在大模型应用中反复遭遇的落差直观呈现：生成已经极快，交付依然繁重。

即便依据洪定坤在演讲中“AI写代码至少比人快10倍”的估算，为何完整的需求交付未能同步提速10倍？

我的看法是：AI最先提速的是“生成”，而实际工作考验的是“交付”。

若未曾参与完整的软件开发，很容易将写代码视为程序员的核心任务。

但一个需求从提出到上线，通常还需经历：

AI能迅速让某个功能“启动运行”。

然而“能运行”与“能上线”并非同一概念。犹如一辆车能点火，不代表它已可安全行驶；刹车、转向、碰撞防护及后续维护，同样决定它是否为一辆真正可用的车。

这也是我从事大模型应用时日益深刻的体会。

模型生成一段结果，往往已非常迅速。真正耗时的，开始转变为为其准备恰当的上下文、核查它是否跨越业务界限、检验结果是否稳定，以及出现问题后能否定位和撤回。

从工程视角看，快速产出答案与稳定交付成果，是两个不同的目标。

前者更多依赖模型能力与输入品质；后者还取决于模型之外的整套体系。

洪定坤在演讲中还分享了一项内部实验。

字节选取了一个中等复杂度、即将上线的真实功能，让3个主流Coding模型与3个主流Agent框架两两组合，围绕同一需求反复运行，共测试了900次。

若仅看“基本功能是否准确”，各组合的准确率都超过了80%。

这个成绩已相当不错。

但当评价标准增加UI易用性、交互、可靠性、可维护性、性能和兼容性后，结果显著下滑。代码可能能运行，却未复用现有组件；可能完成了当前功能，却干扰了历史功能；也可能忽视异常处理和团队的工程规范。

后来，团队加入了自身的Harness工程基建。在这项实验中，它主要包括项目上下文、架构约束、团队知识积累和对历史技术债务的梳理。

融入这些能力后，基本准确率从超过80%提升至接近90%，更关键的可交付性评分，则从约40～60分提升到80分左右。

这组数据源自企业内部披露，并非独立的同行评审研究，也未公开完整原始数据。它无法代表所有团队。

但它揭示的方向，我非常赞同：

所谓工程化治理，并非给AI增添一堆形式上的条规。

在我看来，它更似为一辆日益加速的车修筑道路、护栏和交通规则：让模型获取正确信息，遵循既有架构；在更完整的研发流程中，再衔接测试、验证、发布和故障应对，使其在出错时能停下、溯源、回退。

模型决定了速度上限，工程系统决定了这份速度能否稳定兑现。

代码只是一个易于量化的示例。

在文档、数据分析、写作和日常办公中，我看到的是同一规律：任务越贴近真实交付，生成速度越不能代表整体效率。

例如，让AI为一场活动构思20个主题，十分适宜。结果好坏，人扫一眼即可判断，选错一个的代价也很低。

但若要从一份文档中逐字提取金额和条款，且要求结果与原文一字不差，就不适合仅交由大模型。

这类任务的目标不是“写得通顺”，而是“一字无误”。更稳妥的方式，是先用适合逐字提取的工具读取内容，再与原文逐项比对；AI负责分类和处理难以判断的部分，而非独自承担“一字无误”的任务。重要结果仍需保留人工抽查。

类似地：

我现在判断一项任务是否适宜交给AI，通常不会只问“模型会不会做”，而会再问四件事：

这四个问题，比“提示词应如何编写”更贴近真实的AI应用。

我并不认为人均需求吞吐提升60%是一个低数字。对于一个真实研发团队而言，1.6倍已是极为显著的效率变化。

问题在于，效率提升后，节省的时间通常会流向三个方向：做更多事务、将事务做得更优，或留给人自身。

在多数工作系统中，前两个去向会自然发生。

代码写得更快，就会多做一个版本、多验证一种方案、将原先排不上队的需求提前。过去因成本过高而放弃的事务，也会重新进入队列。

于是，AI确实提高了产出，人却未必因此更早下班。

这未必是坏事。许多新增的测试、验证和迭代，本就具有价值。

但若我们只统计AI写了多少代码、生成了多少文档、调用了多少次模型，就易将“使用得更多”误认为“生产力更高”。

真正值得衡量的，应是需求出现到可信结果交付的总时长，是质量有无提升、返工有无减少、故障能否控制，以及人是否因此获得了更佳的工作方式。

上一篇文章里，我写道：从2026年开始，一些面向企业的任务终于跨越了“可用”的及格线。

写完后，我一直在思索：“可用”之后呢？

刚转向大模型算法时，我最常问的是：哪个模型更强？准确率还能提升多少？

现在，我会多问几句：它出错时，我们能否及时察觉？结果能否验证？这次积累的规则和经验，下次能否直接复用？

这些问题没有模型榜单那般吸引目光，却日益决定AI到底是在替我们省事，还是在制造新的返工。

这并非因为模型不再重要。恰恰相反，是因模型终于足够强大，强到我们必须认真设计它将融入怎样的工作系统。

我仍对这场变革保持乐观。AI带来的效率是真实的，只是更优的工作方式不会自动浮现。它需要我们将“生成得更快”，逐步转变为“交付得更稳”。

最后也想请你一同审视自己的工作或学习：