人工智能的生产力陷阱

在人工智能技术快速发展的今天，许多组织都在增加AI的使用量——更多的支出、更多的令牌消耗、更高的采用率，并将这些指标作为价值体现的证据。然而，这些组织却私下抱怨实际影响力并未达到预期。使用量上升了，但交付成果却没有同步增长。作者经过数周的思考，认为这背后有两个问题：多数人对AI的正确使用方式理解有误，即使他们知道更好的方法，也存在结构性的原因使他们偏离正确方向。

首先，我们要理解真正的任务是什么：交付客户愿意付费的东西。然而一个令人不安的事实是，大多数构建的项目最终都会失败。作者以自己在Mixpanel的经历为例：他花费数月打造了一个功能，允许客户将所有数据导入Mixpanel进行分析，但几乎完全没有在开发过程中接触客户。最终产品发布后反应冷淡。这次失败让他意识到，关键不在于变得更聪明，而在于增加可从中学习的尝试次数——不是同时向客户抛出大量东西，而是缩短迭代周期，快速将粗糙的早期版本交给客户反馈，保留有效的部分，丢弃无效的。

因此，AI的有效利用应当使这种迭代交付更快、更好、更安全。但大多数人的做法恰恰相反。代码生成是AI的第一个重大胜利，也是阻力最小的路径：输入提示，代码立即出现，大多能正常运行，这种即时满足感让人沉迷。于是人们不自觉地沿着这条路径前进，寻找更多能用AI快速完成的工作：构建更多功能、重构、工具、仪表板，以及各种一次性技能。然而，这种舒适的AI工作恰恰是低ROI的，因为它让你不断重复AI已轻易实现的事情。阻力最小的路径与加速交付的路径并不相同，尽管它们都让人感觉忙碌。

有时，重构或清理确实是当务之急，比如当它能解除交付瓶颈或符合本季度目标时。但真正的陷阱不是做非交付工作，而是因为容易而选择它，事后才称之为优先事项。编写代码只是众多瓶颈之一，移除它后，约束并未消失，而是转移到审查、验证、部署、调试等更麻烦的环节。真正的技能在于主动寻找下一个瓶颈，用AI解决它，然后继续前进。那些抱怨AI未带来预期收益的人，正是优化了下坡步骤，却手动处理后续所有环节，他们深陷在循环中而不自知。

要爬出陷阱，需要改变与工具的关系。不要像任务猴子一样逐条指令地指挥AI，而应将其视为一个非确定性的黑箱，设定目标并定义验证方式，然后让它自主运行。构建审查循环、浏览器测试、验证脚本和自我纠正机制。AI在需要你介入前运行的时间越长，你从中获得的收益就越大。当然，这需要适应：AI有时会写出低效代码，偶尔引入错误。但只要投资了捕捉这些问题的验证机制，代价是可控的。验证是让速度变得安全的关键，而不是为了快而跳过的步骤。

那些最充分利用AI的工程师与一年前已截然不同。他们设定目标，而非陷入循环；他们从客户需求到原型再到生产的周期比以前更短，并且毫不犹豫地丢弃代码，因为代码从来不是重点，反馈信号才是。如果AI负责执行，那么工程师剩下的不再是敲击键盘，而是品味、客户理解力以及判断什么值得构建。AI不了解你的客户，这是工作中没有变得更容易的部分，也是值得你投入时间的地方。

因此，在遇到任何问题时，先问自己一个问题：使用AI是否能压缩我交付一个可让客户做出反应的东西的时间？如果是，则大力投入，构建循环和验证，然后放手让它工作。如果否，则要诚实：这项工作可能值得做，但无论感觉多么高效，它都不是ROI所在。未来几年胜出的组织不是那些AI使用量最大的，因为AI让“做更多”变得容易。胜利属于迭代最快、愿意远离舒适的下坡工作、真正交付并从中学习的人。