Warp的创始人 Zach Lloyd：我们现在是工厂工程师，而不是产品工程师
这是我分享给 Warp 团队的一份备忘录，讲的是构建 Warp 这件事应该变成什么样。它结合了我从客户那里听到的反馈、我对未来开发形态的判断，以及 Warp 团队为了保持前沿需要做出的调整。
过去一年，我们已经从 AI 自动补全，转向了交互式编码智能体。接下来六个月，这个范式还会再次演进，进入自动化开发。
在自动化开发的世界里，工程师的工作不再是写代码。甚至也不是直接构建产品。工程师的工作，是构建一台内部机器——一座云端软件工厂——由这座工厂替他们构建产品。这座工厂的目标，是交付出色的产品；但工程师日常要做的，并不是直接去构建这个产品，而是构建那个“构建产品的东西”。
成功不再用某个工程师交付了多少功能来衡量；那反而是一种失败指标。成功要用所有变更中有多大比例是自动交付的，以及交付成本是多少来衡量。“自动”意味着智能体完成了所有工作：从分诊、编写规格说明，到实现、评审、验证和监控。如果某个变更目前还无法自动交付——现在很多都还做不到——那目标就应该是半自动化：即便人类仍需要介入代码评审，也要让智能体先承担分诊或验证等环节。让智能体尽可能多地做事。
每个工程师的工作，都是提升自己团队产品工厂的效率。工厂效率大致可以用这个公式衡量：
> 交付的产品 /（推理成本 + 人力时间成本）
公司将会用投资回报率来评估这些工厂的有效性：如果它们在自动化上投入一美元，业务是否能获得超过一美元的价值？当然，用“交付产品”来衡量价值并不完美，但眼下已经足够。
给所有工程师无限 token 预算、让他们随意花在交互式编码智能体上的时代正在结束。取而代之的是，公司会把软件生产视为一种可变成本，而不是研发开支。它会作为 COGS 出现在 P&L 上，因为公司会希望看到：在软件工厂上持续投入更多资源，边际收益到底是多少。
我写下这些，是因为这正是我们在 Warp 需要接受的心智模型。每位工程师都必须停止认为自己是在直接修改我们的代码库和产品，而是要从“如何改进我们的工厂”这个视角来看待一切。
当然，在我们构建和改进工厂的过程中，你仍然要对产品本身的改进负责——毕竟，我们交付的产品才是为客户和用户创造价值的东西。但每当我们的工厂失败时，我们都需要从失败中学习，并在下一次让自动化走得更远。随着时间推移，自动化比例会不断提高，直到我们的工作完全变成提升效率，而不是把车从生产线上拉下来、亲手把它造完。
这对 Warp 尤其重要，因为我们公司现在所处的就是“工厂业务”。我们正在运营一座工厂，用来改进我们的开源 Warp 终端；这个终端几乎有一百万开发者在依赖它不断变好。我们也在推出一个名为 Oz 的平台，帮助其他公司在自己最重要的产品上复制这种工作流。工厂业务将是唯一真正重要的软件生产力业务。如果我们要出售这种东西，就必须自己先接受它的精神。
需要改变什么：自动化命令
首先，我们必须衡量吞吐量和效率。我们必须非常严格地关注：我们有多少产品是自主交付的，以及交付它们花了多少成本。我们现在还没有做到这一点。眼下最重要的指标，是我们完成的全自动任务占比，以及完成这些任务的成本。
第二，我们必须强迫自己以自动化优先的方式处理一切。这意味着，每当我们使用交互式智能体，也就是人在回路的方式去写代码时，都应该把它视为一次需要从中学习的失败。对于每一项任务，我们都应该遵循工厂工作流，只有在必要的时候才把事情从工厂流水线上拿下来人工处理。现在我们会经常需要这样做，这没问题。但目标是让这种情况越来越少。
工厂工作流很简单：
1. 分诊智能体运行，尝试理解问题并复现问题。 如果它判断这个任务可以自动化，就交给实现智能体。 如果因为存在歧义或范围不清而需要规格说明，就让规格智能体来编写规格。 如果任务本身含糊不清，就获取人类输入后重新运行，或者暂时搁置这个问题。
2. 如有必要，规格智能体运行。 人类审查规格说明，然后将其交给实现智能体。
3. 实现智能体编写代码。
4. 代码评审智能体审查代码。
5. 验证智能体进行计算机操作式验证，或其他形式的验证。
6. 人类审查代码和验证输出。 如有必要，回到第 2、3、4 或 5 步。
8. CI / CD。
9. 发布。
10. 监控智能体运行，并在需要时创建问题，从而闭合整个循环。
这个工作流应该已经看起来很熟悉了——这正是我们为那个拥有 6 万 star 的开源仓库所构建的东西。你可以在 build.warp.dev 看到它的运行情况。我的看法是，它已经半能运转了，但我们还没有真正完全接受它。我看着 build.warp.dev 上有 1300 个 issue 处于 ready-to-implement 状态，就会想：“那我们还在等什么？让智能体去实现它们啊。”我们需要让它真正完全运转起来。
每当我们需要把人类带入流程中时，我们的平台 Oz 都需要记录这件事，并让我们的自我改进智能体尝试改进流程，从而降低下一次仍需人类介入的概率。同样，我们也需要让自我改进智能体分析工厂中的对话，寻找 token 浪费的模式，并提出效率提升建议。我们应该评估不同的执行框架和提示词，并记录哪些方案在下一次执行时效果最好。
我们作为 Warp 工程师的首要工作，是确保这套工作流顺畅运行，并确保 Oz 能为支持这套工作流提供尽可能好的体验。如果我们做对了，工厂最终会进入一种递归式自我改进的状态。这就是黄金路径。
这听起来也许像是在拥抱苦差事，或者像是一个理想主义但不现实的世界愿景；好像我们再也不能摆弄代码了，或者我们会把所有时间都花在评审智能体生成的低质量代码上。
但我不这么看。我认为，这是在解决软件工程中最后一个、也是最重要的问题——可以称之为元工程：也就是去工程化地构建一个系统，让编码智能体能够最有效地构建并交付有用的东西。
是的，短期内会有大量痛苦：智能体会失败，我们也必须审查它们生成的粗糙内容。但我们必须让自己经历这种痛苦，才能弄清楚如何把这种痛苦自动化掉。如果我们不这么做，别人就会这么做。
我们的使命一直都是赋能开发者，让他们更快地交付更好的软件。让他们每个人都能构建、管理和调优云端软件工厂，就是这个使命最终形态的产品。