图片来源：红杉资本
Z highlight
-
从长期看，大多数内容将由AI生成。所以“这是不是AI生成的”这个问题将变得无意义真正。值得关注的是内容的来源、溯源和引用等问题。而讽刺的是，AI反而可能更有助于解决这些问题。
-
最好的AI产品往往不是计划出来的，而是“从底层自发长出来”的。很多产品，只有在与模型非常靠近、深入实验后，才会逐渐显露其真正潜力。所以改变产品开发的路径，是从以往的“自上而下”转为“自下而上”。
-
我能用Claude生成初稿吗？这是不是“作弊”？但现在，我们已经开始鼓励这种用法了。当然，用AI写完后你要自己校对，确保内容准确、有判断。但如果它能帮你节省两小时，让你腾出时间去做更重要的事——那为什么不用？
-
模型本能想“讨好”你，容易透露太多；但如果它什么都不说，又可能变得过度保守。这种细腻的判断力，目前还没有被很好地训练出来。
Mike是Anthropic的首席产品官，曾参与创办Instagram，也在红杉资本的创始人之一，长期专注于产品从0到1的打造。他主导了Claude、MCP协议等核心产品的设计与落地。Anthropic是一家专注于安全可控人工智能的公司，致力于将前沿AI能力转化为可靠的产品体验。其代表产品Claude是面向通用场景的大语言模型，以对话自然、指令理解强和安全性高著称。
AI生成内容的未来，不是真假之辨，而是可信与共鸣
Lauren：谢谢你的到来，Mike。大家可能不知道，Mike其实是个内容迷。能和这位热衷AI创作的人一起聊聊，非常有趣。你认为AI生成内容的发展趋势是什么？无论使用何种媒介、AI参与多少，核心问题始终是：有没有一个吸引人的故事？人们是否能感受到内容背后的人，从而建立起连接？所以AI只是讲故事者工具箱中的一个工具而已。我也很好奇你们是如何看待这个问题的：当你们不断制作内容、生成图像时，你们如何帮助用户保持对内容的掌控？比如你们在模型可解释性方面做得很好，那你们如何赋予用户理解或引导Claude这类系统的能力？
Mike：是的，有些问题在短期内仍然值得探讨，比如加水印来标记AI生成内容。但从长期看，大多数内容将由AI生成。所以“这是不是AI生成的”这个问题将变得无意义真正。值得关注的是内容的来源、溯源和引用等问题。而讽刺的是，AI反而可能更有助于解决这些问题。有趣的是，这让我想起了区块链。虽然现在已经不算热门话题了，但区块链曾试图解决的一些问题，其实在整个内容生成和传播链条完全数字化的今天，更容易通过AI来实现。例如，以前我们常常关注一个文档的出处，比如有没有引用、是不是原创，这些问题现在依然重要，但在AI帮助下也变得更容易追踪。所以，未来重点不再是“这是不是AI生成的”，而是“它来自哪里”“内容是否可信”“能否验证”。
真正有价值的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优化，反而被放大了。这导致产品流程中的不协调变得更明显、更痛苦。虽然模型可以总结会议、提出下一步建议，但它们现在还做不到真正帮助我们做出组织层面的决策。
从工具到协作体：组织如何适应AI时代的效率重构
Lauren：你提到Anthropic内部在广泛使用Claude。能分享一下哪些使用方式是你觉得特别值得推广的吗？有没有一些你们过去半年内尝试、并且觉得其他人也应该尝试的用法？
Mike：我最喜欢看到的是——非技术团队开始主动使用模型。比如销售团队，会用Claude来准备客户会议。他们一开始只是用公共版本，但当碰到具体障碍时，我们就会根据他们的需求开发专属工具。这种需求驱动的方式，非常有效。不过坦率地说，即便在我们这样的AI实验室，使用AI的能力也分布不均。有的员工用得非常熟练，高效地解决问题；而有的人还停留在传统流程。我自己则把Claude当成“思维合伙人”。无论是写战略文档、制定规划，还是写绩效评语，我都习惯先通过Claude进行一轮“脑力激荡”。就像有了Copilot之后，我在飞机上没有它会觉得“不会写代码了一样”，我现在也很难回到没有AI协助的写作状态了。
过去一年半里，我亲眼看到Anthropic内部的文化发生了变化。起初，很多人在写绩效评语、工作总结时会犹豫：我能用Claude生成初稿吗？这是不是“作弊”？但现在，我们已经开始鼓励这种用法了。当然，用AI写完后你要自己校对，确保内容准确、有判断。但如果它能帮你节省两小时，让你腾出时间去做更重要的事——那为什么不用？我们有一个内部工具，可以跨越整个Slack和所有内部文档运行。它支持公共和私密频道，但大多数人更喜欢用“公开版”，因为这意味着他们使用AI的过程是可见的。有趣的是，在绩效季时，很多员工开始用这个工具来生成评语初稿——而且是在公共频道里！这种“共享式使用”反而帮助打破了“AI使用羞耻感”。这让我想起了Midjourney刚兴起的那段时间，大家都愿意公开展示自己用AI生成的图。这种“可见性”对于推动AI融入日常工作非常关键。我们还远没到AI全面普及的阶段，但可以看到，文化正在朝这个方向转变。
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
编译：Guangyuan Tang，关注具身智能及AIGC艺术美学，欢迎交流
请注意，本文编译自文末载明的原始链接，不代表Z Potentials立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。
Z Potentials将继续提供更多关于人工智能、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。
（文：Z Potentials）