如果你的团队日常在 Slack 里协作，这条和你有关：Anthropic 推出了 Claude Tag，做法很直接——在任意 Slack 频道里 @Claude，像给同事派活一样把任务丢给它，它就接手去做。区别于此前"打开某个专门的 AI 工具或 IDE 才能用模型"的形态，这次 AI 被放进了团队已经天天在用的沟通渠道里。 这个产品形态的变化值得单独说清楚。过去用模型干活，往往要离开当前手头的协作流：切到一个聊天界面、一个插件、或一个独立 agent 环境，把上下文重新交代一遍。Claude Tag 把这一步省了——分派任务用的是 Slack 里本就熟悉的 @ 动作，给人派活和给 AI 派活在交互上变成同一件事。对团队来说，降低的不只是操作步骤，更是"要不要为这件事专门去用 AI"的心智门槛：任务出现在频道里，顺手 @ 一下就能委派出去。 Anthropic 给这条新闻配的核心数字是：在公司内部，这套工具已经生成了产品团队 65% 的代码。这是一个相当激进的占比——意味着在 Anthropic 自己的产品开发里，多数代码不再是工程师逐行手敲，而是由 Claude 产出。把这个数字和产品本身放在一起看，叙事是自洽的：如果委派 AB 干活的门槛足够低、低到融进日常沟通流，AI 承担的工作量自然会显著上升。 但这个 65% 需要谨慎对待，原因有几个，而原文都没有展开。第一，它是公司自报的内部数据，不是第三方独立核实的结果，自然带有展示动机。第二，"生成 65% 的代码"这个表述本身口径不清：统计的是字符数、行数，还是最终合并进主干的提交？AI 初稿里有多少经过工程师改写、审查、甚至推翻重来？把脚手架、样板代码和真正的核心逻辑混在一起算，得到的占比可能很不一样。第三，Anthropic 是一家以 Claude 编码能力为卖点的公司，用自家产品、由自家工程师产出这个数字，代表性能否外推到口径不同、约束更多的其他团队，是个开放问题。 落到实用层面：这条对正在评估"如何把 AI 编码更自然地嵌进团队工作流"的工程和产品团队最有参考价值——它给出的方向是"把 AI 放到协作工具里、而不是让人切换到 AI 工具里"。但要不要据此下判断，目前素材太薄。这条来自二手报道（The Decoder），更具体的运作细节、面向外部团队的开放范围与时间、定价、以及那 65% 的精确统计口径，原文均未给出，需等一手信息或第三方验证后再做判断。