Warp CEO：先把产品建出来，再对齐

Warp CEO Zach Lloyd 近日发表长文，系统阐述了一个反直觉但正在发生的事情：

在 Agent 时代，"先对齐再动手"的产品开发流程已经过时了。

为什么以前的流程要先对齐？

在 Agent 出现之前，Coding 是最贵、最耗时的环节。

所以团队的做法是：

1. 明确问题和用户目标
2. 团队一起探索解决方案空间（product jam）
3. Mock up 不同方案 ← 设计瓶颈
4. 对齐最佳方案 ← 对齐瓶颈
5. Coding ← Coding 瓶颈
6. Code review 确认符合 spec ← 验证瓶颈
7. 内部 dogfood 测试
8. Bug bash，质量把关
9. 发布，监控，根据用户反馈调整

其中 Step 4（对齐）是整个流程中最贵的环节之一——涉及大量会议、Slack、Loom、PRD，所有利益相关者参与。

为什么 Agent 时代这个逻辑变了？

Zach 的核心论点是：

Coding 的成本趋近于零，所以"一次做对"的优先级下降，"快速建出来、然后实验"的优先级上升。

以前：建错东西 = 浪费大量时间和钱 现在：Agent 让 coding 成本大幅降低，犯错成本随之降低

新流程：Build first, align after

Zach 的建议流程：

1. 同样做 pre-work：搞清楚用户问题、product jam、设计初稿
2. 快速构建可测试版本（不用管是不是最优解）
3. 内部 dogfood
4. 迭代直到感觉对
5. 到了这里，团队自然对齐了

对齐是在有实物之后发生的，不是之前靠想象达成的。

关键心态转变：不要担心第一个方案是否理想。它不重要。快速建，快速试。

实物实验 vs 纸上推演

Zach 指出了两种方式的本质差异：

纸上推演：每个 stakeholder 对"那个东西应该怎么工作"都有自己略微不同的想象，大家争论的是不同的假设。

实物实验：所有人都在玩同一个东西，想法自然收敛，不需要会议来对齐各自的想象。

Warp 的实际案例

Warp 自己在 2023 年花了大量时间用 mock、Slack、PRD 来讨论 Warp Drive 应该怎么工作——Zach 现在认为这是个错误。

最近他们用新流程做了一套让 coding agent 在 Warp 里更好用的功能：

1. 花时间对齐问题——让 Warp 成为最好的 coding agent 工作场所
2. 花少量时间在设计初稿
3. 团队快速构建
4. 迭代到满意再发布
5. 发布时团队已经对齐——不是因为开会，是因为大家都在用同一个东西

对产品人的启发

Zach 的建议很直接：审视你的产品开发流程，看它是否在 Build 之前放了太多对齐工作。 如果是，可以节省大量时间和精力。

这不是说 pre-work 不重要——搞清楚用户问题、做 product jam、设计初稿这些仍然有价值。但整个流程的重心要变：从"先把规划做好"移到"先把东西建出来"。

这也是 Agent 时代给产品团队结构的一个根本性变化：Coding 从瓶颈变成了最便宜的环节，所以它的位置应该从流程末尾挪到流程前面。