全靠 Claude Code 10 天赶工上线，Cowork 删用户 11G 文件不含糊！核心研发：长时间打磨再发布很难成功
Anthropic 发布 Claude Cowork 研究预览版没多久，就被曝出了删用户文件、窃取文件等问题。 近日，博主 James McAulay 在测试 Cowork 功能中，选择“整理文件夹”这一基础且高频的场景，同时还与 Claude Code 进行对比。当 James 正在对比两款工具的整理进度时，Claude Cowork 突然触发了致命错误：在整理过程中擅自删除了约 11GB 文件。 更令人崩溃的是，这些文件并未进入回收站，而是被执行了“rm -rf”不可逆删除命令。James 紧急让 Claude Cowork 导出操作日志，确认该命令的执行记录后，咨询 Claude Code 能否恢复，得到的却是“无法恢复，属于致命操作”的回复。 事后复盘发现，James 在 Claude Cowork 询问文件操作权限时，点击了“全部允许”或“始终允许”，但没有预料到它会无视明确的“保留文件”指令，更没想到会执行不可逆删除操作。万幸的是，此次被删除的均为过往上传记录，并非核心重要文件，未造成严重损失，但这一安全隐患足以让用户对其望而却步。 James 还指出，Cowork 与 Claude Code 相比，存在两点不足： 首先是交互的繁琐性。发出“整理文件夹”的指令后，Claude Cowork 并未直接行动，而是要求先启动新任务并手动选择目标文件夹；Claude Code 则直接定位文件夹并开始分析，仅需授予一次权限即可推进。Claude Cowork 通过反复交互确认整理细节，比如询问“文件按什么维度分类”“用户数据文件夹如何处理”，即便明确回复“用户数据文件夹暂不删除、保留”，它仍在待办清单中标记“删除用户数据文件夹：已完成”，虽后续未实际执行该删除操作，但也暴露了指令响应的漏洞。 其次是效率的滞后性。整理过程中，Claude Cowork 运行命令多次停顿，节奏拖沓；而同期用 Claude Code 整理“音乐文件夹”，智能体快速给出“专辑和迷你专辑、单曲、Demo、翻唱”的分类建议，确认后即刻推进整理，全程仅需数十秒。即便两者均搭载 Opus 4.5 模型，Claude Cowork 的响应速度和执行效率仍明显落后，甚至让简单的文件夹整理变成了“持久战”。 除此之外，AI 安全公司 PromptArmor 还发现，由于 Claude 代码执行环境中存在已知但未解决的隔离缺陷，Claude Cowork 易受通过间接提示注入实施的文件窃取攻击。 据悉，这是一个最早由 Johann Rehberger 在 Cowork 尚未出现之前、于 Claude.ai 聊天环境中发现的漏洞，已经扩展到 Cowork 中。Anthropic 对该漏洞进行了确认，但并未进行修复。 Anthropic 提醒用户：“Cowork 是一个研究预览版，由于其 agentic 的特性以及可访问互联网，存在独特风险。”官方建议用户警惕“可能表明存在提示注入的可疑行为”。然而，由于该功能面向的是普通大众而非仅限技术用户，PromptArmor 表示认同 Simon Willison 的观点：“要求普通、非程序员用户去警惕‘可能表明提示注入的可疑行为’，这是不公平的！”此前，Every 团队提前获得权限，Dan Shipper、Kieran Klaassen 直播测试了该产品并分享了使用体验。期间，Anthropic Claude Cowork 项目核心成员 Felix Rieseberg 参与解读了产品设计思路。Felix 介绍，Cowork 是一个快速上线、先交给大家看怎么应用的产品，只用了 1.5 周就完成了开发，Felix 表示未来将以用户反馈为核心快速迭代。此外，工程师 Boris Cherny 还在 X 上透露，该产品的全部代码都是由 Claude Code 编写的。 在直播中，Felix 表示，产品工作流可拆分为 “非确定性（依赖模型智能）” 和 “稳定可重复（编写工具）” 两类，按需取舍。Skills 是平衡 “模型灵活性” 与 “工作流稳定性” 的关键，能沉淀可复用知识，还能催生涌现能力。 他认为，未来 Agent 类应用界面会趋简，用统一的 “泛化入口” 覆盖更多场景，而非专用化输入框堆砌。下面是三人对话部分内容，我们进行了翻译，并且在不改变原意基础上进行了删减，以飨读者。 一周半冲刺、先上线再说 Felix：这是我们团队做的产品。我们在最近大概一周半的时间里全力冲刺，把它做出来了。 Dan：一周半？ Felix：对，不过我想澄清一下：其实很多人早就有一个共识：如果能有一个“给非程序员用的 Claude Code”，那一定会非常有帮助、也很有价值。我们真正想做的，是帮助人把事情做完，不管是生活里还是公司工作中。 在这之前，我们其实已经做过好几个原型，尤其是在圣诞节前。但假期期间我们观察到一件事，我相信很多人也注意到了：越来越多的人开始用 Claude Code 做几乎所有事情，某种程度上，大家是在用它“自动化自己的人生”。 于是我们就在想：有没有一个足够小、足够早期的形态，可以先做出来给大家用，然后和用户一起快速迭代，真正搞清楚什么样的用户体验才是对的、我们到底应该构建什么。 现在你们看到的这个就是答案。它是一个 research preview，非常早期的 alpha 版本，有很多不完善的地方、很多毛糙的边角，你们已经看到不少了，这些我们都会很快改进。但这就是我们的尝试：在开放状态下构建产品，和外部的人一起打磨。 Dan：我太喜欢这种方式了，能不能讲讲你们做的一些设计决策？ Felix：这是个很好的问题。我个人有一个判断：不只是 Anthropic，而是整个 Agent 类应用的用户界面，在接下来一两年里都会发生非常大的变化。 现在我们看到的，是为不同任务设计的高度专用化输入框，以及围绕特定任务搭出来的一整套脚手架。但随着模型能力不断提升、整个行业对“泛化问题”的理解逐渐加深，我认为未来我们会用更少的界面，覆盖更广的使用场景。 但在当下，我们之所以把 Cowork 单独拆出来，是因为我们想非常透明地告诉用户：这是一个“施工中的区域”。某种意义上，我们是在邀请你走进我们的厨房。我们希望能和用户一起工作，几乎每天都上线新功能、修 bug、尝试新想法。所以这个独立的 Tab 本身就是实验性的，可以说是在前沿、甚至是“流血边缘”。它节奏更快、打磨得没那么精致，这也是我们把它单独拎出来的主要原因之一。 当然，也有一些技术层面的原因。比如现在这个 Cowork 是运行在你本地电脑上的，所以里面的对话是本地的，不会在多设备之间同步。同时，我们给了 Claude 更激进的一些 Agent 能力。综合这些因素，才决定做成现在这个形态。 Dan：同一个应用里，一边是云端的聊天，一边却是在自己电脑上跑的 Agent。怎么让用户真正理解“这两者不一样”？ Felix：是的，我心里有一个梦想，我相信很多人也有同样的想法：最终这些其实都不重要，代码到底跑在什么地方，应该只是一个技术实现细节。对用户来说，它应该就跟你访问纽约时报网站时会不会用 WebSocket 一样，谁会在乎呢？ 对我们来说，现阶段这样做的好处是，可以跑得更快、发布得更快，也能和真正使用这个产品的人更近距离地一起共创。我一直很坚定地认为，一个人关起门来是很难做出好产品的。那种“躲进山洞里干一年，最后拿出来”的方式，其实很难成功。 我也经常提醒大家：就连第一代 iPhone，都缺了很多我们现在觉得是“理所当然”的功能。所以，这确实是一个不小的门槛，但我们暂时可以接受，因为我们希望现在选择用这个产品的人，本身就是带着明确意图来的。 Dan：我觉得这是一个非常有意思的模式，先极快地把东西做出来，以一个“新入口”的形式放在应用里，让相对更少的人点进来。这样就能在真实世界里快速迭代，而不是一开始就追求完美。尤其是在你刚才说一周半就能做出一个版本，简直疯狂。 “现在的状态是，先看看大家怎么用” Kieran：但在你们脑海里，这个产品“真正的形态”是什么样的？你们接下来想往哪里走？ Felix：我太喜欢这个问题了，因为说实话，我也想反过来问你们两个同样的问题：你们希望它变成什么？你们想用它做什么？我已经听你们提到过，比如想让它能访问整台电脑，还有多选交互是不是可以更灵活一些之类的。 但我现在更多的状态是，先看看大家怎么用，然后疯狂尝试各种可能性。里面肯定有很多是错的，也会有一些是对的。对我来说，真正有意思的不是我个人的愿景，而是用户真正想拿它干什么。 我过去做过的产品几乎都是这样：你心里以为用户会这么用，结果他们找到了完全不同的用法，然后你顺着那个方向继续做下去。所以我特别希望我们能搞清楚：人们现在到底想要什么、喜欢什么、不喜欢什么。肯定也会有人明确说不喜欢某些地方，那我们就根据这些反馈不断调整、迭代。 Kieran：这又回到一个老问题了。比如 Boris 就非常擅长把 Claude Code 做成一种让用户在使用过程中逐渐发现“自己到底想要什么”的工具。那你们在 Cowork 里有没有类似的策略？比如给我们一些“积木式”的东西？能不能加自己的插件或 Skills？Claude Code 很酷的一个地方在于它特别好 hack、特别可塑，你们面向非程序员的 Cowork 是不是也有类似理念？ Felix：对，非常强调可组合性。你刚才提到 Boris 推动 Claude Code 早发布、快迭代、看用户怎么用，其实特别巧，我们之所以能这么快上线，很大程度上也是 Boris 在推动我说，“你应该早点给大家看看，看他们会怎么用”。（注：Boris Cherny 是 Claude Code 核心创作者） 至于可组合这一点，过去几周、甚至最近两个月里，我自己感受最深的，是我越来越依赖 Skills。以前我可能会去写 MCP 工具，或者为 Claude 专门做一套很定制化的东西，现在我更多是直接写 Skills。 有时候我还是会写一个二进制程序，但我随后就会在一个 Skill 文件里用 Markdown 描述：Claude，如果你要做这件事，请遵循这些规则。 举个例子，我最近在给自己做一个马拉松训练计划。我写了一个小程序，从不同平台抓取我的运动数据；然后在一个 Skill 里写清楚：如果你要帮我做训练计划，请按这些原则来。现在，只要你在 Claude AI 里装过的 Skill，都会自动加载到 Cowork 里。而且我觉得这只会越来越重要，尤其是模型越来越聪明，比如 Opus 4.5 版本，对 Skills 的遵循能力真的非常强。 所以目前来说，Skills 大概是我们最主要、也最“可 hack”的入口。 统一的“泛化入口”趋势 Dan：太棒了。你刚才提到未来会有更少的 UI 形态。这是不是也意味着，围绕“聊天是不是 AI 的最终形态”这个争论，你其实是在押注自然语言会长期存在？也就是说，我们最终不会有越来越多复杂的 UI，而是更少的界面，人只需要和一个 Agent，或者一个能调度其他 Agent 的 Agent 对话？你们现在推动的方向，某种程度上是不是就类似今天 Claude Code 所展现出来的那种形态？ Felix：是的，这个问题现在仍然存在很大的争论空间，而且肯定不存在什么“Anthropic 官方立场”。老实说，就算是在我这个并不算大的团队里，大家也未必能在整体上达成一致。每个人对于未来人类将如何与 AI、与模型交互，都有非常不同的想象。 如果只从我个人的角度来说，我大概坚信两件事。第一是：聊天式输入及其各种变体——不仅仅是模型意义上的聊天，而是更广义的那种“我想要点什么”的输入框——会比我们想象中存在得更久。 如果你把它抽象开来看，不管是 Google 首页，还是 Chrome 的地址栏，本质上都是一个“我想要某样东西”的输入框，我认为这种形态会长期存在，我们会继续拥有某种看起来很像搜索框的入口。 问题是，我们到底需要多少个这样的输入框？你会有一个专门写代码的框吗？一个用于个人娱乐的、一个处理医疗相关问题的？我并不确定未来会存在这么多彼此割裂的输入框。 我再拿 Google 做类比。过去你可能记得，Google 会为不同需求提供不同的搜索入口和子产品。但现在，越来越多时候，你只是直接在 Chrome 的地址栏里输入你想要的东西。你不会真的先想清楚“我现在是在购物模式”，然后再专门去打开 Google Shopping。 所以，如果我们未来看不到一种更聪明的、能理解你想做什么的“泛化入口”，我会很意外。当然，后端可能仍然会分流，比如它理解你想要做的是 X，于是给你呈现一个适合 X 的界面，但入口本身很可能是统一的。 产品设计中的取舍 Dan：我觉得一个很有意思的反例是 Microsoft Excel。某种程度上，它和 AI 的工作方式其实也很像：这是一个通用型产品，上手极其简单，但你可以在里面把事情做到无限复杂。而且，Excel 甚至某种程度上催生了后来的 B2B SaaS 浪潮，很多 SaaS 本质上就是把 Excel 里的复杂工作流“产品化”了。所以也有另一种可能：你先有一个极其通用的工具，然后人们在里面发现了高价值、高强度的工作流，最后这些工作流再被拆分成独立产品。 Felix：我觉得 Excel 真的是一个极其漂亮的例子。对很多开发者来说，Excel 其实处在一个有点“边缘化”的位置，但如果你比较一下 Excel 的日活用户数量和全球开发者的数量，那是一个非常惊人的对比。 我在 Excel 身上看到的一个很有意思的点是：它的重度用户，其实并不太在意那种“边际效率提升”，或者 UI 上一点点的小优化。他们更在意的是对这个产品的深度熟悉和肌肉记忆。 这里面是有教训的。我在很多产品表面上都见过这种情况：作为开发者，你会觉得“如果我单独给你做一个更贴合这个场景的小工具，你的工作流会更好”。但结果往往是，用户并不会去用那个新工具，而是继续在他们已经非常熟悉的产品里，把事情做完。 举个例子，这是我在 Slack 工作多年反复学到的一课：你可以做很多你自认为更适合某个使用场景的独立服务，但用户最后往往还是选择就在聊天里完成这件事。 Dan：说到这里，虽然今天的主题更偏向非开发者，但我感觉现在有不少开发者在看。你正好是那种“真的把这个东西做出来了”的人，对 Agent native 应用的构建理解非常深。 我们一直在思考 Agent-native 应用的核心原则。比如其中一个原则是“对等性（parity）”：用户通过 UI 能做的事情，agent 也应该能做。我在 Cowork 里已经能看到这一点。另一个是“粒度（granularity）”：工具应该尽量处在比功能更底层的层级，而“功能”更多存在于 prompt 或 Skill 中，这样你就能以开发者没预料到的方式去组合工具。这会自然带来第三个原则“可组合性（composability）”，而可组合性最终会产生第四个：涌现能力（emergent capability）。也就是用户开始用它做你完全没想到的事情，你看到了潜在需求，然后再围绕它构建产品。 这在我看来，几乎就是 Claude Code 的工作方式。我很好奇，这一套在你听来是否成立？或者从你们在 Anthropic 大规模落地的经验来看，有没有什么能让大家把 Agent native 应用做得更好的建议？ Felix：这套说法对我来说非常有共鸣。而且我觉得，“涌现能力”里隐藏着一个非常重要的事实：无论是个人还是在孤立的小团队里，我们几乎不可能提前预测一个 Agent 最终会在哪些地方变得极其有用，尤其是当你只给了它一些相对原始的工具时。 把工具尽可能下沉、做成通用形态，是一件非常强大的事情。工具越可组合、越通用，你就越能从模型智能的持续提升中获益。我和很多开发者聊过一个感受：模型智能提升、以及模型“正确调用工具”的能力，增长速度往往远快于你新增工具、或者教育用户理解这些工具的速度。 所以如果你退一步思考：“我能不能先做一个高度通用的工具？”那你构建出一个可以适应未来新场景的产品的概率，其实会大得多。这一点，我非常认同。 Dan：那在这些原则之下，你怎么看其中的取舍？比如工具设计本身的权衡问题。 Kieran：对，我觉得把东西放进 prompt 里、再配合工具，本身是很棒的。但问题在于，我们现在突然需要去创建一些“能读取 Skills 的工具”，或者类似的东西。于是就出现了一个新的“元层”。Skills 本质上就像是一种即时的 prompt 注入，但你得先把这个体系搭出来。现在所有在做这些东西的人，如果不是直接用 Claude Code 或 Cloud SDK，那基本都得自己从头构建一整套。 于是就出现了一种拉扯：你到底是把行为直接描述在一个 tool 里？还是再包一层 tool，让它去调用别的东西？这中间是有摩擦成本的。当然，可组合性是很好的。比如一开始你可能会有五个 tool：搜索邮件、读取邮件、做这个、做那个。但你也可以说：不，我只提供一个 execute tool，然后用 Skills、MCP，或者某种抽象层来完成这些事情。现在正处在这样一个转变期，而 Claude Code 和 Claude SDK 显然是在推动这个方向。 但我确实能感受到这种摩擦。我猜你也一定感受到了。所以我很好奇：你有没有什么最佳实践，能给那些还停留在“传统 AI 应用思维”的人一些建议？ Felix：我不确定我能给出什么“来自山顶的智慧”，会比你已经拥有的经验更有价值。但你说的那点，确实非常戳中我。我觉得你必须做一个取舍：哪些输出你愿意让它是非确定性的、哪些地方你愿意依赖模型的智能。而且一旦你依赖模型智能，每当你换一个更便宜、或者“更笨”的模型，那些地方的质量就会下降。 所以我会把整个工作流拆成两类：一类是非确定性的；一类是可重复、稳定的。如果某个部分非常可重复，而且你可以非常确信它“永远不会变”，而且就算模型变聪明了，你也得不到任何额外收益，那我会觉得，这正是写一个工具的好地方。 其实我们已经在这么做了。你完全可以给 Claude 一个极其通用的“汇编级”工具，比如：“直接调用 GCC，你想怎么编就怎么编。”但我们并没有这么做，因为那样就太疯狂了。 Skills 与可组合性实践 Dan：那已经是粒度的极限了。 Kieran：不过我也想说一句：当我和很多开发者聊的时候，我发现即便这个“是否要给模型工具”的基本假设，也正在被挑战。我不会把太多赌注压在这个假设上。比如，我们到底是不是还需要给 Claude 工具？还是说，某一天它只需要靠记忆和权重，直接把 0 和 1 写到世界里？这是一个非常有意思、也非常难判断的问题，没人真的知道答案。 但你们已经在实践中学到了一些东西。你们之所以创造了 Skills，就是因为仅靠 Slash command 或子 Agent 已经不够了，对吧？我们需要 Claude.md 更强，但现实是 Skills 正是为了解决这个问题而诞生的，而且显然它们效果很好。我完全认同你说的，Skills 太棒了。我现在几乎每天都在写 Skills，而且真的很爱用。所以这里面一定有些什么。但问题是：什么时候应该用 Skill？什么时候又不该？ Felix：这真的是一场特别有意思的对话。有一个你以后真的应该跟 Barry 聊聊。在公司内部，至少在某种程度上，Skills 这个概念就是他提出来的。从根本上说，Skills 正是你刚才描述的那种张力的自然产物。 举个例子，我们想让公司内部的人能很容易地拿到各种仪表盘。我们用的是一家主流数据服务商，很多数据都在那儿。一开始我们在想：要不要做一堆非常具体的工具，专门去拉数据、压缩成固定格式。最早那几版仪表盘，其实效果并不理想（那还是 4.5 之前）。大概每三四个里面，就有一个看起来很拉胯。于是，我们开始想：要不要把参数卡死，直接做一个“固定模板”的仪表盘？Claude 只负责往里面填新数据。 但在这个过程中，我们突然发现了一件事：如果你只是告诉 Claude 如何正确地查询这个数据源、可以使用 SQL、以及生成仪表盘时需要遵循哪些设计原则，突然间，它就能稳定地产出质量很高的结果，而且是“几乎每一次”都很好。 更重要的是，这就打开了“涌现能力”的大门。因为你还可以对 Claude 说：“我知道你在遵循这些仪表盘原则，但我想换一种图表类型”，或者“我想把它和另一份数据结合起来。”就在这一刻，事情真正开始变得有趣了。 Dan：这真的很有意思。我觉得为什么要用 Skill，而不是只给它 GCC、让一切都即兴发生，其中一个关键原因在于：你需要把一些可重复的、可分享的知识，变成一个大家都能讨论、都能复用的东西。并不是所有事情都应该是“即时生成”的。有些事情，你就是希望一个团队能长期、反复地用同一种方式来做。而这，本质上就是 Skill。 Felix：而且这其实也很符合人类本身的工作方式，对吧？比如我刚加入一家公司时，总有人教我怎么订机票、怎么订会议室。从某种意义上说，我们每个人，都是靠着一堆 markdown 文件在工作。 我觉得差不多该下线了，但在走之前，我想让你们两个各自给我一个建议：你们最希望我们改的一件事是什么？ Dan：那我先来一个最简单的：给我对整台电脑的完全访问权限。还有就是，让我更清楚地知道它现在到底是在我本地电脑上运行，还是在云端以聊天的形式运行；以及，让它在手机上用起来更顺畅。 Kieran：我也支持移动端。但我最想要的是能让我添加自己的插件。我有一个插件市场，我只想把它接进来直接用。现在我得在一个应用里加东西，再拷贝到这里，有点绕。可能也能凑合用，但如果能原生支持插件市场、直接添加插件，那真的会非常棒。 Felix：好，明白了。谢谢你们，这些反馈都非常有价值。我们会把这些带回去，跟团队一起讨论。也欢迎大家把想法发给我们。我们真的很希望听到大家的反馈，并据此调整路线图。 测试总结：理念可以，做得一般 最后，我们总结了 Every 团队的测评结果。 Claude Cowork 的核心定位是为非技术用户提供 Claude Code 级别的 AI 协作能力，其最显著的突破在于重构了 AI 使用逻辑，从传统“发提示词→等回复”的一问一答模式，升级为“异步协作”模式。 与普通 Claude 聊天相比，Claude Cowork 专为“长时间工作”设计，具备持续推进任务直至完成的能力。直播中展示的典型案例包括：审计过去一个月的日历并分析与目标的匹配度、抓取 PostHog 数据统计按钮点击量、分析 Every 咨询业务的竞品、整理下载文件夹、校对 Google Docs 文案等。这些任务均需 AI 持续“浏览”、推理，部分任务耗时可达一小时左右，远超普通 AI 聊天的响应速度。 产品的场景适配性极强，尤其适合需要深度研究和数据处理的岗位。用户只需连接 Chrome 浏览器，AI 即可直接使用用户已登录的各类服务，无需重复认证，轻松完成 Twitter 时间线热点分析、竞品信息搜集等需多平台联动的任务。同时，它支持生成文档、Excel、PPT、PDF 等多种产出物，可应用于简历优化、会议发言起草等日常工作场景，大幅提升增长团队、咨询人员、写作者等群体的工作效率。 在交互设计上，产品右侧设置了待办任务列表，清晰展示任务进度与当前阶段，用户可直观掌握 AI 工作状态。其“询问用户”功能还配备了可视化交互界面，支持多选项快速响应，进一步降低了操作门槛。 根据测评，Cowork 具备较强的可扩展性，支持加载用户已安装的 Claude Skills，这也是其最具“可玩度”和“可定制性”的核心入口。用户可通过 Skills 封装专业知识与操作逻辑，实现个性化需求。 测评团队也指出了产品当前存在的争议与不足。 最核心的争议在于“单独设置 Cowork 标签页”的设计：部分用户认为应在同一标签页内根据任务自动切换模式，避免额外的选择成本；但也有观点认为，独立标签页能明确提醒用户切换使用心态：从“实时对话”转向“异步托付”，尤其对非技术用户而言，这种明确的区分有助于适应全新的协作范式。 另外在体验细节上，产品仍有诸多优化空间：一是 UI 打磨不足，任务列表仅按时间排序，缺乏视觉区分度，部分内容存在“懒加载”导致展示不及时；二是权限管理不够直观，普通用户难以清晰判断 AI 是在本地还是云端运行，文件夹访问权限需手动配置易造成困惑；三是“询问用户”功能存在逻辑缺陷，可能在用户未响应时自动跳过问题，且选项数量和字符数存在限制；四是对复杂应用（如 Google Docs）的适配尚不完善，相关操作容易失败。 针对不同用户，测评团队给出了针对性使用建议：非技术用户可将其视为“升级版聊天功能”，用日常任务直接尝试，逐步适应异步协作模式；重度用户可尝试通过 Skills 定制个性化功能，探索组合使用的可能性。他们表示，所有用户均需保持好奇心，忽略“三个月前 AI 做不到”的固有认知，在每一次产品更新后重新尝试核心需求，毕竟 AI 能力每隔几个月就会发生巨大迭代。 最终，测评团队给出的评分结论为：“理念绿牌，当前执行黄牌”。理念层面，产品开创性地将 Claude Code 级别的异步协作能力开放给非技术用户，推动了 AI 协作范式的转变，具备极高的探索价值；执行层面，因 UI 粗糙、部分功能逻辑不完善等问题，当前体验仍有较大优化空间。 参考链接：https://www.youtube.com/watch?v=_6C9nMvQsGUhttps://www.youtube.com/watch?v=oPBN-QIfLaYhttps://www.promptarmor.com/resources/claude-cowork-exfiltrates-files
Anthropic 深夜放出王炸！白领饭碗要被 AI 砸了？网友：不支持 Linux，差评
在开发者工具 Claude Code 推出之后，Anthropic 团队很快意识到一个出乎预料的现象：开发者并没有把它局限在“写代码”这件事上。相反，Claude Code 被迅速用于整理资料、撰写文档、生成报告、分析数据，甚至承担起类似“数字同事”的角色。这种使用方式的外溢，最终促使 Anthropic 做出一个更激进的产品判断——如果大模型已经被当作工作伙伴使用，那么是否应该为“所有人”，而不仅仅是开发者，提供一种真正面向日常工作的智能协作形态？于是今天，Anthropic 正式推出了 Cowork。Anthropic 工程师、Claude Code 创建者 Boris Cherny 在 X 上发帖宣布了该消息。他写道：自 Claude Code 发布以来，我们发现用户将其用于各种非编码工作：例如进行度假研究、制作幻灯片、清理电子邮件、取消订阅、从硬盘恢复婚礼照片、监测植物生长、控制烤箱等等。这些应用场景丰富多样，令人惊喜——原因在于底层 Claude Agent 是最佳代理，而 Opus 4.5 是最佳模型。今天，我们非常激动地推出 Cowork，这是我们让 Claude Code 服务于所有非编码工作的第一步。该产品目前仍处于早期阶段，功能尚不完善，与 Claude Code 最初发布时的状态类似。Cowork 包含许多我们认为使其真正与众不同的创新用户体验和安全功能：内置虚拟机用于隔离、开箱即用的浏览器自动化支持、以及对所有非编码工作的支持。据介绍，Cowork 是一款基于 Claude Code 底层架构构建的全新产品，目前以“研究预览版”的形式，率先面向 macOS 平台上的 Claude Max 订阅用户开放。与传统对话式 AI 不同，Cowork 的核心定位并非“聊天”，而是“协作”：它试图让 Claude 从一个被动响应指令的助手，转变为能够理解任务、制定计划、持续执行，并与用户保持协同关系的智能工作体。从“对话助手”到“数字同事”长期以来，大模型产品的主流交互形态仍然是对话。用户输入问题，模型生成回答；用户提出修改，模型再次响应。这种模式在信息查询、文本生成等场景下行之有效，但在真实工作流中却暴露出明显局限——上下文需要反复提供，文件需要人工整理，输出结果往往还要用户自行转换为可用格式。Cowork 试图解决的，正是这一断裂问题。在 Cowork 模式下，用户可以直接授予 Claude 对本地指定文件夹的访问权限。需要强调的是，这种访问并非“全盘授权”，而是由用户明确选择、逐一控制的结果。Claude 只能看到、读取、编辑或创建那些被允许的文件和目录，而无法触及任何未授权内容。一旦获得权限，Claude 的能力边界就发生了质变。它不再只是基于文本上下文“想象”文件内容，而是可以直接操作真实存在的工作材料。例如，它可以扫描一个杂乱无章的下载文件夹，按照文件类型、时间或用途进行分类和重命名；可以从大量截图中提取关键信息，自动生成一份结构化的费用清单；也可以将零散的会议笔记、草稿和片段，整理成一份逻辑清晰的报告初稿。这种能力的本质，并不是简单的“更聪明”，而是 Claude 被嵌入进了用户的实际工作环境之中。Anthropic 在产品说明中多次强调，Cowork 的体验更接近“给同事布置任务”，而不是与机器人来回对话。一旦任务被下达，Claude 会自行拆解步骤、规划执行路径，并在执行过程中持续向用户同步进展。用户无需等待任务完成即可插入新的反馈或补充想法，这些指令会被自动排队、并行处理。这也是 Cowork 与普通对话模式最根本的差异之一：它默认假设用户的工作是多线程的，而不是线性的。当然，“更自主”的能力，意味着更高的风险。让 AI 进入文件系统，甚至具备修改、创建和删除文件的能力，无疑是一种能力跃迁，同时也是风险跃迁。Anthropic 并未回避这一点，反而在产品介绍中反复提醒用户保持警惕。首先是操作层面的风险。如果收到明确指令，Claude 确实可以执行具有破坏性的操作，例如删除本地文件或批量修改内容。一旦指令本身存在歧义，或者模型误解了用户意图，后果可能是不可逆的。因此，在 Cowork 中，Claude 在执行任何“重要操作”之前，都会主动征求用户确认。这种设计并非形式上的“弹窗提示”，而是希望用户在关键节点重新审视任务目标，必要时进行纠正或细化指令。Anthropic 也明确建议，在涉及高风险操作时，用户应提供尽可能清晰、具体的指示，而不是依赖模糊的自然语言。另一类更复杂、也更具行业共性的风险，是“提示注入”（Prompt Injection）。在 Cowork 的工作过程中，Claude 可能会接触来自互联网的内容，例如网页、文档或第三方信息源。如果这些内容中被恶意嵌入了指令，试图诱导模型偏离原本的任务计划，就可能引发安全问题。Anthropic 表示，他们已经构建了针对提示注入的多层防御机制，但也坦言，“代理安全”——即确保 AI 在现实世界中执行操作时的可控性——仍然是整个行业正在积极探索的前沿问题。从这个角度看，Cowork 并不是一个“已经完全成熟”的产品，而更像是一次对未来工作方式的现实实验。Anthropic 也明确指出，这些风险并非 Cowork 独有，而是所有具备“行动能力”的 AI 工具都会面临的问题。只是对许多用户来说，Cowork 可能是第一次接触到一个超越简单对话、真正能够影响本地环境的 AI，因此更需要建立正确的使用习惯和风险意识。研究预览版背后的产品逻辑Cowork 目前被定义为“研究预览版”，这一定位本身就释放了明确信号：Anthropic 并不认为自己已经找到了最终形态，而是希望通过真实用户的使用反馈，加速产品迭代。根据官方披露，Anthropic 计划在后续版本中引入多项重要改进。其中包括跨设备同步能力，使 Cowork 不再局限于单一终端；以及将其移植到 Windows 平台，从而覆盖更广泛的办公人群。同时，安全机制也将持续强化，尤其是在代理行为可解释性和可控性方面。从产品路径上看，Cowork 与 Claude Code 之间存在清晰的继承关系。两者共享相同的底层架构，这意味着 Cowork 在能力上，理论上可以完成 Claude Code 已经证明可行的许多复杂任务。不同之处在于，Cowork 将这些能力重新封装为更偏向非技术用户的交互方式，降低了使用门槛。如果说 Claude Code 面向的是“愿意为效率付出学习成本”的开发者群体，那么 Cowork 的目标人群显然更加广泛：内容创作者、产品经理、运营人员、行政人员，乃至任何需要与文件、资料和信息打交道的知识工作者。在掌握 Cowork 的基本使用方式后，用户还可以进一步扩展 Claude 的能力边界。首先是连接器。Claude 可以通过用户已有的连接器，访问外部信息源，从而将本地任务与外部数据打通。这使得 Cowork 不再只是一个“本地整理工具”，而是可以承担跨系统的信息整合角色。其次是新增的一系列技能。这些技能专门用于提升 Claude 在创建文档、演示文稿以及其他常见办公文件时的表现，使其输出更加贴近真实工作场景的格式和标准。此外，如果用户在 Chrome 浏览器中将 Cowork 与 Claude 配对使用，Claude 还可以完成需要访问浏览器的任务。这一步，实际上进一步模糊了“对话 AI”“自动化工具”和“数字员工”之间的界限。从整体设计来看，Cowork 试图减少用户在“提供上下文”和“整理结果”上的认知负担。用户无需手动拼接背景信息，也无需将 Claude 的输出再加工成可用成果。更重要的是，用户不必为了等待 AI 完成某个任务而中断自己的工作节奏——任务可以被连续布置、并行执行。Anthropic 在描述这种体验时，用了一个耐人寻味的比喻：这更像是给同事留言，而不是来回沟通。用户：没有 Linux 版本，差评！在 Cowork 发布之后，迅速在开发者社区、AI 产品圈以及更广泛的知识工作者群体中引发讨论。与以往单纯围绕模型能力、跑分或价格的争论不同，这一次的焦点明显转向了一个更现实的问题：“AI 是否真的开始成为一个可以被信任、被授权的工作参与者？”在 Reddit 上的最新讨论串里，有用户评论指出他们“很期待尝试这个功能”，认为 Anthropic 近来在产品和用户信任构建上做得不错。**因为仅限 macOS 和订阅计划，部分用户感到遗憾。**在另一个 Reddit 讨论串中，有用户对 Cowork 的平台限制表达了不满或遗憾，评论集中在“只支持 macOS”这一点上。此外，值得注意的是，有些评论虽然不是专门针对 Cowork，但有一些用户还是对 Anthropic 近期产品策略与沟通的不满，对 Cowork 的发布背景和用户关系具有间接关联语境。在 Reddit 平台，有长期用户表示，自己已经从忠实支持者变成对 Anthropic 的信任下降甚至不满。该用户指出：“作为很早一批用户，我原本极力推荐 Claude，但最近几个月感觉 Anthropic 的产品质量沟通都变差了。”参考链接：https://claude.com/blog/cowork-research-previewhttps://x.com/bcherny/status/2010809450844831752https://www.reddit.com/r/singularity/comments/1qb6qv1/introducing_cowork_claude_claude/?utm_source=chatgpt.com