2025 年智能主体将全面爆发。但实际落地中，编码领域的智能体成为核心突破点，其中 Anthropic 的 Claude Code 表现尤为突出。
根据 YC 最新数据，Anthropic 的模型份额突破 52%，正式超越长期霸主 OpenAI。2024 年到 2025 年初，Anthropic 的份额大多维持在 25%左右，但在过去 3 到 6 个月中实现了“曲棍球棒”式的陡峭增长。这种转变的核心驱动力在于 Anthropic 优秀的编写代码能力，这让它成为许多开发人员的首选工具，并渗透到其他使用场景。
近期，Anthropic 首席产品官 Mike Krieger 做客“AI Daily Brief”节目，系统梳理了“vibe coding”在未来的发展方向。
从 Claude 早期对编程能力的聚焦，到像 Claude Code 这样更广泛应用智能体的兴起，他详细拆解了软件工程师、非技术背景的创作者，以及希望从聊天机器人迈向真正 Agent 化工作流、底层基础设施以及可量化投资回报的企业团队，正在面临的问题，以及 Anthropic 为此将在明年进行的优化方向，比如重点解决“企业部署 AI 但员工未变高效”的问题等。
整个对话最大的结论是：下一次跃迁不只是模型更聪明，而在于更高的可靠性、更好的交互方式，以及能稳定、持续把工作从你手里接走的 AI。Mike 指出，短期内 AI 无法完全替代人类接手完整工作流，但“明确任务边界、AI 自主完成细分任务并反馈”的协作模式将成为主流，这也是 Anthropic 明年产品战略的核心方向。
下面是节目对话详情，我们进行了翻译并在不改变原意基础上进行了删减，以飨读者。
编程领域突围，无意还是刻意为之？
主持人：今年有一个非常明显的主题，就是“万物 Vibe Coding，万物 Agentic”。很多人现在都把 Anthropic 视为 AI 编程领域的“火炬手”。我就在想，你当初加入公司的时候，这个方向是不是已经非常明确了？还是说，是后来逐渐发现模型有很强的差异化能力、用户也开始这样使用之后，自然演化出来的？
Mike：我总跟 Anthropic 内部的产品团队说，只要产品方向尽量和公司对“强大 AI 从哪里来”的长期判断保持一致，事情推进起来就会顺畅很多。Anthropic 的特点就是极度专注，这一点从我们选择开发和放弃的产品中就能体现出来。
公司内部确实一直有这样一种理念：要打造强大的 AI，模型必须具备推理能力、能够进行 Agent 式的规划，能在很长的时间跨度内持续工作；同时还需要具备编写和运行代码的能力，这不仅是为了开发软件，更因为代码本身就是一种极其强大的问题解决工具。
这种理念在我加入之前就已经存在了。我是去年五月加入的，但在我加入前后那段时间里，正好外界也开始意识到这一点。Claude 3 是第一个真正引发这种讨论的模型，我记得当时 Twitter 上有一个很明显的时刻，大家突然意识到：哇，这个模型已经不只是写函数级别的代码了，而是可以写完整的代码文件。当然，那时候它还谈不上“写得很好”，但已经非常惊人了。
随后，我们把模型能力和第一个更偏向编程体验的产品结合起来，也就是 Artifacts。你可以让 Claude 在聊天旁边直接生成代码，当时大多是 React 网站。这对很多人来说，是第一次意识到：原来可以“和模型一起写代码”，而且不一定非要在传统开发环境里。
给大模型“松绑”
主持人：某种程度上，几乎可以用 Anthropic 的几次关键发布，来标记人们对 AI 编程可行性的认知变化。我第一次做这个播客在 2023 年 4 月，那时 Agentic Coding 就已经是大家最兴奋的话题了，有像 GPT Engineer 这样的项目，后来差不多一年多以后演化成 Lovable。2025 年，大家都会说：这是 Agent 的一年。而回过头看确实如此，但更准确地说，是“编程 Agent”的一年。结合你们当时的内部沟通和看到的模型能力，你们在年初是否就预判到这一应用场景会成为主流，实现突破性发展？
Mike：这确实是一个很适合反思的时间点。去年年底那几周，我们内部其实已经做了一个叫 Claude CLI 的东西，后来对外发布时改名为 Claude Code。这个项目最早来自我们的 Labs 团队，那个团队主要做的是那种从零到一、带点“不太确定会不会成功”的探索，比如早期的电脑操作实验、一些很疯狂的想法，以及这个 CLI 工具。
从当年 9 月首个版本内部上线到 12 月，它迅速取代了公司内部所有其他编码工具。核心原因在于我们的一个判断：模型的能力会不断提升，或许当前版本还做不到，但后续版本一定可以。所以我们决定让模型有更长的运行和发挥空间，允许它在更长的时间内自主运作。
所以到了假期，我们就面临一个问题：要不要推出这款工具？要不要在 Claude AI 和 API 之外，再增加第三个产品线？这是当时我们重点讨论的话题。
但我们坚信，就算我们不推出，也会有其他使用我们模型的团队发现这一方向：我们不必再过度约束模型，而是可以让它应对更模糊的任务定义，在更长的时间周期内运作。当然，当时的模型仍需要大量人工辅助，但我们已经能看到它的发展雏形。所以在年初，我们就预判到这会是人们开发软件方式的重大转变。
主持人：你有非常深的产品经验，现在对产品经理、创业者来说，最大的挑战之一是如果你想成功，就不能只是嘴上说“要去冰球将要到达的位置”，而是真的要为尚不存在的能力去设计产品。这件事非常非常难。听你描述，Claude Code 的诞生，本身就像是在试探、在“挠这个痒点”。
Mike：是的。我们在 Anthropic 内部有一条产品原则，叫做“为指数增长而设计”，意思是我们开发的产品既要贴合当下需求（至少能解决当下的部分痛点，对于过于超前的产品我们会暂时不发布），又要具备自然迭代升级的潜力。
这一点在 Claude Code 上体现得很明显：随着模型能力提升，我们反而删除了部分工具框架，而不是一味地往里加，因为模型本身能做的事越来越多了。
另外，我们与很多使用我们模型的下游客户合作时发现，有时我们推出新的研究模型，初看提升并不明显，但当我们的应用 AI 团队深入对接客户后，他们会发现问题不在模型，而是现在的工具框架过于僵化。这时反而需要放松约束，让模型多做一点。
这也是我们与平台开发者持续沟通的话题。虽然他们能通过早期访问项目等渠道了解我们的发展方向，但仍需要做大量类似的适配工作：“如果当前模型需要这么多额外框架支撑，那么当模型能力提升、所需框架减少时，我的产品是否依然有用？能否为用户创造价值？模型是否会取代我原本的价值定位？”
主持人：Claude Code 推出后，用户的使用方式有没有让你感到意外？因为它的受众范围似乎远超核心软件工程师群体。
Mike：绝对有。我们最早只是把内部用的东西整理、包装了下就对外发布了，但内部的使用场景其实一直在继续演化。
我们每年会举办两到三次黑客马拉松，有趣的是，每次黑客马拉松都恰逢某项技术即将爆发的节点：第一次围绕 MCP 展开，当时所有项目都基于 MCP，而外界还未广泛关注这一技术；第二次举办时， Claude Code 刚发布不久，最让我们惊喜的是，很多项目并非编码相关，而是将 Claude Code 作为底层引擎。比如有项目用它处理生物信息学问题，后来我们在此基础上开发了面向生命科学领域的 Claude 产品；还有项目将它打造成“一站式 SRE 工具”，处理数据源；还有人用它辅助数据科学工作。
这很好的一点在于，他们不需要重复造工具轮子，只需要在上面叠加价值。等产品发布之后，我们在外部也看到类似趋势：有人把 Claude Code 当项目经理用、当数据科学家用。这也是我们最终将底层 SDK 更名为 Claude Agent SDK 的原因，因为我们发现 Claude Code 的实际应用场景已经远超“编码工具”的定位，“Code”这个词已经不足以覆盖真实发生的事情了。
“不用它真正做点东西，很难感受到跃迁”
主持人：这也是我接下来一年、甚至未来几年里最感兴趣的问题之一：我们到底需要什么，才能让人真正“重塑习惯”，去适应这套全新的工具体系？这几乎是一整套新的语言、新的基础设施，很多人以前根本没接触过，尤其是那些本身不是开发者的人。你觉得现在我们看到的这些，比如用 Claude Code 做一些非编程场景的事情，更多只是“偏技术的爱折腾的人”在尝鲜？还是说，这其实预示着一种完全不同的人机交互方式，未来会越来越普遍？
Mike：我觉得现在还处于早期阶段。即便在那些部署了企业级 Claude 产品的公司里，销售团队、广告团队等非技术团队中，总会有一类“探索型构建者”，他们不是工程师，甚至没有工程背景，但通过学习基础原理，就能与 Claude 高效协作解决问题，比如自动化部分工作流程、优化现有工作、提升团队效率等。但目前这类应用仍依赖这类“关键人物”，我认为这是软件生命周期的自然阶段。
我认为当前仍存在两大差距：一是交互界面层面，如何让人们自然地与这些工具交互，如何让产品充分展现自身能力；二是模型能力层面，如果把模型比作一位富有创造力的人类同事，你交给它一个高阶任务，它大多时候能完成，但有时会犯一些你意想不到的错误（哪怕上周还完美完成过同类任务），那你跟这个同事的关系肯定也会挺复杂的。
我们目前仍处于这个阶段：一方面是人们对这些系统的理解还不够深入；另一方面是模型的可靠性和可预测性有待提升。它们什么时候能变成那种“能力持续、稳定提升”的工具，而不是让人又爱又怕，这个阶段还没完全过去。
主持人：人们需要时间摆脱过去数年甚至数十年形成的工作习惯。比如“vibe coding”这个词，也才大概十个月时间，差不多就是今年 2 月，Claude Code 发布的那个月。可就算是我这种天天聊这个、天天泡在这些工具里的人，最近也才开始真正形成一种条件反射：“这件事我是不是可以直接做个东西解决？而不是再用 Google Sheet 或者用以前那套老方法？”连我这样深度沉浸在这个领域的人都需要适应，更不用说其他人了。
Mike：我觉得用熟悉的工具完成一次构建后，再进行增量创新就会容易很多，最难的是迈出第一步。
周末我在用 Opus 做一个项目，之后需要给家人组织“秘密圣诞老人”活动。正因为我当时一直在用这些工具，所以早餐煮鸡蛋的时候，我就发起了一个异步请求，等我早餐做好，整个活动方案就已经生成好了。
这真的很神奇。但如果我当时没有一直在用这些工具，肯定不会第一时间想到用它来解决这个问题。所以我认为，当前我们仍需要帮助用户培养使用习惯，让他们知道“这些问题可以用 AI 工具解决”。
主持人：完全同意。我听过一个类似的例子：有人用这些工具做了一个礼物追踪器。我特别有共鸣，因为我们每年平安夜都会把礼物塞进壁橱，就因为买得太多记不清了。于是我也模仿着做了一个，这大概是我在最近一波模型发布后，一个月内第一次用工具构建应用。没想到短短三四天内，我就顺理成章地构建了六、七个不同的应用。
Mike：还有一个挺有意思的现象是，无论是我们自己发布的模型还是别家的，很多主要通过“聊天”来体验模型的人，反馈往往是：“嗯，好像更聪明了一点。”“感觉语气更温柔了。”这些其实都属于感觉层面的评价。但如果你不亲自下场，用它真正去做点东西，是很难感受到跃迁的。
周末我用 Opus 深度开发了两天项目，真切感受到有些应用在之前的版本中，哪怕是 Claude 4.5，根本无法实现，要么撞墙、要么卡死。而现在的模型遇到问题会自行调试、查看日志、添加调试日志、重新运行，甚至会打开浏览器验证结果，这些能力要么是与模型协同开发的，要么是随着模型升级而优化的，但你必须深入使用才能感受到这种差异。
所以有时候，外界会有一种“是不是到瓶颈了”的疲劳感。但如果你把时间轴拉长、真正 checkpoint 一下，会发现其实持续进步是非常明显的。
面向不同人群的提升方向
主持人：这正好可以让我们把“AI 编码”或“氛围编程”的话题拆分成几个方向：一是资深软件工程师关注的“AI 编码的意义”“智能体自主性程度”“模型能力边界”等深度话题，今年已经经历了“快速普及到梳理挑战”的完整周期，新技术不会解决所有问题，只是用一套新问题替代旧问题，而我们仍需要解决这些新问题；二是个人非技术用户的工具使用，这一领域还处于非常早期的阶段，我们才刚刚触及表面；三是企业级应用，这既包括软件工程领域的组织变革，也包括企业将这些工具应用于非软件开发的其他业务场景。你认为这三者是同一话题的不同延伸，还是三个独立的话题，只是恰好使用了相同的术语？
Mike：你说得非常准，哪怕底层模型是同一个，哪怕使用的是同一套 SDK 积木，不同场景最终呈现出来的应用形态，差异其实非常大。
首先是软件开发领域，开发者群体本身就很爱折腾，喜欢优化自己的工具链。Emacs 还是 Vim、Tab 还是 Space，这种事能吵二十年。这一点在其他领域可能不那么明显，而且其他领域更换工具也没那么容易。所以该领域的发展形成了一种良性循环：工程师们能清晰地反馈模型需要改进的方向，我们也能从这些反馈里快速对齐研究方向。
但中间这一层，我觉得仍然存在一个“复杂度天花板”。确实已经出现了一些非常惊艳的、从零用 vibe coding 做出来的产品，甚至已经上线了，但我明显感受到一个问题。比如我太太是产品经理 / UX 设计师出身，没有工程背景。我们一起做副业项目时，她用大模型的方式其实是在不断往上下文窗口里塞内容。我就会告诉她：这里其实应该引入语义检索，做 embedding 层。但 Opus 不会主动建议这个方向，她也不知道该用什么术语描述需求，这就需要有人指导。
所以我认为，对于中间层面（帮助非技术人员构建有效软件），所有顶尖模型都需要在“帮助用户逐步提升应用复杂度”上做得更好：氛围编码构建前端 demo 展示想法很棒，但如果需要存储数据，就需要下一步指导；如果要上线应用，就需要进行安全审查；如果应用负载过高，就需要具备性能优化能力。这和 Instagram 的发展历程很像：先做 UI，再开发后端，上线后因流量激增崩溃，然后在接下来的数周数月内重构优化。区别只是：现在你可以在模型辅助下“加速跑完”这条路。
最后是企业软件领域。你之前报道过 MIT 的一份报告，其中提到 AI 落地后“预期和现实之间存在巨大落差”，非常真实。那份报告也许方法上有问题，但它确实指出了一个普遍现象：“公司给我部署了 AI 工具，但我没觉得效率提升了。”
要缩小这一差距，需要从几个方面入手：输出质量必须足够高，高到真的帮用户节省了时间。如果结果是“半成品”，那很多人会觉得我还不如自己来，反而更快。所以，我们最近的重点不是强化智能主体的自主完成能力（比如用两句话描述就让 AI 生成完整 PPT），而是更注重“前期多一点投入，确保初始输出质量足够高”，让用户感受到“AI 确实帮我省了时间”，而不是“用了 AI 反而增加了工作量”。
2026 年愿景：可靠地接过你手里的活儿
主持人：展望 2026 年，您认为企业今年会从哪里开始，特别是相比于 2025 年初，您觉得企业的核心目标是什么？无论是在模型设计还是产品设计方面。
Mike：我觉得现在和一年前相比，有两件事明显不同。第一，企业越来越关注我们所说的“横向智能体”的落地。也就是“伴侣智能体”或“协作型助手智能体”，强调人机协同，共同创建文档、邮件等内容。
同时，越来越多企业开始关注“重复性后台任务”的 AI 赋能：比如如何通过 AI 扩大国际客户身份验证（KYC）等复杂但可重复流程的处理规模，这些流程既包含企业定制化需求，又涉及监管要求。我们发现这一领域的需求正在快速增长，也派出了应用 AI 团队和工程师深入企业，帮助他们部署这类智能主体。核心工作是将企业需求转化为具体流程，确保模型在保持创造力和灵活性的同时，能够稳定遵循企业的操作规范。这点与一年前截然不同，当时我们几乎没有进行过这样的讨论。
第二点，我觉得，企业开始超越“AI 功能点缀”的 1.0 阶段，转向思考“是否需要重构产品核心模块，让它更加 AI 原生。但“是否让 AI 充分发挥了产品的全部潜力”这一转型，比“在产品侧边栏添加 AI 聊天功能”，要难得多。
主持人：回顾今年的预期与实际发展，25 年虽被认为是“Agent 之年”，但实际发展与预期略有不同。一方面，那是“编程型 Agent 之年”；另一方面，也是“Agent 基础设施之年”，比如 MCP 变得普及。最近我在录制节目前讨论了 OpenAI 开始使用 Skill。很明显，现在大家更关注搭建必要基础设施，以便未来能更快推进，而不是陷入过去的标准之争。我觉得 2026 年企业可能会迎来一个“基础设施年”，在这个过程中，需要对流程进行全面复盘，而不仅仅是简单地部署聊天机器人或试点 AI 功能。
Mike：完全同意。我曾和一家大型银行的技术负责人交流，他说他们不仅需要重新规划数据存储（这部分工作他们已经做了很多），还需要优化数据标注和数据谱系管理，使其更适配 AI。这样，当你让 Claude 帮你构建仪表盘或分析数据查询时，额外的标注层就能让模型理解不同表格及其含义，从而真正让产品有用。因此，“填补这些连接缺口”将会是 2026 年的重要工作，非常关键。
我们有 MCP，也看到越来越多企业将内部服务或数据存储接入 MCP，以便在 Claude 等平台中访问。下一步是从“检索”转向“行动”：如何让 AI 成为业务流程中有价值的参与者？比如让 AI 辅助人类做决策，或整理决策建议供人类确认。通过这种“人机协同”模式，提升 AI 的价值，使其匹配行业对它的期待。
主持人：您对 2026 年 AI 与 2025 年不同之处有什么预测？刚才谈到企业用例扩展，您认为企业面临的最大障碍是什么？他们会如何克服？
Mike：我们接触的很多创新企业都面临一个差距：理想状态下，“如果在单一云环境中部署，权限设置完美，推理方式符合预期，那么明天就能解锁相关应用场景”；但现实是，企业存在遗留系统，且出于监管要求，可能只能在特定环境（比如 AWS 的特定配置）中运行。
所以我们明年的核心工作方向是“分布式部署能力”，虽然这不是一个标准词汇，但我们想表达的核心是：要将我们的智能能力、智能主体基础模块（Skill、Agent SDK、存储、记忆功能等）嵌入到企业现有工作负载中，并适配他们的约束条件。
我们正在做更多“组件化”工作，让这些能力在企业的各个环境中都能使用。目前我们已经覆盖了三大主流云平台，接下来的核心项目就是填补这些细节缺口。很多前瞻性的 CTO 和 CIO 都有相关需求，但他们必须在现有约束条件下推进；试点项目可以用简单粗糙的方式验证可行性，但要实现规模化生产部署，这才是最大的障碍。
主持人：“工具”还是“同事”？这是我们讨论已久的话题。我觉得这可能是一个伪二元对立，因为 AI 成熟后的形态或许既非单纯的工具，也非传统意义上的同事。但你认为明年我们会看到更多“将 AI 视为能承担更大工作量的伙伴”的场景吗？这种转变会成为现实吗？
Mike：会的。我认为这将是明年最核心的趋势，编码领域已经出现了这样的迹象。我们与相关平台合作推出了功能：在拉取请求中标记 Claude，你去喝杯咖啡回来，它就已经完成了你需要的工作。我们在 Claude Code 中也集成了类似功能，这预示着未来的交互模式。
当然，现在的 AI 还无法做到“加入一个组织，理解业务领域、人际关系，然后自主接手工作”，这在短期内还无法实现，或许到明年年底才会出现初步迹象。但更接近“工作分工”的场景已经近在眼前，比如准备报告、整理信息、提供参考等类似“委派任务给他人”的交互模式，已经非常接近实现了。
这也是我们明年产品战略的核心思考方向：如何实现这种交互模式？需要创建哪些接口？如何将软件领域的成功经验应用到知识工作中？
主持人：如果给 AI 贴一个 2026 年的愿景标签，你会说什么？
Mike：能可靠地接过你手里的活儿。
原文链接：
https://www.youtube.com/watch?v=VSLEGpCemtE
