最近和我们的工程负责人聊天时，他提到了一个很多技术团队都在担心的问题：随着 AI 编码能力的提升，交付速度越来越快，会不会有一天没有事情可做了？
我的回答是：完全不需要担心。这是一个典型的 Jevons 悖论。
十九世纪，经济学家 William Stanley Jevons 发现，当蒸汽机效率提升、煤炭使用成本下降后，煤炭消耗量不降反升。原因很简单——成本下降让更多原本不值得做的事情变得值得做了。
AI 也是如此。当交付成本下降时，需求不会减少，只会爆炸式增长。真正的问题不是"会不会没事做"，而是游戏规则变了，你准备好了吗？
讨论驱动的死亡螺旋
在传统的产品开发中，大量时间花在讨论上。产品会议里，设计师说这个按钮应该大一点，产品经理说应该小一点，工程师说两个都能做，于是继续讨论……
什么时候触发付费弹窗？定价策略是什么？交互界面怎么设计？这些相对细节层面的问题，很容易陷入"公说公有理，婆说婆有理"的境地。
你可以提出论点，别人可以提出相反的论点。人类的理性——更准确说是 theory 和 reasoning——在这里会丧失太多的参考价值。你怎么说都可以：“我认为用户需要这个”，“我的体验是这样的”，“我觉得应该这样设计”……
结果就是无休止的会议，开几个小时也没有结论。
更糟糕的是，我们绝大多数的 hypothesis 其实都是错的。根据 Google、Microsoft 等公司的实验数据，只有 10-33% 的产品假设最终被证明有效——这意味着 67-90% 的假设会失败。这些基于想象和推理的假设，往往不符合真实用户的需求。
问题的本质在于：我们在用理性（reasoning）解决实证（empirical）问题。而实证问题的唯一答案，在用户那里。
0到1 vs 1到100：方法论的分野
但这不意味着所有阶段都应该实验驱动。产品开发的不同阶段，需要完全不同的方法论。
0到1阶段：你在寻找 Product-Market Fit，还在摸索用户真正需要什么。这个阶段需要：
- 拍脑袋的直觉
- 快速迭代
- 深度用户访谈
- 做那些不规模化的事情
正如我在之前的文章中讨论的，PMF 之前过早追求 A/B testing 和增长黑客是徒劳的。Airbnb 的成功不是因为他们优化了按钮颜色，而是因为创始人 Brian Chesky 和 Joe Gebbia 亲自给纽约的房源拍照片，手工打造 10-star 体验。
这个阶段，产品方向的判断需要依赖 taste——对用户人性的洞察。如果你一直 A/B test 更好的马车，你永远无法发明汽车。
1到100阶段：你已经找到 PMF，有了稳定的用户流量。这个阶段需要：
- 实验驱动
- 数据验证
- 快速迭代
- 规模化优化
正如 Marshall Goldsmith 那句被广泛引用的话：“What got you here won’t get you there.”
这两个阶段的方法论截然不同。混淆它们，要么在 0 到 1 时陷入过度优化，要么在 1 到 100 时依然凭感觉拍脑袋。
实验驱动的前提与陷阱
实验驱动不是万能的。它有明确的前提条件和需要警惕的陷阱。
前提条件：
- PMF 已确定：产品方向清晰，不再是根本性探索
- 有足够流量：能跑出统计显著的实验结果
- Metrics 定义清晰：知道什么重要，什么不重要
陷阱一：Data-centric 而非 User-centric
很多人误解了数据驱动。他们变成了 data-centric——为了优化指标而优化指标，追求 vanity metrics，最终伤害用户体验。
正确的做法是：Data-driven but user-centric。
数据是手段，用户价值是目的。你不能为了提升 5% 的转化率，就在用户刚进来就弹窗，牺牲整体体验。Brian Chesky 说得很清楚：如果为了优化短期 conversion 伤害了 10-star 体验，那就是在杀鸡取卵。
陷阱二：盲目追求 Metrics
如果你定义错了 metric，或者过度追求某个 metric，那可能比不看数据更糟糕。
Metric 应该反映真实的用户价值。如果你的 metric 是"视频生成数量"，你可能会优化出一堆低质量视频。如果你的 metric 是"用户能达到的平均视频质量"，你才是在真正解决问题。
陷阱三：扼杀颠覆性创新
纯数据驱动有个经典陷阱：local optimization vs global innovation。
iPhone 推出时，批评者认为用户需要实体键盘。Airbnb 早期，传统观念认为没人愿意住陌生人家里。Netflix 从 DVD 转向 streaming，短期数据确实是负面的。
所以关键在于：在 paradigm shift 时，需要人的判断和 taste。在优化阶段，需要实验和数据。
实验循环：从假设到验证
有了实验驱动的原则，产品开发的流程会彻底改变。
正如我在之前关于实验文化的讨论中提到的，AI 的真正价值不只是提升生产力，而是让我们能够把"我觉得"转化为"我试过"。当实验成本大幅下降时，讨论的必要性也随之消失。
典型的实验循环：
- 定义假设：清晰的 hypothesis 和成功指标
- 快速构建：用 AI 辅助，几天内做出 MVP
- 灰度发布：不是 100% rollout，而是先给一部分用户
- 数据验证：第二天就能看到数据变化
- 快速决策：继续、调整，还是放弃
不需要在会议室里争论几小时，你可以直接把功能上线，让数据说话。前提是你的流量足够，PMF 得到确保。
这个循环的关键在于速度。从提出假设到验证结果，越快越好。这就是为什么 AI 时代的 momentum 如此重要。
Momentum as Moat
现在可以理解为什么 momentum 在 AI 时代如此重要了。
如果你可以 data-driven 地一天或一周做 5 个产品 feature 的 shipping 和实验，并且用数据验证这些东西有用还是没用，那你和那些还在开会讨论、撰写 PRD 的团队比起来，这就是一个代际差距（generational gap）。
本质上就像是你已经使用了核武器，而他们还停留在冷兵器阶段。这场增长的战役根本没法打。
Momentum 本身就是护城河。
竞争对手一个月发布一个功能，你发布五个实验。你学习的速度快五倍。这个学习会复利，最终转化为更好的产品。这不是关于"快"本身，而是关于学习循环的速度。
HeyGen 的产品开发手册中有一段精彩的描述：“竞争对手一个月发布一个功能，我们发布五个实验。我们学习快五倍。这个学习复利成更优秀的产品。“这就是速度的真正价值——不是快速交付功能，而是快速交付学习。
有人会问：这样快速迭代，技术债怎么办？用户体验的一致性怎么办？
我的观点是：Technical debt 其实跟 financial debt 很像。它不是要躲避的东西，而是一种杠杆。
你用 technical debt 换取产品增长速度。在 AI 这个 momentum-defined 时代，这是合理的 trade-off。当技术债的增量超过增长速度时，才是停下来处理它的时候。
至于用户体验一致性，快速实验确实会带来问题——如果你同时跑多个实验，不同用户可能看到完全不同的产品界面，造成困惑和支持成本上升。
但这是一个 feature gate 和灰度发布的问题。你不需要把每个实验都 100% rollout 给所有用户。可以先给新用户测试，可以只给 10% 的用户，可以分地区、分场景。关键是确保单个用户看到的体验是一致的，而不是今天看到按钮在左边，明天在右边。
这需要更灵活的思维，而不是固化地认为"实验=全量上线”。
AI Native 的真正含义：Ride the Wave
那么，什么是 AI Native 公司？
不只是"用 AI 工具加速开发”，而是整个产品开发流程从零设计为 AI-first。
HeyGen 在他们的产品开发手册中系统地阐述了这一理念。他们的核心洞察是：在 AI 时代，我们运行在一个没有稳定技术基础的环境中。每隔几个月，AI 技术就会发生巨大的演变。模型能力是未知的，变化迅速。
传统的软件开发假设有稳定的基础。但在 AI 时代，这个基础每 2-3 个月就会改变。
这不是 bug，而是机会。关键在于：Ride the wave，而不是对抗潮流。
从稳定基础到冲浪：
传统时代的思维是：
- 构建在稳定的基础上
- 优化长期性
- 提前 12-18 个月规划
- 打磨完再发布
AI 时代的思维是：
- 冲浪技术浪潮
- 构建能自动改进的产品
- 2 个月实际规划周期（与模型升级周期同步）
- 发布以学习
- 并行实验
AI Native 的核心原则：
区分什么会变，什么不变：模型会变，能力会变，但用户的核心问题和工作流不会变。围绕不变的东西构建系统，同时冲浪模型的改进。
设计自动改进的产品：当 GPT-5 出来时，你的产品应该自动变得更好，而不是需要重构。构建抽象层，让产品体验 ride on top of AI advancement。
灵活的架构：预期变化。版本化所有东西。构建可替换的系统。
2 个月的规划周期：足够长去做有意义的事，足够短去快速调整。这与 AI 模型的升级周期同步。
6-12 个月的战略押注：虽然实际规划是 2 个月，但需要预测 6-12 个月后的能力，提前布局。
这不是工具的差异，而是组织架构和思维模式的根本性差异。
Build the Machine that Builds the Machine
Elon Musk 说过一句话：“It’s important to build the machine that builds the machine.”
我现在对这句话有了更深的理解。
对产品有极致的细节追求是合理的，你也必须要有这样的追求。但这些追求不能是主观的"我认为好就好"，而是要有客观的衡量标准。这个客观标准就是：用户是否喜欢。
而用户是否喜欢，很大程度上由你定义的 metrics 和数据所佐证。
所以，能够把你的产品优化 workflow 打造好，比打造好一个单独的产品本身还要重要得多。这就是我说的"build the machine"。
这个 machine 是什么？它是一个完整的、能够自我进化的产品开发系统，包含三个层次：
技术基础设施层：
- Feature flag 系统：允许快速开关功能，灰度发布
- A/B testing 平台：支持多变量实验和统计分析
- 实时监控和分析工具：快速发现问题和机会
- 为 AI 模型升级设计的抽象层：让产品随模型进化而自动改进
组织能力层：
- 实验驱动的文化：用数据说话，而非观点争论
- 快速决策机制：two-way door 决策当天做，避免共识陷阱
- 与 AI 模型同步的 2 个月规划周期
- Disagree and commit 原则：速度优先，错了快速纠正
战略认知层：
- 正确的 metrics 定义：反映真实用户价值，避免 vanity metrics
- Data-driven but user-centric：数据是手段，用户是目的
- 区分 0 到 1 和 1 到 100 的方法论：知道什么时候靠 taste，什么时候靠数据
- 理解什么会变（AI 能力），什么不会变（用户需求）
这是一个 meta-capability——你不是在优化单个产品，而是在优化"优化能力"本身。
前面讨论的所有要素——实验循环、momentum、AI Native、Ride the Wave——都在这个 machine 中融合。你构建的不是一个产品，而是一个能够持续产出更好产品的系统。
大多数初创公司不具备 build this machine 的能力，这也是为什么从 0 到 1 和从 1 到 100 是完全不同的问题。
但在 AI 时代，这不再是可选项，而是必修课。
速度与质量的悖论
有人会问：快速移动和追求卓越不是矛盾的吗？
答案是：不矛盾。反而快速移动是长期打造更好产品的前提。
当竞争对手一个月发布一个功能时，你发布五个实验。你学习快五倍。这个学习复利成更优秀的产品。
Moving fast 不意味着 shipping features quickly，而是意味着 delivering customer value quickly（以及 learning quickly）。速度服务于终极目标：成为绝对最好的。
HeyGen 的质量标准很清晰：对于视频内容这样的创意工具，质量是不可谈判的。用户不会因为精美的 UI 而喜欢产品——他们喜欢能以卓越品质解决问题的产品。成功指标是：任何用户在平台上能达到的平均视频质量。
这才是正确的 north star。
游戏规则变了
回到开头工程师的担忧：AI 会不会让我们没事做？
答案是：不会让你没事做，但会让你做的事情彻底改变。
交付成本下降，需求会爆炸。但真正的问题是：你是在用旧的方式应对新的游戏规则，还是在 build the machine？
AI 时代的产品开发不是打造更好的产品，而是打造更好的生产线。
停止讨论。开始实验。打造你的实验机器。
这是 AI 时代唯一的竞争方式。