返回列表
💬 讨论题 · 🧠 阿头学

三幕式剧本的终结

这篇文章对“AI 时代企业软件创业应放弃楔子、直接奔终局”的判断很激进，但它对产品迭代加速的观察成立，对企业软件通用规律的外推则明显过头。
打开原文 ↗

2026-06-02 原文链接 ↗
阅读简报
双语对照
完整翻译
原文
讨论归档

核心观点

  • 旧 SaaS 剧本被正面挑战 作者把传统企业软件增长路径概括为“楔子切入—套件扩张—平台重构”，并判断这套依赖时间分层推进的打法正在失效，这个判断对 AI 原生工具赛道有现实解释力。
  • 真正被压缩的是产研节奏，不是全部商业成本 AI 确实让产品构建和功能扩展更快，所以第一幕和第二幕的边界在变模糊；但作者把“代码更便宜”推演成“整体公司扩张更容易”，这在企业采购、合规、集成、交付上并不成立。
  • “楔子已死”是最有争议也最容易误导的结论 楔子的价值从来不只是省研发资源，更是降低客户认知门槛和替换风险；对开发者工具也许可以更激进，但对 HR、财务、供应链等核心系统，楔子依然是有效商业武器。
  • 作者真正想强调的是野心溢价 文章表面在谈战略路径，实质在抬高“直接做大替代”的价值；在范式切换期，这种判断对吸引资本和人才确实有用，但它也天然偏向幂律叙事，而不是稳健经营。
  • Cursor 例子能说明窗口变化，不能证明楔子无用 Cursor 的确抓住了范式迁移窗口，但它并不是凭空从零替代一切，而是借助 VS Code 生态和 AI 编程体验形成突破；把它包装成“楔子无意义”的证据，论证并不严密。

跟我们的关联

1. 对 ATou 意味着什么、下一步怎么用：这提醒 ATou 在看 AI 产品时不能只问“切口够不够小”，而要问“这个团队有没有迅速吃下相邻工作流的能力”；下一步可以把现有关注项目按“楔子型 / 终局型 / 可快速套件化”重新分类。 2. 对 Neta 意味着什么、下一步怎么用：这篇文章适合作为“范式迁移期战略判断”的反例材料，因为它抓住了速度变化，却低估了商业复杂度；下一步可以把“开发成本下降”和“销售实施成本下降”拆开建模，避免被技术叙事带偏。 3. 对 Uota 意味着什么、下一步怎么用：它提供了一个很强的讨论框架——今天该做插件还是做系统；下一步可以围绕具体行业逐个判断，哪些赛道适合“全栈直取”，哪些赛道仍必须“楔子破门”。 4. 对三者都意味着什么、下一步怎么用：这不是一篇可以直接照单全收的行动指南，而是一篇用来校准“野心上限”的材料；最好的用法不是跟着喊“三幕式已死”，而是建立一个判断表：赛道窗口、迁移成本、GTM 摩擦、套件扩展速度分别如何。

讨论引子

1. 哪些行业里“楔子策略”真的失效了，哪些行业里它反而比过去更重要？ 2. 如果开发成本下降但采购和交付成本没降，创业公司到底应该更激进做全栈，还是更快做套件化楔子？ 3. Cursor 这类案例到底证明了“直接替代平台”正确，还是证明了“聪明借平台做升级”更有效？

过去，打造一家企业软件公司，通常有一套相当清晰直接的剧本。

第一幕：楔子（也就是拆分）

先从某个现有方案服务不足的功能点，或某个市场细分切入。在平台迁移的过程中，你会从旧平台里挑出一个功能，在新范式下把它做到好上 10 倍，并把这件事当作切入市场的楔子。

这个细分领域要足够大，能让公司较快扩张到数千万美元的 ARR，但又不能大到引来毁灭性的竞争。Statsig 最初从产品实验切入。Rippling 最初从员工入职和离职流程的编排工具切入。诸如此类。

大多数初创公司会花 3 到 5 年打造最初的产品，组建最初的 GTM 团队，然后把 ARR 做到 1000 万到 5000 万美元，再开始第二幕。

第二幕：产品套件

第二幕的重点，是推出相邻产品，让公司突破 1 亿美元 ARR。你不再只做单一产品，而是构建一整套产品。

Statsig 最初从实验产品起步，后来又加入了功能开关、会话回放、产品分析等等。Rippling 最初从薪资和 HR 工作流入手，也就是入职和离职，之后又补充了大量 HR、福利和招聘相关产品，为同一类采购方完善整套方案。

对能走到这一步的公司来说，这往往又需要 3 到 5 年时间。随着第一个产品扩张到 5000 万美元 ARR，你开始交叉销售第 2 和第 3 个产品。到了 1 亿美元 ARR 时，也许后面两个产品分别已经做到 1000 万和 100 万美元。这种套件化打法，打开了通往 2 亿到 5 亿美元以上 ARR 的可能。

第三幕：平台

最终局，是重新打包。随着体量和用户参与度不断累积，你最终会获得替换底层平台的许可。这正是那些正在把底层 “记录系统” 商品化的 “互动系统” 的基本逻辑。理论上，这就是你把持久、黏性极强的 ARR 做到 50 亿美元以上的方式。

把这套剧本速通

担心的是，这套三幕式剧本已经死了。世界变化得太快。

三幕式方法默认依赖一定的自然时间，尤其是在早期。创始人能做的事总归有限。先专注找到产品市场匹配，再建立早期 GTM 动作，然后扩大 GTM。之所以要等到 ARR 到了 1000 万到 5000 万美元才开始第二幕，是因为第一幕本身已经占满了全部注意力。

过去几年里，有那么多公司从接近 0 一路冲到 1 亿美元 ARR，比如 Cursor、Cognition、Clay、Harvey、Sierra、Baseten、Fireworks、Lovable 等等，这本身就说明世界已经变了。

现在已经没有时间对按部就班的策略精打细算了。随着软件工程成本断崖式下降，走完第一幕和第二幕所需的时间也在逼近零。更理性的做法，也许就是从一开始就打算尽快把整套东西都做出来。

野心

这件事对我做早期投资的方式，带来了相当深刻的变化。过去，会去找那个有保护作用的楔子，找那个能让公司安全做到 1000 万到 5000 万美元 ARR 的港湾。现在，楔子这种东西显得太小了。更想看到的是，人们直接跳进深水区。

比如，记得在种子轮阶段见过 Anysphere，也就是 Cursor。当时他们的计划，好像就是直接替代 VS Code，因为 VS Code 对 AI 编程来说限制太多。那在当时看来简直疯狂。VS Code 那时深受喜爱。IDE 多年分裂之后，VS Code 终于赢了。一个种子阶段的公司，为什么要直接取代 VS Code？看起来，先做一个扩展，再慢慢赢得替代它的资格，显然更合理。

N.B. – 当时错了。现在再看，替代 VS Code 甚至都显得不够有野心。为什么只停在那里？

随着写软件的成本降到零，越来越看重的，是高于一切的野心。是不讲理的、毫不松懈的野心。

觉得三幕式剧本已经死了。在一个剧烈变化的时期，还想着依赖一个楔子，太保守了。如果真要做，那大概就该直接奔着整件事去。

There used to be a pretty straightforward playbook for building an enterprise software company.

过去，打造一家企业软件公司，通常有一套相当清晰直接的剧本。

Act I – The Wedge (aka Unbundling)

第一幕：楔子（也就是拆分）

Start with some feature or market niche that was underserved by current solutions. During a platform shift, you’d pick-off a feature of the existing platform that could be made 10x better in the new regime and use that as the wedge.

先从某个现有方案服务不足的功能点，或某个市场细分切入。在平台迁移的过程中，你会从旧平台里挑出一个功能，在新范式下把它做到好上 10 倍，并把这件事当作切入市场的楔子。

This niche needed to be large enough to scale to tens of millions of ARR quickly, but not so large that it attracted ruinous competition. Statsig started with product experimentation. Rippling started with an orchestration tool for onboarding and offboarding employees. Etc.

这个细分领域要足够大，能让公司较快扩张到数千万美元的 ARR，但又不能大到引来毁灭性的竞争。Statsig 最初从产品实验切入。Rippling 最初从员工入职和离职流程的编排工具切入。诸如此类。

Most startups would spend 3-5 years building the initial product, hiring the initial GTM team and then scaling to $10-50M ARR before starting Act II.

大多数初创公司会花 3 到 5 年打造最初的产品，组建最初的 GTM 团队，然后把 ARR 做到 1000 万到 5000 万美元，再开始第二幕。

Act II – The Suite

第二幕：产品套件

Act II was about launching adjacent products that let you scale past $100M ARR. Instead of a single product, you built a suite of products.

第二幕的重点，是推出相邻产品，让公司突破 1 亿美元 ARR。你不再只做单一产品，而是构建一整套产品。

Statsig started with experimentation but then added feature flags, session replays, product analytics and more. Rippling started with payroll and HR workflows (onboarding/offboarding) and then added a bunch of HR, benefits and recruiting-specific products to round out the offering for the same buyer.

Statsig 最初从实验产品起步，后来又加入了功能开关、会话回放、产品分析等等。Rippling 最初从薪资和 HR 工作流入手，也就是入职和离职，之后又补充了大量 HR、福利和招聘相关产品，为同一类采购方完善整套方案。

For companies that made it this far, this might take another 3-5 years of wall time. As the first product scaled to $50M ARR, you start cross-selling products #2 & #3. At $100M ARR, maybe the next two products are each doing $10M and $1M respectively. This suite approach unlocked the ability to to get to $200-500M+ ARR.

对能走到这一步的公司来说，这往往又需要 3 到 5 年时间。随着第一个产品扩张到 5000 万美元 ARR，你开始交叉销售第 2 和第 3 个产品。到了 1 亿美元 ARR 时，也许后面两个产品分别已经做到 1000 万和 100 万美元。这种套件化打法，打开了通往 2 亿到 5 亿美元以上 ARR 的可能。

Act III – The Platform

第三幕：平台

The end game is rebundling. As you accrue enough heft and user engagement, you would eventually earn the license to rip-and-replace the platform underneath you. This was the basic premise of all of the “Systems of Engagement” that were commoditizing the “Systems of Record” underneath them. This was how you – in theory – scaled to $5B+ in durable, sticky ARR.

最终局，是重新打包。随着体量和用户参与度不断累积，你最终会获得替换底层平台的许可。这正是那些正在把底层 “记录系统” 商品化的 “互动系统” 的基本逻辑。理论上，这就是你把持久、黏性极强的 ARR 做到 50 亿美元以上的方式。

Speedrunning the Playbook

把这套剧本速通

I fear the three-act playbook is dead. I think the world is moving too quickly.

担心的是，这套三幕式剧本已经死了。世界变化得太快。

The three-act approach implicitly relied on some amount of calendar time, especially in the early days. The founders could only do so much – first you were focused on finding product-market fit, then building out the early GTM motion, then scaling GTM. The reason you didn’t start Act II until you were at $10-50M in ARR was because you were still single-threaded on Act I.

三幕式方法默认依赖一定的自然时间，尤其是在早期。创始人能做的事总归有限。先专注找到产品市场匹配，再建立早期 GTM 动作，然后扩大 GTM。之所以要等到 ARR 到了 1000 万到 5000 万美元才开始第二幕，是因为第一幕本身已经占满了全部注意力。

The number of businesses that have gone from ~$0 → $100M ARR in the past couple of years (Cursor, Cognition, Clay, Harvey, Sierra, Baseten, Fireworks, Lovable, etc.) is evidence that the world has shifted.

过去几年里，有那么多公司从接近 0 一路冲到 1 亿美元 ARR，比如 Cursor、Cognition、Clay、Harvey、Sierra、Baseten、Fireworks、Lovable 等等，这本身就说明世界已经变了。

There’s no time to be precious about a step-by-step strategy. As the cost of software engineering plummets, the time to finish Act I and Act II also approaches zero. I think the rational thing to do is to just plan to build it all quickly, mostly from the start.

现在已经没有时间对按部就班的策略精打细算了。随着软件工程成本断崖式下降，走完第一幕和第二幕所需的时间也在逼近零。更理性的做法，也许就是从一开始就打算尽快把整套东西都做出来。

Ambition

野心

For me, this has caused a pretty profound change in my approach to early-stage investing. I used to look for the protective wedge – the harbor where you could safely get to $10-$50M ARR. Now, the wedge feels like small ball. I find myself wanting folks to just jump straight into the deep end.

这件事对我做早期投资的方式，带来了相当深刻的变化。过去，会去找那个有保护作用的楔子，找那个能让公司安全做到 1000 万到 5000 万美元 ARR 的港湾。现在，楔子这种东西显得太小了。更想看到的是，人们直接跳进深水区。

E.g., I remember meeting Anysphere (Cursor) at the seed. At the time, I think their plan was to just straight-up replace VS Code because it was too limiting for AI coding. This seemed crazy to me – VS Code was beloved at the time. After years of IDE fragmentation, VS Code had finally won. Why were you going to just straight-up replace VS Code as a seed-stage company? It seemed far more sensible to start by building an extension and then earn the right to replace it.

比如，记得在种子轮阶段见过 Anysphere，也就是 Cursor。当时他们的计划，好像就是直接替代 VS Code，因为 VS Code 对 AI 编程来说限制太多。那在当时看来简直疯狂。VS Code 那时深受喜爱。IDE 多年分裂之后，VS Code 终于赢了。一个种子阶段的公司，为什么要直接取代 VS Code？看起来，先做一个扩展，再慢慢赢得替代它的资格，显然更合理。

N.B. – I was wrong. Now, replacing VS Code almost feels under-ambitious. Why stop there?

N.B. – 当时错了。现在再看，替代 VS Code 甚至都显得不够有野心。为什么只停在那里？

As the cost of writing software drops to zero, I find myself valuing ambition above all else. Unreasonable, unrelenting ambition.

随着写软件的成本降到零，越来越看重的，是高于一切的野心。是不讲理的、毫不松懈的野心。

I think the three-act play is dead. Relying on a wedge in a period of rapid change is too timid. I think if you’re going to go for it, you should probably just go for the whole thing.

觉得三幕式剧本已经死了。在一个剧烈变化的时期，还想着依赖一个楔子，太保守了。如果真要做，那大概就该直接奔着整件事去。

There used to be a pretty straightforward playbook for building an enterprise software company.

Act I – The Wedge (aka Unbundling)

Start with some feature or market niche that was underserved by current solutions. During a platform shift, you’d pick-off a feature of the existing platform that could be made 10x better in the new regime and use that as the wedge.

This niche needed to be large enough to scale to tens of millions of ARR quickly, but not so large that it attracted ruinous competition. Statsig started with product experimentation. Rippling started with an orchestration tool for onboarding and offboarding employees. Etc.

Most startups would spend 3-5 years building the initial product, hiring the initial GTM team and then scaling to $10-50M ARR before starting Act II.

Act II – The Suite

Act II was about launching adjacent products that let you scale past $100M ARR. Instead of a single product, you built a suite of products.

Statsig started with experimentation but then added feature flags, session replays, product analytics and more. Rippling started with payroll and HR workflows (onboarding/offboarding) and then added a bunch of HR, benefits and recruiting-specific products to round out the offering for the same buyer.

For companies that made it this far, this might take another 3-5 years of wall time. As the first product scaled to $50M ARR, you start cross-selling products #2 & #3. At $100M ARR, maybe the next two products are each doing $10M and $1M respectively. This suite approach unlocked the ability to to get to $200-500M+ ARR.

Act III – The Platform

The end game is rebundling. As you accrue enough heft and user engagement, you would eventually earn the license to rip-and-replace the platform underneath you. This was the basic premise of all of the “Systems of Engagement” that were commoditizing the “Systems of Record” underneath them. This was how you – in theory – scaled to $5B+ in durable, sticky ARR.

Speedrunning the Playbook

I fear the three-act playbook is dead. I think the world is moving too quickly.

The three-act approach implicitly relied on some amount of calendar time, especially in the early days. The founders could only do so much – first you were focused on finding product-market fit, then building out the early GTM motion, then scaling GTM. The reason you didn’t start Act II until you were at $10-50M in ARR was because you were still single-threaded on Act I.

The number of businesses that have gone from ~$0 → $100M ARR in the past couple of years (Cursor, Cognition, Clay, Harvey, Sierra, Baseten, Fireworks, Lovable, etc.) is evidence that the world has shifted.

There’s no time to be precious about a step-by-step strategy. As the cost of software engineering plummets, the time to finish Act I and Act II also approaches zero. I think the rational thing to do is to just plan to build it all quickly, mostly from the start.

Ambition

For me, this has caused a pretty profound change in my approach to early-stage investing. I used to look for the protective wedge – the harbor where you could safely get to $10-$50M ARR. Now, the wedge feels like small ball. I find myself wanting folks to just jump straight into the deep end.

E.g., I remember meeting Anysphere (Cursor) at the seed. At the time, I think their plan was to just straight-up replace VS Code because it was too limiting for AI coding. This seemed crazy to me – VS Code was beloved at the time. After years of IDE fragmentation, VS Code had finally won. Why were you going to just straight-up replace VS Code as a seed-stage company? It seemed far more sensible to start by building an extension and then earn the right to replace it.

N.B. – I was wrong. Now, replacing VS Code almost feels under-ambitious. Why stop there?

As the cost of writing software drops to zero, I find myself valuing ambition above all else. Unreasonable, unrelenting ambition.

I think the three-act play is dead. Relying on a wedge in a period of rapid change is too timid. I think if you’re going to go for it, you should probably just go for the whole thing.

📋 讨论归档

讨论进行中…