创始人手册：构建 AI 原生创业公司 — 完整结构树状图

来源：Anthropic / Claude 官方电子书《The Founder's Playbook: Building an AI-Native Startup》 本文为全书内容结构梳理

结构总览

全书 = 背景（1-2章） + 四阶段方法论（3-6章） + 收尾（7章） + 资源（8章）

其中 3–6 章是真正的「方法论主体」，每章固定四件套，彼此高度对称：

目标 → 退出标准 → 挑战 → Claude 怎么帮（含练习）

完整树状图

《创始人手册：构建 AI 原生创业公司》
│
├─ 第1章 创业生命周期，为 2026 重启（总论·背景）
│   ├─ 核心论断：AI 重塑创业构建方式，门槛被拉平
│   ├─ AI 的三大能力：写生产代码 / 市场研究 / 起草材料 / 自动化运营
│   └─ 传统增长曲线被打破
│       └─ 旧路径「验证→融资→招人→构建→再融资→增长」已失效
│           └─ 引出本书框架：重映四大核心阶段
│
├─ 第2章 当一名创始人的定义正在改变（角色论）
│   ├─ 创始人角色转变：从「个人执行者」→「智能体编排者」
│   ├─ 最革命性结果：解放有领域专长的非技术创始人
│   └─ 精简创业的三大 AI 能力支柱
│       ├─ ① 对话式智能与研究（随叫随到的专家）
│       │     深度研究 / 文档起草 / 战略思考伙伴
│       ├─ ② 智能体编程（永不被卡住的工程师）
│       │     用大白话指挥 AI 生成·测试·调试·重构
│       └─ ③ 工作流自动化（随需调用的运营团队）
│             排期 / CRM / 报表 / 文档 / 合规 / 系统集成
│   └─ 结论：时机与编排是一切（非自动驾驶，需创始人会用）
│
├─ 第3章 创意阶段 Idea Stage ★方法论核心
│   ├─ 目标：以研究为导向的验证（构建前先收集证据）
│   ├─ 退出标准：找到「问题—方案契合」
│   │     ① 问题真实具体？ ② 方案对准真问题？ ③ 信号足够？
│   ├─ 挑战
│   │     ├─ 把「构建」误当「验证」（原型≠证据）
│   │     ├─ 过早规模化
│   │     └─ 客观性丧失（确认偏误 + 研究引擎）
│   └─ Claude 怎么帮
│         ├─ 选对形态：Chat / Cowork / Code（含对照表）
│         ├─ 定义并压力测试问题假设（让 AI 唱反调）
│         ├─ 市场研究与竞争格局
│         │     竞争对手评估 / 市场研究 / 趋势分析
│         ├─ 规划设计客户探索（找谁聊·问什么·访后分析）
│         ├─ 客户触达与排期（Cowork 自动化）
│         ├─ 设计最终方案构想
│         └─ 用 Claude Code 搭轻量原型（只做核心交互→5人试用）
│
├─ 第4章 MVP 阶段 MVP Stage ★方法论核心
│   ├─ 目标：把已验证问题→可用产品；快不积债；投资持久上下文
│   ├─ 退出标准：产品—市场契合的真实证据（留存/营收/转介）
│   ├─ 挑战
│   │     ├─ 智能体式技术债（复利式增长）
│   │     ├─ 误信虚假 PMF（早期数据≠市场需要）
│   │     ├─ 零摩擦的范围蔓延
│   │     └─ 因经验不足而不安全（能跑≠安全）
│   └─ Claude 怎么帮
│         ├─ 构建前先定义架构（产出存为 CLAUDE.md）
│         ├─ 定义并执行 MVP 范围（范围文档 + 新增标准）
│         ├─ 用 Claude Code 构建（每次会话=执行已定决策）
│         ├─ 上线前安全审查（Claude Code Security）
│         ├─ 发布前建好度量框架（留存基准/激活/D7·D30）
│         ├─ 管理探索与反馈事务（保留真人解读）
│         ├─ 朝证据迭代而非朝「完整」（Sean Ellis / 努力测试）
│         └─ 证据要求时就转向（探索新客群 / 调价值主张 / 根本性改变）
│
├─ 第5章 发布阶段 Launch Stage ★方法论核心
│   ├─ 目标：早期牵引力→可重复可持续增长引擎；建运营系统释放注意力
│   ├─ 退出标准
│   │     ① 增长可重复·渠道驱动（CAC/LTV/回本）
│   │     ② 产品扛得住生产负载
│   │     ③ 运营无创始人瓶颈
│   ├─ 挑战
│   │     ├─ 技术债到期了
│   │     ├─ 创始人成为瓶颈
│   │     ├─ 安全合规不再可拖延
│   │     └─ 在准备好之前就扩张
│   └─ Claude 怎么帮（三形态协同放大）
│         ├─ 技术债复利前修复（Code 审计→Claude 排序）
│         ├─ 构建取代创始人注意力的系统（运营负载审计→分类）
│         ├─ 让安全合规成为产品工作流（SOC2/GDPR/HIPAA）
│         └─ 建立一直跳过的产品管理流程（冲刺/规格/bug分诊/周报）
│
├─ 第6章 规模化阶段 Scale Stage ★方法论核心
│   ├─ 目标：系统化增长；通过「积累的深度」建可防御护城河；扛外部审视
│   ├─ 退出标准：阈值事件（可持续盈利 / IPO就绪 / 被收购）
│   ├─ 挑战
│   │     ├─ 委派运营层（结构 + 心理双重挑战）
│   │     ├─ 扩展技术运营（成为可靠基础设施伙伴）
│   │     ├─ 扩展组织职能（招聘/薪酬/会计/法务）
│   │     └─ 构建 GTM 职能（有机增长撞天花板）
│   └─ Claude 怎么帮
│         ├─ 日常任务移交 Cowork（瓶颈图 / 一周不在测试）
│         ├─ 技术运营→企业级基础设施（文档/SLA/可观测性）
│         ├─ 构建真正的 GTM 职能（细分/信息架构/销售手册）
│         ├─ 领域知识→AI 上下文（对话/记忆/Skills 编码工作流）
│         ├─ 用户数据复利成可防御优势（数据飞轮/护城河叙事）
│         └─ 创造工作流锁定（集成深度/API/SDK→切换成本）
│
├─ 第7章 同样的工作，全新的规则（结论·升华）
│   ├─ 工作没变：找真问题→构建解决→扩成有分量的公司
│   ├─ 变的是路径：AI 把「季度」压缩成「周」
│   └─ 终极论断：瓶颈不再是「你能构建什么」，而是「你选择构建什么」
│
└─ 第8章 资源 Resources（附录）
    ├─ 用 Claude 构建（文档/最佳实践/CLAUDE.md/教程等 7 项）
    ├─ 创始人故事（YC三家 / GC AI / Carta / Anything / Cogent /
    │   Airtree / Duvo / Zingage / Kindora / Wordsmith）
    └─ 创业支持与机会（Startups Program / 社区 / 直播学习）

结构规律一句话总结

全书 = 背景(1-2章) + 四阶段方法论(3-6章，每章固定四件套：目标→退出标准→挑战→Claude怎么帮+练习) + 收尾(7章) + 资源(8章)。

其中 3–6 章是真正的「方法论主体」，彼此高度对称，可横向拉成一张「阶段 × 要素」矩阵表。

第 1 章 · The startup lifecycle, rebooted for 2026 / 创业生命周期，为 2026 重启

AI is reshaping how startups are built. Founders who've never written a line of code are shipping production applications today, and the lean 10-person unicorn has gone from scrappy underdog story to deliberate plan of action.

AI 正在重塑创业公司的构建方式。今天，从未写过一行代码的创始人也能交付生产级应用；而"精简的 10 人独角兽"已经从草根逆袭的故事，变成了一套深思熟虑的行动方案。

In 2026, AI can write production code, conduct market research, synthesize competitive landscapes, draft investor materials, and automate operational workflows. By eradicating the once-steep learning curves that even experienced technical founders faced in integrating the tools, platforms, and systems needed to bring their idea to life, AI has above all leveled the playing field around who can launch a startup or build a product.

在 2026 年，AI 能够编写生产代码、开展市场调研、综合竞争格局、起草投资人材料，并自动化运营工作流。它消除了曾经陡峭的学习曲线——即便是经验丰富的技术型创始人，过去也要费力整合各种工具、平台和系统才能把想法变为现实。最重要的是，AI 把"谁能创业、谁能做产品"这件事的门槛拉平了。

In 2026, a good idea gets founders further than ever. Agentic coding compresses what used to take a team of engineers into work a single founder can ship themselves.

在 2026 年，一个好点子能让创始人走得比以往任何时候都远。智能体编程（agentic coding）把过去需要一整支工程师团队才能完成的工作，压缩成一个创始人自己就能交付的活儿。

The traditional startup growth arc assumes that the path from idea to scale is validate → raise → hire → build → raise again → grow → hire more → repeat. Now, AI has erased the expectation that each new phase in the startup lifecycle requires a bigger team, a different skill set, and a fresh funding round.

传统的创业增长曲线假设：从创意到规模化的路径是"验证 → 融资 → 招人 → 构建 → 再融资 → 增长 → 再招人 → 循环"。如今，AI 抹去了这样一种预期——即创业生命周期的每个新阶段都必须配上更大的团队、不同的技能组合和新一轮融资。

This playbook remaps the four core stages of the startup journey (Idea, MVP, Launch, and Scale) according to these new realities. We examine what each stage looks like when AI is core to your technical and organizational development, what the right tools are for each phase, and how founders are using these tools are compressing timelines. If you're ready to map the shortest path between idea and exit, read on.

本手册依据这些新现实，重新绘制了创业旅程的四个核心阶段（创意、MVP、发布、规模化）。我们将探讨：当 AI 成为你技术与组织发展的核心时，每个阶段是什么样子；每个阶段对应的正确工具是什么；以及创始人们如何用这些工具压缩时间线。如果你准备好规划一条从创意到退出的最短路径，请继续读下去。

第 2 章 · What it means to be a founder is changing / 当一名创始人的定义正在改变

Founders used to be defined by what they could do: technical founders wrote code, non-technical founders ran business ops and closed deals. But the models, systems, and AI agents available to founders in 2026 have dissolved the wall between "people who can build" and "people with ideas worth building."

过去，创始人是由他们"能做什么"来定义的：技术型创始人写代码，非技术型创始人负责业务运营和谈成交易。但在 2026 年，创始人可用的模型、系统和 AI 智能体，已经消融了"能构建的人"与"拥有值得构建之想法的人"之间的那堵墙。

AI-native startups are fundamentally transforming what it means to be a founder. Now someone with no engineering background can build production software that brings their idea to life, while a technically adept founder with little business knowledge can produce a go-to-market strategy, a financial model, and a highly polished pitch deck.

AI 原生创业公司正在从根本上改变"做一名创始人"的含义。如今，没有工程背景的人也能构建出让想法落地的生产级软件；而技术娴熟但缺乏商业知识的创始人，也能产出一份 go-to-market 策略、一个财务模型和一份高度精致的融资演示稿。

Historically, founders spent the bulk of their time in execution mode: writing code, managing people, handling day-to-day operational work. In an AI-native startup, the founder role becomes much less individual contributor and much more orchestrator of agents—specialized AI assistants that can read files, run commands, execute code, and even browse the web. The founder's attention shifts up the stack toward the higher-order work: generating ideas and directing the systems (AI agents, tools, and whatever small team exists) that carry those ideas out.

过去，创始人大部分时间处于"执行模式"：写代码、管人、处理日常运营。在 AI 原生创业公司里，创始人的角色不再那么像"个人贡献者"，而更像"智能体的编排者"——这些专业的 AI 助手能读取文件、运行命令、执行代码，甚至浏览网页。创始人的注意力向上层转移，聚焦于更高阶的工作：产生想法，并指挥那些把想法落地的系统（AI 智能体、工具，以及任何规模的小团队）。

The most revolutionary result of AI as central infrastructure, though, is to unblock non-technical founders with subject matter expertise. When the founding pool expands beyond people with engineering backgrounds, you get startups built by people with radically different lived experiences, solving real problems that the traditional tech-founder pipeline never prioritized (or perhaps even noticed).

不过，AI 作为核心基础设施带来的最具革命性的结果，是为拥有领域专长的非技术型创始人扫清了障碍。当创始人群体不再局限于有工程背景的人，你会看到由拥有截然不同人生经历的人创办的公司——他们解决的是真实存在、却被传统"技术创始人流水线"从未优先（甚至从未注意到）的问题。

AI tool capabilities for lean startups / 精简创业公司的 AI 工具能力

The traditional startup model assumed you needed to hire engineers to build, salespeople to sell, and ops people to run the business. Headcount was treated as a sign of organizational momentum and product maturity.

传统的创业模式假设：你需要招工程师来构建、招销售来卖货、招运营来运转业务。人头数被当作组织势能和产品成熟度的标志。

Early-stage startups in 2026 are radically different. They're extremely lean by design, often just the founder alone or a team with a few others. By centering both technical and organizational development on AI as infrastructure, they can reach product validation, early revenue, or even profitability before scaling the team. There are three areas in particular where AI helps a startup function like a much larger org: research, agentic coding, and automating workflows for key business operations.

2026 年的早期创业公司则截然不同。它们在设计上就极度精简，往往只有创始人一人，或加上寥寥几位伙伴。通过把技术与组织发展都建立在"AI 即基础设施"之上，它们能在扩张团队之前就实现产品验证、早期营收，甚至盈利。AI 尤其在三个领域帮助小公司像大组织一样运转：研究、智能体编程，以及关键业务运营的工作流自动化。

Conversational intelligence and research / 对话式智能与研究

Think: on-call expert for every domain

可以这样理解： 每个领域随叫随到的专家。

Consider everything a founder needs to know in the first year that they almost certainly don't know going in: how do I set up payroll? How do I plan product development sprints? How do I draft a tight investor memo?

想想一个创始人在第一年需要懂、但起步时几乎肯定不懂的所有事情：我该怎么发工资？怎么规划产品开发冲刺（sprint）？怎么写一份精炼的投资人备忘录？

Early-stage startup questions like these all used to have the same answer, which was Find someone who knows. For a bootstrapped or pre-seed founder, this could consume time spent knowledge-gathering instead of building, or possibly requiring burning a chunk of early capital on a consultant. Now, they have AI as an on-call expert across every conceivable domain.

过去，这类早期创业问题的答案都一样：去找一个懂的人。对于自筹资金或种子前（pre-seed）的创始人来说，这意味着把时间花在搜集知识而非构建上，或者可能要烧掉一笔早期资金去请顾问。现在，他们拥有了一位覆盖一切可想象领域、随叫随到的 AI 专家。

• Deep research: competitive analysis, market sizing, financial modeling
• Document drafting: pitch decks, case studies, investor memos, PRDs
• Strategic thinking partner: devil's advocate analysis, pre-mortems, scenario planning, roadmap optimization

• 深度研究： 竞争分析、市场规模测算、财务建模
• 文档起草： 融资演示稿、案例研究、投资人备忘录、PRD（产品需求文档）
• 战略思考伙伴： 唱反调式分析、事前剖析（pre-mortem）、情景规划、路线图优化

Agentic coding / 智能体编程

Think: the engineer who's always available, never blocked

可以这样理解： 永远在线、从不被卡住的工程师。

Building software used to require a technical co-founder, a contract dev shop, or a long enough runway to hire an engineering team before you'd written a line of production code.

过去，做软件需要一位技术联合创始人、一家外包开发公司，或者足够长的现金跑道——好让你在写出第一行生产代码之前先招一支工程团队。

Agentic coding tools now allow every aspiring founder to describe what they want to build in plain language and direct AI to generate, test, debug, and refactor a production-grade codebase at the speed and scale of a full engineering team.

如今，智能体编程工具让每一位有抱负的创始人都能用大白话描述想构建什么，并指挥 AI 以一整支工程团队的速度与规模来生成、测试、调试和重构一个生产级代码库。

The timeline from "I have an idea" to "I have a product" has compressed. And the founder's role now centers on what to build and why, while AI handles the actual construction of real infrastructure that's ready for real users.

从"我有一个想法"到"我有一个产品"的时间线被压缩了。如今创始人的角色聚焦于"构建什么"和"为什么构建"，而 AI 负责真正构建那套面向真实用户、随时可用的基础设施。

Workflow automation / 工作流自动化

Think: on-demand, automated ops team

可以这样理解： 随需调用、自动化的运营团队。

Even when a founder can research like a consultant and build like an engineering team, there's still a whole category of work beyond strategic planning or product development that still has to get done. Scheduling, updating the CRM, pulling weekly reports, keeping documentation current, publishing content, tracking compliance requirements, managing the connective tissue between the tools and systems the company runs on all have to happen, too. In a lean startup, this load falls mainly on the founder—and it's a significant tax on the time and attention that should be going toward higher-order decisions.

即便一个创始人能像顾问那样做研究、像工程团队那样搞构建，仍有一整类工作——在战略规划或产品开发之外——必须有人完成。排日程、更新 CRM、拉每周报表、保持文档更新、发布内容、跟踪合规要求、管理公司所依赖的各种工具与系统之间的"连接组织"，这些都得做。在精简创业公司里，这份负担主要落在创始人身上——它对本应投入更高阶决策的时间与精力，是一项沉重的税。

Workflow automation with AI tools offloads that tax. Recurring operational tasks can be configured to happen automatically so that the CRM updates when a deal moves, a weekly report compiles itself, and product documentation gets updated in sync with product changes. And, crucially, Claude Cowork integrates with the interconnected systems a startup runs on—your project management tool, your communication stack, your data sources—without needing someone to build and maintain those integrations. In Day Zero startups, that someone is almost always the founder.

用 AI 工具做工作流自动化，能卸下这项税。重复性的运营任务可以被配置为自动发生：交易状态变动时 CRM 自动更新、每周报表自动汇编、产品文档随产品变更同步更新。而且关键在于，Claude Cowork 能与创业公司所依赖的互联系统集成——你的项目管理工具、你的沟通工具栈、你的数据源——而无需专人去搭建和维护这些集成。在"第零天"创业公司里，那个专人几乎总是创始人本人。

Timing and orchestration are everything / 时机与编排就是一切

Founders that effectively harnesses AI's research, automation, and agentic coding capabilities can build a startup that operates with far more leverage than its headcount suggests. They also get to dedicate the majority of their time and bandwidth to the work that actually matters.

能有效驾驭 AI 的研究、自动化与智能体编程能力的创始人，可以打造出一家杠杆远超其人头数的创业公司。他们也得以把绝大部分时间和精力投入到真正重要的工作上。

This work doesn't happen on autopilot; the founder orchestrating these AI tools needs to know how (and when) to apply them. The rest of this playbook is dedicated to exploring the goals and challenges founders will encounter as they follow the AI-native startup path, and how to effectively apply AI tools at each stage of the journey.

这一切并非自动驾驶就能完成；编排这些 AI 工具的创始人需要知道如何（以及何时）使用它们。本手册的其余部分专门探讨：创始人沿着 AI 原生创业路径前进时会遇到的目标与挑战，以及如何在旅程的每个阶段有效运用 AI 工具。

第 3 章 · Idea Stage / 创意阶段

Every startup founder starts from the same place: a problem they can't stop thinking about. This is the startup phase where idea meets reality: startup success in 2026 requires the discipline of not building until the evidence justifies it.

每一位创业者都从同一个地方出发：一个让他们念念不忘的问题。这是创意与现实相遇的创业阶段：在 2026 年，创业的成功需要一种纪律——在证据足够支撑之前，不要动手构建。

The work in this stage is research, customer discovery, competitive analysis, and honest evaluation of disconfirming evidence, all before asking Claude Code to generate your first line of production code.

这个阶段的工作是研究、客户探索、竞争分析，以及对"反向证据"的诚实评估——这一切都发生在你让 Claude Code 生成第一行生产代码之前。

Idea stage goal / 创意阶段的目标

While in the Idea stage, the founder's main goal is research-oriented validation: assembling solid evidence that a real problem exists (and that your proposed solution effectively addresses it) before committing resources to building.

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

Practically speaking, the Idea stage is a series of questions a founder has to answer in roughly this order:

实际操作上，创意阶段是创始人需要大致按以下顺序回答的一系列问题：

• Is this problem real, specific, and frequent enough to build around?
• Who exactly has it, and is that a market?
• Is anyone else solving it, if so, how and how well?
• What would a solution actually need to do in order to solve this problem, and does my idea do that?

• 这个问题是否真实、具体、且足够高频，值得围绕它来构建？
• 究竟是谁有这个问题，这是否构成一个市场？
• 是否已有人在解决它？如果有，他们做得怎样、效果如何？
• 一个方案究竟需要做到什么才能解决这个问题，而我的想法做到了吗？

The results of these inquiries add up to answer a single, ultimate question: Is this worth building?

这些追问的结果，最终汇聚为回答一个终极问题：这值得构建吗？

That means getting specific before you get moving. "People struggle with expense reporting" is an observation. "Finance managers at mid-market companies spend four-plus hours a week reconciling submissions because their current tools don't integrate with their accounting software" is a testable hypothesis.

这意味着在行动之前先做到具体。"人们在报销上很头疼"是一个观察。"中型市场公司的财务经理每周要花四个多小时去核对报销单，因为他们现有的工具无法与会计软件集成"——这才是一个可检验的假设。

Idea stage exit criteria / 创意阶段的退出标准

The Idea stage exit condition is finding problem-solution fit. You've established qualitative evidence, primarily from real human conversations, that you're solving a real problem for real people before you start building the thing that solves it.

创意阶段的退出条件是找到问题—方案契合（problem-solution fit）。你已经建立起定性证据——主要来自真实的人际对话——证明你在为真实的人解决一个真实的问题；这一切都发生在你着手构建解决方案之前。

You're ready to leave the Idea stage when you can answer yes to all three of the following:

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

1. Is the problem real and specific? Answering in the affirmative here requires that you can name exactly who experiences this problem, how often they encounter it, how severely it affects them, and what they currently do about it.
2. Does your solution address the actual problem? Not the problem you originally assumed, but the one the validation process revealed. Sometimes these are the same thing, but not always.
3. Do you have enough signal to justify building? You will never have certainty at this stage, and waiting for it is its own failure mode, but you need enough qualitative evidence that committing to an MVP is a reasoned decision over an act of faith.

1. 问题是否真实且具体？ 要回答"是"，你必须能准确说出谁会遇到这个问题、他们多久遇到一次、它对他们的影响有多严重，以及他们目前是怎么应对的。
2. 你的方案是否针对真正的问题？ 不是你最初假设的那个问题，而是验证过程揭示出的那个问题。有时两者是一回事，但并不总是。
3. 你是否有足够的信号来支撑构建？ 在这个阶段你永远不会有确定性，而苦等确定性本身就是一种失败模式；但你需要足够的定性证据，使"投入做 MVP"成为一个经过推理的决定，而非一次信仰之举。

Idea stage challenges / 创意阶段的挑战

The Idea stage is where the most important work of your startup journey happens, because it's where the most consequential mistakes are made: getting something wrong now can quickly run your budding venture right off the rails. The majority of ideation phase challenges involve moving faster than your understanding justifies, though, so founders who proceed with thoughtfulness and deliberation will experience steady progress.

创意阶段是你整个创业旅程中最重要的工作所在，因为它也是最具决定性后果的错误发生的地方：此刻搞错某件事，可能很快让你萌芽中的事业彻底脱轨。不过，构思阶段的大多数挑战都源于"行动速度超出了你的理解所能支撑的程度"，所以那些深思熟虑、稳扎稳打的创始人会取得稳定的进展。

Mistaking building for validating / 把"构建"误当成"验证"

The challenge: When technical blockers are lifted, an impassioned founder risks skipping the most important work in the startup journey: validating that their idea is genuinely a solution that people need and will use.

挑战： 当技术障碍被移除，一个满腔热情的创始人就有可能跳过创业旅程中最重要的工作：验证他们的想法是否真的是人们需要、并且会使用的方案。

Even before the current era of agentic coding, 42% of startups failed because they built something nobody wanted. Now, though, agentic coding solutions like Claude Code have drastically collapsed the distance between "I have an idea" and "I have a product" and that failure rate is only going to climb.

即便在智能体编程时代之前，就有 42% 的创业公司失败，原因是他们构建了没人想要的东西。而如今，像 Claude Code 这样的智能体编程方案，极大地缩短了*"我有一个想法"与"我有一个产品"*之间的距离——这个失败率只会继续攀升。

While there's never been a better time to be a founder with a synapse-shakingly good idea, the rapidity and ease of spinning up a prototype that looks something like a product also, counterintuitively, presents a genuinely dangerous existential risk for the AI-native startup.

虽然对于一个有着惊艳好点子的创始人而言，从未有过比现在更好的时代，但"快速、轻松地搭出一个看起来像产品的原型"这件事，反直觉地，也给 AI 原生创业公司带来了一种真正危险的生存风险。

Until very recently, building required real dev time and budget, and getting even a basic prototype together typically took months. Now that the hurdle of technical development is largely gone, though, AI makes it all too easy for a founder to jump straight into building without validating its utility in the real world.

直到不久前，构建还需要真金白银的开发时间和预算，哪怕拼出一个基础原型通常也要数月。而如今技术开发这道坎大体已经消失，AI 让创始人太容易直接跳进构建，而不去在真实世界中验证它的实用性。

Reaching problem-solution fit requires first validating your hypothesis then building, but many first-time (and even experienced) founders mistakenly believe that AI short-circuits that requirement, turning the flow into have an idea -> immediately build a prototype -> treat the existence of the prototype as validation. The prototype becomes a reason to believe the hypothesis was right all along, without ever testing whether it's actually true.

达成问题—方案契合，要求你先验证假设、再构建；但许多初次（甚至有经验的）创始人错误地以为 AI 让这一要求可以被绕过，把流程变成了*"有一个想法 → 立刻做出一个原型 → 把原型的存在当作验证"*。原型变成了"假设一直是对的"的理由，却从未真正去检验它是否成立。

A working prototype is easy to mistake as concrete evidence that you're solving a real problem, but it's not. Your prototype instead serves as a useful pressure-testing prop for conversations with potential users. These conversations themselves are the real evidence.

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

Premature scaling / 过早规模化

The challenge: When building is effortless and instant, you can scale execution far ahead of what business demands.

挑战： 当构建变得毫不费力且即时，你可能会让执行的规模远远超前于业务的实际需求。

Scaling prematurely means committing to a product path before you've genuinely validated that the path is worth committing to.

过早规模化，意味着在你真正验证某条产品路径值得投入之前，就一头扎了进去。

This has always been a startup killer, but AI has made it dramatically easier for founders to fall into the premature scaling trap without noticing. Agentic coding assistants are so powerful that it's easy to scale execution far ahead of validating problem-solution fit without ever consciously deciding to stray off course.

这一直是创业公司的杀手，但 AI 让创始人极其容易在不知不觉中掉进过早规模化的陷阱。智能体编程助手如此强大，以至于你很容易在从未有意识地决定"偏离航线"的情况下，就把执行的规模推进到远远超前于"问题—方案契合"验证的程度。

It will generate, test, debug, and refactor a codebase around a fundamentally flawed premise with exactly the same enthusiasm it brings to a great idea. The intelligence in the system is yours. The prime directive at this stage is keeping your sense-making ahead of your building, especially when building is so quick and feels so effortless.

它会围绕一个根本上有缺陷的前提去生成、测试、调试和重构代码库，其热情与对待一个绝妙想法时一模一样。系统里的"判断力"来自你。这个阶段的首要准则是：让你的"意义判断"始终领先于你的"构建"——尤其是当构建如此之快、如此毫不费力的时候。

Loss of objectivity / 客观性的丧失

The challenge: Ask an AI tool for evidence supporting what you already believe, and it will find it. Confirmation bias now comes with a research engine.

挑战： 向 AI 工具索要支持你既有信念的证据，它就会找到。如今，确认偏误（confirmation bias）配上了一台研究引擎。

Confirmation bias has always been an occupational hazard in startups: founders are, by nature, passionate about their ideas. Now, AI tools have given confirmation bias a significant powerup. Ask AI to validate your startup idea and it will find supporting evidence; ask it to size your potential market and it will find the number that makes your TAM look fundable.

确认偏误一直是创业的职业病：创始人天生对自己的想法充满热情。如今，AI 工具给确认偏误来了一记大幅加成。让 AI 验证你的创业想法，它会找到支持的证据；让它测算你的潜在市场，它会找出那个让你的 TAM（潜在市场总规模）看起来值得融资的数字。

AI follows your direction, which means a founder who isn't asking hard questions can now construct an elaborate, well-researched-looking case for a bad idea faster than ever before, while feeling fully confident that they are, in fact, performing due diligence. The antidote is the same tool, only pointed in the opposite direction: AI will pressure-test an idea just as thoroughly as it validates one.

AI 会顺着你的指令走，这意味着一个不去问尖锐问题的创始人，如今能比以往更快地为一个糟糕的想法构建出一套精致、看似经过充分研究的论证，同时还自信满满地以为自己确实在做尽职调查。解药是同一个工具，只不过指向相反的方向：AI 在"压力测试"一个想法时，会和它"验证"一个想法时一样彻底。

When research and structured adversarial thinking surface evidence that your idea needs revision, this the signal to pivot.

当研究和结构化的对抗式思考浮现出"你的想法需要修正"的证据时，这就是该转向（pivot）的信号。

How Claude can help Idea stage founders / Claude 如何帮助创意阶段的创始人

Progressing your AI-native startup concept through the Idea stage can feel like it takes forever. You are a founder and you just want to build. But this all-important kickoff phase is fundamentally a research and validation exercise, which means reaching for the tools that help you think more rigorously before going all in on writing code. Here are the ways to use Claude across its product surfaces (Chat, Claude Cowork, and Claude Code) for moving through the Idea stage as quickly as possible while doing proper due diligence.

推动你的 AI 原生创业构想走过创意阶段，可能感觉漫长无比。你是个创始人，你只想动手构建。但这个至关重要的启动阶段，本质上是一项研究与验证的工作，这意味着你要拿起那些能帮你在全力写代码之前更严谨地思考的工具。下面是在 Claude 的各个产品形态（Chat、Claude Cowork 和 Claude Code）中，如何在做好尽职调查的同时尽可能快速地走过创意阶段的方法。

Chat, Claude Cowork, or Claude Code: choosing the right Claude surface / 选择正确的 Claude 形态

AI makes it easier for startup founders to ship faster, automate tedious workflows, and operate at scale, but the surface you use matters. Here's when to use Chat, Claude Cowork, or Claude Code depending on the task at hand.

AI 让创业者更容易快速交付、自动化繁琐的工作流、并以规模化方式运营，但你使用哪种形态很重要。下面是根据手头任务在 Chat、Claude Cowork 或 Claude Code 之间做选择的指南。

Chat is for quick exchanges without leaving the app you're already in. Use it for the constant small tasks of running a company: pulling the one-sentence takeaway from a dense investor memo, sanity-checking a claim before a board meeting, or making sense of a long Slack thread with your team.

Chat 适合不离开当前应用的快速交流。用它来处理经营公司中层出不穷的小任务：从一份密集的投资人备忘录里提炼一句话要点、在董事会前快速核验一个论断，或读懂团队里一长串的 Slack 讨论。

Claude Cowork is for the knowledge work that actually takes time: pulling from many sources, making sense of it, and producing something finished, like a doc, deck, or spreadsheet. Think turning a folder of customer call transcripts into a themed findings doc for your next product review, building a competitive landscape from a dozen vendor sites before a fundraise, or a standing Monday-morning task that pulls metrics from your connected tools and drops a weekly KPI brief into a shared folder.

Claude Cowork 适合那些真正耗时的知识工作：从多个来源汇集信息、理解它，并产出成品，比如文档、演示稿或电子表格。比如：把一文件夹的客户通话记录变成下次产品评审用的主题化发现文档；融资前从十几个供应商网站构建一份竞争格局；或者设一个每周一早晨的常驻任务，从你连接的工具里拉取指标，并把每周 KPI 简报放进共享文件夹。

Claude Code is the agentic coding environment for the engineers on your team: direct codebase access, Plan Mode, git integration, and local, IDE, or sandboxed cloud environments. It's where a lean team ships features across a growing codebase, migrates legacy code from the MVP days, and moves from prototype to production without waiting on more headcount.

Claude Code 是面向团队工程师的智能体编程环境：直接访问代码库、计划模式（Plan Mode）、git 集成，以及本地、IDE 或沙箱云环境。在这里，精简的团队可以在不断增长的代码库上交付功能、迁移 MVP 时期的遗留代码，并在无需增加人头的情况下从原型走向生产。

The three share the same Claude underneath; what changes is the workspace around it.

这三者底层共享同一个 Claude；改变的只是围绕它的工作空间。

Defining and pressure-testing the problem hypothesis / 定义并压力测试问题假设

Your own domain expertise and up-front research have already generated a hypothesis. The first job is to sharpen it until it's actually testable. Claude is particularly useful here for forcing specificity: who exactly has this problem, how often, how severely, and what do they currently do about it? A problem statement that can't answer those questions precisely isn't ready to validate.

你自身的领域专长和前期研究已经产生了一个假设。第一项任务是把它打磨到真正可检验。Claude 在这里特别有用，因为它会逼你做到具体：究竟是谁有这个问题、多久一次、多严重、目前怎么应对？一个无法精确回答这些问题的问题陈述，还没准备好接受验证。

• Exercise: Work with Claude to sharpen your problem statement until it's a testable hypothesis. For example, "Contract review takes too long" is not meaningfully testable. But "In-house legal teams at mid-market companies spend 3+ days per contract review cycle because redlines are managed across email threads rather than a single version-controlled document" is very testable.

• 练习： 与 Claude 一起打磨你的问题陈述，直到它成为一个可检验的假设。例如，"合同审查耗时太久"没有实质意义上的可检验性。但"中型市场公司的内部法务团队，每个合同审查周期要花 3 天以上，因为修订意见是散落在邮件往来里管理的，而非一份统一的版本受控文档"——这就非常可检验。

Your next move is to ask Claude to argue against your idea, and to find disconfirming evidence that refutes your hypothesis. This can surface negative market signals, failed competitors, customer behavior patterns, and structural obstacles that a supportive synthesis would have quietly deprioritized.

你的下一步，是让 Claude 反驳你的想法，并寻找能推翻你假设的反向证据。这能浮现出负面的市场信号、失败的竞争者、客户行为模式，以及那些"一味支持式的综述"会悄悄淡化掉的结构性障碍。

The goal is to arrive at customer discovery having already stress-tested your assumptions against the strongest available counterarguments so that informational user interviews are genuinely open-ended rather than a search for confirmation.

目标是：在进入客户探索之前，就已经用现有最强的反方论点对你的假设做过压力测试——这样，那些信息型用户访谈才是真正开放式的，而不是一场寻求确认的搜索。

Note: Using Claude as structured devil's advocate is a core use case at every stage of the AI startup life cycle.

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

Market research and mapping the competitive landscape / 市场研究与绘制竞争格局

Sizing up your competitors / 评估你的竞争对手

There's a startup-specific phenomenon called competitor neglect: the tendency to focus so intensely on your own vision and execution that you systematically underweight what others are doing in the same space. Fortunately, AI offers the antidote: ask Claude to make the most compelling argument for why a competitor in this solution space would succeed while you do not.

有一种创业公司特有的现象叫"竞争对手忽视"：过于专注自身的愿景与执行，以致系统性地低估了同领域其他玩家在做什么。所幸，AI 提供了解药：让 Claude 给出最有说服力的论证，说明为什么这个领域的某个竞争对手会成功、而你会失败。

Claude can analyze why their approach is actually better, why customers would choose them, why your potential differentiators may not be as defensible as you think.

Claude 能分析为什么他们的做法其实更好、为什么客户会选择他们、为什么你以为的差异化优势可能并不像你想的那样有护城河。

• Exercise: Ask Claude to map your competitive landscape by tier: direct competitors, indirect competitors, potential acquirers, and adjacent players who could move into your space. Then ask it to argue for why each tier poses a genuine threat to your success, not just the version of the threat that's easiest to dismiss.

• 练习： 让 Claude 按层级绘制你的竞争格局：直接竞争者、间接竞争者、潜在收购方，以及可能切入你领域的相邻玩家。然后让它论证为什么每一层都对你的成功构成真正的威胁——而不只是那种最容易被你打发掉的版本。

Market research / 市场研究

Claude Code can synthesize publicly available customer feedback to surface recurring complaints and unmet needs. Bonus: doing this is essentially free qualitative research on your competitors' customers.

Claude Code 能综合公开可得的客户反馈，浮现出反复出现的抱怨和未被满足的需求。附带好处：这本质上是对你竞争对手的客户做的免费定性研究。

• Exercise: Direct Claude Cowork to synthesize competitor reviews across your key sources and identify the top complaints existing solutions haven't resolved. If your hypothesis addresses one or more of them, that's strong evidence of problem-solution fit. If it doesn't, that's worth knowing too.

• 练习： 指挥 Claude Cowork 综合你关键来源里的竞品评论，找出现有方案尚未解决的头部抱怨。如果你的假设能解决其中一个或多个，那就是问题—方案契合的有力证据。如果不能，那也值得知道。

Claude Cowork can also extract relevant information and figures from dense industry reports, analyst filings, and market research documents; next, these clean, synthesized inputs become ideal context for Claude's analysis work.

Claude Cowork 还能从密集的行业报告、分析师文件和市场研究文档里提取相关信息与数据；随后，这些干净、综合过的输入就成了 Claude 分析工作的理想上下文。

• Exercise: Build TAM/SAM/SOM models from publicly available data and pressure-test the assumptions behind them. Identify whether the market is expanding, consolidating, or mature; this context influences how you think about timing and differentiation. Map the buyer landscape: who holds budget, who influences decisions, and whether those are the same person.

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

Trend analysis / 趋势分析

Finally, use Claude to listen for early indicators that tell you whether you're entering at the right moment. Track subreddits and LinkedIn groups where conversations about your problem are already happening and the exact language users reach for when describing their issues. Ask Claude to identify analogous markets where a similar problem was solved, and extract what worked and what didn't. Surface regulatory, technological, or demographic trends that could accelerate or threaten the opportunity.

最后，用 Claude 去倾听那些告诉你"是否在正确时机切入"的早期指标。追踪那些已经在讨论你的问题的 subreddit 和 LinkedIn 群组，以及用户描述自身困扰时所使用的确切措辞。让 Claude 找出曾解决过类似问题的类比市场，并提取其中哪些有效、哪些无效。浮现出可能加速或威胁这一机会的监管、技术或人口结构趋势。

• Exercise: Ask Claude to identify three external trends—regulatory, technological, or demographic—that could significantly affect your market in the next two years, and to assess whether each one is a tailwind or a headwind for your specific hypothesis.

• 练习： 让 Claude 找出三个可能在未来两年显著影响你市场的外部趋势——监管、技术或人口结构方面——并评估每一个对你的具体假设而言是顺风还是逆风。

Note: The market research and competitive mapping work in this section isn't a one-time exercise. You are going to continue making discoveries and evolving your thinking through the MVP and Launch stages, so it's important to repeat these exercises whenever your hypothesis evolves.

注： 本节的市场研究与竞争格局绘制并非一次性的工作。在 MVP 和发布阶段，你会持续有新发现、不断演进你的思考，所以每当你的假设发生变化时，重复做这些练习很重要。

Plan and design customer discovery / 规划并设计客户探索

The quality of what you learn by talking to potential users for your product is determined by (1) the quality of the questions you ask and (2) whether you are posing these to the right people. Claude is particularly helpful for conducting customer discovery, including who to talk to, what to ask, and how to make sense of what you hear.

你通过与产品潜在用户交谈所学到的东西，其质量取决于：(1) 你所问问题的质量；(2) 你是否在向正确的人提问。Claude 在开展客户探索方面尤其有帮助，包括该找谁聊、问什么，以及如何理解你听到的内容。

Who to talk to / 该找谁聊

A precise target profile is infinitely more valuable than a long contact list, including specific job titles, company types, team structures, and seniority levels most likely to experience the problem acutely. From there, identify where those people are actually reachable—the communities, events, LinkedIn groups, and Slack workspaces where they congregate—and build a prioritization framework for who to reach out to first based on how close they are to the problem.

一份精确的目标画像，远比一长串联系人名单有价值得多，其中包括最可能强烈感受到该问题的具体职位、公司类型、团队结构和资历层级。在此基础上，找出这些人实际可触达的地方——他们聚集的社区、活动、LinkedIn 群组和 Slack 工作区——并基于他们与问题的接近程度，构建一个"先联系谁"的优先级框架。

What to ask / 该问什么

With your targets defined, use Claude to build the interview framework itself: the right questions, in the right order, structured to surface what people actually do rather than what they think they would do. A rookie founder mistake is asking a generic, open-ended question about the future ("would you use something like this?") instead of specifically querying the relevant past ("tell me about the last time you dealt with this problem.")

在目标确定后，用 Claude 来搭建访谈框架本身：以正确的顺序、问出正确的问题，其结构旨在浮现人们实际做了什么，而非他们以为自己会做什么。新手创始人常犯的错误，是问一个泛泛的、面向未来的开放式问题（"你会用这样的东西吗？"），而不是具体地探询相关的过去（"跟我说说你上一次处理这个问题是什么情况。"）

Claude can flag where your draft questions are leading the respondent, too broad, or otherwise likely to produce noise instead of signal. Claude can also help you in designing follow-up questions to probe deflections or drill down on vague answers to important questions.

Claude 能标出你草拟的问题里哪些在诱导受访者、哪些太宽泛，或哪些可能产出噪声而非信号。Claude 还能帮你设计追问，以探查回避之处，或针对重要问题里含糊的回答进一步深挖。

If your hypothesis involves more than one persona, Claude can also design different question sets for each. A finance manager and a CFO have different relationships to the same problem, and a single interview framework will flatten that distinction.

如果你的假设涉及不止一种用户画像，Claude 还能为每一种设计不同的问题集。财务经理和 CFO 与同一个问题的关系是不同的，而单一的访谈框架会抹平这种区别。

• Exercise: Draft your interview questions by hand first, ask Claude to audit them. Ask it specifically to flag any question that is leading, future-facing, too broad, or likely to produce a socially desirable answer rather than an honest one. Then ask it to suggest a follow-up probe for the two or three moments in the interview most likely to generate deflection.

• 练习： 先手写你的访谈问题，再让 Claude 审查它们。具体地让它标出任何具有诱导性、面向未来、过于宽泛，或可能产生"社会期许式回答"而非诚实回答的问题。然后让它针对访谈中最可能产生回避的两三个时刻，建议追问的方式。

Post-interview analysis / 访谈后分析

After each conversation, use Claude to debrief: feed it your notes and ask it to identify what confirmed your hypothesis, what challenged it, and what was genuinely surprising. Once you've gathered a batch of interviews, run your full set of interview notes through Claude Cowork to surface recurring themes, contradictions, and the strongest signals in both directions. Then take that synthesized output back to Claude and ask it to flag where your own read of the data might be pattern-matching to what you want to hear rather than what's actually there.

每次对话后，用 Claude 做复盘：把你的笔记喂给它，让它找出哪些印证了你的假设、哪些挑战了它，以及哪些是真正出人意料的。当你积累了一批访谈后，把全部访谈笔记跑一遍 Claude Cowork，浮现出反复出现的主题、矛盾之处，以及正反两个方向上最强的信号。然后把综合结果再带回给 Claude，让它标出：你对数据的解读，是否在"模式匹配"你想听到的，而非实际存在的。

• Exercise: After every five interviews, direct Claude Cowork to synthesize your notes and produce two lists: the evidence that supports your hypothesis, and the evidence that challenges it. If the first list is significantly longer than the second, ask Claude whether that asymmetry reflects what's actually in the data—or what you were hoping to find.

• 练习： 每做完五次访谈，就指挥 Claude Cowork 综合你的笔记，产出两份清单：支持你假设的证据，以及挑战它的证据。如果第一份清单明显比第二份长，就问 Claude：这种不对称反映的是数据里实际存在的，还是你希望找到的。

Customer outreach and scheduling / 客户触达与排期

Use Claude Cowork to automate the operational lift around building a contact list, running outreach, and scheduling user interviews.

用 Claude Cowork 来自动化围绕"建立联系人名单、开展触达、安排用户访谈"的运营负担。

Claude Cowork can use the target profile you defined with Claude (including job titles, company types, and seniority levels) to research and compile a structured list of prospects and verified contact information. It then drafts personalized outreach emails at scale, tailoring each one to the individual's role and context.

Claude Cowork 能利用你与 Claude 共同定义的目标画像（包括职位、公司类型和资历层级），去研究并编制一份结构化的潜在对象名单和已核实的联系方式。随后它会规模化地起草个性化触达邮件，针对每个人的角色与背景量身定制。

As responses come in, it connects to Gmail and Google Calendar via MCP to manage the thread, handle scheduling requests, and get interviews on the calendar. The rest of this playbook continues as Claude Cowork generates follow-up drafts on a defined cadence (a day-seven follow-up for contacts who haven't responded, for instance) and updates your tracking sheet as each step completes so you always know where every prospect stands in the pipeline.

当回复进来时，它通过 MCP 连接到 Gmail 和 Google Calendar 来管理邮件往来、处理排期请求，并把访谈安排进日历。接下来，Claude Cowork 会按照设定的节奏生成跟进草稿（例如对未回复的联系人在第七天发跟进邮件），并在每一步完成时更新你的追踪表，让你随时清楚每个潜在对象在管线中的状态。

• Exercise: Give Claude Cowork your validated interview target profile and ask it to build a prospect list, draft a personalized outreach sequence, and set up a tracking sheet with columns for outreach status, follow-up cadence, and interview completion. Then let it run the coordination while you focus on preparing for the conversations themselves.

• 练习： 把你已验证的访谈目标画像交给 Claude Cowork，让它构建潜在对象名单、起草个性化的触达序列，并建立一张追踪表，列出触达状态、跟进节奏和访谈完成情况等列。然后让它去跑协调工作，你则专注于准备对话本身。

Design your final solution concept / 设计你的最终方案构想

You've done the validation work: the problem is real, you know who has it, and you have a solution concept that the evidence supports. Use Claude to develop and challenge your solution concept from every angle: What are the gaps? What alternatives exist? What would have to be true for this solution to work at scale? This is an important reality checkpoint: does this design actually address the problem the validation process revealed, and not the problem you originally assumed going in?

你已经完成了验证工作：问题是真实的，你知道谁有这个问题，并且你有一个被证据支持的方案构想。用 Claude 从各个角度发展并挑战你的方案构想：缺口在哪里？存在哪些替代方案？要让这个方案在规模化时奏效，需要什么前提为真？这是一个重要的现实检查点：这个设计真正解决的，是验证过程揭示出的那个问题，还是你最初进场时假设的那个问题？

• Exercise: Present your solution concept to Claude and ask it to identify the three assumptions your design depends on most heavily. Then ask what would have to be true for each assumption to hold, and what the consequences are if any one of them doesn't.

• 练习： 把你的方案构想呈给 Claude，让它找出你的设计最依赖的三个假设。然后问：每个假设要成立需要什么前提为真，以及一旦其中任何一个不成立会带来什么后果。

Build a lightweight prototype with Claude Code / 用 Claude Code 构建轻量原型

Now for the fun part: with a validated hypothesis and a stress-tested solution concept, you're finally ready to build something.

现在到了有趣的部分：有了经过验证的假设和经过压力测试的方案构想，你终于准备好动手构建些东西了。

This is the moment in the Idea stage where Claude Code enters the picture. Even if you've been tinkering all along, now is the point where you generate your official lightweight prototype: the minimum surface area needed to put your idea in front of a real human and get a genuine reaction.

这是创意阶段中 Claude Code 登场的时刻。即便你一路上都在捣鼓，现在才是你生成正式轻量原型的节点：把你的想法摆到一个真实的人面前、并获得真实反应所需的最小界面。

You're not building a real-world product (yet); you're constructing a functional sample of your idea to use in customer and investor conversations. Real users reacting to something they can actually touch will tell you things that a dozen problem-solution discovery interviews couldn't. Before, you were establishing that the problem you're solving is real; now, you are asking potential users to engage with the proposed solution.

你（还）不是在构建一个真实世界的产品；你是在构建一个能运行的"想法样本"，用于客户和投资人对话。真实用户对一个他们能真正上手的东西所做出的反应，会告诉你十几次"问题—方案探索访谈"都问不出来的东西。之前，你是在确立你要解决的问题是真实的；现在，你是在请潜在用户与你提出的方案互动。

• Exercise: Define the single core interaction your solution depends on. Direct Claude Code to build only that. When you have it, put it in front of five people from your validated target profile and ask them to try it out. What you learn in those five conversations determines whether you keep building, or go back to the drawing board.

• 练习： 定义你的方案所依赖的那个唯一核心交互。指挥 Claude Code 只构建这一个。做出来后，把它摆到五位符合你已验证目标画像的人面前，请他们试用。你在这五次对话中学到的东西，决定了你是继续构建，还是回到起点重新设计。

Reaching the end of the Idea stage is a giant leap ahead in the AI startup race because now you're not betting on a hunch; you're executing against evidence. Now comes the MVP stage, where the founder's guiding question goes from "Is this worth building?" to "What exactly should we build first?" and AI's primary role shifts from research partner to construction crew.

走到创意阶段的终点，是 AI 创业竞赛中的一次巨大飞跃，因为此刻你不再是凭直觉下注；你是在依据证据执行。接下来是 MVP 阶段，创始人的指导性问题从"这值得构建吗？"变为"我们究竟应该先构建什么？"，而 AI 的主要角色也从研究伙伴转变为施工队。

第 4 章 · MVP Stage / MVP 阶段

Plenty of founders treat the MVP stage as a construction phase, but the MVP stage is still fundamentally an evidence-gathering exercise. The difference is that you are now gathering evidence about the solution instead of the problem space; specifically, whether a real, identifiable group of people finds it valuable enough to use it, return to it, pay for it, and/or tell others about it.

很多创始人把 MVP 阶段当作一个施工阶段，但 MVP 阶段本质上仍是一项收集证据的工作。区别在于：你现在收集的是关于"方案"的证据，而非"问题空间"的证据；具体而言，是验证一个真实、可识别的群体，是否觉得它有价值到愿意去使用、回访、付费，以及/或者推荐给他人。

MVP stage goals / MVP 阶段的目标

As the founder of an AI-native startup, your goal is to translate a validated problem into a working product that real users will actually use. This is not the full version with every roadmap feature but the smallest, most focused iteration of your idea that puts a real solution in front of real users and generates real evidence of product-market fit.

作为 AI 原生创业公司的创始人，你的目标是把一个已验证的问题转化为真实用户会实际使用的可用产品。这不是包含路线图上所有功能的完整版本，而是你想法中最小、最聚焦的迭代——它把一个真实的方案摆到真实用户面前，并产出关于产品—市场契合（product-market fit）的真实证据。

At the same time, how you build now determines what's possible later. This means that the MVP stage has a second, equally important goal of moving fast without accruing the type of technical debt that compounds–and will haunt you the moment real users arrive in meaningful numbers.

与此同时，你现在如何构建，决定了日后什么是可能的。这意味着 MVP 阶段还有第二个同样重要的目标：快速推进，同时不积累那种会复利式滚雪球的技术债——一旦真实用户以可观数量到来，它就会回来缠住你。

And finally, investing in persistent context from day one is what keeps AI a force multiplier instead of a source of entropy. In an AI-native startup, your codebase is something you collaborate with AI on session after session, which makes legibility foundational. Founders who skip specs, architectural decisions, and context files (like CLAUDE.md) hit a predictable wall where every new session requires re-explaining the codebase and AI-generated changes drift from the original vision.

最后，从第一天起就投资于持久化上下文，是让 AI 始终是"力量倍增器"而非"熵增之源"的关键。在 AI 原生创业公司里，你的代码库是你与 AI 一次次会话协作的对象，这使得"可读性"成为根基。那些跳过规格说明、架构决策和上下文文件（如 CLAUDE.md）的创始人，会撞上一堵可预见的墙：每次新会话都要重新讲解代码库，而 AI 生成的改动会偏离最初的愿景。

MVP stage exit criteria / MVP 阶段的退出标准

The MVP stage exit condition is genuine evidence of product-market fit: proof that a specific, identifiable group of users has found the product valuable enough to return to it (retention), pay for it (revenue), or tell others about it (referral).

MVP 阶段的退出条件，是产品—市场契合的真实证据：证明一个具体、可识别的用户群体，觉得产品有价值到愿意回访（留存）、付费（营收）或推荐给他人（转介）。

MVP stage challenges / MVP 阶段的挑战

In the MVP stage, a founder's prime directives are speed and judgment. The challenges here center on whether you can build the right thing, the right way, fast enough to matter, without cutting corners that will cost you later.

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

Agentic technical debt / 智能体式技术债

The challenge: Because AI essentially removes every natural bottleneck that once controlled what reaches production, speed is guaranteed. But when speed is the only variable that founders factor into their MVP build, they risk accruing technical debt they'll struggle to pay off.

挑战： 由于 AI 基本上移除了过去控制"什么能进入生产"的每一个自然瓶颈，速度是有保障的。但当速度成为创始人在 MVP 构建中考虑的唯一变量时，他们就有可能积累起难以偿还的技术债。

Some technical debt is appropriate at the MVP stage, with the understanding that it must be managed before scaling. It builds gradually and can be cleared over time or in a dedicated sprint. AI technical debt, however, compounds.

一些技术债在 MVP 阶段是合理的，前提是你明白它必须在规模化之前被管理。它逐渐累积，可以随时间推移或在专门的冲刺中清理。然而，AI 技术债是复利式增长的。

Without specs and architectural constraints written down somewhere the AI can read, each session re-derives foundational decisions from scratch, and those decisions drift. You end up with a codebase that has no coherent mental model behind it, not because any single piece is bad, but because the pieces were never designed to fit together. That's a real problem, and it does tend to surface late.

如果没有把规格说明和架构约束写在 AI 能读取的地方，每次会话都会从零重新推导那些基础性决策，而这些决策会发生漂移。你最终得到的代码库，背后没有一个连贯的心智模型——不是因为某一块写得差，而是因为这些块从一开始就不是为彼此契合而设计的。这是个实实在在的问题，而且它往往很晚才暴露出来。

Falling for false product-market fit / 误信虚假的产品—市场契合

The challenge: AI tools can generate impressive early numbers, but these are not a guarantee that the market needs your product.

挑战： AI 工具能生成亮眼的早期数据，但这些并不能保证市场需要你的产品。

Early momentum is one of the most psychologically powerful experiences a founder can have. After weeks or months of validation work and careful, disciplined building, shipping a product feels like confirmation that you were right all along.

早期势头是创始人能体验到的、心理上最具冲击力的事情之一。在数周或数月的验证工作和谨慎、自律的构建之后，交付一个产品感觉就像是在确认你一直都是对的。

Agentic coding tools can help you reach this moment faster than ever before, but early traction is not the same as product-market fit. Launch energy is generated from ephemeral forces, like your founder's friends, prospective buyers at your investor's other portfolio companies, or a Hacker News headline that drives a spike. Unfortunately, none of these reliably predicts what happens at week six or week twelve when that initial boost has faded.

智能体编程工具能帮你比以往更快到达这一刻，但早期牵引力并不等同于产品—市场契合。发布时的能量来自一些转瞬即逝的力量，比如创始人的朋友、你投资人旗下其他被投公司里的潜在买家，或者一条带来流量峰值的 Hacker News 头条。不幸的是，这些都无法可靠地预测：当最初的助推消退后，第六周或第十二周会发生什么。

Zero-friction scope creep / 零摩擦的范围蔓延

The challenge: When building feels effortless and is nearly free, there's always one more edge case to handle. This scope creep can do more harm than good.

挑战： 当构建感觉毫不费力、且几乎免费时，总有"再多一个边缘情况"要处理。这种范围蔓延弊大于利。

Scope creep has always been a startup risk. The difference now is that the traditional forcing function against it-the real cost of engineering time-no longer exists in the same way when adding a feature takes an afternoon instead of a sprint.

范围蔓延一直是创业的风险。如今的区别在于：当添加一个功能只需一个下午而非一个冲刺时，过去对抗它的那个强制约束——工程时间的真实成本——已不再以同样的方式存在。

The challenge here is that each individual addition is defensible. Of course the product should handle that edge case; of course users will want that workflow. These don't feel like scope creep in the moment because each one takes so little effort to build with agentic coding, but as your product sprawls beyond its original boundaries you risk losing direction and momentum.

这里的挑战在于：每一项单独的新增都说得过去。当然产品应该处理那个边缘情况；当然用户会想要那个工作流。当下它们都不像是范围蔓延，因为用智能体编程构建每一个都只需极少的力气；但随着你的产品蔓延到超出最初边界，你就有可能失去方向和势头。

The antidote is a written scope definition created before building begins, describing what the product does, what it deliberately does not do, and the specific evidence from real users that would justify adding something new. This moves the decision point from "should we build this?" to "a critical mass of users have told us they can't get value from the product without this?"

解药是在构建开始之前就写好一份范围定义，描述产品做什么、刻意不做什么，以及哪些来自真实用户的具体证据才能证明值得新增某项功能。这把决策点从"我们该构建这个吗？"变成了"是否有足够多的用户告诉我们，没有这个他们就无法从产品中获得价值？"

Insecure by inexperience / 因经验不足而不安全

The challenge: Founders using AI tools to rush applications to market without first understanding fundamental security principles end up exposing their users to preventable risks.

挑战： 那些用 AI 工具仓促把应用推向市场、却没有先理解基本安全原则的创始人，最终会让用户暴露于本可避免的风险之中。

The hard truth is that agentic coding tools generate code that works, not code that is inherently secure. Functional code is easy, because either the feature works or it doesn't. Security vulnerabilities are invisible until they're exploited, which means there's no natural feedback loop to alert a first-time founder that something is wrong. Shipping a live MVP to real users, however, means real data, real exposure, and real consequences if something goes wrong.

残酷的真相是：智能体编程工具生成的是"能运行"的代码，而不是"天生安全"的代码。功能性代码很容易判断，因为功能要么能用、要么不能用。而安全漏洞在被利用之前是隐形的，这意味着没有一个自然的反馈回路来提醒初次创业者出了问题。然而，把一个上线的 MVP 交付给真实用户，意味着真实的数据、真实的暴露面，以及一旦出错就真实的后果。

Slighting security isn't brand new to AI-native projects. Bootstrapped startups in every era often delayed security considerations until late in the build, sometimes waiting until the verge of production launch. A security review before any user touches your app or solution is the minimum responsible threshold for releasing a minimum viable product into the world.

轻视安全并非 AI 原生项目独有的新问题。各个时代的自筹资金创业公司，常常把安全考量拖到构建后期，有时甚至拖到临近生产上线。在任何用户接触你的应用或方案之前先做一次安全审查，是把一个最小可行产品发布到世界上的最低负责任门槛。

How Claude can help MVP stage founders / Claude 如何帮助 MVP 阶段的创始人

Define your architecture before you build / 在构建之前先定义你的架构

Before Claude Code writes a line of production code, use Claude to define and document the architectural decisions that will govern everything built in this stage: the patterns to follow, the dependencies to avoid, the tradeoffs being made and why. This output will serve as a focused architectural context document and establish the guardrails that Claude Code will operate inside.

在 Claude Code 写下第一行生产代码之前，先用 Claude 来定义并记录将主导本阶段一切构建的架构决策：要遵循的模式、要避免的依赖、正在做的取舍及其原因。这份产出将作为一份聚焦的架构上下文文档，并确立 Claude Code 在其中运作的护栏。

Without this context, each session starts from scratch and Claude Code is forced to infer its own structural assumptions. Letting Claude Code build without guardrails produces a codebase that will be functional but structurally incoherent, and iterating on and scaling incoherent codebases is ultimately a waste of time and tokens. Sooner or later there's a point where the code inevitably collapses, forcing you to rebuild from scratch.

没有这份上下文，每次会话都从零开始，Claude Code 被迫去推断它自己的结构性假设。让 Claude Code 在没有护栏的情况下构建，会产出一个"能用但结构不连贯"的代码库；而在不连贯的代码库上迭代和规模化，最终是在浪费时间和 token。迟早会到一个点，代码不可避免地崩塌，逼你从头重建。

• Exercise: Before opening Claude Code, open Claude and describe what you're building: the core problem it solves, the users it serves, and the scale you realistically expect in the next six months. Ask it to help you define the architectural principles that should govern your MVP build, the dependencies to avoid given your constraints, and the tradeoffs you're consciously accepting at this stage.

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

Next, save this output as CLAUDE.md markdown file(s). This is your architectural context document: the first artifact of your build, and the one every subsequent session depends on. CLAUDE.md files serve as project-level instructions for Claude Code, providing project-specific context and instructions that are automatically read by the Agent SDK when it runs in a directory. Functionally, they are persistent "memory" for your project.

接着，把这份产出保存为 CLAUDE.md markdown 文件。这就是你的架构上下文文档：你这次构建的第一个产物，也是之后每次会话都依赖的产物。CLAUDE.md 文件充当 Claude Code 的项目级指令，提供特定于项目的上下文与指示，当 Agent SDK 在某个目录中运行时会自动读取它们。从功能上看，它们就是你项目的持久化"记忆"。

Define and enforce your MVP scope / 定义并执行你的 MVP 范围

Scope creep without friction is one of the defining failure modes of AI-era MVPs. Just as you defined and documented your product's application architecture, you also need to define your MVP's scope before a single feature gets built.

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

Claude can help you create a scope document that describes what your MVP product does, what it deliberately does not do, and feature amendment criteria: what specific evidence from real users would justify adding something new at this point.

Claude 能帮你创建一份范围文档，描述你的 MVP 产品做什么、刻意不做什么，以及功能新增标准：在现阶段，哪些来自真实用户的具体证据才能证明值得新增某项功能。

When new feature ideas surface—and they surely will—you use Claude to pressure-test whether it's genuine signal from users or founder enthusiasm dressed up as product thinking.

当新功能想法浮现时——它们一定会浮现——你用 Claude 来压力测试：它究竟是来自用户的真实信号，还是被包装成"产品思考"的创始人热情。

Build your MVP with Claude Code / 用 Claude Code 构建你的 MVP

Once architecture and scope are defined, Claude Code becomes the primary MVP build tool. Use it to generate, test, debug, and iterate on your codebase, but treat each session as an execution of product decisions you have already made, not as an opportunity to throw in some new ones.

一旦架构和范围确定，Claude Code 就成了主要的 MVP 构建工具。用它来生成、测试、调试并迭代你的代码库，但要把每次会话都当作"执行你已经做出的产品决策"，而不是"塞进一些新决策"的机会。

Start each Claude Code session by (1) revisiting your scope document and (2) providing the model with your CLAUDE.md architectural context document. End each session by updating it with any decisions the session surfaced. The goal is a codebase whose structure you can explain, not just a codebase that runs.

每次 Claude Code 会话开始时，要 (1) 回顾你的范围文档，并 (2) 把你的 CLAUDE.md 架构上下文文档提供给模型。每次会话结束时，用这次会话中浮现的任何决策来更新它。目标是一个"你能解释其结构"的代码库，而不仅仅是一个"能跑"的代码库。

• Exercise: Create a simple session template for your Claude Code work that includes the architectural context document, the specific task for this session, and any constraints or patterns to observe. At the end of each session, add a brief log entry to the context document that details what was built, what decisions were made, and what assumptions the session introduced. Five minutes of documentation per session is cheap insurance against architectural drift that compounds into an unmanageable codebase.

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

Security review before any user touches it / 在任何用户接触之前做安全审查

As an AI-native startup founder, your responsibility is to know what's in your codebase, understand any potential exposure vectors, and not ship obvious vulnerabilities to real users who are trusting you with their data.

作为 AI 原生创业公司的创始人，你的责任是：清楚你的代码库里有什么、理解任何潜在的暴露途径，并且不把明显的漏洞交付给那些把数据托付给你的真实用户。

Claude can do a useful first-pass security review of AI-generated code and can help identify common vulnerabilities. It's a good habit to build into the loop before shipping. It is not a substitute for security tooling, however, or, at higher stakes, a human reviewer—and founders who treat it as one are the ones who end up in the breach stories.

Claude 能对 AI 生成的代码做一次有用的初步安全审查，并帮你识别常见漏洞。把它作为交付前的一个固定环节是个好习惯。但它不能替代专门的安全工具，在更高风险场景下也不能替代人工审查者——把它当作替代品的创始人，最终会成为"数据泄露故事"里的主角。

Claude Code Security goes further: it scans codebases for security vulnerabilities and suggests targeted patches for human review, surfacing issues that traditional methods can miss.

Claude Code Security 走得更远：它扫描代码库以查找安全漏洞，并建议有针对性的补丁供人工审查，浮现出传统方法可能遗漏的问题。

Note: At the time of this ebook's publication, Claude Code Security is a limited beta release so check current availability before building it into your workflow.

注： 在本电子书发布时，Claude Code Security 还是限量测试版，因此在把它纳入工作流之前请先确认当前可用情况。

• Exercise: Before deploying to any real users, run your core application code through Claude with a specific brief: review for authentication and session handling, data exposure in API responses, input validation and injection risks, and dependencies with known vulnerabilities. Treat each finding seriously and assess whether it requires a fix, with human review for anything that touches authentication, secrets, or data handling.

• 练习： 在部署给任何真实用户之前，把你的核心应用代码喂给 Claude，并给出明确任务：审查身份验证与会话处理、API 响应中的数据暴露、输入校验与注入风险，以及含已知漏洞的依赖。认真对待每一个发现，评估它是否需要修复；对于任何涉及身份验证、密钥或数据处理的内容，都要有人工审查。

Build your measurement framework before launch / 在发布之前构建你的度量框架

The founders who mis-identify early traction as product-market fit are typically the same ones who started tracking data after launch, using metrics chosen to assess what was working rather than to surface what wasn't. The antidote is to establish your measurement framework before the first user shows up.

那些把早期牵引力误判为产品—市场契合的创始人，通常正是那些发布之后才开始追踪数据的人——他们选用的指标是为了评估"什么在奏效"，而不是为了浮现"什么没奏效"。解药是在第一位用户出现之前就建立好你的度量框架。

Use Claude to define which metrics matter for your specific product, what the benchmarks are, and what patterns in the data would constitute genuine product-market fit versus flattering noise. Specifically: set your retention benchmarks, your activation criteria, and your Day 7 and Day 30 targets before releasing your MVP.

用 Claude 来定义：对你的具体产品而言哪些指标重要、基准值是多少，以及数据中的哪些模式构成真正的产品—市场契合、而非自我安慰式的噪声。具体而言：在发布你的 MVP 之前，先设定好你的留存基准、激活标准，以及第 7 天和第 30 天的目标。

Next, define what a false positive looks like for your specific product: signups without activation, revenue without retention, or initial enthusiasm without repeat usage, for example. When the data arrives, ask Claude to make the adversarial case against your own traction: what would a skeptic say about these numbers?

接着，定义对你的具体产品而言"假阳性"长什么样：例如，有注册却无激活、有营收却无留存，或有最初的热情却无重复使用。当数据到来时，让 Claude 对你自己的牵引力提出反方论证：一个怀疑者会怎么评价这些数字？

Manage discovery and user feedback logistics / 管理探索与用户反馈的事务工作

Once real users are in the product, the operational layer expands fast. Claude Cowork handles the important-but-tedious work like building and maintaining user contact lists, running outreach sequences, scheduling feedback sessions, triaging bug reports, and tracking iteration cycles. The same MCP integrations that managed discovery logistics in the Idea stage apply here.

一旦真实用户进入产品，运营层会迅速膨胀。Claude Cowork 处理那些"重要但繁琐"的工作，比如建立和维护用户联系人名单、运行触达序列、安排反馈会话、分类处理 bug 报告，以及追踪迭代周期。在创意阶段用于管理探索事务的那些 MCP 集成，在这里同样适用。

Keep a human in the collection loop for nuanced exploration of user feedback. A user saying, for example, "this is great but I wish it could also...," requires interpretation: Is it a core need or a nice-to-have? Is it specific to this customer or representative of a segment? Is the missing feature the real problem, or is something upstream in the onboarding? No tool can answer those questions.

在收集环节保留一个真人，用于对用户反馈做细致入微的探查。比如一个用户说"这很棒，但我希望它还能……"，这需要解读：这是核心需求还是"锦上添花"？它是这个客户特有的，还是代表了某个用户群体？缺失的功能是真正的问题，还是上游的引导（onboarding）出了问题？没有工具能回答这些问题。

• Exercise: Configure Claude Cowork to run your MVP-stage feedback loop: draft outreach to your early user list, schedule feedback sessions, design structured intake process for bug reports and feature requests, and write up a weekly synthesis of what's come in. Review the synthesis yourself; after that, you can ask Claude to analyze the information to catch any significant points you may have overlooked.

• 练习： 配置 Claude Cowork 来运行你的 MVP 阶段反馈回路：起草对早期用户名单的触达、安排反馈会话、为 bug 报告和功能请求设计结构化的接收流程，并撰写每周一次的汇总。汇总由你亲自审阅；之后，你可以让 Claude 分析这些信息，以捕捉任何你可能忽略的重要点。

Iterate toward evidence, not toward completeness / 朝着证据迭代，而非朝着"完整"迭代

The MVP stage ends when you have genuine evidence of product-market fit, no matter how "finished" the product feels. Declaring that you've achieved product-market fit and are now ready to move on from the MVP phase to the Launch stage is ultimately a judgement exercise that combines founder intuition with collected evidence. There are some useful litmus tests, though:

MVP 阶段在你拥有产品—市场契合的真实证据时结束，无论产品感觉上有多"完整"。宣布你已实现产品—市场契合、并准备从 MVP 阶段进入发布阶段，最终是一项把创始人直觉与所收集证据相结合的判断。不过，有一些有用的试金石：

• The Sean Ellis test: Ask your active users: "How would you feel if you could no longer use this product?" If more than 40% answer "very disappointed," that's a meaningful PMF indicator.
• The effort test: Pre-product-market fit, retention requires constant intervention, including frequent outreach, incentives, personal follow-up, and a heroic founder energy expended to keep users engaged. Post product-market fit, the product starts doing that work on its own. When things begin pulling instead of pushing, that shift is one of the clearest signals that something real has changed.

• Sean Ellis 测试： 问你的活跃用户："如果你再也不能使用这个产品，你会作何感受？"如果超过 40% 的人回答"非常失望"，那是一个有意义的 PMF（产品—市场契合）指标。
• 努力程度测试： 在产品—市场契合之前，留存需要持续的干预，包括频繁触达、激励、人工跟进，以及创始人为维持用户参与而付出的英雄式精力。在产品—市场契合之后，产品开始自己完成这项工作。当事情开始从"推"变成"拉"时，这种转变是"某件真实的事情已经改变"的最清晰信号之一。

Ultimately, no single data point confirms product-market fit because it's a pattern that has to hold across multiple iteration cycles before you can definitively call it.

归根结底，没有任何单一数据点能确认产品—市场契合，因为它是一种必须在多个迭代周期中持续成立的模式——之后你才能确定地下结论。

Pivot when the evidence demands it / 当证据要求时就转向

What if, even after investing all this work, you just can't seem to arrive at product-market fit? The fact that your results don't confirm the direction you started from is not failure, it's the system working: the MVP stage is designed to surface this information before you over-invest in the wrong answer.

如果在投入了所有这些努力之后，你似乎就是无法达到产品—市场契合，怎么办？你的结果没有印证你出发时的方向，这并非失败，而是系统在正常运转：MVP 阶段的设计初衷，就是在你过度投资于错误答案之前把这一信息浮现出来。

When the data doesn't support your current product, use Claude to work through what that data is telling you.

当数据不支持你当前的产品时，用 Claude 来梳理这些数据在告诉你什么。

• Exploring alternative customer segments. Perhaps the users who aren't converting were never the right target to begin with. Often the right audience is already in your data, just underweighted.
• Adjusting your product's value prop. Maybe you have the correct audience but your MVP is just not resonating with users. An adjustment to onboarding, messaging, or core feature emphasis can potentially fix this without changing what you've built.

• 探索其他客户群体。 也许那些没有转化的用户，从一开始就不是正确的目标。正确的受众往往已经在你的数据里，只是被低估了。
• 调整你产品的价值主张。 也许你的受众是对的，只是你的 MVP 没能与用户产生共鸣。对引导、信息传达或核心功能侧重点的调整，有可能在不改变你已构建之物的前提下解决这个问题。

Stay open to the possibility that the disconnect may run deep enough to require a more fundamental change

也要对一种可能性保持开放：这种脱节可能深到需要一次更根本性的改变。

• Exercise: If you've completed three or more iteration cycles without meaningful movement toward your product-market fit benchmarks, use Claude to run a diagnostic before deciding what to do next. Feed it your retention data, your user feedback, and your original problem hypothesis, and ask it three questions:
  • Is there a segment in this data responding differently than the rest?
  • Is the gap between designed value and experienced value a positioning problem or a product problem?
  • What would have to be true for the current product to find genuine PMF, and is that scenario realistic given what you're seeing?

• 练习： 如果你已经完成三个或更多迭代周期，却仍未朝产品—市场契合基准取得有意义的进展，在决定下一步做什么之前，用 Claude 跑一次诊断。把你的留存数据、用户反馈和最初的问题假设喂给它，并问它三个问题：
  • 这份数据里是否有某个群体的反应与其余群体不同？
  • "设计价值"与"体验价值"之间的差距，是定位问题还是产品问题？
  • 要让当前产品找到真正的 PMF，需要什么前提为真？而根据你所看到的情况，那种情景现实吗？

Let the answers determine whether you adjust, pivot, or return to the Idea stage.

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

第 5 章 · Launch stage / 发布阶段

If the MVP stage was about proving your product deserves to exist, the Launch stage is about proving your business deserves to grow.

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

Launch stage goals / 发布阶段的目标

In the Launch stage, startup founders must turn early traction into a repeatable, sustainable growth engine. Beyond making your product production-ready, you also must harden the infrastructure underneath while simultaneously building an actual company around your product.

在发布阶段，创业者必须把早期牵引力转化为一台可重复、可持续的增长引擎。除了让你的产品达到生产就绪，你还必须加固底层基础设施，同时围绕你的产品构建一家真正的公司。

Startups are naturally founder-centric during the Idea and MVP stages because you need the full situational awareness and tight feedback loops. Now, though, founders who still try to personally hold every thread become a Launch stage bottleneck. The goal isn't to remove yourself from the company, but to build operational systems that free your attention for the decisions only a founder can make.

在创意和 MVP 阶段，创业公司天然以创始人为中心，因为你需要完整的态势感知和紧密的反馈回路。但现在，仍试图亲手抓住每一根线头的创始人，会成为发布阶段的瓶颈。目标不是把你自己从公司里抽离，而是构建能释放你注意力的运营系统，让你专注于只有创始人才能做的决策。

Launch stage exit criteria / 发布阶段的退出标准

The Launch stage exit condition has three elements:

发布阶段的退出条件有三个要素：

1. Growth is repeatable and channel-driven. You're not just retaining users, you're acquiring them predictably through specific channels with understood unit economics: CAC, LTV, and payback period are numbers you know and can defend.
2. The product can handle production workloads. Infrastructure is hardened, security and compliance are in order, and reliability holds under real production conditions (not just the conditions you tested for).
3. Operations run without founder bottlenecks. Processes exist and automation is in place. You are no longer the person personally handling support, triage, sprint planning, or reporting.

1. 增长是可重复且由渠道驱动的。 你不只是在留住用户，而是通过具体渠道以可预测的方式获取他们，且单位经济模型清晰：CAC（获客成本）、LTV（生命周期价值）和回本周期，都是你了然于心、能站得住脚的数字。
2. 产品能承受生产负载。 基础设施已加固，安全与合规就位，且在真实生产条件下（而不只是你测试过的条件下）可靠性依旧稳固。
3. 运营在没有创始人瓶颈的情况下运转。 流程已建立、自动化已就位。你不再是那个亲自处理客服、分类、冲刺规划或报表的人。

Launch stage challenges / 发布阶段的挑战

Finding product-market fit is the hardest problem in the early startup lifecycle. Now, the founder's challenge becomes keeping it. The Launch stage is where companies that found real product traction may still fall apart if the organization that surrounds and supports the product can't keep up. These are the failure modes to watch for.

找到产品—市场契合是早期创业生命周期中最难的问题。如今，创始人的挑战变成了"保住它"。发布阶段是这样一个地方：那些找到了真实产品牵引力的公司，如果围绕并支撑产品的组织跟不上，仍然可能崩解。以下是需要警惕的失败模式。

Technical debt comes due / 技术债到期了

The challenge: The MVP codebase built for speed and validation ran well enough to prove the product worked, but production traffic, new features, and growing complexity are now exposing the shortcuts.

挑战： 那个为速度和验证而构建的 MVP 代码库，运行得足以证明产品可行；但生产流量、新功能和不断增长的复杂度，如今正把那些走过的捷径暴露出来。

At MVP, accumulating some technical debt was a reasonable tradeoff for velocity. In the Launch phase, that debt starts accruing interest, and the longer it goes unaddressed, the more expensive it is to fix.

在 MVP 阶段，积累一些技术债是为换取速度而做的合理取舍。在发布阶段，这笔债开始计息，而拖得越久不处理，修复成本就越高。

The solution consists of a systematic architectural audit to identify structural weaknesses, targeted refactoring to address the worst of them, and a meaningful expansion of test coverage so that the next round of feature work doesn't reintroduce the same problems.

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

The founder becomes the bottleneck / 创始人成为瓶颈

The challenge: At MVP, the founder being in every loop was an asset. At Launch, as support volume grows, product decisions stack up, and operational complexity multiplies, that same instinct becomes the constraint.

挑战： 在 MVP 阶段，创始人身处每一个环路之中是一种资产。到了发布阶段，随着客服量增长、产品决策堆积、运营复杂度倍增，同样的本能就变成了约束。

The transition from doing the work to designing the systems that do the work is one of the hardest shifts in the startup lifecycle. Because there's rarely a clear moment when it happens, the risk is to miss it entirely and stay in builder mode while the organization stalls around you. Telltale signs that this is happening include decisions that should take an hour now take a week for you to get around to them, support requests that pile up because only you know the answer, and operational tasks that only happen when you personally remember to do them.

从"亲自做工作"到"设计能做工作的系统"，这一过渡是创业生命周期中最艰难的转变之一。由于很少有一个清晰的时刻标志它的发生，风险在于你完全错过它、继续停留在"构建者模式"，而组织在你周围陷入停滞。这种情况正在发生的迹象包括：本该一小时搞定的决策，现在要拖一周你才腾出手；客服请求堆积如山，因为只有你知道答案；以及那些只有在你亲自想起来时才会发生的运营任务。

The remedy is an all-out audit of everything you're personally handling, from the tiniest task to the most high-stakes decisions, in order to identify what can be systematized, what can be delegated, and what genuinely still merits founder time and attention.

解药是对你亲自处理的一切——从最微小的任务到最高风险的决策——做一次全面审计，以识别哪些可以系统化、哪些可以委派，以及哪些真正仍然值得创始人投入时间与注意力。

Security and compliance are no longer deferrable / 安全与合规不再可以拖延

The challenge: Keeping security and compliance measures simple was OK for MVP but now, with real users, real data, and potentially enterprise contracts on the table, it becomes a liability.

挑战： 在 MVP 阶段把安全与合规措施保持简单是可以的，但现在有了真实用户、真实数据，以及可能摆上桌面的企业合同，简单就变成了一种负债。

At MVP, with a handful of beta users and no sensitive data in production, security vulnerabilities were theoretical risks. The hypothetical, however, becomes very real exposure risk the moment your product enters production with real users depending on it. Furthermore, compliance requirements that didn't apply to a prototype definitely apply the moment you're handling customer data, processing payments, or selling into regulated industries.

在 MVP 阶段，只有少数测试用户、生产环境里没有敏感数据时，安全漏洞还只是理论风险。然而，一旦你的产品进入生产、有真实用户依赖它，这个"假设"就变成了非常真实的暴露风险。此外，那些不适用于原型的合规要求，在你开始处理客户数据、处理支付，或向受监管行业销售的那一刻，就一定会适用。

The remedy is a systematic security and compliance review before production scale arrives, not after, and treat everything that surfaces as a required remediation—not a suggestion—before the next wave of users arrives.

解药是在生产规模到来之前（而非之后）做一次系统性的安全与合规审查，并把浮现出的一切都当作"必须修复项"——而非"建议"——在下一波用户到来之前处理掉。

Expansion before you're ready / 在你准备好之前就扩张

The challenge: New markets and funding opportunities look like growth opportunities. They can also be where product-market fit goes to die.

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

The initial traction you've built is real, but it's also specific to your early audience. Expanding too early into a market that's meaningfully different from your original one introduces new user behaviors, compliance requirements, payment infrastructure, and baseline expectations that your product wasn't designed around. Suddenly there are too many new variables and you lose the ability to interpret your own data clearly. You also run the risk of neglecting your original user base while chasing a new and unproven audience.

你建立起的最初牵引力是真实的，但它也是特定于你早期受众的。过早扩张进入一个与你原有市场存在显著差异的市场，会引入新的用户行为、合规要求、支付基础设施，以及你的产品并非围绕其设计的基准期望。突然之间，新变量太多，你失去了清晰解读自己数据的能力。你还会冒一种风险：在追逐一个全新且未经验证的受众时，忽视了你原有的用户群体。

How Claude can help Launch stage founders / Claude 如何帮助发布阶段的创始人

All three forms of Claude are in full use in the Launch stage, and they support each other: each tool produces outputs that become inputs for the other two. The results compound organically, and a founder using all three tools together gets more than the sum of their parts.

在发布阶段，Claude 的三种形态都被充分使用，并且彼此支撑：每个工具产出的结果，都会成为另外两个工具的输入。这些结果会有机地复利叠加，而一个同时使用这三种工具的创始人，得到的将超过各部分之和。

This is what makes the ultra-lean startup model structurally possible. When Claude Code builds the product, Claude Cowork builds the company around it, and Claude helps operationalize this product and organizational knowledge, a small team can run like a company nx its size.

这正是超精简创业模式在结构上得以可能的原因。当 Claude Code 构建产品、Claude Cowork 围绕它构建公司、Claude 帮助把产品与组织知识落地运营时，一个小团队就能像一家规模是其 n 倍的公司那样运转。

Remediate technical debt before it compounds / 在技术债复利之前修复它

Your MVP codebase works, but it also needs a systematic remediation pass in search of any technical debt that could become a structural liability.

你的 MVP 代码库能用，但它也需要一次系统性的修复，以排查任何可能演变为结构性负债的技术债。

First, use Claude Code to run a full architectural audit: identify where the codebase is brittle, any shortcuts that will become more expensive to maintain, and where test coverage is thin enough that the next round of feature work will reintroduce the same problems.

首先，用 Claude Code 做一次完整的架构审计：识别代码库哪里脆弱、哪些捷径日后维护起来会更昂贵，以及哪里的测试覆盖率薄到下一轮功能工作会重新引入同样的问题。

Feed Claude Code's audit findings back to Claude to triage and sequence the remediation work: what needs to be fixed before the next release, what can wait a sprint, and what represents acceptable ongoing debt given your current stage. This is also the moment to document the architectural decisions you made during the MVP stage (the ones that lived in your head because there was no time to write them down). Getting them into a CLAUDE.md now ensures that every future Claude Code session starts from a shared understanding of how the system was designed and why.

把 Claude Code 的审计发现反馈给 Claude，以对修复工作进行分类和排序：哪些必须在下次发布前修复、哪些可以等一个冲刺、哪些在你当前阶段属于可接受的持续性债务。这也是把你在 MVP 阶段做出的架构决策（那些因为没时间写下来而只存在于你脑子里的决策）记录下来的时刻。现在把它们写进一份 CLAUDE.md，能确保未来每一次 Claude Code 会话，都从"对系统如何设计、为何如此设计的共同理解"出发。

• Exercise: Direct Claude Code to audit your MVP codebase and produce a prioritized list of structural weaknesses, test coverage gaps, and refactoring candidates. Then feed that list to Claude and ask it to sequence the remediation work across your several sprints: any significant issues that you need to address first, things that can be handled in parallel with feature development, and things that can wait.

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

Build the systems that replace founder attention / 构建取代创始人注意力的系统

Building the operational systems that free your attention to handle responsibilities only the founder can tackle requires knowing exactly where your attention is going. Use Claude Cowork to run a structured audit of your current operational load, documenting every recurring task, every decision that lands on your desk, and every workflow that only happens because you personally remember to do it. Then have Claude Cowork categorize this inventory into what can be automated entirely, what needs a human but not necessarily you, and what genuinely requires founder judgment.

构建那些"释放你注意力、好让你去处理只有创始人才能解决的责任"的运营系统，前提是你要确切知道你的注意力都流向了哪里。用 Claude Cowork 对你当前的运营负载做一次结构化审计，记录每一项重复性任务、每一个落到你桌上的决策，以及每一个只因你亲自记得才会发生的工作流。然后让 Claude Cowork 把这份清单分类为：可以完全自动化的、需要真人但不一定是你的、以及真正需要创始人判断的。

Once the audit is complete, use Claude Cowork to design the workflow logic for the automation candidates: what triggers each workflow, what the decision rules are, what the output looks like, and where it goes when it's done.

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

Make security and compliance a product workstream / 让安全与合规成为一条产品工作流

Use Claude Code to surface code-level issues that frequently come up in SOC 2, GDPR, or HIPAA audits and standards that your target market requires. This will surface both vulnerabilities and compliance gaps. Feed those findings to Claude to help you prioritize the remediation work and design the controls, audit logging, and access management that enterprise buyers will ask for before they sign. Note: AI scans are an aid but not a substitute for qualified compliance review.

用 Claude Code 浮现出那些在 SOC 2、GDPR 或 HIPAA 审计中、以及你目标市场所要求的标准中频繁出现的代码级问题。这会同时浮现出漏洞和合规缺口。把这些发现喂给 Claude，帮你对修复工作排定优先级，并设计企业买家在签约前会要求的控制措施、审计日志和访问管理。注： AI 扫描是一种辅助，但不能替代合格的合规审查。

Next, build the compliance workstream into your development cycle rather than running it as a one-time project; compliance documentation needs to be continually maintained and updated. For founders approaching enterprise contracts or international markets, this is also the moment where the Claude Code security scan can help you prepare for an independent security assessment.

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

• Exercise: Run a code-level security review with Claude Code oriented to the frameworks your target market requires. Feed the output to Claude and ask it to produce two things: a prioritized security remediation sequence and a list of the documentation and controls you'll need to produce to satisfy a compliance review from a prospective enterprise buyer.

• 练习： 用 Claude Code 做一次面向你目标市场所要求框架的代码级安全审查。把输出喂给 Claude，让它产出两样东西：一份按优先级排序的安全修复序列，以及一份"为满足潜在企业买家的合规审查、你需要产出的文档与控制措施"清单。

Stand up the product management processes you've been skipping / 把你一直跳过的产品管理流程建立起来

The Launch stage requires a set of lightweight, repeatable processes that can run without requiring founder intervention to trigger or function. Use Claude to design how your product timeline and work cycles will be structured, what a spec needs to include before Claude Code touches a feature, how bug reports get triaged and routed, and what your weekly metrics report covers and how it's distributed.

发布阶段需要一套轻量、可重复的流程，它们的触发和运行无需创始人介入。用 Claude 来设计：你的产品时间线和工作周期将如何组织、在 Claude Code 着手一个功能之前一份规格说明需要包含什么、bug 报告如何被分类和路由，以及你的每周指标报告涵盖什么、如何分发。

Once process design is done, use Claude Cowork to build and run the operational layer: scheduling sprint ceremonies, routing incoming bug reports to the right place, compiling weekly metrics from your connected data sources, and maintaining the feedback loop that keeps user signals flowing into product decisions.

流程设计完成后，用 Claude Cowork 来构建并运行这个运营层：安排冲刺仪式、把进来的 bug 报告路由到正确的地方、从你连接的数据源汇编每周指标，并维护那个让用户信号持续流入产品决策的反馈回路。

• Exercise: Ask Claude to design a lightweight product management operating system: a defined sprint cadence, a minimum spec template, a bug triage decision tree, and a weekly metrics brief that pulls from your actual data sources. Then set up Claude Cowork to implement and run the system's recurring operational elements, like scheduling, routing, and report compilation, to happen on schedule without you.

• 练习： 让 Claude 设计一套轻量的产品管理操作系统：明确的冲刺节奏、一份最小规格模板、一棵 bug 分类决策树，以及一份从你真实数据源拉取的每周指标简报。然后设置 Claude Cowork 来实现并运行该系统的重复性运营要素，比如排期、路由和报表汇编，使其按计划自动发生、无需你参与。

第 6 章 · Scale stage / 规模化阶段

During the Scale phase, the founder's role re-centers from builder to public-facing executive. The product is still central, but your personal day-to-day work becomes increasingly about the company itself. Your attention must expand to new Scale-stage activities like analyst briefings and IPO roadshows even as you strive to maintain the lean, AI-centered structural advantage.

在规模化阶段，创始人的角色从"构建者"重新转向"面向公众的高管"。产品仍是核心，但你个人的日常工作越来越多地围绕公司本身。你的注意力必须扩展到新的规模化阶段活动，比如分析师简报和 IPO 路演——即便你仍努力维持那种精简、以 AI 为中心的结构性优势。

Scale stage goals / 规模化阶段的目标

The work of scaling technical infrastructure keeps on going, and is now joined by the work of scaling the organization itself and maturing it into a business.

扩展技术基础设施的工作仍在继续，如今还加入了扩展组织本身、并把它培育成一门成熟生意的工作。

At the scale stage you're looking at going from thousands of users to millions, and from one market to many. At every prior stage, growth was something you could feel your way through by being close to users and adjusting course based on data from tight feedback loops plus a healthy dose of founder instinct. Now, though, the goal is to build systematic growth that's sustained by mature organizational operations.

在规模化阶段，你面对的是从数千用户增长到数百万、从一个市场扩展到多个市场。在此前的每个阶段，增长都是你可以"摸着石头过河"的东西——靠贴近用户、根据紧密反馈回路的数据调整方向，再加上相当份量的创始人直觉。但现在，目标是构建系统化的增长，并由成熟的组织运营来维持它。

For an AI-native startup, your goal should be to build a defensible moat through accumulated depth, stemming from the expertise you've built into your product, your product's depth of integration with the other tools and platforms your users rely on, and the proprietary system data and workflows. The founders who've been building consistently in one direction, on consistent infrastructure, now have something genuinely hard to replicate.

对于 AI 原生创业公司，你的目标应该是通过积累的深度构建一条可防御的护城河——它源自你注入产品的专长、你的产品与用户所依赖的其他工具和平台的集成深度，以及专有的系统数据和工作流。那些在一个方向上、在一致的基础设施上持续构建的创始人，如今拥有了真正难以复制的东西。

At this stage, public investors, analysts, regulators, enterprise procurement teams, and acquirers apply greater pressure–along with greater skepticism–because the stakes are higher now. Your product and org have to withstand external scrutiny: not just the capabilities of what you've built, but the governance, compliance posture, financial controls, and strategic narrative that surround it.

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

Scale stage exit criteria / 规模化阶段的退出标准

The exit condition at Scale is no longer a single milestone but a threshold event: the company is sustainable even as the founder is, increasingly, not directly running day-to-day operations. You've demonstrated systematic growth; built organizational governance and compliance infrastructure that satisfies the most demanding external reviewers; and have a solid answer to the question, "If a well-funded incumbent copied your product today, would your users stay?"

规模化阶段的退出条件，不再是单一里程碑，而是一个阈值事件：即便创始人越来越多地不再直接管理日常运营，公司依然可持续。你已经展示了系统化的增长；建立了能满足最苛刻外部审查者的组织治理与合规基础设施；并且对这个问题有了扎实的答案："如果一个资金雄厚的现有巨头今天复制你的产品，你的用户会留下来吗？"

In practice, this threshold will typically take one of three forms: sustainable profitability at a scale that no longer requires external capital, IPO-readiness, or acquisition. All three require that your growth is systematic and auditable, your product moat stands up under scrutiny, and your organization is operationally mature and sustainable.

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

When this is true, congratulations are in order: your startup has gone from being a bet to being a business.

当这些都成立时，应当道贺：你的创业公司已经从一场赌注，变成了一门生意。

Scale stage challenges / 规模化阶段的挑战

Delegating the operational layer / 委派运营层

The challenge: Scale-stage operational systems have to run reliably and sustainably without being babysat. For a founder who has been hands-on since day one, that transition can be as much a psychological challenge as a structural one.

挑战： 规模化阶段的运营系统必须可靠、可持续地运转，而无需人盯着照看。对于一个从第一天起就事必躬亲的创始人来说，这种过渡既是结构性挑战，也同样是心理挑战。

Your Launch stage work was creating the systems; in the Scale phase, it becomes (1) maturing these systems until they are fully trustworthy and (2) then actually trusting them.

你在发布阶段的工作是创建这些系统；到了规模化阶段，工作变成了：(1) 把这些系统打磨到完全值得信赖，以及 (2) 然后真正去信任它们。

This is harder than it sounds. Even if you're a founder who delegates well it's not always obvious what to hand off and what to keep on your plate. Hand off too much, too fast—especially to AI-automated systems—and critical decisions get made without crucial context that only the founder can provide. Hold on too long, though, and you can become a bottleneck.

这比听起来要难。即便你是一个善于授权的创始人，也并不总能一眼看清哪些该交出去、哪些该留在自己手里。交得太多、太快——尤其是交给 AI 自动化系统——关键决策就会在缺少只有创始人能提供的关键上下文的情况下被做出。但抓得太久，你又会变成瓶颈。

The fundamental challenge here is identifying the institutional knowledge that lives only in the founder's head and undocumented workflows, and then codifying it into systems that are documented, auditable, and transferable.

这里的根本挑战，是识别那些只存在于创始人脑中的机构知识和未被记录的工作流，然后把它们编码成有文档、可审计、可移交的系统。

Scaling technical operations / 扩展技术运营

The challenge: Customers no longer evaluate only your product; they want to know that your organization can be a dependable infrastructure partner.

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

Technical challenges during the first three startup stages centered on the codebase: building the right solution without accruing technical debt and then hardening security and compliance for real users. Having reached the Scale phase, the challenge now becomes everything built around the codebase; creating the support infrastructure, documentation, and reliability guarantees that signal maturity.

前三个创业阶段的技术挑战都围绕代码库：在不积累技术债的前提下构建正确的方案，然后为真实用户加固安全与合规。到了规模化阶段，挑战转向了围绕代码库构建的一切：创建那些彰显成熟度的支持基础设施、文档和可靠性保证。

Larger-scale customers and institutional buyers signing multi-year contracts want these before they'll sign, and they'll also hold you to them once they do. The same AI infrastructure that got you this far, though, helps you build dedicated support functions with defined response times and documentation that a new customer's engineering team can actually use.

签署多年合同的大型客户和机构买家，会在签约前就要求这些，并且一旦签约也会拿这些来要求你。不过，那套把你带到这一步的同一 AI 基础设施，能帮你构建出具有明确响应时间的专属支持职能，以及新客户的工程团队能真正使用的文档。

Scaling organizational functions / 扩展组织职能

The challenge: A Scale-stage company generally needs organizational infrastructure like hiring, payroll, accounting, and legal operations, regardless of how many people are running it.

挑战： 一家规模化阶段的公司，通常需要诸如招聘、薪酬、会计和法务运营之类的组织基础设施，无论运营它的人有多少。

At Launch, systematizing operations meant automating the workflows consuming founder attention. A Scale-stage startup now needs to grow an even broader, and in some ways more consequential, array of operational functions such as financial reporting, compliance monitoring, contract management, and customer support, to name a few.

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

Building a GTM function / 构建 GTM 职能

The challenge: Organic growth has a ceiling, and most Scale-stage founders hit it before they've ever had to build a real go-to-market function.

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

Idea, MVP, and Launch stage growth often originates from founder-led selling, from a well-timed Product Hunt post to personal relationships with early customers. Organic growth like this works only to a certain point, though, and most startups hit this limit in the Scale phase. Signs include flattening user curves, rising customer acquisition costs, and a pipeline that only moves when the founder is personally involved.

创意、MVP 和发布阶段的增长，往往源自创始人主导的销售——从一篇时机恰当的 Product Hunt 帖子，到与早期客户的私人关系。但这种有机增长只在一定程度上奏效，而大多数创业公司在规模化阶段撞上这一极限。迹象包括：用户曲线趋平、获客成本上升，以及只有创始人亲自参与时才会推进的销售管线。

Scale-stage growth requires building a dedicated growth engine to reach new and broader audiences for your product. Most startup founders, though, probably have never had to run things like marketing, sales, and analyst relations programs before. A legit GTM motion requires not just establishing new systems and processes, but also creating a brand voice and story for how you want to talk about your product. Because, at this stage in the startup lifecycle, you're going to need one to reach not only individual new users, but also entire target audiences like investors and enterprise buyers.

规模化阶段的增长，需要构建一台专门的增长引擎，去触达你产品的全新且更广泛的受众。然而，大多数创始人此前可能从未运营过市场营销、销售和分析师关系这类项目。一套正经的 GTM 打法，不仅需要建立新的系统和流程，还需要创造一种品牌声音和叙事，来表达你想如何谈论你的产品。因为在创业生命周期的这个阶段，你将需要它来触达的，不只是单个新用户，还有整个目标受众群体——比如投资者和企业买家。

Fortunately, the GTM function doesn't have to be large to be effective, and the same AI infrastructure that built the product can bootstrap bringing it to market.

所幸，GTM 职能不必很庞大就能有效，而那套构建了产品的同一 AI 基础设施，也能帮你把产品推向市场。

How Claude can help Scale stage founders / Claude 如何帮助规模化阶段的创始人

Early startup stages use Claude as foundational infrastructure for the product itself: a research partner for validating the idea, the engineering team that designs and builds the prototype, and the AI operational layer that makes a single-founder startup possible. AI-native startup founders who reach the Scale stage can now use Claude, Claude Code, and Claude Cowork to keep scaling the same way they built.

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

Handing off day-to-day tasks to Claude Cowork / 把日常任务移交给 Claude Cowork

Start the Scale stage with a clear-eyed view of where you most need to invest your time and attention now, which can be a challenge for first time founders who've never built a business before. Claude can help by building the list of things only you should be doing at this stage, which could include things like product narrative decisions, board relationships, enterprise deals, and founder-to-founder conversations. Anything not on that list is a candidate for delegation or Claude Cowork automation.

以清醒的眼光开启规模化阶段：弄清此刻你最需要把时间和注意力投入到哪里——对于此前从未创办过企业的初次创始人来说，这可能是个挑战。Claude 能帮你列出"此阶段只有你才应该做"的事情清单，可能包括产品叙事决策、董事会关系、企业大单，以及创始人对创始人的对话。任何不在这份清单上的事，都是委派或交给 Claude Cowork 自动化的候选项。

• Exercise: Use Claude to produce a bottleneck map of your current operational layer: every workflow, decision, and approval currently routed through you. Now, ask Claude to extrapolate what happens to each one when you're unavailable for a week. The workflows that stall are the ones where you are still hands-on enough to derail progress.

• 练习： 用 Claude 绘制一张你当前运营层的瓶颈图：当前一切经由你路由的工作流、决策和审批。然后，让 Claude 推演：当你一周无法处理事务时，每一项会发生什么。那些停滞的工作流，正是你仍然亲力亲为到足以拖累进度的地方。

How do these map to the inventory of founder priorities and responsibilities you made with Claude?

这些与你和 Claude 一起整理出的"创始人优先事项与职责清单"如何对应？

Next, it's time to pressure-test that the systems you've already built are actually ready to scale with your business as it grows.

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

• Exercise: Use Claude to map your current workflows, and then ask it what happens to each one when you're unavailable for a week. The workflows that stall are the ones where handoff criteria, escalation paths, or exception handling still need tightening. Claude can help analyze the failure points and recommend appropriate fixes so you can update or replace Claude Cowork automations as necessary.

• 练习： 用 Claude 梳理你当前的工作流，然后问它：当你一周无法处理事务时，每一项会发生什么。那些停滞的工作流，正是其移交标准、升级路径或异常处理仍需收紧的地方。Claude 能帮你分析故障点并建议合适的修复方案，以便你按需更新或替换 Claude Cowork 的自动化。

Scale technical operations into enterprise-grade infrastructure / 把技术运营扩展为企业级基础设施

As you scale, buyers need reassurance that your product and your organization can be trusted as long-term infrastructure. Technical work still goes on inside the codebase as always, but now there is technical work around the codebase to handle, too.

随着你扩展，买家需要确信你的产品和组织可被信赖为长期基础设施。代码库内部的技术工作一如既往地继续，但现在还有围绕代码库的技术工作需要处理。

The first step is to convert institutional knowledge into a system that scales. Use Claude to draft and maintain the written infrastructure that enterprise procurement expects to see, including product documentation, support playbooks, and SLAs.

第一步是把机构知识转化为一个可扩展的系统。用 Claude 来起草并维护企业采购期望看到的书面基础设施，包括产品文档、支持手册和 SLA（服务级别协议）。

In parallel, direct Claude Code to audit and harden the codebase against the specific reliability and security standards that enterprise contracts require, and to build out the technical support infrastructure that Discord-based community support never had to provide: logging, monitoring, incident response tooling, and the observability layer that makes SLAs actually enforceable.

与此同时，指挥 Claude Code 依据企业合同所要求的特定可靠性与安全标准来审计并加固代码库，并构建出那种"基于 Discord 的社区支持从来不需要提供"的技术支持基础设施：日志、监控、事件响应工具，以及让 SLA 真正可执行的可观测性层。

Claude Cowork then runs the operational layer of enterprise support itself: ticket routing, escalation workflows, documentation updates triggered by product changes, renewal tracking, and the reporting cadences that enterprise customer success relies on. Together, these three give a small team the support posture of a much larger organization, which is exactly what signing a multi-year enterprise contract requires you to demonstrate.

然后，Claude Cowork 运行企业支持本身的运营层：工单路由、升级工作流、由产品变更触发的文档更新、续约跟踪，以及企业客户成功所依赖的报告节奏。这三者合在一起，让一个小团队拥有一家大得多的组织的支持姿态——而这恰恰是签署一份多年期企业合同要求你展示的。

• Exercise: Pick your three most demanding prospects or identify three ideal customers for your product that you'd love to sign. Ask Claude to produce a gap analysis: what documentation, SLAs, and support infrastructure would an enterprise procurement team at each of these accounts expect to see before signing a multi-year contract, and where do you currently fall short? Use the output to sequence the technical and documentation work across Claude Code and Claude Cowork.

• 练习： 挑选你最苛刻的三个潜在客户，或确定三个你很想签下的理想客户。让 Claude 产出一份差距分析：这几个客户的企业采购团队在签署多年期合同之前，期望看到什么样的文档、SLA 和支持基础设施，而你目前在哪些方面有所欠缺？用这份产出来把技术与文档工作分摊到 Claude Code 和 Claude Cowork 上。

Build a real GTM function / 构建一个真正的 GTM 职能

Founder hustle got you this far, but scaling your startup requires creating and implementing an actual go-to-market strategy. AI can help you build, then and run, that complete GTM engine.

创始人的拼劲把你带到了这一步，但扩展你的创业公司，需要创建并实施一套真正的 go-to-market 策略。AI 能帮你构建并运行那台完整的 GTM 引擎。

Claude can assist with building foundational GTM resources from scratch: market segmentation, messaging architecture, analyst relations strategy, sales playbooks, and the investor-facing metrics narratives that matter once you're talking to public investors, enterprise buyers, and Wall Street analysts. Each of these audiences has its own vocabulary and evaluates you against its own standards; Claude's job is to translate your product's value props into a product marketing approach that's relevant for each audience segment.

Claude 能协助从零开始构建基础性的 GTM 资源：市场细分、信息架构、分析师关系策略、销售手册，以及一旦你开始与公开市场投资者、企业买家和华尔街分析师对话时至关重要的、面向投资者的指标叙事。这些受众各有自己的术语，也各自用自己的标准来评判你；Claude 的任务，是把你产品的价值主张翻译成对每个受众群体都切题的产品营销方法。

Now, Claude Cowork can become your tactical execution layer: content pipelines, outbound sequences, analyst briefing logistics, newsroom and PR cadences, CRM hygiene, pipeline reporting, and the many recurring cycles that turn GTM strategy into actual commercial motion.

接着，Claude Cowork 可以成为你的战术执行层：内容管线、外呼序列、分析师简报事务、新闻室和公关节奏、CRM 卫生维护、销售管线报告，以及把 GTM 策略转化为实际商业行动的众多重复性循环。

Where the GTM motion requires product marketing infrastructure—interactive demo environments, integration documentation, sandbox tenants, API references, technical one-pagers—Claude Code can build it for you. Buyers expect this all used to in the Scale phase, a Loom video and a sales deck no longer suffice. This is also the infrastructure that lets your GTM motion run asynchronously: a well-built demo environment closes deals while you're in board meetings.

当 GTM 打法需要产品营销基础设施时——交互式演示环境、集成文档、沙箱租户、API 参考、技术单页文档——Claude Code 能帮你构建它。买家如今对此有所期待；在规模化阶段，一段 Loom 视频和一份销售演示稿已不再够用。这也是让你的 GTM 打法得以异步运行的基础设施：一个搭建良好的演示环境，能在你开董事会时帮你谈成交易。

Turning domain expertise and institutional knowledge into AI context / 把领域专长与机构知识转化为 AI 上下文

Many ultra-lean startup founders are building highly specific apps or tools for a real-world problem they experience or observe first-hand in a particular sector. Agentic AI now makes it possible for founders who have never written a line of code to use their domain expertise to build products that solve sophisticated problems. Claude, Claude Code, and Claude Cowork each play a part in converting founder knowledge into compounding product specificity.

许多超精简创业公司的创始人，正在为他们在某个特定行业中亲身经历或一手观察到的真实问题，构建高度具体的应用或工具。智能体 AI 如今让那些从未写过一行代码的创始人，得以用他们的领域专长来构建解决复杂问题的产品。Claude、Claude Code 和 Claude Cowork 各自在"把创始人的知识转化为可复利的产品独特性"中扮演角色。

Using Claude to capture, organize, and refine founder knowledge puts domain expertise somewhere the product can reach. Through extended conversations, projects, and memory, a founder can share everything they know—industry jargon, regulatory gotchas, edge cases, frustrations, reasons why the obvious answers to this problem don't work—into a structured, searchable context. Skills can then codify recurring workflows (e.g., "how I audit a commercial lease," "how I triage a patient intake form") into reusable routines Claude runs the same way every time. Over months, this becomes a proprietary knowledge substrate that no generalist AI can match.

用 Claude 来捕捉、组织和提炼创始人的知识，能把领域专长放到产品可触及的地方。通过长时间的对话、项目和记忆，创始人可以把自己所知的一切——行业术语、监管陷阱、边缘情况、痛点、以及为什么针对这个问题的显而易见的答案行不通——分享进一个结构化、可搜索的上下文。Skills 随后可以把重复性的工作流（例如"我如何审计一份商业租约"、"我如何分诊一份病人接诊表")编码成可复用的例程，让 Claude 每次都以同样的方式执行。数月之后，这会变成一个通用型 AI 无法匹敌的专有知识基底。

Externalizing your domain knowledge with Claude becomes invaluable for encoding industry-specific edge cases into your product: a generalist AI medical billing tool breaks on 340B drug program claims, for example, but yours has specific logic for them. Claude Code helps you translate common frustrations experienced by other professionals in your field into validation logic, prompt refinements, or an MCP integration with a niche industry system your competitors haven't heard of. As a result, your app or tool's depth and breadth both continually compound in a way that competitors simply can't replicate.

借助 Claude 把你的领域知识外化，对于"把行业特定的边缘情况编码进你的产品"而言变得极其宝贵：比如，一个通用型 AI 医疗账单工具在处理 340B 药品计划理赔时会出错，而你的工具针对它们有专门的逻辑。Claude Code 能帮你把你所在领域其他专业人士常遇到的痛点，转化为校验逻辑、prompt 精调，或与某个你竞争对手闻所未闻的小众行业系统的 MCP 集成。结果是，你的应用或工具的深度与广度都以一种竞争对手根本无法复制的方式持续复利增长。

• Exercise: Identify one edge case a generic competitor would definitely get wrong in your vertical. Work with Claude Code to build a dedicated test case for it (not a unit test) based on a scenario you've actually seen. Every time a similar edge case surfaces, add it. Your test suite becomes a map of your moat.

• 练习： 找出一个在你所在垂直领域中、通用竞争对手一定会搞错的边缘情况。基于你实际见过的场景，与 Claude Code 一起为它构建一个专门的测试用例（不是单元测试）。每当类似的边缘情况浮现时，就把它加进去。你的测试套件，会成为你护城河的一张地图。

Compound accumulated user data into a defensible advantage / 把积累的用户数据复利成可防御的优势

As users interact with your product, they generate behavioral signals (i.e., which outputs they accept and which they reject), which informs the product roadmap. Over time, you'll learn the specific patterns, preferences, and edge cases of your particular user base. This is what we mean by compounding value: each improvement makes the product more useful, which drives more usage, which creates more feedback, which drives more improvement.

随着用户与你的产品互动，他们会产生行为信号（即，他们接受哪些输出、拒绝哪些），这些信号为产品路线图提供依据。随着时间推移，你会了解你特定用户群体的具体模式、偏好和边缘情况。这就是我们所说的"复利价值"：每一次改进都让产品更有用，从而驱动更多使用，进而产生更多反馈，再驱动更多改进。

This data is time-locked, context-specific, and impossible for a copycat to recreate: you simply can't buy the behavioral fingerprint of thousands of users who've been refining their workflows inside your product.

这些数据是时间锁定的、特定于上下文的，且模仿者无法重建：你根本买不到成千上万、在你产品内部不断打磨自身工作流的用户的"行为指纹"。

Claude can help audit whatever user interaction data you've collected, identify the highest-signal behavioral patterns within it, and design the feedback loop that turns ongoing usage into systematic model improvement.

Claude 能帮你审计你已收集的任何用户交互数据、识别其中信号最强的行为模式，并设计那个"把持续使用转化为系统性模型改进"的反馈回路。

• Exercise: Feed Claude a summary of your product's interaction data: what you've been collecting, how long you've been collecting it, and what you know about how users engage with your product over time. Ask it to identify the three highest-signal behavioral patterns in that data and design a feedback loop that turns each one into a systematic model improvement. Then ask it to help you draft a one-page moat narrative to inform product marketing: the story of how your data flywheel works, how long it's been spinning, and why a well-resourced competitor starting today couldn't replicate it in under two years.

• 练习： 把你产品交互数据的摘要喂给 Claude：你一直在收集什么、收集了多久，以及你对用户随时间如何使用你产品的了解。让它识别出该数据中信号最强的三种行为模式，并设计一个反馈回路，把每一种都转化为系统性的模型改进。然后让它帮你起草一份一页纸的护城河叙事，用以指导产品营销：讲清你的数据飞轮如何运转、它已经转了多久，以及为什么一个今天起步、资源充足的竞争对手在两年内无法复制它。

Create workflow lock-in / 创造工作流锁定

Compounding data network effects make your product harder to replicate, but user workflow lock-in makes your product harder to leave. The longer users run your product inside their daily operations, the more deeply it gets embedded in how they actually work. They've built automations on top of it, trained people to use it, and connected it to their data sources and other tools. The prompts they've developed, the workflows they've refined, and the outputs they've standardized have all been shaped around what your product does and how it does it. At this point, switching goes from product decision to full scale operational project.

复利式的数据网络效应让你的产品更难被复制，而用户的工作流锁定让你的产品更难被舍弃。用户在日常运营中使用你产品的时间越长，它就越深地嵌入他们实际工作的方式中。他们在它之上构建了自动化、培训人员使用它，并把它连接到自己的数据源和其他工具。他们开发的 prompt、打磨的工作流、标准化的输出，全都是围绕你的产品做什么、以及它如何做而塑造的。到了这个地步，切换就从一个产品决策，变成了一项全规模的运营工程。

The first step in creating workflow lock-in is asking Claude to map your current customer base by integration depth. For each customer segment, identify what workflows they've built on top of your product and which integrations they depend on. This shows where your product is sticking, and where it needs to go deeper.

创造工作流锁定的第一步，是让 Claude 按集成深度来绘制你当前的客户群。对于每个客户细分群体，识别他们在你产品之上构建了哪些工作流、依赖哪些集成。这能显示出你的产品在哪里"粘住"了用户，以及它需要往哪里更深入。

The more integrations you offer, the more surface area a customer has to construct workflows that rely on your product. Claude Code helps you quickly spin up native integrations with the data pipelines, project management tools, and other systems that your target users depend on. Claude Code can also build the APIs, webhooks, and SDKs that let customers not just use your product, but build on top of it—the deepest form of lock-in

你提供的集成越多，客户就有越多的界面去构建依赖你产品的工作流。Claude Code 能帮你快速搭建与目标用户所依赖的数据管线、项目管理工具和其他系统的原生集成。Claude Code 还能构建 API、webhook 和 SDK，让客户不只是使用你的产品，而是在它之上进行构建——这是最深层的锁定。

• Exercise: Ask Claude to help you build a workflow integration audit for your top ten customers. For each one, document the automations they've built, the integrations they depend on, the team workflows that run through your product, and your estimate of their switching cost. Then ask Claude to identify the patterns across the group: what types of integration create the deepest lock-in for your specific product, and what you could build or enable to deepen integration for customers who are currently at the surface.

• 练习： 让 Claude 帮你为你的前十大客户构建一份工作流集成审计。对于每一个，记录他们构建的自动化、依赖的集成、贯穿你产品的团队工作流，以及你对他们切换成本的估计。然后让 Claude 识别这一群体中的模式：哪些类型的集成为你的具体产品创造了最深的锁定，以及你可以构建或开启什么，来为那些目前还停留在表层的客户深化集成。

第 7 章 · Same job, new rules / 同样的工作，全新的规则

In the AI area, the founder's job hasn't changed: find a real problem, build something that solves it, and scale it into a company that matters. What's changed is the path to get there. Across the four stages—Idea, MVP, Launch, and Scale—AI compresses quarters into weeks.

在 AI 时代，创始人的工作并没有改变：找到一个真实的问题、构建出能解决它的东西，并把它扩展成一家有分量的公司。改变的是抵达那里的路径。在四个阶段——创意、MVP、发布和规模化——AI 把以季度计的时间压缩成以周计。

Validation cycles that used to take months now take afternoons. A working prototype no longer requires a co-founder with the right stack; it requires a clear problem and a few focused sessions with a coding agent. Launch readiness compresses from a pre-launch scramble into a continuous workstream. And at scale, the operational weight that used to force early hires into firefighting roles can increasingly be handed off to AI, freeing your team to spend their attention on the judgment calls that become your moat.

过去要花数月的验证周期，现在只需几个下午。一个能运行的原型不再需要一位掌握正确技术栈的联合创始人；它只需要一个清晰的问题，外加几次与编程智能体的专注会话。发布就绪从一场发布前的手忙脚乱，压缩成一条持续的工作流。而在规模化阶段，过去逼着早期员工陷入救火角色的运营重负，如今越来越多地可以交给 AI，从而释放你的团队，让他们把注意力花在那些将成为你护城河的判断性决策上。

The bottlenecks are no longer what you can build, but what you choose to build.

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

第 8 章 · Resources / 资源

Building with Claude / 用 Claude 构建

• Building AI Agents for Startups: Shares how startups use agents to become less founder-dependent as they scale.
• Claude Code docs: Carries builders from initial installation to advanced agentic workflows. Pro-tip: get started with the "How Claude Code works" overview.
• Claude Code best practices: Covers patterns that have worked inside Anthropic and across engineering teams — context management, permissions, planning, and verification workflows.
• Using CLAUDE.md files: Walks through how to configure Claude Code for your specific codebase. Essential reading for MVP-stage founders setting up their development environment.
• Claude Code power user tips: Highlights workflow patterns from the Claude Code team itself, including parallel sessions and verification loops.
• Get started with Claude Cowork: Shares how teams can set up Claude Cowork and start implementing skills, plugins, and other features that scale its impact across your startup.
• Tutorials: claude.com/resources/tutorials offers a searchable list of hands-on walkthroughs for specific tasks.

• Building AI Agents for Startups（为创业公司构建 AI 智能体）： 分享创业公司如何在扩张过程中利用智能体降低对创始人的依赖。
• Claude Code 文档： 带领构建者从初次安装走到高级智能体工作流。小贴士：从"How Claude Code works"概览开始。
• Claude Code 最佳实践： 涵盖在 Anthropic 内部及各工程团队中行之有效的模式——上下文管理、权限、规划与验证工作流。
• 使用 CLAUDE.md 文件： 讲解如何为你的特定代码库配置 Claude Code。对于正在搭建开发环境的 MVP 阶段创始人来说是必读内容。
• Claude Code 高阶用户技巧： 重点介绍来自 Claude Code 团队本身的工作流模式，包括并行会话和验证回路。
• Claude Cowork 入门： 分享团队如何设置 Claude Cowork，并开始落地实施 skills、插件等能在你整个创业公司中扩大其影响力的功能。
• 教程： claude.com/resources/tutorials 提供一份可搜索的、针对特定任务的动手演练清单。

Founder stories / 创始人故事

• How three YC startups built their companies with Claude Code: Examining how HumanLayer (F24), Ambral (W25), and Vulcan Technologies (S25) used Claude to get prototypes to market fast and scale AI-powered platforms with agentic coding workflows.
• GC AI's founders used domain expertise to build a responsive, Claude-powered legal platform for how in-house teams actually work: company-specific playbooks, cross-functional stakeholders, and variable risk tolerance thresholds.

• 三家 YC 创业公司如何用 Claude Code 构建公司： 探讨 HumanLayer（F24）、Ambral（W25）和 Vulcan Technologies（S25）如何用 Claude 快速把原型推向市场，并以智能体编程工作流扩展 AI 驱动的平台。
• GC AI 的创始人运用领域专长，构建了一个响应迅速、由 Claude 驱动的法律平台，贴合内部团队的真实工作方式：公司特定的手册、跨职能利益相关方，以及可变的风险容忍阈值。

• Carta Healthcare uses Claude to power their clinical abstraction platform, processing 22,000 surgical cases per year and reducing data abstraction time by 66%.
• Anything, powered by Claude and the Agent SDK, has helped 1.5 million users turn ideas into working software products without writing code, including a non-technical founder who built and is already selling a full recruiting platform. Anything's AI agent handles the full build so solopreneurs can double down on their domain expertise.
• Cogent is an applied AI lab building agents to automate critical enterprise security tasks. The startup uses Claude as the reasoning layer for agents that automate investigation, prioritization, and remediation across the full vulnerability lifecycle.
• Airtree uses Claude Cowork as the center of its operations infrastructure, uniting data that used to be scattered across a dozen different tools and teams. Now, when one person builds a workflow automation with skills, everyone in the organization can use it to do all the things on their to-do list that never got done.
• Duvo builds AI agents that run procurement, supply chain, and category management processes across ERPs, supplier portals, spreadsheets, email, and even phone calls. Duvo is built entirely on Claude, using the Agent SDK to orchestrate across workflows.
• Zingage is an AI agent platform built for 24/7 automated operations for home-care agencies. The startup uses Claude's structured tool calling to orchestrate across an EMR and multiple communication channels, and Claude's contextual reasoning to build agents that can give nuanced, patient-tailored outcomes rather than pattern-matching to the most common response.
• Kindora is an AI-powered tool built by a nonprofit executive who used Claude Sonnet to build a desperately-needed tool for intelligently matching charities with funders. After filtering thousands of matches down to the few worth pursuing, Kindora's MCP connector lets nonprofits access its prospecting tools directly within Claude.
• Wordsmith was founded by a lawyer-turned-CTO to provide reliable AI-powered legal technology for in-house legal teams. Claude is the reasoning engine for Wordsmith's contract review, agreement drafting, and document review capabilities, and the startup's engineering team uses Claude Code for building and evolving the platform itself.

• Carta Healthcare 使用 Claude 驱动其临床抽象平台，每年处理 22,000 例外科手术病例，并将数据抽象时间减少了 66%。
• Anything 由 Claude 和 Agent SDK 驱动，已帮助 150 万用户在不写代码的情况下把想法变成可用的软件产品，其中包括一位构建并已在销售一整套招聘平台的非技术创始人。Anything 的 AI 智能体处理整个构建过程，让个人创业者能集中精力在自己的领域专长上。
• Cogent 是一家应用型 AI 实验室，构建用于自动化关键企业安全任务的智能体。这家创业公司把 Claude 作为推理层，驱动那些在整个漏洞生命周期中自动化调查、优先级排序和修复的智能体。
• Airtree 把 Claude Cowork 作为其运营基础设施的中心，统一了过去散落在十几个不同工具和团队中的数据。如今，当一个人用 skills 构建了一个工作流自动化，组织里的每个人都能用它来完成待办清单上那些从未被完成的事。
• Duvo 构建 AI 智能体，在 ERP、供应商门户、电子表格、电子邮件甚至电话之间运行采购、供应链和品类管理流程。Duvo 完全建立在 Claude 之上，使用 Agent SDK 在各工作流之间进行编排。
• Zingage 是一个为居家护理机构提供全天候自动化运营的 AI 智能体平台。这家创业公司使用 Claude 的结构化工具调用，在一个 EMR（电子病历）和多个沟通渠道之间进行编排，并用 Claude 的上下文推理来构建能给出细致、因人而异结果的智能体，而非只是匹配到最常见的回应。
• Kindora 是一款由一位非营利组织高管构建的 AI 工具，他用 Claude Sonnet 构建了一个亟需的工具，用于智能匹配慈善机构与资助方。在把数千个匹配结果筛选到少数几个值得跟进的之后，Kindora 的 MCP 连接器让非营利组织能直接在 Claude 内部访问它的潜在对象挖掘工具。
• Wordsmith 由一位"律师转型 CTO"创办，旨在为内部法务团队提供可靠的、AI 驱动的法律技术。Claude 是 Wordsmith 合同审查、协议起草和文档审查能力的推理引擎，而这家创业公司的工程团队则用 Claude Code 来构建和演进平台本身。

Startup support and opportunities / 创业支持与机会

• Anthropic Startups Program: For startups working with Anthropic's VC partners, the program provides free API credits, the highest tier of publicly available rate limits, and invitations to exclusive founder events and workshops.
• Claude community: Forums and community spaces for builders.
• Live learning resources: Conferences, webinars, livestreams, and recordings.

• Anthropic Startups Program（Anthropic 创业公司计划）： 对于与 Anthropic 的风投合作伙伴合作的创业公司，该计划提供免费 API 额度、最高级别的公开可用速率上限，以及参加专属创始人活动和工作坊的邀请。
• Claude 社区： 面向构建者的论坛和社区空间。
• 实时学习资源： 会议、网络研讨会、直播和录播。

claude.ai

第三章 · 创意阶段：方法论 + 案例演练

本文分两部分： 第一部分 是一张能直接照着走的落地方法论清单（7 步 + 1 道总闸）； 第二部分 用一位瑜伽教练的完整案例，把每一步演给你看怎么操作。

核心心法（先记死这句）： 在写第一行生产代码之前，用证据（尤其真人对话）回答「这值得做吗」；证据不够，就别造。AI 三件套是加速器，不是证据本身——真假判断只来自真人。

第一部分 · 落地方法论 SOP

从「打磨假设」到「5 人原型测试」，每一步都标清 该做什么 · 用哪个工具 · 产出什么 · 怎么判断能不能进下一步。

总览：7 步 + 1 道总闸

★ = 真正产生「真假判断」的两步。其余步骤都是为这两步找方向、做准备、提效率。

Step 1 · 打磨成「可检验的假设」

• 做什么：把模糊的观察，逼成一个具体、可被证伪的句子。
• 工具：Chat
• 判据（可检验性测试）：这句话能不能精确回答——谁有这问题？多频繁？多严重？现在怎么应对？四个都答得上，才算合格。
• 产出物：1 句可检验假设。

反例 ❌：「合同审查太慢。」（观察，不可检验） 正例 ✅：「中型公司内部法务，每个合同审查周期要 3 天以上，因为修订意见散在邮件里、没有统一版本受控文档。」

Step 2 · 让 AI 唱反调（找反证）

• 做什么：让 Claude 反驳你的假设，主动去找能推翻它的证据。
• 工具：Chat（结构化「反方辩手」）
• 要它找的：负面市场信号、失败的竞品、用户行为反例、结构性障碍。
• 判据：你能不能在听完最强反方论点后，依然觉得假设站得住？站不住的地方，就是后面访谈要重点验的。
• 产出物：一份「反方论点 + 待验疑点」清单。

⚠️ 防坑：这一步是整章对抗「确认偏误」的关键。别让 AI 帮你论证你想做的事，让它帮你拆。

Step 3 · 市场研究 + 竞争格局（爬虫数据落这里）

• 做什么：扒方向、扒高频抱怨、扒用户原话；摸清竞品和市场。
• 工具：Claude Cowork（综合公开评论 / 竞品 reviews / 行业报告）
• 三件事：
  1. 竞品评估：让 Claude 论证「为什么某竞品会赢、而你会输」——专治「竞争对手忽视」。
  2. 市场研究：综合公开评论 + 竞品 reviews，找出现有方案没解决的高频抱怨。（你的小红书/抖音/Reddit 爬虫数据用在这。）
  3. 趋势分析：找出未来两年的监管/技术/人口趋势，判断对你是顺风还是逆风。
• 判据：你的假设是否命中了「现有方案没解决的抱怨」？命中是利好；没命中，也值得知道。
• 产出物：竞争格局图 + 高频未满足需求清单 + 市场规模/趋势判断。

⚠️ 边界（牢记）：爬虫只能确认「这个抱怨被高频提到」，不能确认「这是个值得你做的真问题」。它是望远镜（找方向），不是显微镜（证真假）。真假留给 Step 5–7。

Step 4 · 设计客户探索

• 做什么：定「找谁聊」+「问什么」。
• 工具：Chat / Claude Cowork
• 找谁聊（目标画像 > 联系人名单）：具体职位、公司类型、团队结构、资历层级——最可能强烈感受到该问题的人。
• 问什么（访谈框架）：
  • 问过去的具体行为：「上次你遇到这问题，具体怎么做的？」
  • 别问未来意愿：「你会用这样的东西吗？」（《Mom Test》：人会出于礼貌骗你）
  • 让 Claude 审你的草稿问题，标出诱导性 / 面向未来 / 太宽泛 / 会得到讨好式回答的问题。
• 判据：每个问题都指向「可观察的过去行为」，而非「主观的未来表态」。
• 产出物：目标画像 + 一套访谈脚本（含追问设计）。

Step 5 · 跑访谈 + 自动化触达排期 ★真人证据

• 做什么：约人、聊、记录。
• 工具：Claude Cowork（建潜在对象名单、个性化触达、连 Gmail/Calendar 排期、跟进、更新追踪表）
• 怎么跑：每聊完一场就复盘——这场印证了什么、挑战了什么、有什么意外。
• 判据（节奏）：每 5 场访谈做一次小结。
• 产出物：原始访谈记录 + 每场复盘。

★ 这是第一处真证据来源。工具能把约人、排期、跟进全包了，但坐下来听人说话这件事，顶不掉。

Step 6 · 访谈后综合（两张清单）

• 做什么：把一批访谈逼出「正反两面」。
• 工具：Claude Cowork
• 要它产出：① 支持你假设的证据；② 挑战你假设的证据。
• 关键判据：如果「支持清单」明显比「反对清单」长，反问 Claude：这是数据里真实存在的不对称，还是我只想听到的？
• 产出物：支持 vs 反对 两张证据清单 + 一个诚实的偏差自检。

Step 7 · 搭轻量原型 → 放到 5 个真人面前 ★真人证据

• 做什么：造最小可感知的原型（不是产品），让人能上手摸。
• 工具：Claude Code（只做那一个核心交互，别多做）
• 怎么用：放到 5 个符合目标画像的真人面前，看他们的真实反应。
• 判据：这 5 场对话，决定你是继续造还是回炉重想。
• 产出物：一个核心交互原型 + 5 份真人反应记录。

⚠️ 防坑：原型是对话的压力测试道具，不是「我在解决真问题」的证据。能跑的原型 ≠ 被验证的需求。

总闸 · go / no-go：这值得构建吗？

只有三个都能答「是」，才算通过创意阶段（达成「问题—方案契合」）：

1. 问题真实且具体？ —— 能说清谁有、多频繁、多严重、现在怎么应对。
2. 方案对准的是「验证揭示的真问题」，而非「你最初假设的问题」？
3. 信号是否足够支撑「投入做 MVP」是个推理决定，而非信仰之举？（永远不会有 100% 确定性，但要够。）

判断主体是你，不是工具。 当证据要求修正时——这就是该转向（pivot）的信号，不是失败。

一页速记

模糊观察
  └─[Chat] Step1 逼成可检验假设  →  谁/多频/多严重/现在怎么做
      └─[Chat] Step2 唱反调找反证
          └─[Cowork] Step3 市场+竞品（爬虫=望远镜，只找方向）
              └─[Chat/Cowork] Step4 设计访谈（问过去，不问未来）
                  └─[Cowork] Step5 跑真人访谈 ★
                      └─[Cowork] Step6 综合：支持 vs 反对 + 偏差自检
                          └─[Code] Step7 轻量原型 → 5 个真人 ★
                              └─[你] 总闸：这值得构建吗？ go / no-go

心法重申： 爬虫/AI 帮你找到「哪里可能有问题」；真人对话帮你证明「这是不是值得你做的那个问题」。工具是加速器，证据才是目的，判断永远是人的事。

第二部分 · 案例演练：瑜伽教练小琳的全流程

用一个完整真实的案例，把上面 7 步 + 总闸逐步串起来。每一步都给：怎么操作（含示例话术）→ 实际产出（示例）→ 判据/决定。对照第一部分的清单一起看。

主角设定

• 人物：小琳，独立瑜伽教练，从业 6 年，带过 200+ 学员。懂瑜伽，不懂代码。
• 动机：想用 AI 做个属于自己的产品，把多年经验变现、不再纯卖时间。
• 最初的念头：「我每天微信约课、改时间太烦了，我要做一个瑜伽约课 App。」

这就是 99% 的人起步的样子——带着一个"我觉得"的方案就想冲去 Claude Code 开造。第三章的全部意义，就是拦住她这一冲动。

Step 1 · 把模糊念头逼成「可检验假设」

怎么操作：打开 Chat，别让它帮你想功能，让它帮你逼具体。

示例话术： 「我是瑜伽教练，想做约课工具。帮我把『约课很麻烦』这句话，逼成一个可检验的假设。请追问我：谁最受此困扰？多频繁？多严重？现在用什么应对？我答不上来的地方，直接标出来。」

实际产出（小琳被逼出来的假设 v1）：

「独立瑜伽教练（非连锁机构），每周花 3–5 小时在微信里手动约课、改时间、记考勤，因为现有约课工具都是给机构用的、太重，个人教练用不起也不会配。」

判据：四个问题(谁/多频/多严重/现在怎么做)是否都答得上？→ ✅ 答上了，假设合格，进入下一步。

📌 教学点：注意她被迫说清了"独立教练 ≠ 机构""3–5 小时""工具太重"。这就是从观察升级成可证伪的句子。

Step 2 · 让 AI 唱反调（找反证）

怎么操作：同一个 Chat，立刻调转枪口。

示例话术： 「现在请你当反方。用最有说服力的方式论证：为什么我这个『个人教练约课工具』会失败？ 去找：已经存在的替代方案、这个方向失败过的产品、用户其实并不在乎这件事的证据。别照顾我情绪。」

实际产出（AI 给出的反方论点）：

1. 约课是已饱和赛道——微信小程序、问卷接龙、甚至备忘录都能凑合，切换成本 ≈ 0。
2. "麻烦但能忍"≠"愿意付费"——约课一周才烦几次，痛感低频。
3. 个人教练极度价格敏感，为省时间付月费的意愿存疑。
4. 真问题也许不在"约课"，而在别处——教练真正的焦虑往往是学员留存/续课，约课只是表面。

判据：听完最强反方后，假设还站得住吗？→ ⚠️ 动摇了。第 4 点尤其扎心。

产出物：一份「待验疑点清单」，最关键的一条被标红：

❓ 约课到底是不是真痛点？还是说真痛点其实是"学员留存/课后跟进"？

📌 教学点：第三章最恨"确认偏误"。这一步故意让 AI 拆你，于是一个原本被她忽略的方向(留存)浮出水面——这条疑点，决定了后面访谈要重点问什么。

Step 3 · 市场研究 + 竞争格局（爬虫数据落这里）

怎么操作：用 Claude Cowork，综合公开评论与竞品。小琳让助手扒了小红书、抖音、即刻上瑜伽教练相关的发帖和评论。

示例话术： 「这是我整理的 2000 条小红书/抖音上瑜伽教练相关的评论和发帖（附文件）。请综合出：① 教练们反复抱怨的高频问题 Top 5；② 现有约课工具的差评集中在哪；③ 有没有关于『学员留不住/课后不练』的声音，频率多高。给我原话引用。」

实际产出（高频抱怨 Top 5）：

判据：你的假设(约课)是否命中了"现有方案没解决的高频抱怨"？→ ❌ 约课排倒数第一，而 Step 2 怀疑的"留存/课后跟进"霸占了前三。

📌 教学点（关键边界）：到这一步，小琳很想立刻信"那我改做课后跟进工具吧！"——打住。 爬虫只能证明"这个抱怨被高频提到"，不能证明"这是个值得做的真问题"。望远镜看到了方向，真假还得靠显微镜（真人访谈）。否则这就是一份"穿了大数据马甲的 MRD"。

Step 4 · 设计客户探索（找谁聊·问什么）

怎么操作：用 Chat / Cowork 定目标画像和访谈脚本。把"约课"和"课后跟进"两个方向都放进去验，不预设答案。

示例话术： 「帮我设计瑜伽教练的访谈脚本。目标画像：独立/工作室教练，带学员 50 人以上，从业 2 年+。原则：只问过去的具体行为，不问未来意愿。帮我审一遍，把任何诱导性、面向未来、太宽泛、会得到讨好式回答的问题标出来。」

实际产出（访谈脚本节选，对比修正前后）：

• ❌ 修正前（被 AI 打回）："你会用一个课后跟进工具吗？" → 面向未来，会得到礼貌的"会啊"。
• ✅ 修正后："上一次你给学员发课后练习计划，是什么时候？具体怎么做的？花了多久？"
• ✅ 关键对照题："过去一个月，你为'约课改时间'烦过几次？为'学员不练/留不住'烦过几次？" → 用真实频率直接 PK 两个方向。

产出物：目标画像 + 一套"问过去行为"的访谈脚本（含追问设计）。

📌 教学点：《The Mom Test》的精髓全在这——问"上次怎么做的"，不问"以后会不会用"。人会为了礼貌骗你未来，但骗不了已经发生的过去。

Step 5 · 跑访谈 + 自动化触达排期 ★第一处真证据

怎么操作：用 Claude Cowork 把杂活全包了，小琳只管聊。

示例话术： 「按这个目标画像，帮我从我的微信/小红书粉丝里筛 15 个符合的教练，起草个性化邀约话术，连我的日历排好 30 分钟访谈，没回的第 3 天自动跟进，进度更新到追踪表。」

实际产出（聊完 8 场后的复盘要点）：

• 8 个教练里，7 个主动大吐苦水："学员回家根本不练""我每周末手打计划手抽筋"。
• 问到约课："还好吧，微信接龙够用了"——没人当回事。
• 一个意外：有教练说"我发了计划他们也不看，得有人催/有反馈他们才动"——指向"互动感"，不只是"发计划"。

判据（节奏）：每 5 场小结一次。→ 8 场后信号已经很强且一致。

📌 教学点：到这里"约课"假设基本被真人判了死刑。注意那个意外发现(光发计划没用、要有催促/反馈)——这种东西爬虫和问卷永远问不出来，只有可追问的真人对话能挖到。这就是 Step 5 不可替代的原因。

Step 6 · 访谈后综合（支持 vs 反对两张清单）

怎么操作：把 8 份访谈记录丢给 Claude Cowork。

示例话术： 「这是 8 份访谈记录。产出两张清单：① 支持『约课是真痛点』的证据；② 反对它的证据。再单独列：关于『课后跟进/留存』，支持和反对各有哪些。最后反问我一句：我的解读是不是在挑我想听的？」

实际产出：

• 「约课假设」：支持 1 条、反对 7 条 → 基本证伪。
• 「课后个性化跟进假设」：支持 7 条、反对 1 条，且反对那条是"怕麻烦"，恰好能被产品解决。
• Claude 的反问：「你最初想做约课，现在数据全指向课后跟进——你确定不是因为'课后跟进'听起来更性感，而过度解读了？ 建议原型阶段用最小成本验证'教练真的愿意为省下手打计划的时间付费'。」

判据：哪个方向的"支持 > 反对"且反对项可被解决？→ 方向确认从「约课」转向「课后个性化练习计划 + 跟进」。

📌 教学点：这正是总闸判据②的现场——「方案要对准验证揭示的真问题，而不是你最初假设的问题」。小琳的真问题，是被流程"揪"出来的，不是她拍脑袋想出来的。

Step 7 · 搭轻量原型 → 放到 5 个真人面前 ★第二处真证据

怎么操作：用 Claude Code，只做那一个核心交互——别做约课、别做收款、别做社区。

• 核心交互定义：教练用语音/几个关键词描述学员情况 → AI 自动生成一份图文版个性化课后练习计划（这一个动作，直击"手打计划累死"的最高频痛点）。

示例话术： 「帮我用 Claude Code 做一个极简原型：输入框接收教练对学员的口述（如'初学者、腰不好、想改善体态'）→ 输出一份结构化的图文练习计划。只做这一个功能，能在手机上打开演示就行。」

实际产出 + 怎么用：原型做出来后，拿给 5 个 Step 5 里聊过的教练真上手试。

• 4 个看完第一反应："这个直接能用！我现在就想拿它给我学员发。"
• 1 个："计划生成得不错，但学员到底练没练、我还是不知道"——再次印证那个"要有反馈闭环"的意外发现。

判据：这 5 场决定继续造还是回炉。→ ✅ 继续，且明确了 MVP 第二刀要补"练习完成反馈"。

📌 教学点：原型不是产品，是对话的压力测试道具。4 个人说"想用"是强信号，但真正值钱的是那第 5 个人暴露的缺口——它定义了你 MVP 阶段第一个要补的功能。

总闸 · go / no-go：这值得构建吗？

→ GO。 小琳进入 MVP 阶段。但她要造的，已经不是当初那个"约课 App"了。

这个案例真正教会你的 4 件事

1. 她最初的方案（约课）是错的，而且是被流程"证伪"的，不是被否定的。 —— 第三章不是来打击你的，是来帮你省下几个月造错东西的命。
2. 真痛点（课后跟进）是揪出来的，不是想出来的。 —— Step 2 唱反调起疑 → Step 3 爬虫指向 → Step 5 真人坐实，三层证据逐级收紧。
3. 爬虫给方向，真人给真假。 —— 少了 Step 5/7 任意一个，她都可能做出一个"看起来有数据支持"的错产品。
4. 每一步都有 AI，但每一个"判断"都是人做的。 —— 工具把约人、研究、综合、搭原型全包了，但"约课是错的、课后跟进是对的"这个决定，是小琳看着真人证据自己下的。

一句话收尾： 第三章不是"教你怎么造"，是"教你在造之前，怎么确认你要造的东西是对的"——而小琳的故事证明：你以为对的，往往是错的；而对的那个，得靠证据一步步把它逼出来。

第四章 · MVP 阶段：方法论 + 案例演练

本文分两部分： 第一部分 是一张能直接照着走的落地方法论清单（7 步 + 1 道总闸）； 第二部分 接着第三章的瑜伽教练小琳，把每一步演给你看怎么操作。

配套阅读：[[第三章-创意阶段-方法论与案例]]（小琳已在第三章验证出方向：课后个性化练习计划 + 一个"练没练"的反馈闭环）。

核心心法（先记死这句）： MVP 不是"造一个完整产品"，是"用最小的东西换到真实的 PMF 证据"。快，但别欠会复利的技术债；而"是不是真 PMF"的判断，永远是人盯着数据做的——漂亮的早期数字，往往是"发布能量"，不是 PMF。

第一部分 · 落地方法论 SOP

第三章解决的是"该不该造"；第四章解决的是"怎么造、造到什么程度、怎么知道造对了"。注意：MVP 阶段本质仍是收集证据，只不过现在收集的是关于"方案"的证据（有没有人愿意持续用、付费、推荐）。

总览：7 步 + 1 道总闸

★ = MVP 阶段三处真功夫：构建本身、真人反馈、PMF 判断。前 3 步是地基，地基不打，后面全漂移。

📌 顺序提醒：第 1–3 步必须在写第一行生产代码之前做完。 大多数 MVP 翻车，不是死在"造得慢"，是死在"没地基就开造"。

Step 1 · 先定架构（存成 CLAUDE.md）

• 做什么：在 Claude Code 写第一行代码前，先用 Claude 把架构决策想清楚并写下来：要遵循的模式、要避免的依赖、有意识接受的取舍及原因。
• 工具：Claude（Chat）→ 把产出保存为 CLAUDE.md
• 怎么做：告诉它你造什么、服务谁、未来 6 个月现实预期的规模，让它帮你定架构原则。
• 产出物：一份 CLAUDE.md——你这次构建的第一个产物，之后每次会话都读它（它就是项目的持久"记忆"）。
• 判据：CLAUDE.md 能不能让一个新会话"不用你重新讲一遍"就接着干？

⚠️ 防坑【智能体技术债】：AI 技术债是复利的。没有写下来的架构约束，每次会话都从零重新推导、决策漂移，最后代码库"没有连贯的心智模型"，迟早崩塌、被迫重写。不懂代码也必须先定架构——这恰恰是你最该做的人类判断。

Step 2 · 锁死 MVP 范围（含新增标准）

• 做什么：在造任何一个功能前，定义清楚——产品做什么、刻意不做什么、以及"什么证据才够格新增一个功能"。
• 工具：Claude（Chat / Cowork）
• 产出物：一份范围文档（做 / 不做 / 新增门槛）。
• 判据：新功能想法冒出来时，决策点是不是从"这个该不该做？"变成了"是否有足够多真实用户说，没有它就没法从产品里获得价值？"

⚠️ 防坑【零摩擦范围蔓延】：AI 时代加一个功能只要一下午，过去"工程时间贵"这个天然刹车没了。每个新增单看都说得过去，但产品会蔓延到失去方向。用范围文档当刹车。

Step 3 · 上线前建好度量框架

• 做什么：在第一个用户出现之前，定义清楚哪些指标算真 PMF、哪些是好看的噪声。
• 工具：Claude（Chat）
• 要定的：留存基准、激活标准、D7 / D30 目标；并明确定义你的产品的"假阳性"长什么样（如：注册但不激活、有营收但无留存、初始热情但不复用）。
• 产出物：一张度量表 + 一份"假阳性清单"。
• 判据：数据到来时，你能不能让 Claude 替怀疑者说话——"这些数字，一个 skeptic 会怎么喷？"

⚠️ 防坑【虚假 PMF】：误把早期牵引力当 PMF 的人，几乎都是上线后才埋点、且只埋"成功"指标的人。上线前埋点，是你唯一能不自欺的办法。

Step 4 · 用 Claude Code 构建 ★

• 做什么：在架构和范围已定的前提下，用 Claude Code 生成、测试、调试、迭代代码库。
• 工具：Claude Code
• 怎么做：每次会话 (1) 回顾范围文档 (2) 把 CLAUDE.md 喂给它；会话结束时把本次浮现的决策写回 CLAUDE.md 日志。
• 产出物：一个"你能解释其结构"的代码库（不只是"能跑"）。
• 判据：把每次会话当成"执行你已经做出的产品决策"，而不是"塞进几个新决策"的机会。

📌 教学点：每会话 5 分钟写日志，是对抗"架构漂移复利成不可管理代码库"的最便宜的保险。

Step 5 · 任何真人接触前做安全审查

• 做什么：在部署给任何真实用户前，过一遍安全。
• 工具：Claude Code（首过审查）/ Claude Code Security（扫漏洞、建补丁）
• 审查 brief：鉴权与会话处理、API 响应里的数据暴露、输入校验与注入风险、含已知漏洞的依赖。
• 产出物：一份安全发现清单 + 处理决定。
• 判据：凡涉及鉴权、密钥、数据处理的，必须有人工复核。

⚠️ 防坑【因经验不足而不安全】：agentic 工具生成的是"能跑"的代码，不是"天生安全"的代码。功能坏了你立刻知道，漏洞在被利用前是隐形的——没有反馈回路提醒你。上线 = 真实数据、真实暴露、真实后果。AI 扫描是辅助，不替代安全工具，高风险下也不替代人工。

Step 6 · 跑用户反馈闭环（工具收集 · 真人解读）★

• 做什么：真实用户进来后，把"建联系人名单、跑触达、约反馈、分类 bug、追踪迭代"这些重要但繁琐的事自动化。
• 工具：Claude Cowork（事务）+ 你（解读）
• 产出物：每周一次的反馈汇总 + 你的解读批注。
• 判据：模糊反馈必须真人解读——用户说"这挺好，但我希望它还能…"，到底是核心需求还是锦上添花？是这个客户特有，还是代表一个群体？没有工具能替你回答。

Step 7 · 朝证据迭代，而非朝"完整"迭代 ★

• 做什么：用证据判断"是否已达 PMF"，无论产品感觉多"完整"。
• 工具：Claude（综合分析）+ 你（判断）
• 两把试金石：
  • Sean Ellis 测试：问活跃用户"如果再也不能用它，你会怎样？"——>40% 答'非常失望' 是有意义的 PMF 信号。
  • 努力测试：PMF 前，留存靠你不停地推（催、激励、人工跟进）；PMF 后，产品**自己开始"拉"**用户。从"推"变"拉"，是最清晰的信号之一。
• 判据：单个数据点不算数，PMF 是一个跨多个迭代周期持续成立的模式。

总闸 · 真实 PMF 证据？否则 pivot

退出 MVP 的条件 = 真实的 PMF 证据：一个具体、可识别的人群，觉得它有价值到——

• 回来用（留存） / 付费（营收） / 告诉别人（转介）

若反复迭代仍达不到 PMF——不是失败，是系统在正常工作。 用 Claude 梳理数据在告诉你什么，三条出路：

1. 换细分人群：没转化的人也许从一开始就不是对的目标；对的受众往往已经在你数据里，只是被平均值掩盖。
2. 调价值主张：受众对，但 MVP 没共鸣——调引导/信息/核心功能侧重，可能不用改已造的东西。
3. 更根本的改变：脱节深到要回第三章。
   • 三连问诊断：①数据里有没有某群体反应不同？②"设计价值 vs 体验价值"的差距是定位问题还是产品问题？③要让当前产品找到真 PMF，需要什么为真，现实吗？

一页速记

带着第三章验证出的方向进场
  └─[Chat→CLAUDE.md] Step1 先定架构（防技术债复利）
      └─[Chat/Cowork] Step2 锁范围（做/不做/新增门槛，防蔓延）
          └─[Chat] Step3 上线前埋度量（定义"假阳性"，防虚假PMF）
              └─[Code] Step4 构建：每会话=执行已定决策 ★
                  └─[Code/Security] Step5 真人接触前安全审查
                      └─[Cowork+你] Step6 反馈闭环：工具收集·真人解读 ★
                          └─[Claude+你] Step7 朝证据迭代（Sean Ellis>40% / 推→拉）★
                              └─[你] 总闸：真PMF？(留存/营收/转介) 否则 pivot

心法重申： 前 3 步是地基（架构/范围/度量），地基决定你能不能"快而不塌"。工具让你造得飞快，但"这是不是真 PMF、该聚焦哪群人"的判断，永远是人盯着证据下的。

第二部分 · 案例演练：小琳的 MVP 阶段

接第三章。小琳已验证：真痛点是课后个性化练习计划，且第 5 个原型测试者暴露了关键缺口——"学员到底练没练，教练不知道"（需要反馈闭环）。现在她进入 MVP。

进场状态

• 要造的东西：教练口述学员情况 → AI 生成图文练习计划（核心）+ 学员端打卡反馈（补缺口）。
• 她的冲动：粉丝里好多人喊"快上线"，她想一周糊出来全量推。
• MVP 阶段要拦住的：糊得快 ≠ 造对、≠ 安全、≠ 真 PMF。

Step 1 · 先定架构（存成 CLAUDE.md）

怎么操作：小琳不懂代码，但先用 Chat 把地基想清楚。

示例话术： 「我要造一个'瑜伽教练课后练习计划'工具。服务对象：独立教练 + 他们的学员；未来 6 个月现实规模：我自己 200 个学员，加几个教练朋友，撑死一两千人。核心数据里有学员的伤病/身体状况（敏感）。帮我定：该用的架构原则、在我这个规模下要避免的依赖、现在有意识接受的取舍。输出成一份我能存成 CLAUDE.md 的文档。」

实际产出（CLAUDE.md 要点）：

• 规模假设：单机/轻量后端足够，别上微服务（取舍：先简单，规模到了再说）。
• 敏感数据：伤病信息单独加密存储 + 访问隔离，写成硬约束。
• 要避免的依赖：不引入重型 CRM/IM SDK（范围外）。

判据：新会话读完这份能直接接着干吗？→ ✅

📌 教学点：她一行代码不会写，但**"伤病数据要隔离""别上微服务"这些是产品/业务判断，只有她能拍**。地基由人打，施工才交给 AI。

Step 2 · 锁死 MVP 范围

怎么操作：用 Chat 写范围文档，把"想做的一堆"砍到"最小那一个"。

示例话术： 「帮我写 MVP 范围文档：① 只做哪些；② 刻意不做哪些；③ 什么证据才够格新增功能。我列一下脑子里冒出来的：约课、收款、视频库、师生社区、打卡反馈…帮我对照'第三章验证出的真痛点'砍。」

实际产出（范围文档）：

判据：决策点是否从"该不该做"变成"有没有证据"？→ ✅

📌 教学点：注意"约课"被明确写进不做——这就是第三章验证的价值落地：不是删了一个功能，是省下了一个会拖垮 MVP 的方向。

Step 3 · 上线前建好度量框架

怎么操作：用 Chat 在上线前把"什么算成功""什么是自欺"定死。

示例话术： 「帮我为这个产品定 PMF 度量：留存基准、激活标准、D7/D30 目标。再帮我定义'假阳性'——哪些数据好看但其实不是 PMF。」

实际产出：

• 激活：教练注册后生成 ≥1 份计划并发给学员才算激活（光注册不算）。
• 留存目标：D7 教练回访发计划 ≥40%；学员打卡 ≥30%。
• 假阳性清单：①朋友捧场注册但不发计划；②发一次就再不发；③学员注册但从不打卡。

判据：数据来时能不能让怀疑者开喷？→ 已备好。

📌 教学点：这一步是后面没被"虚假 PMF"骗到的唯一原因。 上线前埋点 + 提前写好"假阳性长什么样"。

Step 4 · 用 Claude Code 构建

怎么操作：用 Claude Code，开局喂 CLAUDE.md + 范围文档，只做范围内的事。

示例话术（每次会话开头固定模板）： 「读取项目 CLAUDE.md 和范围文档。本次会话只做一件事：实现'教练口述→生成图文计划'。不要顺手加任何范围外功能。结束时把本次的架构决策追加到 CLAUDE.md 日志。」

实际产出 + 一次"差点翻车"：

• 造计划生成、学员打卡两个核心功能，分多次会话推进。
• 中途她手痒想"顺便把视频库也加了吧，反正 AI 一下午就能写"——翻开范围文档，新增门槛没达到 → 忍住。

判据：每次会话是"执行已定决策"还是"塞新东西"？→ 守住了。

📌 教学点：这就是"零摩擦范围蔓延"的现场。刹车不是 AI 帮你踩的，是范围文档帮你踩的。

Step 5 · 任何真人接触前做安全审查

怎么操作：上线给真实学员前，因为存了伤病/身体数据，必须审。

示例话术： 「上线前审一遍核心代码：鉴权与会话、API 响应里有没有泄露学员伤病信息、输入校验与注入风险、依赖有没有已知漏洞。涉及学员健康数据的，单独标出来给我人工确认。」

实际产出：Claude 标出两处——①学员计划接口返回了多余的身体数据字段；②没做基础越权校验（A 教练能看到 B 的学员）。两处都属"碰健康数据"，人工复核后修掉才上线。

判据：涉敏感数据的发现是否人工复核？→ ✅

📌 教学点：功能能跑她早试过了，但"越权能看别人学员伤病"这种隐形漏洞，不审根本发现不了——而它一旦被利用，就是上头条的那种事故。

Step 6 · 跑用户反馈闭环

怎么操作：上线给早期教练 + 学员，用 Claude Cowork 管收集，她自己解读。

示例话术： 「给我的早期教练名单跑反馈闭环：每周约 3 个深聊、收集所有 bug 和功能请求、生成每周汇总。汇总给我看，别替我下结论。」

实际产出（第一周汇总里的一句模糊反馈）：

一位教练："计划生成挺好，但我希望它还能自动提醒学员打卡。"

她的真人解读：这不是"锦上添花的提醒功能"，而是再次指向第三章那个缺口——没有反馈闭环，学员就是不动。 这是核心需求，不是 nice-to-have。

判据：模糊反馈有没有被真人解读？→ ✅

Step 7 · 朝证据迭代（本章反转在这）

第一周数据爆好：80 个教练注册，朋友圈一片叫好。小琳差点宣布"PMF 达成、开香槟"。

但上线前埋的度量框架打脸：

• D7 教练回访发计划只有 15%（目标 40%）——大多数发一两次就不发了 = 命中"假阳性②"。
• 整体 Sean Ellis 测试："非常失望"只有 25%（<40%）。

她忍住没自嗨，让 Claude 拆 segment——真相浮现：

• 努力测试：私教这群是"拉"（自己天天回来用、催着要打卡功能）；大课群是"推"（她得催）。

判据 / 决定：PMF 不是全人群成立，而是先在"私教/系统训练教练"这个细分人群成立。→ 迭代聚焦这群人，把"打卡反馈闭环"做深（正好是第三章第 5 个测试者 + Step 6 那位教练反复指向的缺口）。

📌 教学点：这是 MVP 阶段最值钱的一课——漂亮的 80 注册是"发布能量"（朋友捧场），不是 PMF；真 PMF 藏在一个被平均值掩盖的细分人群里。 没有 Step 3 的度量框架，她已经带着"假 PMF"冲进发布阶段、烧钱推给错的人了。

总闸 · 真实 PMF 证据？

→ GO。 小琳进入发布阶段——但她的产品定位，已从"给所有瑜伽教练"收窄到"给私教/系统训练教练的课后跟练闭环工具"。

这个案例真正教会你的 4 件事

1. 漂亮的早期数字往往是"发布能量"，不是 PMF。 —— 朋友捧场的 80 注册差点骗到她；幸亏度量框架是上线前埋的，且提前写好了"假阳性长什么样"。
2. PMF 往往先在一个"细分人群"成立，不是全人群。 —— 对的人群早就在数据里，只是被平均值（整体 15%/25%）掩盖了；拆 segment 才看见 70%/55%。
3. 架构先行 + 范围克制 + CLAUDE.md，是"不懂代码也能持续迭代"的前提。 —— 没有它们，技术债复利、范围蔓延会让她很快被迫重写；地基由人打，施工交给 AI。
4. 工具能极快造出来，但"是不是真 PMF、该聚焦谁、那条模糊反馈是不是核心需求"——全是人盯着证据下的判断。

一句话收尾： 第四章不是"教你怎么把产品造完整"，是"教你用最小的东西，换到真实的 PMF 证据，并在被假象骗到之前认出它"。小琳的故事证明：造得快是 AI 给的，造得对是人挣的。

第五章 · 发布阶段：方法论 + 案例演练

本文分两部分： 第一部分 是一张能直接照着走的落地方法论清单（6 步 + 1 道总闸）； 第二部分 接着第四章的瑜伽教练小琳，把每一步演给你看怎么操作。

配套阅读：[[第四章-MVP阶段-方法论与案例]]（小琳已在第四章拿到 PMF："私教/系统训练教练"细分人群 + 课后跟练闭环工具，并开始收费）。

核心心法（先记死这句）： MVP 阶段证明的是"产品配得上存在"；发布阶段证明的是"业务配得上增长"。核心动作是把你自己从每一个环路里解放出来（建系统），同时还清技术债、扛住生产、让增长可重复——而此阶段最大的诱惑（看起来巨大的扩张机会），往往是陷阱。

第一部分 · 落地方法论 SOP

找到 PMF 是早期最难的问题；发布阶段的挑战变成"保住它"。找到了真实牵引力的公司，仍可能因为围绕产品的组织跟不上而散架。这一章治的就是这个。

总览：6 步 + 1 道总闸

💡 发布阶段 Claude 三形态全开且互相喂：Code 修产品、Cowork 修组织、Claude 把知识落地运营——小团队因此能跑出 n 倍人数的样子。

Step 1 · 还技术债（趁它复利前到期）

• 做什么：MVP 为速度欠的债，现在开始计息——系统性架构审计，修最差的，补测试覆盖。
• 工具：Claude Code（全架构审计）→ Claude（排序到各 sprint）
• 怎么做：让 Claude Code 审出脆弱点/捷径/测试缺口 → 把发现喂给 Claude，排序成"本次发布前必修 / 可等一个 sprint / 当前可接受"。顺便把 MVP 期只在你脑子里的架构决策补进 CLAUDE.md。
• 产出物：修复优先级清单 + 更新后的 CLAUDE.md。
• 判据：下一轮功能开发会不会重新引入同样的问题？测试覆盖够不够拦住？

⚠️ 防坑【技术债到期】：MVP 阶段欠点债是合理取舍；发布阶段那笔债开始计息，越晚修越贵。

Step 2 · 把增长做成可重复、渠道驱动

• 做什么：从"创始人靠人脉/口碑零散获客"，升级到"通过特定渠道可预测地获客，且单位经济清楚"。
• 工具：Claude（分析获客数据）+ 你（判断）
• 要搞清的：CAC（获客成本）、LTV（生命周期价值）、回本周期——这三个数你得知道且站得住脚。哪个渠道能重复？
• 产出物：单位经济模型 + 1–2 个被验证"可重复"的获客渠道。
• 判据：增长还靠不靠你亲自下场？能不能预测"投入 X 获客，得到 Y 用户"？

⚠️ 防坑：别把"一次性爆发"（某篇爆款、某个大 V 转发）当成"可重复渠道"。可重复 = 再来一次还成立。

Step 3 · 把安全合规做成持续工作流

• 做什么：MVP 时简单凑合的安全合规，现在有真实用户、真实数据、可能企业合同——它变成负债了。
• 工具：Claude Code（扫 SOC2/GDPR/HIPAA 等目标市场要求的代码级问题）→ Claude（排优先级 + 设计控制/审计日志/访问管理）
• 关键：把合规嵌进开发周期，不是当一次性项目——合规文档需要持续维护更新。
• 产出物：安全修复序列 + 合规文档与控制清单。
• 判据：企业买家签约前要的东西（控制、审计日志、访问管理），你拿得出吗？

⚠️ 防坑【安全合规不再可拖】：MVP 时漏洞是"理论风险"；产品进生产、真人依赖它的那一刻，就变成真实暴露风险。 注：AI 扫描是辅助，不替代合格的合规审查。

Step 4 · 审计创始人负载 → 建取代你的系统

• 做什么：把你亲自处理的一切（最小任务到最高风险决策）审一遍，分出：可全自动 / 要人但不必是你 / 真正需要创始人判断。
• 工具：Claude Cowork（结构化审计你的运营负载）+ 你
• 怎么做：记录每个重复任务、每个落到你桌上的决策、每个"只因你记得才发生"的工作流 → 让 Cowork 分类 → 为可自动化项设计工作流逻辑（什么触发、决策规则、输出去哪）。
• 产出物：创始人负载清单（三分类）+ 自动化工作流设计。
• 判据：本该 1 小时的决策，是不是正在拖成 1 周？客服是不是因"只有你知道答案"而堆积？

⚠️ 防坑【创始人成瓶颈】：MVP 时"你在每个环路里"是资产；发布时它变成约束。从"做事"转到"设计做事的系统"，是创业里最难的转变之一——因为没有明确的时刻提醒你该转了。

Step 5 · 立起你一直跳过的产品管理流程

• 做什么：建一套无需创始人介入就能触发和运行的轻量、可重复流程。
• 工具：Claude（设计）→ Claude Cowork（运行）
• 要建的：sprint 节奏、动手前的最小 spec 模板、bug 分诊决策树、每周指标简报（covers 什么、怎么分发）。
• 产出物：一套产品管理操作系统 + Cowork 自动跑它的重复环节（排期、路由、报表汇编）。
• 判据：这些流程能不能在你不在场时照常运转？

Step 6 · 抵御"过早扩张"的诱惑（守核心）

• 做什么：当新市场/新人群/融资机会来敲门、看起来像巨大增长时——先二次验证，别直接跳。
• 工具：Claude（把新机会当新假设，重跑第三章式验证）+ 你
• 判据三问：① 新人群的行为/合规/支付/基线预期，和你已验证的核心人群真的一样吗？② 扩进去会不会引入太多新变量，让你读不懂自己的数据？③ 会不会在追新人群时冷落了已验证的核心人群？
• 产出物：扩张机会的 go/no-go 判断（含"小范围试点先验证"的中间选项）。

⚠️ 防坑【过早扩张】：你建立的初始牵引力是真的，但它特定于你的早期受众。过早扩进一个"看似相似实则不同"的市场，是 PMF 的坟墓。

总闸 · 三条退出标准全绿？

全绿才算通过发布阶段，可进规模化：

1. 增长可重复、渠道驱动 —— CAC / LTV / 回本周期你都知道且能站住；不只是留住用户，而是能可预测地获取。
2. 产品扛得住生产负载 —— 基础设施加固、安全合规就位、真实生产条件下可靠（不只是你测过的条件）。
3. 运营无创始人瓶颈 —— 流程和自动化就位，你不再是亲自处理客服/分诊/冲刺规划/报表的那个人。

没全绿就硬进规模化 = 把一个还会卡住、会崩、增长靠你亲自推的东西放大 n 倍。先补绿，再放大。

一页速记

带着 MVP 验证出的 PMF（某细分人群）进场
  └─[Code→Claude] Step1 还技术债（趁复利前，补CLAUDE.md）
      └─[Claude+你] Step2 增长做成可重复（CAC/LTV/回本，找可复制渠道）
          └─[Code→Claude] Step3 安全合规做成持续工作流（不是一次性）
              └─[Cowork+你] Step4 审计创始人负载→建系统（自动/他人/你判断）
                  └─[Claude→Cowork] Step5 立产品管理流程（sprint/spec/分诊/周报）
                      └─[Claude+你] Step6 抵御过早扩张（新机会先二次验证）
                          └─[你] 总闸：①可重复增长 ②扛生产 ③无瓶颈 全绿?

心法重申： 发布阶段把重心从"造产品"挪到"造围绕产品的组织"。把自己从每个环路解放出来是主线；而看起来最大的增长机会，常常是把你拽离核心人群的陷阱。

第二部分 · 案例演练：小琳的发布阶段

接第四章。小琳已在**"私教/系统训练教练"**人群拿到 PMF（D7 70%、Sean Ellis 55%、已转"拉"、开始收费）。产品定位收窄为"给私教教练的课后跟练闭环工具"。现在进入发布。

进场状态

• 现状：核心人群留存好、肯付费、互相安利；但增长靠"教练口口相传"，不可预测。
• 新冒头的问题：用户多了之后系统偶尔崩；客服爆炸；她每天被淹没；而且收费 + 存健康数据，安全合规绷不住了。
• 发布阶段要做的：把口碑变成可重复增长、还债扛住生产、把自己解放出来——并顶住一个即将到来的大诱惑。

Step 1 · 还技术债

怎么操作：用 Claude Code 全面审计 MVP 那套"为快欠的债"。

示例话术： 「审计当前代码库：哪里脆弱、哪些 MVP 期的捷径现在维护越来越贵、哪里测试覆盖薄到下一轮功能会重新引入同样的 bug。出一份按严重度排序的清单。」

实际产出 + 处理：Claude Code 审出——并发量上来后计划生成接口会超时、学员打卡数据没做好索引、几乎没有测试。她把清单喂给 Claude 排序：

• 本次发布前必修：接口超时、打卡索引（直接影响生产可靠性）。
• 可等一个 sprint：补核心路径测试覆盖。
• 顺手：把 MVP 期"只在她脑子里"的架构决策（伤病数据隔离、为什么不上微服务）补写进 CLAUDE.md。

判据：下轮功能会不会重引入同样问题？→ 补了测试 + 文档，风险下降。

📌 教学点：MVP 的"快"是借来的。发布阶段不还，债就开始计息——而 AI 让你欠债更快，所以更要主动还。

Step 2 · 把增长做成可重复

怎么操作：用 Claude 分析她现有的获客数据，找"可重复的渠道"。

示例话术： 「这是我过去 3 个月的新增教练来源数据。帮我算每个渠道的 CAC、这些教练的 LTV、回本周期。哪个渠道是可重复的（再投入还成立），哪个只是一次性爆发？」

实际产出：

• "某次小红书爆款"带来一波，但不可复制（一次性）。
• "老教练拉新教练"（转介）转化最高、CAC 最低、留存最好——这是可重复渠道。
• 决定：把转介产品化——做"邀请有礼"，让最满意的私教教练系统性地带人。

判据：增长能不能预测、不靠她亲自下场？→ 转介渠道可量化、可复制。✅

📌 教学点：别把"爆款"当增长引擎。可重复 = 再来一次还成立。

Step 3 · 把安全合规做成持续工作流

怎么操作：她现在收费 + 存学员伤病数据，又有机构来谈合作要求合规。用 Claude Code 扫缺口。

示例话术： 「按处理用户健康数据 + 付费的标准，扫一遍代码级合规缺口：访问控制、审计日志、数据处理同意、支付安全。出一份修复序列 + 我需要准备的合规文档清单。」

实际产出：Claude Code 扫出缺审计日志、数据导出无同意记录、支付回调校验弱。Claude 帮她排序并设计：访问控制、操作审计日志、学员数据处理同意流程。并把合规嵌进开发周期（每次发版跑一遍），不是做一次就完。

判据：机构签约前要的控制/日志/文档，拿得出吗？→ 正在补齐。

📌 教学点：MVP 时漏洞是"理论风险"；收费 + 存健康数据那刻起，它变成真实负债。 这不是可选项。

Step 4 · 审计创始人负载 → 建取代她的系统

怎么操作：她快被淹没了——用 Claude Cowork 把她手上的一切审一遍。

示例话术： 「帮我审计我每天在做的所有事：客服、bug 处理、教练答疑、发周报、催转介…每一项标注：能不能全自动 / 要人但不必是我 / 真正需要我判断。再为可自动化的设计触发规则和输出。」

实际产出（三分类）：

判据：本该 1 小时的决策有没有拖成 1 周？→ 客服/周报自动化后，她的时间回来了。

📌 教学点：MVP 时"她在每个环路里"是优势；发布时变成瓶颈。从"做事"转到"设计做事的系统"——这步最难，因为没人提醒你该转了。

Step 5 · 立起跳过的产品管理流程

怎么操作：之前全靠她记，现在用 Claude 设计、Cowork 运行。

示例话术： 「帮我设计一套轻量产品管理系统：双周 sprint 节奏、动手前的最小 spec 模板、bug 分诊决策树、每周指标简报（拉我真实数据）。然后让 Cowork 把排期、bug 路由、周报汇编自动跑起来。」

实际产出：一套能在她不盯着时照常运转的流程：bug 进来自动按决策树分诊路由、每周一自动出指标简报、sprint 仪式自动排期。

判据：她不在场流程还转吗？→ ✅

Step 6 · 抵御过早扩张（本章高潮反转）

诱惑来了：一家大型连锁健身房找上门——"把你的工具给我们全国 200 家店的普拉提教练用，先签一笔大的。"看起来像天降增长、一夜放大 100 倍。小琳差点签。

她用 Claude 把这当成新假设，二次验证（三问）：

而且：机构采购要一堆她还没有的合规、SLA、支持体系。

决定：不直接签全量。改为"小范围试点"——先在 3–5 家店验证普拉提教练是否真的留存，同时守住核心私教人群、把转介增长引擎做稳。

判据 / 教学点：看起来最大的机会，常常是 PMF 的坟墓。过早扩进一个"看似相似实则不同"的人群，会稀释你刚刚拿命验证出来的东西。 守核心、小步试，而不是被大单冲昏头。

总闸 · 三条退出标准全绿？

→ GO。 小琳进入规模化阶段——守住了核心私教人群、把口碑变成了可重复的转介增长、把自己从日常里解放了出来，并顶住了那张差点要了她命的大单。

这个案例真正教会你的 4 件事

1. 技术债会计息，MVP 的"快"是借来的。 —— 发布阶段必须主动还，AI 让你欠债更快，越晚修越贵。
2. 创始人最大的瓶颈，是创始人自己。 —— 从"亲自做事"转到"设计做事的系统"，是发布阶段最难、也最值钱的一跳；没人会提醒你该转了。
3. 看起来最大的增长机会（大连锁大单），常常是 PMF 的坟墓。 —— 过早扩进"看似相似实则不同"的人群，会稀释你刚验证出来的核心；守核心、先小步试点。
4. 收费 + 存健康数据那刻起，安全合规从"理论风险"变成"真实负债"。 —— 必须做成持续工作流，不是一次性项目。

一句话收尾： 第五章不是"教你怎么把产品做大"，是"教你把'产品配得上存在'升级成'业务配得上增长'，同时不被自己卡住、不被大诱惑带偏"。小琳的故事证明：增长的上限，往往不是你能不能拿到大单，而是你忍不忍得住不拿。

第六章 · 规模化阶段：方法论 + 案例演练

本文分两部分： 第一部分 是一张能直接照着走的落地方法论清单（6 步 + 1 道总闸）； 第二部分 接着第五章的瑜伽教练小琳，把每一步演给你看怎么操作——也是她从创意到规模化的完整故事线收官。

配套阅读：[[第五章-发布阶段-方法论与案例]]（小琳已通过发布阶段：转介增长可重复、技术债已还、合规嵌入、自己从日常解放，并顶住了大连锁的诱惑）。

核心心法（先记死这句）： 规模化阶段，创始人的角色从"构建者"变成"面向公众的高管"。目标是系统化的增长 + 靠"积累的深度"建可防御护城河 + 整个组织扛得住外部审视。最难的一跳不是技术，是心理——把你亲手建的系统真正交出去、并真正信任它。

第一部分 · 落地方法论 SOP

前三阶段你"贴着用户、摸着数据"就能往前走；规模化阶段，增长要靠成熟的组织运营来维持。从数千用户到数百万、从一个市场到多个市场，赌注更高、审视更严。这一章治的是"把一场赌注，变成一门生意"。

总览：6 步 + 1 道总闸

★ = 规模化的真正主战场：护城河。前三阶段比"谁先做出来"，规模化比"谁的东西别人抄不走"。

Step 1 · 把日常彻底交出去

• 做什么：清醒地划出"此阶段只有你该做"的事；其余一律委派或交给 Cowork 自动化，并把已建系统打磨到值得信任、然后真正信任它。
• 工具：Claude Cowork（画瓶颈图）+ 你
• 怎么做：让 Claude 列出"只有你该做"的清单（产品叙事、董事会、企业大单、创始人对创始人对话）；再画一张运营瓶颈图——模拟"你一周不在"，哪些工作流会停？ 停的就是你还卡着、还需收紧移交标准的地方。
• 产出物：创始人专属事项清单 + 瓶颈图 + 待加固的移交点。
• 判据：你消失一周，公司还转吗？

⚠️ 防坑【委派的心理关】：交得太多太快（尤其交给 AI）→ 关键决策缺你才有的上下文；抓得太久 → 你又成瓶颈。这一跳，结构难，心理更难。

Step 2 · 技术运营升级成企业级基础设施

• 做什么：买家不再只看你的产品，要看你的组织能不能当长期基础设施伙伴。代码库内部照常迭代，但现在要处理围绕代码库的技术工作。
• 工具：Claude（写文档/SLA/支持手册）+ Claude Code（按企业可靠性/安全标准加固，建日志/监控/事件响应/可观测性）+ Claude Cowork（跑企业支持运营层：工单路由、升级、续约跟踪、报告节奏）
• 产出物：产品文档 + SLA + 可观测性层 + 企业级支持运营。
• 判据：一个签多年合同的企业，签约前要的"可信赖证据"你拿得出吗？

Step 3 · 建一个真正的 GTM 职能

• 做什么：有机增长有天花板，多数创始人在这撞上。要建一台专门的增长引擎触达更广人群（含投资人、企业买家）。
• 工具：Claude（从零搭 GTM 资源：市场细分、信息架构、分析师关系、销售手册、面向投资人的指标叙事）→ Cowork（战术执行层：内容管线、外呼、PR 节奏、CRM、管线报告）→ Code（产品营销基础设施：交互式 demo 环境、集成文档、沙箱租户、API 参考）
• 产出物：品牌叙事 + 各受众的信息打法 + 自动跑的 GTM 引擎 + 异步成交的 demo 环境。
• 判据：增长还只靠"创始人亲自卖"吗？能不能触达"整类受众"而非单个用户？

📌 教学点：GTM 不必庞大就有效；当初造产品的同一套 AI 基础设施，也能帮你把它推向市场。

Step 4 · 把领域知识灌进 AI，铸造护城河 ★

• 做什么：把创始人脑中的领域专长（行业黑话、监管陷阱、边缘情况、为什么显而易见的答案行不通）外化成 AI 可触达的结构化上下文。
• 工具：Claude（长对话/项目/记忆捕捉知识）+ Skills（把重复工作流编码成每次同样执行的例程）+ Claude Code（把同行痛点翻译成校验逻辑、prompt 精调、或与小众行业系统的 MCP 集成）
• 产出物：一个通用 AI 无法匹敌的专有知识基底 + 一套会增长的行业边缘用例测试集。
• 判据：一个通用工具会在你的垂直里哪个边缘情况上翻车，而你的不会？

📌 教学点：每遇到一个"通用竞品一定会搞错"的边缘情况，就给它建一个测试用例。你的测试集，会变成你护城河的一张地图。

Step 5 · 把用户数据复利成可防御优势 ★

• 做什么：用户每次交互都在产生行为信号（接受/拒绝哪些输出）→ 喂回产品改进。每次改进让产品更有用 → 更多使用 → 更多反馈 → 更多改进。
• 工具：Claude（审计已收集的交互数据、找信号最强的行为模式、设计"使用→系统性模型改进"的反馈回路）+ 你
• 产出物：数据飞轮 + 一页"护城河叙事"（飞轮怎么转、转了多久、为什么资源充足的竞品两年内也复制不了）。
• 判据：你这份"成千上万用户在你产品里打磨工作流"的行为指纹，是不是时间锁定、买不到、抄不走？

Step 6 · 创造工作流锁定（让人离不开）

• 做什么：数据网络效应让产品难被复制，工作流锁定让产品难被离开。用户在你产品里跑得越久，越深地嵌进他们的日常。
• 工具：Claude（按"集成深度"给客户分群，找产品在哪粘住、哪需更深）→ Claude Code（快速搭与目标用户所依赖系统的原生集成；建 API/webhook/SDK 让客户在你之上构建——最深的锁定）
• 产出物：客户集成深度图 + 切换成本估计 + 加深集成的路线。
• 判据：对客户而言，"换掉你"是一个产品决策，还是一个全规模运营工程？

📌 教学点：当用户在你之上建了自动化、训练了人、接了数据源和别的工具——换你就从"换个软件"变成"重做一遍运营"。 这是最深的护城河。

总闸 · 阈值事件（不再是单一里程碑）

规模化的退出不是某个点，而是一个状态：即便你越来越不直接管日常，公司依然可持续。 通常表现为三种之一：

1. 可持续盈利（规模上不再需要外部资本）
2. IPO 就绪
3. 被收购

三者都要求：增长系统化且可审计、产品护城河经得起审视、组织运营成熟可持续。 核心拷问："如果一个资金雄厚的巨头今天复制你的产品，你的用户会留下来吗？"

当答案是"会"——恭喜，你的创业公司从一场赌注，变成了一门生意。

一页速记

带着发布阶段的可重复增长 + 稳固组织进场
  └─[Cowork+你] Step1 把日常交出去（你一周不在，公司还转吗？）
      └─[Claude+Code+Cowork] Step2 升级企业级基础设施（文档/SLA/可观测性）
          └─[Claude→Cowork→Code] Step3 建真正的 GTM 职能（触达整类受众）
              └─[Claude+Skills+Code] Step4 领域知识灌进AI → 护城河 ★
                  └─[Claude+你] Step5 用户数据复利成数据飞轮 ★
                      └─[Claude→Code] Step6 工作流锁定（让换你=重做运营）★
                          └─[你] 总闸：盈利/IPO就绪/被收购 —— 巨头抄了用户会留吗?

心法重申： 前三阶段比"谁先做出来"，规模化比"谁的东西别人抄不走"。护城河（领域知识 + 数据飞轮 + 工作流锁定）是主战场；而最难的，是把你亲手建的一切真正交出去、并信任它。

第二部分 · 案例演练：小琳的规模化阶段（收官）

接第五章。小琳的"私教教练课后跟练工具"已有可重复的转介增长、稳固的组织和合规。现在她要把它从"一个不错的产品"变成"一门经得起审视的生意"——并完成从教练到 CEO 的角色蜕变。

进场状态

• 现状：核心人群稳、增长可重复、自己已部分解放；那家连锁的小范围试点也在跑。
• 新阶段的命题：从数千教练走向数万、甚至开始有投资人/收购方接触；产品要能扛外部审视；而她得学会当一个不再凡事亲力亲为的 CEO。
• 真正的胜负手：护城河——别人能不能两年内抄出一个一样的她。

Step 1 · 把日常彻底交出去

怎么操作：用 Claude Cowork 画瓶颈图，逼自己面对"放手"。

示例话术： 「列出'此阶段只有我该做'的事。再画一张瓶颈图：模拟我一周完全不在，我现在经手的每个工作流会怎样？哪些会停？」

实际产出：

• 只有她该做的：产品叙事方向、和投资人/收购方对话、连锁试点的战略决策、教练社区的灵魂人物角色。
• 一周不在会停的：新功能拍板（还卡在她）、关键教练的私人关系维护（只有她有）。→ 这两处需要加固移交：建产品决策框架、培养社区负责人。

判据：她消失一周公司还转吗？→ 大部分能转，两个卡点正在交出去。

📌 教学点：这是心理关。小琳一开始很难接受"新功能不由我拍板"——但抓着不放，她就是天花板。从教练到 CEO，第一道坎是学会信任系统。

Step 2 · 技术运营升级成企业级基础设施

怎么操作：连锁试点要往全国推，企业买家要"可信赖证据"。三形态齐上。

示例话术： 「按企业客户标准，帮我：①Claude 写产品文档、SLA、支持手册；②Claude Code 加固代码库到企业可靠性/安全标准，建日志、监控、事件响应、可观测性；③Cowork 跑企业支持运营层：工单路由、升级、续约跟踪、报告节奏。」

实际产出：一套企业级支持姿态——有 SLA、有可观测性（SLA 才真能执行）、有自动化的工单与续约管理。一个小团队，撑起了大组织才有的支持体面——这正是签多年企业合同要她证明的。

判据：企业签约前要的可信赖证据拿得出吗？→ ✅

Step 3 · 建一个真正的 GTM 职能

怎么操作：口碑转介有天花板了，要建专门增长引擎,还要会跟投资人/企业买家说话。

示例话术： 「帮我从零搭 GTM：市场细分、信息架构、销售手册、面向投资人的指标叙事。然后 Cowork 跑内容管线、外呼、PR、CRM、管线报告。Claude Code 给企业买家做一个交互式 demo 环境 + 集成文档。」

实际产出：

• 针对三类受众的不同话术：私教个人教练、连锁机构采购、投资人。
• 一个异步成交的 demo 环境——她开董事会时，机构采购自己上手试、自己被说服。

判据：增长还只靠她亲自卖吗？→ 引擎自己跑。✅

📌 教学点：当初用 Claude Code 造产品的同一套能力，现在用来造"产品营销基础设施"。GTM 不必庞大，但必须系统化。

Step 4 · 把领域知识灌进 AI，铸造护城河 ★

怎么操作：这是小琳真正抄不走的东西——6 年带 200+ 学员的瑜伽私教 know-how。用 Claude + Skills + Code 外化。

示例话术： 「我把我所有的私教经验讲给你：不同伤病（腰突、肩颈、产后）的禁忌体式、循序渐进的编排逻辑、学员卡在哪个阶段最容易放弃、为什么网上通用计划会练伤人…帮我结构化成可搜索的上下文。再把'给腰突学员编课后计划'这类重复流程做成 Skill，每次同样执行。」

实际产出：

• 一个专有瑜伽康复知识基底：通用 AI 生成计划会忽略伤病禁忌（甚至练伤人），她的产品有专门的安全校验逻辑。
• 一个不断增长的"边缘情况测试集"：每遇到一个"通用竞品一定会搞错"的康复场景（如孕期/术后），就加一条。

判据：通用工具会在哪个边缘翻车而她的不会？→ 伤病安全这条，通用工具根本不懂。

📌 教学点：这就是第二章我们聊的"领域专长 + AI"真正变现的地方。 素人创始人唯一抄不走的，就是这套灌进产品里的深度领域 know-how——而且它每天还在长。

Step 5 · 把用户数据复利成数据飞轮 ★

怎么操作：成千上万教练 + 学员在产品里产生的行为数据，用 Claude 变成飞轮。

示例话术： 「这是我产品的交互数据：教练接受/改写了哪些 AI 生成的计划、学员在哪些体式上打卡完成率高/低、哪些计划带来续课。找出信号最强的三个行为模式，设计'使用→模型改进'的反馈回路。再帮我写一页护城河叙事。」

实际产出：飞轮转起来——AI 越来越懂"什么计划学员真的会练完、教练真的会用"，计划质量↑ → 用得更多 → 反馈更多 → 更准。护城河叙事：这份"几万教练打磨过的康复跟练行为指纹"，时间锁定、买不到、新玩家两年内复制不了。

判据：这数据抄得走吗？→ 抄不走。✅

Step 6 · 创造工作流锁定

怎么操作：让教练离不开。用 Claude 按集成深度分群，用 Code 加深嵌入。

示例话术： 「按集成深度给我的教练分群：每群在我产品上建了什么工作流、依赖哪些集成、切换成本多高。再帮我用 Claude Code 建：和他们常用的微信/收款/课表系统的原生集成、以及让头部工作室在我之上搭自己流程的 API。」

实际产出：头部私教工作室把整个课后服务流程搭在了她产品上——接了收款、学员档案、自动跟练提醒。对他们而言，换掉她 = 重做整套运营，不再是"换个 App"。

判据：换她是产品决策还是运营工程？→ 已是运营工程。✅

总闸 · 阈值事件

→ 她的公司，从一场赌注，变成了一门生意。 路径上她将面对三种归宿之一：可持续盈利 / IPO 就绪 / 被收购。

这个案例真正教会你的 4 件事

1. 规模化比的不是"谁先做出来"，是"谁的东西别人抄不走"。 —— 前三阶段拼速度，这一阶段拼护城河（领域知识 + 数据飞轮 + 工作流锁定）。
2. 素人创始人唯一抄不走的，是灌进产品里的深度领域 know-how。 —— 这正是第二章那个悖论的答案：领域专长一旦被结构化进产品 + 数据飞轮 + 锁定，就不再是"做成产品就被解码"，而是越用越深、越抄越难。
3. 最难的一跳是心理，不是技术。 —— 从"凡事亲力亲为的教练"到"信任系统的 CEO"，放手比建系统更难。
4. AI 全程是放大器，但"做不做这门生意、护城河押在哪、什么时候放手"——全是人下的判断。 —— 从第三章到第六章，这条线从未变过。

一句话收尾（全四阶段收官）： 从创意到规模化，AI 帮小琳把"造"的成本一路压到接近零——但让她活下来的，从来不是 AI 造得多快，而是她在每个阶段都盯着真实证据、做对了那个只有人能做的判断：该不该做、是不是真 PMF、忍不忍得住不扩张、护城河押在哪。造得快是 AI 给的，造得对、造得久，是人挣的。