0326-构建产品是最简单的部分
输入“/”快速插入内容
0326-构建产品是最简单的部分
0326-构建产品是最简单的部分
用户9970用户9970
用户3733用户37335月9日修改
Instagram 联合创始人、现 Anthropic Labs 联合负责人 Mike Krieger 说了一句话值得所有 AI 时代的产品人反复咀嚼：
"构建是简单的部分。模型很擅长添加功能，但不擅长判断什么该砍掉。"
他让 Claude 花两小时重建了 Instagram 的前身 Bourbon——甚至自作主张加上了原本没有的滤镜。但他说，真正破圈的消费级产品并没有因此变多。原因很反直觉：速度越快，产品直觉的积累越难。
总结一下做个笔记👇
1️⃣ 室内种不出好树。 Dan Shipper 用了个比喻：在温室里种树，没有风的推压，树会长歪变脆。vibe coding 让你可以几小时从零到"最终产品"，但跳过了每一步跟真实用户接触的迭代，产品就像温室里的树——看起来完整，实则脆弱。这是精益创业在 2026 年的新表达：时间尺度变了，但"暴露给用户"这个核心没变。
2️⃣ 八个功能做不出好产品，第九个也不会。 Mike 回忆做 Bourbon 时的最大错误就是不停加功能而不是砍功能。现在 AI 让"加功能"变成零成本，这个陷阱反而更深了——他在 Labs 做的项目就因为"为什么不也加上"的心态，做成了一个功能矩阵，用户一进来就懵了。
3️⃣ 重写不再是公司杀手，反而成了最佳实践。 Fred Brooks《人月神话》说不要重写软件，Netscape 因此而死。但 Mike 说现在重写可能就是几天的事，尤其是基于已有代码。他们好几个项目在上线前甚至上线后都会推翻重来——"那是上周的事，这周我可以重新来"。痛苦感从"做了一年白费了"变成"上周做的不对，砍了重来"。
4️⃣ Agent native 不只是加功能，是让产品能自我修改。 Mike 举了个例子：有人在 Claude 里让"把这个加到项目知识库"，Claude 给出的是操作步骤而不是直接执行——"这不对，这应该是它能原生做到的事"。真正 agent native 的产品，从设计之初就把"它能了解并修改自己的每个 primitive"烘焙进去。Claude Code 是 2025 年的标杆，但更激进的形态是 harness 能修改 harness 本身。
5️⃣ AI 写的代码不能自证清白，你需要 Proof of Thoughtfulness。 不只是 proof of work（证明它能跑），而是 proof of thoughtfulness（证明你真的想清楚了）。Mike 说："有时工程师提交 PR，我问他为什么这样做，答案是模型做的选择。也许合理，但它是最佳选择吗？"这暴露了 vibe coding 的核心风险：你可能在用"还算合理"替代"深思熟虑"。
6️⃣ 别用 system prompt 修架构问题。 Mike 把 prompt 问题和系统架构问题类比：你不会用"那就 5 秒后重试一下"修补分布式系统，也不该用"绝对不要大写输出 markdown"修补 prompt 问题。他发现模型迭代 prompt 的自然倾向是不断加东西，最后变成给新员工第一天就塞一百条指令——"他们会短路"。
7️⃣ 分布式系统技能可能比写代码更有用。 Mike 笑着说他以为分布式系统知识不会再有用，结果成了最有用的技能之一。"到底需不需要 Redis，还是只用 Postgres 就行？"——这些决策模型还做不好，需要真正有经验的人。
8️⃣ "看起来还行"是一个项目的墓志铭。 Mike 说 Labs 砍掉项目事后复盘，发现共同点是：团队里没有一个人真正觉得这就是那个东西。最成功的人不是最强的，而是对问题空间有"撞破南墙不罢休"信念的人。可以是设计师，可以是产品导向型工程师，但很少是纯 PM。
9️⃣ 太快扩大团队是净负面的。 这个结论不太直观——即使想法很令人兴奋，更多人意味着更多协调、更多对齐对话。Artifact 团队从两人扩张到八人后，"我们还没找到 PMF 就陷入八个人的 Zoom 会议讨论下一步"。在 AI 领域，每三到六个月就要扔掉产品的一半，小团队 pivot 的能力远大于大团队。
🔟 愿意 unship 你的功能。 Claude Code 团队把"删除功能"作为准则。Mike 举了个例子：Claude 里的 styles 功能用的人不多但用得很重，他们想移除时发现有几家公司完全依赖——"CEO 亲自写的公司风格发给每个员工"。他的解决方案是建立插件和 skill 系统，让功能不需要活在核心产品里，用户可以"继续迭代它、把它变成自己的"。
1️⃣1️⃣ 企业客户和你的产品在赛跑，而且客户在赢。 Mike 说如果创业公司优化的是"巨型上市公司里的人现在就会买的东西"，就很容易被颠覆。Anthropic 的做法是告诉企业：这列火车会一直往前走，你可以关掉任何功能。公司们也接受一年期承诺，因为"他们能看到事情移动得太快了"。
1️⃣2️⃣ Open Claw 的真正贡献不是技术，是提出了"边界在哪"的问题。 Mike 说大多数产品的状态是"可以调用 MCP 但有权限门控"，而 Open Claw 的光圈"宽到我看不到边"。这个中间地带——不是完全 yolo，也不是严格受限——是 2026 年所有 AI 公司都在追的核心产品问题。
1️⃣3️⃣ 一个人能做的事的上限在增长，但那条线仍然存在。 Dan 提到：什么时候该给产品加人？到了某个点，即使你是推动者，整个东西装不进脑子里了。以前这条线很低，现在高了很多，但仍然存在。Instagram 消息功能一开始一个人一周搞定，后来变成了自己的产品需要自己的团队。
1️⃣4️⃣ 每个人都该有一个自己调教过的 agent，它会变成你个人能力的延伸。 Dan 分享了一个有趣的模式：他用 agent 做自己擅长的事，组织里的人因为信任他就信任这个 agent——"你得到了一个影子组织架构图"。Mike 把这比作 Q 和 Moneypenny 的关系——单点 agent 模式有独特的信任积累和 IKEA 效应。
---
长文版本
Mike Krieger：构建是简单的部分
断断续续，终于看完了这期 Stanford GSB 播客。
Mike Krieger，Instagram 联合创始人，现在 Anthropic Labs 做联合负责人。这期跟 Dan Shipper 对话，聊了将近 50 分钟，干货密度极高。我觉得 Mike 可能是目前在"AI 产品怎么造"这个问题上思考最深的从业者之一——不是那种在高处喊口号的，而是真的在泥里打过滚、亲手造过多个产品的。
他谈的核心问题是：当 AI 让构建变得几乎零成本，到底什么是难的？ 答案比大多数人想象的要深刻得多。
今天不忙，把这次访谈按话题重新整理出来，供大家学习。赠人玫瑰，手有余香。
---
#01 构建变快了，但产品直觉变难了
Dan Shipper 问了一个非常好的开场问题：随着 AI 改变了构建产品的底层基质，什么变容易了，什么变难了？
Mike Krieger： 几周前我做了一个思想实验。Instagram 的故事大家都知道——之前有个产品叫 Bourbon，做了将近一年效果不好，转了方向，三个月构建了 Instagram。我就问自己：现在哪些事变得微不足道了？而那个过程中本质上的东西，哪些没有变简单？
我发现即使今天的模型，它们也很擅长添加功能，但不一定擅长判断产品里应该砍掉什么。这需要真实的用户使用来锤炼。
现在，尤其是一些我们在 Labs 做的东西，你真的可以不只是从零到一，而是从零到最终产品，几个小时就能搞定。但过程中它做了很多决策。关于什么东西该放进去的那些直觉，我觉得是需要时间积累的。
所以我一直在反思，即使在 AI 加速构建的时代，真正破圈的消费级产品也没有那么多。我觉得部分原因在于，你仍然需要时间去打磨你对"你想给世界带来什么改变"的理解。
我让 Claude 基本上重建了 Bourbon，大概花了两个小时，功能齐全。它还加了滤镜——Bourbon 本来没有滤镜，那些是我们后来给 Instagram 加的。但它好像预知了产品的未来，所以直接就构建进去了。
这个点真的太重要了。 Mike 说模型甚至"预知了产品的未来"直接把滤镜加进去了——两小时就完成了 Bourbon+Instagram 的混合体。但他没有因此觉得"太棒了"，而是开始反思：为什么速度这么快，破圈产品反而没有变多？
Dan Shipper 接着用了一个让我拍案叫绝的比喻：
Dan Shipper： 我脑子里一直有个想法——如果你在室内种树，不暴露在风里，它就不会长得那么强壮。因为树在生长过程中，需要那些来回推压的力量，才能真正长成一棵好树。如果你在室内无风的环境里种树，它会歪斜、变得脆弱。
我觉得你说的就是这个意思——因为我们大大加速了开发速度，那些本该一步一步来、每一步都暴露给用户的迭代过程，现在你可以直接在室内种出一整棵树，然后你就有了这么个东西，但它在每一步都缺乏那种直觉和对经验的接触。
Mike Krieger： 我太喜欢这个比喻了。
Mike 接着分享了他自己在 Labs 的教训——他做的 Proof 项目就因为 vibe coding 太上瘾，忍不住一直加功能，"做出来一个怪物，不太好用"。后来他受到另一个产品 Monologue 的启发（一个极简的语音转文字应用），把产品推翻重做，简化成一个可分享的 markdown 链接，结果开始在内部病毒式传播。
说实话，这个经历太真实了。 Vibe coding 最大的诱惑就是"为什么不也加上"——当你进入了一个很好的心流状态，不断发东西、去吃午饭、回来，东西就做完了，你会觉得太好了又加了一个功能。Mike 说他们最终"创建了一个功能矩阵，实际上很难测试、很难跟上，也很难向用户解释"。
他还打了另一个比方：就像你是一集一集看一个剧慢慢认识角色，还是被直接扔进最后一集——"你会说等等这都是什么？这些人都是谁？我已经被期望有了所有的上下文？"
#02 重写不再是噩梦，删除才是最大的勇气
Mike 聊到他们怎么应对"过度构建"的问题时，说了一个让我非常意外的观点：
Mike Krieger： 经典的 Fred Brooks《人月神话》说你不要重写软件，因为 V1 里积淀的所有东西你都会搞丢。还有"第二系统综合征"。这确实有道理，但一方面，模型可以帮你 diff，看看你有没有遗漏第一个版本里的东西。另一方面，重写不再是一个可能杀死公司的年度工程了——著名的 Netscape 重写之类的。现在可能就是几天，尤其基于已有的代码。
所以我们确实有好几个项目，通常在上线前，偶尔上线后，我们会构建完整的东西，然后发现过度复杂或做了错误的核心假设，然后拆掉做 V2。
这太有意思了。 以前"重写"是产品经理的噩梦，是 CEO 的禁忌。但现在 Mike 说这成了 Labs 的常规操作——痛苦感从"天哪做了一年白费了"变成"哦那是上周的事，这周可以重新来"。
他还谈到 Claude Code 团队的一个准则：
Mike Krieger： Claude Code 团队做得很好的一点是把"删除功能"作为团队的准则——如果这东西不行，让我们 unship 它。通常是因为你创建了别的东西，即使不完全替代它，也做了足够多的同样的事，让它值得被弃用和移除。
不过他也坦白说，在企业端这越来越难。他举了个很生动的例子：