早上九点，我打开电脑，同时启动了三个 AI 任务：让 Claude 审查昨天提交的代码、让 Codex 生成单元测试、让另一个 Agent 整理技术方案文档。一个小时后，三件事都有了初步产出。
要是在两年前，这三件事需要一整个上午，甚至更久。
效率确实提高了。但我发现一个有意思的事情：当我放下 AI 产出物，开始做真正重要的决策——这个架构该不该拆、这个技术路线要不要换、这段代码的设计到底对不对——AI 完全帮不上忙。
这不是 AI 不够好的问题。这是工程效率的本质。
核心判断
我对 AI 时代工程效率的判断很简单：
本质上只有两件事发生了绝对的变化：
- 代码编写耗时——AI 直接生成代码，写代码本身变快了
- 单人任务从串行到并发——一个人可以同时跑多条线，像小团队一样运转
其他方面，还得靠人的品味。
OpenAI 的报告印证了什么
OpenAI 最近发了一份报告叫《The Next Era of Knowledge Work》，讲的是 Codex 如何改变人们处理复杂工作的方式。有几个数据值得关注：
- 每周超过 500 万活跃用户
- 约 50% 的用户同时运行多个 AI 任务——从串行变成了并行
- 72% 的用户在生产文档和素材，46% 在写代码
这组数据说明什么？产品经理自己搭数据看板，研究员自己写数据清洗脚本，设计师自己把原型交付上线。岗位边界在模糊，一个人可以像小团队一样运转。
报告用了一个好类比：电力刚出现时，工厂只是把蒸汽机换成了电动机，车间布局没变，效率提升有限。直到后来彻底重新设计布局，把小型电动机放到每台机器旁边，生产力才真正爆发。
AI 对工程工作的改变是同一个逻辑——不是替代某个工具，而是把 AI 放到每个问题旁边。
但 AI 改变的边界在哪里
一个工程师的日常，写代码大概只占两三成时间。剩下的在做什么？
- 理解需求——搞清楚老板到底想要什么
- 架构设计——在三种技术路线里选一个
- 代码审查——判断这段代码该不该这么写
- 沟通协调——说服隔壁团队配合你
- 技术选型——在十个开源方案里挑一个
AI 能加速其中哪些？
写代码——能。 AI 生成代码的速度确实比人手快几倍。我在 Claude Code 自动修正生成代码的原理解析 中分析过，AI 代码助手已经能通过反馈循环实现自我修正，生成可用的代码已经不是瓶颈。
同时跑多个任务——能。 你可以一边让 AI 写测试，一边让它整理文档，一边让它跑数据分析。你从执行者变成了调度者。
架构决策——不能。 三种技术路线选哪个，取决于你对业务、团队、未来的判断。AI 可以列出 pros and cons，但做决定的是你。
代码审查的深层判断——不能。 AI 能发现语法错误和常见 bug，但「这个抽象层次对不对」「这个耦合是否合理」需要你来判断。
需求理解——不能。 搞清楚需求方真正想要什么（而不是他们嘴上说的），这是人际洞察，不是信息处理。
本质上，AI 改变的是 执行层 的吞吐量，不改变 判断层 的质量。
品味是 AI 无法替代的竞争力
我越来越相信一件事：在 AI 时代，工程师最稀缺的能力是品味。
品味不是审美，是 在多种可能性中做出判断的能力：
- 什么时候该用微服务，什么时候单体更好
- 什么时候该追求性能极致，什么时候够用就行
- 什么时候技术债必须立刻还，什么时候可以拖一拖
- 什么时候需求该拒绝，什么时候该妥协
这些判断没有正确答案，只有上下文相关的答案。同样的选择，团队 3 个人和 30 个人时完全不同。业务初期和成熟期的权衡也不同。
AI 可以在几秒内生成 10 个技术方案，但 选哪个 才是真正值钱的能力。
一个真实的例子
我在实际工程中遇到过：AI 代码审查能准确找出空指针异常、SQL 注入、性能瓶颈——这些是技术层面的问题。但当涉及「这个模块的抽象层次是否和业务模型匹配」时，AI 完全没有判断力。
有一次，AI 建议我们把一个同步调用改成异步消息队列，理由是「提高系统吞吐量」。从纯技术角度，这个建议完全正确。但我们团队只有三个人，引入消息队列意味着运维复杂度直接翻倍。在这个上下文里，「正确」的方案恰恰是最坏的方案。
判断一个方案好不好，和判断这个方案适不适合你，是两种完全不同的能力。
并发的诱惑
报告提到 50% 的用户同时运行多个 AI 任务，这个数字让我既兴奋又警惕。
兴奋是因为这确实是个突破。以前一个人一次只能做一件事，现在可以同时推进三条线——你变成了工作流的调度者。
警惕是因为 并发容易制造一种虚假的效率感。
同时跑三个 AI 任务，每个任务都产出了东西，你会觉得「我今天效率好高」。但这些产出物的质量如何？方向对不对？相互之间有没有冲突？这些判断仍然需要你一件一件地做，而且需要深度思考。
并行的执行，串行的判断。这是 AI 时代工程师的真实状态。
生产力悖论的幽灵
报告引用了经济学家索洛在上世纪 80 年代注意到的「生产力悖论」——电脑进了办公室，生产力统计却迟迟不涨。布林约尔松的解释是：信息技术只有在组织重新设计流程之后，才能带来真正的大幅提升。
这个悖论在个人层面同样成立。
AI 让写代码变便宜了，结果是什么？代码量暴增。但消化这些代码需要的架构判断力，并没有变便宜。这和 压缩即智能 的视角一致——当信息爆炸时，真正稀缺的不是生产能力，而是压缩和判断的能力。
邮件让通信变便宜，通信量暴增。文档协作变便宜，草稿和审阅轮次暴增。AI 让代码变便宜，代码量也会暴增。
工具降低了生产中间产物的成本，但没有减少消化这些产物所需的注意力。
所以呢
如果 AI 只能加速执行层，那我们应该把省出来的时间投到哪里？
我的答案是 判断层。
- 更多的 code review，不是让 AI review 更多代码，而是 你 review AI 产出的代码
- 更深入的技术调研，不是让 AI 调研更多方案，而是 你 判断哪个方案适合你的上下文
- 更多的架构讨论，不是让 AI 画更多架构图，而是 你 和团队讨论架构取舍
省出来的时间应该用来提升品味，而不是用来接更多任务。
但人性恰恰相反——我们倾向于用省出来的时间做更多的事，而不是做更深的事。AI 加速了执行层，我们就开始接更多任务，同时跑更多线，每条线都更快地出代码出文档，但花在判断上的时间反而更少了。
这才是 AI 时代工程效率的真正风险。不是 AI 做不好执行，而是我们会被加速的执行层推着走，在判断层上越来越敷衍。
跑得越快，越需要在关键路口停下来想。高速跑在错误方向上，只会更快地到达错误的终点。
你在实际工程中使用 AI 的感受是什么？哪些事情真的变快了，哪些事情其实没变？欢迎留言讨论。