夜雨聆风摘要：AI 创业最危险的变化，表面看是代码变便宜了，底层其实是错误想法也能被更快做成产品。Anthropic 这份 AI 原生创业（AI-native startup）playbook 最值得借鉴的地方，是把创业拆成四个检查点：Idea 看问题是否真实，MVP 看证据是否成立，Launch 看公司能否脱离创始人运转，Scale 看护城河是否开始沉淀。
5 月 14 日，Claude Blog 发布了一份新资料：《The Founder’s Playbook: Building an AI-Native Startup》。
如果只把它当成 Anthropic 的产品手册，会低估这份资料的价值。它真正有意思的地方，是把「AI 创业」这件事从一句口号，拆成了一套可以自查的创业生命周期。
过去创业有一条默认路径：先验证，再融资，再招人，再开发，再融资，再增长。每进入一个新阶段，团队要变大，技能要变多，资金压力也随之上升。
AI 把这条路径压扁了。
一个非技术背景的创始人，可以让 coding agent（编程智能体）写出可用产品；一个技术创始人，也可以让 AI 协助做市场研究、竞品分析、投资人材料和运营流程。创始人的角色开始从「亲自做事的人」，变成「编排系统的人」。
但这并不意味着创业变简单了。
相反，很多旧约束消失后，新的风险会更隐蔽。以前做不出来，至少能逼你慢下来想清楚；现在一个下午就能做出原型，反而更容易把「能跑起来」误认为「值得做」。
这篇不做新闻转述，也不逐章翻译。我们直接把 Anthropic 这份 playbook 压成一张创业者自查表：每个阶段，创始人要判断什么，AI 该做什么，最容易踩什么坑，以及什么时候可以进入下一步。
这张表的重点，是提醒创始人别把 AI 当成单纯的外包工程师。AI 可以放大执行，但方向、边界和取舍，仍然要由创始人负责。
一、Idea 阶段：先验证问题，再碰代码
Idea 阶段的目标很简单：确认你要解决的是一个真实、具体、足够频繁的问题。
这听起来像创业常识，但在 AI 时代反而更容易被跳过。因为 coding agent 太好用了。你脑子里刚有一个想法，就可以让它生成界面、写后端、接数据库，甚至顺手加上登录和支付。
Anthropic 在手册里提到一个老问题：很多创业公司失败，是因为做了没人真正想要的东西。AI 不会消灭这个问题，甚至会让它变得更快。过去，一个错误想法可能要几个月才暴露；现在，它可能先变成一个看起来很完整的产品，再把你带进更深的误判。
关键在于，原型只能帮助你获得证据，用户反应才是证据本身。
Anthropic 在 playbook 里反复强调：Idea 阶段不要急着让 Claude Code 写生产代码。AI 此时最适合做三类事情。
第一，帮你把问题假设变得可验证。
「合同审核太慢」这样的假设太宽泛，没法验证。更好的表达是：「中型公司的法务团队，因为红线版本散落在邮件线程里，每份合同审核要花 3 天以上。」
后者至少回答了四个问题：谁遇到这个问题，多久遇到一次，严重到什么程度，现在为什么解决不好。
这个阶段，你可以让 AI 不断追问：
这个问题具体发生在哪类人身上？ 他们现在怎么解决？ 他们为这个问题付出了什么成本？ 如果你的方案成立，哪些前提必须为真？
第二，帮你做反向研究。
创业者最容易犯的错，是让 AI 去证明自己已经相信的东西。你问「这个市场有多大」，AI 很容易给你整理出一份看起来很漂亮的 TAM/SAM/SOM（总可用市场/可服务市场/可获得市场）；你问「这个方向为什么有机会」，它也能快速列出一堆支持论据。
更好的问法是反过来：
站在竞品角度，为什么他们会赢？ 这个市场里有哪些失败案例？ 用户为什么可能根本不需要我的方案？ 哪些监管、技术或人口变化会让这个机会变小？
AI 在 Idea 阶段最有用的身份，是结构化的反方辩手；啦啦队这个位置，最好留空。
第三，帮你设计用户访谈和整理证据。
访谈要少问「你会不会用这个产品？」这种未来假设题，多问过去发生过什么：
上一次你遇到这个问题是什么时候？ 当时你怎么处理？ 花了多少时间？ 哪一步最痛苦？ 你最后有没有为解决它付钱？
访谈之后，再把笔记交给 AI 做两份清单：支持你假设的证据，以及挑战你假设的证据。如果第一份明显更长，还要继续追问：这是数据真的如此，还是你在提问和记录时只听见了自己想听的部分？
离开 Idea 阶段前，至少要能回答三个问题：
问题是否真实、具体、频繁？ 你的方案是否解决了验证过程中暴露出来的真实问题？ 你是否有足够信号，值得进入 MVP，避免只凭信念开工？
这一阶段最重要的纪律是：让 AI 帮你更慢地判断，别急着更快开工。
Idea 阶段自查清单：
我能说清楚谁在什么场景下反复遇到这个问题吗？ 我有没有主动寻找反面证据，避免只让 AI 证明自己是对的？ 我问用户的是过去真实行为，还是未来意愿表态？ 我是否知道竞品为什么可能赢？ 我是否能明确说出：现在进入 MVP 的证据是什么？
二、MVP 阶段：先写边界，再写功能
进入 MVP 阶段后，AI 的角色开始变化。
Idea 阶段，AI 主要是研究伙伴；MVP 阶段，Claude Code 这类 coding agent 会变成核心生产力。但这里有一个很容易被忽视的前提：你要先写清楚边界，再让 AI 写代码。
Anthropic 对 MVP 阶段的定义很克制：MVP 仍然是证据收集过程，只是你开始收集「解决方案是否成立」的证据。
这意味着 MVP 应该少追求功能数量，多追求真实用户行为：用最小、最聚焦的产品，让人真的留下来、付钱或推荐。
AI-native startup（AI 原生创业公司）在 MVP 阶段有三个高频坑，其中最容易被低估的是 AI 技术债。
AI 技术债会按复利累积
普通技术债，是为了速度暂时接受一些不完美，后面可以集中偿还。AI 技术债更麻烦，因为它往往来自上下文漂移。
如果你没有写清楚架构原则、依赖选择、代码风格、产品边界，每一次 Claude Code 会话都在重新猜你的系统该怎么长。单次输出可能能跑，十次会话之后，代码库就会变成一堆彼此不协调的局部正确。
所以 MVP 的第一个产物，最好先是一份上下文文档，再是代码。
在 Claude Code 里，这通常可以是 CLAUDE.md。里面至少写清楚：
这个产品解决什么核心问题； 目标用户是谁； 未来 6 个月的规模预期； 技术栈和依赖选择； 哪些东西暂时不做； 哪些架构原则不能破坏； 每次会话结束后要记录哪些决策。
这份文档的作用，是让 AI 每次开工前都能读到同一套项目记忆。它看起来像形式主义，实际更像防止系统长歪的护栏。
第二个坑是无摩擦的 scope creep（范围蔓延，即功能边界不断膨胀）。
过去加一个功能要花工程师一周，现在可能一个下午就能做完。于是每个新增功能看起来都很合理：这个边界情况也处理一下，那个小流程也加一下，再顺手做一个报表。
但 MVP 最怕的就是这种「每个局部都合理，整体开始失焦」。
在写代码前，你需要一份 scope document，明确三件事：
这个 MVP 做什么； 这个 MVP 明确不做什么； 用户给出什么证据，才允许你把某个新功能加进来。
当新想法出现时，先别问「这个功能能不能做」。更好的问题是：「是否有足够用户证据证明，没有它用户就无法获得核心价值？」
第三个坑是把早期热闹误认为 PMF（product-market fit，产品-市场匹配）。
朋友帮你转发、投资人介绍几个客户、Hacker News 带来一波流量，这些都可能让数据看起来很好。但早期热闹不等于产品-市场匹配。
Anthropic 提到几个更稳的判断方式。
比如 Sean Ellis test：问活跃用户「如果明天不能再使用这个产品，你会有什么感受？」如果超过 40% 的用户回答「非常失望」，这是一个有意义的 PMF 信号。
再比如 effort test：在 PMF 之前，你要靠频繁跟进、补贴、人工提醒，才能让用户回来；PMF 之后，产品本身开始拉动用户回来。你从「推着用户走」变成「被用户拉着走」。
所以 MVP 阶段的 AI 用法应该是：
用 Claude 帮你定义架构和 scope； 用 Claude Code 执行明确的产品决策； 用 Claude Cowork 管理用户反馈、访谈排期和每周总结； 用 Claude 帮你反向解读数据，专门找「看起来好，但其实不成立」的迹象。
离开 MVP 阶段要看的，是你是否有了真实 PMF 证据：留存、收入、推荐，至少有一个开始稳定出现。产品完整度可以继续补，真实需求信号要先出现。
MVP 阶段自查清单：
我的 CLAUDE.md是否写清楚了产品边界、架构原则和不能破坏的约束？每次 Claude Code 会话结束后，我有没有记录新增决策和假设？ 我有没有一份 scope document，明确哪些功能现在不做？ 用户增长里有多少来自真实需求，有多少来自朋友圈、投资人资源或一次性流量？ 如果三轮迭代都没有接近 PMF，我是否愿意回到 Idea 阶段重审假设？
三、Launch 阶段：公司要开始脱离创始人的手
MVP 阶段证明产品值得存在，Launch 阶段要证明业务值得增长。
这个阶段最大的变化，是创始人开始从资产变成瓶颈。
在 Idea 和 MVP 阶段，创始人待在每个循环里是好事。你需要最快的反馈、最细的判断、最强的上下文。但到了 Launch，支持请求变多，产品决策堆积，运营流程变复杂，如果所有事情都还要等你拍板，公司就会卡在你身上。
Anthropic 给 Launch 阶段的退出标准很清楚：
增长是可重复、可归因的。你知道用户来自哪些渠道，也能解释 CAC（获客成本）、LTV（用户生命周期价值）和回本周期。 产品能承受生产负载。基础设施、安全、合规和可靠性都经得起真实用户使用。 运营不再依赖创始人记得去做。支持、triage（问题分流）、sprint planning（迭代计划）、周报这些事情有流程和自动化。
这也是 AI 工具组合真正开始发挥组织杠杆的阶段。
Claude Code 该做的是技术债审计和生产化加固。
MVP 时为了验证速度做过的取舍，现在要集中清理。让 Claude Code 审计代码库，输出三类结果：
结构性脆弱点； 测试覆盖缺口； 必须重构的高风险模块。
然后再把这份清单交给 Claude 排优先级：哪些必须下个版本前修，哪些可以和功能开发并行，哪些可以暂时接受。
Claude Cowork 该做的是替代创始人的运营注意力。
你可以先让它做一份「创始人注意力审计」：
哪些任务每周重复发生？ 哪些决策总是卡在你这里？ 哪些流程只有你记得触发？ 哪些事情可以完全自动化？ 哪些事情需要人，但不一定需要你？ 哪些事情确实只能创始人判断？
这份清单很重要。Launch 阶段要让创始人从日常触发器里退出来，只处理真正需要自己判断的事情。
同时，安全和合规也要从「发布前检查」变成产品工作流。
只要你开始处理真实用户数据、支付、企业客户或受监管行业，安全风险就不再是理论问题。可以用 AI 先做代码级安全检查，比如认证和 session、API 数据暴露、输入校验、依赖漏洞。但这里要保留边界：AI 扫描只能辅助，不能替代合格的安全审计。
Launch 阶段最实用的一套 AI 工作流是：
Claude Code 审计技术债和安全风险； Claude 设计修复顺序和产品管理流程； Claude Cowork 运行周报、bug triage（缺陷分流）、用户反馈同步、sprint 节奏； 创始人只保留战略判断、关键客户、产品方向和重大取舍。
走到这里，AI-native startup 才真的开始像一家小而完整的公司。
Launch 阶段自查清单：
哪些决策本该一小时完成，却因为等我变成了一周？ 哪些支持、周报、bug triage（缺陷分流）、用户反馈同步还依赖我手动推动？ 技术债里哪些会影响下一轮增长，哪些只是暂时不优雅？ 安全和合规是否已经进入产品工作流，避免变成发布前临时补课？ 我是否知道增长来自哪些渠道，以及 CAC（获客成本）、LTV（用户生命周期价值）、回本周期这些数字？
四、Scale 阶段：把领域知识变成护城河
Scale 阶段，问题再次变化。
早期你在问：这个问题值不值得做？这个产品有没有 PMF（产品-市场匹配）？这家公司能不能增长？
到了 Scale，你要回答一个更尖锐的问题：如果一个资金更充足的大公司今天复制你的产品，用户为什么还会留下？
Anthropic 给出的答案很务实：护城河来自持续沉淀的深度。
这种深度有三层。
第一层：领域知识进入 AI 上下文
很多 AI-native startup 的起点，来自创始人对某个垂直行业的亲身理解。比如法律、医疗、采购、供应链、非营利组织募资。这些行业里有大量通用 AI 不懂的细节：术语、流程、监管、边界情况、用户真正讨厌的地方、看起来合理但实际行不通的解法。
Scale 阶段要做的事，是把这些创始人脑子里的隐性知识，变成产品可以读取、团队可以复用、AI 可以执行的结构化上下文。
这可以是：
行业术语表； 特殊场景测试集； 客户工作流模板； 领域 playbook； 可复用的 Claude Skills； 针对垂直系统的 MCP（模型上下文协议）集成。
Anthropic 在 PDF 里举了一个例子：通用医疗账单工具可能处理不好 340B 药品项目相关索赔，但如果你的产品专门为这个场景写了规则和测试，这就是垂直深度。
第二层：用户行为数据开始复利
用户长期使用你的产品，会留下行为信号：他们接受哪些输出，拒绝哪些输出，在哪些步骤反复修改，哪些工作流会沉淀下来。
这些数据有时间锁定效应。竞争对手可以买流量、招工程师、复刻功能，但买不到你和真实用户一起磨出来的行为指纹。
Scale 阶段可以让 AI 帮你做三件事：
审计你已经收集了哪些交互数据； 找出最高信号的行为模式； 设计反馈循环，把这些模式变成模型改进、产品改进或销售叙事。
第三层：工作流锁定
当用户只是登录你的产品，切换成本不高。当用户把团队流程、自动化、数据源、API、webhook、报表和培训都建在你的产品上，切换就变成一个运营项目。
这时候，AI 的任务重心要从「继续堆功能」转向「集成深度审计」：
前十大客户分别接入了哪些系统？ 哪些自动化跑在你的产品上？ 哪些团队流程依赖你的输出？ 哪类集成带来的留存最强？ 哪些客户还停留在浅层使用，可以继续加深？
Scale 阶段的创始人，也要继续把自己从日常运营里抽出来。Claude Cowork 可以承担更多财务报告、合规监控、合同管理、客户支持和 GTM（go-to-market，上市策略）流程；Claude Code 则补齐企业级客户需要的日志、监控、SLA（服务等级协议）、文档和支持基础设施。
这一阶段要证明的，除了产品能跑，还包括一家公司离开创始人的手，也能可靠运转。
Scale 阶段自查清单：
我的领域知识是否还停留在创始人脑子里？ 用户长期使用产品后，是否留下了能反哺产品的数据？ 我是否知道哪些集成最能提升留存和切换成本？ 如果大公司复制我的功能，用户留下来的理由是什么？ 公司离开我一周，哪些流程会停摆？
最后：AI 创业的核心问题变了
Anthropic 在 playbook 的结尾写了一个很关键的判断：AI 时代，创始人的工作没有变。你仍然要找到真实问题，做出解决方案，再把它扩展成一家重要的公司。
变化的是路径。
验证周期从几个月压缩到几个下午；工作原型不再依赖完整工程团队；发布准备从一次性冲刺，变成持续工作流；规模化时，很多过去必须靠早期招聘承担的运营重量，可以交给 AI 系统。
但瓶颈也随之迁移。
过去的瓶颈是你能不能做出来。现在的瓶颈是你选择做什么、何时做、做到什么程度，以及哪些事情必须由人判断。
所以，如果你正在做一个 AI 产品，可以直接拿这四阶段做一次自查：
Idea：我是在验证问题，还是只是急着做出原型？ MVP：我有没有写清楚架构、边界和 PMF 指标？ Launch：哪些事情还卡在我本人身上？ Scale：我的领域知识、用户数据和工作流集成，是否正在变成别人复制不了的深度？
AI 让一个人启动公司的可能性大幅提高。但更关键的是，它降低的是生产端门槛：产品怎么被做出来，第一次变得没有那么依赖完整团队。
真正能走远的 AI 原生创业公司，不会只是「一个人加一堆工具」。更准确地说，它是一套不断沉淀的系统：创始人负责判断方向，AI 负责放大执行，用户反馈负责校准现实。
从想法到护城河，中间真正要积累的，代码量只占很小一部分。更关键的是四样东西：验证过的问题、写清楚的边界、可运行的流程、持续变深的用户和领域上下文。
这才是这份 playbook 最值得带走的东西。
参考资料
Claude Blog：The founder’s playbook: Building an AI-native startup，https://claude.com/blog/the-founders-playbook，2026年 5 月 14 日 Anthropic：《The Founder’s Playbook: Building an AI-Native Startup》，2026 年 5 月