上周，Anthropic 在 Claude 官方博客上发布了《The Founder's Playbook: Building an AI-Native Startup》，一份 36 页的 PDF。我在 Claude 里和它一起读完了这份文档，然后做了三件事：

拆解它的核心框架;

围绕"如何选择建什么"这个命题做了一次深度讨论;

最后把 Idea 阶段的方法论工程化为一个可复用的产品需求审计技能。

这篇文章记录了整个过程。它既是一份读后感和方法论笔记，也是一个"从理论到工具"的实践案例。

一、这份 Playbook 在说什么

我完整地阅读了这份Playbook, 读到第五页的时候我意识到，这份文档在做的事情并不是要给创业者的AI 使用建议，它在重新定义AI时代"创业"这件事本身的含义。

该文的核心命题只有一句话：AI 让创业的瓶颈从执行力移到了判断力。

论证逻辑很简单：

42% 的创业公司死于做了没人想要的东西，这是 AI 时代之前的数据。

AI 出现之后，从有想法到有产品的距离被压缩到了几乎为零，Claude Code 一个下午能出一个可用的原型。这意味着能不能建不再是一个有意义的筛选器，但该不该建依然是，而且因为建造门槛消失，该不该建的判断失误会比过去更快地变成废代码库和烧掉的存款。

这个命题有一个隐含的张力：

它来自 Anthropic，而 Anthropic 正是让"建"变得便宜的核心推手。换句话说就是：我们让执行力贬值了，所以请把注意力转向判断力。

我觉得这个坦诚本身就值得尊重，它没有假装自己的产品只带来好处。

二、Idea 阶段：如何回答"该不该建"

Playbook 把创业生命周期拆为四个阶段：Idea、MVP、Launch、Scale。整份文档最密集、也最值得反复读的部分是 Idea 阶段，因为它是所有后续阶段的杠杆。Idea 阶段错了，后面三个阶段只是在高效地建造一个错误的东西。

这一阶段的方法论可以拆成四个层次。

第一层：三道门禁问题

Playbook 给 Idea 阶段设了三道退出标准。只有三道全部回答"是"，才允许进入 MVP。这三个问题是：

问题一：这个问题真实且具体吗？

"具体"是关键。Playbook 的判定标准是：你能不能精确说出谁遇到了这个问题、多久一次、严重到什么程度、他们现在用什么方式凑合着对付？如果说不出来，你还没有找到一个问题，你只有一个模糊的印象。

问题二：你的方案解决的是验证出来的问题，还是你最初假设的那个？

这个区分很锋利。它的潜台词是：做完用户访谈之后，真正暴露出来的问题大概率和你最初以为的不一样。如果你坚持解决最初假设的那个问题而不是验证出来的那个，你是在为想象中的用户做产品。

问题三：有没有足够的信号？

Playbook 在这里做了一个重要区分：永远不会有确定性，等待确定性本身就是一种失败模式。"足够"的标准不是统计学置信度，而是"足够多的定性证据，让建 MVP 成为一个有理由的赌注，而不是信仰之跃"。

这三道题的共同作用，是帮创始人区分"一个被验证过的判断"和"一个被 AI 加速了的确证偏误"。

第二层：问题陈述的锐化

Anthropic的这篇Playbook 提供一个具体的技术，可以把模糊的直觉磨成可测试的命题。文中举了一个例子：

"合同审阅太慢了" 不可测试。"太慢"是相对于什么？对谁而言？

锐化后变成："中型法务团队每个合同审阅周期花 3 天以上，因为修订意见散落在邮件线程里，而不是集中在一个带版本控制的文档中。"

这句话嵌入了 who（中型法务团队）、how much（3 天+）、why（邮件散落）、what（缺版本控制）。一旦精确到这个程度，你拿它去跟法务总监聊，对方的回答要么是"对，就这个"，要么是"不，真正的问题不是这个，是 X"。两种回答都是信号。

这个技术解决了一个根本问题：模糊的问题陈述只能得到模糊的反馈，而模糊的反馈什么都验证不了。

第三层：客户访谈的先手写再审计

知道了要访谈，那么如何访谈呢？

第一步：自己先手写问题。不要一开始就问 AI，创始人先写出访谈问题；

第二步：让 Claude 审计访谈问题，专门让它找三类问题：引导性问题、未来假设性问题、太宽泛的问题。

这个顺序是一种判断力训练。如果你把问题设计外包给 AI，你在最关键的一步上就放弃了思考。AI 的角色在这里是审计者，不是作者。

Anthropic在Playbook中还专门提醒：

不要问："你会用这样的产品吗？"

这是最经典的无效问题。

要问的是："上一次你遇到这个问题时，你具体做了什么？"

行为数据比意愿数据可靠得多。这个常识虽然在用户研究领域早就存在，但在 AI 可以批量生成访谈问题的环境下，反而更容易被跳过。

第四层：结构化对抗思维

Playbook 还直接点破了一个尴尬的事实：你让 AI 论证你的想法好，它一定能找到论据。AI 不会跟你说"这个想法烂透了，别做了"，除非你命令它这么说。

所以正确的操作是：不要让 Claude 论证 idea 可行，让它去研究、论证为什么你的竞争对手会赢、你会输。解决方案设计完成后后，再让 Claude 找出你的方案最依赖的三个假设，追问每个假设成立的条件和失败后的后果。

这样的设计其价值不在于"AI 能不能真的模拟出一个挑剔客户"（它当然不能完全做到），而在于：即使 AI 的反对意见只有 60% 的准确率，它也比你脑子里那个从不反对你的内在声音有用。本质是用 AI 的论证能力对冲 AI 放大的确认偏误。

整个方法论的内核

串起来看，Playbook 对"如何选择建什么"的回答是一个认知纪律框架，而不是一个预测工具。它不会假装能告诉你哪个 idea 会成功，实际上这永远不可能预先知道。因此需要做的是：最大化你在动手前暴露错误假设的概率，最大化你在用户对话中获取真实信号而非虚假安慰的概率，确保你建的东西解决的是验证出来的问题。

在这个框架里，Claude 不去做判断。判断始终是创始人的事。Claude 的角色是暴露你判断中可能出错的点。它像一面凹面镜，把光聚到你最不愿意看的地方。

三、我们在讨论中触及的几个问题

在阅读这份文档的过程中，我和 Claude 讨论了几个 Playbook 留了白的问题。

判断力能不能被训练或外包？

Playbook 把判断力定义为人独有的优势，但 Anthropic 自己的产品路线图显然在让 AI 越来越擅长判断。如果有一天 AI 的判断力也足够好了，创始人的独特价值在哪里？

讨论中没有得出一个确定的答案，但我认为：

判断力的训练方式恰恰是通过这个审计流程本身。当你反复用结构化对抗思维审视自己的假设，当你在每五场访谈后强制列出支持方和挑战方的证据，你其实是在训练一种认知习惯。这个过程本身在提升你的判断力。即便有一天 AI 的判断力足够做大部分决策，经历过这个训练的人也会更清楚地知道该在什么时候质疑 AI 的判断，以及在什么地方 AI 的判断天然有盲区。

代理技术债的复利效应到底多严重？

Playbook 提了 agentic technical debt 这个概念，说 AI 生成的代码会"以复利方式累积"，但没有给量化数据。CLAUDE.md 被当作解法，但它本质上是一个规则文件，规则覆盖不到的场景怎么办？

我的感觉是这是一个被严重低估的问题。我们目前对 AI 代码质量的讨论大多集中在"能不能跑"、"有没有 bug"这个层面。agentic technical debt 的害处是更深层的：代码虽然能跑了，但代码库本身变成了一个没人理解的东西。每一次 AI 在上一轮的烂代码基础上匹配风格继续生成，代码的可理解性就再降一级。CLAUDE.md 只能减缓这个过程，不能根治。根治可能需要一个我们现在还不知道的工具，或者一种新的代码审阅方式。

42% 的失败率在 AI 时代会上升多少？

Playbook 觉得失败率只会更高，但没有给出具体的预测值。

我自己的假设是：如果构建的成本趋近于零，验证的成本（用户的时间、注意力、信任）就会变成新的瓶颈。

AI 无法替你获取真实用户反馈。你可以在一个下午让 Claude Code 出一个原型，但你不能让 Claude Code 替你约到 15 个法务总监聊 30 分钟。这意味着成功和失败之间的差距会进一步拉大：

会做验证的人比以前更容易成功，不会做验证的人比以前更快地失败。

四、从方法论到工具：产品需求审计技能

读完 Playbook 讨论完要点之后，我产生了一个想法：

能不能把 Idea 阶段的方法论做成一个可复用的技能？

老话说，学以致用，我需要的不止是记住这些原则，而是每次有一个新 idea 的时候，能够让Claude Code或者CodeX按固定的流程引导我走完整套审计。

于是花了大约两个小时，做了一版产品需求审计技能（product-requirement-audit）。

设计选择

技能的核心设计是五个严格顺序的阶段，并加了一个启动判断环节。启动判断根据用户是带着"模糊方向"还是"具体假设"来的，以及有没有聊过用户，决定从哪个阶段入口。这避免了"用户已经有 20 场访谈数据了，技能还让他从问题锐化开始做"的尴尬。

阶段一：问题陈述锐化

把模糊直觉磨成可测试的问题陈述。先让用户自己描述，再用技能审计。

这个过程中，AI AGent专门找模糊措辞（"太慢""太贵""不方便"），然后输出一个包含 who、how much、why、what 的锐化版，附带三个压力测试追问。

阶段二：结构化对抗审计

这是整个技能最有原创性的部分。我设计了六个指定的攻击角度（问题真实性、付费意愿、替代方案、切入点、时机、执行风险），而不是笼统地说"请反驳我"。因为笼统的反驳容易变成空话，指定角度能逼出具体论据。对抗审计之后，再提取三个按致命程度排序的核心假设，带进后续的用户访谈中优先验证。

阶段三：客户访谈设计

这一步严格遵循 Playbook 的原则：用户先手写 8-12 个问题，然后 Claude 审计找三类坏问题（引导性、未来假设、太宽泛），给出修改建议。我额外加了一个访谈对象画像的分级系统，把潜在用户分成 A/B/C 三档，确保优先触达信号最强的用户。

阶段四：双向信号合成

这是对抗确认偏误的核心机制。每完成五场访谈，Agent 把所有笔记拆成两个清单：支持假设的证据和挑战假设的证据。然后追问一个关键问题：清单 A 显著长于清单 B 是不是因为你的提问方式或记录偏差，而不是因为数据本身？这个追问的设计直接来自 Playbook 里让 Claude 审视你自己的偏见的思路。

阶段五：三道门禁退出检查

把 Playbook 的三道退出标准变成了可勾选的检查清单。每道门禁不仅判断是否通过，还给出不通过时应该回到哪个阶段。这形成了一个闭环，而不是单次判定。

技能与原文的差异

Playbook 原文把 Idea 阶段的练习和警告分散在各处，没有明确的先后依赖关系。我选择把它们组织成严格顺序的流水线，因为实践中"先做对抗审计再做访谈设计"和"先做访谈设计再做对抗审计"效果完全不同。带着对抗审计暴露的致命假设去做访谈，你会自然地去问那些最能决定 idea 生死的问题，而不是泛泛地收集反馈。

另一个差异是：我把 Playbook 里暗示的操作变成了明确的 prompt 模板。比如原文说"用 AI 做魔鬼代言人"，我在技能里给出了一个包含六个攻击角度和输出格式要求的具体 prompt。这样做的好处是降低了执行门槛，坏处是可能过度规范了一个本是"启发式"的过程。这个 trade-off 值得在后续使用中观察。

五、初步测试

技能写完之后的第一次测试，用的是"AI 原生的 2D 游戏精灵生成应用"这个 idea。

测试只跑了一个启动判断。用户（也就是我）给出的描述里有 who（非专业的 AI 游戏开发者）、有场景（做小游戏自用/分享/变现）、有明确痛点（缺美术能力，工具不会用），而且已经和超过 20 个潜在用户聊过。

按技能的入口逻辑，这属于"有具体假设 + 已聊过用户"，应该从阶段四（信号合成）开始。但阶段四需要结构化的访谈记录，而 20+ 场交流并没有系统性的笔记。所以实际建议是：快速走完阶段一和阶段二（这两个阶段不需要额外做用户访谈），然后进入阶段三设计一套正式的访谈方案。

这场初步测试暴露了一个问题：技能的入口逻辑假设"聊过用户"就等于"有结构化访谈记录"，但现实中大多数早期创业者的用户对话是非结构化的。这意味着技能可能需要一个额外的"非正式对话转结构化记录"的辅助步骤，或者需要在启动判断里区分"结构化访谈"和"非正式交流"。

但整体的流程感是对的：从判断当前状态，到匹配入口策略，到给出具体的下一步建议。这个方向值得继续打磨。

六、这篇文章之外

三个收获。

第一，Playbook 最有价值的不是它的框架本身，而是它坦率地承认了 AI 在降低创业门槛的同时制造的新问题。确认偏误被 AI 放大、技术债以复利累积、创始人变成瓶颈。这些诊断之所以有价值，恰恰因为它们来自制造这些新工具的公司自己。

第二，好的方法论是可以被工程化的。Idea 阶段的五个步骤，Playbook 原文是分散的练习和警告，但稍加组织就能变成一个可以复用的审计流程。这不是在降低方法论的价值，相反，这是在检验它的可操作性。不可操作的方法论只是好看的文章。

第三，这篇文章的写作本身也是这个审计流程的一次间接测试：我在写"不应该用 AI 确认偏误"的时候，Claude 在帮我写这篇反思文章。这其实就是一个持续发生的张力的现场展示：我在用 AI 的工具分析 AI 带来的认知风险。工具和分析之间的关系是循环的。意识到这一点，可能是所有 AI 工具使用者最重要的一层自觉。

《The Founder's Playbook: Building an AI-Native Startup》可在 claude.com/blog/the-founders-playbook 阅读。本文讨论的产品需求审计技能已作为 Claude 技能保存，可在后续会话中通过 /product-requirement-audit 调用。