第 1 章｜创业生命周期：为 2026 年重新启动

AI 正在重塑创业公司的搭建方式。从没写过一行代码的创始人，今天已经可以把生产级应用送上线；而「10 个人的独角兽」也从一个小作坊式的励志故事，变成了一种有意识的战略选择。

2026 年的 AI 已经能够：

• 编写生产级代码
• 做市场调研
• 综合竞争格局分析
• 起草投资人材料
• 自动化运营流程

过去，即便是技术背景的创始人，要把一堆工具、平台和系统拼接起来去实现自己的想法，也要爬一段相当陡的学习曲线。AI 把这条曲线几乎抹平了。它带来的最深层变化是：「谁有资格开公司、谁能做产品」这件事被彻底拉平了。

2026 年，一个好的想法能把创始人带得比任何时候都远。Agentic Coding（智能体编程）把过去需要一整支工程团队几个月的工作，压缩成创始人自己就能交付的成果。

传统创业增长路径已经过时

传统创业公司的增长弧线大致是这样：

验证 → 融资 → 招人 → 开发 → 再融资 → 增长 → 继续招人 → 循环

这套路径默认每进入一个新阶段，就要：更大的团队、不同的技能组合、新一轮融资。

现在，AI 已经把这种预设擦掉了。

本手册把创业旅程重新映射为四个核心阶段——Idea（想法）、MVP（最小可行产品）、Launch（发布）、Scale（规模化）——并在每个阶段回答三个问题：

• 当 AI 是你技术与组织的核心基础设施时，这个阶段长什么样？
• 哪些工具是这个阶段的「最佳搭档」？
• 已经在用这些工具的创始人，是怎么把时间线压缩的？

如果你想画出从「一个想法」到「退出」之间最短的那条路径，请继续往下读。

第 2 章｜「创始人」这个角色，正在发生变化

过去，创始人是被「他能做什么」定义的：

• 技术创始人写代码；
• 非技术创始人跑业务、谈合同。

但 2026 年可用的模型、系统与 AI Agent，已经彻底拆掉了「会写代码的人」和「有好想法的人」之间那堵墙。

• 没有工程背景的人，可以做出真正能上生产环境的软件；
• 不太懂商业的技术创始人，可以快速搞出 GTM 策略、财务模型和一份漂亮的 pitch deck。

创始人角色的重心也在上移。

以前，创始人大部分时间在「执行」：写代码、管理人、处理琐碎运营。在一个 AI 原生创业公司里，创始人越来越少是「单打独斗的执行者」，而越来越像一个 Agent 编排者（orchestrator of agents）——指挥一群能读文件、执行命令、跑代码、上网检索的专用 AI 助手。

创始人的注意力被推向更高的层级：

• 产生想法
• 定义方向
• 指挥系统（AI Agent + 工具 + 小团队）去落地这些想法

而 AI 作为核心基础设施带来的最深刻变化，是让有领域专长但没有工程背景的人，也能成为创始人。当「能创业的人」不再局限于技术背景，你会看到一波由完全不同的人生经验背景的人创办的公司，去解决那些过去技术驱动的创业管线根本看不见的真实问题。

精益创业公司的三种 AI 能力

传统模式假设：你要招工程师来写代码、招销售来卖货、招运营来跑公司——人头数 = 组织成熟度的标志。

2026 年的早期创业公司则有意保持精简：常常只有创始人一人，或者一个三五人的小团队。借助以 AI 为基础设施的体系，他们可以在团队扩张之前就达成产品验证、早期收入，甚至盈利。

以下三类 AI 能力，让小团队跑出大公司的产能：

1. 对话式智能与研究：你的随叫随到专家

Think：永远在线的全领域顾问

想想第一年创业你几乎不可能事先就懂的所有事：怎么搞工资单？怎么规划产品 Sprint？怎么写一份紧凑的投资人 memo？

这些早期问题以前的答案都一样——找一个懂的人。要么花时间到处问、要么烧早期资金请顾问。

现在，AI 就是那个 24/7 在线的领域专家：

• 深度研究：竞品分析、市场规模、财务模型
• 文档起草：pitch deck、案例研究、投资人 memo、PRD
• 战略思考搭档：唱反调、做事前复盘（pre-mortem）、情景规划、路线图优化

2. Agentic Coding：永远在岗、永不阻塞的工程师

Think：那个从来不会请假的工程师

以前做软件，要么找技术联合创始人，要么外包，要么有足够长的现金跑道在写第一行代码之前就把工程团队组好。

Agentic Coding 工具让创始人可以用大白话描述要做什么，由 AI 来生成、测试、调试和重构整个生产级代码库——以一支完整工程团队的速度和规模。

「我有个想法」→「我有个产品」之间的时间，被严重压缩。创始人的精力回到该做什么、为什么做；至于这玩意儿真正怎么搭出来、能不能跑在真实用户面前，AI 来扛。

3. 工作流自动化：随用随有的运营团队

Think：全自动的后台运营

就算你已经能像顾问那样做研究、像工程团队那样写代码，还是有一大类「必须有人做」的事在等你：

• 安排日程
• 更新 CRM
• 拉周报
• 维护文档
• 发内容
• 跟进合规
• 维护工具之间的连接

在一家精益创业公司里，这些工作几乎全压在创始人头上——这是对「本应用在更高维决策上的时间和注意力」的一笔沉重税。

用 AI 做工作流自动化，正是用来减免这笔税的：CRM 自动跟随成交状态更新；周报自己生成；文档跟着产品一起演进。更关键的是，Claude Cowork 可以直接对接你公司在用的项目管理工具、沟通系统、数据源，不再需要单独有人去搭和维护这些集成。

时机和编排，才是真正的胜负手

会把 AI 的研究、自动化、Agentic Coding 这三大能力协调好的创始人，能以远超自己团队规模的杠杆去运作公司，并且把绝大多数时间花在真正重要的事情上。

但这一切不会自动发生。创始人需要知道：

• 什么时候该上哪种 AI 能力
• 怎么把它们串成一条完整的工作流

本手册剩下的部分，就是逐阶段拆解：你会遇到什么目标、什么挑战，以及在每个阶段该怎么用好这些 AI 工具。

第 3 章｜Idea 阶段：想法

每个创始人都是从同一个地方开始的：一个让你睡不好觉的问题。

Idea 阶段是「想法」与「现实」第一次正面交锋。2026 年要做成一家公司，需要一种新的纪律性——在证据足够之前，不要急着去 build。

这个阶段的工作主要是：

• 研究
• 客户访谈
• 竞争分析
• 诚实地评估那些「不利于自己想法」的证据

——这一切都发生在你让 Claude Code 写下第一行生产代码之前。

🎯 Idea 阶段的目标

核心目标：研究驱动的验证（research-oriented validation）。

在投入资源去做之前，先攒够扎实的证据，证明：

1. 这是一个真实存在的问题；
2. 你的方案能有效地解决它。

实践上，这个阶段是按顺序回答以下问题：

• 这个问题真实、具体、高频到足以围绕它建一家公司吗？
• 谁有这个问题？他们能构成一个市场吗？
• 还有谁在做类似的事？做得怎样？
• 一个真正能解决问题的方案，必须做到什么？我现在的想法做到了吗？

这些问题最终汇总成一个终极判断：这件事值得做吗？

这意味着，你得先把问题描述得足够具体，再开始动作。

❌「人们觉得报销很麻烦」——这是观察。

✅「中型公司的财务经理每周要花 4 个多小时去核对报销单，因为他们现在用的工具和会计系统不互通」——这才是一个可以被检验的假设。

✅ Idea 阶段的退出标准

退出条件：找到 Problem-Solution Fit（问题-方案匹配）。

你要能基于真实的人类对话积累出的定性证据，回答以下三个问题——并且每一个都答「是」：

1. 问题是真实且具体的吗？ 你能说清谁会遇到、多久遇到一次、严重程度多高、他们现在怎么对付。
2. 你的方案解决的是这个真实问题吗？ 不是你最初臆测的版本，而是验证过程揭示出的那个版本。
3. 信号足以支撑「开始动手」吗？ 这个阶段你永远不会 100% 确定，但应该有足够的定性证据让 MVP 是一个理性决策，而不是一次信仰跳跃。

⚠️ Idea 阶段的挑战

这是整个创业旅程中最重要的工作发生的地方，因为这里也是最具杀伤力的错误最容易发生的地方。Idea 阶段大多数的坑，本质上都来自一句话：你跑得比你的理解更快。

误把「在做」当成「在验证」

挑战：当技术门槛被搬走，狂热的创始人最容易跳过创业最关键的一步——验证。

哪怕在 Agentic Coding 出现之前，42% 的创业公司死于「做了没人要的东西」。现在 Claude Code 把「我有个想法」到「我有个产品」的距离严重压缩，这个失败率只会更高。

这是一个反直觉的危险：当 prototype 太容易做出来时，创始人会不自觉地把它当成「想法被验证」的证据——「你看，它都跑起来了，那它一定是个好主意吧？」

不。Prototype 本身不是证据。它只是和潜在用户对话时一个有用的压力测试道具。

真正的证据，来自这些对话本身。

过早 Scaling

挑战：当 build 几乎零成本，你很容易在「方向都还没验证清楚」的时候就把执行规模化。

Agentic Coding 工具太强了，强到你完全可能在没意识到的情况下，已经围绕一个错误前提搭了一整个代码库——而且 AI 会以同样的热情把它做得漂漂亮亮。

请记住：系统里的 intelligence 是你的，不是它的。 在这个阶段的最高准则是——让你的 sense-making 始终跑在 build 前面，尤其是当 build 变得这么轻松、这么快的时候。

客观性的丧失

挑战：你让 AI 找支持你的证据，它就一定能找到。Confirmation Bias 现在自带研究引擎。

创始人天然就对自己的想法有偏爱。AI 让这种偏爱有了「装备」：你叫它验证你的点子，它能找出证据；你让它估算市场规模，它能给你一个看起来能融资的 TAM。

解药是反过来用同一个工具：让 AI 狠狠地反对你。

当研究和结构化的对抗性思考揭示出你的想法需要修正时——这就是该转向（pivot）的信号。

🛠 Claude 怎么帮 Idea 阶段的创始人

这是一个研究和验证的阶段，所以你要拿出来用的是「让你更严谨地思考」的工具，而不是「让你赶紧动手」的工具。

三者底下是同一个 Claude，变化的只是它周围的工作台。

定义并压力测试你的问题假设

你的领域经验已经孕育出一个假设。第一步是把它磨到可被验证为止。

让 Claude 强迫你具体化：谁有这个问题？多久一次？多严重？现在他们怎么处理？回答不了这些问题的「问题陈述」，就不具备验证条件。

练习：和 Claude 一起把你的问题陈述打磨成一个可检验的假设。

❌ 「合同审查太慢了」——不能被检验。

✅ 「中型企业的内部法务团队，每份合同从开始到收尾要花 3 天以上，因为所有红线修改都散落在邮件线程里，而不是一个版本受控的文档中」——这就可以被验证。

下一步：让 Claude 来反对你——让它找出能反驳你假设的证据：失败的市场信号、阵亡的竞品、用户行为模式、结构性障碍。

📌 整个 AI 创业生命周期中，「让 Claude 当结构化的魔鬼代言人」都是核心用法。

市场研究与竞争格局

创业领域有个特殊现象叫 competitor neglect——专注做自己的事，结果系统性低估了别人在干什么。解药很直接：

让 Claude 替你的竞争对手做最有说服力的辩护——为什么他们会成功，而你不会。

练习：让 Claude 把你的竞争格局分层：直接竞品、间接竞品、潜在收购方、未来可能切进来的邻近玩家。再让它论证每一层为什么是真正的威胁——而不是你最容易反驳的那一版威胁。

• 让 Claude Code 从公开的用户反馈中提炼反复出现的抱怨与未被满足的需求——这等于免费做了一遍竞品的用户研究。
• 让 Claude Cowork 从厚重的行研报告、券商报告、市场分析文档里抽出关键事实和数字，再回头喂给 Claude 做综合分析。

练习：基于公开数据搭一个 TAM/SAM/SOM 模型，并对它的关键假设做压力测试。判断市场是在扩张、整合，还是已经成熟——这会影响你对时机和差异化的判断。再把买家图景搞清楚：谁有预算、谁影响决策、这两者是不是同一个人。

用 Claude 监听早期信号，判断你是不是踩在了对的时间点上：

• 关注那些用户已经在抱怨这个问题的 Reddit 板块和 LinkedIn 群组
• 注意用户描述自己困境时用的原话
• 找出类似市场里曾经解决过类似问题的案例
• 浮出可能加速或威胁这个机会的法规、技术、人口结构趋势

练习：让 Claude 找出三个会在未来两年显著影响你市场的外部趋势（法规 / 技术 / 人口），并判断每一个对你的具体假设而言是顺风还是逆风。

📌 市场研究和竞争分析不是一次性任务。 在 MVP 和 Launch 阶段，你的假设还会演化，每次演化都要把这些练习再跑一遍。

设计与执行客户访谈

你从潜在用户那里能学到什么，取决于两件事：问的问题有多好 + 问的人对不对。

精确的目标画像，比一长串联系人名单值钱得多。具体到职务、公司类型、团队结构、Seniority 级别——「最有可能切身遇到这个问题」的人长什么样。然后再确定这些人到底在哪里能找到：社群、活动、LinkedIn Group、Slack 工作区。

新手创始人最爱犯的错误是问一些面向未来的、开放式的问题：「你会不会用一个类似这样的东西？」——这种问法，得到的答案几乎全是噪音。

正确的问法是直接回到具体的过去：「跟我说说你上一次遇到这个问题时是怎么应对的。」

Claude 可以帮你审你的访谈提纲：

• 有没有诱导性的问题？
• 有没有问得太宽泛的？
• 有没有更可能引出「社交期望答案」而非真实答案的问题？
• 在最容易被「闪躲」的环节，要怎么准备追问？

如果你的假设涉及多个 persona，Claude 还能为每个 persona 设计不同的提纲。

练习：先自己手写访谈问题，再让 Claude 审查。要求它专门标出诱导性、面向未来、过宽、容易得到社交期望答案的问题，并对其中最可能引发闪躲的两三个时刻设计追问。

每次访谈结束，把笔记喂给 Claude，让它告诉你：哪里证实了假设、哪里挑战了假设、哪里出现了真正出乎意料的发现。每攒五场访谈，把全部笔记一起喂给 Claude Cowork，让它综合出重复出现的主题、矛盾点，以及正反两边的最强信号。

然后——这一步很关键——再把综合结果丢给 Claude 自己，让它判断：你对数据的解读，是不是在「往你希望听到的方向」上做模式匹配？

练习：每做完五场访谈，让 Claude Cowork 综合笔记，产出两份清单：「支持假设的证据」和「挑战假设的证据」。如果前一份明显比后一份长很多，问 Claude：这种不对称，真的来自数据本身，还是你的偏好？

让 Claude Cowork 承担「建联系人列表、批量外联、安排访谈」的运营负担：

• 基于你定义的目标画像，研究并整理一份带可核实联系方式的潜在受访者列表
• 按角色和上下文，批量起草个性化的外联邮件
• 通过 MCP 接入 Gmail 和 Google Calendar，自动处理回信、排期
• 按既定节奏发跟进邮件（比如第 7 天对没回的人发一次）
• 在你的跟踪表里同步每一步状态

练习：把验证过的访谈目标画像交给 Claude Cowork，让它：构建候选人列表 + 起草个性化外联序列 + 创建包含外联状态、跟进节奏、访谈完成情况的跟踪表。然后让它跑后台协调，你专心准备对话本身。

最终方案概念的设计

验证工作做完之后，你拥有的是：一个真实的问题，一群明确的人，一个被证据支撑的方案概念。

用 Claude 把这个概念从所有角度再揉一遍：

• 哪些地方有缺口？
• 还存在哪些替代方案？
• 这个方案要在规模上跑通，必须哪些前提成立？
• 这个设计真的在解决「验证过程揭示的问题」，而不是「你最初臆测的问题」吗？

练习：把你的方案概念交给 Claude，让它指出最依赖的三个假设。然后问它：每一个假设要成立必须满足什么？如果某一个不成立，后果是什么？

用 Claude Code 做一个轻量 prototype

现在终于到了能动手的环节。

这个时候你做的不是真正的产品，而是一个最小可触摸的「样品」——给真实用户一个可以摸、可以点的东西，让他们产生真实的反应。

真实用户对真实交互的反应，能告诉你十几场访谈都问不出来的东西。

练习：定义你方案中最核心的那一个交互，让 Claude Code 只把这一个东西做出来。然后把它放到五个目标画像里的真人面前，让他们试用。这五场对话决定了你接下来是继续往前走，还是回到设计板前。

走到 Idea 阶段的尾声，意味着你不再是凭直觉押注，而是在依据证据执行。接下来进入 MVP 阶段——创始人的引导问题从「这值得做吗？」变成「我们到底应该先做什么？」，而 AI 的角色也从研究伙伴换成施工队。

第 4 章｜MVP 阶段：最小可行产品

很多创始人把 MVP 当成「施工阶段」。其实它本质上还是一个收集证据的阶段——只是收集对象从问题空间，换成了解决方案：是否有一群明确的人，觉得它有价值到愿意使用、愿意回来、愿意付费、愿意推荐。

🎯 MVP 阶段的目标

核心目标：把一个被验证过的问题，翻译成一个真实用户愿意用的、能跑起来的产品。

这不是「装满路线图的完整版本」，而是把你的想法以最小、最聚焦的形式摆在真实用户面前，并由此产生关于 Product-Market Fit 的真实证据。

同时，MVP 阶段还有一个同样重要的第二目标：快，但不要欠下会复利的债。

而从 Day 0 起就投入 persistent context（持久上下文），是保证 AI 始终是「乘数」而不是「熵源」的关键。

在一家 AI 原生公司里，你和 AI 是在同一个代码库上跨多次会话协作的——这让「代码可被理解」成为基础设施。跳过 spec、跳过架构决策、跳过 CLAUDE.md，你迟早会撞上一堵墙：每次新会话都得重新解释整个代码库，AI 生成的修改和最初的设计意图渐行渐远。

✅ MVP 阶段的退出标准

真实的 Product-Market Fit 证据：一群明确的用户觉得这个产品有价值到——

• 愿意回来（留存）
• 愿意付费（收入）
• 愿意告诉别人（推荐）

⚠️ MVP 阶段的挑战

这个阶段，创始人最重要的两件事：速度 + 判断力。

Agentic 技术债

挑战：AI 移除了所有曾经控制「什么进生产环境」的天然瓶颈，速度被保证了。但如果速度成了唯一变量，你欠下的债将难以偿还。

一般技术债是渐进的，可以慢慢清，也可以单独排一个 Sprint 来清。AI 技术债是会复利的：

如果没有 spec 和架构约束被写在 AI 能读到的地方，每次会话都会从零再推演一遍最基础的决策，而那些决策会逐渐漂移。最后你得到的是一个——每一块单独看都不错，但整体上没有任何一致心智模型的代码库。

假性 PMF

挑战：AI 能让早期数字看起来很漂亮，但这不等于市场真的需要你。

发布初期的势能特别能给创始人「我早就知道我是对的」的心理高潮。但早期 traction 不等于 PMF：朋友、投资人推荐的人、Hacker News 头版冲来的一波——这些都是短暂力量。第 6 周、第 12 周以后还剩下什么，才是真正的答案。

零摩擦的 Scope Creep

挑战：当做一个新功能像「下午就能搞完」一样轻松，每一次增项都看起来合理；但合起来，你的产品会失去方向。

传统创业里限制 Scope Creep 的力量是工程时间的成本；现在这个限制几乎不存在了。解药是：在动手之前写下一份 Scope 文档，明确产品做什么、不做什么、以及「什么样的真实用户证据」才有资格让一个新功能进入产品。

这把决策从「我们要不要做这个？」改成「关键多数的用户告诉我们，没有这个功能他们就用不下去吗？」

因为不懂而不安全

挑战：创始人用 AI 工具把应用赶上线，却跳过了基础的安全实践，把用户暴露在本可避免的风险里。

硬道理：Agentic Coding 工具产出的是「能跑」的代码，不是「天然安全」的代码。 功能层面对错有反馈，安全漏洞却在被利用之前都是隐形的——没有自然反馈回路提示你哪里出错了。

在让任何真实用户接触应用之前做一轮安全审查，是把 MVP 推到世界面前最低限度的负责任标准。

🛠 Claude 怎么帮 MVP 阶段的创始人

先定架构，再开始 build

在 Claude Code 写下第一行生产代码之前，先用 Claude 定义并记录将统御整个 MVP 阶段的架构决策：要遵循的模式、要避免的依赖、有意识承担的 tradeoff，以及背后的原因。

练习：在打开 Claude Code 之前，先打开 Claude，描述你要做什么——它解决什么核心问题、为谁服务、未来 6 个月预期到什么规模。让它帮你定义 MVP 阶段的架构原则、要避免的依赖、当前阶段你有意识接受的 tradeoff。

然后把这份输出保存成 CLAUDE.md 文件。它是你这次 build 的第一个工件，也是后续每一次 AI 会话都要依赖的「持续记忆」。

定义并强制执行 MVP 范围

用 Claude 写一份范围文档：产品做什么、不做什么、「新增功能的准入标准」是什么样的真实用户证据。

当新功能想法浮现时——它们一定会浮现——用 Claude 压力测试一下：这是用户的真实信号，还是伪装成产品思考的创始人热情？

用 Claude Code 开搭 MVP

架构和范围定好之后，Claude Code 成为主要 Build 工具。但每一次会话都应该是「执行已经决定好的产品决策」，而不是又顺手往里塞新东西。

每次 Claude Code 会话开始时做两件事：

1. 回顾你的 Scope 文档
2. 把 CLAUDE.md 架构上下文喂给模型

结束时更新它，记录这次会话里出现的新决策。

练习：搭一个简单的 Claude Code 会话模板，包含：架构上下文文档、本次会话的具体任务、要遵守的约束或模式。每次结束写一段简短的日志，记录做了什么、做了什么决定、引入了什么假设。每场五分钟的文档化，是防止架构漂移变成不可收拾局面的便宜保险。

在任何用户上来之前，做一次安全审查

Claude 可以做一份对 AI 生成代码的一遍式安全检查，帮你发现常见漏洞。它不是安全工具的替代品，也不是高风险场景下人类评审的替代品。

Claude Code Security（在本电子书发布时仍处于受限 beta）可以扫描代码库找漏洞，并提出供人类审核的定向补丁。

练习：上线前用 Claude 把核心应用代码过一遍，明确要求：审查鉴权和会话处理、API 响应中的数据暴露、输入验证和注入风险、有已知漏洞的依赖。涉及鉴权、密钥、数据处理的，坚持人工 review。

在发布之前先搭好测量框架

那些把「早期 traction 当 PMF」的创始人，几乎都是上线后才开始选指标——而且选的指标用来证明「什么在 work」，而不是用来揭示「什么不 work」。

用 Claude 定义：哪些指标对你的产品真正重要、行业基准是什么、什么样的数据形态算真 PMF、什么样只是漂亮噪音。

• 在 MVP 发布之前就设定：留存基准、激活标准、Day 7 / Day 30 目标。
• 定义对你产品而言「假阳性」长什么样：只注册没激活、有收入没留存、初始热情但没复访……
• 当数据进来时，让 Claude 替怀疑论者说话：一个 skeptic 会怎么看这些数据？

用户反馈的运营管理

真实用户进入产品之后，运营层瞬间膨胀：建用户名单、跑外联、约反馈、分流 bug 报告、跟踪迭代周期。Claude Cowork 接管这一切。

但「人类要留在反馈解读环节」：当用户说「这挺好的，但我希望它还能……」，这是核心需求还是 nice-to-have？是个体诉求还是某个 segment 的代表？是缺一个功能，还是 onboarding 上游出了问题？这些问题没有工具能替你回答。

练习：让 Claude Cowork 来跑 MVP 阶段的反馈回路——给早期用户发外联、约反馈会、设计 bug 和 feature request 的结构化收集流程、写一份每周综述。先自己看综述，再让 Claude 检漏。

朝证据迭代，而不是朝「完整度」迭代

MVP 阶段的结束信号是「真 PMF 的证据」，不是「产品看起来完整了」。两个有用的判别测试：

• Sean Ellis 测试：问你的活跃用户：「如果你不再能用这个产品，会有什么感受？」如果超过 40% 的人回答「非常失望」，那是一个有意义的 PMF 信号。
• 力气测试（effort test）：PMF 之前，留存靠你不断推——频繁外联、激励、亲自跟、英雄主义般的能量。PMF 之后，产品开始自己拉着用户走。从「推」到「拉」的能量切换，是最清楚的信号之一。

当证据要求转向时，就转向

如果做了那么多还是到不了 PMF——这不是失败，这是系统在工作。MVP 阶段就是设计来让这种信息早点冒出来。

让 Claude 帮你思考：

• 是不是你最初选错了目标群体？也许真正契合的人群已经在你的数据里，只是被低估了。
• 是价值主张需要调整吗？相同人群，但 onboarding、信息、核心功能强调点需要被重新打磨。
• 是不是这个产品根本就需要更深层的转向？

练习：如果连续 3 轮以上迭代还达不到 PMF 基准，把留存数据、用户反馈、最初的问题假设一起喂给 Claude，问它三个问题：

1）数据里有没有某个 segment 的反应明显不同？

2）「设计价值 vs 体验价值」的差距，是定位问题还是产品问题？

3）现产品要拿到真 PMF，需要什么前提？这些前提在当下现实吗？

答案会告诉你：是微调、转向，还是回到 Idea 阶段。

第 5 章｜Launch 阶段：发布

MVP 阶段是在证明产品值得存在。Launch 阶段是在证明业务值得增长。

🎯 Launch 阶段的目标

核心目标：把早期 traction 转化为一个可重复、可持续的增长引擎。

同时要把产品下面的基础设施加固，并真正把一家「公司」搭起来。

在 Idea 和 MVP 阶段，公司天然是「创始人中心」——因为你需要保持完整的态势感知和紧密反馈循环。Launch 阶段，还试图把每根线都攥在自己手里的创始人，反过来会成为系统的瓶颈。目标不是把你从公司里拿掉，而是搭出运营系统，把你的注意力解放出来去做只有创始人能做的决定。

✅ Launch 阶段的退出标准

三件事都要做到：

1. 增长是可复制、由渠道驱动的：不只是留存，而是通过明确渠道可预测地获客，CAC、LTV、Payback Period 你都能说清楚并捍卫。
2. 产品能扛生产负载：基础设施加固、安全合规到位，可靠性在真实生产条件下稳得住。
3. 运营不再被创始人卡脖子：流程存在、自动化就位，你不再是亲自处理支持、分流、Sprint 规划、汇报那个人。

⚠️ Launch 阶段的挑战

找到 PMF 是早期创业最难的事；保住 PMF则是下一个难关。

技术债开始要利息了

MVP 阶段为了速度欠下的债，到 Launch 开始计息：生产流量、新功能、增长的复杂度，会把每一个捷径都暴露出来。

解决方案：系统性架构 Audit → 针对最严重问题做定向 refactor → 显著扩展测试覆盖率，防止下一轮功能开发把同样问题再引回来。

创始人变成瓶颈

MVP 时，「创始人在每个环节里」是优势；Launch 时，它变成约束。

典型征兆：本应 1 小时解决的决策拖了一周（因为要等你）；支持工单堆积，因为只有你知道答案；很多运营事项只在你恰好记起时才发生。

解决方案：对你「目前亲自做的所有事」做一次彻底的盘点——大事小事都列出来——区分：可以系统化、可以委派、真正只能创始人做。

安全与合规不能再延后

MVP 阶段，几个 beta 用户、生产环境里没有敏感数据，安全漏洞还是理论风险；Launch 阶段，这些立刻变成真实风险。处理用户数据、跑支付、卖给受监管行业——合规要求立刻适用。

下一波用户到来之前，把这件事当作必须做的整改项，而不是建议。

还没准备好就扩张

新市场和新融资机会看起来都像增长机会，但它们也是 PMF 死亡的常见地点。早期 traction 是真的，但它是特定于你最初的那群用户的。过早进入与之差异很大的新市场，会同时引入新用户行为、合规要求、支付基础设施和基准期望——你会瞬间多出太多新变量，连自己的数据都解读不了。

🛠 Claude 怎么帮 Launch 阶段的创始人

Claude、Claude Cowork、Claude Code 三者在 Launch 阶段全开火，并且彼此供料：一个工具的输出会成为另一个工具的输入。复利天然就会出现。

这就是「超精益创业」结构上之所以可能的原因：Claude Code 搭产品、Claude Cowork 搭围绕产品的公司、Claude 把这些知识运营化——一个小团队可以跑出一家「N 倍于自己规模」的公司。

技术债的早整改

先用 Claude Code 做一次完整架构 Audit：定位代码库的脆弱点、会变成维护成本的捷径、测试覆盖薄弱的位置。

然后把审计结果喂给 Claude，让它排序整改顺序：哪些必须在下一个版本前修、哪些可以再撑一个 Sprint、哪些是当前阶段可以接受的存量债。

这也是把你 MVP 阶段那些只活在脑子里的架构决策写进 CLAUDE.md 的时机：让每一次未来会话都建立在一个共享的「系统是怎么设计的、为什么这么设计」上。

练习：让 Claude Code 审你的 MVP 代码库，输出结构性弱点、测试覆盖缺口、可重构候选项的优先级清单。再把它丢给 Claude，让它把整改工作分布到接下来的几个 Sprint 里。

搭出替代「创始人注意力」的系统

要把注意力解放出来，先得知道它现在在哪。让 Claude Cowork 做一次结构化盘点：每个反复发生的任务、每个落到你桌上的决策、每个仅在你记起时才发生的工作流。

然后让它分类：可以完全自动化的、需要人但不必是你的、真正需要创始人判断的。最后由 Claude Cowork 设计每条自动化的触发条件、决策规则、输出形式和落点。

把安全与合规作为一条产品工作流

用 Claude Code 找出 SOC 2、GDPR、HIPAA 等标准下常见的代码层面问题，以及你目标市场要求的标准。把发现结果交给 Claude 来排序整改、设计审计日志、访问控制等企业买家会要的控制项。

注：AI 扫描是辅助，不是合格合规审查的替代品。

把合规作为开发周期里的持续工作流，而不是一次性项目。对要做企业销售或国际化的创始人来说，这也是用 Claude Code Security 准备独立安全评估的时机。

把你一直在跳过的产品管理流程立起来

Launch 阶段需要一套轻量、可重复、不需要创始人触发的流程。让 Claude 帮你设计：

• 产品时间线与 Sprint 节奏
• Claude Code 动手前一份 spec 必须包含什么
• Bug 报告怎么分流和派发
• 周度指标简报包括什么、发给谁

再让 Claude Cowork 把它们运转起来：开 Sprint 仪式、路由 bug、用接入的数据源生成每周指标、维护「用户信号 → 产品决策」的回路。

第 6 章｜Scale 阶段：规模化

Scale 阶段，创始人的角色从「Builder」重新中心化为「面向公众的高管」。产品依然是公司的中心，但你个人的日常工作越来越多地围绕着公司本身：分析师 briefing、IPO 路演、企业级合同……同时你还要保住那种「精益 + AI 中心」的结构性优势。

🎯 Scale 阶段的目标

• 系统化的增长：从几千用户做到几百万，从一个市场进入多个市场。
• 通过积累的深度建立护城河：你做进产品的领域专长、产品与用户依赖工具的集成深度、专有的系统数据与工作流。一直在同一个方向、同一套基础设施上稳定建造的创始人，到这个阶段拥有了别人很难复制的东西。
• 能扛外部审视：公众投资人、分析师、监管机构、企业采购、潜在收购方都会施加更大压力——产品和组织都要能撑住治理、合规、财务控制和战略叙事这几个维度的检查。

✅ Scale 阶段的退出标准

不再是单一里程碑，而是一种门槛事件：公司即使在创始人不再亲自跑日常的情况下，也是可持续的。

实践上，常表现为三种形态之一：

1. 可持续盈利，不再需要外部融资
2. IPO Ready
3. 被收购

⚠️ Scale 阶段的挑战

• 委派运营层：Scale 阶段的系统必须能在没人盯着的情况下稳定跑。这既是结构挑战，也是心理挑战。
• 扩大技术运营：客户开始不只是评估你的产品，而是要求你作为长期基础设施合作伙伴值得信赖——支持体系、文档、可靠性保证、SLA。
• 扩大组织职能：HR、薪资、会计、法务……
• 搭一个真正的 GTM 函数：早期靠创始人「下场卖」走得通，到 Scale 阶段会遇到天花板：用户曲线变平、CAC 上升、Pipeline 只在你亲自介入时才推进。

🛠 Claude 怎么帮 Scale 阶段的创始人

把日常事务交给 Claude Cowork

用 Claude 列出只有你应该做的事——产品叙事决策、董事会关系、企业合同、Founder-to-Founder 对话。不在这份清单上的，都是委派或自动化候选。

练习：让 Claude 画一张「瓶颈地图」：所有目前流经你的工作流 / 决策 / 审批。让它推演：如果你整周都不在，每条工作流会怎么样？卡住的那些，就是你还在亲手操盘到「会拖后腿」程度的地方。

把技术运营升级为企业级基础设施

• 用 Claude 起草并维护企业采购想看到的书面体系：产品文档、支持 playbook、SLA。
• 用 Claude Code 把代码库对照企业合同要求做加固，同时搭出日志、监控、事件响应、可观测性。
• 用 Claude Cowork 跑企业支持运营层：工单路由、升级流程、产品变更触发的文档更新、续约跟踪、企业客户成功的报告节奏。

练习：挑三家你最想签的客户，让 Claude 做差距分析：他们的采购团队签多年合同前期望看到什么文档 / SLA / 支持基础设施，你现在差在哪里？

搭一支真正的 GTM

• Claude：从零搭 GTM 资产——市场分层、信息架构、分析师关系策略、销售 playbook、面向公开市场投资者的指标叙事。
• Claude Cowork：成为战术执行层——内容流水线、外联序列、分析师 briefing 协调、PR 节奏、CRM 卫生、Pipeline 报告。
• Claude Code：搭产品营销基础设施——交互式 demo 环境、集成文档、Sandbox 租户、API 文档、技术 one-pager。一份做得好的 demo 环境，能在你坐在董事会里时自己关掉单子。

把领域专长和机构知识变成 AI 上下文

很多超精益创业的创始人，是为自己亲历的真实问题、在一个具体行业里造工具的人。Agentic AI 让没写过一行代码的人也能用领域专长解决复杂问题。

通过持续对话、项目、记忆，把你的所有领域知识——行业黑话、监管陷阱、边界案例、为什么显而易见的答案行不通——沉淀成一个结构化、可检索的上下文。Skills 把反复发生的工作流（「我怎么审一份商业租约」「我怎么分流一份病人录入表」）编码成可复用、每次都一样跑的程序。

几个月之后，这变成了一个专有知识基底——通用 AI 永远做不到。

练习：找出一个「通用竞争对手在你这个垂类一定会做错」的边界案例，让 Claude Code 基于你真实见过的场景，为它构建一个专门的测试用例（不是单元测试）。每次类似 case 出现，就加一个进去。你的测试套件最终会变成你护城河的地图。

把累积的用户数据变成可防御的优势

用户使用产品时会留下行为信号——他们接受哪些输出、拒绝哪些。时间一长，你会非常清楚这个用户群的偏好、模式、边界情况。这就是「复利价值」：产品改善 → 更多使用 → 更多反馈 → 更多改善。

这种数据时间锁定、上下文专属，无法被买回、无法被一夜复刻。

练习：把你产品的交互数据现状喂给 Claude——你在收集什么、收了多久、用户随时间怎么变化。让它指出三个最高信号的行为模式，并为每一个设计一条「持续使用 → 模型系统改进」的反馈回路。再让它帮你写一页「护城河叙事」用于产品营销。

制造工作流锁定

复利的数据网络效应让你的产品难以被复制；工作流锁定让你的产品难以被离开。

用户在产品里跑得越久，它就越深地嵌入到他们的日常运作里：搭在上面的自动化、训练好的人、对接好的数据源、为它磨好的 prompt 和工作流……此时切换不再是产品决策，而是一整个运营项目。

用 Claude 给现有客户按「集成深度」分层；用 Claude Code 快速搭原生集成、API、Webhook、SDK，让客户不只是「使用」你的产品，而是「在你上面建东西」——这是最深层的锁定。

练习：给你的前 10 名客户做一份工作流集成审计：他们搭了什么自动化、依赖哪些集成、有哪些团队流程跑在你的产品上、你估计他们的切换成本是多少？让 Claude 找规律：哪种集成对你的产品最有粘性？你能搭或开放什么，把那些「还停留在表层」的客户拉得更深？

第 7 章｜同样的工作，全新的规则

AI 时代，创始人的工作本身没有变：找到一个真实的问题、做出能解决它的东西、把它变成一家有分量的公司。

变化的是到达那里的路径。

在 Idea、MVP、Launch、Scale 四个阶段里，AI 把「季度」压缩成「周」：

• 过去要几个月的验证循环，现在一个下午就能跑一轮。
• 一个能用的 prototype 不再需要拥有合适技术栈的联合创始人，只需要一个清晰的问题和几次专注的 Coding Agent 会话。
• Launch 阶段的准备工作，从「上线前的临时冲刺」变成「贯穿始终的持续工作流」。
• 到了 Scale，过去被迫早早招人来救火的运营负担，可以越来越多地交给 AI——团队的注意力可以集中在那些会成为你护城河的判断决策上。

瓶颈不再是你能做什么，而是你选择去做什么。

第 8 章｜延伸资源

用 Claude 来 build

• Building AI Agents for Startups：创业公司如何用 Agent 让自己越长大越「不依赖创始人」。
• Claude Code Docs：从安装到高级 Agentic 工作流。建议从 How Claude Code works 开始。
• Claude Code Best Practices：上下文管理、权限、规划、验证工作流。
• 使用 CLAUDE.md 文件：MVP 阶段创始人必读，教你为代码库配置 Claude Code。
• Claude Code Power User Tips：来自 Claude Code 团队自身的工作流模式：并行会话、验证循环等。
• Get started with Claude Cowork：如何把 Skill、Plugin 等用起来。
• Tutorials：claude.com/resources/tutorials

创始人故事

• 三家 YC 创业公司用 Claude Code 搭出公司：HumanLayer (F24)、Ambral (W25)、Vulcan Technologies (S25)。
• GC AI：用领域专长把 Claude 用成一个真正贴合 in-house 法务工作方式的平台。
• Carta Healthcare：用 Claude 处理每年 22,000 例手术 case，数据抽取时间减少 66%。
• Anything：用 Claude + Agent SDK，帮 150 万用户把想法变成软件产品。
• Cogent：用 Claude 自动化企业级安全的调查、排序、修复全生命周期。
• Airtree：用 Claude Cowork 当作运营基础设施中心。
• Duvo：完全建在 Claude 上的采购 / 供应链 / 品类管理 Agent。
• Zingage：24/7 家庭护理代理。
• Kindora：智能匹配公益与捐助方的 AI 平台。
• Wordsmith：法律科技，Claude 作为合同审查与起草的推理引擎。

创业支持与机会

• Anthropic Startups Program：与 Anthropic VC 合作伙伴对接的创业公司，可享免费 API 额度、最高级别公开速率限制、专属创始人活动与工作坊。
• Claude Community：开发者论坛与社区。
• Live learning resources：会议、Webinar、直播与回放。