Anthropic CPO Mike Krieger：自下而上构建 AI 产品
摘要
Mike Krieger 是 Instagram 的联合创始人，现任 Anthropic 的首席产品官（Chief Product Officer, CPO）。在这段与红杉资本的对谈中，他从产品领导者的视角分享了在 AI 前沿实验室构建产品的独特方法论。他提出了一个核心理念：AI 时代的最佳产品不是自上而下规划出来的，而是自下而上（Bottom-Up）从研究原型中涌现的。他回顾了 Anthropic 的多个标志性产品——Artifacts、MCP 协议（Model Context Protocol）、Claude Code——的诞生过程，揭示了它们如何在"两三个工程师的小火花"中萌芽，而非源自高层的战略指令。他还分享了 AI 产品面临的核心挑战：用户上手难度大、AI 能力与用户实际使用之间存在巨大的"能力悬垂"（Capability Overhang），以及 AI 辅助编码在组织层面带来的二阶效应——当编码速度被 AI 成倍提升后，团队对齐、代码审查、设计决策等瓶颈变得更加痛苦。
正文
从 Instagram 到 Anthropic：产品哲学的反转
Mike Krieger 的故事本身就是硅谷的传奇。他是 Instagram 的联合创始人——一个曾经只"火热了一周"便卖给 Facebook 的创业项目。在 Anthropic，他担任首席产品官，管理着一个由前沿 AI 研究和消费级产品组成的复杂组织。
他分享了从 Instagram 时代到 Anthropic 时代最大的产品哲学转变：
"在 Instagram，我们采用自上而下的方式——3 到 6 个月的时间框架，规划和交付。这很常见，Thomas（第三排的那位同事）可以证明。但在 Anthropic，以及我与其他 AI 实验室同行的交流中，你必须允许更多的自下而上的创造力。 最好的产品往往是那些紧贴着模型构建的产品。而模型的真实能力，你往往只能在开发过程的后期才能感知到。"
这意味着产品领导者必须"反向"调整创意流程——从自上而下的控制型管理模式，转向更松散、更依赖基层实验的自组织模式。对 Mike Krieger 这种天生喜欢掌控的人来说，这并不容易，但也"开启了真正有趣的事情"。
Artifacts 的诞生：一个研究原型的蜕变
Mike Krieger 以 Artifacts 为例说明自下而上的产品路径：它最初是一个研究原型，然后被一位设计师和一位工程师接手打磨，最终被推向生产环境。
"这个故事我不仅从我们这里听过，也从其他 AI 领域的创作者那里听过。"——这似乎正在成为 AI 产品开发的一种普遍模式：研究人员探索能力边界 → 原型自然涌现 → 产品和设计团队将其打磨为可用产品。
MCP 协议的诞生：在第三次重复时抽象
MCP（Model Context Protocol）已经成为了整个 AI 行业开始采用的标准协议，但它的起源故事相当朴素。Mike Krieger 回忆道：
Anthropic 在实现 Google Drive 集成时采用了一套方案，在实现 GitHub 集成时又写了另一套完全不同的方案——两者本质上是同一件事：将上下文引入模型。 当第三个集成（即将是又一套全新方案）被提上日程时，团队踩下了刹车。
"我的通用模式是：做三次，在第三次时尝试找出抽象层。 "这正是 MCP 诞生的时刻——"好吧，这些集成的共同点是什么？方向在哪里？"
这绝非自上而下的产品规划——"我们需要一个更好的模型交互协议"——而是两个工程师说："我认为这是个好主意，我们去原型开发吧。"随后，团队投入时间打磨协议，使其真正开放，确保能够被 Anthropic 之外的社区采用。如今，MCP 已经从公司内部项目演变为一个社区驱动、包含微软和亚马逊等大厂参与的生态系统。
MCP 的下一步：从获取上下文到执行行动
Mike Krieger 对 MCP 的未来方向感到最兴奋的有两个领域：
- 从上下文到行动：V1 阶段解决了"如何将外部数据引入模型"的问题。但现在，真正重要的是"实际采取行动"——理想情况下，AI 应当不仅能够检索信息，还能自动执行工作流程。
- 智能体间交互：当 MCP 以及更广义的智能体开始互相通信时，正确的协议是什么？Mike Krieger 认为现在过早标准化还为时过早，但内部的探索已经非常有趣——"在什么时候，你的智能体会开始雇佣其他智能体？这个智能体经济会是什么样子？"
Claude Code 与 AI 编码的二阶效应
在被问及 Anthropic 的编码产品时，Mike Krieger 分享了一个令人吃惊的数字："我们超过一半的 Pull Request 是 Claude Code 生成的，现在可能已经超过 70%。 "
但这带来了深层的组织和流程挑战。AI 编码让团队内部的其他效率瓶颈变得"极度痛苦"——过去，一场对齐会议可能"仅仅"阻碍了 1 小时的工程产出，而现在它阻碍的可能是 4 到 8 小时的工作量。当代码生成速度被 AI 成倍放大后，产品决策、代码审查、架构方向等非编码环节的瓶颈变得更加尖锐。
"我们内部还在搞清楚生成式代码在代码库中应该扮演什么角色。你当然可以让 Claude 审查 Claude 生成的代码，再让 Claude 审核审查的结果……然后就变成了'套娃'（Turtles All the Way Down）。"
AI 产品的最大挑战：用户上手难
当被问及"什么让你夜不能寐"时，Mike Krieger 的回答直指 AI 产品最根本的困境："这些产品对于第一次接近它的绝大多数人来说，真的很难有效使用。"
他打了一个对比："当你第一次打开 Instagram，你知道该做什么——拍照就好了。但我们的 AI 产品绝对不是这样。"
"如果你以正确的方式去'握住它'，你可以获得惊人的结果。但只要稍微偏离惯常的使用路径，或者缺少某种洞察——比如'噢，你应该这样引入数据'或者'这是你可以做的事和正确的流程'——就非常容易用不好。"
他称之为"能力悬垂"（Capability Overhang）——模型的能力与普通人实际可调用的能力之间存在巨大的差距。
AI 使用中的"羞耻感"与社会化学习
Mike Krieger 观察到一个微妙但重要的现象：即使在 Anthropic 这样的 AI 前沿实验室内部，AI 的使用也不是均匀分布的。销售团队中有人用得炉火纯青（例如用 AI 准备会议），但也有人依然走传统路线。
他分享了一个管理启示：公开可见的使用行为能够打破"你是用 AI 做的吗"的羞耻感。 Anthropic 内部构建了一个集成到 Slack 的工具，大多数人选择使用公开频道模式。在绩效评估季，员工在公开频道中使用 AI 生成初稿——这在一开始让人觉得"怪异"，但现在已经成为被鼓励的行为。
"我观察到，新入职的年轻人带着'当然会用 AI 做大部分事情'的假设进入职场……他们没有那种羞耻感。这让我联想到 Midjourney 早期的社区——那种共享可见性非常重要。"
模型发布与内部使用的算力博弈
当被问及 Anthropic 的未来方向时，Mike Krieger 坦言了一个所有 AI 实验室都在面对的深层张力：
"每一个实验室都在进行着同一场对话：增量地，你是把额外的计算时间花在 RL 训练上，花在客户用例上，还是花在下一个预训练上？——算力的分配正变得极其重要。"
当 AI 模型自身成为一个需要大量推理算力的消费级产品时，每一次模型推理都在"直接消耗本可用于研究的时间"。他指出，这甚至不是指已知实验的算力——还包括那些"两个人在房间里想出的有趣新想法"，那些可能成为下一个测试时计算突破的奇思妙想。
Mike Krieger 对"将模型扣留不外发、仅用于内部部署"的策略持怀疑态度："我们从将模型放到真实世界中获得了很多反馈。如果我们没有看到市场的实际使用情况，我们不会以现有的方式构建 Claude 3.7 Sonnet。"
应用层的常见误区：把 AI 贴在旧 GUI 上
最后，Mike Krieger 为应用层创业者提供了两条精辟的建议：
-
不要从"轻 AI"慢慢变成"重 AI"——许多产品一开始在侧边栏塞进一个 AI 功能，结果 AI 永远停留在"次要界面"的感觉。当产品越来越走向智能体化时，旧有的 GUI 结构会越来越难以承载新的交互模式。你需要在某个时间点重新思考产品的核心构建块，让它们真正成为 AI 原生的。
-
令人震惊地，大量 AI 原生产品没有将应用的原始能力暴露给模型。他的意思是：用户可以向产品下达指令，但产品回答"抱歉，我没有被建成那样"——因为底层组件没有以模型可以调用的方式暴露出来。这两个问题是一体两面的：当你为 GUI 设计的软件上面"贴"了一个模型，你通常不会想到这个模型应该成为应用的"主要用户"。
Mike Krieger 的最终信息是：在 AI 时代，产品需要从底层被重新思考——不是把 AI 当作现有架构的附加功能，而是让 AI 成为架构设计的起点。