创始人手册：打造人
工智能原生初创企业
米 克劳德
The Founder’s Playbook:
Building an AI-Native
Startup
Idea Stage 8
MVP stage 15
Launch stage 21
Scale stage 25
Same job, new rules 31
Resources 33
2
目录
面向2026 年重启的创业公司生命周期 3
创始人的含义正在发生变化 5
创意阶段 8
最小可行产品阶段 15
发布阶段 21
扩展阶段 25
同样的工作，新的规则 31
资源 33
Contents
The startup lifecycle, rebooted for 2026 3
What it means to be a founder is changing 5
Idea Stage 8
MVP stage 15
Launch stage 21
Scale stage 25
Same job, new rules 31
Resources 33
2
Chapter 1
3
面向2026年重启的创业公司生命周期
Chapter 1
The startup lifecycle,
rebooted for 2026
3
Chapter 1
4
面向2026 年重启的创业公司生命周期
人工智能正在重塑创业公司的构建方式。那些从未写过一行代码
的创始人如今正在交付生产应用程序，而由10人组成的精简独角
兽公司已从斗志旺盛的失败者故事转变为深思熟虑的行动计划。
在2026年，人工智能可以编写生产代码、进行市场研究、综合竞
争格局、起草投资者材料并自动化运营工作流程。通过消除即使
是经验丰富的技术创始人在整合将想法变为现实所需的工具、平
台和系统时也曾面临的一度陡峭的学习曲线，人工智能首先在谁
能创办初创公司或打造产品方面创造了公平的竞争环境。
在2026年，一个好点子能让创始人比以往走得更远。智能编码将
过去需要一个工程师团队完成的工作压缩为创始人自己就能交付
的成果。
传统的创业公司增长轨迹假定，从想法到规模化的路径是验证
融资 招聘 构建 再次融资 增长 招聘更多人员
重复。如今，人工智能已经打破了这样一种预期，即创业公
司生命周期中的每个新阶段都需要一个更大的团队、一套不同的
技能组合以及一轮新的融资。
本手册根据这些新现实重新规划了创业旅程的四个核心阶段（想法
、最小可行产品、推出和规模化）。我们研究了在人工智能成为技
术和组织发展核心的情况下，每个阶段是什么样子，每个阶段适用
的正确工具是什么，以及使用这些工具的创始人是如何压缩时间线
的。如果您准备好规划从想法到退出的最短路径，请继续阅读。
Chapter 1
The startup lifecycle, rebooted for 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.
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.
In 2026, a good idea gets founders further than ever. Agentic coding compresses
what used to take a team of engineers into work a founder can ship themselves.
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.
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 using these tools are
compressing timelines. If you’re ready to map the shortest path between idea and
exit, read on.
4
5
第2章
成为创始人的意义正在发生变化
Chapter 2
What it means to be a
founder is changing
5
Chapter 2
6
成为创始人的意义正在发生变化
创始人过去常由他们能做的事情来定义：技术型创始人编写代码
，非技术型创始人运营业务并完成交易。但到了2026年，创始人
可用的模型、系统和人工智能代理打破了“能构建的人”和“有值得
构建的想法的人”之间的界限。
原生人工智能的创业公司正在从根本上改变成为创始人的意义。
现在，一个没有工程背景的人可以构建将其想法变为现实的生产
软件，而一个技术娴熟但商业知识匮乏的创始人也能轻松制定上
市策略、财务模型和一份非常精美的推介资料。
从历史上看，创始人大部分时间都处于执行模式：编写代码、管
理人、处理日常运营工作。在原生人工智能的创业公司中，创始
人的角色不再那么像是个体贡献者，而更像是代理的协调者——
专门的人工智能助手，它们可以读取文件、运行命令、执行代码
，甚至浏览网页。创始人的注意力向上转移到更高层次的工作：
产生想法并指导将这些想法付诸实践的系统（人工智能代理、工
具以及任何现有的小团队）。
不过，人工智能作为核心基础设施最具革命性的结果是，为具有
主题专业知识的非技术型创始人消除了障碍。当创始人群体扩大
到超出有工程背景的人时，你会看到由有着截然不同生活经历的
人创建的创业公司，它们正在解决传统科技创始人渠道从未优先
考虑（甚至可能从未注意到）的实际问题。
面向精益创业公司的人工智能工具能力
传统的创业公司模式假定，你需要雇佣工程师来构建、销售人员
来销售、运营人员来经营业务。员工数量被视为组织发展动力和
产品成熟度的标志。
2026年的早期创业公司截然不同。它们在设计上极其精简，通常
只有创始人独自一人或与其他几个人组成的团队。通过将技术和
组织发展都以人工智能作为基础设施为核心，它们在扩大团队规
模之前就能实现产品验证、早期收入甚至盈利。人工智能尤其在
三个方面帮助创业公司像一个规模大得多的组织一样运作：研究
、代理编码以及关键业务运营工作流程自动化。
对话式智能与研究
想象一下：每个领域的随时待命专家
想想创始人在第一年几乎肯定不知道但又需要了解的所有事情：
我如何设置工资单？我如何规划产品开发冲刺？我如何起草一份
简洁的投资者备忘录？
像这样的早期创业公司问题过去都只有一个答案，那就是找个懂
行的人。对于自力更生或处于种子轮前阶段的创始人来说，这可
能会消耗用于知识收集而非构建的时间，或者可能需要在顾问身
上花费一大笔早期资金。现在，他们有了人工智能这个涵盖每个
可想象领域的随时待命专家。
• 深度研究：竞争分析、市场规模评估、财务建模
• 文件起草：商业计划书、案例分析、投资者备忘录、产品需求文档
• 战略思维伙伴：唱反调分析、事前检验、情景规划、路线图
优化
Chapter 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."
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 easily produce a go-to-market strategy, a financial
model, and a highly polished pitch deck.
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.
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 tool capabilities for lean startups
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.
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?
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.
• 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
6
7
智能编码
思考：随时待命、从不受阻的工程师
过去，在编写一行生产代码之前，构建软件通常需要一位技术联
合创始人、一家合同开发公司，或者有足够长的运营期来组建一
个工程团队。
智能编码工具现在允许每个有抱负的创始人用通俗易懂的语言描
述他们想要构建的东西，并指导人工智能以完整工程团队的速度
和规模生成、测试、调试和重构一个生产级代码库。
从“我有一个想法”到“我有一个产品”的时间线已经压缩。现在创
始人的角色主要集中在构建什么以及为什么构建上，而人工智能
则负责为真实用户构建实际可用的真实基础设施。
工作流程自动化
思考：按需提供的自动化运营团队
即使创始人能像顾问一样进行研究，像工程团队一样进行构建，
但在战略规划或产品开发之外，仍有一整类工作必须完成。日程
安排、更新客户关系管理系统、拉取每周报告、保持文档更新、
发布内容、跟踪合规要求、管理公司所使用的工具和系统之间的
连接组织等等，这些也都必须进行。在精益创业中，这些工作主
要落在创始人身上，这对本应用于更高层次决策的时间和精力来
说是一项巨大的负担。
使用人工智能工具进行工作流程自动化减轻了这一负担。重复性
的运营任务可以配置为自动执行，这样当交易进展时客户关系管
理系统会自动更新，每周报告会自动生成，产品文档会与产品变
更同步更新。至关重要的是，Claude Cowork可以与初创公司所使
用的相互连接的系统集成，如项目管理工具、通信栈、数据源，
而无需有人去构建和维护这些集成。在初创公司成立的第一天，
那个人几乎总是创始人。
时机和协调至关重要
有效利用人工智能的研究、自动化和智能编码能力的创始人可以
打造一家运营效率远超其员工数量所显示的初创公司。他们还能
将大部分时间和精力投入到真正重要的工作中。
这项工作并非自动进行；协调这些人工智能工具的创始人需要知
道如何（以及何时）应用它们。本手册的其余部分致力于探索创
始人在遵循人工智能原生创业路径时将遇到的目标和挑战，以及
如何在旅程的每个阶段有效应用人工智能工具。
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.
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.
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.
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.
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.
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.
7
Chapter 3
8
创意阶段
Chapter 3
Idea Stage
8
Chapter 3
9
创意阶段
每位初创公司创始人都从同一个起点出发：一个他们无法停止思
考的问题。这是创意与现实相遇的创业阶段：要在2026年取得创
业成功，就需要有这样的原则，即在有充分证据证明可行之前不
进行构建。
在这个阶段的工作是进行研究、客户探索、竞争分析，以及在要
求Claude Code生成第一行生产代码之前，对反证进行如实评估。
创意阶段目标
在创意阶段，创始人的主要目标是以研究为导向进行验证：在投
入资源进行构建之前，收集确凿的证据，证明存在一个实际问题
（并且你提出的解决方案能够有效解决该问题）。
实际上，创意阶段是创始人必须大致按此顺序回答的一系列
问题：
• 这个问题是否真实、具体且频繁到值得围绕它构建产品？
• 到底是谁有这个问题，这是一个市场吗？
• 有没有其他人在解决这个问题，如果有，是如何解决的，效果如何？
• 为了解决这个问题，解决方案实际需要做什么，我的想法能做
到吗？
这些询问的结果汇总起来要回答一个最终问题：这值得构建吗？
这意味着在行动之前要明确具体。“人们在费用报销方面存在困扰
”只是一种观察。“中型市场公司的财务经理每周花费四个多小时
核对报销提交，因为他们目前的工具无法与会计软件集成”是一个
可验证的假设。
创意阶段退出标准
创意阶段的退出条件是找到问题与解决方案的契合点。在开始构
建解决问题的产品之前，你已经从与真实用户的对话中获得了定
性证据，证明你正在为真实的人解决一个真实的问题。
当你能对以下三个问题都给出肯定回答时，就准备好离开创意阶
段：
1. 问题是否真实且具体？要肯定回答这个问题，你需要确切说出谁遇到了
这个问题，他们多久遇到一次，问题对他们的影响有多严重，以及他们
目前对此采取了什么措施。
2. 你的解决方案是否解决了实际问题？不是你最初设想的问题，而是
验证过程中揭示的问题。有时这两者是相同的，但并非总是如此。
3. 你是否有足够的迹象表明值得构建？在这个阶段你永远不会有确
定性，等待确定性本身就是一种失败模式，但你需要足够的定性
证据，以证明致力于构建最小可行产品是一个经过深思熟虑的决
定，而不是凭信念行事。
创意阶段的挑战
创意阶段是你创业旅程中最重要的工作发生的地方，因为正是在
这个阶段会犯下最严重的错误：现在出错可能会迅速让你初露头
角的企业偏离正轨。然而，构思阶段的大部分挑战都涉及行动速
度超过了你的理解所能证明的合理程度，因此，深思熟虑地推进
的创始人将取得稳步进展。
Chapter 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.
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.
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, and 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.
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.
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.
9
10
将构建误认为验证
挑战：当技术障碍被消除时，充满激情的创始人有可能跳过创业
旅程中最重要的工作：验证他们的想法确实是人们需要并会使用
的解决方案。
即使在当前的智能编码时代之前， 的初创公司失败是因为
他们构建了没人想要的东西。然而现在，像Claude Code这样的
智能编码解决方案极大地缩短了“我有一个想法”和“我有一个产
品”之间的距离，而且失败率只会上升。
虽然现在对于有一个令人震惊的好想法的创始人来说是前所未有
的好时机，但直观地说，快速轻松地创建一个看起来像产品的原
型也给人工智能原生初创公司带来了真正危险的生存风险。
直到最近，构建还需要实际的开发时间和预算，而且即使是拼
凑一个基本的原型通常也需要数月时间。然而现在，技术开发
的障碍基本消除了，人工智能让创始人太容易直接跳入构建阶
段，而没有在现实世界中验证其效用。
要实现问题与解决方案的匹配，首先需要验证你的假设，然后再
进行构建，但许多首次创业（甚至有经验的）创始人错误地认为
人工智能绕过了这一要求，将流程变成了有一个想法 -> 立即构建
一个原型 -> 将原型的存在视为验证。原型成为了相信假设一直正
确的理由，而从未测试过它是否真的正确。
一个能运行的原型很容易被误认为是你正在解决一个实际问题的
具体证据，但事实并非如此。你的原型反而可以作为与潜在用户
对话时有用的压力测试工具。这些对话本身才是真正的证据。
过早扩张
挑战：当构建变得轻松且即时，你可以在业务需求之前就大幅
扩大执行规模。
过早扩张意味着在你真正验证这条道路值得投入之前就致
力于某一产品路径。
这一直是初创公司的杀手，但人工智能让创始人更容易在不知不
觉中陷入过早扩张的陷阱。智能编码助手非常强大，很容易在验
证问题与解决方案的匹配之前就大幅扩大执行规模，而从未有意
识地决定偏离正轨。
它会以与对待一个好想法完全相同的热情，围绕一个根本有缺陷
的前提生成、测试、调试和重构代码库。系统中的智能是你的。
在这个阶段的首要任务是让你的理解领先于你的构建，尤其是当
构建如此迅速且感觉如此轻松的时候。
客观性缺失
挑战：向人工智能工具索要支持你已有信念的证据，它就会找到
。如今，确认性偏差有了一个研究引擎。
确认性偏差一直是初创企业中的职业风险：从本质上讲，创始人
对自己的想法充满热情。现在，人工智能工具让确认性偏差的力
量大幅增强。让人工智能验证你的初创企业想法，它就会找到支
持证据；让它评估你的潜在市场规模，它就会找到能让你的总可
寻址市场看起来值得投资的数字。
人工智能听从你的指令，这意味着一个不提出尖锐问题的创始人现
在能够比以往任何时候都更快地为一个糟糕的想法构建一个精心制
作、看似经过充分研究的案例，同时还能完全自信地认为自己实际
上在进行尽职调查。解决办法是使用同样的工具，只是方向相反：
人工智能会像验证一个想法一样彻底地对一个想法进行压力测试。
当研究和结构化的对抗性思维揭示出你的想法需要修正的证据
时，这就是转向的信号。
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.
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.
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.
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.
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.
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.
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 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.
When research and structured adversarial thinking surface evidence that your
idea needs revision, this the signal to pivot.
10
11
Claude 如何帮助处于想法阶段的创始人
让你基于人工智能的初创企业概念度过想法阶段可能感觉要花很
长时间。你是创始人，你只想去构建产品。但这个至关重要的启
动阶段从根本上来说是一个研究和验证的过程，这意味着在全力
投入编写代码之前，要使用能帮助你更严谨思考的工具。以下是
在Claude的各个产品界面（聊天、Claude协作、Claude代码）中使
用Claude的方法，以便在进行适当尽职调查的同时尽快度过想法
阶段。
聊天、Claude协作还是Claude
代码：选择合适的Claude界面
人工智能让初创企业创始人更容易更快地推出产品、自动化
繁琐的工作流程并实现规模化运营，但你使用的界面很重要
。以下是根据手头任务选择使用聊天、Claude协作或Claude代
码的时机。
聊天适用于不离开你当前所在应用程序的快速交流。用于处
理经营公司中持续不断的小任务：从一份冗长的投资者备忘
录中提取一句话要点、在董事会会议前对一个说法进行合理
性检查，或者梳理与团队的一长串Slack聊天记录。
Claude协作适用于实际需要花费时间的知识工作：从多个来
源收集信息、理解并产出成品，比如文档、演示文稿或电子
表格。比如将一文件夹客户通话记录整理成下一次产品评审
的主题发现文档、在融资前从十几个供应商网站构建竞争格
局，或者是每周一早上固定的任务，即从你的连接工具中提
取指标并将每周关键绩效指标简报放入共享文件夹。
Claude代码是为你团队中的工程师提供的智能编码环境：直
接访问代码库、计划模式、git集成以及本地、集成开发环境
或沙盒化云环境。在这里，一个精简的团队可以在不断增长
的代码库中推出功能特性、迁移MVP阶段的遗留代码，并从
原型过渡到生产阶段，而无需等待增加人手。
如果任务是... 使用 原因
一个问题、一次改写、一次
快速头脑风暴
聊天 快速、对话式，无需
设置
基于您的文件和系统进行研
究、分析或生成完整文档
Claude协作 文件夹访问、连
接器、技能、计
划运行
编写、测试或交付软件 Claude代码 代码库访问、差异比较
、git、开发环境
三者在底层共享同一个Claude；不同的是其周围的工
作区。
定义并对问题假设进行压力测试
您自己的领域专业知识和前期研究已经产生了一个假设。首要
任务是对其进行细化，直到它真正可测试。Claude在此特别有
用，可促使明确具体内容：到底是谁有这个问题，频率如何，
严重程度怎样，他们目前对此采取了什么措施？一个无法精确
回答这些问题的问题陈述还未准备好进行验证。
• 练习：与Claude合作，细化您的问题陈述，直到它成为一个可
测试的假设。例如，“合同审查耗时过长”没有实际可测试性。
但“中型市场公司的内部法律团队每个合同审查周期花费3天以
上时间，因为红线是通过电子邮件线程而非单一版本控制文档
进行管理的”则具有很强的可测试性。
您的下一步是要求Claude反驳您的想法，并找到反驳您假设的反
证。这可能会揭示负面市场信号、失败的竞争对手、客户行为模
式以及支持性综合分析可能会悄悄弱化优先级的结构性障碍。
How Claude can help Idea stage founders
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 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.
Chat, Claude Cowork, or Claude Code:
choosing the right Claude surface
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.
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.
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 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.
If the task is... Reach for Why
A question, a rewrite,
a quick brainstorm
Chat Fast, conversational,
no setup
Research, analysis, or
a finished document
built from your files
and systems
Claude Cowork Folder access,
connectors, skills,
scheduled runs
Writing, testing, or
shipping software
Claude Code Codebase access,
diffs, git, dev
environments
The three share the same Claude underneath; what changes is the
workspace around it.
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.
• 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.
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.
11
12
目标是在进行客户发现时，已经针对最强有力的反驳论据对您的
假设进行了压力测试，以便信息性用户访谈真正是开放式的，而
不是寻求确认。
注意：在人工智能初创企业生命周期的每个阶段，将Claude用
作结构化的魔鬼代言人都是一个核心用例。
市场研究与绘制竞争格局
评估你的竞争对手
有一种特定于初创公司的现象叫做竞争对手忽视：即倾向于过于
专注自己的愿景和执行，以至于系统性地低估了其他人在同一领
域的所作所为。幸运的是，人工智能提供了解决办法：让
Claude给出最有说服力的论据，说明在这个解决方案领域中，为
什么一个竞争对手会成功而你却不会。
Claude可以分析他们的方法实际上为什么更好，客户为什么会选
择他们，以及你潜在的差异化因素可能不像你认为的那样具有防
御性。
• 练习：让Claude按层级绘制你的竞争格局：直接竞争对手、间
接竞争对手、潜在收购者以及可能进入你所在领域的相邻参与
者。然后让它论证为什么每个层级对你的成功都构成真正的威
胁，而不仅仅是最容易被忽视的那种威胁版本。
市场研究
Claude Code可以综合公开可用的客户反馈，以找出反复出现的投诉
和未满足的需求。额外收获：这样做本质上是对你竞争对手的客户
进行免费的定性研究。
• 练习：指示Claude Cowork综合你主要来源的竞争对手评论，并确
定现有解决方案尚未解决的主要投诉。如果你的假设解决了其中一
个或多个投诉，那就是问题与解决方案匹配的有力证据。如果没有
，那也值得了解。
Claude Cowork还可以从密集的行业报告、分析师文件和市场研究文档
中提取相关信息和数据；接下来，这些经过清理和综合的输入将成为
Claude分析工作的理想背景。
• 练习：根据公开可用的数据构建TAM/SAM/SOM模型，并对其
背后的假设进行压力测试。确定市场是在扩张、整合还是成熟；
这种背景会影响你对时机和差异化的思考方式。绘制买家格局：
谁掌握预算，谁影响决策，以及这些人是否是同一人。
趋势分析
最后，使用Claude来寻找早期指标，以告诉你是否在正确的时机
进入。跟踪已经在讨论你的问题的Reddit子版块和领英群组，以及
用户在描述他们的问题时使用的准确语言。让Claude识别类似问
题已得到解决的类似市场，并提取成功和失败的经验。找出可能
加速或威胁该机会的监管、技术或人口趋势。
• 练习：让Claude识别三个可能在未来两年对你的市场产生重大
影响的外部趋势——监管、技术或人口趋势，并评估每个趋势对
你的具体假设是助力还是阻力。
注意：本节中的市场研究和竞争格局绘制工作不是一次性的练习
。你将在MVP和发布阶段继续发现并发展你的想法，所以每当你
的假设演变时，重复这些练习很重要。
规划和设计客户发现
你通过与产品的潜在用户交谈所学到的东西的质量取决于(1)你所
问问题的质量，以及(2)你是否向正确的人提出这些问题。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.
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.
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.
• 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.
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.
• Exercise: Direct Claude Cowork to synthesize competitor reviews across your
key sources and identify the top complaints that 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 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.
• 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.
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.
• 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.
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.
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.
12
Who to talk to
13
一个精确的目标概况比一长串联系人列表更有价值得多，包括最
有可能严重经历该问题的具体职位、公司类型、团队结构和资历
水平。从那里，确定这些人实际上可以在哪里找到——他们聚集
的社区、活动、领英群组和Slack工作区——并根据他们与问题的
接近程度建立一个优先联系对象的框架。
要问什么
在确定了你的目标之后，使用Claude来构建面试框架本身：提出正
确的问题，按照正确的顺序，构建方式要能揭示人们实际做了什
么，而不是他们认为自己会做什么。新手创始人常犯的一个错误
是问一个关于未来的一般性、开放式问题（“你会使用这样的东西
吗？”），而不是具体询问相关的过去（“告诉我你上次处理这个
问题的情况。”）
Claude还可以指出你的草稿问题会引导受访者走向何方、过于宽
泛，或者可能产生噪音而非有效信息。Claude还可以帮助你设计
后续问题，以探究受访者的回避回答，或深入挖掘对重要问题的
模糊答案。
如果你的假设涉及多个角色，Claude还可以为每个角色设计不同
的问题集。财务经理和首席财务官对同一个问题有不同的关系，
单一的面试框架会模糊这种区别。
• 练习：首先手动起草你的面试问题，让Claude审核它们。特别
要求它标记任何引导性、面向未来、过于宽泛或可能产生符合
社会期望而非真实答案的问题。然后要求它为面试中最有可能
产生回避回答的两三个环节提出后续追问。
面试后分析
每次谈话后，使用Claude进行总结：将你的笔记提供给它，让
它确定哪些证实了你的假设，哪些对其提出了挑战，以及哪些
是
真正令人惊讶的。一旦你收集了一批面试记录，将你所有的面试
笔记通过Claude Cowork进行梳理，以找出反复出现的主题、矛盾
点以及正反两方面最强的信号。然后将那个综合输出结果反馈给
Claude，让它指出你自己对数据的解读可能在哪些地方是在与你
想听的内容进行模式匹配，而不是与实际存在的内容进行匹配。
• 练习：每进行五次面试后，让Claude Cowork梳理你的笔记并生
成两个列表：支持你假设的证据和挑战你假设的证据。如果第一
个列表明显比第二个长，问问Claude这种不对称是反映了数据中
的实际情况——还是你希望找到的情况。
客户拓展与安排
使用Claude Cowork来自动化围绕建立联系人列表、进行拓展以
及安排用户面试的运营工作。
Claude Cowork可以使用你用Claude定义的目标档案（包括职位头衔
、公司类型和资历水平）来研究并编制一份结构化的潜在客户列表
和经过验证的联系信息。然后它会大规模起草个性化的拓展邮件，
根据每个人的角色和背景进行定制。
当收到回复时，它通过MCP连接到Gmail和谷歌日历来管理对话线
程、处理日程安排请求，并将面试安排到日程中。工作流程会继
续，Claude Cowork会按照定义的节奏生成后续草稿（例如，对未
回复的联系人在第七天进行跟进），并在每个步骤完成时更新你
的跟踪表，这样你始终知道每个潜在客户在流程中的进展情况。
• 练习：将你经过验证的面试目标档案提供给Claude Cowork，
让它建立一个潜在客户列表，起草一个个性化的拓展序列，并
设置一个跟踪表，其中包含拓展状态、跟进节奏和面试完成情
况等列。然后让它进行协调工作，而你则专注于为对话本身做
准备。
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.
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 can flag where your draft questions are leading the respondent, too
broad, or otherwise likely to generate 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.
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.
• 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.
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.
• 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.
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 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.
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 workflow 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.
• 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.
13
14
设计你的最终解决方案概念
你已经完成了验证工作：问题是真实存在的，你知道谁有这个问
题，并且你有一个证据支持的解决方案概念。使用Claude从各个
角度来发展和挑战你的解决方案概念：有哪些差距？存在哪些替
代方案？这个解决方案要在大规模实施时可行，必须满足哪些条
件？这是一个重要的现实检验点：这个设计实际上解决的是验证
过程中揭示的问题，而不是你最初假设的问题吗？
• 练习：向Claude展示你的解决方案概念，并要求它找出你的设
计最依赖的三个假设。然后询问每个假设成立需要满足什么条件
，以及如果其中任何一个假设不成立会有什么后果。
使用Claude Code 构建一个轻量级原型
现在到了有趣的部分：有了经过验证的假设和经过压力测试的
解决方案概念，你终于准备好构建一些东西了。
在创意阶段的这个时刻，Claude Code进入了画面。即使你一直在
进行尝试，现在也是你生成官方轻量级原型的时候了：将你的想
法展示给真实的人并获得真实反应所需的最小表面积。
你还没有构建一个实际的产品；你正在构建你的想法的功能样
本，用于与客户和投资者的对话。真实用户对他们实际可以触
摸的东西做出反应，会告诉你许多问题 - 解决方案发现访谈无
法告诉你的事情。之前，你在确定你正在解决的问题是真实的
；现在，你要求潜在用户参与所提出的解决方案。
• 练习：定义你的解决方案所依赖的单一核心交互。指示
Claude Code只构建那个。当你完成后，将其展示给来自经过验
证的目标用户群体的五个人，并让他们试用。你在这五次对话
中学到的东西将决定你是继续构建还是回到绘图板。
到达创意阶段的终点是人工智能初创企业竞赛中的一个巨大飞跃
，因为现在你不是基于直觉下注；你是根据证据执行。现在进入
MVP阶段，创始人的指导问题从“这值得构建吗？”变为“我们首
先应该具体构建什么？”，人工智能的主要角色从研究伙伴转变
为施工团队。
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?
• 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.
Build a lightweight prototype with 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.
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.
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.
14
Chapter 4
15
MVP阶段
Chapter 4
MVP Stage
15
Chapter 4
16
MVP阶段
许多创始人将MVP阶段视为一个建设阶段，但MVP阶段从根本上
来说仍然是一个收集证据的过程。不同之处在于，你现在正在收
集关于解决方案的证据，而不是问题空间的证据；具体来说，就
是是否有一个真实的、可识别的人群发现它有足够的价值来使用
它、返回使用它、为它付费和/或告诉其他人。
MVP阶段目标
作为一家原生人工智能初创公司的创始人，你的目标是将经过验
证的问题转化为真实用户实际会使用的可行产品。这不是包含每
个路线图功能的完整版本，而是你想法的最小、最聚焦的迭代，
将一个真正的解决方案展示给真实用户，并生成产品与市场契合
的真实证据。
与此同时，你现在的构建方式决定了以后可能实现的目标。这意
味着MVP阶段还有第二个同样重要的目标，即快速行动，同时
不积累那种会在真实用户大量到来时成倍增加并困扰你的技术债
务。
最后，从第一天开始就投资于持久的上下文，这是使人工智能成
为力量倍增器而不是熵源的关键。在一家原生人工智能初创公司
中，你的代码库是你与人工智能逐会话协作的东西，这使得可读
性成为基础。跳过规范、架构决策和上下文文件（如
）的创始人会遇到一个可预测的障碍，即每个新会
话都需要重新解释代码库，并且人工智能生成的更改会偏离原始
愿景。
MVP阶段退出标准
MVP阶段的退出条件是产品与市场契合的真实证据：证明一个特
定的、可识别的用户群体发现该产品有足够的价值返回使用它（
留存率）、为它付费（收入）或告诉其他人（推荐）。
MVP阶段的挑战
在MVP阶段，创始人的首要任务是速度和判断力。这里的挑战
集中在你是否能够以正确的方式、足够快地构建出正确的产品，
且不偷工减料以免日后付出代价。
代理性技术债务
挑战：由于人工智能本质上消除了曾经控制进入生产环节内容的
每一个自然瓶颈，速度得到了保证。但当速度是创始人在构建
MVP时唯一考虑的变量时，他们就有可能积累难以偿还的技术
债务。
在MVP阶段，一些技术债务是合适的，但前提是要明白在扩大
规模之前必须对其进行管理。它会逐渐积累，可以随着时间推
移或在专门的冲刺阶段清除。然而，人工智能技术债务会不断
累积。
如果没有在某个地方写下来让人工智能能够读取的规范和架构约
束，每次会话都会从头重新推导基础决策，而且这些决策会发生
偏差。最终你会得到一个背后没有连贯心智模型的代码库，不是
因为任何单个部分不好，而是因为这些部分从未被设计成能够协
同工作。这是个真正的问题，而且往往会在后期才显现出来。
Chapter 4
MVP Stage
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 stage goals
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.
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.
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 ) hit a predictable wall where every new
session requires re-explaining the codebase and AI-generated changes drift
from the original vision.
MVP stage exit criteria
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 stage challenges
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.
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.
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.
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.
16
17
陷入虚假的产品 - 市场契合
挑战：人工智能工具可以生成令人印象深刻的早期数据，但这些
并不能保证市场需要你的产品。
早期的发展势头是创始人能够拥有的最具心理影响力的体验之
一。经过数周或数月的验证工作以及精心、有纪律的构建，推
出一款产品感觉就像是确认了你一直都是正确的。
代理性编码工具可以帮助你比以往任何时候都更快地达到这一时
刻，但早期的吸引力并不等同于产品 - 市场契合。推出产品的能
量来自短暂的力量，比如创始人的朋友、投资者其他投资组合公
司的潜在买家，或者一篇引发热潮的黑客新闻头条。不幸的是，
这些都无法可靠地预测在最初的推动消退后的第六周或第十二周
会发生什么。
零摩擦的范围蔓延
挑战：当构建过程感觉毫不费力且成本几乎为零时，总会有一个
更酷的功能可以添加或一个更多的边缘情况需要处理。这种范围
蔓延可能弊大于利。
范围蔓延一直是创业公司的风险。现在的不同之处在于，传统的
限制因素——工程时间的实际成本——在添加一个功能只需一个
下午而非一个冲刺阶段的情况下，不再以同样的方式存在。
这里的挑战在于每个单独的添加都是有道理的。当然产品应该处
理那个边缘情况；当然用户会想要那个工作流程。这些在当下感
觉不像是范围蔓延，因为使用代理性编码构建每个功能都只需很
少的努力，但随着你的产品超出其原始边界，你有可能失去方向
和动力。
解决办法是在开始构建之前创建一个书面的范围定义，描述产品
做什么、故意不做什么，以及来自真实用户的具体证据，这些证
据将证明添加新内容是合理的。这将决策点从“我们应该构建这
个吗？”转变为“大量用户告诉我们如果没有这个功能他们就无法
从产品中获得价值吗？”
因缺乏经验而缺乏安全感
挑战：创始人在未首先理解基本安全原则的情况下就使用人工智
能工具匆忙将应用推向市场，最终会让用户面临可预防的风险。
残酷的事实是，智能编码工具生成的是能运行的代码，而非本质
上安全的代码。功能性代码很容易判断，因为功能要么可用，要
么不可用。安全漏洞在被利用之前是看不见的，这意味着没有自
然的反馈循环来提醒初次创业的创始人出了问题。然而，向真实
用户发布一个可运行的最小可行产品（MVP）意味着真实的数据
、真实的暴露风险，如果出了问题还会带来真实的后果。
轻视安全性并非人工智能原生项目所独有。每个时代白手起家的
初创公司往往会将安全考虑推迟到开发后期，有时甚至等到即将
投入生产的时候。在任何用户接触你的应用程序或解决方案之前
进行安全审查，是向世界发布最小可行产品的最低责任门槛。
Claude 如何帮助处于MVP阶段的创始人
在构建之前定义架构
在Claude Code编写一行生产代码之前，使用Claude定义并记录将
指导此阶段构建的所有内容的架构决策：要遵循的模式、要避免
的依赖关系、正在做出的权衡以及原因。此输出将作为一份重点
突出的架构上下文文档，并建立Claude Code将在其中运行的防护
栏。
没有这个上下文，每次会话都要从头开始，Claude Code就会被
迫推断自己的结构假设。让Claude Code在没有防护栏的情况下
构建会产生一个功能上可用但结构上不连贯的代码库，而在不连
贯的代码库上进行迭代和扩展最终是浪费时间和令牌。迟早会有
一个点，代码不可避免地会崩溃，迫使你从头开始重建。
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.
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.
Zero-friction scope creep
The challenge: When building feels effortless and is nearly free, there’s always
one more cool feature to add or 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.
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.
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.
How Claude can help MVP stage founders
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.
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.
17
18
• 练习：在打开Claude Code之前，打开Claude并描述你正在构建
的内容：它解决的核心问题、服务的用户以及你在未来六个月内
实际期望的规模。要求它帮助你定义应该指导MVP构建的架构
原则、鉴于你的限制要避免的依赖关系以及你在这个阶段有意识
接受的权衡。
接下来，将此输出保存为 markdown文件。这是你
的架构上下文文档：构建的第一个工件，也是每个后续会话所
依赖的文档。文件作为Claude Code的项目级指令
，提供项目特定的上下文和指令，当Agent SDK在一个目录中
运行时会自动读取这些指令。从功能上讲，它们是你项目的持
久“记忆”。
定义并执行MVP范围
无阻碍的范围蔓延是人工智能时代MVP的典型失败模式之一。正
如你定义并记录了产品的应用架构一样，在构建任何一个功能之
前，你还需要定义MVP的范围。
Claude可以帮助你创建一个范围文档，描述你的MVP产品做什么
、故意不做什么以及功能修改标准：来自真实用户的哪些具体证
据能证明此时添加新内容是合理的。
当新的功能想法出现时——它们肯定会出现——你使用
Claude来压力测试这是来自用户的真实信号还是伪装成产品
思维的创始人热情。
使用Claude Code 构建你的MVP
一旦定义了架构和范围，Claude Code就成为主要的MVP构建工具
。使用它来生成、测试、调试和迭代你的代码库，但将每次会话
视为对你已经做出的产品决策的执行，而不是引入一些新决策的
机会。
每次Claude Code会话开始时，先（1）回顾你的范围文档，（2）向模型
提供你的架构上下文文档。每次会话结束时，用会话中出现
的任何决策更新它。目标是得到一个你能解释其结构的代码库，而不仅
仅是一个能运行的代码库。
• 练习：为你的Claude代码工作创建一个简单的会话模板，其中
包括架构上下文文档、本次会话的具体任务以及需要遵守的任何
约束或模式。在每次会话结束时，在上下文文档中添加一个简短
的日志条目，详细说明构建了什么、做出了哪些决策以及本次会
话引入了哪些假设。每次会话花费五分钟进行文档记录，这是防
止架构漂移演变成难以管理的代码库的低成本保障。
在任何用户接触之前进行安全审查
作为一名原生人工智能初创公司的创始人，你的责任是了解代
码库中的内容，理解任何潜在的暴露向量，并且不要向信任你
并提供数据的真实用户发布明显的漏洞。
Claude可以对人工智能生成的代码进行有用的初步安全审查，并
有助于识别常见漏洞。在发布之前将其纳入流程是个好习惯。然
而，它不能替代安全工具，在风险更高的情况下，也不能替代人
工审查——而将其视为替代品的创始人最终会出现在安全漏洞事
件中。
Claude代码安全更进一步：它会扫描代码库以查找安全漏洞，并建
议针对性的补丁供人工审查，揭示传统方法可能遗漏的问题。
注意：在本电子书出版时，Claude代码安全处于有限的测试版发
布阶段，因此在将其纳入工作流程之前，请检查当前的可用性。
• 练习：在部署到任何真实用户之前，使用特定的概要将你的核
心应用代码通过Claude运行：审查认证和会话处理、API响应中
的数据暴露、输入验证和注入风险以及与已知漏洞的依赖关系。
认真对待每个发现，并评估是否需要修复，对于涉及认证、机密
或数据处理的任何内容都要进行人工审查。
• 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.
Next, save this output as markdown file(s). This is your
architectural context document: the first artifact of your build, and the one
every subsequent session depends on. 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.
Define and enforce your MVP scope
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.
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.
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.
Build your MVP with Claude Code
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.
Start each Claude Code session by (1) revisiting your scope document and (2)
providing the model with your 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.
• 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.
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.
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 Code Security goes further: it scans codebases for security
vulnerabilities and suggests targeted patches for human review, surfacing issues
that traditional methods can miss.
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.
• 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.
18
19
在推出之前构建你的衡量框架
那些将早期的用户增长误认作产品与市场匹配的创始人，通常也
是那些在推出产品后才开始跟踪数据的人，他们使用选择用来评
估哪些方面有效的指标，而不是用来揭示哪些方面无效的指标。
解决办法是在第一个用户出现之前就建立你的衡量框架。
使用Claude来定义哪些指标对你的特定产品重要，基准是什么
，以及数据中的哪些模式将构成真正的产品与市场匹配，而不
是令人欣慰的噪音。具体来说：在发布你的最小可行产品（
MVP）之前，设定你的留存基准、激活标准以及第7天和第30天
的目标。
接下来，定义对你的特定产品来说误报是什么样的：例如，没有
激活的注册、没有留存的收入，或者没有重复使用的初始热情。
当数据到来时，让Claude对你自己的用户增长情况提出反对意见
：怀疑论者会对这些数字说什么？
管理发现和用户反馈流程
一旦真实用户进入产品，运营层面就会迅速扩大。Claude
Cowork处理诸如建立和维护用户联系列表、运行推广序列、安排
反馈会议、对错误报告进行分类以及跟踪迭代周期等重要但繁琐
的工作。在创意阶段管理发现流程的相同MCP集成在此处也适用
。
在收集用户反馈的过程中保留人工参与，以便对用户反馈进行细致
入微的探索。例如，用户说“这很棒，但我希望它也能……”，这需
要解读：这是核心需求还是锦上添花的需求？这是特定于这个客户
的情况还是代表一个细分群体？缺少的功能是真正的问题，还是入
门流程中上游的某个环节？没有工具能回答这些问题。
• 练习：配置Claude Cowork来运行你的MVP阶段的反馈循环：
起草给早期用户列表的推广内容、安排反馈会议、设计针对错
误报告和功能请求的结构化接收流程，并撰写每周收到内容摘
要。首先自己审查摘要；之后，你可以让Claude分析信息，以
捕捉你可能忽略的任何重要要点。
朝着证据迭代，而不是朝着完整性迭代
当你有了产品与市场匹配的真实证据时，MVP 阶段就结束了，无
论产品看起来有多“完善”。宣称你已经实现了产品与市场的匹配
，并且现在准备从 MVP 阶段进入发布阶段，这最终是一项将创始
人的直觉与收集到的证据相结合的判断工作。不过，有一些有用
的试金石：
• 肖恩·埃利斯测试：询问你的活跃用户：“如果无法再使用这个产品，
你会有什么感受？”如果超过 40% 的人回答“非常失望”，这就是一个
有意义的产品与市场匹配指标。
• 努力测试：在产品与市场匹配之前，用户留存需要持续干预，
包括频繁的推广、激励、个人跟进，以及创始人投入巨大精力
来保持用户参与度。在产品与市场匹配之后，产品开始自行完
成这项工作。当事情开始产生拉力而非推力时，这种努力的转
变是最明显的信号之一，表明确实有事情发生了变化。
最终，没有单一的数据点能确认产品与市场的匹配，因为这是一
种模式，必须在多个迭代周期中都成立，你才能确定地称之为产
品与市场匹配。
根据证据要求进行转型
要是即便投入了所有这些工作，你似乎还是无法实现产品与市场
的匹配呢？你的结果没有证实你最初的方向这一事实并非失败，
而是系统在起作用：MVP 阶段的设计目的就是在你对错误答案过
度投资之前揭示这些信息。
当数据不支持你当前的产品时，使用 Claude 来梳理这些数
据告诉你的信息。
• 探索其他客户群体。也许那些没有转化的用户从一开始就不是正
确的目标群体。通常正确的受众已经在你的数据中，只是权重较低
。
• 调整你的产品价值主张。也许你有正确的受众，但你的 MVP
就是无法引起用户共鸣。对产品入门引导、信息传达或核心功
能重点进行调整，有可能在不改变你已构建内容的情况下解决
这个问题。
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.
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?
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.
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.
• 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 first; after
that, you can ask Claude to analyze the information to catch any significant
points you may have overlooked.
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:
• 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 in effort is one of the clearest signals that
something real has changed.
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.
When the data doesn't support your current product, use Claude to work
through what that data is telling you.
• 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.
19
Let the answers determine whether you adjust, pivot, or return to the Idea stage.
20
对这种脱节可能足够严重以至于需要更根本改变的可能性保持开
放态度
• 练习：如果你已经完成了三个或更多的迭代周期，但在朝着产品与
市场匹配基准前进方面没有取得有意义的进展，在决定下一步做什
么之前，使用 Claude 进行诊断。将你的留存数据、用户反馈和原始
问题假设提供给它，并问它三个问题：
• 这些数据中是否有一个细分群体的反应与其他群体不同？
• 设计价值与体验价值之间的差距是定位问题还是产品问题
？
• 要使当前产品找到真正的产品与市场匹配，必须满足什么条件，鉴于你所看
到的情况，这种情况现实吗？
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?
Let the answers determine whether you adjust, pivot, or return to the Idea stage.
20
Chapter 5
21
发布阶段
Chapter 5
Launch Stage
21
Chapter 5
22
发布阶段
如果说MVP阶段是要证明你的产品值得存在，那么发布阶段就
是要证明你的业务值得发展壮大。
发布阶段目标
在发布阶段，初创公司创始人必须将早期的初步成功转化为一个
可重复、可持续的增长引擎。除了让你的产品能够投入生产，你
还必须强化其底层基础设施，同时围绕你的产品建立一个实实在
在的公司。
在创意和MVP阶段，初创公司自然是以创始人为主导，因为你需
要全面的态势感知和紧密的反馈循环。然而现在，如果创始人仍
然试图亲自掌控每一个环节，就会成为发布阶段的瓶颈。目标不
是让你脱离公司，而是建立运营体系，将你的注意力解放出来，
专注于只有创始人才能做出的决策。
发布阶段退出标准
发布阶段的退出条件有三个要素：
1. 增长是可重复且由渠道驱动的。你不仅要留住用户，还要通过具有明
确单位经济效益的特定渠道可预测地获取用户：客户获取成本（CAC
）、客户终身价值（LTV）和投资回收期是你了解并能论证的数字。
2. 产品能够处理生产工作负载。基础设施得到强化，安全和合规方面没问
题，并且在实际生产条件下（而不仅仅是你测试的条件）具备可靠性。
3. 运营能够在没有创始人瓶颈的情况下运行。流程已经存在
且自动化已经到位。你不再是亲自处理支持、故障分类、
冲刺计划或报告的那个人。
发布阶段挑战
找到产品与市场的契合点是早期创业生命周期中最难的问题。现
在，创始人的挑战变成了保持这种契合。如果围绕并支持产品的
组织跟不上，那么在发布阶段，那些在产品上获得了真正牵引力
的公司仍可能分崩离析。这些就是需要留意的失败模式。
技术债务到期
挑战：为速度和验证而构建的MVP代码库运行得足以证明产品
可行，但生产流量、新功能以及日益增加的复杂性现在正暴露
了其中的捷径。
在MVP阶段，积累一些技术债务是为了速度而做出的合理权衡。
在发布阶段，这笔债务开始产生利息，而且搁置的时间越长，修
复成本就越高。
解决方案包括进行系统的架构审核以识别结构弱点，进行有针对
性的重构以解决最严重的问题，并大幅扩展测试覆盖范围，以便
下一轮功能开发不会再次引入同样的问题。
Chapter 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.
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 it 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.
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.
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.
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.
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.
22
23
创始人成为瓶颈
挑战：在MVP阶段，创始人参与每一个环节是一项资产。在产品
发布阶段，随着支持量的增长、产品决策的堆积以及运营复杂性
的增加，同样的本能却成为了一种限制。
从亲自做工作转变为设计做工作的系统，这是创业生命周期中最
艰难的转变之一。因为这种转变很少有明确的时刻，所以风险是
完全错过它，在组织围绕着你停滞不前时仍停留在构建者模式。
这种情况发生的明显迹象包括：本应花一小时做出的决策现在要
花一周时间才能处理，支持请求堆积如山，因为只有你知道答案
，以及运营任务只有在你亲自记得去做时才会进行。
补救措施是全面审计你亲自处理的所有事情，从最微小的任务到
最高风险的决策，以便确定哪些可以系统化、哪些可以委派，以
及哪些真正仍然值得创始人投入时间和精力。
安全与合规不再可以拖延
挑战：在MVP阶段，保持安全和合规措施简单是可以的，但现
在，面对真实用户、真实数据以及潜在的企业合同，这就成了
一种负担。
在MVP阶段，有少数测试用户且生产环境中没有敏感数据，安
全漏洞只是理论上的风险。然而，当你的产品带着依赖它的真
实用户进入生产阶段时，这种假设就变成了非常真实的暴露风
险。此外，不适用于原型的合规要求，在你处理客户数据、处
理支付或向受监管行业销售产品时肯定会适用。
补救措施是在生产规模扩大之前，而不是之后，进行系统的安
全和合规审查，并将出现的所有问题都视为在下一波用户到来
之前必须补救的问题，而不是建议。
在准备好之前就扩张
挑战：新市场和资金机会看起来像是增长机会。它们也可
能是产品与市场契合度走向死亡的地方。
你最初建立的吸引力是真实的，但它也特定于你的早期受众。过
早扩展到与你原来的市场有显著差异的市场会引入新的用户行为
、合规要求、支付基础设施以及你的产品未围绕其设计的基本期
望。突然之间有太多新变量，你失去了清晰解读自己数据的能力
。你还冒着在追逐新的、未经证实的受众时忽视原有用户基础的
风险。
Claude 如何帮助产品发布阶段的创始人
Claude的三种形式在产品发布阶段都得到充分利用，并且它们相
互支持：每个工具产生的输出成为其他两个工具的输入。结果有
机地复合，一起使用这三种工具的创始人得到的比各部分之和更
多。
这就是超精简创业模式在结构上成为可能的原因。当Claude
Code构建产品，Claude Cowork围绕它建立公司，并且Claude帮助
将这种产品和组织知识付诸实践时，一个小团队可以像规模为其
n倍的公司一样运作。
在技术债务恶化之前进行补救
你的MVP代码库可以运行，但它也需要进行一次系统的补救，
以查找任何可能成为结构性负担的技术债务。
首先，使用Claude Code进行全面的架构审计：确定代码库哪里
脆弱、哪些捷径维护起来会变得昂贵，以及哪些地方测试覆盖
不足，以至于下一轮功能开发会再次引入相同的问题。
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.
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.
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.
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
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.
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.
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.
First, use Claude Code to run a full architectural audit: identify where the
codebase is brittle, any shortcuts that will become expensive to maintain, and
where test coverage is thin enough that the next round of feature work will
reintroduce the same problems.
23
24
将克劳德代码的审计结果反馈给克劳德，以便对修复工作进行分
类和排序：在下一个版本发布之前需要修复的内容、可以等待一
个冲刺周期处理的内容，以及鉴于当前阶段可接受的持续技术债
务。现在也是记录你在MVP阶段做出的架构决策的时候了（那些
因为没时间写下来而只存在于你脑海中的决策）。现在将它们整
理到中，可确保未来的每次克劳德代码会议都能基于
对系统设计方式和原因的共同理解展开。
• 练习：指导克劳德代码审计你的MVP代码库，并生成一份按
优先级排列的结构弱点、测试覆盖漏洞和重构候选列表。然
后将该列表反馈给克劳德，并要求它在你的几个冲刺周期内
对修复工作进行排序：你需要首先解决的任何重大问题、可
以与功能开发并行处理的事情，以及可以等待的事情。
构建能够替代创始人注意力的系统
构建能够解放你的注意力以处理只有创始人才能解决的职责的运
营系统，需要确切了解你的注意力投向何处。使用克劳德协同工
具对当前的运营负荷进行结构化审计，记录每一项重复任务、落
在你桌上的每一个决策，以及仅因你个人记得去做才会发生的每
一个工作流程。然后让克劳德协同工具将这份清单分类为完全可
以自动化的内容、需要人工但不一定是你的内容，以及真正需要
创始人判断的内容。
审计完成后，使用克劳德协同工具为自动化候选方案设计工作流
程逻辑：每个工作流程的触发条件、决策规则、输出形式，以及
完成后去向何处。
将安全与合规作为一个产品工作流
使用克劳德代码找出SOC 2、GDPR或HIPAA审计以及目标市场要求的标准中经
常出现的代码级问题。这将揭示漏洞和合规差距。将这些发现反馈给克劳德，
以帮助你对修复工作进行优先级排序，并设计企业买家在签约前会要求的控制
措施、审计日志和访问管理。注意：人工智能扫描是一种辅助手段，但不能替
代合格的合规审查。
接下来，将合规工作流纳入你的开发周期，而不是作为一次性项目来运行
；合规文档需要持续维护和更新。对于接近企业合同或国际市场的创始人
来说，此时克劳德代码安全扫描也可以帮助你为独立安全评估做准备。
• 练习：使用克劳德代码针对目标市场要求的框架进行代码级
安全审查。将输出反馈给克劳德，并要求它生成两件事：按优
先级排列的安全修复顺序，以及为满足潜在企业买家的合规审
查你需要生成的文档和控制措施清单。
建立你一直跳过的产品管理流程
发布阶段需要一套轻量级、可重复的流程，这些流程可以在无需创始人干
预触发或运作的情况下运行。使用克劳德设计你的产品时间表和工作周期
的结构、在克劳德代码处理某个功能之前规范需要包含的内容、错误报告
如何分类和路由，以及你的每周指标报告涵盖哪些内容以及如何分发。
流程设计完成后，使用克劳德协同工具构建并运行运营层：安排
冲刺仪式、将传入的错误报告路由到正确的地方、从连接的数据
源编译每周指标，以及维护使用户信号流入产品决策的反馈循环
。
• 练习：要求克劳德设计一个轻量级的产品管理操作系统：定义的
冲刺节奏、最小规范模板、错误分类决策树，以及从实际数据源提取
的每周指标简报。然后设置克劳德协同工具来实施和运行系统的重复
运营元素，如调度、路由和报告编译，使其在没有你的情况下按时进
行。
扩展阶段
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 now ensures that
every future Claude Code session starts from a shared understanding of how the
system was designed and why.
• 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.
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.
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.
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.
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.
• 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.
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.
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.
• 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.
24
Chapter 6
25
规模化阶段
Chapter 6
Scale stage
25
Chapter 6
26
规模化阶段
在规模化阶段，创始人的角色从建设者重新定位为面向公众的高管
。产品仍然是核心，但你日常的个人工作越来越围绕公司本身。即
使你努力保持以人工智能为核心的精益结构优势，你的注意力也必
须扩展到新的规模化阶段活动，如分析师简报和首次公开募股路演
。
规模化阶段目标
扩展技术基础设施的工作仍在继续，现在又增加了扩展组织本身并使
其成熟为一家企业的工作。
在规模化阶段，你要着眼于从数千用户增长到数百万用户，从一个市
场拓展到多个市场。在之前的每个阶段，增长可以通过贴近用户、根
据紧密反馈循环的数据以及创始人的直觉来调整方向来实现。然而现
在，目标是建立由成熟的组织运营支撑的系统性增长。
对于一家原生人工智能初创公司，你的目标应该是通过积累深度来建
立一条可防御的护城河，这种深度源于你构建到产品中的专业知识、
产品与用户依赖的其他工具和平台的集成深度，以及专有系统数据和
工作流程。一直朝着一个方向、在一致的基础设施上持续建设的创始
人，现在拥有了真正难以复制的东西。
在这个阶段，公共投资者、分析师、监管机构、企业采购团队和收
购方会施加更大的压力，同时也会更加怀疑，因为现在 stakes 更高
了。你的产品和组织必须经受住外部审查：不仅是你所构建产品的
能力，还有
围绕它的治理、合规态势、财务控制和战略叙事。
规模化阶段退出标准
规模化阶段的退出条件不再是一个单一的里程碑，而是一个临界事件
：即使创始人越来越不直接参与日常运营，公司仍能持续发展。你已
经展示了系统性增长；建立了满足最严格外部审查者要求的组织治理
和合规基础设施；并且对“如果一个资金雄厚的现有企业今天复制了
你的产品，你的用户会留下吗？”这个问题有一个可靠的答案。
实际上，这个临界值通常会采取三种形式之一：达到不再需要外部
资本的规模下的可持续盈利能力、具备首次公开募股的条件或被收
购。这三种情况都要求你的增长是系统性的且可审计的，你的产品
护城河在审查下经得起考验，并且你的组织在运营上成熟且可持续
。
当达到这种情况时，值得祝贺：你的初创公司已经从一个赌注变成了
一家企业。
规模化阶段挑战
下放运营层面
挑战：规模化阶段的运营系统必须在无人监管的情况下可靠且可持续
地运行。对于从第一天起就亲力亲为的创始人来说，这种转变在心理
上和结构上都是一个挑战。
Chapter 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.
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.
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.
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.
26
27
您在启动阶段的工作是创建系统；在扩展阶段，它变成了（1）使这
些系统成熟，直到它们完全值得信赖，以及（2）然后真正信任它们
。
这比听起来要难。即使您是一位善于授权的创始人，也不总是清楚该
移交什么以及该保留什么。移交过多、过快——尤其是交给人工智能
自动化系统——关键决策就会在没有只有创始人才能提供的关键背景
信息的情况下做出。然而，如果保留时间过长，您可能会成为瓶颈。
这里的根本挑战是识别仅存在于创始人头脑中或未记录的工作流程中
的机构知识，然后将其编纂成有记录、可审计且可转移的系统。
扩展技术运营
挑战：客户不再只评估您的产品；他们想知道您的组织能否成为可
靠的基础设施合作伙伴。
初创公司前三个阶段的技术挑战集中在代码库上：构建正确的解决
方案而不产生技术债务，然后为真实用户强化安全性和合规性。进
入扩展阶段后，现在的挑战变成了围绕代码库构建的一切；创建支
持基础设施、文档以及表明成熟度的可靠性保证。
签订多年合同的大规模客户和机构买家在签约前就想要这些，而且
一旦签约，他们也会要求您兑现。不过，帮助您走到这一步的人工
智能基础设施，也能帮助您建立具有明确响应时间和文档的专门支
持功能，新客户的工程团队实际上可以使用这些文档。
扩展组织职能
挑战：处于扩展阶段的公司通常需要招聘、薪资、会计和法律运营等
组织基础设施，无论运营公司的人数有多少。
在启动阶段，将运营系统化意味着自动化消耗创始人注意力的工作流
程。处于扩展阶段的初创公司现在需要发展更广泛、在某些方面更重
要的一系列运营职能，如财务报告、合规监控、合同管理和客户支持
等等。
建立进入市场的职能
挑战：自然增长有上限，大多数处于扩展阶段的创始人在不得不建立
真正的进入市场职能之前就达到了这个上限。
创意、最小可行产品和启动阶段的增长通常源于创始人主导的销售
，从适时发布到产品搜索文章到与早期客户的个人关系。不过，这
样的自然增长只在一定程度上有效，大多数初创公司在扩展阶段达
到这个极限。迹象包括用户曲线趋于平缓、客户获取成本上升以及
只有创始人亲自参与时销售管道才会移动。
扩展阶段的增长需要建立一个专门的增长引擎，以接触到您产品的新
的和更广泛的受众。然而，大多数初创公司创始人可能以前从未管理
过营销、销售和分析师关系项目等事务。一个合理的进入市场策略不
仅需要建立新的系统和流程，还需要为您想要如何谈论您的数据创建
品牌声音和故事。因为，在初创公司生命周期的这个阶段，您不仅需
要一个来接触单个新用户，还需要接触像投资者和企业买家这样的整
个目标受众。
幸运的是，进入市场的职能不一定规模大才有效，构建产品的同一人
工智能基础设施可以帮助将其推向市场。
Claude 如何帮助处于扩展阶段的创始人
早期创业阶段将Claude用作产品本身的基础架构：作为验证想法的研
究伙伴、设计和构建原型的工程团队，以及使单人创始人创业成为可
能的人工智能运营层。达到规模化阶段的原生人工智能创业公司创始
人
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.
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.
The fundamental challenge here is identifying the institutional knowledge that
lives only in the founder's head or 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.
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
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.
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.
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.
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.
How Claude can help Scale stage founders
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
27
same way they built.
28
现在可以使用Claude 、Claude Code 和Claude Cowork 来持续扩大
将日常任务交给Claude Cowork
以清醒的眼光开始规模化阶段，明确你现在最需要投入时间和精力的
地方，这对从未创办过企业的首次创业者来说可能是一项挑战。
Claude可以通过列出你在这个阶段只应该做的事情来提供帮助，这可
能包括产品叙事决策、董事会关系、企业交易以及创始人之间的对话
等。不在清单上的任何事情都是可以委托给他人或由Claude Cowork自
动化处理的候选事项。
• 练习：使用Claude生成你当前运营层的瓶颈图：当前通过你进行的
每个工作流程、决策和审批。现在，询问Claude当你一周无法工作
时每个流程会发生什么。停滞的工作流程就是那些你仍然亲自参与
过多以至于会阻碍进展的流程。
这些如何与你用Claude制定的创始人优先事项和责任清单相对应？
接下来，是时候对已经构建的系统进行压力测试，以确保它们实际上
能够随着业务增长而扩展。
• 练习：使用Claude绘制你当前的工作流程，然后询问当你一周无法
工作时每个流程会发生什么。停滞的工作流程就是那些交接标准、
升级路径或异常处理仍需加强的流程。Claude可以帮助分析故障点
并推荐适当的修复方法，以便你根据需要更新或替换Claude
Cowork自动化流程。
将技术运营扩展到企业级基础设施
随着业务扩展，买家需要确信你的产品和组织可以作为长期基础设施
被信任。代码库内部的技术工作一如既往地继续进行，但现在围绕代
码库也有技术工作需要处理。
第一步是将机构知识转化为可扩展的系统。使用Claude起草并维
护企业采购期望看到的书面基础设施，包括产品文档、支持手册
和服务水平协议。
与此同时，指导Claude Code根据企业合同要求的特定可靠性和安全标
准对代码库进行审计和强化，并构建基于Discord的社区支持从未需要
提供的技术支持基础设施：日志记录、监控、事件响应工具以及使服
务水平协议真正可执行的可观测性层。
然后Claude Cowork运行企业支持的运营层本身：工单路由、升级工作
流程、由产品更改触发的文档更新、续约跟踪以及企业客户成功所依
赖的报告节奏。这三者共同为一个小团队提供了一个规模大得多的组
织的支持态势，而这正是签署多年期企业合同时你需要展示的。
• 练习：挑选你最苛刻的三个潜在客户，或者确定你希望签约的产品
的三个理想客户。让Claude进行差距分析：这些客户的企业采购团队
在签署多年期合同之前期望看到哪些文档、服务水平协议和支持基
础设施，而你目前在哪些方面存在不足？利用输出结果来安排
Claude Code和Claude Cowork之间的技术和文档工作顺序。
建立一个真正的GTM功能
创始人的努力让你走到了这一步，但扩大你的初创企业需要创建并
实施一个实际的进入市场战略。人工智能可以帮助你构建并运行那
个完整的GTM引擎。
克劳德可以协助从头构建基础的进入市场（GTM）资源：市场细分
、信息架构、分析师关系策略、销售手册，以及当你与公开投资者
、企业买家和华尔街分析师交流时至关重要的面向投资者的指标叙
述。这些受众中的每一个都有自己的词汇表，并根据自己的
stage can now use Claude, Claude Code, and Claude Cowork to keep scaling the
same way they built.
Handing off day-to-day tasks to 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.
• 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.
How do these map to the inventory of founder priorities and responsibilities you
made with 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.
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.
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 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.
• 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.
Build a real GTM function
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.
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
28
29
标准来评估你；克劳德的工作是将你的产品价值主张转化为与每个
受众细分相关的产品营销方法。
现在，克劳德协作可以成为你的战术执行层：内容管道、外发序列
、分析师简报后勤、新闻编辑室和公关节奏、客户关系管理（CRM
）维护、管道报告，以及将GTM战略转化为实际商业行动的许多重
复周期。
在GTM行动需要产品营销基础设施的地方——交互式演示环境、集成
文档、沙盒租户、API参考、技术单页资料——克劳德代码可以为你构
建。买家期望从技术上评估你的产品，在规模化阶段，一个Loom视频
和一个销售演示文稿已经不够了。这也是让你的GTM行动异步运行的
基础设施：一个构建良好的演示环境可以在你参加董事会会议时促成
交易。
将领域专业知识和机构知识转化为人工智能上下文
许多超精简的初创公司创始人正在为他们在特定行业中亲身经历或
观察到的现实世界问题构建高度特定的应用程序或工具。智能代理
人工智能现在使那些从未编写过一行代码的创始人能够利用他们的
领域专业知识构建解决复杂问题的产品。克劳德、克劳德代码和克
劳德协作在将创始人知识转化为复合产品特异性方面都发挥着作用
。
使用克劳德来捕捉、组织和完善创始人知识，将领域专业知识置于产
品能够触及的地方。通过扩展对话、项目和记忆，创始人可以将他们
所知道的一切——行业术语、监管陷阱、边缘情况、挫折、这个问题
的明显答案不起作用的原因——分享到一个结构化、可搜索的上下文
中。然后，技能可以将重复的工作流程（例如，“我如何审核商业租赁
”，“我如何对患者 intake 表单进行分类”）编纂成克劳德每次都以相
同方式运行的可重复例程。几个月后，这将成为任何通用人工智能都
无法匹敌的专有知识基础。
用克劳德将你的领域知识外化对于将特定行业的边缘情况编码到
你的产品中变得非常宝贵：一个通用人工智能
例如，医疗计费工具在340B药品计划索赔上会出错，但你的工具对它
们有特定的逻辑。克劳德代码帮助你将你所在领域其他专业人员遇到
的常见挫折转化为验证逻辑、提示优化，或与你的竞争对手从未听说
过的利基行业系统进行MCP集成。结果，你的应用程序或工具的深度
和广度都以竞争对手根本无法复制的方式不断增加。
• 练习：找出一个通用竞争对手在你的垂直领域肯定会出错的边缘情
况。与克劳德代码合作，根据你实际看到的场景为其构建一个专用
测试用例（不是单元测试）。每次出现类似的边缘情况时，添加它
。你的测试套件将成为你的护城河地图。
将积累的用户数据转化为可防御的优势
当用户与你的产品交互时，他们会生成行为信号（即他们接受哪些输
出，拒绝哪些输出），这为产品路线图提供信息。随着时间的推移，
你将了解你特定用户群体的具体模式、偏好和边缘情况。这就是我们
所说的价值复合：每一次改进都会使产品更有用，这会推动更多的使
用，从而产生更多的反馈，进而推动更多的改进。
这些数据是时间锁定的、特定于上下文的，并且模仿者无法重新创
建：你根本无法购买数千名在你的产品中完善其工作流程的用户的
行为指纹。
克劳德可以帮助审核你收集的任何用户交互数据，识别其中最高信
号的行为模式，并设计将持续使用转化为系统模型改进的反馈循环
。
• 练习：向克劳德提供你的产品交互数据摘要：你一直在收集什么、
收集了多长时间，以及你对用户随着时间推移如何与你的产品互动
的了解。要求它识别该数据中三个最高信号的行为模式，并设计一
个反馈循环，将每个模式转化为系统模型改进。然后要求它帮助你
起草一份单页的护城河叙述，以告知产品营销：你的数据飞轮如何
工作、它已经旋转了多长时间，以及为什么一个资源充足的竞争对
手从今天开始在两年内无法复制它。
standards; Claude's job is to translate your product’s value props into a product
marketing approach that’s relevant for each audience segment.
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.
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 to evaluate your product technically and, 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.
Turning domain expertise and institutional knowledge into AI context
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.
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 (., "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.
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.
• 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.
Compound accumulated user data into a defensible advantage
As users interact with your product, they generate behavioral signals (., 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.
• 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.
29
30
创建工作流程锁定
复合数据网络效应使你的产品更难被复制，但用户工作流程锁定会使
你的产品更难被舍弃。用户在日常运营中使用你的产品的时间越长，
它就越深入地融入到他们的实际工作方式中。他们在其之上构建了自
动化流程，培训人员使用它，并将其连接到他们的数据源和其他工具
。他们开发的提示、完善的工作流程以及标准化的输出，都是围绕你
的产品功能及其实现方式形成的。此时，切换就从产品决策变成了全
面的运营项目。
创建工作流程锁定的第一步是让Claude按集成深度对你当前的客户群
进行映射。对于每个客户细分群体，确定他们在你的产品之上构建
了哪些工作流程以及他们依赖哪些集成。这显示了你的产品在哪些
方面扎根，以及在哪些方面需要进一步深入。
你提供的集成越多，客户构建依赖于你的产品的工作流程的空间就
越大。Claude Code可帮助你快速与目标用户依赖的数据管道、项目
管理工具和其他系统建立原生集成。Claude Code还可以构建API、网
络钩子和软件开发工具包，不仅让客户能够使用你的产品，还能在
其之上进行构建——这是最深度的锁定形式。
• 练习：让Claude帮助你为前十大客户构建工作流程集成审计。对于
每个客户，记录他们构建的自动化流程、依赖的集成、通过你的产
品运行的团队工作流程，以及你对他们的切换成本的估计。然后让
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.
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.
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
• 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.
30
Chapter 7
31
相同的工作，新的规则
Chapter 7
Same job, new rules
31
Chapter 7
32
相同的工作，新的规则
在人工智能领域，创始人的工作并没有改变：找到一个实际问题，构
建解决该问题的东西，并将其扩展成一个有影响力的公司。改变的是
实现这一目标的途径。在创意、最小可行产品、
