这份手册真正想说什么
这份文档表面上是在讲 Claude、Claude Code、Claude Cowork 如何帮助创业公司提速;更深一层,它其实在改写“创业公司如何从一个想法长成一个组织”的默认剧本。
旧剧本是:验证、融资、招聘、开发、再融资、增长、继续招聘。新剧本是:创始人先用 AI 把研究、验证、原型、工程、运营和知识管理组合成一个高杠杆系统,再在证据足够强的时候才扩大团队。公司不再天然等于人数增长,人数也不再天然代表进展。
核心判断
AI 没有让创业变得“更容易成功”,它让执行变得更容易,于是判断错误的代价来得更快。真正的瓶颈从“我能不能把东西做出来”变成“我有没有足够证据证明这件事值得做,以及我能不能让系统持续按正确方向运转”。
这份手册的四个转向
- 从技术能力转向问题洞察。 不会写代码的人也能做出产品,所以真正稀缺的是对真实问题的敏感度、行业经验和用户理解。
- 从“亲自执行”转向“编排系统”。 创始人越来越像 AI 智能体、工具链、少量团队成员和业务流程的总导演。
- 从“快点做”转向“证据先行”。 AI 让错误想法也能被迅速做成一个像样产品,所以每个阶段都必须有退出标准。
- 从招聘扩张转向系统扩张。 研究、代码、运营、合规、销售和客户成功可以先由 AI 系统承担一部分,团队扩张不再是唯一的增长方式。
最值得创始人警惕的地方
这份手册反复提醒一个危险:AI 会放大确认偏误。你让它证明一个想法很好,它能找到证据;你让它找出这个想法为什么会失败,它也能找到证据。因此 AI 原生创始人必须把“反方辩论”“预演失败”“寻找反证”制度化,而不是只把 AI 当成执行外包。
可以带走的一句话
AI 原生创业公司的优势,不在于创始人少招几个人,而在于创始人更早地把公司变成一个可学习、可验证、可自动化、可审计的系统。
创业生命周期,在 2026 年重启
AI 正在重塑创业公司的构建方式。今天,从未写过一行代码的创始人也能发布生产级应用;而“10 人独角兽”也已经从一个草根逆袭故事,变成了一套有意设计的行动方案。
在 2026 年,AI 可以编写生产代码、开展市场研究、综合竞争格局、起草投资人材料,并自动化运营工作流。过去,即便是经验丰富的技术创始人,也需要跨过很高的学习曲线,才能把想法落地所需的工具、平台和系统整合起来。AI 消除了其中相当一部分障碍,最重要的是,它让“谁可以创办公司、谁可以构建产品”这件事变得更加平等。
在 2026 年,一个好想法能把创始人带得比以往更远。智能体式编程把过去需要一支工程团队完成的事情,压缩成创始人自己就能交付的工作。
传统的创业增长曲线默认从想法到规模化的路径是:验证 → 融资 → 招人 → 构建 → 再融资 → 增长 → 继续招人 → 循环往复。现在,AI 已经抹掉了这样一种预期:创业生命周期的每个新阶段,都必须需要更大的团队、不同的技能组合和新一轮融资。
本手册会根据这些新现实,重新映射创业旅程的四个核心阶段:想法、MVP、发布和规模化。我们会考察:当 AI 成为技术发展和组织发展的核心时,每个阶段会是什么样子;每个阶段应该使用什么工具;以及使用这些工具的创始人如何压缩时间线。如果你已经准备好描绘从想法到退出的最短路径,请继续读下去。
创始人的含义正在改变
过去,人们常常用“一个人会做什么”来定义创始人:技术创始人写代码,非技术创始人负责商业运营和成交。但在 2026 年,创始人可用的模型、系统和 AI 智能体,已经消解了“能构建的人”和“有值得构建的想法的人”之间的墙。
AI 原生创业公司正在从根本上改变“成为创始人”这件事的含义。现在,一个没有工程背景的人,也可以构建能让想法落地的生产级软件;而一个技术能力很强、但商业知识有限的创始人,也可以轻松产出上市策略、财务模型和高度打磨过的融资路演材料。
历史上,创始人大部分时间都处在执行模式:写代码、管人、处理日常运营工作。在 AI 原生创业公司里,创始人的角色更少是个人贡献者,更像是智能体的编排者。这些专门化的 AI 助手可以读取文件、运行命令、执行代码,甚至浏览网页。创始人的注意力向上移动,转向更高阶的工作:产生想法,并指挥那些负责把想法实现出来的系统,包括 AI 智能体、工具以及任何已有的小团队。
然而,把 AI 作为核心基础设施最具革命性的结果,是释放那些拥有领域专业知识但不懂技术的创始人。当创始人池不再局限于工程背景的人,就会出现由完全不同生活经验的人创建的公司。它们会解决真实问题,而传统技术创始人路径过去可能从未优先考虑这些问题,甚至根本没有注意到这些问题。
适用于精益创业公司的 AI 工具能力
传统创业模型假定:你需要雇工程师来构建产品,雇销售来卖产品,雇运营人员来经营业务。员工人数被视为组织动能和产品成熟度的标志。
2026 年的早期创业公司截然不同。它们在设计上就极其精益,常常只有创始人本人,或者只有创始人加少数几个人。通过把技术发展和组织发展都建立在 AI 作为基础设施之上,它们可以在扩张团队之前,就达到产品验证、早期收入,甚至盈利。AI 尤其在三个方面帮助创业公司像更大的组织一样运转:研究、智能体式编程,以及关键业务运营工作流的自动化。
对话式智能与研究
可以理解为:每个领域都有一位随叫随到的专家
想想创始人在第一年需要知道的所有东西,而他们开始时几乎肯定不知道:我该如何设置薪资系统?我该如何规划产品开发冲刺?我该如何写一份紧凑的投资人备忘录?
过去,这类早期创业问题几乎都有同一个答案:找一个懂的人。对自力更生或种子轮前的创始人来说,这可能意味着把本该用于构建产品的时间花在搜集知识上,或者把早期资金中的一大块花在顾问身上。现在,他们拥有了一个横跨所有可想象领域的随叫随到专家。
- 深度研究:竞争分析、市场规模测算、财务建模。
- 文档起草:融资路演材料、案例研究、投资人备忘录、产品需求文档。
- 战略思考伙伴:反方分析、失败预演、情景规划、路线图优化。
智能体式编程
可以理解为:永远在线、永不被阻塞的工程师
过去,构建软件通常需要一个技术联合创始人、一个外包开发团队,或者足够长的资金跑道,让你在写出第一行生产代码之前就先雇到工程团队。
智能体式编程工具现在让每一个有志创始人都能用自然语言描述自己想构建的东西,并指挥 AI 生成、测试、调试和重构生产级代码库,其速度和规模接近一支完整工程团队。
从“我有一个想法”到“我有一个产品”的时间线已经被压缩。创始人的角色现在更集中在“构建什么”和“为什么构建”,而 AI 负责实际搭建可供真实用户使用的真实基础设施。
工作流自动化
可以理解为:按需出现的自动化运营团队
即使创始人能像顾问一样做研究、像工程团队一样构建产品,还有一大类既不属于战略规划也不属于产品开发的工作仍然必须完成。排期、更新 CRM、拉取周报、保持文档更新、发布内容、跟踪合规要求、管理公司所依赖的工具和系统之间的连接组织,这些都需要有人处理。在精益创业公司里,这些负担主要落在创始人身上,并且会大量消耗本应投入高阶决策的时间和注意力。
使用 AI 工具进行工作流自动化,可以卸下这种负担。重复性运营任务可以被配置为自动发生:交易状态变化时 CRM 自动更新,周报自动生成,产品变更时文档同步更新。关键在于,Claude Cowork 可以与创业公司运行所依赖的互联系统集成,包括项目管理工具、沟通栈和数据源,而不需要有人构建和维护这些集成。在 Day Zero 创业公司里,这个人几乎总是创始人。
时机与编排就是一切
能够有效利用 AI 的研究、自动化和智能体式编程能力的创始人,可以构建出一家运营杠杆远高于员工人数所暗示规模的创业公司。他们也能够把大部分时间和带宽投入真正重要的工作。
这些工作不会自动发生。编排这些 AI 工具的创始人必须知道如何应用它们,以及何时应用它们。本手册余下部分将探索创始人在 AI 原生创业路径中会遇到的目标和挑战,以及如何在旅程的每个阶段有效应用 AI 工具。
想法阶段
每个创业者都从同一个地方出发:一个他们无法停止思考的问题。这是想法与现实相遇的阶段。2026 年的创业成功要求一种纪律:在证据足以支持之前,不要开始构建。
这个阶段的工作包括研究、客户发现、竞争分析,以及诚实评估那些会推翻自己判断的证据。所有这些,都应该发生在你让 Claude Code 生成第一行生产代码之前。
想法阶段的目标
在想法阶段,创始人的主要目标是以研究为导向的验证:在投入资源开始构建之前,汇集坚实证据,证明一个真实问题确实存在,并且你提出的解决方案能够有效解决它。
实践上,想法阶段是一系列创始人大致需要按顺序回答的问题:
- 这个问题是否真实、具体,并且出现频率足以围绕它构建公司?
- 到底是谁有这个问题?这是否构成一个市场?
- 是否已经有人在解决它?如果有,他们如何解决,解决得怎么样?
- 一个真正解决这个问题的方案需要做什么?我的想法是否做到了?
这些问题的答案最终汇集成一个终极问题:这件事值得构建吗?
这意味着你要先具体,再行动。“人们在报销上遇到困难”只是一个观察。“中型市场公司的财务经理每周花四小时以上核对报销提交,因为他们现有工具无法与会计软件集成”才是一个可测试的假设。
想法阶段的退出标准
想法阶段的退出条件,是找到问题与解决方案的匹配。你已经通过真实的人类对话,建立了定性证据,证明在你开始构建解决方案之前,你正在为真实的人解决真实的问题。
当你能够对下面三个问题全部回答“是”时,就可以离开想法阶段:
- 问题是否真实且具体? 肯定回答意味着你能准确说出谁正在经历这个问题,他们多久遇到一次,它对他们造成多严重的影响,以及他们目前如何处理。
- 你的解决方案是否解决了真正的问题? 不是你最初假设的问题,而是验证过程揭示出来的问题。有时两者相同,但并不总是如此。
- 你是否有足够信号支持开始构建? 这个阶段你永远不会拥有确定性,等待确定性本身就是一种失败模式。但你需要足够的定性证据,使投入 MVP 成为一个经过推理的决定,而不是信仰之跃。
想法阶段的挑战
想法阶段是创业旅程中最重要的工作发生之处,因为最具后果性的错误也会在这里发生:现在搞错某件事,可能很快就会让刚起步的事业偏离轨道。不过,多数构思阶段的挑战都与“行动速度超过理解深度”有关。因此,慎重且有意识地推进的创始人会看到稳定进展。
把构建误认为验证
挑战:当技术障碍被移除,一个热情高涨的创始人可能会跳过创业旅程中最重要的工作:验证自己的想法是否确实是人们需要并会使用的解决方案。
即使在当前智能体式编程时代之前,也有 42% 的创业公司失败,是因为他们构建了没人想要的东西。现在,Claude Code 这样的智能体式编程方案大幅缩短了“我有一个想法”和“我有一个产品”之间的距离,这个失败率只会继续上升。
对拥有绝妙想法的创始人来说,现在确实是最好的时代。但反直觉的是,快速轻松地搭建出一个看起来像产品的原型,也会给 AI 原生创业公司带来真正危险的生存风险。
直到不久前,构建仍然需要真实的开发时间和预算,即便是基础原型通常也需要几个月才能做出来。现在,技术开发的门槛基本消失,AI 让创始人太容易跳过现实世界的效用验证,直接开始构建。
达到问题与解决方案匹配,必须先验证假设,再开始构建。但很多初次创业者,甚至有经验的创始人,会误以为 AI 可以绕过这个要求,把流程变成:有一个想法 → 立即构建原型 → 把原型存在本身当作验证。原型成了相信假设一开始就是对的理由,而不是测试假设是否真的成立的工具。
一个可运行的原型很容易被误认为是你正在解决真实问题的具体证据,但它不是。原型更像是你与潜在用户对话时用于压力测试的道具。真正的证据,是这些对话本身。
过早扩张
挑战:当构建变得轻松且即时,你可以把执行规模扩张到远远超过业务需求的位置。
过早扩张意味着,在你真正验证某条产品路径值得投入之前,就已经对它做了承诺。
这一直是创业杀手,但 AI 让创始人更容易在毫无察觉的情况下掉进过早扩张的陷阱。智能体式编程助手过于强大,导致在尚未验证问题与解决方案匹配前,执行就已经远远跑在前面,而创始人甚至没有意识到自己偏离了路线。
AI 会围绕一个根本有缺陷的前提生成、测试、调试和重构代码库,热情程度与它面对一个伟大想法时完全一样。系统中的智能是你的智能。这个阶段的首要原则,是让你的判断始终跑在构建前面,尤其是在构建如此迅速、感觉如此轻松的时候。
失去客观性
挑战:让 AI 工具寻找支持你既有信念的证据,它就会找到。确认偏误现在配上了一个研究引擎。
确认偏误一直是创业中的职业风险:创始人天生对自己的想法充满激情。现在,AI 工具大幅增强了确认偏误。让 AI 验证你的创业想法,它会找到支持证据;让它估算你的潜在市场规模,它会找到让总可触达市场看起来值得融资的数字。
AI 会遵循你的方向,这意味着一个不问尖锐问题的创始人,现在可以比以往更快地为一个糟糕想法构建出一套看起来研究充分的复杂论证,同时还确信自己确实完成了尽职调查。解药还是同一个工具,只是方向相反:AI 可以像验证一个想法那样彻底地压力测试一个想法。
当研究和结构化的对抗性思考呈现出证据,表明你的想法需要修正时,这就是转向的信号。
Claude 如何帮助想法阶段的创始人
推动一个 AI 原生创业概念穿过想法阶段,可能感觉像永远也结束不了。你是创始人,你只想开始构建。但这个至关重要的启动阶段,本质上是研究和验证练习,这意味着你需要使用那些能帮助你在全力写代码之前更严谨思考的工具。下面是如何在 Claude 的不同产品界面,包括 Chat、Claude Cowork 和 Claude Code 中,尽可能快速且尽责地推进想法阶段。
AI 让创业创始人更容易更快发布产品、自动化繁琐工作流并规模化运营,但你使用的界面很重要。下面是根据任务选择 Chat、Claude Cowork 或 Claude Code 的方式。
Chat 适合在你已经使用的应用中快速来回交流。用它处理经营公司时持续出现的小任务:从一份密集的投资人备忘录中提炼一句话结论,在董事会会议前检查一个说法是否站得住脚,或理解团队中一长串 Slack 讨论。
Claude Cowork 适合真正耗时的知识工作:从多个来源拉取信息、理解它,并产出一个完成品,比如文档、演示稿或表格。可以把一整个客户电话转录文件夹变成下一次产品评审使用的主题洞察文档,也可以在融资前从十几个供应商网站构建竞争格局,还可以设置一个每周一早上的固定任务,从你连接的工具中拉取指标,并把每周 KPI 简报放进共享文件夹。
Claude Code 是给团队工程师使用的智能体式编程环境:直接访问代码库、Plan Mode、Git 集成,以及本地、IDE 或沙盒云环境。精益团队在这里跨越不断增长的代码库发布功能、迁移 MVP 阶段遗留代码,并在不等待更多人手的情况下从原型走向生产。
| 如果任务是 | 使用 | 原因 |
|---|---|---|
| 一个问题、一次改写、一次快速头脑风暴 | Chat | 快速、对话式、无需设置 |
| 研究、分析,或基于文件和系统生成完成版文档 | Claude Cowork | 文件夹访问、连接器、技能、定时运行 |
| 编写、测试或发布软件 | Claude Code | 代码库访问、差异、Git、开发环境 |
三者底层使用的是同一个 Claude,变化的是它周围的工作空间。
定义并压力测试问题假设
你自己的领域专业知识和前期研究已经生成了一个假设。第一项工作,是把它打磨到真正可测试的程度。Claude 在这里特别有用,因为它会迫使你具体化:到底是谁有这个问题,多久发生一次,严重程度如何,他们现在如何处理?如果一个问题陈述不能精准回答这些问题,它还没有准备好被验证。
和 Claude 一起打磨你的问题陈述,直到它成为一个可测试假设。比如,“合同审查耗时太久”并不具备有效可测试性。但“中型市场公司的内部法务团队每个合同审查周期花费 3 天以上,因为红线修改分散在邮件线程中,而不是集中在一个有版本控制的文档里”,就是一个非常可测试的假设。
下一步,是让 Claude 反驳你的想法,并寻找推翻你假设的反证。这可以暴露负面市场信号、失败的竞争者、客户行为模式,以及支持性总结可能悄悄降低优先级的结构性障碍。
目标是在进入客户发现之前,就已经用最强的可用反方论点压力测试过你的假设。这样,信息性用户访谈才是真正开放的,而不是在寻找确认。
市场研究与竞争格局映射
评估竞争对手
创业公司中有一种特定现象叫“竞争者忽视”:过于专注于自己的愿景和执行,以至于系统性低估同一领域其他人在做什么。幸运的是,AI 提供了解药:让 Claude 构建最有说服力的论点,说明为什么这个解决方案空间中的某个竞争对手会成功,而你不会。
Claude 可以分析为什么他们的方法实际上更好,为什么客户会选择他们,为什么你以为的潜在差异化并没有那么可防御。
让 Claude 按层级映射你的竞争格局:直接竞争对手、间接竞争对手、潜在收购方,以及可能进入你所在领域的相邻玩家。然后让它论证每一层为什么会对你的成功构成真正威胁,而不只是描述那些最容易被你否定的威胁版本。
市场研究
Claude Code 可以综合公开可得的客户反馈,挖掘反复出现的抱怨和未满足需求。额外好处是,这基本等于对竞争对手客户进行免费定性研究。
指挥 Claude Cowork 综合关键来源中的竞争对手评论,并识别现有解决方案尚未解决的主要抱怨。如果你的假设解决了其中一个或多个抱怨,那就是问题与解决方案匹配的强证据。如果没有,知道这一点同样有价值。
Claude Cowork 还可以从密集的行业报告、分析师文件和市场研究文档中提取相关信息和数字。接着,这些整理干净的输入会成为 Claude 分析工作的理想上下文。
基于公开数据构建 TAM、SAM、SOM 模型,并压力测试模型背后的假设。识别市场是在扩张、整合还是成熟;这个背景会影响你如何思考时机和差异化。绘制买方格局:谁掌握预算,谁影响决策,他们是否是同一个人。
趋势分析
最后,用 Claude 监听早期指标,判断你是否在正确时间进入市场。跟踪那些已经有人讨论你所关注问题的 subreddit 和 LinkedIn 群组,以及用户在描述问题时使用的确切语言。让 Claude 识别曾经解决类似问题的相邻市场,并提取其中有效和无效的做法。暴露可能加速或威胁机会的监管、技术或人口趋势。
让 Claude 识别三个外部趋势,包括监管、技术或人口趋势,它们可能在未来两年显著影响你的市场,并评估每个趋势对你的具体假设来说是顺风还是逆风。
规划并设计客户发现
你通过和潜在用户交谈学到的东西,取决于两件事:你问的问题质量,以及你是否把这些问题问给了正确的人。Claude 在客户发现方面特别有帮助,包括该找谁聊、该问什么,以及如何理解听到的内容。
该和谁聊
一个精准的目标画像,比一长串联系人名单有价值得多。这个画像应该包括最可能强烈感受到该问题的具体职位、公司类型、团队结构和资历层级。然后,识别这些人实际可触达的地方,比如社区、活动、LinkedIn 群组和 Slack 工作区,并基于他们与问题的接近程度建立优先级框架,决定先联系谁。
该问什么
目标明确后,用 Claude 构建访谈框架本身:正确的问题、正确的顺序,并且结构上要能暴露人们实际做什么,而不是他们以为自己将来会做什么。新手创始人常犯的错误,是提出关于未来的泛泛开放问题,比如“你会用这样的东西吗?”,而不是具体询问相关过去,比如“告诉我你上一次处理这个问题的经历”。
Claude 也可以指出你草拟的问题哪里在引导受访者、哪里太宽泛,或哪里可能产生噪音而不是信号。Claude 还可以帮助你设计追问,用来探查回避回答,或深入挖掘重要问题上的模糊回答。
如果你的假设涉及多个角色,Claude 还可以为每个角色设计不同问题集。财务经理和 CFO 与同一个问题的关系不同,单一访谈框架会抹平这种差异。
先手写访谈问题,再让 Claude 审核。明确要求它标出任何具有引导性、面向未来、过于宽泛,或容易产生社会期许式回答而非诚实回答的问题。然后让它为访谈中最可能出现回避的两三个时刻设计追问。
访谈后分析
每次谈话后,用 Claude 复盘:输入你的笔记,让它识别哪些内容确认了你的假设,哪些内容挑战了你的假设,哪些内容是真正令人意外的。收集一批访谈后,把完整访谈笔记交给 Claude Cowork,提炼反复出现的主题、矛盾,以及正反两个方向上最强的信号。然后把综合输出带回 Claude,让它标记你自己对数据的解读是否在套用你想听到的模式,而不是忠实反映数据本身。
每完成五次访谈,就指挥 Claude Cowork 综合你的笔记,并产出两份清单:支持你假设的证据,以及挑战你假设的证据。如果第一份清单显著长于第二份,就问 Claude 这种不对称反映的是数据本身,还是你希望找到的东西。
客户外联与排期
使用 Claude Cowork 自动化围绕联系人名单建设、外联和用户访谈排期的运营负担。
Claude Cowork 可以使用你通过 Claude 定义的目标画像,包括职位、公司类型和资历层级,研究并汇编结构化潜在客户名单和已验证联系方式。随后,它可以批量起草个性化外联邮件,根据每个人的角色和背景进行定制。
当回复进来时,它可以通过 MCP 连接 Gmail 和 Google Calendar 来管理邮件线程、处理排期请求,并把访谈放进日历。工作流还会继续:Claude Cowork 可以按照定义的节奏生成跟进草稿,比如给未回复联系人的第七天跟进,并在每一步完成时更新你的跟踪表,让你始终知道每个潜在受访者处在管道中的什么位置。
把你已验证的访谈目标画像交给 Claude Cowork,让它构建潜在客户名单、起草个性化外联序列,并设置一个跟踪表,包含外联状态、跟进节奏和访谈完成情况等列。然后让它处理协调工作,而你专注准备对话本身。
设计最终解决方案概念
你已经完成验证工作:问题真实存在,你知道谁有这个问题,并且有一个由证据支持的解决方案概念。用 Claude 从各个角度发展并挑战你的解决方案概念:有哪些空白?有哪些替代方案?要让这个解决方案规模化成功,什么条件必须成立?这是一个重要的现实检查:这个设计是否真正解决了验证过程揭示的问题,而不是你一开始假设的问题?
把你的解决方案概念提交给 Claude,让它识别你的设计最依赖的三个假设。然后问它:每个假设要成立,必须有哪些事实为真?如果其中任何一个不成立,后果是什么?
用 Claude Code 构建轻量原型
现在到了有趣的部分:有了已验证的假设和经过压力测试的解决方案概念,你终于准备好构建一些东西了。
这是 Claude Code 在想法阶段正式登场的时刻。即使你之前一直在尝试,现在才是生成官方轻量原型的节点:只构建把你的想法放到真人面前并获得真实反应所需的最小表面积。
你还不是在构建真实世界产品,而是在构建一个功能性样本,用于客户和投资人对话。真实用户对他们可以实际触摸的东西做出反应,会告诉你十几次问题与解决方案发现访谈无法告诉你的事情。之前,你是在证明你要解决的问题真实存在;现在,你是在要求潜在用户与拟议解决方案发生互动。
定义你的解决方案最依赖的单一核心互动。指挥 Claude Code 只构建这一件事。完成后,把它放到五位来自已验证目标画像的人面前,让他们试用。你从这五次对话中学到的东西,将决定你是继续构建,还是回到画板前重新设计。
到达想法阶段的终点,是 AI 创业赛道上的巨大跃迁,因为此时你不再是在押注直觉,而是在根据证据执行。接下来是 MVP 阶段,创始人的指导问题会从“这是否值得构建?”变成“我们首先到底应该构建什么?”,而 AI 的主要角色也从研究伙伴转向施工队。
MVP 阶段
很多创始人把 MVP 阶段看作施工阶段,但 MVP 阶段本质上仍然是收集证据的练习。不同之处在于,现在你收集的是关于解决方案的证据,而不是关于问题空间的证据。具体来说,是一个真实且可识别的人群是否认为它有足够价值,愿意使用它、再次使用它、为它付费,或者把它告诉别人。
MVP 阶段的目标
作为 AI 原生创业公司的创始人,你的目标是把一个经过验证的问题,转化为真实用户真正会使用的工作产品。这不是包含路线图上所有功能的完整版,而是你的想法中最小、最聚焦的迭代:把真实解决方案放到真实用户面前,并生成关于产品与市场匹配的真实证据。
与此同时,你现在如何构建,会决定之后什么事情成为可能。这意味着 MVP 阶段还有第二个同样重要的目标:快速推进,同时不要积累那种会复利增长、并在真实用户大规模到来时困扰你的技术债。
最后,从第一天起投资于持久上下文,是让 AI 成为倍增器而不是熵源的关键。在 AI 原生创业公司中,你会在一个又一个会话中与 AI 协作维护代码库,因此可读性是基础。跳过规格说明、架构决策和上下文文件,比如 CLAUDE.md 的创始人,会撞上一堵可预测的墙:每个新会话都需要重新解释代码库,AI 生成的变更也会逐渐偏离最初愿景。
MVP 阶段的退出标准
MVP 阶段的退出条件是真正的产品与市场匹配证据:证明一个具体、可识别的用户群体已经发现产品有足够价值,愿意回来使用它、为它付费,或把它推荐给别人。
MVP 阶段的挑战
在 MVP 阶段,创始人的首要原则是速度和判断。这里的挑战集中在:你能否以足够快、足以产生影响的速度,构建正确的东西,并以正确方式构建,同时不走那些日后会付出代价的捷径。
智能体式技术债
挑战:AI 基本移除了过去控制什么能进入生产环境的所有自然瓶颈,因此速度已经被保证。但如果速度是创始人在 MVP 构建中唯一考虑的变量,他们就可能积累将来难以偿还的技术债。
在 MVP 阶段,一些技术债是合适的,前提是理解这些债务必须在规模化之前被管理。传统技术债会逐渐累积,也可以在一段时间内或专门冲刺中清理。但 AI 技术债会复利增长。
如果没有规格说明和架构约束写在 AI 可以读取的地方,每个会话都会从头推导基础决策,而这些决策会漂移。你最终得到的是一个背后没有一致心智模型的代码库。不是因为任何单个部分都糟糕,而是因为这些部分从未被设计为相互配合。这是一个真正的问题,并且往往会在很晚的时候暴露。
误把假性产品与市场匹配当真
挑战:AI 工具可以生成令人印象深刻的早期数字,但这些数字并不能保证市场需要你的产品。
早期动能是创始人能体验到的最具心理力量的经历之一。经过几周或几个月的验证工作和谨慎纪律性的构建后,发布产品感觉像是证明你从一开始就是对的。
智能体式编程工具可以帮助你比以往更快到达这一刻,但早期牵引力不等于产品与市场匹配。发布能量常常来自短暂因素,比如创始人的朋友、投资人其他被投公司里的潜在买家,或者 Hacker News 头条带来的流量峰值。不幸的是,这些都无法可靠预测第六周或第十二周,当最初推动力消退后会发生什么。
零摩擦范围蔓延
挑战:当构建感觉毫不费力且几乎免费时,总会有另一个很酷的功能可以加,或者另一个边缘情况可以处理。这种范围蔓延可能弊大于利。
范围蔓延一直是创业风险。现在的区别是,过去抵抗它的传统约束,也就是真实工程时间成本,在“加一个功能只要一个下午而不是一个冲刺”的情况下不再以同样方式存在。
挑战在于,每一个单独新增都似乎合理。产品当然应该处理那个边缘情况,用户当然会想要那个工作流。在当下,它们并不像范围蔓延,因为借助智能体式编程,每一项都几乎不费力。但当产品蔓延到超出原始边界时,你会面临失去方向和动能的风险。
解药是在构建开始前创建书面范围定义,描述产品做什么、刻意不做什么,以及什么来自真实用户的具体证据足以支持新增某件事。这样,决策点就从“我们要不要构建这个?”转变为“一批关键用户是否告诉我们,没有这个就无法从产品获得价值?”
因经验不足而不安全
挑战:创始人使用 AI 工具匆忙把应用推向市场,却没有先理解基本安全原则,最终会让用户暴露在本可避免的风险中。
严酷事实是,智能体式编程工具会生成能工作的代码,而不是天然安全的代码。功能性代码很容易判断,因为功能要么有效,要么无效。安全漏洞在被利用之前是不可见的,这意味着没有自然反馈回路提醒首次创业者哪里出了问题。然而,把一个在线 MVP 发布给真实用户,意味着真实数据、真实暴露面和真实后果。
忽视安全并不是 AI 原生项目的新问题。每个时代的自力更生创业公司都常常把安全考虑推迟到构建后期,有时甚至等到生产发布前夕。任何用户接触你的应用或解决方案之前进行安全审查,是把最小可行产品负责任地释放到世界上的最低门槛。
Claude 如何帮助 MVP 阶段的创始人
在构建前定义架构
在 Claude Code 写下第一行生产代码之前,用 Claude 定义并记录将支配本阶段全部构建工作的架构决策:应该遵循的模式、应避免的依赖、正在做出的权衡及其原因。这个输出将成为一份聚焦的架构上下文文档,并建立 Claude Code 运行时的护栏。
没有这个上下文,每个会话都会从零开始,Claude Code 被迫推断自己的结构性假设。让 Claude Code 在没有护栏的情况下构建,会产出功能上可用但结构上不连贯的代码库。而在不连贯的代码库上迭代和规模化,最终会浪费时间和 token。迟早会到达一个代码不可避免崩塌的点,迫使你从头重建。
在打开 Claude Code 之前,先打开 Claude 并描述你正在构建的东西:它解决的核心问题、服务的用户,以及你对未来六个月规模的现实预期。让它帮你定义支配 MVP 构建的架构原则、在约束下应避免的依赖,以及你在这个阶段有意识接受的权衡。
接着,把这个输出保存为 CLAUDE.md Markdown 文件。这是你的架构上下文文档:构建工作的第一件产物,也是之后每个会话都依赖的产物。CLAUDE.md 文件是 Claude Code 的项目级指令,提供项目特定上下文和说明。当 Agent SDK 在某个目录中运行时,会自动读取这些文件。功能上,它们是项目的持久“记忆”。
定义并强制执行 MVP 范围
无摩擦范围蔓延,是 AI 时代 MVP 的典型失败模式之一。就像你定义并记录产品应用架构一样,在构建任何功能之前,你也需要定义 MVP 范围。
Claude 可以帮助你创建范围文档,描述 MVP 产品做什么、刻意不做什么,以及功能修订标准:在这个阶段,来自真实用户的什么具体证据足以支持新增某件事。
当新的功能想法出现时,它们一定会出现,你可以用 Claude 压力测试这是真正来自用户的信号,还是披着产品思考外衣的创始人热情。
用 Claude Code 构建 MVP
架构和范围定义完成后,Claude Code 就成为主要的 MVP 构建工具。用它生成、测试、调试和迭代代码库,但要把每个会话视为执行你已经做出的产品决策,而不是把它当成随手塞进新想法的机会。
每次 Claude Code 会话开始时,先重新查看范围文档,并向模型提供 CLAUDE.md 架构上下文文档。每次会话结束时,用会话中浮现的任何决策更新它。目标是一个你能解释其结构的代码库,而不仅仅是一个能运行的代码库。
为你的 Claude Code 工作创建一个简单的会话模板,其中包含架构上下文文档、本次会话的具体任务,以及需要遵守的约束或模式。每次会话结束时,在上下文文档中增加一条简短日志,说明构建了什么、做出了什么决策、引入了什么假设。每次会话花五分钟写文档,是防止架构漂移复利增长成不可管理代码库的廉价保险。
任何用户接触前的安全审查
作为 AI 原生创业公司创始人,你有责任知道代码库里有什么,理解任何潜在暴露路径,并且不把明显漏洞发布给信任你处理其数据的真实用户。
Claude 可以对 AI 生成代码做有用的一轮安全初审,并帮助识别常见漏洞。这是发布前值得纳入循环的好习惯。不过,它不能替代安全工具,也不能在更高风险场景中替代人类审查者。把它当成替代品的创始人,最终更容易出现在安全事故故事里。
Claude Code Security 走得更远:它会扫描代码库中的安全漏洞,并提出供人类审阅的定向补丁,暴露传统方法可能漏掉的问题。
在部署给任何真实用户之前,用一个具体 brief 让 Claude 审查核心应用代码:审查认证和会话处理、API 响应中的数据暴露、输入验证和注入风险,以及存在已知漏洞的依赖。认真对待每个发现,并评估是否需要修复。任何涉及认证、密钥或数据处理的内容,都需要人类审查。
发布前构建度量框架
那些把早期牵引力误认为产品与市场匹配的创始人,通常也是发布后才开始追踪数据的人,并且用来评估哪些事情有效的指标,往往无法暴露哪些事情无效。解药是在第一个用户出现之前就建立度量框架。
用 Claude 为你的具体产品定义哪些指标重要、基准是什么,以及哪些数据模式是真正的产品与市场匹配,哪些只是令人愉悦的噪音。具体来说,在发布 MVP 之前,先设定留存基准、激活标准,以及第 7 天和第 30 天目标。
接着,定义你的具体产品中“假阳性”长什么样:比如有注册但无激活、有收入但无留存,或初始热情之后没有重复使用。当数据到来时,让 Claude 构建反方论证:一个怀疑者会如何看待这些数字?
管理发现和用户反馈的运营工作
一旦真实用户进入产品,运营层会迅速扩张。Claude Cowork 可以处理重要但繁琐的工作,比如建立并维护用户联系人名单、运行外联序列、安排反馈会议、分流 bug 报告,以及跟踪迭代周期。在想法阶段用于管理发现工作的 MCP 集成,在这里同样适用。
对于用户反馈中的微妙探索,需要让人类留在收集循环中。例如用户说“这个很好,但我希望它也能……”,这需要解释:这是核心需求还是锦上添花?它只适用于这个客户,还是代表某个细分群体?缺少的功能是真正问题,还是入门流程上游出了问题?没有工具能替你回答这些问题。
配置 Claude Cowork 运行你的 MVP 阶段反馈循环:为早期用户名单起草外联邮件、安排反馈会议、设计 bug 报告和功能请求的结构化收集流程,并每周写出收到内容的综合分析。先由你自己审阅综合内容;之后,你可以让 Claude 分析这些信息,捕捉你可能忽略的重要点。
朝证据迭代,而不是朝完整性迭代
MVP 阶段结束的条件,是你拥有真正的产品与市场匹配证据,而不管产品感觉有多“完整”。宣布你已经实现产品与市场匹配,并准备从 MVP 阶段进入发布阶段,最终是一项结合创始人直觉和已收集证据的判断练习。不过,下面有一些有用的试金石:
- Sean Ellis 测试:询问活跃用户:“如果你不能再使用这个产品,你会有什么感受?”如果超过 40% 的用户回答“非常失望”,这是一个有意义的 PMF 指标。
- 努力程度测试:在产品与市场匹配之前,留存需要持续干预,包括频繁外联、激励、个人跟进,以及创始人投入英雄式精力来维持用户参与。产品与市场匹配之后,产品开始自己做这件事。当事情开始从“推”变成“拉”时,这种努力变化就是某件真实之物已经出现的最清晰信号之一。
最终,没有单一数据点可以确认产品与市场匹配,因为它是一种必须跨多个迭代周期持续成立的模式,然后你才能明确说它成立。
当证据要求时就转向
如果即使投入了所有这些工作,你似乎仍然无法达到产品与市场匹配,该怎么办?结果没有确认你一开始选择的方向,并不是失败,而是系统正在发挥作用:MVP 阶段的设计目的,就是在你对错误答案过度投入之前暴露这些信息。
当数据不支持当前产品时,用 Claude 研究这些数据到底在告诉你什么。
- 探索替代客户细分。 也许没有转化的用户从一开始就不是正确目标。正确受众常常已经在你的数据里,只是权重被低估了。
- 调整产品价值主张。 也许你有正确受众,但 MVP 并没有引起用户共鸣。调整入门流程、信息表达或核心功能重点,可能在不改变已构建内容的情况下解决问题。
也要保持开放:这种断裂可能深到需要更根本的改变。
如果你已经完成三轮或更多迭代,却没有朝产品与市场匹配基准产生有意义进展,在决定下一步之前,用 Claude 做一次诊断。把留存数据、用户反馈和原始问题假设交给它,并问三个问题:
- 这些数据中是否有某个细分群体的反应明显不同?
- 设计价值与体验价值之间的差距,是定位问题还是产品问题?
- 要让当前产品找到真正的 PMF,哪些条件必须成立?根据你看到的情况,这种场景现实吗?
让答案决定你是调整、转向,还是回到想法阶段。
发布阶段
如果 MVP 阶段是在证明你的产品值得存在,那么发布阶段就是证明你的业务值得增长。
发布阶段的目标
在发布阶段,创业创始人必须把早期牵引力转化为一个可重复、可持续的增长引擎。除了让产品生产就绪之外,你还必须加固其底层基础设施,同时围绕产品构建一家真正的公司。
创业公司在想法和 MVP 阶段天然以创始人为中心,因为你需要完整态势感知和紧密反馈循环。但现在,仍然试图亲自抓住每一条线索的创始人,会成为发布阶段的瓶颈。目标不是把你从公司中移除,而是构建运营系统,把你的注意力释放出来,投入只有创始人能做的决策。
发布阶段的退出标准
发布阶段的退出条件包含三个要素:
- 增长是可重复且由渠道驱动的。 你不仅在留住用户,也能通过特定渠道可预测地获取用户,并理解单位经济学:获客成本、客户生命周期价值和回本周期,都是你知道并能捍卫的数字。
- 产品可以处理生产工作负载。 基础设施已经加固,安全和合规已就位,可靠性能够在真实生产条件下保持,而不仅是在你测试过的条件下保持。
- 运营不再因创始人而阻塞。 流程已经存在,自动化已经到位。你不再是亲自处理支持、分流、冲刺规划或报告的人。
发布阶段的挑战
找到产品与市场匹配,是早期创业生命周期中最难的问题。现在,创始人的挑战变成保住它。发布阶段中,那些已经找到真实产品牵引力的公司,如果包围并支持产品的组织跟不上,仍然可能崩塌。下面是需要警惕的失败模式。
技术债到期
挑战:为速度和验证而构建的 MVP 代码库运行得足够好,足以证明产品有效。但生产流量、新功能和增长中的复杂度,正在暴露那些捷径。
在 MVP 阶段,积累一些技术债是为了速度而做出的合理权衡。在发布阶段,这些债开始计息,并且拖得越久,修复成本越高。
解决方案包括:进行系统性架构审计,识别结构性弱点;有针对性地重构,解决其中最严重的问题;显著扩展测试覆盖,以确保下一轮功能开发不会重新引入同样问题。
创始人成为瓶颈
挑战:在 MVP 阶段,创始人身处每个循环是一种资产。到了发布阶段,随着支持量增长、产品决策堆积、运营复杂度倍增,同样的本能会变成约束。
从亲自做事,转向设计“做事的系统”,是创业生命周期中最困难的转变之一。因为很少有一个清晰时刻宣布它已经发生,风险在于你完全错过它,并停留在构建者模式,而组织在你周围停滞。典型迹象包括:本该一小时内完成的决策现在需要一周才能排到你;支持请求堆积,因为只有你知道答案;运营任务只有在你亲自记得时才会发生。
补救办法是对你亲自处理的所有事情进行全面审计,从最小任务到最高风险决策,以识别哪些可以系统化,哪些可以委派,哪些确实仍然值得创始人投入时间和注意力。
安全与合规不再能推迟
挑战:对 MVP 来说,保持安全和合规措施简单也许可以接受。但现在,有真实用户、真实数据,甚至潜在企业合同摆在面前,它会成为一种责任风险。
在 MVP 阶段,只有少量 beta 用户且生产中没有敏感数据时,安全漏洞是理论风险。然而,一旦产品进入生产环境,并有真实用户依赖它,假设风险就会变成非常真实的暴露风险。此外,当你处理客户数据、处理付款或向受监管行业销售时,那些不适用于原型的合规要求肯定会适用。
补救办法是在生产规模到来之前,而不是之后,进行系统性安全和合规审查,并把浮现出来的每一项都视为下一波用户到来前必须完成的修复,而不是建议。
在准备好之前扩张
挑战:新市场和融资机会看起来像增长机会。它们也可能是产品与市场匹配死去的地方。
你已经建立的初始牵引力是真实的,但它也是针对早期受众的特定牵引力。过早进入一个与你原始市场显著不同的市场,会引入新的用户行为、合规要求、支付基础设施和基线期待,而你的产品并不是围绕这些设计的。突然之间,变量太多,你失去了清晰解释自己数据的能力。你还可能为了追逐一个新的、未经验证的受众,而忽视原有用户群。
Claude 如何帮助发布阶段的创始人
在发布阶段,Claude 的三种形态都会被充分使用,并且彼此支持:每个工具产出的输出都会成为另外两个工具的输入。结果会自然复利。把三者一起使用的创始人,得到的不只是各部分之和。
这就是超精益创业模型在结构上成为可能的原因。当 Claude Code 构建产品,Claude Cowork 构建围绕产品的公司,Claude 帮助把产品和组织知识运营化时,一个小团队可以像数倍于自身规模的公司一样运转。
在技术债复利前修复它
你的 MVP 代码库可以工作,但它也需要一次系统性修复检查,寻找任何可能成为结构性负担的技术债。
首先,用 Claude Code 进行完整架构审计:识别代码库脆弱的地方、哪些捷径会变得昂贵,以及测试覆盖薄弱到下一轮功能工作可能重新引入同样问题的位置。
把 Claude Code 的审计发现反馈给 Claude,让它为修复工作排序:哪些必须在下一次发布前修复,哪些可以等一个冲刺,哪些在当前阶段属于可接受的持续债务。这也是记录你在 MVP 阶段做出的架构决策的时刻,也就是那些因为当时没时间写下来而一直只存在于你脑中的决策。现在把它们写进 CLAUDE.md,可以确保未来每个 Claude Code 会话都从对系统如何设计及为什么这么设计的共同理解开始。
指挥 Claude Code 审计你的 MVP 代码库,并产出结构性弱点、测试覆盖缺口和重构候选项的优先级清单。然后把清单交给 Claude,让它把修复工作排进未来几个冲刺:需要首先处理的重大问题、可以与功能开发并行处理的问题,以及可以等待的问题。
构建替代创始人注意力的系统
构建运营系统,让你的注意力从日常事务中释放出来,投入只有创始人能承担的责任,前提是你清楚知道自己的注意力到底去了哪里。用 Claude Cowork 对当前运营负荷进行结构化审计,记录每一个重复任务、每一个落到你桌上的决策,以及每一个只有因为你亲自记得才会发生的工作流。然后让 Claude Cowork 把这些清单分类:哪些可以完全自动化,哪些需要人但不一定需要你,哪些真正需要创始人判断。
审计完成后,用 Claude Cowork 为自动化候选项设计工作流逻辑:每个工作流由什么触发、决策规则是什么、输出长什么样,以及完成后送到哪里。
把安全与合规变成产品工作流
用 Claude Code 暴露经常出现在 SOC 2、GDPR 或 HIPAA 审计中的代码级问题,以及目标市场要求的标准。这会同时暴露漏洞和合规缺口。把这些发现交给 Claude,让它帮助你排序修复工作,并设计企业买家在签约前会询问的控制措施、审计日志和访问管理。注意:AI 扫描是辅助工具,不能替代合格的合规审查。
接下来,把合规工作流纳入开发周期,而不是把它当作一次性项目。合规文档需要持续维护和更新。对于正在接近企业合同或国际市场的创始人来说,这也是 Claude Code 安全扫描可以帮助你准备独立安全评估的时刻。
用 Claude Code 进行代码级安全审查,方向对齐目标市场要求的框架。把输出交给 Claude,让它产出两件事:优先级排序后的安全修复序列,以及为了通过潜在企业买家的合规审查,你需要产出的文档和控制清单。
建立你一直跳过的产品管理流程
发布阶段需要一组轻量、可重复的流程,这些流程可以在不需要创始人干预触发或运转的情况下运行。用 Claude 设计产品时间线和工作周期如何组织,一个功能在 Claude Code 触碰之前规格说明需要包含什么,bug 报告如何分流和路由,每周指标报告覆盖什么以及如何分发。
流程设计完成后,用 Claude Cowork 构建并运行运营层:安排冲刺仪式,把收到的 bug 报告路由到正确位置,从已连接的数据源汇总每周指标,并维持让用户信号持续流入产品决策的反馈循环。
让 Claude 设计一个轻量产品管理操作系统:明确的冲刺节奏、最低规格说明模板、bug 分流决策树,以及从真实数据源拉取内容的每周指标简报。然后设置 Claude Cowork 实施并运行系统中重复出现的运营元素,比如排期、路由和报告汇编,让它们按时发生且无需你介入。
规模化阶段
在规模化阶段,创始人的角色重新集中到从构建者转变为面向公众的高管。产品仍然是核心,但你的日常工作越来越围绕公司本身展开。你的注意力必须扩展到规模化阶段的新活动,比如分析师简报和 IPO 路演,同时仍然努力维持精益且以 AI 为中心的结构性优势。
规模化阶段的目标
扩展技术基础设施的工作会继续进行,而且现在还加入了扩展组织本身、让它成熟为一家企业的工作。
在规模化阶段,你正在从数千用户走向数百万用户,从一个市场走向多个市场。在之前每个阶段,增长仍然可以通过贴近用户、基于紧密反馈循环中的数据调整方向,再加上健康的创始人直觉来摸索。现在,目标是构建由成熟组织运营支撑的系统性增长。
对 AI 原生创业公司来说,你的目标应该是通过累积深度建立可防御护城河。这种深度来自你嵌入产品中的专业知识、产品与用户依赖的其他工具和平台的集成深度,以及专有系统数据和工作流。那些一直在同一方向、同一基础设施上持续构建的创始人,现在拥有了真正难以复制的东西。
在这个阶段,公开市场投资者、分析师、监管者、企业采购团队和收购方会施加更大压力,也会带来更高怀疑,因为此时风险更高。你的产品和组织必须经得起外部审视:不仅是你所构建东西的能力,还包括围绕它的治理、合规姿态、财务控制和战略叙事。
规模化阶段的退出标准
规模化阶段的退出条件不再是单个里程碑,而是一个阈值事件:即使创始人越来越不直接管理日常运营,公司仍然可持续。你已经证明系统性增长,构建了能满足最苛刻外部审查者的组织治理和合规基础设施,并且能够扎实回答这个问题:“如果一家资金充足的现有巨头今天复制你的产品,你的用户还会留下吗?”
实践上,这个阈值通常会采取三种形式之一:在不再需要外部资本的规模上实现可持续盈利,准备好 IPO,或被收购。三者都要求你的增长是系统性的、可审计的;你的产品护城河经得起审视;你的组织已经运营成熟且可持续。
当这些为真时,值得恭喜:你的创业公司已经从一次押注变成了一门生意。
规模化阶段的挑战
委派运营层
挑战:规模化阶段的运营系统必须可靠、可持续地运行,而不需要被盯着。对一个从第一天就亲力亲为的创始人来说,这种转变既是结构挑战,也是心理挑战。
发布阶段的工作是创建系统;到了规模化阶段,工作变成两件事:让这些系统成熟到完全值得信任,然后真正信任它们。
这比听起来更难。即使你是一个很会委派的创始人,也并不总是清楚什么该交出去,什么该留在自己手里。交得太多、太快,尤其是交给 AI 自动化系统,关键决策可能会在缺少只有创始人才有的关键上下文下被做出。抓得太久,又会让你成为瓶颈。
这里的根本挑战,是识别那些只存在于创始人脑中或未记录工作流中的组织知识,并把它们编码进有文档、可审计、可转移的系统。
扩展技术运营
挑战:客户不再只评估你的产品,他们还想知道你的组织是否能成为可靠的基础设施伙伴。
前面三个创业阶段的技术挑战集中在代码库:构建正确解决方案、避免技术债,然后为真实用户加固安全和合规。进入规模化阶段后,挑战变成围绕代码库构建的一切:创建支持基础设施、文档和可靠性保证,以传达成熟度。
签多年合同的大型客户和机构买家,在签约前希望看到这些东西,签约后也会按这些要求约束你。好消息是,把你带到这里的同一套 AI 基础设施,也能帮助你构建具有明确响应时间和文档的专门支持功能,让新客户的工程团队能够真正使用。
扩展组织职能
挑战:规模化阶段的公司通常需要招聘、薪资、会计和法务运营等组织基础设施,不论实际有多少人在运行这些职能。
在发布阶段,系统化运营意味着自动化那些消耗创始人注意力的工作流。规模化阶段的创业公司现在需要发展更广泛、在某些方面更关键的一系列运营职能,比如财务报告、合规监控、合同管理和客户支持等等。
构建 GTM 职能
挑战:有机增长有天花板,而大多数规模化阶段创始人在真正构建 go-to-market 职能之前,就会碰到它。
想法、MVP 和发布阶段的增长,常常来自创始人主导的销售:一次时机正好的 Product Hunt 发布,或与早期客户的个人关系。这种有机增长只能走到某一点,而大多数创业公司会在规模化阶段撞上限制。迹象包括用户曲线变平、获客成本上升,以及只有创始人亲自参与时才会推进的销售管道。
规模化阶段的增长,需要构建专门的增长引擎,以触达更广泛的新受众。大多数创业创始人此前可能从未真正运营过营销、销售和分析师关系项目。一个真正的 GTM 动作不仅需要建立新系统和流程,还需要创造品牌声音和产品叙事,说明你希望如何谈论自己的产品。因为在创业生命周期的这个阶段,你不仅需要触达新的个人用户,也需要触达投资者和企业买家等整个目标受众。
幸运的是,GTM 职能不需要很大才能有效。构建产品的同一套 AI 基础设施,也可以帮助你启动产品上市。
Claude 如何帮助规模化阶段的创始人
早期创业阶段把 Claude 作为产品本身的基础设施:验证想法的研究伙伴,设计和构建原型的工程团队,以及让单人创企成为可能的 AI 运营层。到达规模化阶段的 AI 原生创业创始人,现在可以继续用 Claude、Claude Code 和 Claude Cowork,以构建时的方式继续扩张。
把日常任务交给 Claude Cowork
规模化阶段的开始,应该是清醒地看见你现在最需要把时间和注意力投入哪里。对于从未构建过企业的首次创业者来说,这可能很有挑战。Claude 可以通过列出这个阶段只有你应该做的事情来帮助你,例如产品叙事决策、董事会关系、企业交易、创始人与创始人的对话。凡是不在这张清单上的,都是委派或交给 Claude Cowork 自动化的候选项。
用 Claude 生成当前运营层的瓶颈地图:所有仍然经由你路由的工作流、决策和审批。现在,让 Claude 推演当你一周不可用时,每一项会发生什么。那些停滞的工作流,就是你仍然亲自参与到足以阻碍进展的地方。
这些结果如何映射到你用 Claude 制作的创始人优先事项和责任清单?
接下来,需要压力测试你已经构建的系统是否真的准备好随业务增长而扩展。
用 Claude 映射当前工作流,然后问它:当你一周不可用时,每个工作流会发生什么。停滞的工作流,就是交接标准、升级路径或异常处理仍需收紧的地方。Claude 可以帮助分析失败点并推荐适当修复,以便你更新或替换 Claude Cowork 自动化。
把技术运营扩展为企业级基础设施
随着规模化,买家需要确信你的产品和组织可以作为长期基础设施被信任。和以往一样,技术工作仍然在代码库内部继续,但现在还需要处理代码库周围的技术工作。
第一步是把组织知识转换成可规模化系统。用 Claude 起草并维护企业采购预期会看到的书面基础设施,包括产品文档、支持手册和 SLA。
同时,指挥 Claude Code 根据企业合同要求的具体可靠性和安全标准审计并加固代码库,并构建 Discord 式社区支持过去不需要提供的技术支持基础设施:日志、监控、事件响应工具,以及让 SLA 真正可执行的可观测性层。
Claude Cowork 随后运行企业支持本身的运营层:工单路由、升级工作流、由产品变更触发的文档更新、续约跟踪,以及企业客户成功依赖的报告节奏。三者结合,可以让小团队拥有大得多的组织才具备的支持姿态,而这正是签下多年企业合同所必须证明的。
选出三个要求最高的潜在客户,或识别三个你非常想签下的理想客户。让 Claude 生成差距分析:这些账户中的企业采购团队在签署多年合同前,会期待看到哪些文档、SLA 和支持基础设施?你目前有哪些不足?用输出结果为 Claude Code 和 Claude Cowork 的技术与文档工作排序。
构建真正的 GTM 职能
创始人的拼劲把你带到了这里,但规模化创业公司需要创建并实施真正的 go-to-market 策略。AI 可以帮助你构建并运行完整 GTM 引擎。
Claude 可以从零开始协助构建基础 GTM 资源:市场细分、信息架构、分析师关系策略、销售手册,以及当你开始面对公开市场投资者、企业买家和华尔街分析师时重要的投资人指标叙事。每个受众都有自己的词汇,也会用自己的标准评估你。Claude 的任务,是把产品价值主张翻译成对每个受众细分都相关的产品营销方法。
现在,Claude Cowork 可以成为你的战术执行层:内容管道、出站序列、分析师简报安排、新闻室和公关节奏、CRM 卫生、管道报告,以及许多把 GTM 策略转化为真实商业动作的重复周期。
在 GTM 动作需要产品营销基础设施时,比如交互式演示环境、集成文档、沙盒租户、API 参考、技术单页,Claude Code 可以为你构建它们。买家期望从技术上评估你的产品。在规模化阶段,一个 Loom 视频和一份销售演示稿已经不够了。这也是让 GTM 动作可以异步运转的基础设施:一个构建良好的演示环境,可以在你参加董事会会议时帮助成交。
把领域专业知识和组织知识转化为 AI 上下文
许多超精益创业创始人正在为自己在特定行业中亲身经历或一手观察到的真实问题,构建高度具体的应用或工具。智能体式 AI 让从未写过一行代码的创始人,也能用自己的领域专业知识构建解决复杂问题的产品。Claude、Claude Code 和 Claude Cowork 各自参与把创始人知识转化为复利增长的产品特异性。
使用 Claude 捕捉、组织和打磨创始人知识,可以把领域专业知识放到产品可以触达的位置。通过长期对话、项目和记忆,创始人可以分享自己知道的一切,包括行业黑话、监管陷阱、边缘情况、挫败点,以及为什么这个问题的显而易见答案不起作用,并把它们转化为结构化、可搜索的上下文。技能可以进一步把重复工作流编码成可复用例程,比如“我如何审计商业租赁合同”“我如何分诊患者入院表格”,让 Claude 每次都以同样方式执行。几个月后,这会成为普通通用 AI 无法匹敌的专有知识基底。
用 Claude 外化领域知识,对于把行业特定边缘情况编码进产品非常有价值。例如,一个通用 AI 医疗计费工具可能在处理 340B 药品计划申报时崩掉,而你的产品拥有针对它们的具体逻辑。Claude Code 帮助你把同领域专业人士常见的挫败感,转化为验证逻辑、提示优化,或与竞争者从未听说过的小众行业系统的 MCP 集成。结果是,你的应用或工具的深度和广度都会持续复利,以一种竞争者无法复制的方式增长。
识别一个通用竞争对手在你的垂直领域一定会处理错的边缘情况。和 Claude Code 一起基于你真实见过的场景,为它构建一个专门测试案例,这里不是单元测试。每当类似边缘情况出现,就把它加入测试集合。你的测试套件会变成护城河地图。
把累积用户数据复利为可防御优势
用户与你的产品互动时,会生成行为信号,比如他们接受哪些输出、拒绝哪些输出。这些信号会影响产品路线图。随着时间推移,你会了解自己特定用户群体的具体模式、偏好和边缘情况。这就是复利价值的意思:每一次改进让产品更有用,从而带来更多使用,更多使用产生更多反馈,更多反馈推动更多改进。
这些数据是被时间锁定、具有上下文特异性且无法被复制者重建的:你无法购买成千上万用户在你的产品中持续打磨工作流所形成的行为指纹。
Claude 可以帮助审计你收集到的任何用户互动数据,识别其中信号最高的行为模式,并设计反馈循环,把持续使用转化为系统性模型改进。
把你的产品互动数据摘要交给 Claude:你收集了什么、收集了多久、你了解用户如何随时间与产品互动。让它识别数据中三个信号最高的行为模式,并为每一个设计反馈循环,把它转化为系统性模型改进。然后让它帮你起草一页护城河叙事,用于产品营销:你的数据飞轮如何运转、已经转了多久,以及为什么一个资源充足的竞争者从今天开始也无法在两年内复制。
创造工作流锁定
复利的数据网络效应让产品更难被复制,而用户工作流锁定让产品更难被离开。用户在日常运营中运行你的产品越久,它就越深地嵌入他们实际工作的方式。他们在它之上构建了自动化,培训了人员使用它,并把它连接到自己的数据源和其他工具。他们开发的提示、打磨的工作流、标准化的输出,都已经围绕你的产品做什么以及如何做而形成。此时,切换不再只是产品决策,而是完整的运营项目。
创造工作流锁定的第一步,是让 Claude 按集成深度映射当前客户群。对每个客户细分,识别他们在你的产品上构建了哪些工作流,以及依赖哪些集成。这会显示你的产品在哪里粘住了用户,以及哪里需要更深入。
你提供的集成越多,客户就拥有越多表面积,可以构建依赖你产品的工作流。Claude Code 可以帮助你快速搭建与你目标用户依赖的数据管道、项目管理工具和其他系统的原生集成。Claude Code 也可以构建 API、webhook 和 SDK,让客户不只是使用你的产品,而是在你的产品之上构建,这是最深层的锁定。
让 Claude 帮你为前十个客户构建工作流集成审计。对每个客户,记录他们构建的自动化、依赖的集成、通过你产品运行的团队工作流,以及你对其切换成本的估计。然后让 Claude 识别群体中的模式:对你的具体产品而言,哪些类型的集成创造最深锁定?你可以构建或开放什么,来加深那些目前还停留在表层的客户集成?
同一份工作,新的规则
在 AI 时代,创始人的工作并没有改变:找到一个真实问题,构建能解决它的东西,并把它规模化为一家重要的公司。改变的是到达那里的路径。穿过想法、MVP、发布和规模化四个阶段,AI 把季度压缩成星期。
过去需要几个月的验证周期,现在可以在几个下午内完成。一个可工作的原型不再要求有一位掌握正确技术栈的联合创始人;它要求一个清晰问题,以及和编程智能体进行几次聚焦会话。发布就绪不再是发布前的混乱冲刺,而是一个持续工作流。到了规模化阶段,过去迫使早期招聘陷入救火角色的运营重量,越来越可以交给 AI,从而释放团队注意力,投入那些会成为护城河的判断。
瓶颈不再是你能构建什么,而是你选择构建什么。
资源
使用 Claude 构建
- Building AI Agents for Startups:分享创业公司如何使用智能体,在规模化时降低对创始人的依赖。
- Claude Code 文档:带领构建者从初始安装走向高级智能体式工作流。提示:从“How Claude Code works”概览开始。
- Claude Code 最佳实践:覆盖 Anthropic 内部和工程团队中已验证有效的模式,包括上下文管理、权限、规划和验证工作流。
- 使用 CLAUDE.md 文件:介绍如何为你的具体代码库配置 Claude Code。对于正在设置开发环境的 MVP 阶段创始人来说,这是必读内容。
- Claude Code 高阶用户技巧:突出 Claude Code 团队自身的工作流模式,包括并行会话和验证循环。
- Claude Cowork 入门:介绍团队如何设置 Claude Cowork,并开始实施技能、插件和其他能放大其在创业公司中影响力的功能。
- 教程:claude.com/resources/tutorials 提供可搜索的具体任务动手教程列表。
创始人故事
- 三家 YC 创业公司如何用 Claude Code 构建公司:考察 HumanLayer(F24)、Ambral(W25)和 Vulcan Technologies(S25)如何使用 Claude 让原型快速上市,并通过智能体式编程工作流扩展 AI 驱动平台。
- GC AI:其创始人使用领域专业知识,构建了一个由 Claude 驱动的法律平台,适配内部法务团队实际工作的方式:公司特定手册、跨职能利益相关方,以及可变风险容忍阈值。
- Carta Healthcare:使用 Claude 驱动临床抽象平台,每年处理 22,000 个外科病例,并将数据抽象时间减少 66%。
- Anything:由 Claude 和 Agent SDK 驱动,帮助 150 万用户在不写代码的情况下把想法变成可工作的软件产品,其中包括一位非技术创始人已经构建并开始销售完整招聘平台。Anything 的 AI 智能体处理完整构建,让单人创业者可以加倍投入领域专业知识。
- Cogent:一家应用 AI 实验室,构建智能体来自动化关键企业安全任务。该公司使用 Claude 作为智能体的推理层,自动化完整漏洞生命周期中的调查、优先级排序和修复。
- Airtree:使用 Claude Cowork 作为运营基础设施中心,把过去散落在十几个不同工具和团队中的数据统一起来。现在,当一个人用技能构建工作流自动化时,组织中的每个人都可以用它完成待办事项中那些一直没做完的事情。
- Duvo:构建 AI 智能体,在 ERP、供应商门户、表格、邮件甚至电话中运行采购、供应链和品类管理流程。Duvo 完全基于 Claude 构建,使用 Agent SDK 跨工作流编排。
- Zingage:面向居家护理机构的 24/7 自动化运营 AI 智能体平台。该公司使用 Claude 的结构化工具调用,在电子病历系统和多个沟通渠道之间编排,并使用 Claude 的上下文推理构建能够给出细腻、患者定制化结果的智能体,而不是简单匹配最常见回应。
- Kindora:一个由非营利组织高管使用 Claude Sonnet 构建的 AI 平台,用于智能匹配慈善机构与资助方。在把数千个匹配筛选成少数值得追踪的机会后,Kindora 的 MCP 连接器让非营利组织可以直接在 Claude 中访问其潜在客户开发工具。
- Wordsmith:由一位律师转型 CTO 的创始人创建,为企业内部法务团队提供可靠的 AI 法律技术。Claude 是 Wordsmith 合同审查、协议起草和文档审阅能力的推理引擎,该创业公司的工程团队也使用 Claude Code 构建和演进平台本身。
创业支持与机会
- Anthropic Startups Program:面向与 Anthropic 风投伙伴合作的创业公司,提供免费 API credits、公开可用最高层级速率限制,以及参加专属创始人活动和工作坊的邀请。
- Claude 社区:面向构建者的论坛和社区空间。
- 实时学习资源:会议、线上研讨会、直播和录播。