最近读到Charles Lamanna的一篇文章《Changing how we build》。

Charles是我所在部门的执行副总裁，目前负责微软Copilot、Agents与Platform相关业务。

他从微软内部的产品实践出发，讨论了一个我最近也反复感受到的变化：AI正在显著提高编码效率，但软件开发并不会因此自动变快。

过去，软件开发最明显的瓶颈之一是编码。

需求已经有了，方案大致清楚，但工程师数量有限，代码写不完，缺陷修不完，测试和维护也需要时间。

现在，Agentic Coding正在快速提高这一环的生产力。工程师不再需要亲手写下每一行代码，而是可以让AI完成大量实现、测试、修改和重复劳动。

从系统角度看，这只是加速了完整链路中的一个环节。编码不再是主要约束以后，决定什么最重要、如何设计系统，以及怎样验证最终产物，反而更容易成为新的瓶颈。

这篇文章给了我一个思考起点，但我真正想讨论的是另一个问题：

当AI释放了生产力以后，为什么我们未必会变得更轻松？

AI让我们终于有能力把事情真正做完

最近一段时间，我让不同的AI Agent承担代码审查、信息跟进、调查分析和一些固定任务。

以前需要排队处理的事情，现在可以并行推进；以前要花很长时间调查、实现和验证的问题，现在也能更快得到结果。

实话说，生产力确实提高了。

但我现在越来越觉得，AI释放出来的产能，最重要的用途未必是做更多新功能，而是让我们终于有时间和精力，把工程真正做好。

过去在紧张的项目里，很多时候只能先解决最紧急的问题。

系统已经亮起红灯，我们先止血、控制影响、让服务恢复，把红灯变成黄灯，就已经很不容易了。

但黄灯不等于问题真正解决。

临时方案有没有清理，根因有没有消除，测试和监控有没有补齐，同类问题会不会再次发生，后续维护者是否理解发生过什么——这些善后工作，常常只能被留到“以后”。

这并不是工程师不想把事情做好，而是在有限时间和紧急压力下，对产能做出的现实分配。先把问题从红灯变成黄灯，往往比追求一次做到100分更重要。

现在AI降低了调查、编码、测试和重复劳动的成本，我们理应有更多机会继续向前一步：

• 不只是缓解症状，而是解决根因；
• 不只是让系统恢复，而是补上测试和监控；
• 不只是留下临时绕行，而是完成清理和重构；
• 不只是关闭当前问题，而是降低同类问题再次发生的概率。

这里说的100分，不是无限打磨，也不是追求完美主义，而是达到一个清晰的完成标准：问题解决了，风险收住了，善后完成了，结果也经过验证。

从这个角度看，善后本来就是一种真实需求，只是过去经常被有限的生产力压住。

AI最有价值的地方，或许不是让我们把更多事情从红灯变成黄灯，而是终于有余力把黄灯真正变成绿灯。

系统能快多少，取决于下一个瓶颈

软件从想法变成用户价值，需要经过一条完整链路：

发现需求 → 定义问题 → 设计方案 → 编码实现 → 测试验证 → 发布部署 → 用户采用 → 收集反馈

过去，编码实现可能是其中最慢的一环。

AI把这一环加速以后，整个系统不会自动获得同等幅度的提升。生产力能继续向前推进多少，取决于下一处最慢的环节在哪里。

它可能是：

假如AI每天可以生成100个代码修改，而团队每天只能可靠评审10个，系统生产力并没有提高十倍。

剩下的90个修改只会变成在制品，继续等待评审、测试和合并。队列越长，沟通和切换成本越高，最终交付周期反而可能变长。

这就是系统思考里很重要的一点：

局部环节的效率，不等于整个系统的吞吐量。

最危险的做法，是立刻把产能重新填满

生产力突然提高以后，最自然的反应是做更多事情。

文中有个很有代表性的团队案例：有了AI以后，他们没有把原来交付5个功能的目标膨胀成500个，而是仍然交付大致相同数量的功能，把释放出来的大部分工程能力投入质量、可靠性、性能和安全。

结果是，在产品使用量增长的同时，支持请求同比下降了双位数百分比，因为团队能够比过去更快地修复更多缺陷。

这个选择很值得思考。

AI释放出来的产能，可以有两种去向：

• 用来接收更多需求，持续增加功能和系统复杂度；
• 用来解决根因、完成善后、偿还技术债，完善测试、监控、性能和用户体验。

第一条路更容易制造“生产力很高”的感觉，因为功能数量、代码行数和任务完成量都会快速上升。

第二条路不一定热闹，但它可能真正提高系统的长期吞吐量。

如果每次效率提升，都立刻被更多需求填满，我们只会得到一个速度更快、在制品更多、复杂度更高的系统。

原来只能做到60至80分的工程，仍然没有机会补到真正完成；原来从红灯变成黄灯的问题，也会长期停留在黄灯。

人也不会因此更轻松，只会以更快的速度处理更多事情。

不要为了使用AI而使用AI

当组织开始推广AI时，很容易把AI使用本身变成目标。

生成了多少行代码、调用了多少次AI、消耗了多少Token、多少人每天使用，这些指标并不先进。它们只能说明AI被使用了，不能说明AI创造了价值。

这些使用量数据可以帮助我们观察采用情况、计算成本或者发现使用障碍，但不应该成为AI是否成功的最终标准。否则，团队很容易为了证明自己正在使用AI而使用AI，甚至生成更多原本并不需要的代码和内容。

AI是手段。真正需要衡量的，仍然是那些本来就存在、也本来就重要的结果：

• 产品是否更可靠；
• 用户体验是否改善；
• 从需求到上线的周期是否缩短；
• 故障和返工是否减少；
• 问题是否从临时缓解走向根因解决；
• 收入、成本和利润是否发生变化；
• 团队是否能用更少的协调完成同样甚至更好的结果。

简单来说：

不要为了证明我们正在使用AI，而创造一套AI指标。真正的生产力，不是单位时间生成了多少东西，而是AI有没有改善那些原本就重要的结果。

AI让输出变得很便宜以后，这种区分会更加重要。

对个人来说，新的瓶颈可能是注意力

这个问题不只存在于软件团队。

当AI能够帮一个人同时推进更多事情时，个人工作系统也会发生瓶颈迁移。

过去的瓶颈可能是执行能力：很多事情知道应该做，但没有时间亲手完成。

现在，执行能力扩大以后，新的瓶颈可能变成：

• 是否知道什么最重要；
• 是否能拒绝低价值需求；
• 是否能给Agent提供清楚的目标和验收标准；
• 是否有时间检查越来越多的AI产出；
• 是否能保护自己的注意力，不被所有新发现的问题拉走。

这也是我最近越来越有感触的一点。

AI让我有能力关注更多事情，但“有能力做”不等于“应该由我做”。

如果每个Agent发现的问题都立刻进入我的待办清单，每一次节省下来的时间都被新的任务填满，那么我得到的不是自由，而是一个吞吐量更高的忙碌系统。

所以，使用AI以后，优先级管理反而比过去更重要。

真正稀缺的资源，正在从“我能不能完成这件事”，转向：

这件事是否值得消耗我和整个系统的产能。

每次提效以后，都问三个问题

AI还会继续提高编码、分析和执行的效率。

每当一个环节明显提速，我觉得都应该停下来问三个问题：

AI不会让瓶颈从此消失。

它会不断把瓶颈推向更需要人类判断、更接近系统目标的地方。

这其实是一件好事。

过去我们把大量时间花在实现和重复劳动上；未来，我们可以把更多时间花在选择正确的问题、设计更好的系统，以及判断结果是否真正有价值。

当然，前提是我们没有急着用更多需求，把刚刚释放出来的生产力重新填满，而是愿意把那些长期停留在黄灯的问题真正做完。

共勉。