全靠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=_6C9nMvQsGU

https://www.youtube.com/watch?v=oPBN-QIfLaY

https://www.promptarmor.com/resources/claude-cowork-exfiltrates-files

本文来自微信公众号“InfoQ”，整理：褚杏娟，36氪经授权发布。