亨利·福特说：“我问人们想要什么，他们说要一匹更快的马。“但福特真正的天才不是发明了汽车——他发明了生产汽车的系统。没有装配线，T 型车只是另一辆昂贵的实验品。Launch 阶段的核心任务，是把创始人从"T 型车"变成"装配线”。
创始人成为瓶颈的那一刻
The Founder’s Playbook 描述了一个每个创始人都会经历但很少提前意识到的时刻：你不再是公司的加速器，你成了公司的限速器。
信号很具体：本该一小时的决策，你现在要一周才能排上；支持请求在堆积，因为只有你知道答案；运营任务只在你记得做的时候才发生；产品路线图卡在你这里，因为所有重要决定都要过你。
在 Idea 和 MVP 阶段，创始人在每个循环里是一种资产——你需要全局的认知和紧密的反馈循环。但到了 Launch，支持量在增长，产品在变复杂，运营在膨胀。那种"我亲自盯着"的习惯，开始反噬。
这不是一次突然发生的转变。它是一个渐进的过程，像温水煮青蛙。你某一天突然发现，公司不在"因为你而快”，而在"因为你而慢"。
全面审计：你在忙什么
The Founder’s Playbook 的解法是：全面审计你亲自在处理的每件事。
从最小的任务到最高风险的决策，全部列出来。然后分三类：
可以系统化的。 CRM 更新、周报生成、用户外联排期、bug 分类——这些是 AI 工作流自动化的理想候选。它们有明确的触发条件、决策规则和输出格式。
需要人但不一定是你。 某些支持请求、代码审查、内容审核——这些需要人类的判断，但不一定需要创始人的判断。可以委托给团队成员或 AI 辅助的初级处理。
真的需要创始人。 产品叙事决策、董事会关系、战略合作、创始人对创始人的对话——这些需要你独有的上下文和关系。
分类完之后，用 Claude Cowork 来设计自动化工作流的逻辑：什么触发、什么规则、输出是什么、完成后去哪里。
技术债的系统性清理
Launch 阶段的另一个紧迫任务是处理 MVP 阶段积累的技术债。
MVP 阶段，一些技术债是合理的——你用速度换取了代码质量。但在 Launch 阶段，那些债开始产生利息。生产流量在增长、新功能在叠加、代码库在膨胀——那些"以后再说"的捷径，现在成了结构性负债。
The Founder’s Playbook 建议三步走：先用 Claude Code 做一次完整的架构审计，找出脆弱的地方、维护成本高的捷径、测试覆盖不足的区域。然后把审计结果交给 Claude 做优先级排序——什么需要在下次发布前修，什么可以等一轮 sprint，什么是当前阶段可以接受的持续债。最后，把 MVP 阶段脑子里的架构决策写进 CLAUDE.md——那些当时没时间写下来的决定，现在该落地了。
安全与合规：不再是可选项
MVP 阶段，安全漏洞是理论风险——你的用户是 beta 测试者，没有敏感数据在生产环境里。
Launch 阶段，你的产品上有真实用户、真实数据，可能还有企业合同在谈。合规要求也是一样——处理客户数据、处理支付、卖到受监管行业，这些都不再是未来的事。
书中的态度很直接：在规模到来之前，而不是之后，做一次系统性的安全和合规审查。 把所有发现当作必须修复的项目，不是建议。
用 Claude Code 跑一次代码级安全审查，把结果交给 Claude 做优先级排序，然后逐个修复。同时把合规工作流嵌入开发周期——不是一次性项目，而是持续维护的流程。
轻量产品管理系统
Launch 阶段需要一套轻量、可重复的流程，能在不需要创始人触发的情况下运行。
The Founder’s Playbook 建议用 Claude 来设计这套系统：sprint 节奏怎么定、spec 在 Claude Code 碰一个功能之前需要包含什么、bug 报告怎么分流和路由、周报覆盖什么内容以及怎么分发。
设计完之后，用 Claude Cowork 来运行操作层：排 sprint 仪式、路由 bug 报告、从数据源编译周报、维护让用户信号流入产品决策的反馈循环。
三个工具的协同
Launch Stage 的一个特点是：Chat、Claude Cowork、Claude Code 三个工具进入全面协同。
Claude Code 做产品和技术工作——审计代码库、修复技术债、构建合规控制。Claude Cowork 围绕产品构建公司运营——自动化工作流、管理支持工单、运行 GTM 操作层。Claude 帮助把产品和组织知识操作化——设计流程、起草文档、做战略分析。
每个工具的产出成为另一个的输入。一个小团队能跑出比自身规模大 n 倍的公司，靠的就是这种协同。
我的反思
从创始人驱动到系统化运营，这个转变之所以难，是因为它不只是结构上的——它是心理上的。
很多创始人（尤其是技术创始人）的价值感和"我在做事情"绑定在一起。写代码、回邮件、做决策——这些具体的行动给了我在创造价值的幻觉。系统化意味着你不再"做事情"，你"设计做事情的系统"。你的产出不再是代码或邮件，而是规则和流程。
这让我想到一个关于管理者的经典定义：管理者通过别人来完成工作。
在 AI 原生公司里，这句话应该改成：“创始人通过系统和 AI 来完成工作。” 你的工作不是做事，而是设计做事的系统。
福特没有发明汽车——在他之前已经有几十个人发明了汽车。福特发明的是生产汽车的系统。同样，AI 原生创始人的核心竞争力不是"能做出产品"，而是"能设计一个持续产出产品的系统"。
下一篇，我们进入技术深水区：技术债与架构决策。
系列阅读快速跳转
| 日期 | 篇目 | 核心问题 |
|---|---|---|
| 06-03 | 从福特流水线到 AI 原生：范式转移 | 什么是 AI Native？为什么是现在？ |
| 06-05 | 找到你的问题域：从"能做"到"该做" | 如何在无限可能中找到值得解决的问题 |
| 06-06 | 用 AI 做压力测试：让魔鬼代言人替你思考 | 如何用 AI 反驳自己，避免确认偏误 |
| 06-07 | 构建第一个 AI 原生产品：从 CLAUDE.md 开始 | 写代码之前先写文档的逆向思维 |
| 06-10 | MVP 的四个暗礁：速度与陷阱的博弈 | AI 加速下最容易踩的四个坑 |
| 06-11 | 产品市场契合的谎言与真相 | 如何识别假信号，找到真契合 |
| 06-12 | 从创始人驱动到系统化运营 | 建立不依赖创始人的运营机器 |
| 06-22 | 技术债与架构决策：为 Scale 打下地基 | 如何在快与稳之间找到平衡 |
| 06-23 | 构建护城河：数据、知识与锁定 | AI 时代的三种防御体系 |
| 06-25 | Same Job, New Rules：创始人的不变与变 | 什么变了，什么没变 |