AI

中世纪欧洲的城堡有三种防御：护城河（让敌人难以接近）、城墙（让敌人难以突破）、和吊桥（让盟友自由进出）。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 工具移除了所有曾经控制什么进入生产的自然瓶颈。过去，代码要经过设计审查、代码审查、测试——每一步都是制衡。现在，一个 prompt 就能让代码进生产。速度是保证了，但质量控制的责任完全落到了创始人身上。这一层责任，是 agentic 工具不会主动告诉你的。 架构审计：看见你的地基 The Founder’s Playbook 建议在 Scale 阶段做一次完整的架构审计。 具体操作：让 Claude Code 审计代码库，产出一份结构脆弱性清单——哪里是脆的捷径、哪里测试覆盖不足、哪里模块边界模糊。然后让 Claude 对这份清单做优先级排序：什么会拖累下次发布，什么可以并行处理，什么是当前阶段能接受的。 这个审计的价值不只是"修 bug"。它强迫你看见自己的代码库——不是作为一个个文件，而是作为一个系统。我自己的经验是，大多数创始人在 Scale 阶段第一次真正"看见"自己的代码库，那种感觉有点像第一次站在高楼上俯瞰自己住了多年的城市：你突然意识到有些路是断头路，有些楼是没有地基的。 从"能跑"到"能扛" Scale 阶段的技术工作不只是修代码——它是围绕代码构建基础设施。 企业买家在签多年合同之前，要看的不是你的产品功能，而是你的组织能不能成为一个可靠的基础设施合作伙伴。他们要看产品文档、支持 playbook、SLA 承诺。签了之后，他们会要求你兑现。 The Founder’s Playbook 给出了一个三层方案。 第一层是文档：产品文档、支持 playbook、SLA——这些是企业采购团队期望看到的东西。AI 帮你起草和更新，但内容需要你的领域知识来校准。 第二层是代码：用 Claude Code 加固代码库，针对企业合同要求的特定可靠性和安全标准。构建日志、监控、事件响应工具、可观测性层——让 SLA 真正可执行，而不是一句口号。 第三层是运营：用 Claude Cowork 跑企业支持运营层。工单路由、升级工作流、文档更新（随产品变化自动触发）、续约追踪、企业客户成功依赖的报告节奏。 三个工具协同，让一个小团队能展示出比自身规模大得多的组织成熟度。这件事看起来是技术问题，其实是组织伪装问题——你得让外界觉得你"像那么回事"。 知识编码：把你的脑子变成系统 Scale 阶段最容易被低估的挑战，是创始人的制度知识。 ...

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

1947 年，飞行员肯尼斯·阿诺德在雷尼尔山附近目击九个碟状物体，“飞碟"一词从此诞生。但大多数 UFO 报告最终都被证实是气象气球、金星、或光学错觉。数据不会说谎，但对数据的解读会。 创始人最容易对自己撒的谎 产品市场契合（Product-Market Fit，PMF）大概是创业里最被滥用的词。每个创始人都在找它，但说实话，很多人找到的只是它的影子。 The Founder’s Playbook 给的定义反而很克制：一个特定、可识别的用户群体，发现你的产品有价值到足以回来用（留存）、付费（收入）、或告诉别人（推荐）。三个条件满足其一就行。 问题就出在"其一"上——这三个信号，每一个都能被伪造。 三种假阳性 最常见的假阳性是注册涨、激活没动。用户来了、注册了，但从未真正用过产品的核心功能。你打开后台，注册曲线昂扬向上，活跃曲线却像一条死鱼。这种情况在有强外联驱动的产品里尤其多见——创始人人脉能拉来注册，但拉不来留存。 收入也是个大坑。用户付了一个月的费，第二个月就走了。这事在解决一次性需求的产品里几乎是标配——报税、年度合规检查、一次性数据迁移。用户掏钱那一刻你以为是 PMF，其实只是一次性需求被满足了。一次性收入和持续收入之间那道缝，就是假 PMF 和真 PMF 之间的距离。 但最伤人的，是访谈里的热情。用户当面说"这产品太棒了”，第三周就不来了。说出来的喜好和实际行为之间，有一条巨大的鸿沟。斯坦福行为设计实验室反复证实过一件事：自我报告的行为，预测力接近随机。 这句话我每次读到都觉得像被扇了一巴掌。 从"推"到"拉" The Founder’s Playbook 给了一个更本质的判断标准——你的产品是在被你"推"，还是在被用户"拉"。 PMF 之前，留存全靠你干预。频繁外联、给激励、创始人亲自盯，所有的留存都是你"推"出来的。就像推一辆没发动的车，你一松手它就停。 PMF 之后，产品开始自己做这些事。用户自己回来、自己摸索新功能、自己告诉朋友。这时候你松手，车还在走——它有自己的发动机了。 这个转变很难量化，但你能感觉到。某天你发现自己不再需要每天发邮件求用户使用，用户开始主动给你发功能请求，自然增长（而非付费增长）开始占比上升——这些信号叠在一起，就是 PMF 的证据。 衡量框架：在用户来之前建好 上一篇文章提过这个原则，但值得展开。 The Founder’s Playbook 的建议是：在第一个用户进来之前，就定义好你的衡量框架。我倾向于把这件事看得比"写第一行代码"还重要——因为一旦数据开始流，你就来不及冷静定义"什么算好"了，你会被数字推着走。 具体要做的几件事，先说留存基准。Day 7 留存多少算合格？Day 30 呢？这数字因产品而异——社交工具和 SaaS 的基准天差地别。但你必须给自己一个数字，否则"好不好"永远是一个情绪判断。 然后是激活标准。注册不算数，完成第一次核心工作流才算。AI 写作工具可能是"生成第一篇文章并导出"，CRM 可能是"导入联系人并创建了第一个 pipeline"。这个标准要硬，不能事后改。 最后——也是最容易被忽略的——是预设"假阳性"模式。注册了但没激活、付费了但没留存、初始热情但没有重复使用。当这些模式出现时，你的框架应该能自动把它们标红，而不是让你事后拍脑袋回忆。 用 AI 做对抗性分析 数据进来之后，The Founder’s Playbook 建议让 AI 对你的 traction 做一次 adversarial 分析——让它扮演最严厉的怀疑论者。 “这些注册数字里有多少是创始人的朋友？” “这个留存率在同行业里算什么水平？” “如果去掉前两周的外联推动，自然留存是多少？” 这些问题你自己其实也能想到。但问题在于，创始人天生有一种倾向——把好消息当证据，把坏消息当例外。我自己写过几年量化策略，对此深有体会：人一旦对某个结果有情绪偏好，“客观分析"就开始失灵。AI 没这个偏好。它不会因为这是你的创业公司就对你温柔。 ...

希腊神话中，奥德修斯在塞壬女妖的海域航行时，让船员用蜡封住耳朵，把自己绑在桅杆上。他听到了歌声，但无法偏航。MVP 阶段，你需要同样的自律——听到"快"的歌声，但不被它带偏。 速度是一把双刃剑 上一篇文章我们讲了如何从 CLAUDE.md 开始构建产品。现在假设你已经有了架构文档、范围文档，代码开始跑起来了。 然后速度来了。 Agentic coding 工具让"构建"变得前所未有的快。一个功能从想法到上线，过去要一个 sprint，现在要一个下午。这种速度让人上瘾——你开始觉得"再做几个功能"、“再处理几个边缘 case”、“产品再完善一点再发”。 The Founder’s Playbook 把 MVP 阶段的核心矛盾归结为一句话：AI 保证了速度，但速度本身成了最大的风险。 接下来要说的四个暗礁，都和这个矛盾有关。 第一个暗礁：Agentic 技术债 普通技术债是可以管理的——你欠了，但知道要还，可以在某个 sprint 里集中清理。 Agentic 技术债不一样。它会累积。 原因在于：没有写下来的架构约束，每个 AI 会话都从头推导基础决策。这个会话决定用 REST API，那个会话决定用 GraphQL；这个会话把用户认证放在前端，那个会话把它放在后端。每个决策单独看都合理，但它们合在一起——代码能跑，但背后没有一个连贯的心智模型。 这就像让十个厨师各自做一道菜，但没人告诉他们这是同一桌宴席。每道菜单独吃都没问题，但放在一起，口味冲突、温度不一致、上菜顺序混乱。 The Founder’s Playbook 的建议是：在 MVP 阶段就保持 CLAUDE.md 的更新。每个会话结束，花五分钟记录这个会话做了什么决策、引入了什么假设。这不是文档洁癖，是防止你的代码库在第六个月变成一团只有 AI 能读懂的意大利面。 第二个暗礁：假产品市场契合 这是最危险的暗礁，因为它看起来像陆地。 发布产品的那一刻，是创始人最脆弱的时刻。几周的验证、几个月的构建，终于有了一个能跑的东西。你的朋友来试用，投资人介绍的潜在买家来试用，一条 Hacker News 头条带来一波流量——早期数字看起来不错。 但早期 traction 不等于产品市场契合。 Launch 能量来自短暂的、外部的助推力。真正的产品市场契合是一个模式——它必须在多个迭代周期中持续成立，才能被确认。 书中提到了 Sean Ellis 测试：问你的活跃用户"如果你不能再用这个产品了，你会感觉怎么样？“如果超过 40% 回答"非常失望”，这是一个有意义的信号。 但更根本的检验是从"推"到"拉"的转变。产品市场契合之前，留存需要持续干预——频繁的外联、激励、创始人亲自盯。产品市场契合之后，产品开始自己做这些事。当你发现自己在"推"的力气开始变轻，那才是真正变化的信号。 第三个暗礁：零摩擦范围蔓延 每个功能只要一个下午。每个边缘 case 只要几分钟。每一项单独看都理所当然。 这就是 AI 时代范围蔓延的新形态。传统的制衡——工程师时间的真实成本——不存在了。加一个功能不再需要一个 sprint 的讨论，只需要你的一句话。 ...