Mike Krieger 两小时重建了 Bourbon，然后说了一句很反直觉的话#

Mike Krieger（Instagram 联合创始人，现 Anthropic Labs 负责人） 最近做了一件很有象征意义的事：他让 Claude 重建了 Bourbon。

Bourbon 是他和 Kevin Systrom 在做 Instagram 之前，花了将近一年开发的位置签到 App。结果两个小时，功能齐全。Claude 甚至自己加了滤镜功能——因为它知道 Bourbon 后来变成了 Instagram，所以提前把滤镜做进去了。

两小时 vs 一年。这个故事听起来像是 AI 编程的胜利宣言。

但 Krieger 的感慨完全不是"好快好厉害"。他说的是：

当年我们花了一年做 Bourbon，最大的收获其实是发现它太复杂了，然后花三个月简化出了 Instagram。如果两小时就能做完，你根本不会经历那个"发现该砍什么"的过程。

这句话点破了一个很多人还没意识到的事：

AI 让"做出来"变简单了，但"知道该做什么"反而更难了。

播客主持人 Dan Shipper（Every 创始人）接了一个比喻，我觉得很精准：树在室内长大，如果没有风吹，就不会长得结实。因为树干需要风力反复推拉才会变粗变强。在室内种出来的树，看着是棵树，但它是歪的、脆弱的。

AI 加速开发，就像把树种在了室内。 你可以几小时就长出一棵完整的树，但它没有经历过风吹雨打——没有用户反馈的打磨，没有一步步迭代建立起来的直觉。整棵树看着完整，其实一推就倒。

阅读地图

这篇不讲抽象产品学，只回答三个问题：

1. 为什么 AI 一提速，最先炸的往往是目标、范围和验收
2. "产品判断"在 AI 时代到底是一种什么能力
3. 为什么下一部分必须先从 PRD / 范围裁剪 / 验收口径 开始，而不是直接开写

最容易翻车的不是"做不出来"，而是"越做越像样，但越来越偏"#

Krieger 的故事不是孤例。Dan Shipper 自己也踩过完全一样的坑。

他做了一个叫 Proof 的产品——一个 agent native 的协作营销编辑器。第一版完全是 vibe coding 出来的：

Vibe coding 太好玩了，太上瘾了。我就一直加功能，做这个，做那个……最后做出来一个怪物，不好用。

后来他看到另一个产品 Monologue——一个极简的语音转文字 App，只做一件事，做得极好。他受到启发，推翻重来，只留了一个核心功能：可分享的 Markdown 链接。

结果这个极简版本在公司内部开始病毒式传播，上线后直接爆了。

Krieger 在 Anthropic Labs 内部也遇到了一样的问题：

我们最近有个项目，V1 之前就过度建设了。因为你可以嘛。哦，这个功能？一个 PR 就搞定了。那加上吧。然后你去吃个午饭回来，发现 Claude 又做完一个，那也加上吧。最后我们搞出了一个功能矩阵，测试起来极其困难，给用户解释也讲不清楚。

"你可以"和"你应该"之间，差距从来没有这么大过。

我自己用 AI 做项目的时候也有完全一样的体感：脑子里有个模糊的想法，丢给 AI，它两小时就能给你搭出来一个看着很完整的东西——功能列表、页面布局、甚至测试脚手架都有了。然后你觉得不错，接着让它加这个、加那个……三天之后，你得到了一个功能怪物。

功能很全，但没有人能一句话说清楚这个产品到底在解决什么问题。

为什么以前没这么刺眼#

这些翻车案例背后有一个共同的结构性原因。

以前手写代码慢的时候，很多烂判断会被实现成本拖住。你想法再飘，真要一点点敲页面、改接口、联调、回归，项目天然会被迫收敛一轮。这个过程当然不舒服，但某种程度上也像一种被动熔断。

现在这层被动熔断没了。页面可以很快生成，接口可以很快搭出来。于是原来藏在后面的那些模糊判断，会直接跑到台前来：

• 目标模糊 → AI 会自动脑补
• 范围没收 → AI 会顺着隐含需求一路扩写
• 没有非目标 → AI 会把"顺手做一下"当成美德
• 验收不清 → AI 会用"看起来差不多"糊过去
• 优先级没排 → AI 会默认把最容易做的先做掉

代码生成能力像发动机，产品判断像方向盘和刹车。 发动机越强，方向盘打歪的代价越大。

产品判断实战：这本书的主线项目是怎么收敛出来的#

讲了这么多别人的故事，我想用自己的一次亲身经历来收束这一篇。

这本书需要一个贯穿全程的主线项目——不是那种"为了讲知识点而编的 demo"，而是一个真正有产品价值、能逼出 AI Native 开发全链路能力的实战项目。

选什么项目，我纠结了挺久。这个过程本身就是一次产品判断的实战。

第一轮：丢给 AI，拿到一个大而全的怪物#

我的起点其实很模糊：想要一个能融合 Context Engineering 和 Harness Engineering 的产品，主要解决文档维护和架构可视化的问题。我把这些想法丢给 AI，让它作为一个"AI 产品经理"来帮我设计。

结果我拿到了 ContextWeaver（语境编织者）：

看起来很完整，对吧？但我的反应是：这不是我要的东西。

问题出在哪？

• 它是一个"什么都想做"的全家桶——知识图谱、RAG、多 Agent、向量数据库、AST 解析、跨平台 GUI……每一个拉出来都够写一本书
• 读者不可能跟着做出这样一个东西，我也不能保证每一块都能在教学中讲透
• 更关键的是：它的核心痛点不够尖锐。 "文档会过时"确实是个问题，但 ContextWeaver 把它包装成了一个需要全链路重构的终极方案

这就是典型的"方向没定，执行力先溢出"。AI 非常勤奋地把我提到的每个关键词都展开了，但没有人先回答一个问题：这个产品到底先解决谁的什么痛点？

第二轮：收了一刀，但抽象层次还是不对#

我调整了方向。告诉 AI：不要做大而全的产品，要结合 Issue-Driven 和 Spec-Driven 的现有框架，让读者能快速跑通。

这次我拿到了 SpecSync（规范同步者）：

SpecSync 比 ContextWeaver 好很多了。它更轻，阶段拆得更清晰，读者的上手门槛也低了不少。

但我还是觉得不对。

它的核心问题是：SpecSync 是一个流程自动化工具，不是一个有独立产品价值的东西。 "同步 Issue 和 Spec"这件事，说到底是一个 CI check 或者 GitHub Action 就能干的活。读者跟着做完，会学到一些技术点，但不会有"我做了一个真正有用的产品"的感觉。

而且，它的交互形态太单薄了——主要就是终端里的文本流转。这本书要讲的是 AI Native 开发，如果主线项目的交互形态停留在"命令行里读 Issue 写文件"，那后面讲到 MCP、可视化、Agent 编排的时候就没有落脚点。

第三轮：找到真正的痛点，收敛出 GraphSpec#

SpecSync 还没凉透，我就在想另一个问题：我自己在开发中最常做的第一件事是什么？

不是写代码，不是看文档，而是画一张图——在白板或者纸上把要改的那块功能的结构画出来，搞清楚上下游关系，然后才开始动手。每次让 AI 帮我改一个深层功能，第一件事也是把相关的架构上下文喂给它，否则它改出来的东西一定跑偏。

这不是我一个人的习惯。这是所有开发者在面对复杂系统时的本能：先看清全局，再下手。

而 AI 的上下文窗口有限，不可能一次性塞进去整个项目的所有细节。这其实是 AI 辅助开发中最核心的认知瓶颈：不是 AI 不够聪明，而是它看不到全貌。

有了这个痛点锚点，产品定义自然就收敛了。我最终拿到了 GraphSpec：

三轮迭代，到底收敛了什么#

回头看这三轮，产品判断的核心动作其实只有三步：

每一轮都没有加功能，反而是在砍。从全家桶砍到流程工具，再砍到一个可视化白板 + MCP 接口。

这就是产品判断：不是想清楚"要做什么"，而是想清楚"不做什么"。

这个过程不只适用于"定义产品"

上面这三轮，是从一个模糊想法到一份粗糙 PRD 的收敛过程。但它不是一次性的事情——后面开发每一个具体功能的时候，也要走同样的路。

拿到 AI 给的方案后，第一反应不应该是"开干"，而是先问自己几个问题：

• 它解决了谁的什么痛点？够不够尖锐？
• 我能不能在一句话里说清楚这个功能的价值？
• 有没有把"顺手做一下"的私货夹带进来？

AI 给的方案再完整，也只是起点。你得自己判断哪些该留、哪些该砍、哪些得换一个角度重新想。 这个判断没人能替你做——AI 也不行。

这本书后面的每一章，本质上都在重复这个收敛动作：先定义清楚要解决什么问题，再让 AI 去执行。

GraphSpec 会作为主线项目贯穿整本书的每一个环节。不是某几章的示例，而是所有方法论和工程实践的统一战场。

不只是我这么想，行业也在往同一个方向收#

上面讲的这些，如果只是个人的体感，那最多算一段牢骚。但过去这段时间，头部产品其实都在往同一个方向收：把 AI 协作的入口，从"直接写代码"往前挪到规格、任务入口、验收和反馈闭环。

两个足够说明趋势的信号（2026-03-15 校验）：

• GitHub Copilot coding agent 把任务入口的权重拉得极高。 当 issue 被分配给 Copilot 时，它会吃进去标题、描述、已有评论和额外指令；但分配之后新增的评论，它不会自动感知。翻成人话就是：任务入口写得烂，agent 就会很忠诚地把烂需求执行到底。
• OpenAI《Harness engineering》 已经不只在讲"agent 能不能多写点代码"。 它在讲 PRODUCT_SENSE.md、PLAN.md、失败反馈和验证闭环。这类资产的核心，已经明显不是纯实现层材料，而是更上游的产品意图和收敛机制。

这两件事拼在一起，指向同一个结论：

AI 正在逼人把原本含糊的产品判断，提前写成它真的能执行的约束。

产品判断不是"想法更多"，而是"边界更清楚"#

如果把这件事说得太虚，很容易变成新黑话。所以我更愿意把它拆成几个非常具体的判断。

这些判断不是什么新鲜的方法论——版本目标、范围裁剪、验收标准，在传统软件工程里都有。区别在于：以前这些事不做，项目最多慢一点；现在这些事不做，AI 会把你的模糊放大成灾难。

谁能更早把这些边界钉住，谁就在事实上掌握了控制权——不管你的 title 是工程师还是产品经理。

真正厉害的人，不是每次都能多想十个功能，而是能更早判断：哪一个功能现在值得做，哪一个应该延后，哪一个虽然看起来酷但会把主线带偏。

这也是为什么 Part 2 不会一上来就写功能#

所以这一篇的任务，不是把读者训练成另一种"空谈产品"的人，而是先把一个认知种下去：

项目主线应该从产品判断开始，而不是从代码生成开始。

回到 Krieger 说的那句话：两小时做完 Bourbon，你永远不会经历"发现该砍什么"的过程。

这本书要做的，就是帮你在动手之前，先把这个"该砍什么"想清楚——不是帮你砍得更快，而是帮你在长出树之前，先想清楚这棵树应该长成什么样。

顺着这个逻辑，下一部分才会正式进入 PRD -> 需求收敛 -> 范围裁剪 -> 验收口径 -> 技术栈 -> 架构 -> 仓库规范 这条真正能把项目钉稳的路径——而这条路径的终点，就是 GraphSpec。

顺着往下读

下一篇真正接这件事的，就是 《拿到 PRD 后先做什么：需求收敛、范围裁剪与验收口径》。

那一篇会把这里讲的"产品判断"，继续落成项目启动阶段最具体的几个动作。