AI 提效的陷阱：为什么「用得多」不等于「产出高」

AI 的使用量在过去一年持续攀升：更多预算、更多 token、更高频次的调用，几乎成了团队对外展示「价值」的标准证据。然而不少团队私下承认，AI 带来的实际产出并没有像使用曲线那样漂亮地跟上来。代码生成作为 AI 最早落地、阻力最低的场景，自然成了所有人伸手就够到的工具；问题在于，这条「最容易走的路」和「真正通往更快交付的路」并不是同一条路。

现象：用量飞涨，交付停滞

文章开篇就抛出一个反差：AI 用量曲线不断攀升，但真正「发货」的速度并未跟上。许多人把「更多 AI 使用」当作生产力提升的证明，却忽略了业务最关心的指标——有没有更短周期地把客户愿意买单的东西送出去。

作者回顾自己在 Mixpanel 的一段经历：团队花了数月打磨一个数据分析功能，几乎全程闭门造车，直到上线才发现方向跑偏。如果当时更早把粗糙、可被客户反应的版本推出去，结果可能完全不同。由此他得出一个朴素的结论：杠杆不是「更聪明」，而是「更多可学习的尝试」，是更紧的反馈循环。

根源：把「舒适的下坡」当成高效

代码生成之所以流行，不是因为人们深思熟虑后选择了它，而是因为「梯度」把它推到了所有人面前。键入即出、立刻见效的体验让人上瘾，于是团队开始主动寻找更多类似的工作：重构、工具搭建、一次性脚本、内部仪表盘……这些工作量大、看起来忙碌，但 ROI 往往很低，因为它们只是让人继续做「AI 已经变容易的那件事」。

文章特别强调：清理代码、重构旧项目并非毫无价值，前提是它真的在解锁交付能力，或是当季的硬目标。真正的陷阱在于「因为容易就去做，做完再贴上『高优先级』的标签」。代码编写从来只是多个瓶颈之一；移除它，瓶颈不会消失，只会迁移到代码审查、验证、上线和调试等更不舒适的位置。

解法：把 AI 指向下一个瓶颈

文中给出了一个相当具体的工程姿态：不要把 AI 当作逐行听指令的任务执行者，而应把它当作一个「非确定性黑盒」，只给定目标和验证方式，然后放手让它跑。更长的无人值守运行时间，意味着更高的杠杆。这背后需要一套基础设施：

• 自动化代码审查与回环
• 浏览器端测试与端到端验证脚本
• 自校正的 harness，让模型自己发现并修复错误

作者承认这条路并不舒适：AI 有时会写出低效代码，偶尔会引入 bug。这些成本可以接受，前提是验证体系足够扎实。验证不是「为了更快而跳过的步骤」，恰恰是让速度变得安全的装置。

工程师角色的转变

文章描绘了一类正在变化的工程师形象：他们不再沉浸在循环里逐句指挥 AI，而是设定目标、让代理自行推进；他们能更短地把客户需求转化为原型再推到生产；他们毫不犹豫地扔掉代码，因为代码从来不是重点，信号才是。当 AI 接管了「苦力」部分，剩下属于工程师的就只剩品味、对客户的理解、以及「什么值得做」的判断力——这部分 AI 帮不上忙，也正是最值得投入时间的部分。

核心问题：是否压缩了交付周期

文章最后给出一个简洁的自检标准：在动手使用 AI 之前，先问一句——这件事能否缩短我把可被客户验证的东西送出去的时间？如果是，就大力投入，构建循环与验证体系，让自己从循环中脱身；如果不是，就诚实面对：工作或许值得做，但它不在 ROI 的位置，无论感觉上多「高效」。

作者的结论颇具挑衅性：未来几年赢的不会是「用 AI 最多」的组织。AI 让「做更多」变成了最容易的事，真正的赢家是最快迭代、最愿意从舒适的下坡路爬向真正能发货、真正能学到东西的工作的那批人。