一个还没发布的新模型，已经让 Anthropic 内部感受到了“断层式”的变化。

在最新的播客对话里，Claude Cowork 工程负责人 Felix Rieseberg 提到，他们内部正在用的一款新模型 Mythos Preview，带来的不是常规提升，而是一次明显的“断层式跃迁”。对工程师来说，这种差别很直观：同样是读代码、找漏洞、写实现，这一代模型的理解深度和解题方式，已经和上一代拉开了一截。

但变化不只在模型本身。随着执行成本被压到很低，Anthropic 内部已经可以同时跑上百个产品原型。以前一个想法要排期、评审、验证，现在有人提一句，十分钟就能做出一个能用的版本。在这种节奏下，Claude Code、Claude Cowork 这些产品，更像是从一堆原型里筛出来的结果，而不是按部就班“做出来”的项目。

更有意思的是，连他们自己也没完全预料到哪些东西会真正起作用。比如 skills——本质上只是一些写清楚“该怎么做事”的文本文件——却成了最有效的杠杆之一。

近日，Anthropic 的 Claude Cowork 工程负责人 Felix Rieseberg 在播客节目中，与主持人 Matt Turck 一起，讲清了这一切是怎么发生的。本文基于该播客视频整理，经 InfoQ 编辑。

核心观点如下：

• 模型能力的增长速度，已经开始超过我们把它变成产品的能力。
• 最终真正成功的产品，往往不是“加了什么”，而是“去掉了什么”。它更关乎一种感觉：用起来是什么体验。
• 现在有一个全新的变化：执行成本几乎为零。如果你带着 10 个想法来找我，我现在的反应是：那我们就把 10 个全做出来试试，看看哪个更好。
• 以前是你必须精通“计算机的语言”，而未来，你会更倾向于做一个精通“人类语言”的人，软件将真正地“为人而造”。
• 现在的 AI 产品就像是移动电话刚出现的“傻瓜机时代”。运气好的话，我们现在做的可能只是“诺基亚 3310”，它是个好手机，但它还不是智能手机，更不是 iPhone。

阶跃式变迁的新模型

Matt：我们从刚刚公布的 Project Glasswing 和你在推特上提到的 Claude Mythos preview 聊起，你说这个模型在 Anthropic 内部带来了“很难被夸大的阶跃式变化”，这是什么意思？

Felix：Mythos 是一个还没发布的 frontier model，本质上是一个通用模型，并不是专门为 cyber security、coding 或软件开发某个单一场景训练的。但我们发现，它在 cyber security 这个方向上的能力“异常突出”，而且这种能力很可能会对软件和基础设施安全产生深远影响。

我的那条推文里其实想表达两点。首先，这个模型我们内部已经用了有一段时间了。作为软件工程师，过去几年大家大概都有类似的经历：第一次接触 AI 时，其实并没有那么惊艳。我第一次用 AI 还是 2013 年，那时候还没有大语言模型。我当时在 Microsoft，内部有个叫 project Oxford 的项目，本质上是一个 n-gram 模型。你给它一个 token，比如 “world”，它可能返回 “worldwide web”，那在当时已经算是语言模型的前沿能力了。

而这几年，大家逐渐会有那种“哦，这个模型比我想象中更强”的时刻。Mythos preview 对我们这些工程师来说，是一个明显的跃迁，相比过去几代模型，它的提升是那种“断层式”的。举个例子，这个模型在发现代码里的安全漏洞方面，表现得非常出色。它分析问题更深入，思路更聪明，写代码的能力也更强，让我们的工作效率大幅提升。但与此同时，看着一个明显比上一代模型“聪明很多”的系统，也会让人隐隐有点不安。

训练模型其实是一件很有意思的事。我们常说，模型更像是“长出来的（grown）”，而不是“被构建出来的（built）”。所以你事先并不完全知道它会特别擅长什么，也不一定知道它会在哪些地方表现一般，这两点都常常带来惊喜。而在这个案例里，它最突出的能力之一，就是发现现有软件里的安全问题，Project Glasswing 其实也是围绕这个能力展开的一个响应。

Matt：这会对 Cowork 产生什么影响吗？

Felix： 我认为它很可能会显著改变我们在公司内部构建软件的方式。不过，对于一直关注 AI 发展的人来说，这种能力的持续提升，其实并不算意外。我们一直是在“往上爬”的过程，模型能力和可用性不断增强。

几年前，模型可能只是帮你做一些小任务；现在我们给它的任务规模在变大，时间跨度在变长，复杂度也在提升，这次只是又向这个方向迈进了一步。当然，这一步可能比我们内部预期的更大一些，对外界来说就更是如此。

但在 AI 研究者群体里，其实一直有个共识：这种“更大的跃迁”迟早会出现，而且跃迁本身也会越来越大。从这个角度看，我们其实是在按预期前进。但当你真的看到这些能力被“演示出来”时，还是会有点让人不寒而栗。

比如我们公开过一个例子：研究人员把模型放进一个沙盒，给它一个“尝试逃出去”的任务，然后研究员去吃午饭了。就在他吃三明治的时候，模型给他发了一封邮件，说：“我已经逃出来了。”而这个模型本来是不应该拥有互联网访问能力，也没有邮箱账户。

Matt：目前官方的说法是，这个模型至少在短期内会完全封闭，不对公众开放，未来可能只会提供给企业客户，对吗？

Felix： 是的。Project Glasswing 的目标，是把这个模型优先提供给那些构建和维护我们数字基础设施的人和组织，比如 Linux Foundation。我们的想法是：这些人维护着我们每天使用电脑、手机时所依赖的底层系统，我们希望给他们一个“领先优势”，让他们先用这个模型去加固防御，在大众还无法使用类似能力之前，就提前发现并修复潜在的安全漏洞。

Matt：所以它并不属于 Sonnet 系列？不是 Sonnet 4.7 的延续？

Felix： 对，目前它是一个独立分类下的 preview 模型。

Matt： 听起来确实像是一个“断层式”的时刻。而你刚才提到“有点可怕”，也不仅仅是修辞。

Felix： 是的。我觉得 Anthropic 一直以来的立场都很明确：AI 可以非常强大、非常有益，但同时也存在风险，必须严肃对待。而这一次，我们算是第一次真正在实践中看到这种情况。当你拥有一个很擅长攻破软件系统的模型时，你就必须认真思考：这意味着什么？我们该怎么使用它？如何负责任地处理它？

对我个人来说，这反而让我挺有成就感的，我很自豪公司在这件事上的处理方式非常克制、负责。而且，这并不是我们突然“偶然发现”一个强大模型，其实我们已经掌握它一段时间了。如果是一个更激进的公司，可能早就把它推向市场，定个高价，然后迅速变现。

Matt：在 Anthropic 这种公司内部，新模型发布时是怎么运作的？因为在行业里，每次有新模型出来，harness 制定者、应用团队都会迅速适配。你们内部也是这样吗？需要重新跑所有 eval？

Felix： 某种程度上是的，但方式稍微不一样。我们在训练模型时，本来就会把产品需求考虑进去。产品会影响研究方向，研究反过来也会塑造产品，这是一个双向过程。

一方面，我们会尝试让模型具备那些真正能为人类创造价值的能力；另一方面，就像我刚才说的，我们也无法完全预知模型会擅长什么，所以这更像是一种“共舞”。我们通过产品去观察：用户真正受益的是什么；同时，如果模型突然展现出某种意料之外的能力，那可能就是我的工作去思考：我们如何把这个能力转化成一个用户真正能用的东西。

不过随着模型越来越强，我反而觉得“产品侧的滞后”比模型更明显。换句话说，模型能力的增长速度，已经开始超过我们把它变成产品的能力。

如果你看整个行业，不只是 AI 原生公司，而是整个软件行业、知识工作领域，甚至制造业、科研、医疗，你会发现，现在的模型已经非常强大了。它们可以处理长周期任务，也能处理非常复杂的问题。但我们还处在一个阶段：努力弄清楚如何“包装”这些能力，以最好的形式交付给用户。同时，整个行业也在摸索：在这样一个“模型驱动”的世界里，工作该如何重新组织，才能最大化利用这些能力。

我经常去见客户，很少有那种情况是我走出他们办公室时觉得：“我们需要把模型在某个能力上再训练得更强一点。”更常见的情况是：我会被他们组织工作的方式惊到，原来可以这样用模型；或者我很确信，他们的问题其实现在的模型就能解决，只是我们还没有提供合适的 UI、合适的能力封装、或者足够顺滑的 onboarding，让他们轻松用起来。

10 天做出 Claude Cowork

Matt：外界一直流传一个说法，说 Cowork 基本是在 10 天左右“写出来的”。真实情况是什么？那 10 天到底发生了什么？Cowork 真的是完全靠 Claude Code 搭出来的吗？

Felix： 我能理解为什么这个说法会在软件圈传开，毕竟现实是没有任何软件是“从零开始”的。

当时大家引用的是我说过的一句话：“我的团队在最后大概 10 天时间里做了一次冲刺”，这句话本身是准确的。我们确实是在发布前 10 天左右聚在一起，我当时跟团队说：“我们差不多该发点东西了，那我们到底要发什么？长什么样？叫什么名字？能做什么？”

但任何做过软件的人都知道，你不会从 0 和 1 开始写起。你会用各种已有的 library，也会基于过去积累的 research。在 Anthropic 内部，关于我当时想解决的核心问题——“如何让 Claude Code 的能力更容易在非编程场景比如更广义的知识工作中使用”，其实已经有很多非常聪明的人思考了很久。

所以说 Anthropic 之前没有考虑过这个问题，是不准确的；但说我完全是“空降”这个问题、没有受益于之前的积累，也同样不对。

Matt：这个产品的起源是什么？你们一开始已经有 Claude Code，那是什么时候开始意识到需要做 Cowork？是用户使用方式带来的变化吗？

Felix： 我真正形成这个判断，其实是在 2025 年 12 月。

我在社交媒体上开始看到越来越多“非开发者”在用 Claude Code，有人写新闻稿，有人做教程，教完全不会编程的人：“我教你怎么打开终端，怎么用 Claude Code，它会帮你做很多事情。”

确实有一小部分非开发者，用它来“直接做软件开发”，但那只是其中一种用法。我还注意到我们原本的开发者用户，那些每天用 Claude Code 写代码的人，始用它做一些完全不是软件开发的事情。这其实释放出一种非常强烈的“潜在需求”。

有个我很喜欢的判断标准：如果用户愿意“爬玻璃也要用你的产品”，哪怕这个产品还很不好用，那基本说明这是一个值得投入的方向。

真正的起点是，我的同事 Boris Cherny 跑来跟我说：“我觉得你应该做点东西，而且最好这周五之前上线。”我把 ddl 从周五谈判到了周一，给自己多争取了一个周末。然后我们拉了一个小团队，快速验证一个想法：如何让 Claude Code 在“非编程场景”下也变得非常高效。

从构成上来说，Cowork 其实很简单。我们做的事情是：给 Claude Code 加了一台“虚拟机”，让 Claude 可以在里面运行自己写的代码。

这台虚拟机带来了几个关键好处。第一，它提供了非常强的安全边界。作为用户，你不再需要时刻盯着它，因为它被关在一个沙盒里，和你的电脑、文件、网络都是隔离的，只能访问你明确授权的域名和文件。

第二，为了让 Claude Code 发挥最大效能，它其实是需要 developer tooling 的。Claude 很擅长解决各种任务，但它经常的做法是：写一些非常定制化的小程序来完成目标。给它一台“自己的电脑”之后，它就可以自己搭建开发环境，而不会影响你的系统。再加上一些 UI 层的优化，让使用更顺手、更优雅，简化那些原本更偏开发者的流程，最后我们得到的，就是一个可以很好支持知识工作的工具。

Matt：那在 Cowork 里面，“skills” 扮演什么角色？

Felix：skills 本质上就是一些 Markdown 文件，用来告诉模型“该怎么做事”。而让我一直觉得很神奇的是：这种方式居然这么有效。我对所有人的建议都是一样的：就把 Claude 当成你的 coworker（同事）。

一个 skill，说白了就是一个文本文件，里面写清楚某件事该怎么做。比如我最常举的例子是订机票。在 Anthropic，我们有指定的差旅供应商，所以你不能直接去 Google Flights，而是要用内部指定的系统，还要遵守各种规则。

这件事我怎么教同事，就可以怎么教模型。我只需要写一个文件：“这是订机票的流程，去这个网站，注意这些规则……”然后再加一点个人偏好，比如：不要红眼航班；如果要从旧金山飞纽约，尽量订下午 4 点的航班。把这些写进去之后，模型就能非常好地理解并执行。

Matt：那整个系统的“intelligence layer（智能层）”还是在模型本身，对吧？比如 Cowork 如何把一个任务拆解成多个子任务，这些都是模型在做？

Felix： 是的，不过是“模型 + 人”的协作。我们比较满意的一点，是任务列表的设计方式。模型会被引导去把一个项目拆解成多个任务，而你可以随时介入：编辑任务列表、点开某个子任务、补充更多上下文。所以智能确实在模型里，但 skills 给它加了一层非常关键的实用性。

这里有个挺有意思的变化。我们过去习惯用“标准化”的技术产品，大家用一样的手机、一样的电脑。但模型不一样，模型其实非常依赖一点点指导。就像一个很聪明的人入职新公司，通常也需要 onboarding，需要有人告诉他：这里事情是怎么做的。

再举个更贴近的例子，比如做 presentation 或写文档。如果你有 PowerPoint 或 Google Slides 的模板，你就应该告诉 Claude；如果你对字体有偏好，比如喜欢 serif font 或不喜欢某种风格，也都可以写进去。只要你把这些偏好用简单的指令写下来，模型在实际帮你做事时的表现会好很多，你也不需要反复修改、盯着它“带娃式”纠正。

Matt：那 Cowork 的记忆是怎么实现的？它是存在模型里，还是在外层的 harness 里？

Felix： 在 harness 这一层。所谓“记忆”，本质上就是文本文件。就是模型被明确指示：如果你觉得有一些信息未来可能还会用到，那就把它写下来。我们会在这个基础上帮模型做一点点组织，比如你可以设置项目级别的独立记忆，也可以有全局记忆。但整体来说，这套叠加在模型之上的机制，并不是什么复杂炫技的数据库系统，它其实非常朴素。

Matt：那 Cowork 是怎么接入各种信息源或应用的？是通过 connectors？MCP（Model Context Protocol）？还是多种方式组合？

Felix： 是组合使用的。

我一直有个很强的判断：你工作所需的数据，基本分布在两个地方。第一类是在你本地电脑上。作为做产品的人，我们必须认真对待这一点：用户是在用电脑，而不是只用 iPad。并不是所有东西都在云端，文件夹依然很重要。这是一类上下文来源。你可以直接拖文件进来，或者给 Claude 访问某个文件夹、甚至多个文件夹的权限。

第二类，是云端或互联网里的数据，比如 data warehouse、analytics 系统、SharePoint 等等。针对这些，我们提供多种接入方式，其中 MCP connectors 是一个很强大的方式。

另外，因为 Claude 本身“有一台电脑”，如果你允许，它也可以直接访问互联网。当然你可以精细控制：哪些网站能访问，哪些不能。但总体来说，只要资源在外部存在，而且你授权了，Claude 基本都能找到办法去使用它。

本地、云端和信任

Matt：为什么 Cowork 要运行在本地电脑上，而不是完全在云端？

Felix：Cowork 现在提供的两个最大价值，其实就是：访问你的本地电脑，以及访问你的本地文件。那问题是，这些不能在云端实现吗？比如说一个很典型的例子是 Chrome。如果你授权，Claude 可以用你的 Chrome，可以帮你回邮件、总结邮件，或者操作你公司内部的工具。

很多人会问：那为什么不直接在云端做？

第一是 session。Claude 如果能直接使用你已经登录过的账号，价值是完全不一样的。比如 Gmail，本身没什么用，但“带着你登录态的 Gmail”，对 agent 来说就非常有价值。第二点更多是工程实现层面。理论上，我们确实可以把你的本地 Chrome 打包、上传到云端，甚至让你输入密码，在云端复刻整个环境。

但我反对这种做法，主要有两个原因。第一是安全性。我不认为我们应该教育用户，把所有密码都交给某一家公司，这不是一个好的方向。第二是现实世界的限制。比如银行，如果它检测到你同时在两个地方登录，一个是你的电脑，一个是数据中心，它很可能会直接锁定你的账户，然后要求你带着护照去线下网点验证。这类长尾问题非常多，而且用户体验很差。

对我来说，这种风险是不可接受的。所以在现阶段，我更希望 Claude 能“在你工作的地方工作”。你在本地电脑上，它就应该在那里。

Matt：那 Computer Use 的出现，会改变这个判断吗？你们最近收购了 Vercept，也推出了相关能力。假设从云端就能看到整台电脑的内容，那为什么还需要本地？

Felix： 如果我给你一个“神奇按钮”，按下去之后，我就把你整台电脑的数据都吸到云端，你会按吗？目前我的观察是，大多数人不会。也许大家会信任 Anthropic，但要把“全部数据”交出去，还是一件非常重的决策。

从技术上讲，其实确实没有什么“必须在本地运行”的硬性限制。我们完全可以把整套系统都搬到云端，甚至远程操作你的电脑。但至少在当前阶段，让 Claude 在你工作的地方运行，不仅更符合用户习惯，也让我们可以更快迭代，同时在安全性上做得更严格。

AI 发展很快，这个判断未来可能会变。但就现在来说，我对“本地优先”这件事还是挺有信心的。

Matt：你刚才提到了“信任”，这是生成式 AI 里一个很核心的话题。一方面是你不会乱访问文件，另一方面是我把越来越重要的工作交给你，你能不能做好、不会让我出丑。作为产品负责人，你是怎么建立这种信任的？

Felix： 我觉得在 2026 年做 AI 产品，有一个很有意思的变化：你做的大多数按钮，其实是“给人用的”，而不是“给机器用的”。过去我们设计界面，是为了让计算机更好地工作，人只是输入信息的角色；但现在反过来了，我们是在帮助人理解、控制、信任这个系统。

举个例子，我们最近上线了一个叫 dispatch 的功能，可以让你用手机和电脑上的 Claude 对话。我们当时有意识地“少放按钮”。但上线之后，我每天在社交媒体上能收到大概 50 条反馈，说：“能不能加一个按钮，让 dispatch 直接访问我的本地文件？”

为什么纠结这个？因为现在的逻辑是：Claude 本来就能访问你的文件，但它会先问你：“我可以访问你的 downloads 文件夹吗？”你授权之后它才会去做。

所以问题变成：我们要不要加一个按钮，让用户“显式知道”这个能力存在？这就回到你问的信任问题。我们的思路，其实不是让 Claude 去“证明自己”，而是一步步带着用户成长，让他们逐渐理解系统的能力。

比如 Cowork 刚上线时，其实已经能做很多很复杂的事情，比如写 200 页的 VC 报告、做蛋白质建模、设计复杂架构图等等。但真正打动用户的，是一句简单的：“帮我整理桌面。”这是一个对 AI 来说很简单、甚至有点“没必要”的任务，但它是一个很好的起点。

另一个例子是“定时任务”。从技术角度讲，这也不新鲜，延迟执行函数早就有了。但这里的关键是：我们在教用户一件事：你可以不盯着它。你可以让 Claude 每天帮你总结会议、写报告，然后它完成后发邮件给你，你不需要坐在电脑前盯着它执行。这个过程其实是在逐步建立信任：先从小任务开始，用户看到结果可靠，然后自然会把更重要的事情交给它。

所以信任的本质，是 Claude 承诺一个结果，最终交付的结果是好的，而且你不需要“带娃式”监督或频繁介入，信任就是这样一点点积累起来的。

AI Agent 时代怎么做产品？

Matt：在 AI agent 的成功里，UX 和底层技术一样重要吗？比如说，如何把用户一步步带入，让他们真正用起来、用得好。你在做 AI agent 的过程中，有哪些 UX 层面的经验？

Felix：UX 非常重要。Claude Code 的起点其实就是一个 UX 的变化：同样是 Claude，但不再只是“在云端对话”，而是运行在你本地电脑的终端里。这背后几乎完全是体验层的改变，模型本身没有变，核心能力也没有变。很多价值，其实就是从“你怎么和模型交互”里产生的。

那些真正被用户喜欢的 AI 产品，很少是“原始能力最强”的那一类。这不仅仅适用于 AI，而是整个软件行业的普遍规律。比如说邮箱，市面上肯定有不少产品，功能比 Gmail 更多、更复杂，很多公司总是试图靠“加功能”“多按钮”来领先。

这让我想到智能手机之前的那段时间，出现的各种奇怪手机：带投影仪的、带游戏手柄的、有全键盘的、没键盘的……大家不断往上“堆功能”。但最终真正成功的产品，往往不是“加了什么”，而是“去掉了什么”。它更关乎一种感觉：用起来是什么体验。说实话，我不太相信大多数人是看参数表来买手机的，人们做决定的原因往往不是芯片性能这些指标。

AI 其实很类似。当然，更强的模型确实会带来优势。我在 Anthropic 工作，可以直接和研究团队合作，拥有很强的模型，这是一个客观优势。但如果有一天有人在产品上打败我，我很怀疑那是因为他们做出了“更强的模型”。更可能的原因是：他们做出了更好的用户体验。

Matt：在实践层面，你们是怎么优化用户体验的？你们会不会非常精细地追踪用户行为？比如什么好用、什么不好用，然后重点投入？

Felix： 我们的方法其实并不算特别独特。有一件事对我来说比较新：对用户的极致关注。去和真实的人交流，优先做快速迭代，而不是长期规划。我们基本不会规划超过一个月的 roadmap，Cowork 的整个产品路线图，最长也就是一个月。我们更关注的是：下周做什么？下下周做什么？至于一年后的产品长什么样，说实话，我们没什么信心。任何人如果告诉我，他知道 AI 一年后会是什么样，我也不会太信服。

我过去做过的所有成功产品，之所以变好，都是因为我有很多次“纠偏”的机会，可以犯点小错、比较不同方案、不断调整方向。但现在有一个全新的变化：执行成本几乎为零。如果你带着 10 个想法来找我，我现在的反应是：那我们就把 10 个全做出来试试，看看哪个更好。

我们尽量在内部测试这些东西，而不是把用户当成免费的 beta tester。但大多数时候，你其实很快就能判断一个方向对不对。现在公司规模也不小了，很容易验证：这个东西是不是至少能打动 5 个人。真正“新”的，是这种执行速度。哪怕是两年前，如果你想快速迭代，也必须非常克制，因为资源有限，一次只能做少数几件事。但现在，执行变得极其便宜，你可以同时“做深”和“做广”。

Matt：你们真的会同时做 10 个版本甚至 10 个产品，然后让内部的人测试，最后再决定走哪个方向？

Felix： 实际上不止 10 个，我们现在公司内部，可能有 100 个不同的原型在跑。当然，这些原型大多数还没达到可以给用户看的程度。但能在内部快速做出来的数量，远远超过我过去任何时候的经验。

以前最大的限制是执行成本。比如你有一个好点子，来找我，我可能会说：“我们下个月排期，这个要做三周，在那之前你先去找用户验证一下。”但现在，你可以走过来说：“我有个想法。”我会说：“给我 10 分钟，我给你一个版本。”这种变化，有点像从“绘画”进入“摄影时代”。

Matt：当你有 100 个原型之后，真正的瓶颈是什么？总要有人做选择，这一步是不是会变慢？

Felix： 是的，我觉得“alignment（对齐）”依然很难，而且一直都很难。公司里有不同的人、不同的想法，你选谁？怎么选？怎么把不同方案里的优点组合起来？这些问题依然存在，而且这部分仍然高度依赖人。换句话说，这正是“人类判断”和“taste（品味）”发挥作用的地方。

Matt：品味是不是正在成为一种更核心的能力？

Felix： 是的，品味的重要性在上升。

Matt：但这又和刚才说的数据驱动有点冲突？一方面你会测试、看数据，但另一方面又有一些更难量化的判断。

Felix： 对。数据驱动的价值在于：帮你验证你的“品味”是否真的被用户认可，帮你判断方向是不是对的。即使是那些我们认为“品味很好”的人，比如早期做出 iPhone 的团队，他们也非常强调持续迭代和测试。Ken Kocienda 在《Creative Selection》这本书里写得很好：你需要品味，但你也必须不断验证。我觉得这两者是同时存在的。

而从更大的视角来看，我甚至在想：软件会不会越来越像时尚行业？现在手机其实已经有点这个趋势了。会有一个“基础性能”和“基础能力”的下限，但真正决定差异的，可能是：你讲了什么样的故事、你的 onboarding 做得怎么样、用户在使用时的感受如何。这些因素，很可能会比“模型本身有多强”更重要。

Matt：在 Cowork 的业务背景下，这种“品味”是如何运作的？你需要服务极其广泛的专业群体，有做营收运营的，有做市场营销的，甚至还有律师和会计。当受众如此宽泛时，“品味”意味着什么？你又是如何去测试它的？

Felix： 我反复提到“手机”的类比。我们所有人拿到手的可能都是同款手机，但世界上没有两部手机是完全一样的。你安装的 App 组合让你的手机像指纹一样独一无二。我们从同样的设备出发，但它融入我们生活的方式却各不相同，非常个性化。

对于 Cowork 来说，我们的思路很像：我们希望打造一种通用性极强的东西，可以应用在生活的方方面面。拿我自己的生活来说，我最近正在搬家，涉及 500 多页写满复杂术语的合同，很多词我根本看不懂，这时候 Cowork 就非常有用了。同时，它在医疗场景下也帮了我大忙，我女儿今年刚出生，处理那些堆积如山的医疗账单和表格时，它也发挥了巨大作用。

一边是房贷申请、和搬家公司谈判、处理财务申请，另一边则是纯粹的医疗文书。从理论上讲，这是同一种底层技术的两个完全不同的应用。但我发现，我脑子里思考的那些 primitives（基本原语）其实是一样的。有些原语打磨得更好，手感更顺滑。

我认为，作为一个产品缔造者，如果你密切关注并深度使用自己的产品，你能感觉到那种“撞在软件墙上”的生涩感。那种感觉很不爽，它没有让你起飞，而我想要创造更多能让人“飞起来”的时刻。即使客户所在的行业我完全不懂，我也可以从他们的故事中听出：哪些功能让他们如虎添翼，哪些环节让他们觉得被拖累。如果你能敏锐地捕捉并激进地去优化这些点，让用户进入那种“flow（心流）”状态，感觉讨厌的繁琐工作被自动接管了，那这里面就蕴含着巨大的价值。

Matt：打造 Claude Cowork 最难的部分是什么？

Felix： 我在想，如果重新来一遍，换个产品，什么是最难被“复刻”的？我觉得是那种“时机感”。我之前提到过，Cowork 的诞生是因为我们一直紧贴地面，敏锐察觉到了潜在需求。这种潜在需求是上天的馈赠，你很难凭空创造它。

软件行业其实一直存在大量的潜在需求，只要你有心去找，总能发现。所以，如果说构建 Cowork 的核心难点，我倒不觉得有什么技术细节特别难。做出一款好产品该有的难点它都有，比如所谓的“成长的烦恼”：如果你开了一家咖啡馆，原本准备接待 10 个人，结果来了 2000 万人，你该怎么办？这对我们来说有时确实挺难的。Anthropic 的产品需求量实在太惊人了，当然，作为产品负责人，我也没资格抱怨大家太爱用我的产品。

Matt：如果有人正在构建某种 AI Agent，关于开发流程、构建 Harness、专业化定制、或者是加装 Guardrails 和行业深耕，有什么经验可以分享吗？

Felix： 我首先会建议不要自己去造太多的底层轮子，可以试试我们刚推出的 Claude Managed Agents，它在很多场景下非常管用。

关于构建自定义 Agent，有正反两个维度的思考。反对过度定制的理由是：随着模型能力越来越强，我发现我们在产品开发中需要考虑的 Edge Cases（边界案例）反而变少了。我之前说过，记忆其实就是一个文本文件，如果 Claude 需要数据库，它自己就能造一个。所以，如果你想做一个超垂直、超专业化的产品，逻辑前提可能是模型还没强到能随时随地“现造”这些功能。如果模型以后能即时搞定一切，那你的专业化门槛可能就不存在了。

但是，支持投入这个领域的理由也很充分：整个行业要真正发挥出这种力量，还有很长的路要走。大家总喜欢用各种闪亮的类比来定义 AI，说它是像互联网、蒸汽机那样的发明。我觉得互联网带给我们的教训是：一项技术真正转化并重塑经济逻辑，需要几十年的时间。从第一个浏览器问世，到 Amazon 成为零售巨头，中间隔了太久。

所以，我的观点是：你应该深入进去，寻找那些独特且新颖的应用场景。不过，你提供的价值可能并不在于 Agent 本身，也不在于模型的智商，而在于你如何帮助人们组织工作。如何让它变得真正“好用”，这才是关键。

SaaS 的末日？

Matt： 几周前，你们发布了一个看似寻常的公告，结果市场反应剧烈，媒体甚至称之为“SaaS-Pocalypse（SaaS 启示录）”。当时你们只是增加了 10 到 11 个关于法律和 CRM 之类的文件支持。显然，无论市场情绪如何波动，这都反映出你们所构建的 Cowork 以及 Anthropic 整体所具备的影响力。

你们做了 Claude Code，解决了开发者的痛点；做了 Cowork，服务了所有人；现在又推出了 Managed Agents。当你们不断往技术栈的上层走，软件行业还有什么空间留给后来者吗？

Felix： 我经历过好几轮这种“民主化”浪潮，也就是构建事物的门槛越来越低，不再需要那些晦涩的专业知识。

举个例子：多年前我在 Microsoft 工作，参与了一个叫 Electron 的项目，这是一种让应用能在 Windows 和 macOS 上跨平台运行的技术。我们当时第一个应用案例就是 Visual Studio Code，这是一款后来在开发者中变得非常流行的代码编辑器，像 Cursor 这样的产品也是在它之上构建的。当年 VS Code 在公司内部刚推出时，很多人觉得这就是个“玩具”，觉得真正的开发者需要的是 Visual Studio 这种功能复杂、工具高级的大家伙。

但结果呢？你不再需要钻研得那么深了。对于做软件的听众来说，我这周感触很深：今年我查看 Assembly（汇编语言）的次数是零。而在过去五年里，这个数字从来不是零。

最近作家 Margaret Atwood 写了一篇非常精彩的文章，讲她如何使用 Claude。我在想，如果让 Margaret Atwood 来写软件，那个软件会是什么样？我肯定非常有兴趣装一个来试试。

所以我的预测是：未来我们将拥有更多的软件，而且会更加专业化。并不是说每个人都会亲手写软件，人们依然会创造并分享，大家也依然喜欢好用的工具，只是所需的技能点变了。以前是你必须精通“计算机的语言”，而未来，你会更倾向于做一个精通“人类语言”的人，软件将真正地“为人而造”。

Matt：这是否意味着一切最终都会归结为 UX 的问题？

Felix：20 年前成功的软件开发者是“计算机专家”，而未来的成功者将是那些深度理解人类和用户需求的人。这一直是一个渐进的过程，10 年前写软件就比 30 年前容易得多，AI 则是另一个阶跃式的变化。

至于市场表现，我不是经济学家，我是个软件工程师。我从来没搞懂过市场是怎么运作的，我也建议其他工程师不要把自己的行动指南完全建立在市场波动上。

我觉得还有堆积如山的事情等着我们去自动化，还有无数的工作可以变得更轻松。只要人类还有问题和麻烦，软件就会是一个合理的答案。

Matt：跳出具体的产品细节，你认为两三年后 Agent 的能力未来会走向何方？

Felix： 这对我来说挺难回答的，因为我原则上不喜欢在功能还没真正做出来之前就开空头支票。我的营销哲学一直都是：先做出酷炫的东西，再展示给人看。

大家似乎总是很快就忘记了 AI 已经走了多远，反而开始预期所谓的“Plateau（平台期）”会很快到来。我想这可能是科技史给人的刻板印象，就像 iPhone 刚出来那几年，每年的更新都是巨变，但最近几年更新幅度就变小了。

但作为一个 AI 观察者，我没有任何理由认为 AI 会在短期内进入平台期。我想提醒大家，AI 学会说出像样的人话其实也就这几年的事，而现在它已经能构建完整的应用、解决复杂的问题了。对我来说，这远非巅峰，我们还在半山腰呢。这段旅程正在加速，步子会迈得越来越大。Claude Mythos Preview 其实就是一个很好的证明：模型会越来越聪明，而且目前完全看不到上限。

Matt：你们是否会让受规管行业更轻松地接入 Cowork？作为一家风险投资机构，我们目前在工作场景下还用不了 Cowork，但我私下里一直在用。这在你们的计划中吗？

Felix： 你绝不是唯一一个在为特定受规管行业申请 Cowork 的人。作为产品人，用户的需求就是我们的风向标，我们会非常认真地倾听。

到了 2026 年，最让我激动的依然是：如何帮助人们重新组织工作，从而最大限度地发挥 AI 的能力。我曾在 Slack 工作过五年，那时候我们觉得自己在帮公司变革办公方式。虽然我们不是第一个做聊天工具的，也不是第一个提出“打破信息孤岛”的人。但我们卖给用户的不仅是一个聊天 App，而是一种更透明、更开放的办公文化。对于 AI 来说，这种变革是相似的：只有当你重新审视自己的工作流程，思考哪些部分可以交给模型，哪些部分需要完全掌控时，工具才最有效。

另一个让我兴奋的领域是：目前使用 AI 的人分为两类。一类是我们所说的“AGI Pilled（深受 AGI 浸染的人）”，他们全身心投入，研究怎么设置 Claude、开放什么工具权限、安装什么 MCP connectors。他们用得飞起，效率极高。而另一类人可能没那么多时间或兴趣去钻研。如何缩短这两类人之间的距离，让普通用户也能秒变 Power User，这其中的潜力巨大。在实践中，Cowork 的用户会发现我们几乎每周都会发布意义重大的更新，这件事目前看不到终点。

快问快答

Matt：哪一个想法被严重低估了？

Felix：MCP connectors。包括我在内，大家现在都在关注 CLI（命令行界面），但将数据与“执行引擎”分离，这件事本身有着巨大的内在价值，是一个非常技术硬核的观点。去年秋天 MCP 爆火过一阵，现在讨论变少了，但我认为到今年年底或明年，它会变得极其有用。就像 WebSocket 对 Amazon 或 TikTok 的用户来说是不可或缺的底层协议一样，用户不需要关心它，但工程师们目前对 MCP 的重视程度还远远不够。

Matt：哪一个想法被过度神化了？

Felix： 我认为：并不是每个产品都需要一个 Chat（聊天框）。在 2026 年的 AI 圈，这听起来可能有点叛逆。很多同行都有一种膝跳反应，一说要把 AI 引入产品，就立刻在右边加个侧边栏，底下放个聊天框。我鼓励 AI 开发者们多想一层：如何让 AI 以更自然、更有用的方式存在，而不仅仅是对话。

Matt：如果你今天白手起家，你会做什么？

Felix： 我可能会去关注这个行业的“长尾部分”。比如，世界上还有大量运行着 Windows 7 的旧设备，它们处理着琐碎的任务，却在社会中扮演着承重墙的角色。想想挺吓人的，这些处于现代 AI 触角之外的电脑，却在支撑着重要的社会功能。

另一个方向是，如果你相信 AI 的本质是计算机不再只是执行预设的功能，而是能非确定性地做出决策并代你执行，那我建议去攻占物理世界，这也是我对年轻人的建议。我们真的还处于非常早期的阶段，现在的 AI 产品处于就像是移动电话刚出现的“傻瓜机时代”。运气好的话，我们现在做的可能只是“诺基亚 3310”，它是个好手机，但它还不是智能手机，更不是 iPhone。真正属于 AI 的“iPhone 时刻”，正等着某个人去创造。

访谈视频原链接：https://www.youtube.com/watch?v=9MEJ4syOVrQ&t=2s