五家公司冲到 1 亿 ARR，打法完全不同：AI-Native GTM 手册读后，真正变了的只有三件事

📌 原文系列：The AI-Native GTM Playbook, Part 1–3 — Toby Daniels / ON_Discourse Part 1（五个案例）：https://ondiscourse.substack.com/p/the-ai-native-gtm-playbook-part-1 Part 2（九个模式）：https://ondiscourse.substack.com/p/the-ai-native-gtm-playbook-part-2 Part 3（定价）：https://ondiscourse.substack.com/p/the-ai-native-gtm-playbook-part-3

一句话结论：这个系列拆了五家冲到 1 亿 ARR 的 AI 公司，总结出九个可复制的模式。我读完的判断是，九条里有六条是 SaaS 时代的老道理换了新词。真正因为 AI 而改变的只有三件事——品类命名从营销动作变成了采购前提；商业模式必须和产品同时出生；你的第一个读者不再是人。剩下的部分与其说是打法手册，不如说是五份幸存者传记。

先说清楚这三篇值不值得读：值得，但不是因为它给了答案，而是因为它把问题问对了。作者 Toby Daniels 的素材来自五家公司的公开资料、两场 Chatham House 规则下的从业者闭门圆桌，以及他自己从零做一个 AI 产品的实战。这个组合让第三篇（定价）成了全系列最扎实的一章——因为只有闭门场合，人才会说自己模型的成本敞口。

---

先承认一件事：一半的案例根本不可复制

五个案例：Hugging Face 送出开源基础设施再收编企业；Clay 靠用户在 LinkedIn 晒截图长起来；Writer 从第一天就卖给 CIO 办公室；Legora 死磕法律垂直、先拿下顶级律所让同侪压力替它销售；Sierra 靠 Bret Taylor 的个人品牌直接打给 Fortune 50 的 CEO。

作者在每个案例后面都诚实地写了一节「什么会打破这套打法」，这是全系列最好的写作纪律。但这一节也暴露了尴尬：Sierra 那条的前提是你得是 Bret Taylor；Hugging Face 那条的前提是你有十年跑道去先送后收。这两条不是方法，是禀赋。

Clay 的数据其实最说明问题：2025 年 1 亿 ARR，两年前才 100 万，而在那之前是六年只有约二十个客户每月付两百美元的日子。圆桌上一位认识创始人的从业者补了一句：所谓”八年一夜成名”低估了它离归零有多近——是五次濒死，不是一次。这句才是这个案例真正的信息量，而它恰恰是最不可复制的部分。

那读这类 playbook 的正确姿势是什么？

不是抄动作，是先做减法。把每条经验放回它的前提条件里，问一句”这个前提我有吗”。没有的直接划掉。

划完剩下的才是你的清单。通常短得可怜——但短的那份是真的，长的那份是安慰剂。这是我从这三篇里拿到的第一个、也是最元层面的收获：看完九条觉得受用，往往是因为你把不属于你的前提也一起借用了。

---

第一件真的变了的事：命名品类不再是营销，是采购的前提

SaaS 时代命名品类是为了差异化——你不命名也能卖，无非卖贵一点或便宜一点。AI 时代不一样：买家的采购系统里没有对应的科目。你不给它一个名字，采购单就开不出来。作者引了一位从业者的原话，大意是”我们在造一个根本不是品类的东西，它不曾存在，现在也不存在”。

这五家公司都必须先造名字才能开单：企业生成式 AI（Writer）、collaborative AI（Legora）、agent operations（Sierra）、GTM Engineer（Clay）。

Clay 这一步走到了极致。它命名的不是产品品类，是一个岗位，还配了认证课程。现在有数千人把 “GTM Engineer” 写进了自己的 LinkedIn 头衔。

这一步的含金量在于它换掉了护城河的性质。SaaS 的留存靠切换成本——数据迁移麻烦、流程重建麻烦，本质上是给客户公司增加摩擦。Clay 的留存靠个人职业身份：你没法开除一个岗位名称就是你产品的人。它锁的不是公司，是人。这比任何数据锁定都硬，而且成本是零——是用户自愿把你写进简历的。

可执行的最小动作：如果你在造一个新东西，先回答一个问题——“客户的财务系统里，这笔钱记在哪个科目下？“答不上来，先别急着做 demo，先想名字。名字的验收标准不是好不好听，是买家能不能把它写进预算表。

---

第二件：商业模式必须和产品同时出生

过去十五年 PLG 的全部肌肉记忆是”先拿用户，后想收钱”。这套逻辑成立的唯一前提是边际成本趋近于零——多一个免费用户几乎不花钱。AI 把这个前提删掉了：每个用户从第一天起就在烧真金白银的 token。

所以”尽早发布商业模式”不是纪律要求，是算术要求。这一条本身不难懂，难的是它的下一层。

第三篇指出了一个几乎所有 AI 创业公司都装作没看见的问题：你的成本曲线不在你手里。你的定价钉死在今天的 Anthropic / OpenAI 价格上。如果哪天上游为了要利润把单价翻倍——你的输出一模一样，成本翻倍——你要么自己吃掉，要么丢客户。今天市场上每一个 AI-native 定价模型，都内嵌了这个敞口。

圆桌上给出的解法，是我认为全系列最值钱的一条：AI 公司要么

• (a) 按成本加成卖含 token 的套餐，要么
• (b) 让客户自带上游合同，你只在工作流层收增值加价。

模型 (b) 反转了通常的转售陷阱：客户承担 token 成本的波动风险，你保住自己真正创造的那部分利润。作者说目前几乎没人干净地跑通这个模式，但它可能是市场的最终落点。

我认为这条被严重低估了，因为它表面上是定价技巧，实质上是风险结构设计——你在决定把哪一部分不确定性留给自己。

• 选 (a)：你在做一门赌上游不涨价的生意。营收数字更漂亮，估值故事更好讲。
• 选 (b)：你在做一门只卖自己确实创造了的东西的生意。数字难看一点，但活得久。

顺带一提，这一章还留了个很诚实的反例：Claude Code 是 200 美元/月/席位，而同样的用量按 token 算要一万美元/月。所以”按席位收费已死”是个太顺口的结论。准确的说法是：按席位只在它比按量便宜得离谱时才活着。

同一章还有一条容易被略过但很实在的观察——空席位浪费才是客户真正的反对意见。抱怨不是哲学层面的（“按人头收费不合理”），而是运营层面的（“我在为没人用的席位付钱”）。所以任何能活下来的定价模型，都需要一个”你不用了我们就不收钱”的答案。按量收费之所以赢，不是因为它更公平，是因为工具冷掉时它会自动停止收费。

---

第三件：你的第一个读者不再是人

系列里最短、也最容易被跳过的一条：一位从业者在主页上放了个按钮，把自己的 API 文档直接交给访客自己的 agent——因为用户告诉他，Claude 比他本人更会解释他的产品。他的原话是：“营销就是 AI。”

这条的分量在于它改变了分发的第一触点。SEO 时代你要讨好爬虫；现在你要让买家的 LLM 能准确复述你。

区别在哪？爬虫抓的是关键词，LLM 抓的是能不能把你的价值讲成一段连贯的话。它读不懂的东西，会在一次对话里被静悄悄地跳过——你连一个 404 都看不到，只是永远不会出现在那个人的候选名单里。

这是目前少数还敞着的窗口，而且对小团队和独立开发者格外友好：让 LLM 读懂你不需要预算，只需要你把文档写清楚。反过来说，如果你的产品只有你自己能讲明白，你已经悄悄退出了一个正在增长的渠道。

---

那剩下六条呢？旧酒，但也是酒

先窄后宽、创始人的不公平优势、公开吃自己的狗粮、depositioning（重构对手而不是为价格辩护）、工程师即销售、按结果 vs 按用量定价——这些在 SaaS 时代同样成立，换个词还是同一件事。

作者自己也诚实地承认了其中一条：广告代理行业追了二十年按结果付费，除了纯效果广告从来没做成过，AI 并没有解决归因问题。Sierra 的按结果收费之所以能跑通，是因为”已解决的客服案例”是一个离散的、CFO 能数能比能辩护的单位——大多数品类根本没有这样一个单位。

指出这一点不是批评。旧酒也是酒，只是你要知道自己在喝什么，才不会因为它换了个 AI 的瓶子就付十倍的价钱去学。

---

落到具体角色上，该拿走什么

独立开发者 / 小团队：只做第二和第三件事。想清楚名字（客户怎么把这笔钱记账）、让 LLM 读懂你（文档写清楚）。这两件都不花钱，而且是这个阶段唯一有杠杆的动作。

已有产品、正在找增长的团队：先做减法。把九条对着自己的前提条件划一遍，划完的清单大概率只剩两三条，那才是你能真动的。

做基础设施 / 协议的：认真研究模型 (b)。当你的成本在别人手里，把收益锚定在自己真正创造的那一层，是唯一稳的结构。

---

一个本地视角：这和 PGL 的分账结构是同一件事

Mycelium 这边设计 PGL 数字公共物品公约的分账时，用的是三角结构——Supplier（原作者）50-90%、Wrapper（体验包装者）0-40%、Seller（渠道）固定 10%。

读完第三篇我才意识到，这本质上就是把”工作流层加价”写成了制度：原作者拿核心能力那一层的钱，Wrapper 拿工作流包装那一层的钱，各自的收益对应各自真正创造的价值，而不是谁离收款口更近谁拿得多。

结论是同一个：当上游成本不可控时，唯一稳的做法是把自己的收益锚定在自己真正做的那部分事情上。

---

最该看的那篇还没写

系列的 Part 4 叫「What breaks」，还没发布。以我读完前三篇的感觉，那一篇的价值可能超过前三篇之和。

原因很简单：前三篇是五个幸存者的故事，而幸存者偏差是这类文章的结构性缺陷。同一时期一定有公司用了同样的打法——也去命名了品类、也先窄后宽、也发了定价宣言——然后死掉了。真正稀缺的从来不是”谁成了”，而是”用同样的打法，谁没成，为什么”。

在那篇出来之前，前三篇最好的用法是当问题清单，不是当答案清单。

---

FAQ

Q：这三篇只适合创业公司看吗？ 不是。第三件事（让 LLM 能读懂你）对任何做内容、做开源项目、做文档的人都成立。第一件事（命名）对任何要说服别人掏预算的人都成立——包括在公司内部申请资源。

Q：五个案例里哪个最值得细看？ Clay。因为它是唯一一个”命名岗位而不是命名产品”的案例，而这个动作的杠杆率最高、成本最低，且不依赖创始人禀赋。

Q：模型 (b)「客户自带 token 合同」现在能落地吗？ 作者说几乎没人干净地跑通。障碍在客户侧——让客户自己去签上游合同、自己管配额，是把复杂度推给了客户。可行的中间态是提供两种模式让客户选，把成本透明化本身当成卖点。

📌 Source series: The AI-Native GTM Playbook, Part 1–3 — Toby Daniels / ON_Discourse Part 1 (five case studies): https://ondiscourse.substack.com/p/the-ai-native-gtm-playbook-part-1 Part 2 (nine patterns): https://ondiscourse.substack.com/p/the-ai-native-gtm-playbook-part-2 Part 3 (pricing): https://ondiscourse.substack.com/p/the-ai-native-gtm-playbook-part-3

Bottom line up front: This series dissects five AI companies that crossed $100M ARR and extracts nine repeatable patterns. My read: six of the nine are old SaaS wisdom wearing new clothes. Only three things genuinely changed because of AI — category naming became a procurement precondition; the business model has to ship with the product; and your first reader is no longer human. The rest reads less like a playbook and more like five survivor biographies.

Is it worth reading? Yes — not because it supplies answers, but because it frames the questions correctly. Toby Daniels drew on public reporting about the five companies, two Chatham House–rule operator roundtables, and his own attempt to build an AI product from zero. That mix is why Part 3 (pricing) is the strongest chapter: only behind closed doors will operators admit what their cost exposure actually is.

---

First, admit that half the cases can’t be copied

The five: Hugging Face gave away open-source infrastructure and inherited the enterprise. Clay grew on users posting screenshots to LinkedIn. Writer sold to the office of the CIO from day one. Legora refused to leave the legal vertical, landed the most prestigious firms first, and let peer pressure sell for it. Sierra used Bret Taylor’s personal brand to get Fortune 50 CEOs on the phone.

The author honestly appends a “what breaks this playbook” section to every case — the best writing discipline in the series. But those sections expose the awkward part: Sierra’s move presupposes you are Bret Taylor. Hugging Face’s presupposes a decade of runway to give away first and monetize later. Those aren’t methods. They’re endowments.

Clay’s numbers make the point best: $100M ARR in 2025, $1M two years before that — and before that, six years with roughly twenty customers paying $200/month. One operator who knows the founder added that “eight-year overnight success” undersells it: five near-death moments, not one. That’s the real information in the case, and it’s precisely the part you cannot copy.

So what’s the right way to read a playbook like this?

Not by copying moves. By subtracting first. Put each lesson back inside its precondition and ask: do I have that precondition? If not, cross it out.

What’s left is your actual list. It’s usually depressingly short — but the short one is real and the long one is a placebo. That’s the most meta thing I took from the series: finding all nine patterns useful usually means you borrowed preconditions that aren’t yours.

---

Change #1: Naming a category is no longer marketing — it’s a procurement precondition

In the SaaS era you named a category to differentiate. You could still sell without one; you’d just price a bit higher or lower. AI is different: the buyer’s procurement system has no line item for what you built. Without a name, no PO gets written. One operator put it bluntly: we’re building something that just is not a category — it didn’t exist, it doesn’t exist.

All five had to mint a name before anyone could buy: enterprise generative AI (Writer), collaborative AI (Legora), agent operations (Sierra), GTM Engineer (Clay).

Clay pushed this furthest. It didn’t name a product category — it named a job, and then certified it. Thousands of people now carry “GTM Engineer” in their LinkedIn headline.

What makes that move valuable is that it changes the nature of the moat. SaaS retention runs on switching costs — painful migrations, rebuilt workflows, friction imposed on the customer’s company. Clay’s retention runs on personal professional identity: you can’t fire someone whose job title is your product. It locks in the person, not the org. That’s harder than any data lock-in, and it costs nothing — users put you on their résumé voluntarily.

Smallest executable action: if you’re building something new, answer this first — in the customer’s finance system, which line item does this money come out of? If you can’t answer, stop building the demo and go work on the name. The acceptance criterion isn’t whether it sounds good. It’s whether a buyer can put it in a budget.

---

Change #2: The business model must be born with the product

Fifteen years of PLG muscle memory says “get users first, monetize later.” That only works when marginal cost is near zero — one more free user costs nothing. AI deleted that precondition: every user burns real money in tokens from day one.

So “launch the business model early” isn’t a discipline requirement. It’s arithmetic. That much is easy to grasp. The layer beneath it is the hard part.

Part 3 names the thing most AI startups pretend not to see: your cost curve isn’t yours. Your pricing is pinned to today’s Anthropic/OpenAI rates. If upstream doubles per-token pricing to start taking margin — identical output, double the cost — you either eat it or lose customers. Every AI-native pricing model in market has that exposure baked in.

The roundtable’s answer is, to me, the single most valuable idea in the series. An AI company can either

• (a) sell token-inclusive packages at cost-plus, or
• (b) let the customer bring their own upstream contract and charge a markup on the workflow layer only.

Model (b) inverts the usual reseller trap: the customer carries token-cost volatility, and you keep the margin on what you actually built. Almost nobody is running this cleanly yet, but it may be where the market lands.

I think it’s badly underrated, because it looks like a pricing tactic when it’s really risk-structure design — you’re deciding which uncertainty to keep.

• Choose (a): you’re running a business that bets upstream won’t raise prices. Bigger revenue numbers, better valuation story.
• Choose (b): you’re running a business that only sells what it genuinely created. Uglier numbers, longer life.

The chapter also leaves an honest counterexample: Claude Code costs $200/month per seat, where the same usage on tokens would run $10K/month. So “per-seat is dead” is too glib. The accurate version: per-seat survives only when it’s radically cheaper than usage.

One more easily-skipped but very practical observation from the same chapter: empty-seat waste is the real objection. The complaint isn’t philosophical (“charging per head is unfair”), it’s operational (“I’m paying for seats nobody uses”). Any pricing model that survives needs a we stop charging when you stop using answer. Usage-based wins not because it’s fairer, but because it self-terminates when the tool goes cold.

---

Change #3: Your first reader is no longer human

The shortest and most skippable item in the series: one operator put a button on his homepage that hands his API docs straight to the visitor’s own agent — because users kept telling him Claude explained his product better than he did. His words: “the marketing is the AI.”

This matters because it moves the first point of contact. In the SEO era you optimized for crawlers. Now you optimize so the buyer’s LLM can restate you accurately.

The difference: crawlers index keywords; an LLM indexes whether your value can be told as a coherent paragraph. What it can’t parse gets silently skipped inside someone’s conversation — you don’t even get a 404. You simply never appear on that person’s shortlist.

This is one of the few windows still open, and it’s unusually friendly to small teams: making yourself legible to an LLM costs no budget, only clear documentation. Conversely, if your product only makes sense when you explain it in person, you’ve quietly opted out of a growing channel.

---

What about the other six? Old wine — but still wine

Go narrow before wide. The founder’s unfair advantage. Dogfooding in public. Depositioning instead of defending price. Engineers as the new AEs. Outcomes vs. usage pricing. All of these held in the SaaS era too; new vocabulary, same substance.

The author concedes one of them himself: agencies chased outcomes-based pricing for twenty years and never made it work outside pure performance plays. AI didn’t solve attribution. Sierra’s outcome pricing works because a “resolved case” is a discrete unit a CFO can count, compare and defend — most categories simply don’t have one.

Pointing this out isn’t a criticism. Old wine is still wine. You just need to know what you’re drinking, so you don’t pay ten times to relearn it because it arrived in an AI-branded bottle.

---

What to take, by role

Solo devs / small teams: do only #2 and #3. Get the name right (how does the customer book this cost?) and make yourself legible to LLMs (write clear docs). Both are free, and at your stage they’re the only moves with leverage.

Teams with a product, hunting for growth: subtract first. Run all nine against your own preconditions; you’ll likely be left with two or three. Those are the ones you can actually move on.

Infrastructure / protocol builders: study model (b) seriously. When your costs sit in someone else’s hands, anchoring revenue to the layer you genuinely created is the only stable structure.

---

A local view: this is the same idea as PGL’s revenue split

When we designed the revenue split for Mycelium’s PGL (Digital Public Goods Charter), we used a three-role structure: Supplier (original author) 50–90%, Wrapper (UX packager) 0–40%, Seller (channel) a fixed 10%.

After Part 3 I realized that’s the “workflow-layer markup” idea written into governance: the original author is paid for the core-capability layer, the Wrapper is paid for the workflow-packaging layer, and each share maps to what that party actually created — rather than to whoever sits closest to the payment rail.

Same conclusion either way: when upstream costs are outside your control, the only stable move is to anchor your revenue to the part you genuinely do.

---

The most important installment hasn’t been written yet

Part 4 is titled “What breaks,” and it isn’t out. Having read the first three, I suspect it’s worth more than all of them combined.

The reason is simple: the first three are five survivors’ stories, and survivorship bias is the structural flaw of this genre. Companies in the same window ran the same moves — named a category, went narrow first, published a pricing manifesto — and died. What’s scarce isn’t “who made it.” It’s “who ran the same playbook and didn’t, and why.”

Until that piece lands, the best use of the first three is as a list of questions, not a list of answers.

---

FAQ

Q: Is this only useful for startups? No. Change #3 (be legible to LLMs) applies to anyone shipping content, open source, or documentation. Change #1 (naming) applies to anyone who needs someone else to release budget — including internally.

Q: Which of the five cases deserves the closest read? Clay. It’s the only one that named a job rather than a product category — the highest-leverage, lowest-cost move in the set, and the only one that doesn’t depend on founder endowment.

Q: Is model (b) — customer brings their own token contract — actually workable today? The author says almost nobody runs it cleanly. The friction is on the customer side: making them sign upstream contracts and manage quota pushes complexity onto them. The workable middle ground is offering both modes and treating cost transparency itself as a selling point.

---

© 2026 Author: Mycelium Protocol. Licensed under CC BY 4.0 — free to share and adapt with attribution. You must credit the author and link to the original; removing attribution and republishing as original is not permitted.