创始人手册：打造 AI 原生创业公司

记录时间：2026-05-17 译自 Anthropic 官方电子书 The Founder's Playbook: Building an AI-Native Startup（2026 年 5 月发布）完整 PDF 原文可从官方链接下载。本文为中文意译，便于个人留档检索，关键术语保留英文原文。

第 1 章重启 2026 的创业生命周期

AI 正在重塑创业公司的构建方式。从未写过一行代码的创始人，如今也能把生产级应用推上线；十人规模的「精益独角兽」也已经从草根逆袭的传说，变成了可以刻意设计的路径。

到了 2026 年，AI 能写生产代码、做市场调研、合成竞争格局、起草投资人材料，还能把日常运营流程自动化掉。从前即便是经验丰富的技术型创始人也要经历的工具栈、平台、系统集成的陡峭学习曲线，已经被 AI 抹平。AI 最大的贡献，是让「谁有资格创业、谁有资格做产品」这条线被彻底拉平。

在 2026 年，一个好点子可以把创始人推到比以前远得多的地方。Agentic coding 把过去需要一整支工程团队才能完成的事情，压缩到了一个人就能交付。

传统的创业增长曲线默认一条路径：validate → raise → hire → build → raise again → grow → hire more → repeat。AI 已经擦掉了「每进入新阶段就需要更大的团队、不同的技能、更新的融资轮」这条隐含假设。

这本手册按照新的现实，重新切分了创业旅程的四个核心阶段（Idea、MVP、Launch、Scale）。我们会讨论：当 AI 是技术与组织发展的核心时，每个阶段是什么样子；每个阶段应该用什么工具；以及这些工具如何在压缩时间线。如果你准备好绘制一条从想法到退出的最短路径，请读下去。

第 2 章创始人的定义正在改变

过去，创始人是按「能做什么」来定义的：技术型创始人写代码，非技术型创始人做业务、跑销售。到了 2026 年，模型、系统和 AI agent 已经溶解了「能 build 的人」和「有值得 build 的想法的人」之间那堵墙。

AI 原生创业公司正在从根本上改写「创始人」这个角色。一个完全没有工程背景的人，可以从零开始写出生产级软件，把想法落地；一个技术过硬但缺乏业务感知的人，也能写出像样的 go-to-market 战略、财务模型和投资人 deck。

历史上，创始人大部分时间都花在执行层：写代码、管人、处理日常运营。在 AI 原生创业公司里，创始人不再是 individual contributor，而更像 orchestrator——编排那些可以读文件、跑命令、执行代码、甚至上网浏览的 specialized AI assistants（agents）。创始人的注意力上移：从「亲自做」变成「产生想法 + 指挥系统去做」。

更具革命性的是：AI 把这扇门向那些不写代码、但有真实领域知识的人打开了。当创始人池不再局限于「写代码的人」，你就会看到一批来自完全不同生活经验的人，去解决传统科技创业管道从未优先考虑、甚至从未注意过的真实问题。

AI 工具在精益创业里的能力

旧创业模型假定：你需要雇工程师 build、雇销售去卖、雇运营把公司跑起来。人头数被默认当作组织势能和产品成熟度的指标。

2026 年的早期创业公司则截然不同。它们生来精简，常常只有一个创始人，或者两三个人的小团队。当 AI 成为技术和组织的基础设施，他们就能在团队扩张之前完成产品验证、跑出早期收入、甚至盈利。

AI 让一个精益团队像一个大公司一样运作，主要体现在三个方面：研究（research）、agentic coding、关键业务流程的自动化。

会话式智能与研究

思路： 一位随叫随到的全领域专家。

每个创始人在创业第一年都要回答一堆几乎不可能事先全知道的问题：怎么搭工资系统？产品 sprint 怎么排？投资人 memo 怎么写得紧凑？过去这些问题只有一个答案：「找认识的人问」。对 bootstrap 或 pre-seed 创始人来说，这要么消耗大量本该用来 build 的时间，要么烧掉本就不多的现金请顾问。现在，AI 就是这个全域随叫随到的专家。

Deep research： 竞品分析、市场容量测算、财务建模
文档起草： Pitch deck、案例研究、投资人 memo、PRD
战略思考伙伴： Devil's advocate 分析、pre-mortem、场景规划、roadmap 优化

Agentic coding

思路： 永远在线、永不堵塞的工程师。

过去做软件要么找技术联合创始人，要么找外包开发，要么积攒足够久的现金流再雇工程团队，然后才能写出第一行生产代码。Agentic coding 工具让每一个有志创业的人都能用自然语言描述自己想做什么，再由 AI 在「全工程团队的速度和规模」下生成、测试、调试、重构生产级代码库。

从「我有一个想法」到「我有一个产品」之间的时间，被压缩了。创始人的角色重新回到 build what / build why，而 AI 接手为真实用户准备就绪的真实基础设施的建造工作。

工作流自动化

思路： 按需的、自动化的运营团队。

即使一个创始人能像顾问一样做研究、像工程团队一样写代码，仍然有一大类工作要做——战略规划和产品开发之外的全部杂事：排日程、更新 CRM、出周报、维护文档、发布内容、跟踪合规要求，以及管理工具与系统之间的连接组织。在精益创业里，这些活儿主要落到创始人头上，是一笔可观的注意力税。

工作流自动化把这笔税卸掉。日常运营任务可以被配置成自动发生：deal 推进时 CRM 自动更新，周报自动汇编，产品文档自动跟随代码变化保持同步。关键的是，Claude Cowork 可以打通公司在用的项目管理、通信、数据源等系统——而无需有人专门去维护这些集成。在 Day Zero 创业公司里，那个人几乎永远是创始人。

时机与编排就是一切

能够有效利用 AI 的研究、自动化、agentic coding 能力的创始人，可以把杠杆撬得比团队人头远远更高，把绝大多数时间留给真正重要的工作。

但这不会自动发生。负责编排这些 AI 工具的创始人，必须知道在什么阶段、以什么方式调用它们。本手册剩下的部分会按 AI 原生创业的路径，逐阶段拆解目标、挑战，以及如何在每个阶段有效使用 AI 工具。

第 3 章 Idea 阶段

每个创业者都从同一个地方出发：一个挥之不去的问题。Idea 阶段是想法与现实正面相撞的阶段——2026 年的创业要想成功，必须有一条纪律：在证据足够之前，不要开始 build。

这个阶段的工作是研究、用户发现（customer discovery）、竞争分析，以及对反证（disconfirming evidence）的诚实评估——所有这些都要在你让 Claude Code 生成第一行生产代码之前完成。

Idea 阶段目标

主要目标是 research-oriented validation：在投入资源 build 之前，扎实地证明真问题存在，并且你的解决方案确实能解决它。

依次回答这些问题：

这个问题是真实的、具体的、出现得足够频繁，值得围绕它创业吗？
谁有这个问题？这群人构成一个市场吗？
是否已有别人在解决？怎么解决？解决得多好？
一个解决方案要做到什么，才能真正解决这个问题？我的想法能做到吗？

这些问题加起来，最终回答一个问题：这值得 build 吗？

这意味着在动手前要足够具体。「人们在报销时很挣扎」是一个观察，不是假设。「中端市场的财务经理每周要花四小时以上对账，因为现有工具不能和会计软件打通」才是一个可被验证的假设。

Idea 阶段退出准则

Idea 阶段的退出条件是找到 problem-solution fit：你已经基于真实人类对话拿到了定性证据，证明你在为真实的人解决真实的问题，然后才能开始 build 那个解决问题的东西。

当你能对以下三个问题都答「是」，就可以离开 Idea 阶段：

问题是真实且具体的吗？ 你能说清谁经历这个问题、出现得多频繁、严重程度如何、他们目前如何应对。
你的方案解决的是真正的问题吗？ 不是你一开始设想的那个，而是验证过程揭示出的那个。有时候两者一样，有时候不一样。
是否有足够信号支撑 build？ 你永远不会有百分百的确定，等到确定就是失败模式本身。但你需要足够多的定性证据，使得「投入 MVP」是一个有理由的判断，而不是信念跳跃。

Idea 阶段的挑战

Idea 阶段是最重要工作发生的地方，因为这里犯的错代价最大——一开始就走偏，会立刻让一段创业旅程脱轨。

把 build 当成 validate

挑战： 当技术门槛被移除，热情高涨的创始人很容易跳过「验证想法是不是真的有人需要、有人用」这一步。

即使在 agentic coding 之前，42% 的创业失败是因为 build 了没人想要的东西。现在 Claude Code 这类 agentic coding 方案已经大幅压缩了「我有想法」与「我有产品」之间的距离，这个失败率只会更高。

从未有过更好的时机做创始人；但同时，一个看起来像产品的原型，也以前所未有的速度变成 AI 原生创业的生存性风险。

直到不久之前，把哪怕一个最基础的原型搭起来都要花掉真金白银的开发时间和预算。如今技术开发的门槛已经基本消失，反而让创始人更容易跳过验证，直接钻进 build。

到达 problem-solution fit 的正确路径是：先验证假设，再 build。很多创始人却把它扭曲成：有想法 → 立刻 build 一个原型 → 把原型的存在当成验证。原型变成了「假设一直是对的」的证据，从未真正被检验。

一个能运转的原型，很容易被误认成「我在解决真问题」的硬证据——但它不是。它真正的作用是：成为与潜在用户对话的压力测试道具。那些对话才是真正的证据。

过早 Scaling

挑战： 当 build 几乎零阻力、几乎免费，你很容易把执行 scale 到业务实际还不需要的程度。

过早 scaling 意味着你在还没真正验证一条产品路径值得走之前，就承诺走它。这一直是创业的杀手，但 AI 让创始人滑进去时几乎察觉不到。Agentic coding 太强，让你能在还没意识到偏题的情况下，把执行 scale 到远远超过 problem-solution validation 的范围。

它会带着同样的热情，围绕一个根本错误的前提去生成、测试、调试、重构整个代码库。系统里的智能是你给的。在这一阶段的根本指令是：让你的判断力始终跑在你 build 的速度前面，尤其当 build 又快又毫不费力的时候。

失去客观性

挑战： 让 AI 工具去支持你已经相信的东西，它一定能找到证据。Confirmation bias 现在配了一台研究引擎。

创始人天生对自己的想法有热情。AI 给了 confirmation bias 一个显著的增益：让 AI 验证你的创业想法，它会找到支持证据；让它估算潜在市场，它会算出一个让 TAM 看起来很 fundable 的数字。

AI 顺着你的方向走，意味着不去问难题的创始人，可以以比以往更快的速度，构造一份精心研究、看上去严谨的「为坏想法辩护」的材料，自己却觉得正在做尽调。解药就是同一个工具，只是反向指向：AI 能像支持一个想法那样彻底地压力测试它。

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

Claude 如何帮助 Idea 阶段的创始人

把 AI 原生创业想法推进到 Idea 阶段的尽头会让人觉得漫长。但这个起跑阶段本质是研究和验证练习，意味着大部分时间在 write code 之前。下面是如何在 Claude 三个产品面（Chat、Claude Cowork、Claude Code）之间分工，尽快、又有纪律地走完这段路。

Chat / Claude Cowork / Claude Code，怎么选？

Chat： 不离开你正在使用的 app 的快速对话。用于经营公司过程中的小任务：从一份密集投资人 memo 里抽出一句话要点、在董事会前 sanity-check 一个说法、读懂一个长 Slack thread。

Claude Cowork： 真正花时间的知识工作。从多个来源拉数据、做综合，产出一份完成品（文档、deck、电子表格）。比如把一堆客户访谈转写整理成主题发现报告、为下次融资做竞争格局图、每周一早上把 KPI 摘要丢进共享文件夹。

Claude Code： 团队里 agentic coding 的环境：直接访问代码库、Plan Mode、git 集成、本地或沙箱化云环境。这是精益团队跨日益增长的代码库交付特性、迁移遗留代码、从原型走向生产的地方。

三者底下都是同一个 Claude，差别在于工作区。

任务	选哪个	原因
提问、改写、快速 brainstorm	Chat	快速对话，无需配置
研究、分析、基于文件与系统产出完成品	Claude Cowork	文件夹访问、connectors、skills、scheduled runs
写、测试、发布软件	Claude Code	代码库访问、diff、git、开发环境

定义并压力测试问题假设

你已有的领域经验和前期研究已经生成了一个假设。第一件事是把它磨到可被验证。Claude 在「逼你具体化」这件事上特别有用：谁真的有这个问题？多久遇到一次？严重到什么程度？现在是怎么应对的？无法精确回答这些问题的「问题陈述」就还没准备好被验证。

练习： 与 Claude 一起把问题陈述打磨到可验证。比如，「合同审阅太慢」没什么意义；但「中端市场公司的 in-house 法务团队，每个合同审阅周期要花 3 天以上，因为修订是跨邮件 thread 而不是单一受控文档管理的」就非常可验证。

然后让 Claude 反驳你的想法，找出与之相悖的证据。这能浮出负面市场信号、失败竞品、行为模式、结构性障碍——这些信息通常会被一份「支持性综述」悄悄降权。

Note： 把 Claude 当作结构化的 devil's advocate，是 AI 原生创业全周期都适用的核心用法。

市场调研与绘制竞争格局

审视你的竞争对手。 创业里有种现象叫 competitor neglect：你过于专注自己的愿景，结果系统性低估了别人在同一空间做了什么。AI 是解药：让 Claude 给出最有说服力的论证——为什么这条赛道里的某个竞品会成功而你不会。

Claude 能分析他们的方法为什么实际上更好、客户为什么会选他们、你的潜在差异化为什么没你想得那么牢。

练习： 让 Claude 按 tier 绘制竞争格局：直接竞品、间接竞品、潜在收购方、邻近玩家（可能 move into 这片市场）。然后让它论证每一 tier 为什么是真威胁，而不是你最容易反驳的那个版本。

市场调研。 Claude Code 可以综合公开的客户反馈，把反复出现的抱怨和未满足需求浮上来。顺便：这本质上是免费的、对竞品客户的定性研究。

练习： 让 Claude Cowork 综合关键来源里的竞品评价，识别 top complaints——现有方案没能解决的。如果你的假设打中了其中一两个，那是 problem-solution fit 的强证据；如果一个都没打中，这也值得知道。

Claude Cowork 还能从厚重的行业报告、分析师报告、市场研究文档里抽出相关信息与数据；这些合成过的输入会变成 Claude 后续分析的干净上下文。

练习： 建 TAM/SAM/SOM 模型，并压力测试背后的假设。市场是在扩张、整合还是成熟？这影响你怎么看时机和差异化。绘制买方格局：谁掌握预算、谁影响决策、是不是同一个人。

趋势分析。 用 Claude 监听早期信号，判断你是否在正确的时间进入。追踪用户问题已经在被讨论的 Subreddit 和 LinkedIn 群组，看用户究竟用什么语言描述问题。让 Claude 找到类似问题已被解决的「类似市场」，提炼什么管用、什么没管用。浮出可能加速或威胁机会的监管、技术或人口趋势。

练习： 让 Claude 识别三个外部趋势（监管、技术或人口），评估它们是顺风还是逆风。

Note： 市场调研和竞争图绘制不是一次性练习。MVP 和 Launch 阶段都需要继续推演，所以当你的假设演化时，要重复这些练习。

设计客户发现

潜在用户访谈学到什么，由两件事决定：(1) 你问的问题质量，(2) 你是不是在问对的人。Claude 在客户发现上特别有用：找谁谈、问什么、怎么消化听到的。

找谁谈。 一个精确的目标画像，远比一长串联系人有价值——包括具体岗位、公司类型、团队结构、最可能强烈感受问题的资历层级。然后识别这些人在哪些社群、活动、LinkedIn 群、Slack workspace 里聚集，并基于「离问题多近」搭一个优先级框架。

问什么。 用 Claude 来构建访谈框架本身：在正确顺序里问正确的问题，结构化地引出「人们实际怎么做」而不是「他们觉得自己会怎么做」。新手最常见的错误是问宽泛、面向未来的问题（「你会用这样的东西吗？」），而不是查询具体过去（「告诉我上次你处理这个问题的情况」）。

Claude 能标出哪些问题在诱导回答、哪些过于宽泛、哪些会产生噪音而不是信号。如果你的假设涉及多个角色（例如财务经理和 CFO），Claude 能为各自设计不同问题集——一个统一框架会抹平这种差别。

练习： 自己先手写访谈问题，让 Claude 审计。专门让它标出诱导性、面向未来、太宽、容易得到社交期望答案的问题。然后让它建议两三个最容易引发回避的关键时刻的 follow-up probe。

访谈后分析。 每次访谈结束后，让 Claude 帮你复盘：扔进去笔记，让它指出什么确认了你的假设、什么挑战了、什么真正出人意料。攒到一批访谈后，让 Claude Cowork 综合所有笔记，浮出反复出现的主题、矛盾点、两个方向上的最强信号。再把这份综合输出反向喂给 Claude，让它指出你的解读可能在 pattern-matching 你想听到的内容，而不是数据真正说的。

练习： 每五次访谈后，让 Claude Cowork 产出两份清单：支持你假设的证据，挑战它的证据。如果前者明显长于后者，问 Claude 这种不对称是来自数据还是你的期望。

客户触达与排期

让 Claude Cowork 把建联系人列表、跑触达、约访谈这些运营操作扛起来。

它可以用你和 Claude 一起定义好的目标画像（岗位、公司类型、资历），调研并编出一份结构化的潜在客户清单与已验证联系方式。然后大规模起草个性化触达邮件，针对每个人的角色和上下文裁剪。

随着回复进来，它通过 MCP 接上 Gmail 和 Google Calendar，处理 thread、处理排期请求、把访谈落到日历上。同时 Claude Cowork 按设定节奏发后续邮件（比如第七天 follow-up），并在每一步更新跟踪表。

练习： 把你的目标画像交给 Claude Cowork，让它建潜客列表、起草个性化触达序列、搭一份跟踪表（含触达状态、follow-up 节奏、访谈完成情况）。然后让它跑协调流程，你只管准备对话本身。

设计最终方案概念

验证工作做完了：问题是真的、你知道谁有这个问题，你有一个被证据支持的方案概念。用 Claude 从各种角度发展并挑战这个方案：缺口是什么？有什么替代方案？要让这个方案在 scale 下工作，什么必须为真？这是个重要的现实检查点：这个设计真的能解决「验证过程揭示出的问题」吗？还是只解决你最初设想的问题？

练习： 把你的方案概念呈给 Claude，让它指出你设计最依赖的三个假设。然后问每个假设要为真需要什么、如果有一个不成立后果是什么。

用 Claude Code 建一个轻量原型

现在可以动手了：有了被验证的假设、被压力测试过的方案，你终于可以 build something。

这是 Claude Code 在 Idea 阶段登场的时刻。即使你之前一直在小打小闹地拼东西，到这一步才是正式产出 lightweight prototype 的时候：把你的想法呈到一个真实的人面前并获得真实反应所需的最小面积。

你现在不是在 build 一个真实世界产品（暂时还不是）；你是在构造一个可在用户对话和投资人对话中使用的样本。真实用户对他们能真实触摸的东西的反应，会告诉你十二个 problem-solution 访谈也得不到的信息。之前你在确认「要解决的问题是真的」；现在你在请潜在用户去触碰「被提出的解决方案」。

练习： 定义你方案依赖的那个核心交互。让 Claude Code 只 build 这一个。把它放到五个来自被验证目标画像的人面前。从这五次对话里学到的，决定你是继续 build 还是回到画板。

走完 Idea 阶段，是 AI 创业赛道上的一次飞跃，因为你不再押在直觉上，而是依据证据执行。现在进入 MVP 阶段，创始人的指导问题从「这值得 build 吗？」变成「我们到底应该先 build 什么？」，AI 的主要角色也从研究伙伴换成施工队。

第 4 章 MVP 阶段

很多创始人把 MVP 阶段当成施工阶段，但 MVP 仍然本质上是一项证据收集练习。不同的是，你现在收集的是关于「方案空间」的证据，而不是「问题空间」——具体来说：一群真实、可识别的人是否觉得它有用到愿意继续用、愿意付费、愿意告诉别人。

MVP 阶段目标

作为 AI 原生创业的创始人，你的目标是把一个被验证的问题翻译成一个可工作的产品，让真实用户去用。这不是完整的 roadmap，而是把你的想法变成解决方案的最聚焦、最小的那一版迭代，目的是收集 product-market fit 的真实证据。

同时，你今天 build 的方式决定了你未来能做什么。这意味着 MVP 阶段还有一个同样重要的目标：在不积累让你日后还债的技术债的前提下快速行动。

最后，从第一天就投资 persistent context，能让 AI 持续成为乘数，而不是熵的来源。在 AI 原生创业里，你的代码库是与 AI 一节又一节 session 协作的产物，所以「可读性」是基础。跳过 specs、架构决策、上下文文件（如 CLAUDE.md）的创始人会撞墙：每次新 session 都要重新解释代码库；AI 生成的修改也会偏离原意。

MVP 阶段退出准则

MVP 阶段的退出条件是 product-market fit 的真实证据：一群具体的、可识别的用户认为产品有价值到愿意回来用（retention）、付费（revenue）、或者告诉别人（referral）。

MVP 阶段的挑战

在 MVP 阶段，创始人的最高指令是速度和判断力。挑战集中在：你能否在恰当的速度上 build 正确的东西、用正确的方式 build，而不在以后付出代价。

Agentic 技术债

挑战： 因为 AI 本质上去掉了过去控制「什么能进生产」的每一道天然瓶颈，速度被默认保证。但如果速度是你 MVP 阶段唯一关心的变量，你很可能在积累事后赔不起的技术债。

一些技术债在 MVP 阶段是合理的，但前提是必须在 scale 之前管理好。它是渐进积累的，可以随时间或专门 sprint 清掉。AI 技术债却是复利的。

如果 specs 和架构约束没有被写在 AI 能读到的地方，每次 session 都从零重新推导基础决策，决策会漂移。最终你拿到一个没有连贯心智模型的代码库——不是因为任何一块单独是坏的，而是这些块从未被设计为彼此适配。这是真正的问题，并且通常出现得很晚。

错把早期热度当成 PMF

挑战： AI 工具能让早期数字看起来漂亮，但这并不保证市场需要你的产品。

Early momentum 是创始人能拥有的最有心理冲击力的体验之一。在数周或数月的验证和小心 build 之后，发布一个产品像是「你一直是对的」的确认。Agentic coding 工具让你比以往更快到这一刻，但早期 traction 不等于 product-market fit。Launch 阶段的能量来自一些短暂力量：你创始人朋友、投资人 portfolio 里其他公司的潜在买家、或者一条 Hacker News 头条带来的 spike——这些都不可靠地预测第六周或第十二周的情况。

零摩擦 scope 蔓延

挑战： 当 build 既毫不费力又几乎免费，永远会有「再来一个酷功能、再来一个边角 case」。这种 scope creep 弊大于利。

scope creep 一直是创业风险，但传统的对抗力——真实工程时间成本——在加一个功能只用一个下午、不需要整整一个 sprint 的情况下，不再以同样方式存在。

挑战是：每一次单独添加都看似有道理。当然产品应该处理那个边角；当然用户会想要那个工作流。它们在当下不像 scope creep，因为每一个用 agentic coding 都只费一点点力气；但你的产品会 sprawling 出原本的边界，失去方向和动能。

解药是动手前写下 scope 定义：产品做什么、刻意不做什么、来自真实用户的什么具体证据才足以加新东西。决策点从「我们要不要 build 这个？」变成「有没有足够多用户告诉我们『没有这个就拿不到价值』？」

经验不足导致的不安全

挑战： 创始人用 AI 工具加速上线，却没有先理解基础安全原则，结果把用户暴露在本可预防的风险下。

硬道理是：agentic coding 工具生成的是「能跑」的代码，不是「天然安全」的代码。功能性代码很容易——要么有效要么没用。安全漏洞是不可见的，直到它被利用。 这意味着没有自然的反馈回路来告知一个新手出了问题。把一个 live MVP 发给真实用户，意味着真实数据、真实暴露、真实后果。

把安全往后推不是新事——多年来 bootstrapped 创业经常把安全考量拖到接近上线。在任何用户碰到你的应用之前，做一次 security review，是 MVP 的最低负责门槛。

Claude 如何帮助 MVP 阶段的创始人

Build 之前定义架构

在 Claude Code 写下第一行生产代码之前，用 Claude 定义并文档化将统治这一阶段全部 build 的架构决策：要遵循哪些 pattern、要避开哪些依赖、有意做了哪些 tradeoff、为什么。这份输出会成为你聚焦的架构上下文文档，并为 Claude Code 设定护栏。

没有这份上下文，每次 session 都从零开始，Claude Code 被迫推断结构性假设。让 Claude Code 在没有护栏的情况下 build，会产生一份「能跑、但结构不连贯」的代码库；继续在不连贯的代码库上迭代和 scale，最终是浪费时间和 token。代码迟早会塌，逼你重 build。

练习： 打开 Claude Code 之前，先打开 Claude，描述你在 build 什么：核心问题、目标用户、未来六个月你现实期望的规模。让它帮你定义 MVP build 应该遵循的架构原则、要避开的依赖、当前阶段你愿意主动接受的 tradeoff。

然后把这份输出保存为 CLAUDE.md。这是你 build 的第一份产物——后续每一次 session 都会基于它继续。CLAUDE.md 作为项目级指令，提供项目特定上下文，会被 Agent SDK 在该目录跑动时自动读取。它们在功能上就是你项目的「持久记忆」。

定义并执行 MVP scope

scope creep 无摩擦是 AI 时代 MVP 最典型的失败模式。就像你定义并文档化产品架构一样，你也需要在第一个特性 build 之前定义 MVP scope。

让 Claude 帮你建一份 scope 文档：MVP 产品做什么、有意不做什么、添加特性的修订标准是什么（即「来自真实用户的什么证据」才能让某项内容此时被加进来）。

新特性想法浮出时——它们一定会浮出——用 Claude 压力测试这究竟是用户的真实信号，还是被包装成「产品思考」的创始人热情。

用 Claude Code build 你的 MVP

架构和 scope 定义好后，Claude Code 成为主要 build 工具。用它生成、测试、调试、迭代你的代码库，但每一次 session 都视为「已做决策的执行」，而不是「再丢几个新想法进来」的机会。

每次 Claude Code session 开始前：(1) 重读 scope 文档，(2) 提供 CLAUDE.md 架构上下文。结束时：把这次 session 浮出的新决策回填进上下文文档。目标是你能口头解释结构的代码库，而不是只能跑的代码库。

练习： 给 Claude Code 的工作建一份简单的 session 模板：包含架构上下文文档、本次 session 的具体任务、要遵守的约束或要观察的 pattern。每次 session 末，把发生了什么、做了什么决策、引入了哪些假设，简短记录到上下文文档里。每次 session 五分钟的文档，是对抗复利化架构漂移的便宜保险。

任何用户接触前的安全审查

作为 AI 原生创业的创始人，你的责任是知道代码里有什么、理解任何潜在暴露向量、不向真实用户发明显漏洞。

Claude 可以对 AI 生成代码做一遍有用的 first-pass security review，帮你识别常见漏洞。这是上线前应养成的习惯。它不是替代专业安全工具，更高 stake 时也不是替代人工审查——把它当作其中一项的创始人，最后会成为「事故故事」的主角。

Claude Code Security 更进一步：扫描代码库找安全漏洞，并对人审产出靶向补丁，浮出传统方法可能漏掉的问题。

Note： 本电子书发布时，Claude Code Security 仍在 limited beta，使用前请确认可用性。

练习： 部署给任何真实用户之前，让 Claude 用一份明确简报审你的核心应用代码：认证与 session 处理、API 响应中的数据暴露、输入校验与注入风险、有已知漏洞的依赖。把每个发现当回事，认真评估是否需要修复；任何触及认证、密钥、数据处理的地方，必须人审。

Build 你的测量框架——在 launch 之前

把早期热度误认为 PMF 的创始人，通常也是那些发布之后才开始追踪数据的人——挑选的指标是「证明什么 work」的，而不是「浮出什么不 work」的。解药是在第一个用户出现前，把测量框架先立起来。

用 Claude 定义对你这个具体产品哪些指标重要、benchmark 是什么、数据里哪些 pattern 构成「真 PMF」而非奉承性噪声。具体设定：留存 benchmark、激活标准、Day 7 与 Day 30 的目标——都在你 release MVP 之前。

接下来，定义对你这个具体产品什么是 false positive：注册但不激活、收入但无留存、初始热情但无重复使用。数据来了，让 Claude 做对抗性 case：怀疑论者会怎么 challenge 这些数字？

管理用户发现与反馈物流

一旦真实用户进入产品，运营层会快速扩张。Claude Cowork 处理 build 用户联系人清单、跑外联序列、约反馈 session、分流 bug 报告、追踪迭代周期等重要但繁琐的工作。Idea 阶段那些托管型 MCP 集成在这里继续适用。

人要留在收集回路里以做细微解读。一句「这很好，但我希望它还能……」需要解读：是核心需要还是 nice-to-have？是单个客户特有还是某段细分的代表？是缺失的功能还是 onboarding 上游的问题？没有工具能回答这些。

练习： 配置 Claude Cowork 跑 MVP 阶段的反馈循环：给早期用户起草外联、约反馈 session、为 bug 报告和功能请求设计结构化收件流程、写每周综合。综合先你自己看；然后让 Claude 分析这些信息，捕捉你可能忽略的点。

朝证据迭代，而不是朝完成度

MVP 阶段在你拿到 PMF 真实证据时结束，不管产品看起来多「成品」。宣布 PMF、进入 Launch 是一次结合创始人直觉与已收集证据的判断练习。几条有用的 litmus tests：

Sean Ellis 测试： 问活跃用户：「如果不能再用这个产品你会怎么想？」如果超过 40% 答「非常失望」，是有意义的 PMF 指标。
努力测试： 在 PMF 之前，留存需要持续干预——频繁外联、激励、个人 follow-up、创始人英雄式投入。PMF 之后，产品开始自己跑。当事情开始变成「拉」而不是「推」，是最清晰的信号之一。

最终没有任何单一数据点能确认 PMF，因为它是一种必须在多个迭代周期里成立的 pattern。

证据指向时就要 pivot

如果做完所有这些工作仍然到不了 PMF：结果不证实你出发的方向，不是失败，而是系统在 work——MVP 阶段就是设计来在你过度投资错误答案之前浮出这件事的。

用 Claude 把数据告诉你的东西推一遍：

探索替代客户细分。 也许那些没转化的用户从一开始就不是对的目标。对的受众常常已经在你的数据里，只是被低估了。
调整你的价值主张。 也许受众是对的，但 MVP 的 framing 没让用户共鸣。在不改变产品的前提下，调 onboarding、messaging、核心特性的强调点，或许就能修好。
对不一致可能更深的可能性保持开放——它也许需要更根本的改变。
练习： 如果你完成了三个或更多迭代周期、仍没有 meaningful 朝 PMF 的进展，让 Claude 跑一次诊断再决定下一步。喂入留存数据、用户反馈、原始问题假设，问它三个问题：
- 数据里有没有一段细分的反应明显不同于其它人？
- 「设计价值」与「体验价值」之间的差距，是定位问题还是产品问题？
- 要让当前产品找到真 PMF 需要什么为真？该情景在你看到的数据里现实吗？

让答案决定你 adjust、pivot 或回到 Idea 阶段。

第 5 章 Launch 阶段

如果 MVP 阶段是证明你的产品配得上存在，Launch 阶段就是证明你的业务配得上增长。

Launch 阶段目标

Launch 阶段，创始人必须 把早期 traction 转化为可重复的、可持续的增长引擎。除了让产品达到生产就绪，你还必须硬化产品下面的基础设施，同时围绕产品建立一家真实的公司。

Idea 和 MVP 阶段公司自然是「创始人中心」的，因为你需要完整的情境感知和紧密反馈回路。但现在，仍然亲手抓每一根线的创始人，会变成 Launch 阶段瓶颈。目标不是把自己从公司里抽走，而是搭建运营系统，让你的注意力释放出来，去做只有创始人能做的决策。

Launch 阶段退出准则

Launch 阶段退出条件有三：

增长是可重复且 channel-driven 的。 不只是留住用户，而是通过特定渠道可预测地获取他们；你能算清并辩护 CAC、LTV、payback period。
产品能扛生产负载。 基础设施硬化、安全合规到位、可靠性在真实生产条件下站得住（不是只在你测试过的条件下）。
运营在没有创始人瓶颈下也能跑。 流程存在、自动化到位，你不再亲自处理支持、分流、sprint 规划或汇报。

Launch 阶段的挑战

PMF 是早期生命周期里最难的问题；现在，创始人的挑战变成保住它。Launch 阶段，已找到真实 traction 的公司，仍可能因为围绕产品的组织跟不上而散掉。

技术债到期

挑战： 为速度和验证 build 的 MVP 代码库，工作得「刚好够证明产品有效」；但生产流量、新特性、增长的复杂性，正在把那些 shortcut 暴露。

MVP 阶段为了速度，积累一些技术债是合理 tradeoff。Launch 阶段，这笔债开始计息，越拖越贵。

方案是系统性的架构审计：识别结构性弱点、靶向重构最差部分、有意义地扩大测试覆盖，让下一轮特性工作不再重新引入相同问题。

创始人成为瓶颈

挑战： 在 MVP，创始人在每个回路里是资产；在 Launch，支持量上来、产品决策堆积、运营复杂度倍增，同一种本能变成约束。

从「亲自做」到「设计做事的系统」是创业生命周期里最难的转换之一。很少有清晰的「就是这个时刻」——风险是错过它，整组织停滞而创始人停留在 builder 模式。Telltale 信号：从前一小时能搞定的决策现在要一周；support 请求堆积，因为只有你知道答案；只有你记得去做的运营任务。

补救是对你亲手做的每件事做一次彻底审计：从最小到最高 stake，识别哪些能被系统化、哪些能被委派、哪些真的需要创始人的时间和注意力。

安全与合规不再可推迟

挑战： 保持「安全合规简单」在 MVP 还好；但在 Launch，有真实用户、真实数据、潜在企业合同时，它变成 liability。

MVP 阶段一小撮 beta 用户、无敏感数据时，安全漏洞还是理论风险；产品一进入生产、用户依赖它，假设变成真实暴露。原型阶段不适用的合规要求，一旦你处理客户数据、payment、规管行业，立刻适用。

补救：在生产规模到达之前做系统性安全合规审查，把任何浮出的问题当成必须修——而不是建议——的整改，下一波用户来之前完成。

还没准备好就扩张

挑战： 新市场、新融资机会看起来像增长机会；它们也可能是 PMF 死亡之地。

你 build 的初始 traction 是真的，但它特定于你的早期受众。过早扩到一个跟原本市场显著不同的新市场，会带来新用户行为、合规要求、付款基础设施、基线期望——这些你的产品并未设计去承担。一下子变量太多，你失去清晰解读自己数据的能力；还可能在追逐新的、未经验证的受众时忽略原本的用户基础。

Claude 如何帮助 Launch 阶段的创始人

Claude 三种形态都在 Launch 阶段满负荷使用，并互相支援：每个工具的输出会成为另两个的输入；结果有机叠加，三件一起用比加和更多。

这正是让超精益创业模型在结构上可能的原因：Claude Code build 产品、Claude Cowork build 围绕产品的公司、Claude 帮把产品和组织知识运营化。一个小团队能像规模 N 倍的公司一样运转。

在技术债复利前修整

你的 MVP 代码库工作，但需要一轮系统性整改——找出可能成为结构性 liability 的技术债。

首先用 Claude Code 跑一次全面架构审计：哪里脆弱、哪些 shortcut 维护成本会变贵、哪里测试覆盖薄到下一轮特性工作会重新引入同样问题。

把审计结果反喂给 Claude，分流并排序整改工作：下次发布前必须修什么、什么能等一个 sprint、什么是当前阶段可接受的持续负担。这也是文档化 MVP 阶段架构决策（那些只在你脑子里的）的时机。把它们写进 CLAUDE.md，今后每次 Claude Code session 都从「共享的系统设计理解」开始。

练习： 让 Claude Code 审你的 MVP 代码库，产出一份结构性弱点、测试覆盖缺口、重构候选的优先级列表。把列表喂给 Claude，让它按你接下来几个 sprint 排序：必须先处理的重大问题、能与特性开发并行的、能等的。

搭建替代创始人注意力的系统

Build 让你注意力解放的运营系统，需要清楚知道你的注意力都花到哪去了。让 Claude Cowork 对当前运营负载做结构化审计：每个 recurring task、每个落到你桌上的决策、每个只因你记得而发生的 workflow。然后让 Claude Cowork 把这些清单分类成：能完全自动化的、需要人但不一定是你、真的需要创始人判断的。

审计完成后，用 Claude Cowork 设计自动化候选的 workflow 逻辑：每个 workflow 的触发条件、决策规则、输出长什么样、完成后去哪。

把安全与合规做成产品工作流

让 Claude Code 浮出 SOC 2、GDPR、HIPAA 等审计里常见的代码级问题，以及你的目标市场所要求的标准。这会同时浮出漏洞和合规缺口。把发现喂给 Claude，帮你优先化整改、设计企业买家在签约前会要的控制、审计 logging、访问管理。Note： AI 扫描是辅助，不是合规审查的替代品。

接下来，把合规工作流并入开发周期，而不是当一次性项目跑。合规文档需要持续维护更新。对接近企业合同或国际市场的创始人，也是用 Claude Code 安全扫描为独立安全评估做准备的时机。

练习： 用 Claude Code 跑一次面向目标市场所要框架的代码级安全 review。把输出给 Claude，产出两样东西：优先化的安全整改序列；准备好满足潜在企业买家合规 review 所需的文档与控制清单。

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

Launch 阶段需要一套可重复、轻量的流程，不需要创始人触发或运转。用 Claude 设计：你的产品时间线和工作周期的结构、Claude Code 碰一个特性前需要什么样的 spec、bug 报告怎么被分流路由、每周指标 brief 报告什么以及如何分发。

流程设计完成后，用 Claude Cowork 跑运营层：排 sprint 仪式、把进来的 bug 报告路由到正确位置、从你连接的数据源汇编每周指标，并维护把用户信号引入产品决策的反馈回路。

练习： 让 Claude 设计一套轻量的产品管理操作系统：明确的 sprint 节奏、最低 spec 模板、bug 分流决策树、从真实数据源拉数的每周指标 brief。然后让 Claude Cowork 跑系统的循环运营元素（排期、路由、报告汇编）按表执行而无需你介入。

第 6 章 Scale 阶段

Scale 阶段，创始人角色重新对齐：从 builder 变成对外的 executive。产品仍然是中心，但你日常工作越来越围绕「公司本身」。分析师 briefing、IPO 路演这类 Scale 阶段活动开始挤进日程，同时你仍要保持精益、AI 中心的结构优势。

Scale 阶段目标

scale 技术基础设施的工作仍在继续；现在与之并行的是 scale 组织本身、把它成熟成一家「business」的工作。

在这一阶段，你在从几千用户走向几百万、从一个市场走到多个市场。在更早的每一阶段，增长是你靠贴近用户、紧密反馈回路、加上一剂创始人直觉慢慢摸出来的。现在目标是 build systematic growth——由成熟的组织运营支撑的系统性增长。

对 AI 原生创业，你的目标应是通过积累深度建立可防御的护城河：源于你 build 进产品的专业知识、产品与用户依赖的其他工具与平台的深度集成、产品长期沉淀的专有系统数据与工作流。一直沿一致方向、一致基础设施 build 的创始人，此时手里有真正难以复制的东西。

在这个阶段，公开市场投资人、分析师、监管者、企业采购、并购方施加更大压力，期望也更高，因为 stakes 更高了。你的产品和组织都要经得起外部审视：不仅是你 build 的能力，还包括围绕它的治理、合规姿态、财务控制、战略叙事。

Scale 阶段退出准则

Scale 阶段退出条件不再是单一里程碑，而是「门槛事件」：公司在创始人越来越不直接运营日常的情况下，仍然可持续。你已经展示出系统性增长；建立了能满足最严格外部 reviewer 的治理与合规基础设施；并对「如果一个资金充足的在位者今天复制你的产品，你的用户会留下吗？」有可靠答案。

实践中这一门槛通常体现为三种形式之一：在不再依赖外部资本的规模上可持续盈利、IPO-ready、或被收购。三种都要求增长是系统的、可审计的；你的产品护城河经得起审视；你的组织运营成熟可持续。

当这一切为真，恭喜：你的创业已经从「一个 bet」变成「一家 business」。

Scale 阶段的挑战

委派运营层

挑战： Scale 阶段的运营系统必须可靠、可持续运转，不需要保姆式照看。对从 day one 就 hands-on 的创始人，这种过渡既是结构挑战，也是心理挑战。

Launch 阶段你的工作是搭这些系统；Scale 阶段是 (1) 让这些系统成熟到完全可信，然后 (2) 真正地信任它们。

听起来比做起来难。即便你委派得好，把什么放手、把什么留在自己盘里也不总是明显。放手过早、过多——尤其是放给 AI 自动化系统——关键决策可能在缺乏只有创始人能提供的关键上下文下被做出；抓得太久则成瓶颈。

根本挑战是：识别仍只活在创始人脑子里或未记录工作流中的「机构知识」，把它编码进可文档化、可审计、可转移的系统。

Scale 技术运营

挑战： 客户不再只评估你的产品，他们要知道你的组织能否成为可信的长期基础设施伙伴。

前几阶段的技术挑战中心在代码库本身——build 正确解决方案、不积技术债、为真实用户硬化安全合规。到 Scale，挑战变成围绕代码库的一切：撑起成熟感的支持基础设施、文档、可靠性保证。

更大的客户和机构买家在签多年合同前都要看这些；他们也会在签后让你对此负责。把你撑到这里的同一套 AI 基础设施，现在帮你 build 有明确响应时间、文档的专门 support 功能——能让新客户的工程团队真正用起来的那种。

Scale 组织功能

挑战： Scale 阶段公司一般都需要组织基础设施：招聘、薪酬、会计、法务运营——无论实际跑这些的有几个人。

Launch 阶段做系统化运营意味着把消耗创始人注意力的 workflow 自动化。Scale 创业现在需要更广的运营功能阵列：财务汇报、合规监控、合同管理、客户支持——这些有些后果还更重。

搭建 GTM 功能

挑战： 有机增长有天花板，大多数 Scale 阶段创始人在这之前都没真正 build 过一个 go-to-market 功能。

Idea/MVP/Launch 阶段的增长常起源于创始人亲自卖货：一条 Product Hunt 帖子的好时机、与早期客户的私人关系。这种有机增长只能到一个点，多数创业撞到这个上限就在 Scale 阶段。信号包括：用户曲线变平、获客成本上升、只有创始人亲自介入时管线才动。

Scale 阶段增长需要 build 一个专门的增长引擎，把产品送到新的、更广的受众。多数创始人之前大概没运营过营销、销售、分析师关系。一个真正 legit 的 GTM 不只是新系统流程，还要 build 品牌声音和故事；并且这一阶段，你要打的不只是个人用户，还有整组目标受众，比如投资人和企业买家。

好消息是：GTM 功能不必很大就能有效，build 产品的同一套 AI 基础设施可以 bootstrap 把它推向市场。

Claude 如何帮助 Scale 阶段的创始人

早期阶段把 Claude 当作产品本身的基础设施：研究伙伴、build 原型的工程团队、让单创始人创业成立的 AI 运营层。能走到 Scale 的 AI 原生创业创始人，可以继续用 Claude、Claude Code、Claude Cowork 沿同样方式 scale。

把日常工作交给 Claude Cowork

Scale 阶段开始时，要清晰知道现在最需要把注意力投在哪儿——这对从没 build 过 business 的首次创始人是个挑战。Claude 能帮你列「这一阶段唯一应该亲做」的清单：产品叙事决策、董事会关系、企业 deal、创始人间对话。任何不在清单上的都是委派或交给 Claude Cowork 自动化的候选。

练习： 用 Claude 给你当前运营层做一张瓶颈地图：每个 workflow、决策、审批都要过你。然后让 Claude 推演当你一周不在时每个会发生什么。那些会卡住的，就是你仍 hands-on 到能拖慢进度的地方。

这与你和 Claude 共同列出的创始人优先级与责任清单怎么 match？

接着，压力测试已 build 的系统是否真的能随业务一起 scale。

练习： 让 Claude 画出你当前 workflow，再问它「你一周不在时每个会怎样」。会停的那些，就是 handoff 标准、升级路径、异常处理还要紧的地方。Claude 能帮分析失败点、推荐合适修复，方便你更新或替换 Claude Cowork 自动化。

把技术运营 scale 成企业级基础设施

随你 scale，买家需要确信你的产品和组织能作为长期基础设施被信任。代码库里活儿仍在做，但代码库周围的技术活也要做。

第一步是把机构知识转成可 scale 的系统。用 Claude 起草并维护企业采购希望看到的书面基础设施：产品文档、support playbook、SLA。

并行让 Claude Code 审计并按企业合同所要求的特定可靠性安全标准硬化代码库；build 出 Discord 社区式支持从未需要提供的技术支持基础设施：logging、监控、事故响应工具、让 SLA 真正可执行的 observability 层。

Claude Cowork 然后跑企业支持本身的运营层：工单路由、升级 workflow、产品变更触发的文档更新、续约跟踪、企业客户成功依赖的汇报节奏。三者共同让一支小团队呈现出一个大得多组织的支持姿态。

练习： 挑出当前三个最有前景的潜在客户，或确认三家你想签的理想客户。让 Claude 做缺口分析：这些账户的企业采购在签多年合同前，期望看到什么文档、SLA、支持基础设施？目前你缺什么？然后把技术与文档工作分配到 Claude Code 和 Claude Cowork。

Build 一个真正的 GTM 功能

创始人 hustle 把你带到这里；但 scale 需要一套真实的 go-to-market 策略。AI 能帮你 build 并跑这个完整 GTM 引擎。

Claude 能帮从零搭基础 GTM 资源：市场细分、信息架构、分析师关系策略、销售 playbook、面向投资人的指标叙事。在这阶段你会跟公开市场投资人、企业买家、华尔街分析师说话；每群受众有自己词汇与评估标准。Claude 的工作是把产品价值主张翻译成对每群受众相关的产品营销。

接下来 Claude Cowork 成为战术执行层：内容管线、外发序列、分析师 briefing 物流、新闻 PR 节奏、CRM 卫生、管线汇报，许多 recurring cycle 把 GTM 战略变成实际商业动作。

GTM 还要产品营销基础设施：交互演示环境、集成文档、沙箱租户、API 参考、技术 one-pager——Claude Code 都能 build。买家在 Scale 阶段期待技术与产品兼评；Loom 视频加销售 deck 不够了。这是让 GTM 异步运转的基础设施：一个 build 得好的演示环境会在你开董事会时帮你 close deal。

把领域专业知识与机构知识转成 AI 上下文

很多超精益创业创始人在 build 高度具体的、面向特定行业问题的 app 或工具。Agentic AI 让从未写过代码、但在某行业一线观察过问题的创始人，去 build 能解决复杂问题的产品。Claude、Claude Code、Claude Cowork 都能在「把创始人知识转成复利的产品具体性」上扮演角色。

用 Claude 捕获、组织、提炼创始人知识，把领域专业知识放到产品能取用的地方。通过长期对话、项目、记忆，创始人能把行业 jargon、监管陷阱、边角 case、对显而易见的答案不成立的原因——所有他们知道的——汇成结构化、可搜索的上下文。Skills 还能把循环工作流（如「我怎么审一份商业租约」「我怎么分诊一份病人 intake 表」）编码成可重用例程，Claude 每次都同样跑。几个月下来，这成为通用 AI 无法 match 的专有知识基底。

把领域知识外部化给 Claude，对把行业特定边角 case 编入产品很有价值：通用 AI 医疗计费工具会在 340B 药品项目 claim 上出错；你的工具有专门逻辑处理它。Claude Code 帮你把同行业专业人士的常见 frustration 翻译成 field-level 校验逻辑、prompt 微调、与竞争者没听过的小众行业系统的 MCP 集成。结果是你 app 的深度与广度持续复利，使得竞争者无法复制。

练习： 挑一个通用竞争者一定会在你垂直里搞错的边角 case。与 Claude Code 一起，基于你实际见到的场景 build 一份专门的测试用例（不是单测）。每次类似边角浮出，加进来。你的测试套件变成护城河地图。

把用户数据复利成可防御优势

用户与你产品交互时生成行为信号（哪些输出他们接受、哪些拒绝），这些反过来塑造 roadmap。久而久之，你会学到这群特定用户的具体 pattern、偏好、边角。这就是「复利价值」的含义：每一次改进让产品更有用，驱动更多使用，创造更多反馈，又驱动更多改进。

这份数据是时间锁的、上下文特定的、不可被复制：你买不到来自数千在你产品里磨细 workflow 的用户的「行为指纹」。

Claude 能帮你审计已有的用户交互数据、识别其中信号最强的行为 pattern、设计让持续使用变成系统模型改进的反馈回路。

练习： 把你产品的交互数据汇总喂给 Claude：你在收集什么、收了多久、对用户随时间如何与产品交互你知道什么。让它识别该数据中三条信号最强的行为 pattern，并为每条设计一个反馈回路把它转成系统性模型改进。然后让它帮你写一份一页的「护城河叙事」给产品营销：你的数据飞轮如何运转、转了多久、为什么一家今天起步、资源充足的竞争者也要至少两年才能复制它。

创建工作流锁定

复利数据网络效应让你产品更难复制；用户工作流锁定让它更难离开。用户在你产品里跑日常运营的时间越久，它就越深嵌入他们的工作方式。他们在上面搭了自动化、训人去用它、把它接到自己的数据源和其他工具。他们 develop 的 prompt、refined 的 workflow、standardized 的输出——都已围绕你产品的行为塑形。此时切换不再是产品决策，而是全规模运营项目。

创建工作流锁定第一步是让 Claude 按集成深度画出当前客户：对每个客户细分，他们在你产品之上 build 了什么 workflow、依赖哪些集成。这告诉你产品在哪里粘住、哪里需要更深。

你提供越多集成，客户能用你产品 build 的工作流表面积越大。Claude Code 帮你快速搭与数据管线、项目管理工具、目标用户依赖的其他系统的原生集成。Claude Code 还能 build API、webhook、SDK，让客户在你产品之上 build——而不只是用它——锁定最深的那种。

练习： 让 Claude 帮你为前十大客户做一次 workflow 集成审计。对每位客户记录他们 build 的自动化、依赖的集成、跨他们的团队 workflow、你估计的切换成本。然后让 Claude 跨组识别 pattern：哪种集成对你这特定产品创造最深锁定？对当前只在表层集成的客户，你能 build 或开放什么去加深？

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

在 AI 时代，创始人的工作没变：找到一个真问题、build 解决它的东西、把它 scale 成一家有意义的公司。变的是抵达路径。Idea / MVP / Launch / Scale 四阶段一起，AI 把「季度」压缩成「周」。

过去要花几个月的验证周期现在用一个下午；可工作的原型不再需要有正确栈的联合创始人，只需要清晰问题加几次专注的 coding agent session；Launch readiness 从 pre-launch 的兵荒马乱压成持续工作流；scale 阶段，过去逼早期招聘进入救火模式的运营负担，越来越可以交给 AI，让团队把注意力放到「变成护城河」的判断决策上。

瓶颈不再是「你能 build 什么」，而是「你选择 build 什么」。

第 8 章资源

用 Claude build

Building AI Agents for Startups： 创业如何在 scale 时减少对创始人依赖
Claude Code docs： 从首次安装到高级 agentic workflow。Pro 提示：先看「How Claude Code works」总览
Claude Code best practices： Anthropic 内部及外部工程团队验证过的 pattern：上下文管理、权限、规划、验证 workflow
Using CLAUDE.md files： 如何为你的代码库配置 Claude Code。MVP 阶段创始人搭开发环境时的必读
Claude Code power user tips： 来自 Claude Code 团队自己的 workflow pattern，包括并行 session 与验证回路
Get started with Claude Cowork： 团队如何 set up Claude Cowork、上线 skills、plugins 等让其在创业内 scale 影响力
Tutorials： claude.com/resources/tutorials 提供可搜索的具体任务实操 walkthrough

创始人故事

三家 YC 创业如何用 Claude Code 搭出他们的公司： HumanLayer (F24)、Ambral (W25)、Vulcan Technologies (S25) 如何用 Claude 在 agentic coding workflow 下快速 prototype-to-market 并 scale AI 驱动平台
GC AI 的创始人用领域专长 build 出针对 in-house 法务团队实际工作方式的 Claude 驱动法务平台：公司特定 playbook、跨职能 stakeholder、可变风险容忍门槛
Carta Healthcare 用 Claude 为其临床抽象平台提供动力，处理每年 22,000 例外科 case，把数据抽象时间减少 66%
Anything（由 Claude 与 Agent SDK 驱动）已帮助 150 万用户把想法变成可工作软件产品，无需写代码；包含一位非技术背景创始人 build 并已经在卖一份全功能招聘平台。Anything 的 AI agent 处理完整 build，所以单干创始人能把领域专长发挥到极致
Cogent 是一家用 agent 自动化关键企业安全任务的应用 AI 实验室。它把 Claude 作为推理层，自动化跨完整漏洞生命周期的调查、优先级、整改
Airtree 把 Claude Cowork 当作运营基础设施中心，统一过去散布在十多个工具和团队的数据。现在一个人 build 出的 workflow 自动化，组织里每个人都能用来做那些总没空做的 to-do
Duvo 构建 AI agent，跑 ERP、供应商门户、电子表格、邮件甚至电话的采购、供应链、品类管理流程。Duvo 完全 build 在 Claude 上，用 Agent SDK 跨 workflow 编排
Zingaro 是一个 24/7 自动化运营家庭护理机构的 AI agent 平台。该创业用 Claude 的结构化工具调用跨 EMR 与多通信渠道编排，并用 Claude 的上下文推理 build 出能给出细腻、患者定制结果的 agent，而不是对最常见 pattern 做 pattern match
Kindora 是一家由非营利高管 build 的 AI 平台，用 Claude Sonnet build 出急需的工具，用于把慈善与资助方智能匹配。在把数千匹配过滤到少数值得追的之后，Kindora 的 MCP connector 让非营利能在 Claude 内直接访问其潜在客户工具
Wordsmith 由一名转型为 CTO 的律师创立，为 in-house 法务团队提供可靠 AI 驱动的法律技术。Claude 是 Wordsmith 合同审阅、协议起草、文档审阅能力的推理引擎；工程团队用 Claude Code build 与演进该平台本身

创业支持与机会

Anthropic Startups Program： 与 Anthropic VC partner 合作的创业可获免费 API credits、最高 tier 的公开 rate limit、专属创始人活动与 workshop 邀请
Claude community： builder 的论坛与社区空间
Live learning resources： 会议、webinar、直播、回放

目录

第 1 章 重启 2026 的创业生命周期

第 2 章 创始人的定义正在改变