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

希腊神话中，奥德修斯在塞壬女妖的海域航行时，让船员用蜡封住耳朵，把自己绑在桅杆上。他听到了歌声，但无法偏航。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 的讨论，只需要你的一句话。 ...

文艺复兴时期的大师在动笔之前，先画几百张草图。达·芬奇的笔记本里全是未完成的想法——不是因为他不擅长完成，而是因为他深知：思考的结构决定了作品的结构。今天，CLAUDE.md 就是你的草图。 先写文档，再写代码 这个建议反直觉到几乎冒犯。 你是创始人，你有一个经过验证的问题，你迫不及待要动手做产品。The Founder’s Playbook 却让你在写任何一行代码之前，先坐下来，和 Claude 一起定义并记录架构决策：遵循什么模式、避免什么依赖、接受什么权衡、为什么。 这不是官僚主义，这是防止 AI 把你的代码库变成巴别塔。 想想巴别塔的隐喻。如果每个 AI 会话都是一个工人，每个工人都说自己的语言、按自己的方式砌砖，最终的结果不是塔，而是废墟。CLAUDE.md 就是你的通用语——它告诉每一个进入这个项目的 AI：这个系统为什么这样设计、哪些边界不能碰、哪些权衡是刻意的。 为什么这件事在 AI 时代如此关键 传统团队里，架构知识通过代码审查、站会、文档、以及最重要的——人与人之间的隐性传递来维护。一个新工程师加入团队，通过和老工程师配对编程、一起吃午饭、在 Slack 上问"为什么"来学习系统的设计逻辑。 在 AI 原生团队里，你的"新工程师"是每一个新的 Claude Code 会话。它没有上下文——除非你给它。没有 CLAUDE.md，每次会话都从零开始推断结构假设。它能生成能跑的代码，但生成的代码没有连贯的心智模型支撑。 这就像让十个建筑师各自设计一栋楼的一层，但没人见过总平面图。每一层单独看都没问题，但它们合在一起会怎样？门可能开在承重墙上，水管可能穿过电线管道。 The Founder’s Playbook 把这种现象叫做"结构性不连贯"（structural incoherence）。代码能跑，能过测试，但背后没有一个统一的设计意图。问题不在任何一段代码，而在于所有代码从未被设计成能协同工作。 CLAUDE.md 里应该写什么 不是完整的规格书。你不需要在这个阶段写一份 IEEE 830 标准的需求文档。 你需要写的是决策和理由。为什么选 PostgreSQL 而不是 MongoDB？为什么接受这个技术债？为什么这个模块的边界划在这里而不是那里？ 举个例子，你可能会写： “我们选择 Next.js 而不是纯 React，因为我们预计未来三个月需要 SSR 来支持 SEO。这是一个刻意的选择，即使它增加了部署复杂度。如果三个月后 SEO 不再是优先级，可以重新评估。” 这段话告诉 AI 的不只是"用什么"，还有"为什么用"和"什么情况下可以改"。 范围文档：AI 时代的疫苗 和架构文档同等重要的是范围文档。 在 AI 时代，范围蔓延（scope creep）是一种全新的危险。过去，加一个功能需要一个 sprint 的工程师时间——这个成本本身就是一种制衡。现在，加一个功能只要一个下午。每一项单独看都理所当然：当然产品应该处理这个边缘 case，当然用户会想要那个工作流。 ...

苏格拉底说：“未经审视的人生不值得过。“在 AI 时代，未经反驳的创业想法不值得做——而 AI 给了你一个永不疲倦的反驳者。 确认偏误的新武器 1960 年，英国心理学家彼得·沃森做了一个著名的"2-4-6 实验”。他告诉受试者三个数字 2、4、6 遵循某个规则，让他们猜规则是什么。受试者几乎无一例外地先猜"连续偶数”，然后只举符合这个猜想的例子来验证。沃森的真正规则其实是"任意三个递增数字"——但很少有人主动去举反例来反驳自己。 这就是确认偏误：我们本能地寻找支持自己信念的证据，而忽略或贬低反面证据。在创业中，这是致命的。 The Founder’s Playbook 指出了一个 AI 时代特有的危险：确认偏误现在有了一个研究引擎。 让 AI 验证你的创业想法，它会找到支持证据；让 AI 做市场规模测算，它会找到让 TAM 看起来可融资的数字。如果你不提出尖锐的问题，AI 可以比你更快地为一个坏想法构建出一套看起来像那么回事的"尽职调查"。 更危险的是，这个过程会让你感觉自己在做尽职调查。一份 30 页的市场分析报告、一组漂亮的 TAM/SAM/SOM 拆解、五个"验证过"的用户痛点——看起来严谨无比，但前提可能是错的。 结构化魔鬼代言人 解法是同一个工具，指向相反的方向。 天主教会在 1587 年设立了一个正式职位叫"魔鬼代言人"（Devil’s Advocate）——专门负责在封圣过程中提出反对意见，质疑候选人的圣迹和美德。这个职位的存在不是为了阻挠封圣，而是为了确保封圣决定的严肃性。 The Founder’s Playbook 建议你把 AI 当作你的结构化魔鬼代言人。具体操作分三步。 第一步：让 AI 攻击你的问题陈述。 不是让它说"这个问题很好"，而是让它构建一个论证：为什么这个问题没有你以为的那么大、不值得解决、或者已经被很好地解决了。让它找反例：哪些市场信号是负面的？哪些竞争对手失败了，为什么？用户行为模式里有哪些和你的假设矛盾的地方？ 第二步：让 AI 替竞品辩护。 让它分析竞品的方案为什么比你好、用户为什么选他们、你的差异化优势为什么没有你以为的牢固。这一步的价值在于，它会逼着你理解竞品的真实优势——而不是你为了方便而刻意简化的那个"竞品"。 第三步：让 AI 质疑你的解决方案。 你的方案依赖哪些假设？每个假设在什么情况下不成立？如果有一个假设被证伪，整个方案会怎样？ 压力测试之后 做完这三步，你大概会经历两种反应之一。 第一种：你的想法经受住了攻击，你知道了它最脆弱的在哪里——这让你在接下来的用户访谈中有了明确的测试方向。 第二种：你的想法被撕开了，你发现核心假设站不住——这是好消息。 不是"你失败了"，而是"你在动手之前就知道这条路走不通了"。 这让我想到查理·芒格的一句话：“我只想知道我会死在哪里，这样我就永远不去那个地方。” AI 让你有能力在创业之前，先快速"死"上几十次。每一次虚拟的死亡，都避免了一次真实的资源浪费。 用户访谈的框架 压力测试之后，才轮到用户访谈。书中建议用 AI 来设计和优化访谈框架——但有一个关键原则：问题要先自己写，再让 AI 审。 为什么？因为如果你直接让 AI 生成访谈问题，你会得到一组"正确但平庸"的问题。它们没有引导性、没有漏洞、也没有灵魂。但如果你先自己写——暴露你的偏见、你的假设、你的盲区——然后让 AI 来审，它会指出哪些问题在引导受访者、哪些太宽泛、哪些会得到社会期望的答案而不是真话。 ...

孙子曰：“夫未战而庙算胜者，得算多也。“在 AI 让"建造"几乎免费的今天，“算"什么、“算"哪里，反而成了最难的一道题。 无限可能，零值判断 2024 年秋天，我在旧金山参加了一场创业聚会。一个穿 Patagonia 背心的年轻人告诉我，他周末用 Claude Code 做了三个产品原型——一个 AI 法律助手、一个自动化记账工具、一个社交媒体内容生成器。“三个都能做，“他说，“但我不知道该做哪个。” 这不是个例。当 agentic coding 抹平了技术门槛，创始人面临的选择困境反而加剧了。过去，你能做什么受限于你会什么；现在，你能做什么几乎没有限制，但"该做什么"的判断难度陡然上升。 这就像一个厨师走进一个无限食材的厨房——真正的限制不再是食材，而是对"什么菜值得做"的品味。 问题的三个层次 The Founder’s Playbook 把 Idea Stage 的验证工作归结为四个按顺序回答的问题：这个问题真实、具体、频繁到值得围绕它做公司吗？谁有这个问题？有没有人在解决它？你的方案能做到吗？ 这些问题看似朴素，但每一个都暗藏陷阱。 “真实"不等于"你感觉到了”。 一个经典的创业认知偏差是：我是用户，所以我的问题就是大家的问题。这叫"自我抽样偏差”——你当然有这个问题，因为你就是你。但市场不是你的镜像。 书中给出的例子很精妙：“人们做报销很痛苦"是一个观察，不是假设。“中型公司的财务经理每周花四个多小时核对报销单，因为现有工具和他们的会计软件不互通"才是可验证的假设。前者让你感觉抓住了需求，后者让你能去验证。 “具体"是杀死模糊的刀。 德鲁克在《管理的实践》里说过类似的话：企业只需要做两件事——营销和创新。但如果你问创始人"你在解决什么问题”，得到的答案往往是"让工作更高效"或者"用 AI 改变行业”。这不是问题陈述，这是愿景口号。真正的问题陈述要具体到你能指着一个人说：“他，每天下午三点，正在经历这个问题。” “频繁"决定了你是在做公司还是在做项目。 一个一年发生一次的问题，用户不会为它付费——他们会自己忍着。一个每天发生四次的问题，用户愿意为任何能解决它的东西付费。频率决定了你的收入模型。 用 AI 做竞争地形图 找到问题域不只是向内看——你还得向外看。书中建议用 AI 做竞争地形分析，而且要用一种特殊的方式：让 AI 替你的竞争对手说话。 不是让 AI 列出竞品的功能对比表——那种表格谁都会做。而是让 AI 构建一个论证：为什么这个竞品会成功，而你会失败。让它分析竞品的方案为什么更好、用户为什么选他们、你的差异化优势为什么没有你以为的那么牢固。 这招来自军事战略中的"红队演练”（Red Teaming）。冷战时期，美国国防部专门组建团队扮演苏联指挥官，用苏军的思维来审视美军计划。效果显著——很多在美军内部"显而易见"的行动计划，被红队从敌方视角拆解得千疮百孔。 用在创业上，就是让你的 AI 扮演最了解你竞品的分析师。它会告诉你那些你因为太爱自己的idea而选择性忽略的东西。 客户发现的实操 找到问题域的最后一步是和人说话——不是"你觉得这个想法怎么样”，而是"告诉我你上次遇到这个问题时发生了什么”。 这里有一个创业研究中反复验证的发现：人们不擅长预测自己未来的行为，但很擅长描述自己过去的行为。 问"你会不会用这个东西"得到的是愿望清单；问"你上次遇到这个问题时怎么处理的"得到的是行为数据。 The Founder’s Playbook 建议用 Claude Cowork 来自动化客户发现的操作层：构建目标用户画像、生成外联邮件、管理排期、追踪访谈进度。但有一个原则——收集和初步分析可以自动化，但对话本身必须是人。 一个用户说"这个很好但我希望它也能……"，这句话背后的含义——是核心需求还是一厢情愿？是个人偏好还是群体特征？——只有人能判断。 退出条件 Idea Stage 的退出条件是找到"问题-解决方案匹配”：你有定性证据证明你在为真实的人解决真实的问题。三个检验——你能说清楚谁、多频繁、多严重、现在在怎么办吗？你的方案针对的是被验证过的问题吗？目标用户群构成一个真实的市场吗？ ...

1913 年，福特高地公园工厂引入移动装配线，汽车底盘的装配时间从 12 小时 28 分压缩到 1 小时 33 分。这不是效率的改良，而是生产范式的重构。今天，AI 正在对创业做同样的事。 一场安静的范式转移 1913 年之前，汽车是工匠在固定工位上逐件组装的。每个底盘架在同一个位置，工人围着它转。福特做了一件听起来很简单的事：让底盘动起来，让工人站着不动。装配线不是新工具，它是新范式——它重新定义了"造车"这件事本身。 The Founder’s Playbook: Building an AI-Native Startup 描述的就是这样一个时刻。2026 年的 AI 不是在"改良"创业流程，而是在重构"创办一家公司"这个行为的底层逻辑。 过去几年，我们见证了几个关键节点的到来。2022 年底 ChatGPT 发布，AI 从实验室走进客厅。2024 年 agentic coding 工具成熟，一个人可以在一个下午做出过去一个团队几个月才能交付的产品。2025 年，YC 批次的创业公司中，单人创始的比例显著上升——不是因为他们更孤独，而是因为 AI 让一个人能跑出一个团队的节奏。 这不是"效率提升"。效率提升是在同一个范式里做得更好。范式转移是——你不再需要优化旧范式，因为你换了一个。 什么是 AI Native？ 先说它不是什么。AI Native 不等于"用了 AI 的公司"。就像"移动互联网原生"不等于"做了个 App 的公司"——诺基亚有 App，但它不是移动原生。 AI Native 是一种组织范式：AI 不是工具层，而是基础设施层。 就像电力对工业革命的意义——你可以买发电机，但真正的变革来自整个工厂围绕电力重新设计。 在 AI Native 公司里，创始人的工作不是写代码、做研究、起草融资材料——这些 AI 都能做。创始人的工作是编排：决定用什么工具、在什么阶段、解决什么问题、达到什么效果。这就像福特工厂里的生产工程师，他不拧螺丝，但他设计螺丝被拧的顺序。 为什么是现在 三个条件同时成熟了。 Agentic Coding 让"构建"民主化。 过去，做一个软件产品需要技术联合创始人、外包团队，或者足够长的 runway 去招人。现在，一个没有工程背景的创始人可以用自然语言描述需求，让 AI 生成、测试、调试、重构生产级代码。从"有想法"到"有产品"的距离被压缩到几乎为零。 ...