AI 原生创业手册：拆解 the Founder's Playbook

赫拉克利特说：“人不能两次踏入同一条河流。“创业这条河也不例外——河水在变，河岸在变，但过河这件事本身，从未改变。 什么变了 The Founder’s Playbook 的最后一章叫"Same Job, New Rules”，开篇第一句话就点题：在 AI 时代，创始人的工作没有变——找到真实的问题，构建解决方案，把它变成一个重要的公司。变的是到达那里的路径。 过去九篇文章，我们逐层拆解了这条新路径的每个阶段。 Idea Stage 变了。 过去，验证一个问题需要几个月的调研和几十场访谈。现在，AI 帮你做竞争分析、设计访谈框架、自动化外联——验证周期从几个月压缩到几周。但"验证"本身的必要性没有变，反而因为构建成本的降低而变得更加重要。 MVP Stage 变了。 过去，做一个原型需要一个团队几个月的工作。现在，agentic coding 让一个人一个下午就能做出一个看起来像那么回事的产品。但"产品市场契合"的标准没有变——用户是否真的在乎，不会因为你的产品做得更快而自动成立。 Launch Stage 变了。 过去，从产品到公司需要招一个运营团队。现在，AI 工作流自动化让一个小团队能跑出大团队的运营效率。但"系统化运营"的目标没有变——你需要不依赖创始人的系统。 Scale Stage 变了。 过去，构建护城河需要几年时间和大量资源。现在，AI 让领域知识的编码和用户数据的复利变得更快。但"护城河"的本质没有变——时间积累的东西，仍然需要时间来积累。 什么没变 这是更重要的问题。 判断力没有变。 AI 能帮你做研究、写代码、起草文档、分析数据。但它不能告诉你"这个问题值不值得做”、“这个方向对不对”、“这个时机该不该出手”。这些判断需要你独有的上下文——你的行业经验、你的直觉、你对用户的理解。 领域知识没有变。 AI 是通用智能，它不知道你所在行业的那些"只可意会不可言传"的东西。340B 药品项目的计费逻辑、建筑行业的合规要求、法律行业的风险偏好——这些需要真实经验的东西，AI 只能辅助，不能替代。 用户信任没有变。 用户选择你的产品，不是因为你的 AI 有多强，而是因为他们相信你能解决他们的问题。信任来自真实的对话、可靠的交付、和长期的承诺。这些 AI 帮不了你——只能靠你自己。 创业的本质没有变。 找到真实的问题，构建解决方案，把它变成一个重要的公司。这句话在 2020 年、2026 年、和 2030 年都成立。工具在变，但创业的核心——为真实的人解决真实的问题——从未改变。 路径压缩，本质不变 The Founder’s Playbook 用一句话总结了 AI 对创业的影响：AI 把每个阶段的时间轴压缩了——验证从几个月变成几周，原型从团队工作变成个人工作，运营从小团队变成 AI 加一个人。 但压缩的是时间，不是工作本身。你仍然需要验证、需要构建、需要发布、需要规模化。你仍然需要判断力、领域知识、用户信任。你仍然需要在每个阶段做出正确的选择——只是现在，你有更好的工具来执行这些选择。 这让我想到一个关于摄影的类比。数码相机和 Photoshop 让"拍一张好照片"变得前所未有的容易——你不再需要暗房、不需要对曝光的精确控制、不需要等待胶片冲洗。但"什么值得拍"和"怎么构图"的判断力，仍然是摄影师的核心能力。工具变了，审美没变。 ...

中世纪欧洲的城堡有三种防御：护城河（让敌人难以接近）、城墙（让敌人难以突破）、和吊桥（让盟友自由进出）。AI 时代的护城河也有三种——数据飞轮、领域知识、和用户工作流锁定。 AI 让复制变容易，让积累变稀缺 2025 年，一个有趣的现象引起了投资圈的注意：一批 AI 原生公司的估值开始分化。有些公司功能看起来差不多，但估值差了一个数量级。区别在哪？ 护城河。 在 AI 让"复制一个产品"变得越来越容易的时代，功能不再是壁垒。一个有充足资源的竞品可以用几周时间复制你的功能。那什么才是真正不可复制的？ The Founder’s Playbook 给出了三个答案。每一个都建立在时间积累之上——而时间，是 AI 无法加速的。 第一条护城河：数据飞轮 用户和产品互动时产生行为信号——哪些输出被接受，哪些被拒绝。这些信号随时间积累，变成你的产品路线图。 The Founder’s Playbook 把这叫做"复利价值"：每一次改进让产品更有用，更多使用产生更多反馈，更多反馈驱动更多改进。这就是数据飞轮。 这种数据有三个关键属性。时间锁定的——你买不到数千个用户在你的产品里优化工作流留下的行为指纹。上下文特定的——这些数据是在你的产品、你的用户群体、你的使用场景中产生的，换个环境就不一样了。不可能被复制的——即使竞品知道你有这个飞轮，他们也无法在短时间内重建。 书中给出了一个具体的练习：把你的产品互动数据（收集了什么、收集了多久、用户如何随时间互动）交给 Claude，让它识别三个最高信号的行为模式，然后设计一个反馈循环，把每个模式变成系统性的模型改进。最后，让它帮你起草一页"护城河叙事"——你的数据飞轮怎么转、转了多久、为什么一个有充足资源的竞品今天开始做，两年内也复制不了。 第二条护城河：领域知识外化 很多 AI 原生公司的创始人做的是高度具体的应用——他们在某个行业里亲身经历过的问题。Agentic AI 让这些没有工程背景的创始人也能用领域知识构建产品。 关键在于：把你的领域知识放进一个结构化的、AI 能访问的上下文里。 通过长期对话、项目和记忆，把你的行业知识——行规、监管陷阱、边缘 case、为什么显而易见的答案行不通——放进 Claude 的上下文。然后把这些编码成 Skills，让 Claude 每次都以同样的方式执行。 书中举了一个精彩的例子：一个通用 AI 医疗计费工具会在 340B 药品项目上出错，但你的产品专门处理了这些逻辑。为什么？因为你有领域知识，而且你把它编码进了你的系统。 几个月后，这就变成了一种专有的知识基底，通用 AI 做不到。一个没有你这种领域经验的竞品，即使有同样的 AI 工具，也会在你的细分领域里反复踩坑。 你的测试套件就是你的护城河的地图。 每一个你处理过的边缘 case，都是竞品还没踩到的坑。 第三条护城河：用户工作流锁定 数据飞轮让产品更难复制，但工作流锁定让产品更难离开。 用户在你的产品上构建了自动化，培训了团队，连接了数据源。他们开发的 prompt、优化的工作流、标准化的输出——都是围绕你的产品塑造的。这时候，换产品就不再是产品决策，而是一个全规模的运营项目。 The Founder’s Playbook 给出了一个实操方法：让 Claude 按集成深度映射你的客户群。对每个客户群体，识别他们在你的产品上构建了哪些工作流、依赖哪些集成。这显示了你的产品在哪里"粘"得牢，哪里还需要加深。 集成的数量和质量是关键。你提供的集成越多，客户就有越多表面面积来构建依赖你的工作流。Claude Code 帮你快速构建原生集成——数据管道、项目管理工具、用户依赖的其他系统。更深一层的锁定：构建 API、webhook 和 SDK，让客户不只是"用"你的产品，而是"在之上构建"——这是最深形式的锁定。 ...

古罗马人在建造道路时，会先挖一条深沟，铺上多层砂石和碎石，最后才铺上平整的石板。他们知道：路能走多远，取决于地基有多深。今天，你的代码库就是那条路——而 CLAUDE.md 就是你的地基剖面图。 两种技术债 不是所有技术债都一样。理解这一点，是 Scale 阶段的第一课。 有意技术债。 你在充分知情的情况下，选择用代码质量换取速度。你知道这笔债的存在、它的规模、以及什么时候该还。这种债是投资——你借了时间，计划在某个 sprint 里连本带息还清。 无意技术债。 你不知道它的存在，或者你知道但不知道它有多大。它来自"先这样吧"的临时方案、来自"以后再重构"的承诺、来自那些"能跑就不要动"的模块。这种债是高利贷——利息在暗处累积，直到某天你发现已经还不起了。 在 AI 原型的场景里，The Founder’s Playbook 指出了一个特有的风险：Agentic 技术债是一种"超级无意债"。 为什么？因为 agentic coding 工具移除了所有曾经控制什么进入生产的自然瓶颈。过去，代码要经过设计审查、代码审查、测试——每一步都是制衡。现在，一个提示词就能让代码进入生产。速度是保证了，但质量控制的责任完全落到了创始人身上。 架构审计：看见你的地基 The Founder’s Playbook 建议在 Scale 阶段做一次完整的架构审计。 具体操作：让 Claude Code 审计你的代码库，产出一份结构脆弱性清单——哪里是脆的捷径、哪里测试覆盖不足、哪里模块边界模糊。然后让 Claude 对这份清单做优先级排序：什么会拖累下次发布，什么可以并行处理，什么是当前阶段可以接受的。 这个审计的价值不只是"修 bug"。它强迫你看见你的代码库——不是作为一个个文件，而是一个系统。大多数创始人在 Scale 阶段第一次真正"看见"自己的代码库，就像第一次站在高楼上俯瞰自己住了多年的城市。 从"能跑"到"能扛" Scale 阶段的技术工作不只是修代码——它是围绕代码构建基础设施。 企业买家在签多年合同之前，要看的不是你的产品功能，而是你的组织能不能成为一个可靠的基础设施合作伙伴。他们要看产品文档、支持 playbook、SLA 承诺。签了之后，他们会要求你兑现。 The Founder’s Playbook 给出了一个三层方案： 用 Claude 起草和维护文档。 产品文档、支持 playbook、SLA——这些是企业采购团队期望看到的。AI 帮你起草和更新，但内容需要你的领域知识来校准。 用 Claude Code 加固代码库。 审计和加固代码库，针对企业合同要求的特定可靠性和安全标准。构建日志、监控、事件响应工具、可观测性层——让 SLA 真正可执行。 用 Claude Cowork 运行企业支持运营层。 工单路由、升级工作流、文档更新（随产品变化自动触发）、续约追踪、企业客户成功依赖的报告节奏。 三个工具协同，让一个小团队能展示出比自身规模大得多的组织成熟度。 ...

亨利·福特说：“我问人们想要什么，他们说要一匹更快的马。“但福特真正的天才不是发明了汽车——他发明了生产汽车的系统。没有装配线，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 阶段，你的产品上有真实用户、真实数据，可能还有企业合同在谈。合规要求也是一样——处理客户数据、处理支付、卖到受监管行业，这些都不再是未来的事。 书中的态度很直接：在规模到来之前，而不是之后，做一次系统性的安全和合规审查。 把所有发现当作必须修复的项目，不是建议。 ...

1947 年，飞行员肯尼斯·阿诺德在雷尼尔山附近目击九个碟状物体，“飞碟"一词从此诞生。但大多数 UFO 报告最终都被证实是气象气球、金星、或光学错觉。数据不会说谎，但对数据的解读会。 创始人最容易对自己撒的谎 产品市场契合（Product-Market Fit，PMF）是创业中最被滥用的概念之一。每个创始人都在找它，但很多人找到的只是它的影子。 The Founder’s Playbook 对 PMF 的定义很克制：一个特定、可识别的用户群体，发现你的产品有价值到足以回来用（留存）、付费（收入）、或告诉别人（推荐）。 三个条件满足其一即可。但问题在于，每一个都可以被"伪造”。 三种假阳性 注册不等于激活。 用户来了，注册了，但从未真正用过产品的核心功能。你的注册曲线在涨，但活跃用户曲线是平的。这在有强外联驱动的产品中尤其常见——创始人的人脉网络能带来注册，但带不来留存。 收入不等于留存。 用户付了一个月的费，但第二个月就走了。这可能是因为你的产品解决了一个一次性需求（比如报税），也可能是因为用户只是"试试看"。一次性收入和持续收入之间的差距，就是"假 PMF"和"真 PMF"之间的距离。 热情不等于习惯。 用户在访谈中说"这个产品太棒了"，但第三周就不来了。人们说出来的喜好和实际行为之间，往往有一条巨大的鸿沟。斯坦福大学行为设计实验室的研究反复证实：自我报告的行为预测力，在大多数场景下接近随机。 从"推"到"拉" The Founder’s Playbook 给出了一个更本质的判断标准：你的产品是在"推"还是在"拉"？ 产品市场契合之前，留存需要持续干预。你要频繁外联、给激励、创始人亲自盯——所有的留存都是你"推"出来的。这就像推一辆没发动的汽车，你一松手它就停。 产品市场契合之后，产品开始自己做这些事。用户自己回来、自己探索新功能、自己告诉朋友。这时候你松手，车还在走——因为它有自己的发动机了。 这个转变很难量化，但你能感觉到。当你发现自己不再需要每天发邮件求用户使用，当用户开始主动给你发功能请求，当你的自然增长（而非付费增长）开始占比上升——这些信号加在一起，就是 PMF 的证据。 衡量框架：在用户来之前建好 上一篇文章提到过这个原则，但值得展开。 The Founder’s Playbook 建议：在第一个用户进来之前，就定义好你的衡量框架。具体来说： 设定留存基准。 Day 7 留存多少算合格？Day 30 呢？这些数字因产品类型而异——社交工具和 SaaS 工具的基准完全不同。但你需要一个数字，否则你无法判断"好不好"。 定义激活标准。 什么算"真正用了"？注册不算。完成第一次核心工作流才算。对于一个 AI 写作工具，可能是"生成了第一篇文章并导出"；对于一个 CRM，可能是"导入了联系人并创建了第一个 pipeline"。 预设"假阳性"模式。 注册了但没激活、付费了但没留存、初始热情但没有重复使用——当这些模式出现时，你的衡量框架应该能自动标记它们。 用 AI 做对抗性分析 当数据来了，The Founder’s Playbook 建议让 AI 对你的 traction 做 adversarial 分析——扮演最严厉的怀疑论者。 “这些注册数字里有多少是创始人的朋友？” “这个留存率在同行业里算什么水平？” “如果去掉前两周的外联推动，自然留存是多少？” ...