亨利·福特说：“我问人们想要什么，他们说要一匹更快的马。“但福特真正的天才不是发明了汽车——他发明了生产汽车的系统。没有装配线，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——那些当时没时间写下来的决定，现在该落地了。
这一步我自己的体会是：写下来这件事，比审计本身还重要。审计是发现问题，写 CLAUDE.md 是把"为什么这么决定"固化下来。下次新人或者 AI 接手时，不用再去猜你的意图。
安全与合规：不再是可选项
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 帮助把产品和组织知识操作化——设计流程、起草文档、做战略分析。
每个工具的产出成为另一个的输入。一个小团队能跑出比自身规模大几倍的公司，靠的就是这种协同。
从亲手做事到设计机器
从创始人驱动到系统化运营，这转变之所以难，是因为它不只是结构上的——它是心理上的。
很多创始人（尤其是技术创始人）的价值感和"我在做事情"绑在一起。写代码、回邮件、做决策——这些具体的行动给了你一种"我在创造价值"的幻觉。系统化意味着你不再"做事情"，你"设计做事情的系统"。你的产出不再是代码或邮件，而是规则和流程。
这让我想到德鲁克关于管理者的那个经典定义：管理者通过别人来完成工作。
在 AI 原生公司里，这句话应该改一改——创始人通过系统和 AI 来完成工作。你的工作不是做事，而是设计做事的系统。
福特没有发明汽车。在他之前已经有几十个人发明了汽车。福特发明的是生产汽车的系统。同样，AI 原生创始人的核心竞争力不是"能做出产品"，而是"能设计一个持续产出产品的系统"。
下一篇，我们进入技术深水区：技术债与架构决策。
系列阅读快速跳转
| 日期 | 篇目 | 核心问题 |
|---|---|---|
| 06-05 | 从福特流水线到 AI 原生：新的造法 | 什么是 AI Native？为什么是现在？ |
| 06-13 | 找到你的问题域：从"能做"到"该做" | 如何在无限可能中找到值得解决的问题 |
| 06-18 | 用 AI 做压力测试：让魔鬼代言人替你思考 | 如何用 AI 反驳自己，避免确认偏误 |
| 06-26 | 构建第一个 AI 原生产品：从 CLAUDE.md 开始 | 写代码之前先写文档的逆向思维 |
| 07-02 | MVP 的四个暗礁：速度与陷阱的博弈 | AI 加速下最容易踩的四个坑 |
| 07-09 | 产品市场契合的谎言与真相 | 如何识别假信号，找到真契合 |
| 07-15 | 从创始人驱动到系统化运营 | 建立不依赖创始人的运营机器 |
| 07-21 | 技术债与架构决策：为 Scale 打下地基 | 如何在快与稳之间找到平衡 |
| 07-26 | 构建护城河：数据、知识与锁定 | AI 时代的三种防御体系 |
| 08-01 | Same Job, New Rules：创始人的不变与变 | 什么变了，什么没变 |