3. 创始人手册：打造 AI 原生初创公司

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

The founder's playbook: Building an AI-native startup

https://claude.com/blog/the-founders-playbook

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

AI 正在重塑初创公司的构建方式。今天，从未写过一行代码的创始人也可以发布生产级应用；而"10 人独角兽"也已经从一个带点草莽色彩的弱者故事，变成一套可以被有意规划的行动方案。

在 2026 年，AI 可以编写生产代码、开展市场研究、综合竞争格局、起草投资人材料，并自动化运营工作流。过去，即便是经验丰富的技术创始人，要整合把想法变成现实所需的工具、平台和系统，也要跨过陡峭的学习曲线。AI 最重要的影响，是把"谁能够启动一家初创公司、谁能够构建一个产品"的门槛大幅拉平。

在 2026 年，一个好想法能把创始人带得比以往更远。Agentic coding 把过去需要一支工程团队完成的工作，压缩成创始人自己可以交付的成果。

传统的初创公司成长路径假设，从想法到规模化的过程是：验证 → 融资 → 招人 → 构建 → 再融资 → 增长 → 再招人 → 循环往复。现在，AI 已经抹掉了这样一种预期：创业生命周期每进入一个新阶段，就必然需要更大的团队、不同的技能组合和新一轮融资。

这本手册会根据新的现实，重新绘制创业旅程的四个核心阶段：创意、MVP、发布和规模化。我们会考察，当 AI 成为技术与组织发展的核心时，每个阶段会是什么样；每个阶段适合使用哪些工具；以及创始人如何通过这些工具压缩时间线。如果你已经准备好寻找从想法到退出的最短路径，请继续读下去。

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

过去，创始人常常由他们"能做什么"来定义：技术创始人写代码，非技术创始人负责商业运营和成交。但在 2026 年，创始人可以使用的模型、系统和 AI agents，已经消解了"能构建的人"和"拥有值得构建的想法的人"之间的墙。

AI 原生初创公司正在从根本上改变"创始人"这个角色。现在，一个没有工程背景的人可以构建生产级软件，把自己的想法变成现实；而一个技术能力很强、商业知识不多的创始人，也可以轻松产出 go-to-market 策略、财务模型和高度打磨的融资演示文稿。

历史上，创始人大部分时间都处在执行模式：写代码、管理人员、处理日常运营工作。在 AI 原生初创公司里，创始人的角色不再那么像个人贡献者，而更像 agents 的编排者。这里的 agents 是专门化的 AI 助手，它们可以读取文件、运行命令、执行代码，甚至浏览网页。创始人的注意力会上移，转向更高阶的工作：产生想法，并指挥系统（AI agents、工具，以及可能存在的小团队）把这些想法执行出来。

不过，以 AI 作为核心基础设施最具革命性的结果，是解放了拥有主题专业知识的非技术创始人。当创始人池子不再局限于工程背景的人，你会看到由生活经验完全不同的人创办的公司，去解决传统技术创始人管道从未优先考虑、甚至可能从未注意到的真实问题。

面向精简初创公司的 AI 工具能力

传统创业模型假设：你需要雇工程师来构建，需要雇销售来卖，需要雇运营来跑业务。员工人数经常被视为组织动能和产品成熟度的标志。

2026 年的早期初创公司完全不同。它们在设计上就极其精简，往往只有创始人一人，或者一个很小的团队。通过把技术发展和组织发展都建立在 AI 这种基础设施上，它们可以在扩张团队之前，就达到产品验证、早期收入，甚至盈利。

AI 尤其能帮助初创公司在三个方面像更大的组织一样运转：研究、agentic coding，以及关键业务运营工作流自动化。

对话智能与研究

可以把它理解成：每个领域的随叫随到专家。

想想一位创始人在第一年必须知道，但一开始几乎肯定不知道的所有事情：如何设置工资单？如何规划产品开发 sprint？如何起草一份紧凑的投资人 memo？

这类早期创业问题过去通常只有一个答案：找到懂的人。对于自举或种子前阶段的创始人来说，这可能意味着把本该用来构建产品的时间耗在收集知识上，或者把早期资金的一部分花在顾问身上。现在，他们拥有了一个几乎覆盖所有领域的随叫随到专家：AI。

深度研究：竞争分析、市场规模测算、财务建模。
文档起草：融资演示、案例研究、投资人 memo、产品需求文档。
战略思考伙伴：反方分析、事前验尸、情景规划、路线图优化。

Agentic coding

可以把它理解成：永远在线、永不被卡住的工程师。

过去，构建软件需要一个技术联合创始人、一个外包开发团队，或者足够长的 runway 来先雇一支工程团队，之后才能写下第一行生产代码。

Agentic coding 工具现在允许每一位有志创业者用自然语言描述想构建的东西，并指挥 AI 以一支完整工程团队的速度和规模，生成、测试、调试并重构生产级代码库。

从"我有一个想法"到"我有一个产品"的时间线被压缩了。创始人的角色现在更集中在决定构建什么以及为什么构建，而 AI 则负责真正搭建可以服务真实用户的基础设施。

工作流自动化

可以把它理解成：按需调用的自动化运营团队。

即使创始人已经能像顾问一样做研究、像工程团队一样构建产品，战略规划和产品开发之外仍然有一整类事情必须完成：排期、更新 CRM、拉取周报、维护文档、发布内容、跟踪合规要求、管理公司运行所依赖的各种工具和系统之间的连接组织。这些也都必须发生。在精简初创公司里，这些负担主要落在创始人身上，并且会显著消耗本该用于高阶决策的时间和注意力。

借助 AI 工具进行工作流自动化，可以卸掉这部分负担。重复性运营任务可以被配置为自动发生：当一笔交易推进时 CRM 自动更新；周报自动汇总；产品文档随着产品变化同步更新。关键是，Claude Cowork 可以与初创公司运行所依赖的互联系统集成，包括项目管理工具、沟通工具栈和数据源，而不需要有人专门构建和维护这些集成。在 Day Zero 初创公司里，这个人几乎总是创始人本人。

时机与编排决定一切

能够有效利用 AI 的研究、自动化和 agentic coding 能力的创始人，可以构建出一个杠杆率远高于员工人数的初创公司。他们也可以把大部分时间和心智带宽投入到真正重要的工作上。

但这些工作不会自动发生。编排这些 AI 工具的创始人，必须知道如何以及何时应用它们。本手册接下来会探索创始人在沿着 AI 原生创业路径前进时会遇到的目标和挑战，以及如何在旅程的每个阶段有效使用 AI 工具。

第 3 章：创意阶段

每一位初创公司创始人都从同一个地方开始：一个让他们无法停止思考的问题。这个阶段是想法遇到现实的阶段。2026 年的创业成功，要求创始人具备一种纪律：在证据足以支撑之前，不要开始构建。

这个阶段的工作是研究、客户发现、竞争分析，以及诚实评估反证。所有这些都应该发生在你要求 Claude Code 生成第一行生产代码之前。

创意阶段目标

在创意阶段，创始人的主要目标是以研究为导向的验证：在投入资源构建之前，收集扎实证据，证明真实问题确实存在，并且你提出的解决方案确实能够有效处理它。

具体来说，创意阶段是一系列创始人必须大致按顺序回答的问题：

这个问题是否真实、具体，并且出现频率足以围绕它构建产品？
到底是谁拥有这个问题？这些人能否构成一个市场？
是否有人已经在解决这个问题？如果有，他们如何解决、解决得有多好？
一个解决方案究竟需要做什么，才能真正解决这个问题？我的想法是否做到了？

这些问题的回答会共同指向一个最终问题：这件事值得构建吗？

这意味着你要在行动之前变得具体。"人们在费用报销上很痛苦"只是一个观察。"中型企业的财务经理每周花 4 小时以上核对报销提交，因为他们现有工具无法和会计软件集成"才是一个可测试的假设。

创意阶段退出标准

创意阶段的退出条件，是找到问题-解决方案匹配。你已经通过真实的人类对话等定性证据，确认自己正在为真实的人解决真实问题，然后才开始构建那个解决问题的东西。

当你可以对以下三个问题全部回答"是"时，就准备好离开创意阶段：

问题是否真实且具体？要肯定回答这个问题，你必须能准确说出谁会经历这个问题、他们多频繁遇到它、它对他们造成多严重的影响，以及他们目前如何处理它。
你的解决方案是否处理了真正的问题？不是你最初假设的问题，而是验证过程揭示出来的问题。有时候这两者相同，但并不总是如此。
你是否拥有足够信号来证明构建是合理的？这个阶段永远不会有确定性，等待确定性本身就是一种失败模式。但你需要足够定性证据，让进入 MVP 成为一个理性决策，而不是信仰之跃。

创意阶段挑战

创意阶段是创业旅程中最重要的工作发生之处，因为最具后果性的错误也会在这里发生。现在弄错，很快就会让你刚刚起步的事业偏离轨道。不过，大多数创意阶段挑战都与"行动速度超过理解深度"有关。因此，只要创始人以深思熟虑和审慎的方式推进，就能稳步前进。

把构建误认为验证

挑战：当技术阻碍被移除时，热情高涨的创始人很容易跳过创业旅程中最重要的工作：验证自己的想法是否真的是人们需要并会使用的解决方案。

即便在当前 agentic coding 时代之前，也有 42% 的初创公司失败，是因为它们构建了没人想要的东西。而现在，Claude Code 这样的 agentic coding 解决方案极大缩短了"我有一个想法"和"我有一个产品"之间的距离，这个失败率只会继续上升。

对于拥有一个足以震动神经元的好想法的创始人来说，从未有过比现在更好的时代。但能够快速、轻松地搭出一个看起来像产品的原型，也反直觉地给 AI 原生初创公司带来了真正的生存风险。

直到不久前，构建还需要真正的开发时间和预算，即便是基础原型，通常也要花几个月。现在，技术开发这道门槛基本消失，AI 让创始人太容易直接开始构建，而不去验证它在真实世界中的效用。

达到问题-解决方案匹配需要先验证假设再构建。但很多初次创业者，甚至经验丰富的创始人，会错误地以为 AI 让这个要求变短路，把流程变成：有一个想法 → 立刻构建原型 → 把原型存在本身当成验证。原型于是成了相信假设一直正确的理由，却从未真正测试假设是否成立。

一个能运行的原型很容易被误认为你正在解决真实问题的具体证据，但它不是。你的原型更应该作为与潜在用户对话时的压力测试道具。真正的证据，是这些对话本身。

过早规模化

挑战：当构建变得轻松且即时，你可以让执行规模远远跑在业务需求之前。

过早规模化意味着，在尚未真正验证某条产品路径值得投入之前，你就已经承诺走上那条路径。

这一直是初创公司的杀手，而 AI 让创始人更容易在不知不觉中掉进过早规模化陷阱。Agentic coding 助手如此强大，以至于你很容易在没有有意识偏离方向的情况下，让执行规模远远超过问题-解决方案匹配的验证进度。

它会围绕一个根本错误的前提，带着和好想法完全一样的热情生成、测试、调试和重构代码库。系统中的智能是你自己的。这个阶段的首要指令，是让你的理解能力始终领先于构建速度，尤其是在构建如此快速、看起来如此轻松的时候。

失去客观性

挑战：如果你要求 AI 工具寻找支持你既有信念的证据，它会找到。确认偏误现在配上了研究引擎。

确认偏误一直是初创公司的职业风险：创始人天生对自己的想法充满热情。现在，AI 工具给确认偏误装上了强力推进器。让 AI 验证你的创业想法，它会找到支持证据；让它测算潜在市场规模，它会找到一个让你的 TAM 看起来足以融资的数字。

AI 会顺着你的方向走。这意味着，如果创始人不提出尖锐问题，就可以比以往更快地为一个糟糕想法构造出一套看起来研究充分、细节完备的论证，并且还会觉得自己确实在做尽调。解药仍然是同一个工具，只不过要朝相反方向使用：AI 可以像验证一个想法一样彻底地压力测试一个想法。

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

Claude 如何帮助创意阶段创始人

把 AI 原生创业概念推进过创意阶段，可能让人感觉永远没有尽头。你是创始人，你就是想构建。但这个至关重要的起步阶段本质上是研究和验证练习，因此你应该使用那些能帮助你在写代码之前更严谨思考的工具。下面是如何在 Claude 的不同产品界面（Chat、Claude Cowork 和 Claude Code）中使用 Claude，让你尽可能快地完成创意阶段，同时完成必要的尽职调查。

Chat、Claude Cowork 或 Claude Code：选择合适的 Claude 界面

AI 让初创公司创始人更容易更快交付、自动化繁琐工作流，并以规模化方式运行。但你使用的界面很重要。下面是根据任务选择 Chat、Claude Cowork 或 Claude Code 的方式。

Chat 适合不离开当前应用的快速交流。用它处理公司运行中的日常小任务：从一份密集的投资人 memo 中提炼一句话要点；在董事会会议前 sanity-check 一个说法；或者理解团队里一条很长的 Slack 讨论。

Claude Cowork 适合真正耗时的知识工作：从多个来源提取内容，理解并综合，然后产出一个完成品，比如文档、演示文稿或电子表格。例子包括：把一文件夹客户访谈记录转成下一次产品评审用的主题发现文档；在融资前从十几个供应商网站构建竞争格局；或者设置一个每周一早晨的固定任务，从连接工具中拉取指标，并把每周 KPI 简报放入共享文件夹。

Claude Code 是团队工程师使用的 agentic coding 环境：它可以直接访问代码库，具备 Plan Mode、git 集成，以及本地、IDE 或沙箱云环境。精简团队可以在这里跨不断增长的代码库交付功能，从 MVP 时代的遗留代码中迁移出来，并在不等待更多人手的情况下从原型走向生产。

如果任务是	选择	原因
一个问题、一次改写、一次快速头脑风暴	Chat	快速、对话式、无需设置
基于你的文件和系统完成研究、分析或成品文档	Claude Cowork	文件夹访问、连接器、Skills、定时运行
编写、测试或发布软件	Claude Code	代码库访问、diff、git、开发环境

三者底层都是同一个 Claude；变化的是围绕它的工作空间。

定义并压力测试问题假设

你自己的领域专业知识和前期研究已经产生了一个假设。第一项工作是把它打磨到真正可测试。Claude 在这里特别有用，因为它会迫使你变得具体：到底是谁有这个问题，频率多高，严重程度如何，他们现在怎么处理？一个无法精确回答这些问题的问题陈述，还没有准备好进入验证。

练习：和 Claude 一起打磨你的问题陈述，直到它成为一个可测试假设。例如，"合同审阅太慢"并不具备真正可测试性。但"中型企业的内部法务团队每个合同审阅周期要花 3 天以上，因为红线修改散落在邮件线程中，而不是一个版本受控的文档里"，就是非常可测试的。

下一步，是让 Claude 反驳你的想法，并寻找能推翻你假设的反证。这可以浮现负面市场信号、失败的竞争者、客户行为模式，以及支持性综合分析可能悄悄降权的结构性障碍。

目标是在进入客户发现之前，已经用最强的可得反方论据压力测试过你的假设，这样信息型用户访谈才会真正开放，而不是确认偏误搜索。

提示：把 Claude 用作结构化反方，是 AI 创业生命周期每个阶段的核心用法。

市场研究与竞争格局映射

评估竞争者

创业中有一种特定现象叫竞争者忽视：过度关注自己的愿景和执行，以至于系统性低估同一领域里其他人在做什么。幸运的是，AI 提供了解药：让 Claude 构造最有说服力的论证，说明为什么这个解决方案空间中的某个竞争者会成功，而你不会。

Claude 可以分析为什么他们的方法实际上更好、为什么客户会选择他们、为什么你以为的差异化可能并没有你想象中那么可防御。

练习：让 Claude 按层级绘制你的竞争格局：直接竞争者、间接竞争者、潜在收购方，以及可能进入你所在空间的相邻玩家。然后让它说明每一层为什么对你的成功构成真实威胁，而不只是你最容易轻视的那种威胁。

市场研究

Claude Code 可以综合公开客户反馈，发现重复出现的抱怨和未被满足的需求。额外好处是：这本质上是免费获取竞争者客户的定性研究。

练习：指挥 Claude Cowork 综合关键来源中的竞争者评价，识别现有解决方案尚未解决的主要抱怨。如果你的假设解决了其中一个或多个，这就是问题-解决方案匹配的强信号。如果没有，这同样值得知道。

Claude Cowork 还可以从密集的行业报告、分析师文件和市场研究文档中提取相关信息和数字；随后，这些干净、综合后的输入会成为 Claude 分析工作的理想上下文。

练习：基于公开数据构建 TAM/SAM/SOM 模型，并压力测试背后的假设。判断市场是在扩张、整合还是成熟；这个背景会影响你如何思考时机和差异化。绘制买方格局：谁掌握预算，谁影响决策，这两者是否是同一个人。

趋势分析

最后，用 Claude 监听早期指标，判断你是否在正确时机进入。跟踪那些已经在讨论你的问题的 subreddit 和 LinkedIn 群组，以及用户描述痛点时使用的准确语言。让 Claude 识别那些曾经解决类似问题的相邻市场，并提取哪些做法有效、哪些无效。浮现监管、技术或人口结构趋势，判断它们会加速还是威胁这个机会。

练习：让 Claude 识别三个外部趋势（监管、技术或人口结构），评估它们在未来两年可能如何显著影响你的市场，并判断每个趋势对你的具体假设而言是顺风还是逆风。

提示：本节中的市场研究和竞争映射不是一次性练习。你会在 MVP 和发布阶段持续发现新信息、演化思考。因此，每当你的假设发生变化，都应该重复这些练习。

规划和设计客户发现

你通过和潜在产品用户交谈能学到什么，取决于两件事：你问的问题质量，以及你是否在问正确的人。Claude 在客户发现方面尤其有帮助，包括应该和谁聊、该问什么，以及如何理解你听到的内容。

该和谁聊

一个精确的目标画像，比一长串联系人名单更有价值。它应包括最可能强烈经历这个问题的具体职位、公司类型、团队结构和资历层级。接着，识别这些人真实可触达的地方：社区、活动、LinkedIn 群组和 Slack 工作区。然后基于他们离问题有多近，建立优先联系框架。

该问什么

确定目标之后，用 Claude 构建访谈框架：正确的问题、正确的顺序，并且结构要能浮现人们实际做什么，而不是他们以为自己将来会做什么。新手创始人常犯的错误，是提出关于未来的泛泛开放问题（"你会用这样的东西吗？"），而不是具体询问相关的过去（"告诉我上一次你处理这个问题时发生了什么。"）。

Claude 可以标出草稿问题中哪些在引导受访者、过于宽泛，或可能产生噪音而不是信号。Claude 也可以帮助你设计追问，用来处理回避或深入挖掘重要问题中的模糊回答。

如果你的假设涉及多个角色，Claude 还可以为每个角色设计不同的问题集。财务经理和 CFO 与同一问题的关系不同；单一访谈框架会抹平这种差异。

练习：先手写你的访谈问题，再让 Claude 审核。明确要求它标出所有引导性、面向未来、过于宽泛，或可能产生社会期望答案而不是诚实答案的问题。然后让它为访谈中最可能出现回避的两三个时刻设计追问。

访谈后分析

每次对话后，用 Claude 做复盘：把你的笔记喂给它，让它识别哪些内容确认了你的假设，哪些挑战了它，哪些是真正令人意外的发现。收集了一批访谈之后，把整组访谈笔记交给 Claude Cowork，让它浮现反复出现的主题、矛盾点，以及正反两个方向上最强的信号。然后把综合输出带回 Claude，让它标记你对数据的解读是否可能是在匹配你想听到的模式，而不是数据本身。

练习：每完成五次访谈，就指挥 Claude Cowork 综合你的笔记，并产出两个列表：支持你假设的证据，以及挑战你假设的证据。如果第一个列表显著长于第二个，让 Claude 判断这种不对称反映的是数据本身，还是你希望发现的东西。

客户外联与排期

使用 Claude Cowork 自动化围绕联系人名单构建、外联和用户访谈排期的运营负担。

Claude Cowork 可以使用你与 Claude 定义的目标画像（包括职位、公司类型和资历层级），研究并汇编一份结构化的潜在受访者名单和已验证联系方式。随后，它可以大规模起草个性化外联邮件，并根据每个人的角色和背景调整内容。随着回复进入，它可以通过 MCP 连接 Gmail 和 Google Calendar 来管理线程、处理排期请求，并把访谈放入日历。工作流还会继续：Claude Cowork 根据设定节奏生成后续跟进草稿（例如给七天未回复联系人的跟进），并随着每一步完成更新你的跟踪表，这样你始终知道每个潜在受访者在管道中的状态。

练习：把你验证后的访谈目标画像交给 Claude Cowork，让它构建潜在受访者名单，起草个性化外联序列，并设置一张跟踪表，列包含外联状态、跟进节奏和访谈完成情况。然后让它运行协调工作，而你专注于准备对话本身。

设计最终解决方案概念

你已经完成验证工作：问题真实存在，你知道谁拥有这个问题，并且你有一个证据支持的解决方案概念。使用 Claude 从各个角度发展并挑战你的解决方案概念：有哪些缺口？有哪些替代方案？要让这个方案在规模化时成立，必须满足哪些条件？

这是一个重要的现实检查：这个设计是否真正处理了验证过程揭示的问题，而不是你一开始假设的问题？

练习：把你的解决方案概念呈现给 Claude，让它识别你的设计最依赖的三个假设。然后询问每个假设要成立必须满足什么条件，以及如果任意一个假设不成立，会产生什么后果。

用 Claude Code 构建轻量原型

现在进入有趣的部分：有了验证过的假设和经过压力测试的解决方案概念之后，你终于准备好构建某个东西了。

这是创意阶段中 Claude Code 入场的时刻。即便你之前一直在 tinkering，现在才是生成正式轻量原型的节点：只构建足以把想法放到真实人类面前、获得真实反应的最小表面积。

你还不是在构建真实世界产品；你是在构造一个想法的功能样本，用于客户和投资人对话。真实用户与一个他们能实际触碰的东西互动，会告诉你十几次问题-解决方案发现访谈无法告诉你的事情。之前，你是在确认自己要解决的问题是否真实；现在，你是在让潜在用户接触拟议解决方案。

练习：定义你的解决方案所依赖的单一核心交互。指挥 Claude Code 只构建它。当你得到这个原型后，把它交给五位来自已验证目标画像的人试用。你在这五次对话中学到的内容，将决定你是继续构建，还是回到绘图板。

到达创意阶段终点，是 AI 创业竞赛中的巨大跨越，因为此时你不是在押注直觉，而是在基于证据执行。接下来是 MVP 阶段，创始人的指导问题会从"这件事值得构建吗？"变成"我们首先究竟应该构建什么？"AI 的主要角色也会从研究伙伴转变为施工队。

第 4 章：MVP 阶段

很多创始人把 MVP 阶段当成构建阶段，但 MVP 阶段本质上仍然是收集证据的练习。区别在于：你现在收集的是关于解决方案的证据，而不是关于问题空间的证据。具体来说，你要验证一个真实、可识别的人群是否认为它足够有价值，愿意使用它、回到它、为它付费，和/或把它推荐给别人。

MVP 阶段目标

作为 AI 原生初创公司的创始人，你的目标是把一个经过验证的问题转化成真实用户会实际使用的工作产品。这不是包含路线图全部功能的完整版本，而是你想法中最小、最聚焦的迭代：它把一个真实解决方案放到真实用户面前，并生成有关产品-市场匹配的真实证据。

与此同时，你现在怎么构建，会决定以后什么是可能的。这意味着 MVP 阶段还有第二个同样重要的目标：快速行动，但不要累积那种会复利增长、并在真实用户大量到来时反过来困扰你的技术债。

最后，从第一天起投资于持久上下文，是让 AI 成为力量倍增器而不是熵源的关键。在 AI 原生初创公司里，你的代码库是你会一轮又一轮与 AI 协作的对象，因此可读性是基础。不写规格、架构决策和上下文文件（例如 CLAUDE.md）的创始人，会撞上一堵可预见的墙：每个新会话都要重新解释代码库，而 AI 生成的修改会逐渐偏离最初愿景。

MVP 阶段退出标准

MVP 阶段的退出条件，是真正的产品-市场匹配证据：证明一个具体、可识别的用户群体认为产品足够有价值，以至于会回来使用它（留存）、为它付费（收入），或告诉别人（推荐）。

MVP 阶段挑战

在 MVP 阶段，创始人的首要指令是速度和判断力。这里的挑战集中在：你能否足够快地以正确方式构建正确的东西，同时不走那些之后会让你付出代价的捷径。

Agentic 技术债

挑战：因为 AI 实质上移除了过去控制什么能进入生产环境的所有自然瓶颈，速度已经有了保证。但当速度成为创始人在 MVP 构建中唯一考虑的变量时，他们就有可能累积很难偿还的技术债。

MVP 阶段存在一些技术债是合理的，前提是你理解这些债必须在规模化之前被管理。普通技术债会逐渐积累，可以随着时间或一个专门 sprint 清理。但 AI 技术债会复利增长。

如果没有把规格和架构约束写在 AI 能读到的地方，每一次会话都会从头重新推导基础决策，而这些决策会漂移。最后你得到的是一个背后没有一致心智模型的代码库。不是因为某一块很糟，而是因为这些块从未被设计成相互配合。这是真实问题，而且通常会很晚才暴露。

陷入虚假的产品-市场匹配

挑战：AI 工具可以生成令人印象深刻的早期数字，但这些数字并不能保证市场需要你的产品。

早期势头是创始人最强烈的心理体验之一。在经历数周或数月的验证和克制构建之后，发布产品会让人感觉自己从一开始就是对的。

Agentic coding 工具可以让你比以往更快抵达这一刻，但早期 traction 不等于产品-市场匹配。发布能量可能来自短暂因素：创始人的朋友、投资人其他被投公司中的潜在买家，或者 Hacker News 标题带来的流量尖峰。不幸的是，这些因素都无法可靠预测第六周或第十二周、最初助推消退后会发生什么。

零摩擦范围蔓延

挑战：当构建感觉毫不费力且几乎免费时，总还有一个很酷的功能可以加，还有一个边界案例可以处理。这种范围蔓延可能弊大于利。

范围蔓延一直是创业风险。不同的是，如今传统上抑制范围蔓延的强制因素，也就是真实工程时间成本，在 agentic coding 让"加一个功能"从一个 sprint 变成一个下午之后，不再以同样方式存在。

这里的挑战在于，每一次单独新增都看起来站得住脚。当然产品应该处理那个边界案例；当然用户会想要那个工作流。因为每一个新增用 agentic coding 构建起来都如此省力，所以它们在当下不像范围蔓延。但当产品扩展到原始边界之外时，你可能会失去方向和动量。

解药是在构建开始之前写下范围定义：产品做什么、明确不做什么，以及只有哪些来自真实用户的具体证据，才足以证明现在应该添加新东西。这样，决策点就从"我们是否应该构建这个？"转变为"是否有足够多关键用户告诉我们，如果没有这个，他们无法从产品中获得价值？"

因缺乏经验而不安全

挑战：创始人使用 AI 工具快速把应用推向市场，却没有先理解基本安全原则，最终会让用户暴露在本可避免的风险之下。

残酷事实是：agentic coding 工具生成的是能运行的代码，而不是天然安全的代码。功能性代码很容易判断，因为功能要么工作，要么不工作。安全漏洞在被利用之前是不可见的，这意味着没有自然反馈回路提醒初次创业者出了问题。然而，把一个活的 MVP 交给真实用户，意味着真实数据、真实暴露面，以及出错时的真实后果。

忽视安全并不是 AI 原生项目的新问题。每个时代的自举初创公司都经常把安全考虑推迟到很晚，有时直到生产发布前夕。最低限度的责任标准，是在任何用户触碰你的应用或解决方案之前完成安全审查。

Claude 如何帮助 MVP 阶段创始人

在构建之前定义架构

在 Claude Code 写下第一行生产代码之前，先用 Claude 定义并记录将支配这一阶段所有构建工作的架构决策：要遵循的模式、要避免的依赖、正在做出的取舍以及原因。这个输出会成为聚焦的架构上下文文档，并建立 Claude Code 将在其中运行的护栏。

没有这些上下文，每个会话都会从零开始，Claude Code 被迫推断自己的结构性假设。让 Claude Code 在没有护栏的情况下构建，会产生一个功能上能运行但结构上不一致的代码库。迭代和扩展不一致的代码库，最终是在浪费时间和 token。迟早会有一个点，代码不可避免地崩塌，迫使你从头重建。

练习：在打开 Claude Code 之前，先打开 Claude，描述你正在构建什么：它解决的核心问题、服务的用户，以及未来六个月你现实预期的规模。让它帮助你定义 MVP 构建应遵循的架构原则、在约束下应避免的依赖，以及这个阶段你有意识接受的取舍。

接着，把这个输出保存为 CLAUDE.md Markdown 文件。这是你的架构上下文文档：构建过程中的第一个 artifact，也是之后每一次会话所依赖的 artifact。CLAUDE.md 文件作为 Claude Code 的项目级说明，提供项目特定上下文和指令，并在 Agent SDK 于某个目录运行时自动读取。从功能上说，它们就是项目的持久"记忆"。

定义并执行 MVP 范围

无摩擦的范围蔓延，是 AI 时代 MVP 的典型失败模式之一。正如你定义并记录了产品应用架构，也需要在第一个功能被构建之前，定义 MVP 的范围。

Claude 可以帮助你创建一份范围文档，描述你的 MVP 产品做什么、明确不做什么，以及功能修订标准：什么来自真实用户的具体证据，才足以证明现在应该新增某个东西。

当新功能想法出现时（它们一定会出现），你可以用 Claude 压力测试它是真正的用户信号，还是披着产品思考外衣的创始人热情。

用 Claude Code 构建 MVP

架构和范围确定之后，Claude Code 就成为主要的 MVP 构建工具。用它生成、测试、调试和迭代你的代码库，但把每次会话视为执行你已经做出的产品决策，而不是随手加入新决策的机会。

每次 Claude Code 会话开始时，先重新查看范围文档，并把 CLAUDE.md 架构上下文文档提供给模型。每次会话结束时，把会话中浮现的任何决策更新进去。目标是得到一个你能解释其结构的代码库，而不只是一个能运行的代码库。

练习：为 Claude Code 工作创建一个简单的会话模板，包括架构上下文文档、本次会话的具体任务，以及需要遵守的约束或模式。每次会话结束时，在上下文文档中添加一条简短日志，说明构建了什么、做出了什么决策、引入了什么假设。每次花五分钟记录，是防止架构漂移复利成不可管理代码库的廉价保险。

在任何用户接触之前进行安全审查

作为 AI 原生初创公司创始人，你有责任知道代码库里有什么，理解任何潜在暴露向量，并且不要把明显漏洞发布给信任你处理其数据的真实用户。

Claude 可以对 AI 生成代码做有用的第一轮安全审查，并帮助识别常见漏洞。在发布前把它纳入循环是一个好习惯。不过，它不能替代安全工具；在更高风险场景下，也不能替代人类审查者。把它当成替代品的创始人，才会成为事故故事的主角。

Claude Code Security 更进一步：它可以扫描代码库中的安全漏洞，并为人工审查建议有针对性的补丁，浮现传统方法可能漏掉的问题。

提示：在本电子书发布时，Claude Code Security 仍处于有限 beta 阶段，因此在把它纳入工作流之前，请检查当前可用性。

练习：在部署给任何真实用户之前，用一个具体 brief 让 Claude 审查你的核心应用代码：检查认证和会话处理、API 响应中的数据暴露、输入验证与注入风险，以及已知漏洞依赖。认真对待每一个发现，并评估是否需要修复。任何涉及认证、密钥或数据处理的问题，都应进行人工审查。

在发布前构建度量框架

那些把早期 traction 误认为产品-市场匹配的创始人，通常也是那些在发布之后才开始跟踪数据，并选择指标来评估哪些东西有效、而不是浮现哪些东西无效的人。解药是在第一位用户出现之前建立度量框架。

用 Claude 定义哪些指标对你的具体产品重要、基准是什么，以及数据中的哪些模式构成真正的产品-市场匹配，哪些只是讨喜的噪音。具体来说，在发布 MVP 之前，就设置好留存基准、激活标准，以及 Day 7 和 Day 30 目标。

接着，定义对你的产品而言，假阳性是什么样：注册但不激活，有收入但没有留存，或者初始热情但没有重复使用。数据到来后，让 Claude 构造反对你 traction 的对抗性论证：怀疑者会如何看这些数字？

管理发现与用户反馈物流

一旦真实用户进入产品，运营层会迅速扩张。Claude Cowork 可以处理重要但繁琐的工作，比如构建和维护用户联系人名单、运行外联序列、安排反馈会、分流 bug 报告，以及跟踪迭代周期。创意阶段用于管理发现物流的 MCP 集成，在这里同样适用。

在用户反馈收集中，仍要让人类保留在循环中，尤其是需要细腻探索的部分。比如用户说"这个很好，但我希望它还能......"，这需要解释：这是核心需求还是 nice-to-have？这是这个客户特有，还是代表一个细分群体？缺失功能才是真问题，还是 onboarding 上游出了问题？没有工具能替你回答这些问题。

练习：配置 Claude Cowork 来运行你的 MVP 阶段反馈循环：给早期用户名单起草外联、安排反馈会、设计 bug 报告和功能请求的结构化收集流程，并每周综合收到的内容。先自己审阅综合结果；之后，你可以让 Claude 分析这些信息，捕捉你可能遗漏的重要点。

朝证据迭代，而不是朝完整性迭代

MVP 阶段在你获得真正的产品-市场匹配证据时结束，不取决于产品感觉上有多"完成"。宣布你已经达到产品-市场匹配、准备从 MVP 阶段进入发布阶段，本质上是一项结合创始人直觉和收集证据的判断练习。不过有一些有用的试金石：

Sean Ellis 测试：问活跃用户："如果你再也不能使用这个产品，你会有什么感受？"如果超过 40% 的用户回答"非常失望"，这是一个有意义的 PMF 指标。
努力程度测试：在产品-市场匹配之前，留存需要持续干预，包括频繁外联、激励、个人跟进，以及创始人为了让用户保持参与而投入的英雄式精力。达到产品-市场匹配之后，产品开始自己完成这项工作。当事情开始"拉动"而不是"推动"时，这种努力程度变化是最清晰的信号之一。

最终，没有单一数据点能确认产品-市场匹配。它是一种必须在多个迭代周期中保持成立的模式。

当证据要求时转向

如果即便投入了所有这些工作，你仍然似乎无法到达产品-市场匹配，该怎么办？结果没有确认你一开始的方向，并不是失败，而是系统在运作：MVP 阶段的设计目的，就是在你对错误答案过度投入之前浮现这些信息。

当数据不支持当前产品时，用 Claude 梳理数据究竟在告诉你什么。

探索替代客户细分。也许那些没有转化的用户从一开始就不是正确目标。真正的受众经常已经在你的数据里，只是权重被低估。
调整产品价值主张。也许受众是正确的，但 MVP 没有和用户产生共鸣。调整 onboarding、消息表达或核心功能强调，可能可以修复问题，而不用改变你已经构建的东西。

也要保持开放：这种断裂可能足够深，需要更根本的改变。

练习：如果你已经完成三个或更多迭代周期，却没有朝产品-市场匹配基准取得有意义进展，那么在决定下一步之前，用 Claude 做一次诊断。把留存数据、用户反馈和原始问题假设交给它，并问三个问题：
- 这份数据中是否有某个细分群体的反应不同于其他人？
- 设计价值和体验价值之间的差距，是定位问题还是产品问题？
- 要让当前产品找到真正 PMF，必须满足什么条件？根据你看到的情况，这种场景现实吗？

让答案决定你是调整、转向，还是回到创意阶段。

第 5 章：发布阶段

如果 MVP 阶段是证明你的产品值得存在，那么发布阶段就是证明你的业务值得增长。

发布阶段目标

在发布阶段，初创公司创始人必须把早期 traction 转化成可重复、可持续的增长引擎。除了让产品生产就绪，你还必须加固底层基础设施，同时围绕产品构建真正的公司。

在创意和 MVP 阶段，初创公司天然以创始人为中心，因为你需要完整的情境感知和紧密反馈循环。但现在，如果创始人仍试图亲自抓住每一条线，就会成为发布阶段瓶颈。目标不是把你从公司中移除，而是构建运营系统，让你的注意力释放出来，专注于只有创始人才能做的决策。

发布阶段退出标准

发布阶段的退出条件包含三个元素：

增长可重复，并由渠道驱动。你不只是留住用户，还能通过特定渠道可预测地获取用户，并理解单位经济模型：CAC、LTV 和回本周期都是你知道且能够捍卫的数字。
产品可以承受生产工作负载。基础设施已经加固，安全和合规就位，可靠性能在真实生产条件下维持，而不只是你测试过的条件。
运营不再依赖创始人作为瓶颈。流程已经存在，自动化已经到位。你不再是亲自处理支持、分流、sprint 规划或报告的人。

发布阶段挑战

找到产品-市场匹配是早期创业生命周期中最难的问题。现在，创始人的挑战变成保持它。发布阶段中，即便公司已经找到了真实产品 traction，如果围绕并支撑产品的组织跟不上，公司仍然可能崩塌。以下是需要警惕的失败模式。

技术债到期

挑战：为速度和验证而构建的 MVP 代码库运行得足够好，证明了产品有效。但生产流量、新功能和不断增长的复杂性，现在正在暴露之前的捷径。

在 MVP 阶段，积累一些技术债是为了速度做出的合理取舍。在发布阶段，这些债开始产生利息；越晚处理，修复成本越高。

解决方案包括系统性架构审计，识别结构性弱点；有针对性地重构，处理最严重的问题；以及有意义地扩展测试覆盖率，确保下一轮功能工作不会重新引入同样问题。

创始人成为瓶颈

挑战：在 MVP 阶段，创始人参与每一个循环是一种资产。到了发布阶段，随着支持量增长、产品决策堆积、运营复杂性倍增，同样的本能会变成约束。

从"做工作"转向"设计能做工作的系统"，是创业生命周期中最困难的转变之一。因为很少有一个清晰时刻告诉你转变已经发生，所以风险在于完全错过它，继续停留在构建者模式，而组织在你周围停滞。

一些迹象包括：本该一小时内完成的决策现在要等你一周才处理；支持请求堆积，因为只有你知道答案；运营任务只有在你亲自记得时才会发生。

补救方法是全面审计你亲自处理的一切，从最小任务到最高风险决策，识别哪些可以系统化、哪些可以委派、哪些确实仍值得创始人的时间和注意力。

安全和合规不再可以推迟

挑战：在 MVP 阶段保持安全和合规措施简单是可以的。但现在，有真实用户、真实数据，并且可能有企业合同在桌面上，这会变成负债。

在 MVP 阶段，只有少量 beta 用户，没有敏感数据进入生产，安全漏洞还是理论风险。然而，当你的产品进入生产、真实用户依赖它时，假设风险会变成非常真实的暴露风险。此外，原型阶段不适用的合规要求，在你处理客户数据、处理付款或卖给受监管行业时，一定会适用。

补救方法是在生产规模到来之前，而不是之后，进行系统性安全和合规审查，并把所有浮现的问题都视为下一波用户到来前必须修复的事项，而不是建议。

在尚未准备好时扩张

挑战：新市场和融资机会看起来像增长机会。它们也可能是产品-市场匹配消亡的地方。

你已经建立的初始 traction 是真实的，但它也特定于早期受众。过早扩张到一个与原始市场有实质差异的市场，会引入新的用户行为、合规要求、支付基础设施和基线预期，而你的产品并非围绕这些设计。突然之间，变量太多，你会失去清晰解释自己数据的能力。你也可能为了追逐新的、尚未验证的受众，而忽视原有用户群。

Claude 如何帮助发布阶段创始人

在发布阶段，三种 Claude 形态都会充分发挥作用，并相互支持：每个工具产出的结果，都会成为另外两个工具的输入。这些结果会自然复利；同时使用三者的创始人，得到的不只是各部分之和。

这正是超精简创业模型在结构上成为可能的原因。当 Claude Code 构建产品、Claude Cowork 构建围绕产品的公司、Claude 帮助把产品和组织知识运营化时，一个小团队可以像一家规模是自己数倍的公司一样运转。

在技术债复利之前修复它

你的 MVP 代码库能运行，但它也需要一次系统性修复检查，寻找任何可能成为结构性负债的技术债。

首先，用 Claude Code 进行完整架构审计：识别代码库中脆弱的地方、哪些捷径会变得昂贵难维护、哪里测试覆盖薄弱到下一轮功能工作会重新引入同样问题。

把 Claude Code 的审计发现反馈给 Claude，让它分流并排序修复工作：下一次发布前必须修复什么，哪些可以等一个 sprint，哪些在当前阶段属于可接受的持续债务。

这也是记录 MVP 阶段架构决策的时刻。那些因为没时间写下来而一直存在你脑子里的决策，现在需要进入 CLAUDE.md。这样，每一次未来的 Claude Code 会话都会从对系统如何设计以及为什么这样设计的共享理解开始。

练习：指挥 Claude Code 审计你的 MVP 代码库，并产出一份按优先级排序的结构性弱点、测试覆盖缺口和重构候选清单。然后把这份清单交给 Claude，让它把修复工作安排到接下来几个 sprint 中：哪些重大问题需要优先解决，哪些可以与功能开发并行处理，哪些可以等待。

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

要构建释放你注意力的运营系统，前提是知道你的注意力到底去了哪里。使用 Claude Cowork 对当前运营负载进行结构化审计，记录每一项重复任务、每一个落到你桌面上的决策，以及每一个只有因为你亲自记得才会发生的工作流。然后让 Claude Cowork 把这份清单分类为：可以完全自动化的事项；需要人类但不一定需要你的事项；以及确实需要创始人判断的事项。

审计完成后，用 Claude Cowork 设计自动化候选项的工作流逻辑：每个工作流由什么触发、决策规则是什么、输出长什么样，以及完成后流向哪里。

让安全和合规成为产品工作流

使用 Claude Code 浮现目标市场要求的 SOC 2、GDPR 或 HIPAA 审计与标准中经常出现的代码级问题。这会暴露漏洞和合规缺口。把这些发现交给 Claude，帮助你确定修复优先级，并设计企业买家签约前会要求的控制、审计日志和访问管理。

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

接着，把合规工作流纳入开发周期，而不是把它当作一次性项目；合规文档需要持续维护和更新。对于正在接近企业合同或国际市场的创始人来说，这也是 Claude Code 安全扫描可以帮助准备独立安全评估的时刻。

练习：用 Claude Code 运行一次面向目标市场所需框架的代码级安全审查。把输出交给 Claude，让它产出两样东西：一个按优先级排序的安全修复顺序，以及为了满足潜在企业买家的合规审查，你需要准备的文档和控制清单。

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

发布阶段需要一组轻量、可重复的流程，它们可以在不需要创始人介入触发或运行的情况下运转。用 Claude 设计产品时间线和工作周期如何组织、在 Claude Code 触碰某个功能之前规格说明需要包含什么、bug 报告如何分流和路由，以及每周指标报告覆盖哪些内容、如何分发。

流程设计完成后，用 Claude Cowork 构建并运行运营层：安排 sprint 仪式、把进入的 bug 报告路由到正确位置、从连接的数据源中编译每周指标，并维护把用户信号持续输入产品决策的反馈循环。

练习：让 Claude 设计一个轻量产品管理操作系统：明确的 sprint 节奏、最低规格模板、bug 分流决策树，以及从实际数据源拉取内容的每周指标简报。然后设置 Claude Cowork 实施并运行系统中重复发生的运营元素，例如排期、路由和报告汇总，使其按计划自动发生。

第 6 章：规模化阶段

在规模化阶段，创始人的角色会从构建者重新居中为面向公众的高管。产品仍然是核心，但你的日常工作会越来越围绕公司本身展开。你的注意力必须扩展到规模化阶段的新活动，例如分析师简报和 IPO 路演，同时你还要努力保持以 AI 为中心的精简结构优势。

规模化阶段目标

技术基础设施的规模化工作会继续进行，同时加入组织本身的规模化工作，以及把它成熟为一家企业的工作。

在规模化阶段，你面对的是从数千用户走向数百万用户，从一个市场走向多个市场。在之前每个阶段，增长都可以通过贴近用户、基于紧密反馈循环的数据和健康的创始人直觉来摸索。现在，目标是构建由成熟组织运营支撑的系统性增长。

对于 AI 原生初创公司，你的目标应该是通过积累深度构建可防御护城河。这种深度来自：你嵌入产品中的专业知识、产品与用户依赖的其他工具和平台之间的深度集成，以及专有系统数据和工作流。那些一直朝同一个方向、基于一致基础设施构建的创始人，现在拥有了真正难以复制的东西。

在这个阶段，公开市场投资者、分析师、监管者、企业采购团队和收购方会施加更大压力，也带来更强怀疑，因为赌注更高了。你的产品和组织必须经得起外部审视：不仅是你所构建产品的能力，还包括围绕它的治理、合规姿态、财务控制和战略叙事。

规模化阶段退出标准

规模化阶段的退出条件不再是单一里程碑，而是一个阈值事件：即便创始人越来越不直接运行日常运营，公司仍然可持续。你已经证明了系统性增长；构建了能满足最苛刻外部审查者的组织治理与合规基础设施；并且能够扎实回答这个问题："如果一个资金充足的 incumbent 今天复制你的产品，你的用户还会留下吗？"

在实践中，这个阈值通常以三种形式之一出现：在不再需要外部资本的规模上实现可持续盈利；具备 IPO 就绪性；或者被收购。三者都要求你的增长是系统性且可审计的，你的产品护城河经得起审查，你的组织运营成熟且可持续。

当这些都成立时，值得祝贺：你的初创公司已经从一个赌注变成了一门生意。

规模化阶段挑战

委派运营层

挑战：规模化阶段的运营系统必须可靠、可持续地运行，而不需要被盯着。对于从第一天起就亲力亲为的创始人来说，这种转变既是结构性挑战，也是心理挑战。

发布阶段的工作是创建系统；规模化阶段则变成两件事：第一，把这些系统成熟到完全可信；第二，真正信任它们。

这比听起来更难。即便你是一个善于委派的创始人，也并不总是明显知道该交出什么、保留什么。太快交出太多，尤其是交给 AI 自动化系统，可能让关键决策缺失只有创始人才能提供的重要上下文。握得太久，你又会成为瓶颈。

这里的根本挑战，是识别那些只存在于创始人脑中或未文档化工作流中的机构知识，并把它们编码进有文档、可审计、可转移的系统。

扩展技术运营

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

创业前三个阶段的技术挑战围绕代码库展开：构建正确解决方案而不累积技术债，然后为真实用户加固安全和合规。进入规模化阶段后，挑战变成围绕代码库构建的一切：创建支持基础设施、文档和可靠性保证，以传递成熟度信号。

更大规模的客户和签署多年合同的机构买家，会在签约前要求这些东西；签约后，他们也会按这些标准要求你。

不过，把你带到这里的同一套 AI 基础设施，也可以帮助你构建具备明确响应时间和文档的专门支持职能，使新客户的工程团队真正能够使用。

扩展组织职能

挑战：规模化阶段公司通常需要招聘、工资、会计和法律运营等组织基础设施，不论实际运行它的人有多少。

在发布阶段，系统化运营意味着自动化那些消耗创始人注意力的工作流。规模化阶段的初创公司现在需要发展更广泛、在某些方面更具后果性的运营职能，例如财务报告、合规监控、合同管理和客户支持等。

构建 GTM 职能

挑战：自然增长有天花板，大多数规模化阶段创始人在真正构建 go-to-market 职能之前就撞上了它。

创意、MVP 和发布阶段的增长，往往来自创始人主导的销售：一次时机恰当的 Product Hunt 发布、个人关系带来的早期客户等。这样的自然增长只能运作到某个点，而大多数初创公司会在规模化阶段触及这个边界。迹象包括用户曲线变平、获客成本上升，以及只有创始人亲自参与时才推进的 pipeline。

规模化阶段增长需要构建一个专门增长引擎，触达新的、更广泛的产品受众。不过，大多数初创公司创始人可能从未真正运行过营销、销售和分析师关系项目。一个正经的 GTM 动作不仅需要建立新系统和流程，也需要创造品牌声音和产品叙事。因为在创业生命周期的这个阶段，你需要这个叙事去触达的不只是个体新用户，还有投资人和企业买家这样的完整目标受众。

幸运的是，GTM 职能不必庞大才有效；构建产品的同一套 AI 基础设施，也可以引导你把产品带向市场。

Claude 如何帮助规模化阶段创始人

早期创业阶段把 Claude 用作产品本身的基础设施：用于验证想法的研究伙伴，用于设计和构建原型的工程团队，以及让单创始人初创公司成为可能的 AI 运营层。到达规模化阶段的 AI 原生创始人，现在可以继续用 Claude、Claude Code 和 Claude Cowork，以他们构建公司的同样方式继续扩展公司。

把日常任务交给 Claude Cowork

规模化阶段开始时，要清醒地看见现在最需要投入自己时间和注意力的地方。对于从未构建过企业的一次创业者来说，这可能是挑战。Claude 可以通过列出这个阶段只有你应该做的事情来帮助你，包括产品叙事决策、董事会关系、企业交易，以及创始人之间的对话。任何不在这个清单上的事项，都是委派或 Claude Cowork 自动化候选项。

练习：用 Claude 生成当前运营层的瓶颈地图：所有目前通过你路由的工作流、决策和批准。然后让 Claude 推演：当你一周不可用时，每一项会发生什么。会停滞的工作流，就是你仍然亲自参与到足以拖慢进展的地方。

这些如何映射到你与 Claude 做出的创始人优先事项和职责清单？

接下来，是时候压力测试你已经构建的系统是否真的准备好随着业务增长而扩展。

练习：用 Claude 映射当前工作流，然后问它：当你一周不可用时，每个工作流会发生什么。会停滞的工作流，就是交接标准、升级路径或异常处理仍需收紧的地方。Claude 可以帮助分析失败点，并建议适当修复，这样你就可以按需更新或替换 Claude Cowork 自动化。

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

随着规模扩大，买家需要确认你的产品和组织可以作为长期基础设施被信任。技术工作仍然会像以往一样在代码库内部继续，但现在也有代码库周围的技术工作要处理。

第一步是把机构知识转成可扩展系统。用 Claude 起草并维护企业采购希望看到的书面基础设施，包括产品文档、支持 playbooks 和 SLA。

与此同时，指挥 Claude Code 针对企业合同要求的具体可靠性和安全标准审计并加固代码库，并构建 Discord 社区支持从未需要过的技术支持基础设施：日志、监控、事故响应工具，以及让 SLA 真正可执行的可观测层。

Claude Cowork 随后运行企业支持本身的运营层：工单路由、升级工作流、由产品变化触发的文档更新、续约跟踪，以及企业客户成功所依赖的报告节奏。三者一起，让一个小团队拥有大得多的组织才通常具备的支持姿态。这正是签署多年期企业合同之前你必须证明的东西。

练习：挑选三个要求最严苛的潜在客户，或识别三个你非常想签下的理想客户。让 Claude 产出差距分析：这些账户中的企业采购团队在签署多年合同前，会期望看到哪些文档、SLA 和支持基础设施？你当前在哪里不足？使用输出结果，在 Claude Code 和 Claude Cowork 之间安排技术与文档工作顺序。

构建真正的 GTM 职能

创始人的 hustle 把你带到了这里，但扩展初创公司需要创建并执行真正的 go-to-market 策略。AI 可以帮助你构建并运行完整 GTM 引擎。

Claude 可以帮助从零构建基础 GTM 资源：市场细分、消息架构、分析师关系策略、销售 playbooks，以及当你开始与公开市场投资者、企业买家和华尔街分析师对话时重要的面向投资人的指标叙事。每类受众都有自己的词汇体系，也会按照自己的标准评估你；Claude 的工作是把产品价值主张翻译成适合每个受众细分的产品营销方式。

现在，Claude Cowork 可以成为你的战术执行层：内容 pipeline、外联序列、分析师简报物流、新闻室和公关节奏、CRM 卫生、pipeline 报告，以及把 GTM 策略转成实际商业动作的许多重复周期。

当 GTM 动作需要产品营销基础设施，例如交互式 demo 环境、集成文档、沙箱租户、API 参考和技术 one-pager 时，Claude Code 可以为你构建。买家期望从技术上评估你的产品；到了规模化阶段，一个 Loom 视频和销售 deck 已经不够。这同样是让 GTM 动作异步运行的基础设施：一个构建良好的 demo 环境，会在你参加董事会会议时继续成交。

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

许多超精简初创公司创始人，正在为他们在某个特定领域中亲身经历或观察到的真实问题，构建高度具体的应用或工具。Agentic AI 现在让从未写过一行代码的创始人，也可以用自己的领域专业知识构建解决复杂问题的产品。Claude、Claude Code 和 Claude Cowork 在把创始人知识转化为持续复利的产品特异性方面各自发挥作用。

用 Claude 捕捉、组织和打磨创始人知识，可以把领域专业知识放到产品能够触达的位置。通过长期对话、projects 和 memory，创始人可以分享自己知道的一切：行业术语、监管陷阱、边界案例、挫折，以及为什么这个问题的显而易见答案行不通。Skills 随后可以把重复工作流（例如"我如何审计商业租赁""我如何分流患者 intake 表"）编码成 Claude 每次都以同样方式运行的可复用例程。几个月后，这会成为一个通用 AI 无法匹敌的专有知识基底。

用 Claude 外化领域知识，对于把行业特定边界案例编码进产品非常有价值。例如，一个通用 AI 医疗账单工具可能会在 340B 药品项目索赔上出错，但你的产品可以有针对它们的特定逻辑。Claude Code 帮助你把同领域其他专业人士经常遇到的挫折，转译成验证逻辑、提示词优化，或与你的竞争者从未听说过的利基行业系统的 MCP 集成。结果是，你的应用或工具的深度和广度会持续复利，而竞争者无法简单复制。

练习：识别一个通用竞争者在你的垂直领域一定会做错的边界案例。和 Claude Code 一起为它构建一个专门测试案例（不是单元测试），基于你真实见过的场景。每次出现类似边界案例，都把它加入。你的测试套件会变成护城河地图。

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

当用户与你的产品互动时，他们会生成行为信号，例如哪些输出被接受，哪些被拒绝。这些信号会影响产品路线图。随着时间推移，你会学到特定用户群的具体模式、偏好和边界案例。这就是复利价值：每一次改进让产品更有用，带来更多使用，产生更多反馈，再推动更多改进。

这些数据具有时间锁定性、上下文特异性，并且无法由复制者重建。你不可能买到成千上万用户在你的产品内部打磨工作流所形成的行为指纹。

Claude 可以帮助审计你收集的用户交互数据，识别其中最高信号的行为模式，并设计把持续使用转化为系统性模型改进的反馈循环。

练习：把产品交互数据摘要喂给 Claude：你收集了什么、收集了多久、你知道用户如何随时间与产品互动。让它识别数据中三个最高信号行为模式，并为每一个设计一个将其转化为系统性模型改进的反馈循环。然后让它帮助你起草一页护城河叙事，用于产品营销：你的数据飞轮如何运作、已经转了多久，以及为什么一个资金充足的竞争者今天开始也无法在两年内复制。

创造工作流锁定

复利的数据网络效应让你的产品更难复制，而用户工作流锁定让你的产品更难离开。用户在日常运营中运行你的产品越久，它就越深地嵌入他们真实的工作方式。他们在它之上构建了自动化，训练员工使用它，并把它连接到数据源和其他工具。他们开发的提示词、打磨的工作流、标准化的输出，都围绕你的产品做什么以及如何做而形成。在这个点上，切换从产品决策变成全面运营项目。

创造工作流锁定的第一步，是让 Claude 按集成深度映射当前客户群。对每个客户细分，识别他们在你的产品之上构建了哪些工作流，依赖哪些集成。这会显示你的产品在哪里有粘性，以及在哪里需要深入。

你提供的集成越多，客户构建依赖你产品的工作流的表面积越大。Claude Code 可以帮助你快速搭建与你目标用户依赖的数据 pipeline、项目管理工具和其他系统的原生集成。Claude Code 还可以构建 API、webhooks 和 SDK，让客户不只是使用你的产品，而是在它之上构建。这是最深层的锁定。

练习：让 Claude 帮你为前十名客户构建一次工作流集成审计。对每个客户记录他们构建的自动化、依赖的集成、通过你的产品运行的团队工作流，以及你估算的切换成本。然后让 Claude 识别这个群体中的模式：对你的具体产品而言，哪些集成类型会创造最深锁定？你可以构建或启用什么，来加深目前只停留在表层的客户集成？

第 7 章：同一份工作，新的规则

在 AI 时代，创始人的工作没有改变：找到一个真实问题，构建能解决它的东西，并把它扩展成一家重要的公司。改变的是到达那里的路径。

在创意、MVP、发布和规模化这四个阶段中，AI 把几个季度压缩成几周。

过去需要几个月的验证周期，现在可能只需要几个下午。一个可运行原型不再要求你有一个掌握正确技术栈的联合创始人；它要求你有一个清晰问题，以及和一个 coding agent 进行几次聚焦会话。发布就绪从一次发布前冲刺，压缩成一个持续工作流。到了规模化阶段，过去迫使早期招聘进入救火角色的运营重量，也越来越可以交给 AI，让你的团队把注意力用在会变成护城河的判断上。

瓶颈不再是你能构建什么，而是你选择构建什么。

资源

使用 Claude 构建

Building AI Agents for Startups：分享初创公司如何使用 agents，在规模化过程中减少对创始人的依赖。
Claude Code docs：带构建者从初始安装走向高级 agentic 工作流。提示：可以从 "How Claude Code works" 概览开始。
Claude Code best practices：覆盖 Anthropic 内部和工程团队中有效的模式，包括上下文管理、权限、规划和验证工作流。
Using CLAUDE.md files：讲解如何为你的具体代码库配置 Claude Code。对于正在设置开发环境的 MVP 阶段创始人，这是必读材料。
Claude Code power user tips：展示 Claude Code 团队自身的工作流模式，包括并行会话和验证循环。
Get started with Claude Cowork：分享团队如何设置 Claude Cowork，并开始实施 Skills、plugins 和其他能在初创公司中扩大影响的功能。
Tutorials ：claude.com/resources/tutorials 提供可搜索的动手教程列表，覆盖具体任务。

创始人故事

How three YC startups built their companies with Claude Code：研究 HumanLayer（F24）、Ambral（W25）和 Vulcan Technologies（S25）如何使用 Claude 快速把原型推向市场，并用 agentic coding 工作流扩展 AI 驱动平台。
GC AI：创始人使用领域专业知识，构建了一个由 Claude 驱动、响应式的法律平台，更贴近内部法务团队真实工作方式：公司特定 playbooks、跨职能利益相关者，以及可变的风险容忍阈值。
Carta Healthcare：使用 Claude 驱动临床抽象平台，每年处理 22,000 个手术病例，并将数据抽象时间减少 66%。
Anything：由 Claude 和 Agent SDK 驱动，帮助 150 万用户在不写代码的情况下把想法变成可运行软件产品，包括一位非技术创始人构建并已经开始销售完整招聘平台。Anything 的 AI agent 负责完整构建，让独立创业者可以加倍投入自己的领域专业知识。
Cogent：一家应用 AI 实验室，构建 agents 来自动化关键企业安全任务。该初创公司使用 Claude 作为 agents 的推理层，覆盖整个漏洞生命周期中的调查、优先级排序和修复。
Airtree：使用 Claude Cowork 作为运营基础设施中心，把过去散落在十几个工具和团队中的数据统一起来。现在，当一个人用 Skills 构建工作流自动化后，组织中每个人都可以用它完成待办清单上那些一直没做完的事。
Duvo：构建运行采购、供应链和品类管理流程的 AI agents，跨 ERP、供应商门户、电子表格、邮件甚至电话工作。Duvo 完全基于 Claude 构建，使用 Agent SDK 在工作流之间进行编排。
Zingage：面向居家护理机构的 AI agent 平台，支持 24/7 自动化运营。该初创公司使用 Claude 的结构化工具调用，在 EMR 和多个沟通渠道之间编排；使用 Claude 的上下文推理，构建能够给出细腻、面向患者定制结果的 agents，而不是匹配最常见回复。
Kindora：一个 AI 驱动平台，由一位非营利组织高管使用 Claude Sonnet 构建，用来智能匹配慈善组织和资助方。在把数千个匹配过滤到少数值得追求的机会后，Kindora 的 MCP connector 让非营利组织可以直接在 Claude 中访问其潜在资助方工具。
Wordsmith：由一位律师转型 CTO 创立，为内部法务团队提供可靠的 AI 驱动法律技术。Claude 是 Wordsmith 合同审阅、协议起草和文档审查能力的推理引擎，其工程团队也使用 Claude Code 构建和演进平台本身。

初创公司支持与机会

Anthropic Startups Program：面向与 Anthropic 风投伙伴合作的初创公司，提供免费 API credits、公开可用最高层级 rate limits，以及参加独家创始人活动和工作坊的邀请。
Claude community：面向构建者的论坛和社区空间。
Live learning resources：会议、网络研讨会、直播和录像资源。