29个月增长100倍：一个AI 2.0公司应该怎么建？HeyGen的取胜的秘密

近日，AI视频生成公司HeyGen宣布其年化经常性收入（ARR）已突破1亿美元大关。值得注意的是，该公司在29个月前才刚刚达到100万美元ARR的里程碑，实现了百倍的增长。

HeyGen创始人兼CEO Joshua Xu近日公开了他们取胜的秘密，他认为HeyGen之所以快速发展很大程度上归功于他们的“圣经”——“The HeyGen Way”，公司为应对AI时代技术快速、持续且不可预测的变化而沉淀的独特运营模式。

Image

拥抱变化

HeyGen方法论的核心，是放弃了传统软件开发中对“稳定技术基础”的追求。他们认为，在当前AI技术每隔数月就会有一次重大突破的背景下，试图建立一个长期不变的完美架构是徒劳的。

取而代之，他们提出了一种“驾驭浪潮”的理念。这意味着，公司的产品和系统在设计之初，就预设了底层AI模型会不断变化。其架构的核心是灵活性与抽象层，目标是让产品能够随着新模型的出现而“自动”提升性能和体验，而不是被旧技术所束缚。

一个关键的区别在于，他们强调这种对“不稳定性”的拥抱仅限于底层的AI技术，而对于面向用户的产品服务、稳定性和体验质量，则要求保持极高的标准。

在这种理念下，HeyGen也重新定义了速度与质量的关系。他们认为，快速行动并非牺牲质量，反而是实现高质量的途径。通过高频率的实验（例如，在一个月内进行五次实验而非完成一个功能），团队能够以数倍于竞争对手的速度学习。这种快速的认知迭代，最终会转化为更符合用户需求、质量更高的产品。

匹配节奏

为了将理念落地，HeyGen建立了一套与之匹配的运营节奏。其核心是为期2个月的路线图规划周期。这个时间长度并非随意设定，而是为了与主流AI模型升级的频率大致对-齐，确保战略规划能及时响应技术前沿的变化。

在此周期内，日常的开发工作被分解得更细：

• 双周承诺清单：产品与工程团队共同商定未来两周内可明确交付的成果。
• 每日发布：无论是功能改进、错误修复还是小型实验，团队力求每天都有新的代码上线。

在决策方面，该公司推行一个简单的框架：区分“单向门”和“双向门”决策。对于会产生重大且不可逆影响的“单向门”决策，团队会进行审慎的讨论；而对于绝大多数可以随时调整或撤销的“双向门”决策，则授权给产品经理快速决定并立即测试，以避免在不必要的讨论中浪费时间。

最小化快速验证迭代

HeyGen的团队结构也为这一模式服务。团队由产品经理、工程师、设计师和数据科学家组成，但每个角色的职责都根据AI时代的特点进行了调整。

• 产品经理与工程师：他们被鼓励组成最小化的（通常是2人）原型开发小组，直接上手构建功能性的MVP（最小可行产品）。这种“原型优先”的方法取代了传统的、冗长的需求文档流程，旨在以最快速度验证一个想法是否可行。
• 设计师：他们的角色定位也颇具特色。设计师通常在某个想法通过初步原型验证、证明其具有用户价值之后，才会深度介入进行体验优化和视觉打磨。这确保了宝贵的设计资源被投入到最有可能成功的项目上，避免了在早期不确定的概念上进行过度投入。
• 数据科学家：作为分析伙伴，他们与产品经理紧密合作，负责定义实验的成功指标、进行深度的数据分析，并确保团队的决策基于可靠的数据而非直觉。

小结

可以说，HeyGen的实践是AI 1.0时代跑赢的代表，如字节早期突围的2.0版本，要想胜利，人本身多寡，并不重要，更重要的快速的寻找方向并在对的方向快速奔跑，试错、验证、加速是其核心，而与之适应运营模式和支撑流水线（虽然没提，但这或许才是核心秘密和壁垒，模式可学，但这些基础设施短期难以复制）是其重要保证。

关注公众号回复“进群”入群讨论。

《The HeyGen Way》的完整翻译如下：

我们如何驾驭浪潮、快速交付，并在不稳定的世界中取胜

目录

我们正在构建什么

前言

第一部分：核心理念

第二部分：我们的节奏

第三部分：运营原则

第四部分：团队结构与通用原则

第五部分：核心产品团队

第六部分：增长产品团队

第七部分：沟通协议

第八部分：需要避免的反模式

第九部分：在战时取胜

结论

引言

我们正在构建什么：为每个人服务的视觉叙事

我们的使命：让视觉叙事触手可及。

我们将视频分为两类：

沟通类视频

— 用于商业动态、教程、访谈、播客、讲解等。这类视频旨在解释、告知或沟通。（最适合基于脚本的编辑。）

电影感视频

— 用于高制作水准的广告、电影、音乐视频、预告片、高端品牌内容等。这类视频旨在感动、启发或娱乐。（最适合基于时间线的编辑。）

我们的重点是让每个人都能轻松制作沟通类视频。当我们说“每个人”时，我们指的是从新手到专业人士的所有技能水平的人。我们的产品足够简单，任何人都能在几分钟内制作出高质量的视频。

前言

为什么会有这本书

传统的软件开发模式已死。曾经稳固的地基如今在我们脚下动摇。在人工智能（AI）时代，突破性进展每隔几个月就会出现，昨天的极限变成了明天的默认标准。

在 HeyGen，我们不与这种不稳定性抗争，而是驾驭浪潮。我们的整个开发理念都围绕着驾驭 AI 进步的浪潮而构建，而不是去寻找那些已不复存在的稳定技术基础。

这本书记录了我们如何思考、构建和取胜。它写给每一位 HeyGen 的团队成员——工程师、设计师、产品经理——也写给那些希望加入我们的人。这就是当基础在我们脚下不断变化时，我们如何工作，以及我们如何将这种不稳定性转化为我们的竞争优势。

第一部分

核心理念

我们的核心理念

“快速行动，做到极致。驾驭 AI 浪潮，拥抱研究的不确定性，以前瞻六个月的眼光进行布局，并构建能够随着模型改进而自我升级的灵活产品，同时绝不牺牲质量。”

根本性转变：从“地基”到“浪潮”

在 AI 时代，我们在没有稳定技术基础的环境中运营。每隔几个月，AI 技术就会发生巨大演变。模型的能力是未知的，并且在迅速变化。

我们正处在一个百年一遇的技术窗口期。在接下来的12个月里，AI 代表了我们这一代人的“战时机遇”。我们有机会打造下一个谷歌或 Facebook。这个机会正在当下爆发。我们应该将紧张感和强度提升到最高水平。这是每个人加入 HeyGen 的原因，也是我们在此的原因。

关键区别：

当我们说“拥抱不稳定性”时，我们指的是底层的 AI 技术基础——模型、能力、研究突破。我们绝不接受在服务正常运行时间、产品质量或用户体验上的不稳定性。即使脚下的 AI 技术基础不断变化，我们的产品也必须保持坚如磐石的可靠性。 这不是一个缺陷，而是我们的机遇。我们驾驭浪潮，而不是逆流而行。

传统时代：

• 在稳定的基础上构建
• 为长期使用而优化
• 制定12-18个月的计划
• 先打磨，后发布
• 顺序开发

AI时代（我们的方式）：

• 驾驭技术浪潮
• 为自动改进而构建
• 现实地规划2个月（与模型升级周期保持一致）
• 为学习而发布
• 并行实验

这与敏捷开发有何不同传统的敏捷开发假设技术相对稳定，能力可预测。而我们工作的环境中，基础技术每隔几个月就会改变。我们的方法扩展了敏捷原则，但针对技术不稳定性进行了优化，而不是稳定的迭代周期。

驾驭浪潮者的优势

竞争对手追逐稳定的基础，结果被下一次技术飞跃打得措手不及。我们则为产品能够随着模型进步而自动改进进行设计，选择驾驭浪潮，而不是与之对抗。

理解变与不变：对我们来说，理解哪些部分可能在短期内改变（模型、能力）以及哪些不太可能改变（用户工作流、核心问题）至关重要。我们围绕不变的元素构建产品/系统，同时驾驭模型改进的浪潮。

驾驭浪潮的机遇示例：

• 语境学习（In-context learning） vs. 微调（fine-tuning） vs. RAG 方法
• 语音模型中的后处理改进
• 多供应商系统优化

质量悖论

我们既要行动迅速，又要做到极致。这似乎是矛盾的，但当你理解了这一点就不会了：从长远来看，快速行动能让我们构建更高质量的产品，并更快地为客户创造价值。当竞争对手一个月发布一个功能时，我们发布五个实验。我们的学习速度是他们的五倍。这种学习的复利效应会转化为卓越的产品。

快速行动并不意味着快速发布功能——它意味着快速交付客户价值（并快速学习）。速度服务于“做到极致”这一最终目标。

尤其对于视频内容，质量是不可妥协的。用户喜爱产品不是因为其界面精美，而是因为它能以卓越的质量解决他们的问题。我们的成功指标是：任何用户在我们平台上所能达到的平均视频质量。

第二部分

我们的节奏

我们的节奏：2个月的浪潮周期

为什么是2个月？这与模型升级周期保持一致，使我们能够在保持专注的同时，快速调整策略。

我们的节奏：

• 2个月的路线图规划

— 与 AI 发展周期同步。与领导层、技术负责人和产品经理（设计可选但鼓励参与）深入探讨产品回顾和策略。理想情况下，线下进行以最大化沟通效率，排除干扰。对我们的表现保持完全透明和坦诚，并根据需要调整策略。

• 6-12个月的战略布局

— 预测并为下一个重大突破做准备。

• 双周承诺清单

— 产品和工程团队共同决定并优先安排每个团队承诺的具体交付成果。

• 每日交付 — 改进、功能或实验每天都会上线。

理念：

短周期使我们与 AI 发展的步伐保持一致。这个周期足够长，可以构建有意义的东西；也足够短，可以在技术格局变化时迅速适应。

运行驾驭浪潮的实验

重要提示：

此框架更适用于现有产品和增长领域，而对于需要更长时间探索的新功能和研究领域则不太适用。

• 第1天：定义假设和成功指标
• 第2天：构建 MVP（真正最小化的版本）
• 第3-5天：向部分用户发布
• 第2周：分析、学习、决定下一步行动

好的实验是：

• 快速的（以天为单位，而不是周）
• 科学且数据驱动的
• 提供明确的信号：继续、调整方向或停止
• 大胆尝试而非小修小补（我们还未到需要优化的成熟阶段）

失败的实验：

• 大多数实验都会失败——这是正常的
• 从失败中学习 = 胜利
• 没有学习的失败 = 真正的失败
• 绝不让实验拖得太久以至于无法得出结论

做出浪潮般速度的决策

决策框架：这是“单向门”还是“双向门”？

• 单向门：深思熟虑（罕见）
• 双向门：产品经理快速决定，立即测试（常见）

当有争论时：我们能测试这个吗？如果可以，停止讨论，开始实验。

决策沟通：

• 通过 Slack 立即沟通，明确指定唯一的负责人和执行时间。
• 团队之间完全透明。
• 分享背景信息，而不仅仅是计划。
• 清晰说明每个决策应传达给谁。

6个月的水晶球虽然我们现实地规划2个月，但我们必须为战略布局预测6-12个月的未来。这需要：

• 关注 AI 研究的突破
• 理解计算能力的趋势
• 预判模型的能力
• 构建能从未来改进中受益的灵活架构

在快速行动中管理技术债

核心原则：为灵活性和可替代性而构建。

• 构建预期会发生变化的抽象层（注意：在时机未到时不要过度抽象）。
• 记录假设，而不是实现细节。
• 对所有东西进行积极的版本控制。
• 设计能随着模型升级而改进的系统。

技术债的时间分配：

我们的原则是：将偿还技术债视为对未来速度的投资。我们鼓励那些能显著提高团队生产力和系统可靠性的技术债偿还工作。技术债工作应与业务成果和速度提升明确挂钩。

第三部分

运营原则

1. 速度就是一切（决不妥协）

新的现实：在 AI 时代，学习最快的团队获胜。就是这样。

• 以天为单位交付，而不是周。
• 如有疑问，发布一个实验。
• 势头比完美更重要。
• 行动缓慢是唯一不可原谅的罪过。

实际应用：

• 用 MVP 测试想法，而不是最终产品。
• 足够好以验证 > 完美但迟到。
• 发布不完美的产品，然后跟进：如果行不通就下线，如果用户在意就改进到最好。
• Bug 比不完美的功能更糟糕（Bug 阻碍学习）。

速度是一种态度

速度不仅仅关乎执行力，更关乎心态。我们不说“为了安全起见，等到周一再发布吧。”这种话暴露了紧迫感的缺失、学习欲望的不足（浪费了2-3天的宝贵数据）、薄弱的主人翁精神以及对执行能力的怀疑。这种心态会阻碍我们取胜。赢家会主动负责、快速交付、学习和适应。

偏向行动 > 追求完美

如果你总想确保自己是正确的，那你的行动就太慢了。不要害怕犯错，要害怕学得太慢。

2. 拥抱技术浪潮

不要再追逐技术的稳定性，它已不复存在。AI 的基础每2个月就会改变。设计你的产品，让它们能随着模型的进步而自动改进。构建预期会发生变化的抽象层。让你的产品体验驾驭在 AI 进步之上，而不是与之对抗。

3. 充分辩论，坚决执行

我们身处战时，而非和平时期。每个人都可以提出想法和反馈，但决策必须迅速。一旦做出决定，我们就全力以赴地执行，即使我们之前并不同意。因缺乏承诺而导致的战略失误，比我们能够快速纠正的不完美决策更糟糕。

4. 通过创新实现用户价值

用户喜爱的是能解决问题的产品，而不是漂亮的界面。创新与用户的喜爱紧密相连。我们创新人们用 AI 创作视频的方式，打造前所未有的神奇体验。但没有解决实际问题的创新是毫无价值的。

新用户入门的挑战：

• AI 产品的能力因用户技能而差异巨大。
• 我们的责任是：教授用例，而不仅仅是功能。
• 成功 = 任何用户都能达到的平均质量。
• 衡量视频质量，而不仅仅是视频创作量。5. 自研 vs. 购买：一个简单的规则

无论哪种方式能提供最佳的用户体验，我们就选择哪种。

• 内部自研：虚拟形象视频模型（没有外部供应商能达到我们的质量标准）。
• 外部供应商：语音（质量足够好，且受资源限制）。

不讲情怀，只看结果。

第四部分

团队结构与通用原则

A. 通用团队结构

所有团队都遵循相同的核心结构：产品经理（PM） + 工程 + 设计 + 数据科学。

B. 通用角色定义

产品经理：总指挥

• 核心职责（所有 PM）：
  • 决策和优先级设定的主要推动者。
  • 直接与领导层合作制定战略。
  • 明确每个功能背后的“为什么”。
  • 协调工程、数据科学和设计团队。
• PM 能力：
  • 创建功能性的 MVP 和用户体验（UX）原型。
  • 为用户简化技术抽象概念。
  • 引领“原型优先”的方法。
• AI 时代的演变：
  • 构建功能性原型，跳过传统的需求文档。
  • 使用 Figma 设计或 UX 原型作为文档。
  • 为尚不存在的能力进行规划。
  • 非常熟悉市场上的所有 AI 工具，并每天使用它们。

工程师：快速构建者

• 核心职责：
  • 以最快速度构建和执行决策。
• 提供 PM 可能忽略的技术见解。
  • 为灵活性和快速迭代构建架构。
  • 深入理解问题背后的“为什么”。
• AI 时代的重点：
  • 使用 AI 编程助手（如 Cursor、ChatGPT 等）来提升速度。我们行业过去常说“10倍工程师”，我不确定是否真有10倍，但有了 AI 编程工具，每个人的生产力至少是两年前的3倍。
  • 构建可以演进为生产系统的原型。
  • 专注于构建，而不是文档。
  • 直接与 PM 合作进行快速原型开发。

设计师：简化者

• 主要角色：定义简单而出色的体验。
• 设计使命：作为一款视频创意工具，我们的设计需要达到世界级水平。任何低于这个标准的设计都无法让我们将工具普及给每个人。因此，我们设计的首要原则是简单。在 AI 领域让某个功能实现并不难，但要让它在保持高质量的同时易于使用则极其困难。这正是我们设计团队的主要使命。
• 核心职责：
  • 创建功能性的 MVP 和 UX 原型。
  • 将原型打磨成消费级的、令人愉悦的体验。
  • 确保所有功能都与 HeyGen 的产品框架协调一致，建立并维护跨产品的设计标准。
  • 坚持我们的原则：对每个人都极其简单。
  • 引领简化工作——如果奶奶都用不了，设计师就要标记并修复它。
  • 负责设计系统，以支持未来开发中一致、快速的迭代。
  • 帮助简化产品营销。
  • 在功能验证后，专注于视觉打磨和体验的一致性。
• AI 时代的重点：
  • 非常熟悉市场上的所有 AI 工具，并每天使用它们。
• 关键原则：为保持开发速度，设计师专注于验证后的卓越体验，而非早期探索。他们是“对每个人（包括奶奶）都极其简单”原则的主要守护者——这是一个在功能验证后需要真正专业知识来应对的基础性设计挑战。

数据科学家 & PM：分析伙伴

• 数据科学职责：
  • 指标解释与验证：作为逻辑和定义的真实来源。
  • 统计分析：相关性、因果关系、因果推断。
  • 为实验建立 PostHog 中无法实现的高级指标。
  • 为已确立的产品功能构建机构级仪表板。
  • 需要高级 SQL/Python 的复杂分析。
  • 轻量级数据工程与建模（数据管道、转换）。
  • 分享数据科学原则和术语。
• PM 职责：
  • 熟悉自己领域的核心指标，能够识别异常模式并发起调查。
  • 利用 PostHog 分析来监控趋势和使用情况（产品分析、用户群组、行为）。
  • 从 Hex 主表中提取简单数据。
  • 主动管理实验生命周期，包括预测试/回测和清理。
  • 定义实验设置——曝光、分组、成功指标。
  • 确定衡量所需的额外事件。
  • 进行初步的实验审查，以确定获胜的变体。
  • 理解领域核心指标与公司战略的联系，能够在发布决策中做出高质量的判断。
  • 期望能自己在 PostHog 中进行数据分析，并在 Hex 中编写简单的查询。
• 共同职责（数据科学家 & PM）：
  • 实验影响分析——就结果和解读达成一致。
  • 关键绩效指标（KPI）定义（如 AER、留存率、转化率）。
  • 需要深入分析时，共同进行实验审查。
  • 调查异常模式。

C. 平等的伙伴，不同的赛道

• PM 帮助定义“做什么”：
  • 框定问题。
  • 定义目标。
  • 带来清晰度和背景信息。
• 工程师塑造“怎么做”：
  • 与 PM 和设计共同设计解决方案。
  • 负责可行性、权衡和执行。
• 设计师确保“简单”：
  • 让复杂的 AI 对每个人都触手可及。
  • 守护“奶奶测试”原则。
  • 创造愉悦的体验。
• 数据科学家提供“真相”：
  • 用数据验证假设。
  • 科学地衡量影响。
  • 指导实验方法论。
• 所有人就“为什么”达成一致：
  • 为什么这件事值得做？
  • 我们为谁解决什么问题？
  • 为什么是现在？为什么是这种方法而不是其他？
  • 为什么这能推动业务前进？

D. 构建原型的流程

理念：在传统软件开发中，PM + 设计 + 工程师构成了“神圣铁三角”。在快节奏的 AI 开发中，我们优先考虑速度和学习，而非完美的流程。

灵活的合作模式：PM 和设计师的合作关系可以因团队而异。一些 PM 在 UX 方面经验更丰富，应端到端地推动原型；一些设计师深入理解 AI 的工作原理，可以介入并主导原型。

两人规则：原则上，由一名 PM/设计师加一名工程师（共2人）来构建原型。我们不为了照顾每个人的感受而追求共识。我们在这里是为了加速，尽快在市场上验证想法，以便我们团队能构建更好的产品。

每个人都有机会为新想法构建原型。在 AI 时代，可以构建的东西理论上是无限的（就像我们在黑客松中所做的那样，真是太棒了）。关键是要有一个高效的小组来推动快速决策。

通用方法：

1. 原型优先：PM/设计师 + 工程师直接合作，快速构建和测试想法。
2. 证明其有效：在投入大量设计资源之前，用真实用户验证概念。
3. 设计打磨：一旦被证明有效，设计师会完善体验，使其符合我们的整体产品框架并保持简单性。
4. 生产就绪：每个从原型阶段进入生产阶段的功能都必须经过精心设计。

为何这样有效：AI 功能具有巨大的不确定性。大多数原型都不会成功。在未经证实的概念上过度投入设计是浪费时间。但所有触达用户的功能都必须达到我们的质量标准。

第五部分

核心产品团队

重点：构建和完善核心产品功能

核心产品团队专注于基础产品体验——构建那些定义 HeyGen 是什么、能做什么的功能。他们为用户体验质量、功能完整性和长期产品愿景进行优化。

核心产品团队的特点：

• 复杂功能的开发周期更长。
• 专注于产品体验和用户旅程。
• 强调设计系统和一致性。
• 与整个产品生态系统集成。
• 我们正在构建一个商业工具，但对于创意工具以及 HeyGen 要达到1亿用户而言，愉悦的产品体验至关重要。

核心产品的标准

标准很简单：在每一种体验上都做到极致。任何低于这个标准的都是不够好的。如何做到？以极快的速度行动，迭代次数比竞争对手多5倍。

零 Bug 的愿景我们应该以零 Bug 为目标。我们还没做到，但那是我们的北极星。当你使用最好的创意工具——如 Canva、Figma 或 CapCut——你很少会遇到 Bug，因为精确性对创意工作至关重要。作为一款创意工具，可靠性不仅仅是锦上添花——它对用户信任和工作流程的连续性至关重要。

第六部分

增长产品团队

实验引擎的理念

增长团队的运作方式与核心产品团队不同。我们是实验引擎。我们为速度、学习和影响力而生。每一条原则都服务于一个目标：提升我们的速度。

核心增长原则

工程是工具，影响力是目标

我们不只是交付代码，我们交付成果。在 AI 时代，代码是廉价的，影响力是宝贵的。不要为了代码的优美或过度设计无人问津的解决方案而优化。为“实现影响力的速度”而优化：交付重要的东西（20%的投入，80%的产出），在被证明有效后进行迭代，在价值得到确认后进行完善。

实验是为了学习，而不是为了赢

安全的实验算不上真正的实验。目标是通过承担明智的风险、基于大胆的假设、并愿意快速犯错来更快地学习，以便我们能更快地做对。

增长团队的重点

增长 PM：实验总指挥

• 与团队共同决策。
• 负责指标和学习循环。
• 深入理解用户问题和业务影响。
• 清晰地框定问题和定义目标。
• 定义“做什么”——框定问题、定义目标、带来清晰度。
• 与工程团队就“为什么”达成一致——为什么值得做？为什么是现在？
• 以偏向行动的态度快速启动实验。
• 对结果负责，而不仅仅是产出。

增长工程师：速度机器

• 与 PM 和设计共同设计解决方案。
• 负责可行性、权衡和执行，以更好、更快、更智能地构建。
• 在与团队就“为什么”达成一致的同时，塑造“怎么做”。
• 以最快速度启动实验。
• 专注于学习循环和数据。
• 深入理解问题，而不仅仅是“告诉我该做什么”。
• 理解了“为什么”之后，成为积极的参与者，用更少的迭代交付更多价值。
• 专注于实现影响力的速度，而非完美的架构。
• 构建能够改变公司发展轨迹的实验引擎。

增长团队的不同之处

增长团队所玩的游戏与核心产品团队不同。核心产品专注于构建和完善功能，而增长则专注于快速实验和学习。我们正在玩一场速度致胜的游戏，每一条原则都服务于这个目标。

第七部分

沟通协议

直接、异步、高效

核心原则：

• 异步优先：由于办公室分布在不同地方，尽可能利用异步沟通。
• 会议红旗：如果任何团队成员每周有超过3个超过5人的同步会议，请提出警示。
• 时间焦点：我们的时间应该用来构建，而不是开会。
• 线下沟通求实效：利用线下时间实现最高效的沟通和团队建设。
• 决策：通过 Slack 立即沟通，明确唯一的负责人和执行时间。团队之间完全透明。分享背景信息，而不仅仅是计划。清晰说明每个决策应传达给谁。
• 反馈：直接——好的工作就是好的，差的工作就是差的。对事不对人。收到反馈时：这是关于工作，而不是关于你。每个人都可以进步。

第八部分

需要避免的反模式

🚨 AI 开发的七宗罪

1. 完美的架构
   • 花费数周为“规模化”进行设计。
   • 你的规模问题：100个用户。
   • 实际问题：还没有用户喜爱它。
2. 研究瘫痪
   • “我们需要更多的用户研究。”
   • 数月的访谈，却从不发布。
   • 更好的方法：发布错误的产品，快速学习，再发布正确的产品。
3. 稳定的基础幻想
   • 等待 AI“成熟”。
   • 像 2019 年那样去构建。
   • 现实：它永远不会稳定——去驾驭浪潮吧。
4. 共识陷阱
   • 所有人都同意 = 没有人在乎。
   • 持有强烈的观点，但思想开放。
   • 冲突意味着你触及到了重要的事情。
5. 质量借口
   • “它还没准备好。”
   • “再打磨一遍就好。”
   • 自信地发布，快速地改进。
6. 大爆炸式发布
   • 秘密开发6个月。
   • 盛大揭幕。
   • 而竞争对手早已发布并完成了学习。
7. 沉没成本谬误
   • “我们已经投入了太多。”
   • 快速终结失败的项目。
   • 庆祝学到的经验，然后删除代码。

什么时候应该真正放慢脚步

质量门槛（不可妥协）：

• 妨碍从实验中学习的 Bug。
• 安全漏洞。
• 严重损害用户体验的功能。
• 影响客户的破坏性变更。战略性暂停（罕见但重要）：
• 具有重大业务影响的“单向门”决策。
• 将影响未来6个月的技术架构。
• 当用户反馈表明需要根本性的方向改变时。
• 法律或合规要求。

红旗探测器如果你听到这些话，请亮起红旗：

• 🚨 “我们再多考虑一下” → 我们已经落后了。
• 🚨 “我们应该与所有利益相关者对齐” → 决策瘫痪即将来临。
• 🚨 “如果技术变了怎么办？” → 它会的。但还是要发布。
• 🚨 “我们等等下一个模型吧” → 我们的竞争对手可没在等。
• 🚨 “我们需要一个更稳健的解决方案” → 我们首先需要用户。
• 🚨 “这个可以再打磨一下” → 先发布，如果用户在乎再打磨。

第九部分

在战时取胜

我们为什么会赢

• 我们的交付速度是竞争对手的5倍：更多实验 = 更多学习。
• 学习的复利效应会转化为更好的产品：我们拥抱他人所规避的东西。
• 不稳定性是我们的优势：守旧的竞争对手无法适应。
• 我们专注于真正重要的事情：为用户提供高质量，为学习提升速度，为差异化而创新。

我们驾驭浪潮的七大原则（愿景）

1. 快速行动，决不妥协。
2. 打造极致的产品体验。
3. 质量至上（尤其是视频的视觉质量）。
4. 充分辩论，坚决执行。
5. 如有疑问，发布一个实验。
6. 拥抱不稳定的 AI 开发——驾驭浪潮。
7. 通过整合促进创新。

结论

驾驭浪潮，勇往直前

三年前，我们无法想象今天 AI 的能力，那时连 ChatGPT 都还没有出现。三年后，今天的尖端技术将显得古老。唯一不变的是变化。唯一的策略是驾驭浪潮。唯一的目标是用户价值。

我们没有所有的答案，但我们有更好的东西：业内最快的学习循环。

每一天，我们都面临一个选择：是寻求虚假的稳定，还是驾驭浪潮。我们选择驾驭。我们选择构建那些随着 AI 进步而变得更神奇的产品。我们选择快速交付，更快地学习，并最终取胜。

欢迎来到软件开发的未来。让我们一起创造非凡。