从云优先到AI优先：生产力最大化还是Token最大化？

想象一家2016年的公司。一位工程师站在会议室里，试图说服CTO和CIO把一个应用迁到云上。这位工程师准备了演示、成本估算，以及上一次会议上提出的那些问题的答案。之前已经开过好几次会了。

CIO问数据会存放在哪里。CTO问团队如何从故障中恢复。财务指出楼下的服务器已经付过钱了。工程师解释说，等待数周才能拿到容量也是有成本的，尤其是团队想先试个小东西、却不得不申请一大笔资源的时候。

所有人都希望公司变得更好。他们分歧在于哪种风险值得承担。我想跟着这位工程师走一段，因为下一场转型会把他放到一个不舒服的位置上。十年后，他会成为提问的那个人。

先在那间会议室里待一会儿。工程师相信云能帮团队更轻松地交付。他能想象出这样的画面：有人需要时开发环境就出现，做实验不需要采购硬件，在真正有用的工作开始之前花在协调基础设施上的时间更少。

高管们能想象出的画面则是：一个敏感应用跑在他们无法控制的地方。他们的问题迫使工程师把访问、恢复、成本和对供应商的依赖想清楚。方案因为工程师不得不解释团队将如何真正承受这个决定而变得更好。

最终，在我们假想的公司里，他们同意先从一个应用开始。这给了团队足够的空间去学习，又不至于让整个业务都成为实验的一部分。

迁移过程中仍然有尴尬的时刻。某个部署假设不成立了。有人发现了一笔意料之外的费用。某个在机房里说得通的流程需要改。当初想推动迁移的那位工程师，正好可以帮忙把这些一一修好。

在我看来，这是一笔挺划算的交易。热情为你赢得尝试的机会。对后续结果负责，为你赢得下一次机会。

Gregor Hohpe写过，在回报值得的时候，接受一定程度的锁定是可以的。我喜欢这个决定所邀请的思考方式：弄清楚你能得到什么，理解改变主意要付出什么代价，然后两者兼顾地做出选择。我们这位工程师的云提案需要的就是这种判断力。

随着团队不断学习，新的工作方式变得熟悉起来。人们不再把云当作一个抽象立场来争论，而是开始讨论他们需要运维的那个应用。会议室里充斥着别的争论。

现在把同一家公司快进十年。这位工程师经验更丰富了，要照看的代码库更大了，还积攒了一堆他宁愿永远不要再发生的事故。CEO召集了一个关于AI的会议。

这一次，高管们已经信了。CEO想要一份给董事会的AI战略。CTO想让工程师用上编码agent。CIO已经开始审查供应商了，尽管有几个部门已经很贴心地抢先一步直接采购了。

我们的工程师带着问题到场。我们想改进的是哪些工作？这些工具能看到哪些数据？谁来审查这些改动？如果团队产出代码的速度超过了他们理解代码的速度，会发生什么？

这些问题听起来很熟悉。怀疑换到了桌子对面。

我认为这种转变解释了围绕AI采纳的部分紧张气氛。高管听到工程师提出担忧，会想不通团队为什么抗拒一个加速的机会。工程师听到高管宣布一个生产力目标，会想这又给下个季度加了多少清理工作。

双方都有合理的动机。看着竞争对手行动的CEO，必须在不确定中做决定。对应用负责的工程师，必须考虑宣布之后会有什么后果。每一方都能看到对方可能低估的某种成本。

而且，愿意为这项工作出钱确实是件好事。我们的工程师当年花了好几个月才拿到云实验的许可。现在实验还没设计，预算就已经到位了。我想好好利用这个变化。

不过首先，得有人解释清楚公司打算拿这些工具做什么。采购部门这个季度业绩很棒。工程部门也想有一个。

CTO描述了一个更宏大的可能性。一个agent接下一个任务，探索代码库，准备改动，跑测试，然后带回来供审查。随着时间推移，这条路径上越来越多的环节会实现自动化。团队可以承接那些总是输给下一个功能需求的维护工作。

Eno Reyes发过一条X帖子，讲软件如何通过用户反馈改进，以及如何把组织里那些不成文的知识变成系统运作方式的一部分。这给了我们的工程师一些更值得思考的东西：团队会从每一项工作中得到什么，这些收获又如何帮助下一项工作？

我们的工程师感兴趣了。积压里有没人愿意手工做的迁移。有团队一直想补的测试。有一些老模块，新员工要花太长时间才能看懂。一个能帮忙做这些事的工厂，很快就能证明自己的价值。

然后CTO建议先拿一个小工单试试：给支付流程加上重试。工程师问，如果支付成功了但响应丢了会怎样。重试会不会再向客户收一次钱？

这下会议室里有了一个具体问题可以讨论。得有人确定系统如何识别一笔已经处理过的交易。得有人决定结果不确定时客户看到什么。agent可以帮忙找到相关代码、调查实际行为。团队仍然需要就自己做出的承诺达成一致。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）