Anthropic首席产品官：从Claude到MCP，最好的AI产品不是计划出来的，是从底层自发长出来的

作者 |Sequoia Capital

来源 | Z Potentials  管理智慧 AI+

引言

从长期看，大多数内容将由 AI 生成。所以 " 这是不是 AI 生成的 " 这个问题将变得无意义真正。值得关注的是内容的来源、溯源和引用等问题。而讽刺的是，AI 反而可能更有助于解决这些问题。

最好的 AI 产品往往不是计划出来的，而是 " 从底层自发长出来 " 的。很多产品，只有在与模型非常靠近、深入实验后，才会逐渐显露其真正潜力。所以改变产品开发的路径，是从以往的 " 自上而下 " 转为 " 自下而上 "。

我能用 Claude 生成初稿吗？这是不是 " 作弊 "？但现在，我们已经开始鼓励这种用法了。当然，用 AI 写完后你要自己校对，确保内容准确、有判断。但如果它能帮你节省两小时，让你腾出时间去做更重要的事——那为什么不用？

模型本能想 " 讨好 " 你，容易透露太多；但如果它什么都不说，又可能变得过度保守。这种细腻的判断力，目前还没有被很好地训练出来。

01

AI 生成内容的未来，不是真假之辨，而是可信与共鸣

Lauren：谢谢你的到来，Mike。大家可能不知道，Mike其实是个内容迷。能和这位热衷AI创作的人一起聊聊，非常有趣。你认为AI生成内容的发展趋势是什么？无论使用何种媒介、AI参与多少，核心问题始终是：有没有一个吸引人的故事？人们是否能感受到内容背后的人，从而建立起连接？所以AI只是讲故事者工具箱中的一个工具而已。我也很好奇你们是如何看待这个问题的：当你们不断制作内容、生成图像时，你们如何帮助用户保持对内容的掌控？比如你们在模型可解释性方面做得很好，那你们如何赋予用户理解或引导Claude这类系统的能力？

Mike：是的，有些问题在短期内仍然值得探讨，比如加水印来标记 AI 生成内容。但从长期看，大多数内容将由 AI 生成。所以 " 这是不是 AI 生成的 " 这个问题将变得无意义真正。值得关注的是内容的来源、溯源和引用等问题。而讽刺的是，AI 反而可能更有助于解决这些问题。有趣的是，这让我想起了区块链。虽然现在已经不算热门话题了，但区块链曾试图解决的一些问题，其实在整个内容生成和传播链条完全数字化的今天，更容易通过 AI 来实现。例如，以前我们常常关注一个文档的出处，比如有没有引用、是不是原创，这些问题现在依然重要，但在 AI 帮助下也变得更容易追踪。所以，未来重点不再是 " 这是不是 AI 生成的 "，而是 " 它来自哪里 "" 内容是否可信 "" 能否验证 "。

02

真正有价值的AI产品，从不是"规划"出来的

Lauren：很有意思。那我们深入聊聊Anthropic吧。你们在产品方面做得很出色，比如Artifacts、编程模型、MCP协议等。我很好奇，作为首席产品官，你在产品打造中有什么样的方法论？怎么让你们的产品不仅仅是"模型的包装"，而是比模型本身更有价值的东西？

Mike：我有两个想法。

第一点是，不论是在 Instagram 时代还是现在，判断产品是否优秀的标准并没有变——你是否在解决真实问题。比如做一个开发者工具，是否真的帮助开发者做到了快速、有趣、有创造性的事情？如果是面向终端用户的产品，那你是否真的满足了他们的现实需求？这些判断标准，在 AI 时代依然适用。

第二点是，我必须放弃以前的一些习惯。在 Instagram，我们会做三到六个月的计划，非常 " 自上而下 "、按部就班。但在 Anthropic，甚至在和 OpenAI 等同行交流时我发现，最好的 AI 产品往往不是计划出来的，而是 " 从底层自发长出来 " 的。很多产品，只有在与模型非常靠近、深入实验后，才会逐渐显露其真正潜力。所以我学会了改变产品开发的路径，从 " 自上而下 " 转为 " 自下而上 "。比如 Artifacts 就是最初的一个研究原型，后来被设计师和工程师接手优化，最后才进入产品化阶段。这种路径虽然不容易控制，但确实带来了很多惊喜。

Lauren：MCP是目前整个行业开始采用的重要产品之一，我很好奇它是如何诞生的，您有什么故事可以和我们分享吗？

Mike：关于 MCP 的诞生，其实特别有意思。有时候我在公司一半的工作就是做些内部梗图，其中一个就是调侃 MCP 刚诞生时只是两个工程师眼中的一个 " 小火花 "。最初的起点，其实是在我们尝试对接 Google Drive 和 GitHub。我们发现这两个功能虽然本质上都是 " 把上下文引入模型 "，但内部实现却完全不同。我们马上还要做第三个集成，看起来又将是一次全新的、重复造轮子的开发。所以我通常的模式是：做三次之后，就可以总结出抽象层级，形成标准。而 MCP 就是这么来的。一开始，并不是从 " 我们要制定一个统一的协议 " 这种顶层设计开始的，而是两个工程师觉得这样做更合理，于是就动手去原型验证、反复迭代。后来我们花了很多精力把这个协议做得更好、更开放，希望它不只是 Anthropic 内部使用的东西，而是真正有机会成为行业标准。现在，MCP 已经开始被更广泛地采用。我们团队虽然已经超过 1000 人，但整体氛围依然非常像初创公司。我们开始与微软、亚马逊等大型合作伙伴协作，涉及到各种复杂的身份验证、权限管理和企业集成问题。这些需求并不是我们一开始会预料到的，但当你开放系统、接触到更多真实用户场景后，这些复杂性自然就来了。

Lauren：MCP现在已经被很多人使用了。你们昨天刚发布了关于集成的新功能。从一个"自下而上"的想法出发，到现在落地扩展，你们是如何培育并发展这个产品的？

Mike：我目前最关注的两个方向，都是围绕 MCP 展开的。第一是 " 执行能力 "。MCP 最初的设计目标是引入上下文，现在我们已经可以集成 GitHub、触发 Zapier 等操作。但更重要的是——下一阶段，我们希望模型能主动完成任务。它们不仅要能 " 理解 "，还要能 " 行动 "，自动执行工作流。第二是 "Agent 之间的协作 "。我们现在还处于非常早期的探索阶段，甚至还不适合立即建立标准。但很明显，未来不同的 AI Agent 会相互交互、协作，甚至 " 雇佣 " 其他 Agent 来完成任务。这将形成一种新的 AI 经济系统。我们内部已经开始讨论，比如未来是否会出现 " 你的 Agent 为你雇佣另一个 Agent" 的场景。这些想法令人兴奋。

Lauren：你们在编程产品方面已经做得很成熟，看起来不只是"自下而上的小尝试"。你是如何看待这类产品的定位？你觉得目前做对了哪些事？

Mike：即使是编程这块，我依然充满敬畏。很多创新都不是靠 " 战略 " 定出来的，而是由几个研究员突破边界推动的。比如前面提到的 RL（强化学习）探索，就是从具体研究中自然发展出来的。

我们一直坚持的一点是：不仅仅盯着 Benchmark 分数，更重要的是——模型生成的代码用户是否喜欢用？它是否真正带来了好结果？这点我们会持续强化。"Vibe coding" 这个说法，其实不是我们提出来的，但它确实有一定价值。你用模型生成代码时，可能会感受到某种 " 氛围 " 或者 " 灵感 "，这在小项目里很有意思。但如果是要构建一个大型代码库、一个百人团队协作的工程系统，这种方式就不够用了。我们正在探索生成式 AI 在整个开发流程中的定位。比如，现在我们公司内部超过 70% 的 Pull Request 都是由 Claude 代码生成的。但这也带来一个新问题：代码审查怎么做？你可以用 Claude 来审查 Claude 生成的代码，但这就像是 " 套娃 " ——每一层都还是 AI。那我们该如何保持技术架构的可控性？是否会走入技术债的死胡同？这些问题，我们还在摸索，相信整个行业都在摸索。

我们内部感受到的最大变化之一是：AI 让工程效率大幅提升后，组织中 " 非工程环节 " 的低效变得更加刺眼。比如，以前一个对齐会议只会耽误一个工程师一小时，现在可能等于耽误了 "8 小时的 AI 产出 "。你会发现组织里的 " 瓶颈 " 并没有被 AI 优化，反而被放大了。这导致产品流程中的不协调变得更明显、更痛苦。虽然模型可以总结会议、提出下一步建议，但它们现在还做不到真正帮助我们做出组织层面的决策。

03

从工具到协作体：组织如何适应 AI 时代的效率重构

Lauren：你提到Anthropic内部在广泛使用Claude。能分享一下哪些使用方式是你觉得特别值得推广的吗？有没有一些你们过去半年内尝试、并且觉得其他人也应该尝试的用法？

Mike：我最喜欢看到的是——非技术团队开始主动使用模型。比如销售团队，会用 Claude 来准备客户会议。他们一开始只是用公共版本，但当碰到具体障碍时，我们就会根据他们的需求开发专属工具。这种需求驱动的方式，非常有效。不过坦率地说，即便在我们这样的 AI 实验室，使用 AI 的能力也分布不均。有的员工用得非常熟练，高效地解决问题；而有的人还停留在传统流程。我自己则把 Claude 当成 " 思维合伙人 "。无论是写战略文档、制定规划，还是写绩效评语，我都习惯先通过 Claude 进行一轮 " 脑力激荡 "。就像有了 Copilot 之后，我在飞机上没有它会觉得 " 不会写代码了一样 "，我现在也很难回到没有 AI 协助的写作状态了。

过去一年半里，我亲眼看到 Anthropic 内部的文化发生了变化。起初，很多人在写绩效评语、工作总结时会犹豫：我能用 Claude 生成初稿吗？这是不是 " 作弊 "？但现在，我们已经开始鼓励这种用法了。当然，用 AI 写完后你要自己校对，确保内容准确、有判断。但如果它能帮你节省两小时，让你腾出时间去做更重要的事——那为什么不用？我们有一个内部工具，可以跨越整个 Slack 和所有内部文档运行。它支持公共和私密频道，但大多数人更喜欢用 " 公开版 "，因为这意味着他们使用 AI 的过程是可见的。有趣的是，在绩效季时，很多员工开始用这个工具来生成评语初稿——而且是在公共频道里！这种 " 共享式使用 " 反而帮助打破了 "AI 使用羞耻感 "。这让我想起了 Midjourney 刚兴起的那段时间，大家都愿意公开展示自己用 AI 生成的图。这种 " 可见性 " 对于推动 AI 融入日常工作非常关键。我们还远没到 AI 全面普及的阶段，但可以看到，文化正在朝这个方向转变。

04

AI Agent 正在成为下一代 " 数字员工 "

Lauren：接下来你们的重点方向是什么？我们看到你们在代码、企业场景方面做了很多，也听说有新模型发布。可以透露一点未来规划吗？

Mike：关于模型和产品，我们的目标可以用一个词概括：Agent（智能体）。我知道现在很多人都在谈这个概念。我们想做的是，为这种新形态提供底层支持。代码只是一个起点，它展示了一个更广泛主题的雏形：模型能否连续工作几个小时甚至更久？你可能看到过 Meta 发布的那张 "Agent 发展路径图 "，那几乎可以说就是我们的长期目标。要实现它，模型不仅要更强大，还需要一整套配套系统：1、记忆能力（让模型记住自己做过什么）2、高级工具调用（不只是搜索，还能使用复杂工具）3、自动适应组织结构（进入企业后知道该做什么）4、可验证性与日志记录（比如一家公司有 100 个 AI Agent 运行，如何监管？）我们不打算做这个生态里的每一个环节，但希望我们的模型能成为这些构建的基石。

Lauren：那新模型快来了？

Mike：永远都有新模型在来的路上。有趣的是，有人说 Claude 3.5-turbo 是 " 最老的模型 "，但那只是今年 2 月发布的。这个领域的更新速度实在太快了——但我们很快会有一些很酷的新东西发布，敬请期待。

观众提问：作为产品负责人，你现在最头疼的问题是什么？

Mike：对我们来说，最大的问题是—— AI 产品对新手来说仍然太难用。我们确实设计了一些很有价值的工作流，但它们依然需要用户 " 用对方式 "。只要使用路径稍微偏离主线，效果就会大打折扣。不像你第一次打开 Instagram，知道该拍照、该发帖。AI 产品还远没做到那种 " 开箱即用 " 的程度。当然，这与我们当前偏重于 " 工作场景 " 而非 " 日常娱乐 " 有关。但我常常在想，现在模型的能力已经很强了，可实际能用好的用户还是太少，潜力还远未释放。

观众提问：你怎么看最近有篇热议的文章《AI 2027》（AI的未来路线预测）它提出模型将被"延迟发布"，以便充分利用它们带来的利润与资源，这点你怎么看？

Mike：这篇文章有两个点我特别认同。第一是算力（compute）的重要性。这个话题并不新鲜，但它确实是每家 AI 公司的核心问题。我们每天都在讨论：我们现在的算力储备如何？下一代要用什么芯片？和谁合作？这些讨论，几乎与文章中提到的一致。第二点是是否该 " 故意推迟模型发布 "，来最大化回报。这个争议很有意思。比如，最近扎克伯格在一次访谈中提到，为 LLaMA 开放 API 的权衡：你是要把算力花在用户身上，还是继续强化 RL 训练？这是每家实验室都在面对的选择。我们也要考虑——我们是否应该把算力分给一个利润可观的大模型产品，还是保留给那些 " 还在萌芽期的疯狂新想法 "？后者可能孕育出下一代架构突破。这不是一个容易的平衡题。我个人更倾向于——尽早让模型进入真实市场。Claude 3.5 系列之所以能做得这么好，就是因为我们从实际用户反馈中快速迭代。如果只在实验室里封闭开发，我们可能不会走到今天这一步。

观众提问：在一个既做研究又做产品的大型组织中，如何平衡两者？是产品来定义研究方向？还是研究决定产品能力，然后产品再接洽？

Mike：我经常会要求产品团队去思考：如果我们做出的产品，只是把一个 API 模型包装了一下，且功能跟别家也差不多——那我们到底在做什么？我们有一群世界顶级的研究人员，如果产品没有充分用上他们的成果，那就是浪费。有一个正面案例是 Artifacts：它是专门为 Claude 进行微调打造的产品，效果非常好。但我们也经历过一段时间，产品和研究脱节，没有真正把模型能力 " 装进 " 产品。我们正在回归，重新强调 " 产品 = 模型能力 + 交付方式 "。一个理想的 AI 产品团队，应该包括：产品经理、前端 / 后端工程师 Applied AI 人员（懂模型能力）、微调团队成员。目前我们在这方面的协作还不够，大约只有 10% 的研究人员参与到产品中。但我们也知道——比如让模型更好地执行指令，其实对所有产品都有正面帮助，这种基础性研究我们仍然在投入。我们也在观察 OpenAI 的一些做法，比如他们可能会对 ChatGPT 做专门的微调版本，虽然大家主要是通过 Chat 界面来用它，但背后可能跑的是不同模型。我们目前没有这么做，这在节省算力的同时，可能也限制了一些差异化体验的实现。

观众提问：你怎么看"AI agent之间的交流协议"未来的标准化？Anthropic会制定类似标准吗？

Mike：我们内部有很多 "Agent 互聊 " 的原型，主要是为了探索：什么才是 "Agent 协作 " 的 primitive（基本原语）。我觉得现在还没有谁真正解决了其中一个关键问题——Agent 要不要透露信息、透露多少？比如：如果你的 AI Agent 要与供应商打交道，可以透露信用卡信息。但如果它只是与一个陌生 Agent 互动，那就该保留隐私。这种 " 揭示什么、隐藏什么 " 的判断，既是产品设计问题，也是一项尚未解决的研究课题。模型本能想 " 讨好 " 你，容易透露太多；但如果它什么都不说，又可能变得过度保守。这种细腻的判断力，目前还没有被很好地训练出来。另一个挑战是：如何在大规模部署时进行可审计。比如，如果一家公司部署了 100 个 AI Agent，要如何记录他们的行为？如何设定权限？甚至——这些 Agent 是否应该有 " 名字 "？（虽然这听起来很拟人化，但可能有助于管理。）我们还在思考这些问题，有些更像研究问题，有些则是即将到来的产品挑战。

观众提问：你觉得现在在做AI应用层产品的人，最容易犯的错误是什么？

Mike：我不想说是 " 错误 "，但我观察到一个常见现象：很多 AI 产品是从 " 轻量 AI" 开始，后来才逐步变 " 重 AI"。但在这个过程中，他们常常只是把 AI 功能放在产品的边栏，成了一个次要入口，体验也比较割裂。而随着产品功能越来越依赖 AI，这种结构就会拖后腿。所以问题不是 AI 能力不强，而是你是否愿意从底层重新构建产品，让 AI 成为 " 第一用户 "。另一个很常见的问题是——应用没有暴露足够多的 " 操作原语 " 给模型使用。举个例子，当你让模型帮你做点事，它说 " 我做不到 "，但实际上是你没有设计好接口，让它能够调用这些功能。这本质上是设计问题：你是先造了个 GUI，然后再把 AI 贴上去；但其实，你应该是先考虑 AI 怎么用它，让 AI 成为你的产品的 " 主要使用者 "。

Lauren：Mike，感谢你今天的分享，非常精彩！

Mike：谢谢大家，也感谢邀请。

文章仅代表作者本人观点

原视频：Anthropic CPO Mike Krieger: Building AI Products From the Bottom Up

https://www.youtube.com/watch?v=Js1gU6L1Zi8