先构建，再对齐

在智能体出现之前的世界里，团队在开始写代码前就构建什么达成一致，确实至关重要。构建错误东西的成本很高，因为编码最耗费时间和金钱。所以在开始编码之前，你希望每个人都达成共识。具体来说，你希望负责编码的人、设计师、产品经理、资深工程师、领导层等各方之间保持一致。

在当今世界，如果你在构建之前花大量时间开会、写文档、在Slack上讨论，那你就做错了。

让我来解释原因。

你经历对齐过程有两个原因：第一，尽量在第一次就构建出最好的东西；第二，避免出现某个利益相关者认为我们在构建X，但实际上我们构建了Y的情况。这种突然的意外会导致大量延误，是我最不想处理的事情之一。

实现对齐需要大量的会议、Slack讨论、Loom视频等，这成本很高，但相比另一种选择还是便宜得多。不经过对齐就进行构建，会让你面临痛苦的抉择：要么交付一个糟糕的或内部有争议的产品，要么接受沉没成本，承认构建错了东西然后从头再来（痛苦但通常是正确的）。

需要说明的是，我这里的“对齐”指的是人类之间就产品应该如何工作达成一致，而不是人类与智能体就如何构建达成一致。我完全支持人类与智能体的对齐（参见我的文章《Spec and Verify》）。

这个过程过去还算合理，但现在不是运营产品组织的方式了。这是一种很难打破的习惯。但如果你能做到，你会行动更快、交付更好。

在Warp，我们正在改变工作方式以适应这个新现实。例如在2023年，我们花了无数时间试图基于原型图、Slack讨论、PRD等来确定我们的协作平台Warp Drive应该如何工作，在此之前一行代码都没写。我不会再这样做了。

相反，我会让团队在问题空间上对齐，从设计师那里获得一些初步想法，然后尽快开始构建解决方案，以便内部试用。对齐应该在我们拿到解决方案之后进行。

你不应该做的，是担心第一次构建的解决方案是否理想。这并不重要。你应该尽快构建一个可测试的版本，然后尝试它。如果你愿意，可以构建多个版本。如果可能的话，让用户试用它。关键在于，不要浪费时间猜测一个产品设计得是否正确——你完全可以以极低的成本和风险构建出来并体验实际解决方案。

一旦东西被构建出来，你就不再是猜测了。你是在实验。更重要的是，你们所有人都在对同一个东西进行实验，而不是在某个人人都在以略微不同的方式想象的假设实现上进行实验。那是旧的方式，也是大量时间浪费的根源。

新的设计流程

以下是我们旧流程的参考版本，改编自我们公开的《我们如何工作指南》中的“我们如何解决用户问题”部分：

• 清晰陈述问题和用户目标

• 团队一起探索解决方案空间，从产品和技术两个角度出发，通常通过“产品工作坊”

• 制作不同可能方案的原型图（<– 设计瓶颈）

• 团队对齐，确定我们认为最好的构建方案（<– 团队对齐瓶颈）

• 编码实现方案（<– 编码瓶颈，正在消失）

• 审查代码和产品，确保符合初始规格（<– 验证瓶颈）

• 内部试用并优化方案，直到我们认为足够好

• 进行Bug大扫除，确保要交付的东西的质量

• 发布，监控并根据用户反馈调整

大部分步骤依然成立，但第4步应该移到初始构建（第5和第6步）之后。你仍然需要做大量的前期工作——明确用户问题、进行产品工作坊、设计出最佳猜想方案——但主要目标是尽快基于一个实实在在的产品开启反馈循环。

在Warp，我们越来越倾向于这样工作。例如，我们最近推出了一整套功能，让编码智能体在应用中更好地工作。我们花时间对齐了我们试图解决的问题——让Warp成为使用任何编码智能体进行构建的最佳场所——但我们并没有花太多时间争论方案细节。相反，我们的设计团队拿出了一些不错的初始设计方案，团队构建了它们，然后我们一起迭代，直到找到感觉良好的状态。到我们发布时，所有人都一致认为这个方案很出色。

现在正是审视你产品开发流程的好时机，看看它是否过于注重前期的构建对齐。你可以通过先编码再对齐来节省大量时间和麻烦。这样工作会帮助你行动更快、交付更好，而且也会有趣得多。