原文：The founder’s playbook: Building an AI-native startup · Anthropic / Claude · 2026-05-14 完整 PDF：The-Founders-Playbook-05062026_v3.pdf
一句话导读：Anthropic 把 2026 年的创业方法论压缩成一句话——「能不能造」不再是边界，「该不该造」才是。Idea / MVP / Launch / Scale 四阶段被重新映射到 AI 原生时代，每个阶段都有自己的退出标准、失败模式和"AI 演练动作"。本文按原文骨架，逐阶段解读，并配上对应的信息图与真实公司样本。
引言：创始人这个职业，正在被悄悄改写
过去十年，创始人这个角色是由"能干什么"定义的：技术创始人写代码，业务创始人跑客户、扎运营。两边之间隔着一堵墙——一边是"会造的人"，一边是"有想法值得造的人"。
到了 2026 年，这堵墙被 AI 拆掉了。原文给出了一组对照：
- 从未写过代码的创始人正在交付生产级应用；
- “10 人独角兽"从一个励志故事，变成了可以认真规划的方案；
- 创业的传统增长弧线（验证 → 融资 → 招人 → 建造 → 再融资 → 增长 → 招更多人）正在塌缩——AI 抹掉了"每进入下一个阶段都必须更大团队、更多融资"的假设。
更核心的变化在创始人的注意力分布。Anthropic 用了一个非常精确的词：
“In an AI-native startup, the founder role becomes much less individual contributor and much more orchestrator of agents — specialized AI assistants that can read files, run commands, execute code, and even browse the web.”
也就是说，创始人不再是"做事的人”，而是"决定让 Agent 做什么、什么时候做、什么不做"的人。注意力上移——把精力转移到"只有我能做"的那部分判断上。
这本手册，就是给"想从第一天起就围绕 AI 重构公司"的创始人写的——它把整个创业生命周期重新铺开成四张地图：Idea / MVP / Launch / Scale。
下面我们逐张地图走一遍。
一、Idea 阶段：在写第一行代码之前，先把假设拷打 100 遍
创始人这阶段的本质问题： 这个问题真的值得我去解吗？
每个创业者都从同一个地方出发：一个让自己睡不着觉的问题。但 Anthropic 把这个阶段的目标定得很冷静——
Idea 阶段的目标不是"开始造"，而是"给问题—解决方案匹配（problem-solution fit）攒证据"。 攒的方式不是搭原型，是访谈、是研究、是把"我以为的需求"和"用户真实经历"做对比。
原文把这个阶段拆成四个递进问题：
- 这个问题是否真实、具体、足够频繁？
- 谁在经历它？这是一个市场吗？
- 有没有其他人在解？怎么解的？解得怎么样？
- 一个真正解决问题的方案需要做什么？我的想法能做到吗？
四个问题加起来，回答的是终极问题：这件事值得造吗？
手册给出的一个金句很值得抄下来：
“People struggle with expense reporting” 是一个观察。 “中型公司的财务经理每周花 4 小时以上对账，因为他们的工具不能和会计软件互通” 是一个可验证的假设。
具体性，是这个阶段唯一的硬通货。
1.1 这个阶段最致命的陷阱：把"能跑的原型"当成"假设被验证"
这是整本手册里最值得反复念的一段判断：
在 agentic coding 出现之前，已经有 42% 的创业公司死于"造了没人要的东西"。 而现在，造原型变得几乎免费——这个比例只会继续上升。
为什么 AI 让这个错误变得更危险？ 因为原型存在感太强了。一晚上你就能让 Claude Code 推出一个能跑的产品，看起来像那么回事——于是你会下意识地把"它能跑"当作"假设是对的"。
但这两件事中间根本没有因果。一个能跑的原型，不是任何东西的证据，它只是技术可行性的证据。
原文给的反例非常直接：
“The prototype becomes a reason to believe the hypothesis was right all along, without ever testing whether it’s actually true.”
1.2 这个阶段，AI 怎么帮你
手册的建议结构很统一：每条策略都给出一个具体的 Exercise。我挑几个最锋利的：
- 拷打你的问题陈述：把你写的"问题描述"丢给 Claude，要求它列出这条陈述里"具体性最差"的三个地方，然后用"谁、多久一次、严重程度、当前替代方案"四个维度逐一改写。
- 绘制竞争地图：让 Claude 把竞争格局画出来——不只是"谁在做"，还包括"为什么有人解决了一半就停了"。这往往是 “为什么这个问题难"的真正线索。
- 客户访谈外联（Cowork 出场）：交给 Claude Cowork 一份目标画像，让它自己拉名单、写个性化外呼、通过 MCP 接入 Gmail / Calendar 排期、按"D+7 还没回信就自动跟进"的节奏推进；你只负责出现在访谈里。
- 质疑你的解决方案：把方案描述丢给 Claude，让它找出方案最依赖的三个假设，每个假设各列出"成立的前提条件"和"如果不成立，会发生什么”。
- 最后才轮到 Claude Code：当方案已经被反复 stress-test，只造支撑核心交互的那一小块，丢给 5 个目标画像里的真实用户。这 5 段对话，决定你是继续往下走，还是回到画板。
1.3 离开 Idea 阶段的硬门槛
不是「感觉差不多了」，而是三个 yes：
- 问题真实且具体 — 你能说清楚谁经历它、多频繁、多严重、目前怎么对付；
- 方案对症 — 解决的是验证过程中揭露出来的那个问题，不是你最初以为的那个；
- 信号足以决策 — 你永远等不到"确定性"，但已有的证据让"决定造 MVP" 是一个理性决策，而不是信仰跳跃。
离开 Idea 阶段不是一次冲刺的终点，而是 AI 创业赛跑里真正的加速点：从这里开始你不是赌直觉，你是按证据执行。
二、MVP 阶段：不是造完整产品，是攒"产品被需要"的证据
创始人这阶段的本质问题： 第一版到底该造什么、不造什么？
很多创始人会把 MVP 当作"建造阶段"。Anthropic 不同意：MVP 阶段本质上仍然是收集证据，只不过对象从"问题"换成了"方案"。 你要回答的是——
一个明确的、可识别的人群，是否把这个产品用进了自己的日常？会回来？愿意付费？愿意推荐？
2.1 MVP 阶段同时要追三个目标
不是一个，是三个，互相牵制：
- 把验证过的问题翻译成最小可用的产品，让真实用户产生真实信号；
- 造的方式不能给未来挖坑 — AI 写的代码"能跑"不等于"可演进"，缺架构、没规范的代码库会在用户真正涌进来的那一刻原地崩塌；
- 从第一天就投资"持久上下文" — 在 AI-native 创业中，你的代码库是和 AI 会话接着会话协作的对象，可读性 / legibility 是基础设施。跳过 specs、跳过架构决策、跳过
CLAUDE.md，你会撞上一堵可以预测的墙：每个新会话都要重新解释一遍代码库，AI 生成的改动开始悄悄偏离原始设计。
2.2 这个阶段的两类高频坑
坑 1：把"build"当成"validate" — Idea 阶段没走完，跳过来直接造完整产品。判断方法很简单：你是不是在用"造更多功能"代替"做更多对话"？
坑 2：因为不懂安全而不安全 — 原文给的判断很直白：
“The hard truth is that agentic coding tools generate code that works, not code that is inherently secure.”
功能型 bug 有自然反馈（要么跑要么不跑），但安全漏洞在被利用之前是不可见的。Anthropic 给的最低门槛是：任何用户接触你的应用之前，先做一次安全审查。 这是把 MVP 放进真实世界之前的"最低责任阈值"。
2.3 这个阶段，AI 怎么帮你（关键动作）
① 在 Code 写一行生产代码之前，先用 Claude 定架构
打开的不是 Code，是 Claude。把你要造的东西描述给它——核心问题、目标用户、未来 6 个月的现实规模——让它帮你定下：
- 要遵循的模式；
- 要回避的依赖；
- 你有意识接受的妥协，以及为什么接受。
输出直接存成 CLAUDE.md。这是你创业第一天最该写的文档，也是后续每一个 Code 会话的"共同记忆"。
“Without this context, each session starts from scratch and Claude Code is forced to infer its own structural assumptions.”
没有这层上下文，Code 会自己脑补结构，代码能跑、但结构不连贯——你迟早被迫重写。
② 在数据到来之前，先定义"成功长什么样"
发布前就要明确：
- 留存基线、激活标准、Day 7 / Day 30 指标；
- 什么叫"假阳性"—— 比如「注册多但未激活」、「营收但无留存」、「初期热度但无重复使用」；
- 数据到了以后，让 Claude 替你做反方：一个怀疑论者会怎么解读这些数字？
③ 用 Cowork 接管反馈流水线
外呼、约会议、把 bug 报告分类、写每周综合简报——交给 Cowork。但收集环节里要留一个人：用户说"挺好，但我希望能也……" 时，你要判断这是核心需求还是 nice-to-have、是这个客户还是这个画像、是缺功能还是 onboarding 出了问题。这些判断没有 AI 能替你做。
2.4 离开 MVP 阶段的判断
Sean Ellis 测试：问活跃用户「如果你不能再用这个产品，会怎么样？」如果超过 40% 的人回答「非常失望」，这是有意义的 PMF 信号。
如果连续做了三轮迭代还没动指标，就让 Claude 当诊断医生：
- 数据里有没有一个反应明显不同的细分人群？
- “设计价值"和"体验价值"之间的差距，是定位问题还是产品问题？
- 要让当前产品找到真 PMF，需要什么前提条件成立？这些条件现实吗？
答案决定你微调、转向，还是回到 Idea 阶段。
三、Launch 阶段：从"产品该不该存在"到"生意该不该成长”
创始人这阶段的本质问题： 把零星牵引力做成可重复的增长引擎。
如果说 MVP 阶段是证明产品该存在，那么 Launch 阶段是证明业务该长大。原文给了三个退出条件，缺一不可：
- 增长是可重复的、按渠道驱动的 — CAC、LTV、回收周期，你能说得出，也守得住；
- 产品能扛真实生产负载 — 基础设施已硬化，安全合规已就位，可靠性在"你没测过的条件下"也成立；
- 运营不再需要创始人在场 — 客服、分诊、Sprint 规划、报表都已经系统化，你不是流程链上的某一环。
3.1 这个阶段的两个高风险
风险 1：技术债现在还得起，再拖就还不起了。 你的 MVP 代码可以工作，但需要一次系统性的"还债扫描"——用 Code 跑一次架构审计，找出脆弱点、捷径、测试覆盖薄的地方，再把审计结果丢给 Claude，让它分级排序：哪些必须在下一个 release 前修，哪些可以等下个 sprint，哪些是"当前阶段可以接受的债"。
风险 2：还没准备好就扩张。 新市场和新融资看起来像增长机会，但它们也是 PMF 死亡的地方。新市场带来新行为、新合规、新支付基建——你的数据信号会被打乱，你失去对自己数据的解释力，同时还会忽视让你走到今天的那批原始用户。
3.2 三件套合奏：1+1+1 > 3
这是手册里出现频次最高的一句结构性总结：
Claude Code builds the product, Claude Cowork builds the company around it, and Claude helps operationalize this product and organizational knowledge.
翻译过来： Code 造产品本身；Cowork 在产品周围搭起一家公司（招聘、客户成功、报表、外呼…）；Claude 把上面这两者沉淀进可被全员调用的知识资产。
这就是"极致精简创业模型"能成立的结构性原因——一支小队跑出n 倍规模公司的样子。
3.3 该自动化的，不只是任务，是"你的注意力本身"
这一段是整本手册里我最喜欢的一条建议——
让 Cowork 对你目前的运营负载做一次结构化审计：
- 每一项重复任务；
- 每一个总是落到你桌上的决策；
- 每一条只因为你还记得去做才发生的工作流。
然后让 Cowork 把它们分成三类：
- 完全可以自动化；
- 需要人做，但不必是你；
- 真的需要创始人判断。
清单出来之后，针对第 1 类让 Cowork 直接画工作流逻辑：触发条件是什么、决策规则、输出格式、产物去向。
这一步的意义不是"省时间"，而是把"只有你能记得"这种隐性依赖暴露出来——它是一切创始人式 bottleneck 的根。
3.4 把"安全和合规"做成一条长期产品工作流
不是一次性项目。用 Code 跑面向 SOC 2 / GDPR / HIPAA 的代码级扫描，让 Claude 把结果排成两份清单：修复优先级 + 企业客户审查会要的文档/控件。AI 扫描是辅助、不是替代 — 关键审查仍需合格的合规人。
四、Scale 阶段：让系统接管你的判断，让护城河从使用中长出来
创始人这阶段的本质问题： 我之所以是不可替代的，靠的不再是亲力亲为，而是什么是只有我们能积累的？
Scale 阶段的工作 ≈ (1) 把 Launch 阶段搭出来的系统养到可信，(2) 然后真的相信它们。
这件事比听起来难。放手太多太快，关键决策就会缺关键 context；抓得太紧，你又会重新变成瓶颈。
“The fundamental challenge here is identifying the institutional knowledge that lives only in the founder’s head or undocumented workflows, and then codifying it into systems that are documented, auditable and transferable.”
4.1 三重护城河（这一段是整本手册的"价值观"）
护城河 ①：领域深度（Domain Edge）
把行业里通用 AI 一定答错的细节，沉淀进你的产品逻辑——
“A generalist AI medical billing tool breaks on 340B drug program claims, for example, but yours has specific logic for them.”
具体做法：找一个泛化竞品一定会做错的 edge case，让 Code 把它写成一个真实场景的测试用例（不是单元测试，是场景测试）。每次再遇到类似 case，加进去。最后你的测试套件，就是你护城河的地图。
护城河 ②：数据飞轮（Data Flywheel）
用户在产品里每接受 / 拒绝一个输出，都在生成行为信号——这些信号反过来塑形产品路线图。这种"行为指纹"是时间锁 + 情境锁的：你买不到、抄不出、模仿不来。
让 Claude 帮你做三件事：
- 审计已积累的交互数据；
- 找出信号最强的三类行为模式；
- 为每一类设计一个"使用 → 系统性模型改进"的闭环；
然后还可以请它写一页"护城河叙事"——讲清楚这条飞轮转了多久、为什么一个今天起步、资源更多的对手也要 2 年才能复制。
护城河 ③：工作流锁定（Workflow Lock-in）
最深的锁定不是数据，是客户在你的产品上"长"出了他们的业务流程：
- 提示词为你的输出形态训练；
- 工作流绕着你的 API 设计；
- 标准化输出已经进入了他们的下游。
切换从"产品决定"升级成"全员搬迁项目"——这才是稳定的高摩擦护城河。
具体动作：让 Claude 对 Top 10 客户做一次集成深度审计——他们在你的产品上跑了哪些自动化、依赖哪些原生集成、有哪些团队工作流穿过你的产品、估算他们的切换成本。然后让 Claude 找出整组数据的共性：什么类型的集成对你这个产品产生最深的锁定？还可以再做什么让"目前停留在表面"的客户走深？
五、案例：把这套 Playbook 真的跑起来的 9 家公司
原文把案例分散在最后的 Resources 章节，我挑出最能映射回四个阶段的几家，按"他们用 Playbook 的哪一格"重新排列：
① 领域深度做到极致：Carta Healthcare（医疗）
Claude 驱动其临床数据抽取平台，每年处理 22,000 例外科手术案例，把数据抽取时间砍掉 66%。这是一个用 AI 把高人力、强专业的工作"工业化" 的典型。
② 非技术创始人也能上场：Anything（平台）
基于 Claude + Agent SDK，已经帮 150 万用户在不写代码的情况下做出自己的软件产品。原文专门点了一句：有非技术创始人已经基于 Anything 做出了完整招聘平台并开始销售。这是这本手册"非技术创始人也能造生产应用"这条主线的最直接证据。
③ 三家 YC 入营公司用 Code 把 MVP 推上市：HumanLayer (F24) · Ambral (W25) · Vulcan Technologies (S25)
三家不同行业的 startup，把同一件事跑通了：用 Claude Code 把原型快速推到市场，再用 agentic 工作流把 AI 平台扩到生产规模。
④ Cogent（企业安全）：Claude 作为推理层，驱动覆盖整个漏洞生命周期的 Agent —— 调查、分诊、修复全自动化。 ⑤ Wordsmith / GC AI（法律）：律师转 CTO 的创始人路径——领域知识 + AI 引擎结合的标本。Wordsmith 用 Claude 做合同审阅、起草和文档审查；GC AI 把"公司专属 playbook / 跨职能 stakeholder / 风险容忍度"这种内部法律团队的实际工作方式编码到了 Claude 驱动的产品里。 ⑥ Airtree（运营）：把 Cowork 当作整个组织的运营中枢，让原本散在十几个工具里的数据汇到同一个工作面。一个人做出来的 workflow skill，全公司都可以调用——这条是组织赋能的范式。 ⑦ Duvo（供应链）：完全基于 Claude，用 Agent SDK 编排跨 ERP / 供应商门户 / 表格 / 邮件 / 甚至电话的采购、供应链、品类管理流程。 ⑧ Zingage（居家护理）：用 Claude 的结构化工具调用横跨 EMR 与多通讯渠道，再用 Claude 的语境推理让 Agent 跳出"模式匹配最常见回应"，给出针对每位患者的个性化结果。 ⑨ Kindora（公益）：一位非营利组织高管用 Claude Sonnet 做出了"为公益组织智能匹配资助方"的工具——把上千个匹配筛到几个真正值得追的，并通过 MCP connector 让非营利组织直接在 Claude 里使用这套工具。
把这 9 家放在一起看，能看到同一条主线：
AI-native startup 的胜出点，不是"用 AI 替代专业知识"，而是"用 AI 把专业知识无限放大"。
六、写给创始人的几句私货
读完整本手册，我把它压成了三句给自己听的话，分享在最后：
1. 工作方式正在反转：先想清楚，再让 Code 写。 过去十年的创业心法是"快速做、快速错、快速改"。现在不是。原型成本趋近于零之后，“判断"才是稀缺资源。先用 Claude 拷打你的问题，再用 Cowork 把外呼自动跑起来，最后才打开 Claude Code——这个顺序，不是工程顺序，是创业顺序。
2. CLAUDE.md 是创业第一天最重要的文档。 不是 README，不是 BRD，不是 OKR。是一份让你和 AI 会话接着会话共享同一份记忆的文档。它决定你的代码库会不会半年后崩塌，决定你的下一位"AI 同事"上手要不要重学一次。
3. 不要再用"人头"做进度指标了。 旧世界里，「招了几个工程师」「招了几个销售」是组织成熟度的代理变量。新世界里，编排了多少个 Agent、自动化了多少类决策、沉淀出多少可复用的 Skill——这些才是。
回到 Anthropic 在原文结尾给的那句总结：
“In the AI era, the founder’s job hasn’t changed: find a real problem, build something that solves it, and scale it into a company that matters. What’s changed is the path to get there. Across the four stages—Idea, MVP, Launch, and Scale—AI compresses quarters into weeks.”
真正的瓶颈，从来都不是"能造什么”，而是"该造什么"。
只是过去这一点被掩盖了，因为"能造什么"足以筛掉 99% 的人。现在那道筛网被 AI 拆掉了——判断力、专业深度、对问题的真实理解，开始成为唯一的护城河。
这本手册之所以值得一读，不是因为它告诉你"用哪个 AI 工具"，而是它把这件事说得很清楚：
做创始人最朴素的部分，从来没变；变的是你身边的工具，和你不得不更早做出的那些决定。
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
