1. 长期来看，未来大多数内容将由 AI 生成。所以“这是不是 AI 生成的”这个问题将变得没有意义。值得关注的是内容的来源、溯源和引用等问题。而讽刺的是，AI 反而可能更有助于解决这些问题。
特工小天：最近毕业季许多同学在论文 AI 查重，然后刚好看到一句特别有意思的表示：现阶段，鉴定内容是否由 AI 创作更像是一种赛博时代的刻舟求剑。
2. 最好的 AI 产品往往不是计划出来的，而是“从底层自发生长出来”的。很多产品，只有在与模型非常靠近、并深入实验后，才会逐渐显露其真正潜力。所以改变产品开发的路径，是从以往的“自上而下”转为“自下而上”。
3. 我能用 Claude 生成初稿吗？这是不是“作弊”？但现在，我们已经开始鼓励这种用法了。当然，用 AI 写完后你要自己校对，确保内容准确、有判断。但如果它能帮你节省两小时，让你腾出时间去做更重要的事——那为什么不用？
4. 模型本能想“讨好”你，容易透露太多；但如果它什么都不说，又可能变得过度保守。这种细腻的判断力，目前还没有被很好地训练出来。
更多优质内容欢迎加入我们的 ima 知识库查看，我们正在不断的构建完善它。
AI 生成内容的未来，不是真假之辨，而是可信与共鸣
Lauren：你认为 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 已经开始被更广泛地采用。
Lauren：从一个“自下而上”的想法出发，到现在落地扩展，你们是如何培育并发展这个产品的？
Mike：我目前最关注的两个方向，都是围绕 MCP 展开的。第一是“执行能力”。MCP 最初的设计目标是引入上下文，现在我们已经可以集成 GitHub、触发 Zapier 等操作。但更重要的是下一阶段，我们希望模型能主动完成任务。它们不仅要能“理解”，还要能“行动”，自动执行工作流。
第二是“Agent 之间的协作”。我们现在还处于非常早期的探索阶段，甚至还不适合立即建立标准。但很明显，未来不同的 Agents 会相互交互、协作，甚至“雇佣”其他 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。我知道现在很多人都在谈这个概念。我们想做的是，为这种新形态提供底层支持。
代码只是一个起点，它展示了一个更广泛主题的雏形：模型能否连续工作几个小时甚至更久？那几乎可以说就是我们的长期目标。
要实现它，模型不仅要更强大，还需要一整套配套系统：1、记忆能力（让模型记住自己做过什么）2、高级工具调用（不只是搜索，还能使用复杂工具）3、自动适应组织结构（进入企业后知道该做什么）4、可验证性与日志记录（比如一家公司有 100 个 Agents 运行，如何监管？）我们不打算做这个生态里的每一个环节，但希望我们的模型能成为这些构建的基石。
Lauren：那新模型快来了？
Mike：永远都有新模型在来的路上。这个领域的更新速度实在太快了——但我们很快会有一些很酷的新东西发布，敬请期待。
观众提问环节
观众提问：作为产品负责人，你现在最头疼的问题是什么？
Mike：对我们来说，最大的问题是——AI 产品对新手来说仍然太难用。我们确实设计了一些很有价值的工作流，但它们依然需要用户“用对方式”。
只要使用路径稍微偏离主线，效果就会大打折扣。不像你第一次打开 Instagram，知道该拍照、该发帖。AI 产品还远没做到那种“开箱即用”的程度。当然，这与我们当前偏重于“工作场景”而非“日常娱乐”有关。但我常常在想，现在模型的能力已经很强了，可实际能用好的用户还是太少，潜力还远未释放。
观众提问：你怎么看最近有篇热议的文章 AI 2027（关于 AI 的未来路线预测）它提出模型将被“延迟发布”，以便充分利用它们带来的利润与资源，这点你怎么看？
Mike：这篇文章有两个点我特别认同。第一是算力的重要性。这个话题并不新鲜，但它确实是每家 AI 公司的核心问题。我们每天都在讨论：我们现在的算力储备如何？下一代要用什么芯片？和谁合作？这些讨论，几乎与文章中提到的一致。
第二点是是否该“故意推迟模型发布”，来最大化回报。这个争议很有意思。比如，最近扎克伯格在一次访谈中提到，为 LLaMA 开放 API 的权衡：你是要把算力花在用户身上，还是继续强化 RL 训练？这是每家实验室都在面对的选择。我们也要考虑——我们是否应该把算力分给一个利润可观的大模型产品，还是保留给那些“还在萌芽期的疯狂新想法”？后者可能孕育出下一代架构突破。这不是一个容易的平衡题。
我个人更倾向于——尽早让模型进入真实市场。Claude 3.5 系列之所以能做得这么好，就是因为我们从实际用户反馈中快速迭代。如果只在实验室里封闭开发，我们可能不会走到今天这一步。
观众提问：在一个既做研究又做产品的大型组织中，如何平衡两者？是产品来定义研究方向？还是研究决定产品能力，然后产品再接洽？
Mike：我经常会要求产品团队去思考：如果我们做出的产品，只是把一个 API 模型包装了一下，且功能跟别家也差不多——那我们到底在做什么？我们有一群世界顶级的研究人员，如果产品没有充分用上他们的成果，那就是浪费。
有一个正面案例是 Artifacts：它是专门为 Claude 进行微调打造的产品，效果非常好。但我们也经历过一段时间，产品和研究脱节，没有真正把模型能力“装进”产品。我们正在回归，重新强调“产品=模型能力+交付方式”。
目前我们在这方面的协作还不够，大约只有 10% 的研究人员参与到产品中。但我们也知道——比如让模型更好地执行指令，其实对所有产品都有正面帮助，这种基础性研究我们仍然在投入。我们也在观察 OpenAI 的一些做法，比如他们可能会对 ChatGPT 做专门的微调版本，虽然大家主要是通过 Chat 界面来用它，但背后可能跑的是不同模型。我们目前没有这么做，这在节省算力的同时，可能也限制了一些差异化体验的实现。
观众提问：你怎么看关于 Agent 之间的交流协议的未来的标准化？Anthropic 会制定类似标准吗？
Mike：我觉得现在还没有谁真正解决了其中一个关键问题——Agent 要不要透露信息、透露多少？比如：如果你的 Agent 要与供应商打交道，可以透露信用卡信息。但如果它只是与一个陌生 Agent 互动，那就该保留隐私。这种“揭示什么、隐藏什么”的判断，既是产品设计问题，也是一项尚未解决的研究课题。
模型本能想“讨好”你，容易透露太多；但如果它什么都不说，又可能变得过度保守。这种细腻的判断力，目前还没有被很好地训练出来。
另一个挑战是：如何在大规模部署时进行可审查。比如，如果一家公司部署了 100个 Agents，要如何记录他们的行为？如何设定权限？甚至——这些 Agents 是否应该有“名字”？我们还在思考这些问题，有些更像研究问题，有些则是即将到来的产品挑战。
观众提问：你觉得现在在做 AI 应用层产品的人，最容易犯的错误是什么？
Mike：我不想说是“错误”，但我观察到一个常见现象：很多 AI 产品是从“轻量 AI”开始，后来才逐步变“重 AI”。但在这个过程中，他们常常只是把 AI 功能放在产品的边栏，成了一个次要入口，体验也比较割裂。
而随着产品功能越来越依赖 AI，这种结构就会拖后腿。所以问题不是 AI 能力不强，而是你是否愿意从底层重新构建产品，让 AI 成为“第一用户”。
另一个很常见的问题是——应用没有暴露足够多的“操作说明”给模型使用。举个例子，当你让模型帮你做点事，它说“我做不到”，但实际上是你没有设计好接口，让它能够调用这些功能。这本质上是设计问题：你是先造了个 GUI，然后再把 AI 贴上去；但其实，你应该是先考虑 AI 怎么用它，让 AI 成为你的产品的“主要使用者”。
以上。
（文：特工宇宙）