ARR 突破 1 亿美元，HeyGen 创始人公开了他们的内部增长手册，全是干货

HeyGen 创始人 Joshua Xu 今天在推特宣布，HeyGen 在本月达到了 1 亿美元的 ARR。从首次达到 100 万美元 ARR，到 1 亿美元，HeyGen 花了 29 个月的时间。

怎么做到的？

HeyGen 的回答是：速度就是一切。想清楚什么在变，什么不变，围绕不变的东西来构建产品和系统，享受模型改进带来的红利。

Joshua Xu 在推特上分享了了一份 AI 创业 Playbook——「无数次团队讨论、实验和一路走来吸取的教训的结晶」。公司内部是如何思考、 如何协作、如何决策、如何保持发布速度比对手快 5 倍的核心方法论，几乎完整地公开了出来，很坦诚。

以下是完整内容，Founder Park 进行了编译和适当调整。要点很多，推荐全文阅读。

原文链接：https://x.com/joshua_xu_/article/1978837502787219578

超 15000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。

邀请从业者、开发人员和创业者，飞书扫码加群： 

进群后，你有机会得到：

• 最新、最值得关注的 AI 新品资讯； 
  

• 不定期赠送热门新品的邀请码、会员码；
  

• 最精准的AI产品曝光渠道

---

HeyGen 的使命很简单：让每个人都能用视觉化的方式讲故事。

我们把视频分成两种：

• 沟通型视频：比如，同步业务进展、做个教程、录个访谈、播客或者产品讲解。这类视频的目的就是为了说清楚一件事。 （用脚本来编辑最合适。)

• 电影感视频：比如，制作精良的广告、电影、MV、预告片，还有那些高端的品牌内容。这类视频是为了打动人、启发人或者纯粹为了娱乐。（用时间线来编辑更方便。)

我们的全部精力都放在第一种视频上，想让它变得人人可用。

我们说的「人人」，是指任何水平的人，不管你是零基础的新手到经验丰富的专业人士。我们的产品足够简单，任何人花几分钟就能做出来一个质量不错的视频。

为什么会有这本小册子？

传统的软件开发模式已经死了。过去的开发常识，现在正在变动。AI 时代，每隔几个月就有一次技术突破，昨天还觉得不可能的事，明天就成了基本操作。

在 HeyGen，我们不跟这种不确定性对抗，我们选择跟着趋势走。我们的整个开发哲学，就是围绕如何 AI 的发展来建立的，而不是去寻找根本就不存在的、所谓的「稳定技术基础」。

这本小册子，就是想讲清楚我们是怎么思考、怎么做产品、怎么赢的。它写给 HeyGen 的每一位同事，工程师、设计师、产品经理，也写给那些想加入我们的人。它告诉你，当「地基」不断变化时，我们是如何工作的，以及我们是如何把这种不确定性变成我们的竞争优势的。

核心理念：

拥抱不确定性

其实就一句话：「快速行动，做到极致。驾驭 AI 浪潮，接受研究本身的不确定性，提前六个月布局，并做出能随着模型升级而能力提升的灵活产品，但绝不以牺牲质量为代价。」

1.1 一个根本性的变化：从找「地基」到驾驭「浪潮」

在 AI 时代，我们工作的前提就是不再依赖一个稳定的技术「地基」。每隔几个月，AI 技术就会发生翻天覆地的变化。模型能做什么，不能做什么，没人说得准，而且一直在变。

我们正处在一个百年一遇的技术窗口期。未来 12 个月，AI 就是我们这代人的「战争」。我们有机会做出下一个 Google 或 Facebook。机会就在眼前，我们必须把强度拉满。这才是大家来 HeyGen 的原因，也是我们聚在这里的理由。

一个关键的区别：不过，说「拥抱不确定性」，我们指的只是底层的 AI 技术基础：模型、能力、研究突破。但在服务稳定性、产品质量和用户体验上，我们绝不接受任何不确定性。就算脚下的「地基」不断变化，我们给用户的东西也必须绝对可靠。

这不是一个 Bug，而是我们的机会。我们选择顺着趋势走。

1.2 这和敏捷开发有什么不一样？

传统的敏捷开发，默认了技术本身是相对稳定的，能力也是可预测的。但我们面对的环境是，基础技术每几个月就「变天」了。所以，我们的方法虽然借鉴了敏捷的原则，但我们优化的核心是应对技术的剧变，而不是在一个稳定的环境里小步快跑。

1.3 冲浪者的优势

竞争对手总想找块坚实的土地，结果被下一波技术飞跃打得措手不及。我们从一开始就想着让产品能随着模型变强而自动升级。我们选择冲浪，而不是跟浪对抗。

想清楚什么在变，什么不变：对我们来说，想清楚哪些东西短期内会变（比如模型、能力），哪些东西大概率不会变（比如用户的工作流程、核心痛点）非常重要。我们要围绕不变的东西来构建产品和系统，同时享受模型改进带来的红利。

一些冲浪的机会：

• In-context learning、fine-tuning 与 RAG 方法的权衡

• 语音模型后处理能力的提升

• 如何优化一个集成了多家供应商的系统

1.4 关于质量的悖论

我们既要行动快，又要做到最好。这听起来是不是很矛盾？但只要你明白这一点就不矛盾了：行动快，才能让我们长期做出更好的东西，也才能更快地给用户创造价值。当别人一个月发布一个功能时，我们已经试了五次。我们的学习速度是他们的五倍。这种学习带来的复利，最终会变成产品的巨大优势。

记住，快不是指功能上得快，而是指用户价值交付得快（以及快速学习）。速度，是为了「做到最好」这个终极目标服务的。

特别是视频内容，质量是绝不能妥协的。用户喜欢一个产品，不是因为你界面好看，而是因为它能用极高的质量解决他们的问题。我们衡量成功的标准很简单：任何用户在我们平台上做出的视频，能达到的平均质量是多少。

迭代节奏：

两个月一次路线图

2.1 我们的节奏：为期两个月的浪潮周期

为什么是两个月？因为这刚好和 AI 模型的升级节奏差不多，能让我们在保持专注的同时，又能灵活地调整方向。

我们的节奏是这样的：

• 每两个月规划一次路线图：跟 AI 的发展周期是同步的。领导层、技术负责人和产品经理（我们也鼓励设计师参加）会坐下来，深入复盘产品和策略。为了聊得透彻，最好在线下进行。我们会非常坦诚地评估自己的表现，该调整策略就调整。

• 6-12 个月的战略布局：预测并为下一个大机会做准备。

• 每两周出一份承诺清单：产品和工程团队一起定下来，接下来两周各自要交付什么。

• 每天都发布：每天都有新的改进、功能或者实验上线。

背后的想法是：短周期让我们能跟上 AI 的发展节奏。这个周期足够长，能让我们做点有意义的事；也足够短，能在技术风向变的时候及时调整。

2.2 如何做「冲浪」实验

注意：这个框架更适合已有的产品和增长方向，对于那些需要更长探索时间的新功能和研究，可能不太适用。

• 第 1 天：想清楚假设和成功的标准。

• 第 2 天：做出一个 MVP（真正意义上最简可行的那种）。

• 第 3-5 天：发给一小部分用户试试。

• 第 2 周：分析数据，总结学到的东西，决定下一步怎么走。

2.3 如何做出「浪潮般」的快速决策

决策框架：很简单，就问一个问题：这是个「单向门」，还是「双向门」？

• 单向门：出去了就回不来的那种决策，要非常谨慎（很少见）。

• 双向门：随时可以反悔的决策，产品经理快速决定，马上测试（很常见）。 当有争论时，问问自己：这事能测试吗？如果能，那就别吵了，直接动手做实验。

如何沟通决策：

• 有了决定，马上在 Slack 里说清楚，指定一个人负责，明确完成时间。

• 团队之间要完全透明。

• 不仅要说计划，还要说为什么这么定。

• 清楚地告诉大家，这个决定需要同步给谁。

2.4 押注 6 个月后的未来

虽然我们只做两个月的具体计划，但得盯着 6 到 12 个月外的地方做战略布局。这要求我们：

• 时刻关注 AI 研究的最新进展。

• 理解算力的发展趋势。

• 预测模型接下来会具备什么能力。

• 搭建能从未来的技术进步中受益的灵活架构。

2.5 如何在快速行动中管理技术债

核心原则：你做的东西，要默认它以后会被替换掉。

• 搭建的抽象层，要假设它未来会变（但提醒一句：时机不成熟时别过度设计）。

• 写文档，要记录你的假设，而不是具体的实现方法。

• 所有东西都严格做好版本控制。

• 设计的系统要能随着模型升级而自动变好。

怎么看待技术债：我们的原则是，把还技术债看成是对未来速度的投资。如果一项工作能明显提升团队效率和系统可靠性，我们就应该鼓励和庆祝。还技术债的工作，必须和业务结果、效率提升挂钩。

行事原则：

速度就是一切

3.1 速度就是一切，没得商量

新的现实：在 AI 时代，谁学得快，谁就赢。就这么简单。

• 以天为单位发布，不是周。

• 拿不准的时候，就发个实验。

• 保持前进的势头比追求完美更重要。

• 慢，是唯一不可原谅的罪。

具体怎么做：

• MVP 是用来验证想法的，不是最终产品。

• 一个「足够好」且及时的东西，远胜于一个「完美」但迟到的。

• 先发布不完美的，再跟进：如果不行就果断砍掉，如果用户在乎就持续迭代到最好。

• Bug 比不完美的功能更糟糕，因为 Bug 会让你学不到东西。

速度是一种态度

速度不只是执行快。它是一种心态。我们从不会说「为了安全，咱们等到周一再发吧」。这种想法暴露了紧迫感的缺失，不想更快学习（白白浪费 2-3 天宝贵的数据），主人翁意识不强，以及对执行能力的不自信。这种心态会让我们输掉。赢家会主动负责，快速发布，快速学习，快速适应。

先行动，别总想着完美

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

3.2 拥抱技术浪潮

别再指望技术稳定了，这不存在。AI 的「地基」每两个月就会变一次。你应该这样设计产品：当模型升级时，它能自动变好。让你的产品体验驾驭在 AI 进步的浪潮之上，而不是被它甩在身后。

3.3 充分讨论，坚决执行

现在是「战时」，不是和平时期。每个人都可以提意见，但决策必须快。一旦决定了，就算你之前不同意，也要百分之百投入去执行。因为执行不到位导致的战略失败，比一个可以快速纠正的错误决策要可怕得多。

3.4 通过创新实现用户价值

用户喜欢的是能解决他们问题的产品，而不是漂亮的界面。创新和用户的喜爱是绑在一起的。我们致力于用 AI 颠覆人们创作视频的方式，创造过去不可能实现的奇妙体验。但是，如果创新不能解决真实的问题，那就毫无价值。

新手入门的挑战：

• 用户水平不同，用 AI 产品做出来的东西差别巨大。

• 我们的责任是：教会用户怎么用，而不只是介绍功能。

• 成功的标准 = 任何一个用户，平均能做出多高质量的视频。

• 我们要衡量的是视频的质量，而不仅仅是创建了多少视频。

3.5 自研还是外购：一个简单的原则

哪个能给用户带来最好的体验，我们就选哪个。

• 我们自己做：Avatar 视频模型（因为没有外部供应商能达到我们的质量要求）。

• 用别人的：语音（外面的供应商质量足够好，我们也能省下资源）。我们不纠结面子，只要结果。

团队协作：

所有人都要对「为什么做」有共识

4.1 通用的团队结构

所有团队都一样：产品经理（PM） + 工程师 + 设计师 + 数据科学家。

4.2 每个角色是干什么的

产品经理：总指挥

在 AI 时代的新要求：

• 直接做能用的原型，别再写又长又臭的文档了。

• 用 Figma 设计稿或者体验原型本身当文档。

• 规划那些眼下还不存在的能力。

• 非常熟悉市面上所有的 AI 工具，并且每天都在用。

工程师：快速构建者

他们主要干什么：

• 用最快的速度把决定好的东西做出来。

• 提供产品经理可能会忽略的技术视角。

• 设计的架构要灵活，方便快速迭代。

• 深入理解做这件事背后的「为什么」。

在 AI 时代的侧重点：

• 用 AI 编程助手（比如 Cursor、ChatGPT）来提速。以前我们总说 10 倍工程师，现在我不确定有没有 10 倍，但有了 AI 工具，每个人的效率至少是两年前的 3 倍。

• 做的原型，要有能进化成正式产品的潜力。

• 少写文档，多写代码。

• 直接跟 PM 一起快速做原型。

设计师：化繁为简的大师

他们的主要角色：定义出简单又出色的体验。

设计的使命：作为一个视频创意工具，我们的设计必须是世界级的。不然，我们就无法让这个工具被所有人使用。所以，我们设计的第一原则就是：简洁。

在 AI 领域，让一个东西能用不难，难的是在保持高质量的同时，让它用起来极其简单。这是我们设计团队的核心任务。

他们主要干什么：

• 能上手做出可用的 MVP 和体验原型。

• 把原型打磨成消费级的、让人用着开心的体验。

• 确保所有功能都和谐地统一在 HeyGen 的产品框架里，并建立和维护设计规范。

• 坚守我们的原则：简单到连我奶奶都会用。

• 主导简化的工作——如果我奶奶用着都费劲，设计师就得站出来解决它。

• 维护好设计系统，让未来的开发能保持一致和快速。

• 帮助把产品营销做得更简单易懂。

• 在功能被验证后，专注于视觉打磨和体验的一致性。

在 AI 时代的侧重点：

• 对市面上所有的 AI 工具了如指掌，并且每天都在用。

一个关键原则：为了保证速度，设计师的重点是在想法被验证之后，把体验做到极致，而不是在早期探索阶段就过度投入。他们是「简单到奶奶都会用」原则的守护者，这是一个在想法验证后，需要真正专业知识才能解决的巨大挑战。

数据科学家 & PM：分析搭档

数据科学家干什么：

• 解释和验证指标：确保大家对数据的理解是一致的。

• 做统计分析：相关性、因果关系推断等。

• 建立 PostHog 里搞不定的高级实验指标。

• 为成熟的功能搭建公司级的数据看板。

• 做需要高级 SQL/Python 的复杂分析。

• 做一些轻量级的数据工程和建模。

• 普及数据科学的知识和术语。

PM 干什么：

• 熟悉自己领域的核心数据，能发现异常并着手调查。

• 用 PostHog 看数据趋势和用户行为。

• 能从 Hex 的主表里拉一些简单数据。

• 主动管理实验的全过程，包括事前的测试和事后的清理。

• 设计实验方案——给谁看，怎么分组，成功的标准是什么。

• 想清楚需要埋哪些点来衡量效果。

• 初步判断实验哪个版本胜出。

• 理解自己领域的数据和公司战略的关系，能在发布决策时做出高质量的判断。

• 应该能自己在 PostHog 里做分析，在 Hex 里写简单的查询。

俩人一起干什么：

• 分析实验的影响——一起解读结果。

• 定义关键指标（比如 AER、留存、转化）。

• 当需要深入分析时，一起复盘实验。

• 调查数据异常。

4.3 平等的伙伴，但分工明确

PM 帮助定义「做什么」：

• 框定问题

• 定义目标

• 理清背景

工程师 确定「怎么做」：

• 和 PM、设计师一起设计方案

• 搞定可行性、权衡和执行

设计师 确保「简单易用」：

• 让复杂的 AI 人人可用

• 守住「奶奶测试」的底线

• 创造愉悦的体验

数据科学家 提供「事实」：

• 用数据验证假设

• 科学地衡量影响

• 指导实验的方法

所有人都要对「为什么做」有共识：

• 这事为什么值得做？

• 我们在为谁解决什么问题？

• 为什么是现在？为什么用这个方法？

• 这事怎么能帮公司往前走？

4.4 做原型的流程

理念：在传统的软件开发里，PM、设计师、工程师是「铁三角」。但在快节奏的 AI 时代，我们更关心速度和学习，而不是完美的流程。

灵活的搭档模式：PM 和设计师的合作可以很灵活。有些 PM 更懂体验，那就他来主导原型；有些设计师深谙 AI，可以主导原型开发。

两人原则：原则上，一个 PM/设计师，加一个工程师，两个人就能开干一个原型。我们不为了照顾每个人的情绪而去追求所有人都同意。我们来这是为了加速验证想法，好让我们能做出更好的产品。

每个人都有机会为新想法做原型。在 AI 时代，可以做的东西简直是无限的（就像我们在黑客松里做出的那些东西一样，太棒了）。关键是要有一个小而精的团队来快速做决定。

通用的方法：

• 原型先行：PM/设计师和工程师直接搭档，快速把想法做出来测试。

• 证明它行：在投入大量设计之前，先用真实用户验证这个想法。

• 设计打磨：一旦被证明可行，设计师再介入，把体验打磨好，确保它和整个产品风格统一且简单。

• 达到上线标准：任何一个从原型毕业要上线的功，都必须是经过精心设计的。

为什么这么做：AI 功能有巨大的不确定性，大部分原型可能都行不通。在没被验证的想法上过度投入设计，纯属浪费时间。但是，最终交到用户手里的东西，必须达到我们的质量标准。

产品团队：

比对手快 5 倍

5.1 他们干什么：构建和打磨产品的核心功能

核心产品团队，专注的是最基础的产品体验，那些定义了 HeyGen 是什么、能做什么的功能。他们追求的是极致的用户体验、完整的功能和长期的产品愿景。

核心产品团队的特点：

• 做复杂功能时，开发周期更长。

• 非常关注产品体验和用户走过的每一步。

• 强调设计系统和体验的一致性。

• 需要和整个产品生态系统打通。

• 我们虽然做的是个商业工具，但对于一个创意工具来说，让人用得爽太重要了，这也是 HeyGen 能不能做到一亿用户的关键。

5.2 核心产品的标准

标准很简单：每一个体验，都要做到绝对的最好。任何差一点的，都算不及格。怎么做到？比你的对手快 5 倍，迭代次数是他们的 5 倍。

5.3 追求零 Bug

我们的目标应该是零 Bug。我们还没做到，但这是我们的方向。你去用那些顶级的创意工具，比如 Canva、Figma 或者 CapCut，你几乎碰不到 Bug，因为创意工作对精确性要求极高。作为一个创意工具，可靠不是加分项，而是必需品，它关乎用户的信任和工作能否继续。

增长团队：

一切为了提升迭代速度

6.1 增长团队是公司的实验引擎

增长团队和核心产品团队的玩法不一样。我们是实验引擎，为速度、学习和影响力而生。我们所有的原则，都只为了一个目的：提升我们的迭代速度。

6.2 增长团队的核心原则

工程只是工具，产生影响才是目的。

我们不只是交付代码，我们交付的是结果。在 AI 时代，代码不值钱，影响力才值钱。别为了追求代码优雅，去过度设计一个没人要的东西。你要优化的，是「多快能产生影响」：做那些最重要的事（20% 的投入，带来 80% 的结果），一旦被证明有效，就迭代，当价值真正体现出来后，再把它打磨好。

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

那些稳赚不赔的实验，根本算不上实验。做实验的目的，是通过冒聪明的风险、赌大胆的假设来学得更快。要愿意快速犯错，这样你才能更快地找到正确的路。

6.3 增长团队的重心

增长 PM：实验的指挥官

• 和团队一起做决定。

• 对数据和学习循环负责。

• 深入理解用户痛点和业务影响。

• 清晰地定义问题和目标。

• 定义「做什么」——框定问题、定义目标、理清背景。

• 和工程师一起明确「为什么做」——为什么这事值得干？为什么是现在？

• 有强烈的行动偏好，快速发起实验。

• 对结果负责，不只是对产出负责。

增长工程师：速度机器

• 和 PM、设计师一起设计方案。

• 负责搞定可行性、权衡和执行，目标是做得更好、更快、更聪明。

• 在明确「为什么做」的同时，塑造「怎么做」。

• 以最快的速度把实验做出来。

• 痴迷于学习循环和数据。

• 深入理解问题，而不只是等着别人告诉他「要做什么」。

• 理解了「为什么」，就能成为一个更主动的参与者，用更少的迭代交付更多的价值。

• 关注多快能产生影响，而不是完美的架构。

• 打造能改变公司发展轨迹的实验引擎。

6.4 增长团队有什么不同

增长团队和核心产品团队玩的是两种完全不同的游戏。核心产品团队专注于构建和打磨功能，而增长团队专注于快速实验和学习。在这场游戏里，速度就是一切，我们所有的原则都为此服务。

如何沟通：

直接、异步、高效

核心原则：

• 异步优先：我们办公室在不同地方，所以尽可能用异步的方式沟通。

• 会议警报：如果团队里有谁一周开超过 3 个、5 人以上的会，就得亮红灯了。

• 时间花在哪：我们的时间应该花在做东西上，不是开会上。

• 线下见面：利用线下见面的时间，实现最高效的沟通和团队建设。

决策怎么沟通：

有了决定，马上在 Slack 里说清楚，指定一个人负责，明确完成时间。团队之间要完全透明。不仅要说计划，还要说为什么这么定。清楚地告诉大家，这个决定需要同步给谁。

反馈怎么给：

直接说。做得好就是好，不好就是不好。对事不对人。当你收到反馈时，记住：这是在说事，不是在说你。每个人都有进步的空间。

极力避免的「坑」

8.1 AI 开发七宗罪

追求完美的架构

• 花好几周去设计一个能「扩展」的架构。

• 扩展想解决的问题是：你只有 100 个用户。

• 你真正的问题是：还没人爱你的产品。
  

研究到瘫痪

• 「我们需要做更多用户研究。」

• 聊了好几个月，一行代码没写。

• 更好的办法是：先做错，快速学习，再做对。
  

对稳定「地基」的幻想

• 总等着 AI 技术「成熟」。

• 还用 2019 年的思路做东西。

• 现实是：它永远不会稳定，去驾驭浪潮吧。
  

共识的陷阱

• 所有人都同意 = 没人在乎。

• 要有强烈的观点，但也要乐于被说服。

• 有争论，说明你可能碰到了真正重要的事。
  

以质量为借口

• 「这个还没准备好。」

• 「我再打磨一下。」

• 自信地发布，然后快速改进。
  

「憋大招」式发布

• 偷偷摸摸开发 6 个月。

• 然后搞个盛大发布。

• 结果发现，你的对手早就发布、早就学到了。
  

沉没成本谬误

• 「我们已经投了这么多了。」

• 快速砍掉失败的项目。

• 庆祝你学到的东西，然后删掉代码。

8.2 什么时候才应该真正慢下来

质量红线（没得商量）：

• 那些让你无法从实验中学到东西的 Bug。

• 安全漏洞。

• 明显伤害用户体验的功能。

• 影响到现有客户的破坏性改动。

战略性停顿（很少，但很重要）：

• 影响公司未来的「单向门」决策。

• 会影响未来 6 个月开发的技术架构决策。

• 当用户反馈告诉你，大方向错了。

• 法律或合规要求。

8.3 危险信号

如果你听到这些话，赶紧拉响警报：

• 「我们再多想想」 → 潜台词：我们已经落后了。

• 「我们得让所有相关方都同意」 → 潜台词：决策瘫痪要来了。

• 「万一技术变了怎么办？」 → 潜台词：它肯定会变，但我们还是得发。

• 「我们等下一个模型出来再说」 → 潜台词：我们的对手可不等。

• 「我们需要一个更稳健的方案」 → 潜台词：我们首先需要的是用户。

• 「这个还可以再打磨一下」 → 潜台词：先发出去，如果用户在乎再说。

怎么打赢这场硬仗？

9.1 我们为什么能赢

• 我们的发布速度比对手快 5 倍：更多的实验 = 更多的学习。

• 学习会产生复利，变成更好的产品：别人躲着走的东西，我们迎头赶上。

• 不确定性就是我们的优势：「老派」的竞争对手适应不了。

• 我们专注于真正重要的事：用户的质量，学习的速度，创新的差异化。

9.2 我们的七条「驾浪」原则（我们的追求）

• 快速行动，不妥协。

• 打造绝对最好的产品体验。

• 质量第一（尤其是视频的视觉质量）。

• 充分讨论，坚决执行。

• 拿不准？发个实验。

• 拥抱不稳定的 AI 开发——去驾驭浪潮。

• 通过整合来激发创新。

唯一不变的，

就是变化本身

三年前，我们根本想象不到 AI 今天能做什么，那时连 ChatGPT 都没有。三年后，我们今天觉得最牛的东西，可能也会显得很古老。唯一不变的，就是变化本身。唯一的策略，就是驾驭浪潮。唯一的目标，就是用户价值。

我们没有所有问题的答案，但我们有一样更好的东西：业内最快的学习闭环。

每一天，我们都面临一个选择：是去寻找虚假的稳定，还是去驾驭浪潮。我们选择后者。我们选择去打造那种能随着 AI 进步而奇迹般变得更好的产品。我们选择快速发布，更快地学习，并最终取胜。

欢迎来到软件开发的未来。让我们一起做点了不起的事。

记住，快但要稳；创意要能整合；速度得有方向。

赶紧上，别纠结，顺势而为。