680 lines
66 KiB
Markdown
680 lines
66 KiB
Markdown
---
|
||
title: "创始人行动手册：打造一家 AI-Native 创业公司"
|
||
source: "https://x.com/AlchainHust/article/2056595872754848232"
|
||
author:
|
||
- "[[花叔 (@AlchainHust)]]"
|
||
published: 2026-05-19
|
||
created: 2026-05-20
|
||
description: "译自 Anthropic 官方手册《The Founder's Playbook: Building an AI-Native Startup》 2026 年 5 月发布花叔注：这是 Anthropic 五月发布的一份创始人手册。三十六页，把 AI 时代的创业生命周期重新画了一遍..."
|
||
tags:
|
||
- "clippings"
|
||
---
|
||
|
||
|
||
译自 Anthropic 官方手册《The Founder's Playbook: Building an AI-Native Startup》 2026 年 5 月发布
|
||
|
||
花叔注：
|
||
|
||
这是 Anthropic 五月发布的一份创始人手册。三十六页，把 AI 时代的创业生命周期重新画了一遍。
|
||
|
||
这本手册主要讲的是，当一个人就能完成过去一整支团队的工作时，创业流程会变成什么样。它把这件事拆成四个阶段：想法、MVP、发布、规模化。每个阶段先讲目标和退出条件，再讲容易踩的坑，最后才是 Claude 怎么用。
|
||
|
||
我觉得最值得读的部分，其实是「容易踩的坑」那几节。比如「把『造』误当作『验证』」「AI 把确认偏误装上了一台研究引擎」「零摩擦的范围蔓延」——这些都是在 AI 让一切变得太容易之后，反而会暴露出来的新风险。
|
||
|
||
我尽量做了贴近原意的翻译，保留了一些英文专有名词（PMF、TAM、GTM、[CLAUDE.md](http://claude.md/) 等），因为强行中译会失真。
|
||
|
||
全文约两万五千字，是一篇能完整读完的长文。也可以收藏起来，按阶段对照你当前的处境来翻。
|
||
|
||
———
|
||
|
||
## 第一章 创业生命周期，为 2026 重新启动
|
||
|
||
AI 正在重塑创业公司的建造方式。今天，从未写过一行代码的创始人正在交付生产级应用，而「10 人独角兽」也从草根传奇变成了一套可以被认真规划的行动方案。
|
||
|
||
到 2026 年，AI 可以写生产环境代码、做市场调研、梳理竞争格局、起草投资人材料，并自动化运营流程。它抹平了过去很陡的学习曲线：即使经验丰富的技术创始人，以前也要花大量时间整合工具、平台和系统，才能把想法落地。**AI 最重要的贡献，是把「谁能启动一家公司、谁能做出一个产品」这件事的门槛拉平了。**
|
||
|
||
2026 年，一个好想法能把创始人带到比以往任何时候都更远的地方。Agentic 编程把过去需要一整支工程团队完成的工作，压缩成了创始人自己就能交付的体量。
|
||
|
||
传统创业增长曲线默认路径是：验证 → 融资 → 招人 → 建造 → 再融资 → 增长 → 继续招人 → 重复。现在，AI 已经抹掉了一个默认预期：创业生命周期的每个新阶段，都必须配更大的团队、不同的技能组和新一轮融资。
|
||
|
||
这本手册会按照这些新现实，重新绘制创业旅程的四个核心阶段：想法、MVP、发布、规模化。我们会逐阶段看：当 AI 成为技术和组织发展的核心基础设施时，每个阶段长什么样；每个阶段该用哪些工具；以及走在前面的创始人如何用这些工具压缩时间线。
|
||
|
||
———
|
||
|
||
## 第二章 「创始人」这件事正在改变
|
||
|
||
过去，创始人是被「能做什么」定义的：技术型创始人写代码，非技术型创始人跑业务、谈合同。但 2026 年创始人可用的模型、系统和 AI agent，已经溶解了「能造东西的人」和「有想法值得造的人」之间那堵墙。
|
||
|
||
AI-Native 创业公司正在从根本上改变「成为创始人」的含义。**现在，一个完全没有工程背景的人，可以做出真正能跑的生产级软件来实现自己的想法**；而一个技术很强但商业知识有限的创始人，也能轻松产出 GTM 策略、财务模型和高度打磨的 pitch deck。
|
||
|
||
从历史上看，创始人大部分时间都在执行模式里：写代码、管人、处理日常运营。**在 AI-Native 创业公司里，创始人的角色不再只是个人贡献者，而更像是一群 agent 的编排者。** 这些 agent 是专门化的 AI 助手，能读文件、跑命令、执行代码，甚至浏览网页。创始人的注意力开始上移，转向更高阶的工作：产生想法，并指挥 AI agent、工具和小团队把想法落实。
|
||
|
||
AI 作为核心基础设施最革命性的结果，是它解锁了有领域专长的非技术背景创始人。当创始人池不再只来自工程背景，你会看到由完全不同人生经验的人创建的公司，去解决传统技术创始人输送管道从未优先关注，甚至从未注意到的真实问题。
|
||
|
||
AI 为精益创业带来的能力
|
||
|
||
传统创业模型假定你必须招工程师来造、招销售来卖、招运营来跑公司。「人头数」被看作组织势能和产品成熟度的标志。
|
||
|
||
2026 年的早期创业公司则完全不同。它们在设计上极度精益，往往只有创始人一人，或加上少数伙伴。把技术与组织发展都建立在 AI 这一基础设施之上，它们可以在扩张团队之前就达成产品验证、产生早期收入，甚至盈利。AI 在三个地方能让一家创业公司像大得多的组织一样运转：研究、Agentic 编程、以及关键业务运营的工作流自动化。
|
||
|
||
对话式智能与研究
|
||
|
||
类比：任何领域随叫随到的专家。
|
||
|
||
想想看，一个创始人在第一年里几乎肯定不知道但又必须知道的事情：怎么搭工资发放系统？怎么规划产品开发冲刺？怎么写一份紧凑的投资人备忘录？
|
||
|
||
早期创业的这类问题过去几乎都是同一个答案：找一个懂的人。对一个自筹资金或种子前的创始人来说，这意味着把本该用来建造的时间花在打听上，或者把早期资金烧一部分给顾问。现在，他们手里就有一个跨几乎所有领域、随时在岗的专家：AI。
|
||
|
||
- 深度研究：竞品分析、市场规模测算、财务建模
|
||
- 文档起草：pitch deck、案例研究、投资人备忘录、PRD
|
||
- 战略思考伙伴：反方代言人分析、事前剖析、情境推演、路线图优化
|
||
|
||
Agentic 编程
|
||
|
||
类比：那位永远在线、永不被卡住的工程师。
|
||
|
||
过去，要做出软件，要么得有一个技术合伙人，要么外包给开发公司，要么有足够长的跑道，先招够一支工程团队，然后才能写下第一行生产代码。
|
||
|
||
Agentic 编程工具如今让每一个有想法的创始人，都可以用平实语言描述自己想做什么，然后指挥 AI 生成、测试、调试、重构一份生产级代码库，速度和体量都堪比一支完整工程团队。
|
||
|
||
从「我有一个想法」到「我有一个产品」的时间线被压缩了。**创始人的角色现在聚焦在「该做什么、为什么做」，而 AI 负责真正的基础设施搭建**，那些直接面对真实用户的部分。
|
||
|
||
工作流自动化
|
||
|
||
类比：一支随时听用的自动化运营团队。
|
||
|
||
即使创始人能像顾问一样研究、像工程团队一样写代码，战略规划和产品开发之外仍有整整一类工作必须完成：排期、更新 CRM、拉周报、维护文档、发布内容、追踪合规要求、管理公司赖以运转的工具和系统之间的连接。这些也都要发生。在精益创业公司里，这些负担主要落在创始人身上，并且会大量侵占本该用于高阶判断的时间和注意力。
|
||
|
||
AI 工具的工作流自动化能卸掉这笔税。重复性运营任务可以被配置为自动发生：交易状态变化时 CRM 自动更新，周报自己汇总，产品文档跟随产品变化同步更新。关键在于，Claude Cowork 能集成创业公司使用的互联系统，例如项目管理工具、沟通栈、数据源，而不需要有人专门构建并维护这些集成。在第零天创业公司里，那个人几乎总是创始人本人。
|
||
|
||
时机和编排，是一切
|
||
|
||
能有效驾驭 AI 的研究能力、自动化能力和 agentic 编程能力的创始人，能用远超团队规模所暗示的杠杆来运营一家公司。他们也能把大部分时间和带宽，放在那些真正重要的工作上。
|
||
|
||
但这套东西不会自动巡航。负责编排这些 AI 工具的创始人，必须知道如何用、什么时候用。本手册剩下的部分，就是探索 AI-Native 创业路径上每一阶段的目标、挑战，以及如何在旅程的每个阶段有效应用 AI 工具。
|
||
|
||
———
|
||
|
||
## 第三章 想法阶段
|
||
|
||
每个创业的创始人都从同一个地方出发：一个让你停不下来去想的问题。这就是创业里想法撞上现实的阶段。**2026 年的创业成功，要求你具备一种纪律：在证据足够之前，不动手造。**
|
||
|
||
这一阶段的工作是研究、客户发现、竞品分析、以及对反证的诚实评估。所有这些，都要发生在你打开 Claude Code 让它写下第一行生产代码之前。
|
||
|
||
想法阶段·目标
|
||
|
||
在想法阶段，创始人的核心目标是以研究为导向的验证：在投入资源开始造东西之前，攒起扎实证据来证明一个真实问题确实存在，并且你提议的方案确实有效解决它。
|
||
|
||
具体来说，想法阶段是一系列大致按以下顺序回答的问题：
|
||
|
||
- 这个问题是真实的、具体的、足够高频的，值得围绕它做一家公司吗？
|
||
- 到底谁有这个问题？这些人能构成一个市场吗？
|
||
- 是否已经有人在解决它？如果是，他们怎么做，做得多好？
|
||
- 一个真正解决这个问题的方案需要做到什么？我的想法做到了吗？
|
||
|
||
这些问询加起来，回答一个终极问题：这值不值得做？
|
||
|
||
也就是说，先具体，再行动。「报销报告让人头痛」是观察。「中型市场公司的财务经理每周要花 4 小时以上核对报销提交，因为现有工具不和会计软件打通」才是一个可以测试的假设。
|
||
|
||
想法阶段·退出标准
|
||
|
||
想法阶段的退出条件，是找到 problem-solution fit（问题-方案匹配）。你要在开始造解决方案之前，建立起质性证据，主要来自真实的人类对话，证明你正在为真实的人解决真实问题。
|
||
|
||
当你能对以下三个问题都答「是」时，就准备好离开想法阶段了：
|
||
|
||
- 这个问题真实且具体吗？你必须能说出谁经历这个问题、多频繁、影响多严重、目前他们怎么处理它。
|
||
- 你的方案是否对应了真实问题？不是你最初设想的问题，而是验证过程里浮现出来的那个。有时两者相同，但并不总是。
|
||
- 你有足够信号去开干吗？你在这个阶段永远不会有 100% 确定，等到完全确定本身就是失败模式。但你需要足够质性证据，让投入做 MVP 看起来是有理有据的决定，而不是一场信仰行动。
|
||
|
||
想法阶段·挑战
|
||
|
||
想法阶段是创业旅程里最重要的工作发生的地方，因为最具后果性的错误就在这里酿成。现在搞错一点，能很快把刚起步的事业带偏。多数想法阶段的挑战，归根到底都是前进速度超过了理解所能支撑的范围。所以，带着思考和审慎前行的创始人，才能稳步推进。
|
||
|
||
**把「造」误当作「验证」**
|
||
|
||
挑战：当技术障碍被移除，一个被激情冲昏头的创始人，可能会跳过创业旅程里最重要的工作：验证自己的想法是不是人们真正需要、也真正会用的方案。
|
||
|
||
即使在 agentic 编程时代之前，也有 42% 的创业公司失败，是因为它们做了没人想要的东西。现在，像 Claude Code 这样的 agentic 编程方案，已经大幅压缩「我有一个想法」到「我有一个产品」之间的距离，这个失败率只会继续上升。
|
||
|
||
现在确实是怀揣绝妙点子的创业者最好的时代，但**一个看起来像产品的原型竟然可以如此快速、轻松地搭出来，反直觉地，这恰恰给 AI-Native 创业公司带来真正危险的存在性风险。**
|
||
|
||
直到不久前，造东西仍需要真金白银的开发时间和预算，连搭个最基本的原型通常都要数月。如今技术开发门槛基本消失，AI 让创始人太容易直接跳进建造，完全跳过验证它在真实世界里是否有用。
|
||
|
||
要达到问题-方案匹配，必须先验证假设、再开始造。但许多首次创业者，甚至有经验的创业者，都错误地以为 AI 能让这一要求短路，把流程改成：有想法 → 立刻造原型 → 把「原型存在」当作验证。
|
||
|
||
一个能跑的原型很容易被误当作「我在解决真实问题」的具体证据，但它不是。原型只是你和潜在用户对话时一个有用的压力测试道具。这些对话本身，才是真正证据。
|
||
|
||
**过早规模化**
|
||
|
||
挑战：当造东西既不费力又即时，你的执行速度可以远远超过业务真正需要的水平。
|
||
|
||
过早规模化意味着：在还没有真正验证这条产品路径值得投入之前，你就已经把自己锁进去了。
|
||
|
||
这一直是创业杀手，但 AI 让创始人更容易在毫无察觉时掉进这个陷阱。Agentic 编程助手太强大了，以至于执行很容易跑在问题-方案匹配验证之前，而你甚至没有意识到自己已经偏航。
|
||
|
||
它会围绕一个根本错误的前提，带着同样的热情生成、测试、调试、重构代码库。系统里的智能是你的。这个阶段的最高指令是：让你的判断力始终走在建造之前，尤其是在建造如此快速、感觉如此轻松的时候。
|
||
|
||
**客观性丧失**
|
||
|
||
挑战：让 AI 工具去找支持你既有看法的证据，它一定能找到。**确认偏误如今配备了一台研究引擎。**
|
||
|
||
确认偏误一直是创业里的职业病：创始人天然对自己的想法充满热情。现在，AI 工具给确认偏误加了很强的外挂。让 AI 验证你的创业想法，它能找出佐证；让它估算潜在市场，它能找到让 TAM 看起来值得融资的数字。
|
||
|
||
AI 会沿着你的方向走。这意味着，一个不问难题的创始人，如今能比以往任何时候都更快地构建出一套精致、看似研究充分的坏点子论据，同时还觉得自己正在做尽调。解药还是同一个工具，只是把方向反过来：AI 同样能像验证想法那样彻底地压力测试它。当研究和结构化对抗性思考浮现证据、提示想法需要修正时，这就是 pivot 的信号。
|
||
|
||
Claude 如何帮助想法阶段的创始人
|
||
|
||
把你的 AI-Native 创业概念推进到走出想法阶段，可能感觉漫长无比。你是创始人，你只想动手造。但这个至关重要的启动阶段，本质上是一次研究和验证练习，意味着你应该先用那些帮助你想得更严谨的工具，而不是急着写代码。
|
||
|
||
**Chat、Claude Cowork，还是 Claude Code：怎么选合适的 Claude 产品面**
|
||
|
||
AI 让创业者能更快交付、自动化繁琐工作流，并在规模上运作起来。但你用哪一面，取决于手头任务。
|
||
|
||
- Chat 适合无需离开当前 app 就能完成的快速交流：从密集投资人备忘录里提炼一句话总结、在董事会前快速核查一个论断、读懂团队里一条很长的 Slack 串。
|
||
- Claude Cowork 适合真正需要时间的知识工作：从多个来源拉资料、整理并产出完成品，比如文档、deck 或电子表格。
|
||
- Claude Code 是团队工程师的 agentic 编程环境：代码库访问、Plan Mode、git 集成、本地、IDE 或沙盒云环境。它是精益团队跨成长中的代码库交付功能、迁移 MVP 遗留代码、把原型推到生产的地方。
|
||
|
||
三者底层是同一个 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 也能指出你的草稿问题哪里在诱导受访者、哪里太宽泛、哪里会产生噪音而不是信号。它还可以帮你设计追问，用来处理回避回答，或深入挖掘那些重要但含糊的答案。
|
||
|
||
如果你的假设涉及多个 persona，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 登场的时刻。即使你之前一直在小修小补，现在才是生成正式轻量原型的节点：只做最小的产品表面，让你能把想法放到真实的人面前，获得真实反应。
|
||
|
||
**你还不是在造一个真实世界产品，而是在构建一份功能样本，用于客户和投资人对话。** 真实用户触碰一个能实际操作的东西，会告诉你十几次问题-方案访谈都无法告诉你的事。此前你是在证明要解决的问题真实存在；现在，你是在邀请潜在用户参与拟议的解决方案。
|
||
|
||
练习：定义你的方案所依赖的单一核心交互。指挥 Claude Code 只做这一件事。做好后，把它放到五个来自已验证目标画像的人面前，请他们试用。你在这五次对话里学到的东西，将决定你是继续建造，还是回到画板。
|
||
|
||
走到想法阶段的尽头，是 AI 创业赛跑里的一大跃迁。因为你不再是在赌一个直觉，你是在对着证据执行。
|
||
|
||
接下来进入 MVP 阶段。创始人的指导问题从「这值不值得做？」转向「到底先造什么？」而 AI 的主要角色，也从研究伙伴切换为施工队。
|
||
|
||
———
|
||
|
||
## 第四章 MVP 阶段
|
||
|
||
很多创始人把 MVP 阶段当作一个施工阶段，但 **MVP 阶段本质上仍是一次证据收集练习**。区别在于，这次你收集的是关于解决方案空间的证据，而不再是问题空间：一个真实、可识别的人群是否觉得这个产品有价值到愿意使用、回来再用、付费，或者推荐给别人。
|
||
|
||
MVP 阶段·目标
|
||
|
||
作为一家 AI-Native 创业公司的创始人，你的目标是把验证过的问题，翻译成一个真实用户会用的可工作产品。它不是带齐每个路线图功能的完整版本，而是你的想法最小、最聚焦的一次迭代：把真实方案摆到真实用户面前，并产生 PMF 的真实证据。
|
||
|
||
与此同时，你现在怎么造，决定了之后能造什么。这意味着 MVP 阶段还有第二个同样重要的目标：快速前进，但不积累那种会复利、会在真实用户达到一定规模时回来缠住你的技术债。
|
||
|
||
最后，从第一天起就投资持久上下文，是让 AI 成为放大器而不是熵源头的关键。在 AI-Native 创业公司里，你的代码库是你和 AI 一次次会话共同协作的对象，这让可读性成为根基。**跳过 spec、架构决策和** [CLAUDE.md](http://claude.md/) **这类上下文文件的创始人，会撞上一堵可预见的墙：每次新会话都要重新解释代码库，AI 生成的改动也会从最初愿景里漂移。**
|
||
|
||
MVP 阶段·退出标准
|
||
|
||
MVP 阶段的退出条件，是出现 PMF 的真实证据：一个具体、可识别的用户群体，发现产品有价值到愿意回头用（留存）、付费（收入），或告诉别人（推荐）。
|
||
|
||
MVP 阶段·挑战
|
||
|
||
在 MVP 阶段，创始人的首要指令是速度与判断力。这里的挑战核心是：你能不能用正确方式造正确东西、快到足够有意义，同时不抄那些以后会让你付代价的近路。
|
||
|
||
**Agentic 技术债**
|
||
|
||
挑战：因为 AI 基本移除了过去那些控制什么能进生产的天然瓶颈，速度是被保证的。但当速度成为创始人在 MVP 阶段唯一考虑的变量时，他们会积累自己很难还清的技术债。
|
||
|
||
一些技术债在 MVP 阶段是合理的，前提是你明白在规模化之前必须管理它。这种债逐步累积，可以在时间里或专门冲刺中清掉。但 **AI 技术债会复利。**
|
||
|
||
如果没有把规格和架构约束写在某个 AI 能读到的地方，每次会话都会从零开始重新推导基础决策，于是这些决策会漂移。你最后会得到一个没有一致心智模型的代码库，不是因为任何一块写得糟，而是因为这些零件从未被设计成能拼到一起。这是真问题，而且往往很晚才显形。
|
||
|
||
**误把虚假 PMF 当作真 PMF**
|
||
|
||
挑战：AI 工具可以生成亮眼的早期数字，但这些数字并不保证市场需要你的产品。
|
||
|
||
早期势头是创始人能经历的最强心理体验之一。经历数周或数月验证和克制建造之后，把产品发出去，会让人觉得自己从一开始就是对的。
|
||
|
||
Agentic 编程工具可以让你比以往更快抵达这个时刻，但**早期牵引不等于 PMF**。发布热度可能来自短暂因素：创始人的朋友、投资人其他被投公司的潜在买家，或 Hacker News 一个标题带来的流量尖峰。可惜，这些都不能可靠预测第六周或第十二周，在最初助推消退后会发生什么。
|
||
|
||
**零摩擦的范围蔓延**
|
||
|
||
挑战：当建造感觉不费力、几乎免费，总会有一个很酷的功能可以加，或一个边缘情况可以处理。这种范围蔓延弊大于利。
|
||
|
||
范围蔓延一直是创业风险。现在的区别是，过去阻止它的强制函数，即工程时间的真实成本，已经不再以同样方式存在。加一个功能从一个冲刺变成一个下午。
|
||
|
||
难点在于，每一个单独新增都显得合理。产品当然应该处理那个边缘情况，用户当然会想要那个工作流。由于 agentic 编程让每一项都很省力，它们在当下并不像范围蔓延。但当产品越过原始边界开始摊大饼，你就会失去方向和动量。
|
||
|
||
解药是在建造前写下范围定义：产品做什么、明确不做什么、以及来自真实用户的哪种具体证据才足以证明应该加新东西。这样，决策点就从「要不要做这个？」变成「是否已有足够多用户告诉我们：没有它，他们无法从产品获得价值？」
|
||
|
||
**因经验不足而不安全**
|
||
|
||
挑战：创始人用 AI 工具匆忙把应用推向市场，却没有先理解基本安全原则，最终会让用户暴露在可避免的风险中。
|
||
|
||
硬道理是：**agentic 编程工具生成的是能运行的代码，而不是天然安全的代码。** 功能代码很容易判断，因为功能要么能跑，要么不能。安全漏洞在被利用之前是隐形的，这意味着没有天然反馈环来提醒首次创业者：哪里出了问题。但把一个 live MVP 交给真实用户，就意味着真实数据、真实暴露和真实后果。
|
||
|
||
轻视安全并不是 AI-Native 项目才有的新问题。每个时代的自筹资金创业公司都常常把安全考虑拖到很晚，有时甚至拖到生产发布前夕。任何用户触碰你的 app 或方案之前，做一次安全审查，是把最小可行产品发布到世界上所需的最低责任门槛。
|
||
|
||
Claude 如何帮助 MVP 阶段创始人
|
||
|
||
**造之前先定架构**
|
||
|
||
在 Claude Code 写下第一行生产代码之前，用 Claude 定义并记录本阶段所有建造都要遵守的架构决策：遵循哪些模式，避开哪些依赖，做了哪些取舍以及为什么。这份输出会成为聚焦的架构上下文文档，并建立 Claude Code 要在其中运行的护栏。
|
||
|
||
没有这份上下文，每次会话都从零开始，Claude Code 被迫推断自己的结构性假设。让 Claude Code 没有护栏地建造，会产出功能可用但结构不一致的代码库。迭代和扩张这种代码库，最终是在浪费时间和 token。迟早会到一个点，代码不可避免地坍塌，迫使你从头重建。
|
||
|
||
练习：打开 Claude Code 之前，先打开 Claude 并描述你要做什么：它解决的核心问题、服务的用户、以及未来六个月现实预期的规模。让它帮你定义 MVP 构建应遵守的架构原则、在约束下应避免的依赖、以及这个阶段有意识接受的取舍。
|
||
|
||
接着，把这份输出保存为 [CLAUDE.md](http://claude.md/) Markdown 文件。这就是你的架构上下文文档：构建过程的第一个产物，也是后续每次会话依赖的东西。[CLAUDE.md](http://claude.md/) 文件是 Claude Code 的项目级指令，为特定代码库提供上下文和说明，并会在 Agent SDK 在目录中运行时被自动读取。功能上，它就是项目的持久记忆。
|
||
|
||
**定义并执行 MVP 范围**
|
||
|
||
没有摩擦的范围蔓延，是 AI 时代 MVP 的典型失败模式之一。就像你定义并记录产品应用架构一样，在任何功能被建造之前，也要先定义 MVP 范围。
|
||
|
||
Claude 可以帮你创建范围文档，描述 MVP 产品做什么、明确不做什么，以及功能修订标准：此时来自真实用户的哪种具体证据，才足以证明应该加新东西。
|
||
|
||
当新的功能想法出现时，它们一定会出现，你要用 Claude 压力测试：这是用户真实信号，还是披着产品思考外衣的创始人热情。
|
||
|
||
**用 Claude Code 造 MVP**
|
||
|
||
架构和范围定义好后，Claude Code 就成为主要的 MVP 构建工具。用它生成、测试、调试、迭代代码库，但要把每次会话当作执行你已经做出的产品决策，而不是趁机塞进新想法。
|
||
|
||
每次 Claude Code 会话开始时，先重新查看范围文档，并给模型提供 [CLAUDE.md](http://claude.md/) 架构上下文文档。每次会话结束时，把会话中浮现的决策更新进去。**目标是一个你能解释其结构的代码库，而不只是一个能跑的代码库。**
|
||
|
||
练习：为 Claude Code 工作创建一个简单会话模板，包括架构上下文文档、本次具体任务、以及需要遵守的约束或模式。每次会话结束时，在上下文文档里加一条简短日志，说明构建了什么、做了哪些决策、引入了哪些假设。每次五分钟的文档记录，是防止架构漂移复利成不可管理代码库的便宜保险。
|
||
|
||
**任何用户上手之前先做安全审查**
|
||
|
||
作为 AI-Native 创业公司创始人，你有责任知道代码库里有什么，理解潜在暴露路径，并且不要把明显漏洞交付给信任你处理其数据的真实用户。
|
||
|
||
Claude 可以对 AI 生成代码做有用的第一轮安全审查，帮助识别常见漏洞。这是发布前值得放进循环里的好习惯。但它不能替代安全工具，在风险更高时也不能替代人类审查。把它当替代品的创始人，最后往往会出现在事故故事里。
|
||
|
||
Claude Code Security 更进一步：它会扫描代码库里的安全漏洞，并为人类审查建议定向补丁，浮现传统方法可能漏掉的问题。
|
||
|
||
注：截至本电子书出版时，Claude Code Security 仍是有限 beta 版本。把它加入工作流之前，请确认当前可用状态。
|
||
|
||
练习：部署给任何真实用户之前，用一个明确 brief 把核心应用代码交给 Claude 审查：认证和会话处理、API 响应中的数据暴露、输入校验和注入风险、以及存在已知漏洞的依赖。认真对待每个发现，并判断是否需要修复；凡是涉及认证、密钥或数据处理的发现，都要有人类审查。
|
||
|
||
**发布前建好度量框架**
|
||
|
||
那些把早期牵引误判成 PMF 的创始人，通常也是发布后才开始追踪数据的人，而且选的指标往往是为了评估什么有效，而不是浮现什么无效。**解药是在第一个用户出现之前，就建立你的度量框架。**
|
||
|
||
用 Claude 定义你的具体产品应该看哪些指标、基准是什么、数据中哪些模式构成真正 PMF、哪些只是好看的噪音。具体来说，在发布 MVP 前设定留存基准、激活标准、以及第 7 日和第 30 日目标。
|
||
|
||
接着，定义对你的具体产品而言什么是假阳性：有注册但无激活、有收入但无留存、初始热情但没有重复使用等。当数据到来时，让 Claude 替怀疑者说话：一个怀疑者会如何解读这些数字？
|
||
|
||
**管理发现和用户反馈的运营层**
|
||
|
||
一旦真实用户进入产品，运营层会迅速膨胀。Claude Cowork 可以处理重要但繁琐的工作：建立和维护用户联系人列表、跑触达序列、安排反馈会、分诊 bug 报告、追踪迭代周期。想法阶段管理发现后勤的 MCP 集成，在这里同样适用。
|
||
|
||
对细腻的用户反馈探索，要保留人在收集循环里。用户说「这很好，但我希望它还能……」时，需要解释：这是核心需求还是锦上添花？是这个客户特有，还是代表某一细分人群？缺失功能才是真问题，还是新用户引导上游出了问题？没有工具能替你回答这些问题。
|
||
|
||
练习：配置 Claude Cowork 跑你的 MVP 阶段反馈环：给早期用户列表起草触达、安排反馈会、设计 bug 和功能请求的结构化收集流程、每周写一份综合摘要。你先自己审阅摘要；之后再让 Claude 分析信息，捕捉你可能漏掉的重要点。
|
||
|
||
**朝证据迭代，而不是朝完整迭代**
|
||
|
||
MVP 阶段结束于你拥有 PMF 的真实证据，而不是产品看起来有多「完整」。宣布已经达到 PMF、准备从 MVP 阶段进入发布阶段，最终是一项判断练习，需要结合创始人直觉和收集到的证据。不过，有一些有用的试金石：
|
||
|
||
- Sean Ellis 测试：问你的活跃用户：「如果再也不能用这个产品，你会感觉如何？」如果超过 40% 的人回答「非常失望」，这是一个有意义的 PMF 指标。
|
||
- 努力测试：PMF 之前，留存需要持续干预：频繁触达、激励、个人跟进，以及创始人那种英雄式能量来维持用户参与。PMF 之后，产品开始自己承担这项工作。**当事情开始「拉」而不是「推」时，这种努力变化是真东西发生的最清晰信号之一。**
|
||
|
||
最终，没有任何单一数据点能确认 PMF，因为它必须在多个迭代周期里持续成立，才能被明确命名。
|
||
|
||
**数据要求 pivot 时，就要 pivot**
|
||
|
||
如果投入这么多工作后，仍然无法抵达 PMF 怎么办？结果没有确认你一开始的方向，并不是失败，而是系统在正常工作：MVP 阶段的设计目的，就是在你对错误答案过度投入之前浮现这些信息。
|
||
|
||
当数据不支持当前产品时，用 Claude 梳理这些数据到底在告诉你什么。
|
||
|
||
- 探索替代客户细分。也许那些没有转化的用户，从一开始就不是正确目标。很多时候，正确受众已经在你的数据里，只是权重被低估了。
|
||
- 调整产品价值主张。也许受众是对的，但 MVP 没有和用户产生共鸣。调整新用户引导、信息表达或核心功能强调，可能无需改变已构建的东西就能修正问题。
|
||
|
||
保持开放：设计价值和体验价值之间的脱节，可能深到需要一次更根本的改变。
|
||
|
||
练习：如果你已经完成三轮或更多迭代周期，仍未看到朝 PMF 基准的实质推进，让 Claude 在决定下一步之前先跑一次诊断。把留存数据、用户反馈和最初的问题假设都喂给它，问三个问题：
|
||
|
||
- 数据里是否存在某一段用户响应方式与其他人不同？
|
||
- 设计价值与体验价值之间的差距，是定位问题还是产品问题？
|
||
- 当前产品要找到真实 PMF，需要哪些条件？以你观察到的现象来看，那个情境现实吗？
|
||
|
||
让答案决定你是调整、pivot，还是退回想法阶段。
|
||
|
||
———
|
||
|
||
## 第五章 发布阶段
|
||
|
||
**如果说 MVP 阶段是要证明你的产品值得存在，那么发布阶段就是要证明你的生意值得长大。**
|
||
|
||
发布阶段·目标
|
||
|
||
在发布阶段，创业者必须把早期势头转化为一台可重复、可持续的增长引擎。除了让产品具备生产就绪状态，你还必须同时加固产品底下的基础设施，也就是说，要围绕产品真正建出一家公司。
|
||
|
||
创业公司在想法和 MVP 阶段天然是创始人中心化的，因为你需要完整的处境感知和紧密反馈环。但现在，那些仍试图把每一根线都自己握在手里的创始人，会变成发布阶段的瓶颈。目标不是把自己从公司里拿掉，而是搭建运营系统，把注意力释放出来，去做那些只有创始人能做的决定。
|
||
|
||
发布阶段·退出标准
|
||
|
||
发布阶段的退出条件包含三个要素：
|
||
|
||
- 增长是可重复的、由渠道驱动的。你不是仅仅在留住用户，而是通过明确渠道、有可被理解的单位经济模型，可预测地获取用户。CAC、LTV、回收周期，这些都是你知道且能 defend 的数字。
|
||
- 产品能扛住生产工作负载。基础设施已加固，安全与合规到位，可靠性在真实生产条件下也站得住，而不只是在你测试过的条件下。
|
||
- 运营在没有创始人瓶颈的情况下也能跑。流程已就位，自动化已部署。你不再是亲自处理客服、分诊、冲刺规划或报表的人。
|
||
|
||
发布阶段·挑战
|
||
|
||
找到 PMF 是早期创业生命周期里最难的问题。现在，创始人的挑战变成了保住它。发布阶段是这样一种地方：那些已经找到真实产品牵引的公司，仍可能在包围和支撑产品的组织跟不上时散掉。
|
||
|
||
**技术债到期**
|
||
|
||
挑战：那个为速度和验证而建的 MVP 代码库勉强够证明产品能跑，但生产流量、新功能和增长中的复杂度，现在正把当初的捷径暴露出来。
|
||
|
||
在 MVP 时，积累一些技术债是合理的速度换取。在发布阶段，那笔债开始算利息，拖得越久，修起来越贵。
|
||
|
||
解决方案是一套系统的架构审查：找出结构性弱点，对最严重的问题做定向重构，并有意义地扩展测试覆盖率，确保下一轮功能开发不会重新引入同样的问题。
|
||
|
||
**创始人成为瓶颈**
|
||
|
||
挑战：MVP 阶段，创始人在每个循环里是一种资产。发布阶段，随着支持量增长、产品决策堆积、运营复杂度倍增，同样的本能会变成约束。
|
||
|
||
从亲自做事，到设计能把事情做完的系统，是创业生命周期里最难的转变之一。因为很少有一个清晰时刻宣告它已经发生，风险就在于你完全错过它，继续停留在建造者模式，而组织在你周围停滞。明显信号包括：本该一小时完成的决策，因为等你处理变成一周；支持请求越堆越多，因为只有你知道答案；运营任务只有在你亲自想起来时才发生。
|
||
|
||
补救办法是彻底审计你亲自处理的一切，从最小任务到最关键决策，识别什么能系统化，什么能委派，什么真正仍值得创始人投入时间和注意力。
|
||
|
||
**安全与合规不再能往后拖**
|
||
|
||
挑战：MVP 阶段，保持安全与合规措施简单还可以。但现在，有真实用户、真实数据，甚至可能有企业合同在桌上，它会变成负债。
|
||
|
||
MVP 阶段，只有少量 beta 用户、生产环境里没有敏感数据时，安全漏洞还是理论风险。但产品一旦进入生产、有真实用户依赖它，假设就会变成非常现实的暴露风险。更进一步，那些不适用于原型的合规要求，会在你处理客户数据、处理支付或销售给受监管行业的那一刻明确适用。
|
||
|
||
补救办法是在生产规模到来之前，而不是之后，做系统的安全与合规审查。凡是浮现出来的问题，都要当成下一波用户到来前必须修复的事项，而不是建议。
|
||
|
||
**还没准备好就扩张**
|
||
|
||
挑战：新市场和融资机会看起来像增长机会。它们也可能是 PMF 死掉的地方。
|
||
|
||
你建立的初始牵引是真实的，但它也具体绑定在早期受众上。过早扩张到一个与原市场显著不同的市场，会引入新的用户行为、合规要求、支付基础设施和基线预期，而你的产品并不是围绕这些设计的。突然之间，变量太多，你失去了清晰解释自己数据的能力。你还可能一边追逐新的、未经验证的受众，一边忽视原始用户群。
|
||
|
||
Claude 如何帮助发布阶段创始人
|
||
|
||
发布阶段会完整用到 Claude 的三种形式，而且它们相互支持：每个工具的输出都会变成另外两个工具的输入。结果会自然复利，一个同时使用三者的创始人，得到的不只是各部分相加。
|
||
|
||
**这正是超精益创业模型在结构上可行的原因。当 Claude Code 构建产品，Claude Cowork 构建产品周围的公司，Claude 帮助把产品和组织知识运营化，一个小团队就能像大得多的公司一样运行。 在技术债复利之前清算**
|
||
|
||
你的 MVP 代码库能跑，但它也需要一次系统的修复扫描，找出任何可能变成结构性负债的技术债。
|
||
|
||
首先，用 Claude Code 跑一次完整架构审查：识别代码库哪里脆弱，哪些捷径会变得维护昂贵，测试覆盖哪里薄到下一轮功能开发会重新引入同样问题。
|
||
|
||
把 Claude Code 的审查发现喂回 Claude，让它分诊并排序修复工作：什么必须在下一次发布前修，什么可以等一个冲刺，什么在当前阶段属于可接受的持续债务。这也是把 MVP 阶段那些只存在你脑子里的架构决策写下来的时刻。把它们放进 [CLAUDE.md](http://claude.md/)，能确保未来每次 Claude Code 会话都从共享理解开始。
|
||
|
||
练习：指挥 Claude Code 审查 MVP 代码库，产出结构性弱点、测试覆盖缺口和重构候选项的优先级列表。然后把清单交给 Claude，让它把修复工作排进几个冲刺：哪些重大问题要先处理，哪些可以和功能开发并行，哪些可以等待。
|
||
|
||
**搭起那些替换创始人注意力的系统**
|
||
|
||
要搭建能释放你注意力的运营系统，去处理只有创始人能承担的责任，第一步是准确知道你的注意力花在哪里。用 Claude Cowork 结构化审计当前运营负荷，记录每个重复任务、每个落到你桌上的决策、每个只因为你亲自记得才会发生的工作流。然后让 Claude Cowork 把清单分成三类：能完全自动化的，需要人但不一定需要你的，以及确实需要创始人判断的。
|
||
|
||
审计完成后，用 Claude Cowork 设计自动化候选项的工作流逻辑：每个工作流由什么触发、决策规则是什么、输出长什么样、完成后流向哪里。
|
||
|
||
**把安全与合规做成产品工作流**
|
||
|
||
用 Claude Code 浮现代码层面的问题，这些问题常出现在 SOC 2、GDPR、HIPAA 审计以及目标市场要求的标准中。它会同时浮现漏洞和合规缺口。把发现交给 Claude，帮助你排列修复优先级，并设计企业买家签约前会要求的控制、审计日志和访问管理。
|
||
|
||
注：AI 扫描是一种辅助，不能替代有资质的合规审查。
|
||
|
||
接下来，把合规工作流纳入开发周期，而不是把它当一次性项目。合规文档需要持续维护和更新。对正在接近企业合同或国际市场的创始人来说，这也是 Claude Code 安全扫描帮助你准备独立安全评估的时刻。
|
||
|
||
练习：用 Claude Code 跑一次代码级安全审查，方向对准目标市场所需框架。把输出喂给 Claude，请它产出两样东西：优先级排序的安全修复序列，以及为了通过潜在企业买家的合规审查，你需要产出的文档和控制清单。
|
||
|
||
**把一直跳过的产品管理流程立起来**
|
||
|
||
发布阶段需要一套轻量、可重复的流程，不需要创始人介入触发或维持也能运行。用 Claude 设计产品时间线和工作周期如何组织，一份 spec 在 Claude Code 触碰功能前必须包含什么，bug 报告如何分诊和路由，每周指标简报覆盖什么、如何分发。
|
||
|
||
流程设计完成后，用 Claude Cowork 搭建并运行运营层：安排冲刺仪式、把新进 bug 报告路由到正确位置、从连接的数据源汇总每周指标、维护让用户信号持续流入产品决策的反馈环。
|
||
|
||
练习：请 Claude 设计一套轻量产品管理操作系统：明确的冲刺节奏、最低规格文档模板、bug 分诊决策树，以及从真实数据源拉取的每周指标简报。然后设置 Claude Cowork 执行并运行系统里的重复运营元素，例如排期、路由和报告汇总，让它们按计划发生，而不需要你。
|
||
|
||
———
|
||
|
||
## 第六章 规模化阶段
|
||
|
||
在规模化阶段，创始人的角色重新校准，从建造者转向面对公众的高管。产品仍是核心，但你的日常工作越来越多地落到公司本身上。你必须把注意力扩展到新的规模化阶段活动，例如分析师沟通会和 IPO 路演，同时尽量保住那份精益、AI 为中心的结构性优势。
|
||
|
||
规模化阶段·目标
|
||
|
||
扩张技术基础设施的工作不会停止，现在又加入了扩张组织本身、把它催熟为一门生意的工作。
|
||
|
||
到了规模化阶段，你要从数千用户走向数百万，从一个市场走向多个市场。在之前每个阶段，增长都是你能摸着走的事：靠贴近用户、靠紧密反馈环的数据，再加上一点健康的创始人直觉来调整方向。现在，目标是搭建由成熟组织运营支撑的系统化增长。
|
||
|
||
**对一家 AI-Native 创业公司，你的目标应该是通过累积深度，建出防御性护城河。** 这来自你已经构建进产品里的专业知识、产品与用户依赖的其他工具和平台之间的深度整合、以及专有系统数据和工作流。那些一直在同一方向、同一基础设施上持续构建的创始人，现在手里有了真正难以复制的东西。
|
||
|
||
到了这个阶段，公开市场投资人、分析师、监管者、企业采购团队和收购方都会施加更大压力，也带来更大怀疑，因为赌注更高了。你的产品和组织必须经得起外部审视：不只是已经造出来的能力，还有围绕它的治理、合规姿态、财务控制和战略叙事。
|
||
|
||
规模化阶段·退出标准
|
||
|
||
规模化阶段的退出条件不再是单一里程碑，而是一个阈值事件：哪怕创始人越来越少直接跑日常运营，公司也已经可持续。你已经展示了系统化增长；建好能满足最苛刻外部审查者的组织治理和合规基础设施；并且能扎实回答这个问题：「如果一个资金充足的现任者今天复制了你的产品，你的用户会留下来吗？」
|
||
|
||
实践中，这个阈值通常会以三种形式之一出现：达到不再需要外部资本的规模化可持续盈利、IPO 就绪、或被收购。三者都要求你的增长系统化且可审计，产品护城河经得起审视，组织在运营上成熟且可持续。
|
||
|
||
当这些都成立时，恭喜你：你的创业公司已经从一场赌注，变成了一门生意。
|
||
|
||
规模化阶段·挑战
|
||
|
||
**把运营层放手出去**
|
||
|
||
挑战：规模化阶段的运营系统必须可靠、可持续地运行，不能靠人盯着。对一个从第一天起就亲力亲为的创始人来说，这种转变既是结构挑战，也是心理挑战。
|
||
|
||
**发布阶段的工作是创建系统；规模化阶段的工作则是让这些系统成熟到完全可信，然后真的信任它们。**
|
||
|
||
这比听起来更难。即使你是一个擅长授权的创始人，也不总是清楚什么该交出去，什么该留在自己手里。交得太多、太快，尤其交给 AI 自动化系统，关键决策可能会在缺少创始人独有上下文的情况下发生。但抓得太久，你又会变成瓶颈。
|
||
|
||
这里的根本挑战，是识别那些只存在于创始人脑子里或未文档化工作流中的机构知识，并把它编码进有文档、可审计、可交接的系统里。
|
||
|
||
**扩张技术运营**
|
||
|
||
挑战：客户不再只评估你的产品；他们还想知道你的组织能不能成为可靠的基础设施伙伴。
|
||
|
||
创业前三个阶段的技术挑战围绕代码库：构建正确方案而不积累技术债，然后为真实用户加固安全和合规。进入规模化阶段后，挑战变成围绕代码库的一切：创建支持基础设施、文档和可靠性保证，来传递成熟信号。
|
||
|
||
签多年合同的大客户和机构买家，在签约前会要求这些东西，签约后也会按这些要求约束你。不过，带你走到这里的同一套 AI 基础设施，也能帮助你建立专门支持职能：明确响应时间、提供新客户工程团队真正能用的文档。
|
||
|
||
**扩张组织职能**
|
||
|
||
挑战：规模化阶段的公司通常需要招聘、工资、会计和法律运营等组织基础设施，不管实际跑公司的人有多少。
|
||
|
||
发布阶段，系统化运营意味着自动化那些消耗创始人注意力的工作流。规模化阶段的创业公司现在需要扩展更广、某些方面也更关键的一组运营职能，例如财务报告、合规监控、合同管理和客户支持。
|
||
|
||
**搭一个 GTM 职能**
|
||
|
||
挑战：自然增长有天花板，而多数规模化阶段创始人在真正搭过 GTM 职能之前，就会撞上它。
|
||
|
||
想法、MVP 和发布阶段的增长，往往来自创始人亲自卖：从一个恰到好处的 Product Hunt 帖子，到与早期客户的私人关系。这样的自然增长只能走到某个点，大多数创业公司会在规模化阶段撞到这个上限。信号包括用户曲线变平、获客成本上升、以及只有创始人亲自介入时管道才会推进。
|
||
|
||
规模化阶段的增长，需要搭建一个专门增长引擎，让产品触达新的、更广的人群。但多数创业公司创始人，可能从来没有真正运行过市场、销售、分析师关系这类项目。一个像样的 GTM motion 不只是建立新系统和流程，还要创造品牌声音和产品故事，说明你想如何谈论自己的产品。因为在生命周期的这个阶段，你需要触达的不只是一个个新用户，还包括投资人、企业买家等完整目标受众。
|
||
|
||
好消息是，GTM 职能不必很大也可以有效。构建产品的同一套 AI 基础设施，也可以引导产品走向市场。
|
||
|
||
Claude 如何帮助规模化阶段创始人
|
||
|
||
早期阶段，Claude 是产品本身的基础设施：验证想法的研究伙伴、设计并构建原型的工程团队、以及让单人创业公司可行的 AI 运营层。走到规模化阶段的 AI-Native 创始人，现在可以继续用 Claude、Claude Code 和 Claude Cowork，以同样方式扩张。
|
||
|
||
**把日常任务交给 Claude Cowork**
|
||
|
||
以一个清醒视角开始规模化阶段：你现在最需要把时间和注意力投在哪里？对第一次创业、从未真正搭过一门生意的创始人来说，这会很难。Claude 可以帮你列出这个阶段只有你该做的事，例如产品叙事决策、董事会关系、企业大单、创始人与创始人的对话。任何不在清单上的事，都是委派或 Claude Cowork 自动化的候选项。
|
||
|
||
练习：用 Claude 绘制当前运营层的瓶颈地图：所有目前经过你的工作流、决策和审批。然后让 Claude 推演：如果你一周不可用，每一项会发生什么？会停下来的工作流，就是你仍亲手握得足以阻碍进展的地方。
|
||
|
||
这些与 Claude 帮你列出的创始人优先事项和责任清单如何对应？
|
||
|
||
接下来，压力测试你已经建好的系统是否真的能随业务增长而扩张。
|
||
|
||
练习：用 Claude 绘制当前工作流，并询问如果你一周不可用，每一项会发生什么。会停滞的工作流，说明交接标准、升级路径或异常处理仍需收紧。Claude 可以分析失败点并建议修复，让你按需更新或替换 Claude Cowork 自动化。
|
||
|
||
**把技术运营升级为企业级基础设施**
|
||
|
||
扩张时，买家需要确信你的产品和组织可以被当作长期基础设施信任。代码库内部的技术工作照常继续，但现在代码库周围的技术工作也必须处理。
|
||
|
||
第一步是把机构知识转换成能扩张的系统。用 Claude 起草并维护企业采购预期会看到的书面基础设施，包括产品文档、支持 playbook 和 SLA。
|
||
|
||
同时，指挥 Claude Code 针对企业合同要求的具体可靠性和安全标准审查并加固代码库，并构建出 Discord 社区支持从未需要提供的技术支持基础设施：日志、监控、事故响应工具，以及让 SLA 真正可执行的可观测性层。
|
||
|
||
随后，Claude Cowork 运行企业支持本身的运营层：工单路由、升级工作流、由产品变化触发的文档更新、续约追踪，以及企业客户成功依赖的报告节奏。三者合起来，让小团队拥有大组织的支持姿态，而这正是签多年企业合同前你必须证明的东西。
|
||
|
||
练习：挑出最苛刻的三个潜在客户，或识别你最想签下的三个理想客户。让 Claude 做差距分析：这些账户的企业采购团队在签多年合同前，会期待看到哪些文档、SLA 和支持基础设施？你目前哪里不足？用输出安排 Claude Code 和 Claude Cowork 的技术与文档工作。
|
||
|
||
**搭一个真正的 GTM 职能**
|
||
|
||
创始人的 hustle 把你带到了这里，但要扩张公司，你需要创建并执行真正的 GTM 策略。AI 可以帮你构建，然后运行完整的 GTM 引擎。
|
||
|
||
Claude 可以从零搭建基础 GTM 资源：市场细分、信息架构、分析师关系策略、销售 playbook，以及当你开始面对公开市场投资人、企业买家和华尔街分析师时重要的投资人指标叙事。每类受众都有自己的词汇，并用自己的标准评估你；Claude 的工作，是把产品价值主张翻译成每个受众都相关的产品营销方法。
|
||
|
||
现在，Claude Cowork 可以成为你的战术执行层：内容管线、外呼序列、分析师沟通会后勤、新闻和 PR 节奏、CRM 卫生、销售管道报告，以及把 GTM 策略变成真实商业动作的许多重复周期。
|
||
|
||
当 GTM motion 需要产品营销基础设施，例如交互式演示环境、集成文档、沙盒租户、API 参考、技术 one-pager，Claude Code 可以为你构建。买家期待从技术上评估你的产品。在规模化阶段，一段 Loom 视频和一份销售 deck 已经不够。这也是让 GTM motion 异步运行的基础设施：一个做得好的 demo 环境，可以在你开董事会时帮你成交。
|
||
|
||
**把领域专长和机构知识转入 AI 上下文**
|
||
|
||
许多超精益创业创始人，正在为某个他们亲身经历或观察到的特定行业真实问题，构建高度具体的 app 或工具。Agentic AI 让从未写过一行代码的创始人，也能用自己的领域专长做出解决复杂问题的产品。Claude、Claude Code 和 Claude Cowork 各自参与，把创始人知识转换成会复利的产品具体性。
|
||
|
||
用 Claude 捕捉、组织并细化创始人知识，就是把领域专长放到产品能够触达的地方。通过长对话、Projects 和记忆，创始人可以把自己知道的一切：行业黑话、监管坑、边缘情况、挫败点、为什么显而易见的答案并不管用，放进结构化、可搜索的上下文。**Skills 可以把重复工作流编码成可复用例程**，例如「我如何审查商业租约」「我如何分诊患者入院表」，让 Claude 每次都用同样方式运行。几个月后，这会变成一种专有知识基底，通用 AI 无法匹配。
|
||
|
||
把领域知识外部化到 Claude 中，对把行业特定边缘情况编码进产品极有价值。例如，一个通用医疗计费工具可能会在 340B 药品项目索赔上出错，而你的工具有专门逻辑。Claude Code 帮你把同行业其他专业人士常遇到的挫败，转译成验证逻辑、prompt 优化，或与竞争对手从未听过的小众行业系统的 MCP 集成。结果是，你的 app 或工具在深度和广度上都持续复利，竞争对手无法简单复制。
|
||
|
||
练习：找出一个通用竞品在你的垂直领域一定会做错的边缘情况。和 Claude Code 一起基于你真实见过的场景，为它构建一个专门测试用例，不是单元测试。每当相似边缘情况出现，就把它加进去。**你的测试套件会变成护城河地图。 让积累的用户数据复利成防御性优势**
|
||
|
||
用户与产品互动时，会生成行为信号，例如他们接受哪些输出、拒绝哪些输出，这会反过来影响产品路线图。随着时间推移，你会学到特定用户群的具体模式、偏好和边缘情况。这就是复利价值：每次改进让产品更有用，带来更多使用，创造更多反馈，再推动更多改进。
|
||
|
||
这些数据有时间锁定、具体上下文，并且无法被复制者重建：你不能买到数千名用户在你的产品里打磨工作流后形成的行为指纹。
|
||
|
||
Claude 可以帮助审计你收集到的用户交互数据，识别其中最高信号的行为模式，并设计把持续使用转化为系统性模型改进的反馈环。
|
||
|
||
练习：给 Claude 一份产品交互数据摘要：你收集了什么、收集了多久、你知道用户如何随时间使用产品。让它识别三个最高信号的行为模式，并为每一个设计能转化为系统性模型改进的反馈环。然后请它帮你起草一页护城河叙事，用于产品营销：你的数据飞轮如何运转、转了多久、为什么一个资源充足的竞争对手今天开始也无法在两年内复制。
|
||
|
||
**创造工作流锁定**
|
||
|
||
数据网络效应的复利会让产品更难被复制，而用户工作流锁定会让产品更难被离开。用户在日常运营中运行你的产品越久，它就越深地嵌入他们真实工作的方式。他们在上面建了自动化，训练团队使用它，把它连接到数据源和其他工具。那些 prompt、被打磨的工作流、被标准化的输出，都围绕你的产品做什么、如何做而成形。**到了这个点，切换不再是一个产品决策，而是一个完整规模的运营项目。**
|
||
|
||
创造工作流锁定的第一步，是让 Claude 按集成深度绘制当前客户群。对每个客户细分，识别他们在你的产品上搭建了哪些工作流、依赖哪些集成。这会显示产品在哪里真正粘住，哪里还需要更深入。
|
||
|
||
你提供的集成越多，客户就越有空间构建依赖你产品的工作流。Claude Code 可以帮你快速搭起目标用户依赖的数据管线、项目管理工具和其他系统的原生集成。它还可以构建 API、webhook 和 SDK，让客户不只是使用你的产品，而是在你的产品之上构建，这是最深的锁定形式。
|
||
|
||
练习：让 Claude 帮你为前十名客户建立工作流集成审计。对每个客户，记录他们搭建的自动化、依赖的集成、经过你产品的团队工作流，以及你估计的切换成本。然后请 Claude 识别这些客户之间的模式：哪些集成类型为你的具体产品创造最深锁定？你还能构建或开放什么，让目前停留在表层的客户拥有更深集成？
|
||
|
||
———
|
||
|
||
## 第七章 工作没变，规则变了
|
||
|
||
**在 AI 时代，创始人的工作并没有变：找到一个真问题，做出能解决它的东西，把它扩张成一家有意义的公司。变的是通往那里的路。**
|
||
|
||
穿过这四个阶段——想法、MVP、发布、规模化，AI 把一个个季度压缩成了一个个星期。
|
||
|
||
那些过去要几个月的验证周期，现在只要一个下午。一个能跑的原型不再需要一位拥有合适技术栈的联合创始人；它只需要一个清晰问题和几次专注会话，配上一个编程 agent。发布就绪从一阵发布前紧张冲刺，压缩成一条持续工作流。在规模化时，过去把早期员工逼成救火队员的运营重量，越来越多可以交给 AI，让你的团队把注意力放在那些会变成护城河的判断决策上。
|
||
|
||
**瓶颈不再是「你能造什么」，而是「你选择造什么」。**
|
||
|
||
———
|
||
|
||
## 资源链接
|
||
|
||
用 Claude 构建
|
||
|
||
- Building AI Agents for Startups：介绍创业公司如何用 agent，让自己在扩张时不那么依赖创始人本人。
|
||
- Claude Code docs：带构建者从初始安装走到进阶 agentic 工作流。提示：先从「How Claude Code works」概览开始。
|
||
- Claude Code best practices：涵盖 Anthropic 内部和工程团队验证过的模式，包括上下文管理、权限、规划和验证工作流。
|
||
- Using [CLAUDE.md](http://claude.md/) files：讲解如何为特定代码库配置 Claude Code。对 MVP 阶段创始人搭建开发环境来说，这是必读材料。
|
||
- Claude Code power user tips：来自 Claude Code 团队自身的工作流模式，包括并行会话和验证环。
|
||
- Get started with Claude Cowork：讲解团队如何搭建 Claude Cowork，并开始实施 Skills、插件和其他能扩大影响的功能。
|
||
- Tutorials：[claude.com/resources/tutorials](http://claude.com/resources/tutorials) 提供可搜索的、面向具体任务的实操教程。
|
||
|
||
创始人故事
|
||
|
||
- How three YC startups built their companies with Claude Code：HumanLayer (F24)、Ambral (W25)、Vulcan Technologies (S25) 如何用 Claude 让原型快速上市，并用 agentic 编程工作流扩张 AI 平台。
|
||
- GC AI：创始人用领域专长做了一个由 Claude 驱动的法律平台，对应内部法务团队真实工作方式：公司专属 playbook、跨职能利益相关者、可变风险容忍阈值。
|
||
- Carta Healthcare：用 Claude 驱动临床抽象平台，每年处理 22,000 例手术，数据抽象时间减少 66%。
|
||
- Anything：由 Claude 和 Agent SDK 驱动，已帮助 150 万用户在不写代码的情况下把想法变成可运行软件产品，包括一位非技术创始人做出并已经在卖的完整招聘平台。
|
||
- Cogent：应用 AI 实验室，构建 agent 自动化企业关键安全任务。Claude 是其 agent 的推理层，覆盖漏洞全生命周期的调查、优先级排序和修复。
|
||
- Airtree：把 Claude Cowork 作为运营基础设施中心，统一过去散落在十几个工具和团队里的数据。现在，一个人用 Skills 搭出工作流自动化，组织中每个人都能用它完成那些长期没空做的事。
|
||
- Duvo：构建 AI agent，跨 ERP、供应商门户、电子表格、邮件甚至电话，运行采购、供应链和品类管理流程。Duvo 完全构建在 Claude 上，使用 Agent SDK 跨工作流编排。
|
||
- Zingage：面向居家护理机构的 24/7 自动化运营 AI agent 平台。它用 Claude 的结构化工具调用编排 EMR 和多通信渠道，用 Claude 的上下文推理给出细腻、因患者而异的结果。
|
||
- Kindora：一位非营利组织高管打造的 AI 驱动平台，用 Claude Sonnet 做出一个急需工具：智能匹配慈善组织与资助方。从数千个匹配筛到少数值得追的对象后，Kindora 的 MCP 连接器让非营利机构可以直接在 Claude 里访问潜在客户工具。
|
||
- Wordsmith：由一位转行做 CTO 的律师创办，为内部法务团队提供可靠的 AI 法律技术。Claude 是 Wordsmith 合同审查、协议起草和文档审查能力的推理引擎，而创业公司的工程团队用 Claude Code 构建并演进平台本身。
|
||
|
||
创业支持与机会
|
||
|
||
- Anthropic Startups Program：面向与 Anthropic VC 合作伙伴合作的创业公司，提供免费 API credits、公开可得的最高级别 rate limits，并邀请参加专属创始人活动和工作坊。
|
||
- Claude community：面向构建者的论坛和社区空间。
|
||
- Live learning resources：大会、网络研讨会、直播流和录播。
|
||
|
||
———
|
||
|
||
本译本仅供个人学习与内部研究使用，不做商业发行。原版权归 Anthropic 所有。 |