分类 分类 下的文章

Sebastian Raschka 刚刚更新了他的「大型 LLM 架构对比」长文,内容量翻倍,堪称 2025 年最全面的 LLM 架构技术解析。

Image

Sebastian Raschka(@rasbt) 是一位 ML/AI 研究工程师,前统计学教授,著有《Build a Large Language Model From Scratch》一书。

他在自己的技术博客上发布的这篇架构对比文章,从最初版本到现在已经扩展了一倍多。

下为 Sebastian Raschka 原文,清晰易懂,值得一读:

大型语言模型架构大比拼

来源: https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison

发布时间: 2025-07-19T11:11:10+00:00

作者: Sebastian Raschka

距离最初的 GPT 架构开发已经过去了七年。乍一看,回顾 GPT-2(2019)并展望 DeepSeek V3 和 LLaMA 4(2024-2025),人们可能会惊讶于这些模型在结构上仍然如此相似。

当然,位置编码已经从绝对位置编码演变为旋转位置编码(RoPE),Multi-Head Attention 在很大程度上已经让位给 Grouped-Query Attention,更高效的 SwiGLU 取代了 GELU 等激活函数。但在这些细微改进之下,我们真的看到了突破性的变化吗?还是我们只是在打磨相同的架构基础?

比较大型语言模型以确定有助于其良好(或不太好)性能的关键要素是出了名的困难:数据集、训练技术和超参数差异很大,而且往往没有详细记录。

然而,我认为检查架构本身的结构变化仍然具有很大价值,可以看到 2025 年大型语言模型开发者们在做什么。(其中一部分模型如图 1 所示。)

图 1:本文涵盖的一部分架构。

因此,在本文中,我不会写基准性能或训练算法,而是专注于定义当今旗舰开源模型的架构发展

(你可能还记得,我不久前写过关于多模态大型语言模型的文章;在本文中,我将专注于最新模型的文本能力,并将多模态能力的讨论留待以后。)

提示: 这是一篇相当全面的文章,因此我建议使用导航栏访问目录(只需将鼠标悬停在 Substack 页面的左侧)。

可选: Sebastian Raschka 原文中还配有视频版本,其为本文的旁白和删节版本。

DeepSeek V3/R1

正如你现在可能已经听过不止一次,DeepSeek R1 在 2025 年 1 月发布时产生了巨大影响。DeepSeek R1 是一个基于 DeepSeek V3 架构 构建的推理模型,该架构于 2024 年 12 月推出。

虽然我在这里的重点是 2025 年发布的架构,但我认为包含 DeepSeek V3 是合理的,因为它只是在 2025 年 DeepSeek R1 推出后才获得广泛关注和采用。

如果你对 DeepSeek R1 的训练特别感兴趣,你可能会发现我今年早些时候的文章很有用:

在本节中,我将重点介绍 DeepSeek V3 中引入的两项关键架构技术,它们提高了计算效率并使其与许多其他大型语言模型区别开来:

  • Multi-Head Latent Attention(MLA)
  • Mixture-of-Experts(MoE)

Multi-Head Latent Attention

在讨论 Multi-Head Latent Attention(MLA)之前,让我们简要回顾一些背景知识,以解释为什么要使用它。为此,让我们从 Grouped-Query Attention(GQA)开始,近年来它已成为 Multi-Head Attention(MHA)的新标准替代品,可以更高效地利用计算和参数。

因此,这里是 GQA 的简要总结。与 MHA 不同,在 MHA 中每个头也有自己的一组键和值,为了减少内存使用,GQA 将多个头分组以共享相同的键和值投影

例如,如图 2 所示,如果有 2 个键值组和 4 个注意力头,那么头 1 和 2 可能共享一组键和值,而头 3 和 4 共享另一组。这减少了键和值计算的总数,从而降低了内存使用并提高了效率(根据消融研究,不会明显影响建模性能)。

图 2:MHA 和 GQA 之间的比较。这里,组大小为 2,其中一个键值对在 2 个查询之间共享。

因此,GQA 背后的核心思想是通过在多个查询头之间共享键和值来减少键和值头的数量。这样做(1)降低了模型的参数数量,(2)减少了推理期间键和值张量的内存带宽使用,因为需要从 KV 缓存中存储和检索的键和值更少。

(如果你好奇 GQA 在代码中的样子,请参阅我的 GPT-2 到 LLaMA 3 转换指南中没有 KV 缓存的版本,以及我的 KV 缓存变体在这里。)

虽然 GQA 主要是 MHA 的计算效率解决方案,但消融研究(例如原始 GQA 论文和 LLaMA 2 论文中的研究)表明,在大型语言模型建模性能方面,它的表现与标准 MHA 相当。

现在,Multi-Head Latent Attention(MLA)提供了一种不同的内存节省策略,特别适合与 KV 缓存配合使用。MLA 不像 GQA 那样共享键和值头,而是在将键和值张量存储到 KV 缓存之前将其压缩到低维空间。

在推理时,这些压缩的张量在使用前会被投影回其原始大小,如下图 3 所示。这增加了一个额外的矩阵乘法,但减少了内存使用。

图 3:MLA(在 DeepSeek V3 和 R1 中使用)与常规 MHA 的比较。

(顺便说一句,查询也被压缩,但仅在训练期间,不在推理期间。)

顺便说一句,MLA 在 DeepSeek V3 中并不新鲜,因为其 DeepSeek-V2 前身也使用(甚至引入)了它。此外,V2 论文包含一些有趣的消融研究,可以解释为什么 DeepSeek 团队选择 MLA 而不是 GQA(见下图 4)。

图 4:来自 DeepSeek-V2 论文的注释表格,https://arxiv.org/abs/2405.04434

如上图 4 所示,GQA 的性能似乎比 MHA 差,而 MLA 提供了比 MHA 更好的建模性能,这可能是 DeepSeek 团队选择 MLA 而不是 GQA 的原因。(如果能看到 MLA 和 GQA 之间的「每个 Token 的 KV 缓存」节省比较就好了!)

在我们进入下一个架构组件之前,总结一下本节,MLA 是一个巧妙的技巧,可以减少 KV 缓存内存使用,同时在建模性能方面甚至略微优于 MHA

Mixture-of-Experts

DeepSeek 中另一个值得强调的主要架构组件是其使用 Mixture-of-Experts(MoE)层。虽然 DeepSeek 没有发明 MoE,但今年它又重新流行起来,我们稍后将介绍的许多架构也采用了它。

你可能已经熟悉 MoE,但快速回顾可能会有所帮助。

MoE 的核心思想是用多个专家层替换 Transformer 块中的每个前馈模块,其中每个专家层也是一个前馈模块。这意味着我们将单个前馈块替换为多个前馈块,如下图 5 所示。

图 5:DeepSeek V3/R1 中的 Mixture-of-Experts(MoE)模块(右)与具有标准前馈块的大型语言模型(左)的对比。

Transformer 块内的前馈块(在上图中显示为深灰色块)通常包含模型总参数的大部分。(请注意,Transformer 块以及前馈块在大型语言模型中重复多次;在 DeepSeek V3 的情况下,重复 61 次。)

因此,用_多个_前馈块替换_单个_前馈块(如在 MoE 设置中所做的)会大大增加模型的总参数数量。然而,关键技巧是我们不会为每个 token 使用(「激活」)所有专家。相反,路由器仅为每个 token 选择一小部分专家。(为了节省时间,或者说文章空间,我将在另一时间更详细地介绍路由器。)

因为一次只有少数专家处于活动状态,MoE 模块通常被称为_稀疏_模块,与始终使用完整参数集的_密集_模块相对。然而,通过 MoE 增加的大量总参数增加了大型语言模型的容量,这意味着它可以在训练期间吸收更多知识。不过,稀疏性使推理保持高效,因为我们不会同时使用所有参数。

例如,DeepSeek V3 每个 MoE 模块有 256 个专家,总共有 6710 亿个参数。然而在推理过程中,一次只有 9 个专家处于活动状态(1 个共享专家加上 8 个由路由器选择的专家)。这意味着每个推理步骤仅使用 370 亿个参数,而不是全部 6710 亿个。

DeepSeek V3 的 MoE 设计的一个显著特征是使用共享专家。这是一个始终为每个 token 激活的专家。这个想法并不新鲜,已经在 DeepSeek 2024 MoE 和 2022 DeepSpeedMoE 论文中引入。

图 6:来自「DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models」的注释图,https://arxiv.org/abs/2401.06066

拥有共享专家的好处首先在 DeepSpeedMoE 论文中被提到,他们发现与没有共享专家相比,它提高了整体建模性能。这可能是因为常见或重复的模式不必由多个单独的专家学习,这为它们留出了更多空间来学习更专业的模式。

总而言之,DeepSeek V3 是一个庞大的 6710 亿参数模型,在发布时,它的性能优于其他开源权重模型,包括 4050 亿参数的 LLaMA 3。尽管体积更大,但由于其 Mixture-of-Experts(MoE)架构,它在推理时效率更高,每个 token 仅激活一小部分(仅 370 亿)参数。

另一个关键区别特征是 DeepSeek V3 使用 Multi-Head Latent Attention(MLA)而不是 Grouped-Query Attention(GQA)。MLA 和 GQA 都是标准 Multi-Head Attention(MHA)的推理高效替代方案,特别是在使用 KV 缓存时。虽然 MLA 实现起来更复杂,但 DeepSeek-V2 论文中的一项研究表明,它提供了比 GQA 更好的建模性能。

OLMo 2

非营利组织 Allen Institute for AI 的 OLMo 系列模型因其在训练数据和代码方面的透明度以及相对详细的技术报告而引人注目。

虽然你可能不会在任何基准或排行榜的顶部找到 OLMo 模型,但它们相当干净,更重要的是,由于其透明度,它们是开发大型语言模型的绝佳蓝图。

虽然 OLMo 模型因其透明度而受欢迎,但它们也不算差。事实上,在 1 月份发布时(在 LLaMA 4、Gemma 3 和 Qwen 3 之前),OLMo 2 模型位于计算与性能的帕累托前沿,如下图 7 所示。

图 7:不同大型语言模型的建模基准性能(越高越好)与预训练成本(FLOPs;越低越好)。这是来自 OLMo 2 论文的注释图,https://arxiv.org/abs/2501.00656

如本文前面所述,我的目标是只关注大型语言模型架构细节(不包括训练或数据),以保持在可管理的长度。那么,OLMo2 中有哪些有趣的架构设计选择呢?主要归结为归一化:RMSNorm 层的放置以及 QK-norm 的添加,我将在下面讨论。

另一件值得一提的事情是,OLMo 2 仍然使用传统的 Multi-Head Attention(MHA)而不是 MLA 或 GQA

总体而言,OLMo 2 在很大程度上遵循原始 GPT 模型的架构,类似于其他当代大型语言模型。但是,有一些值得注意的偏差。让我们从归一化层开始。

RMSNorm 的放置

与 LLaMA、Gemma 和大多数其他大型语言模型类似,OLMo 2 从 LayerNorm 切换到 RMSNorm。

但由于 RMSNorm 是旧帽子(它基本上是 LayerNorm 的简化版本,可训练参数更少),我将跳过 RMSNorm 与 LayerNorm 的讨论。(好奇的读者可以在我的 GPT-2 到 LLaMA 转换指南中找到 RMSNorm 代码实现。)

然而,值得讨论的是 RMSNorm 层的放置。原始 Transformer(来自「Attention is all you need」论文)将 Transformer 块中的两个归一化层分别放置在注意力模块和前馈模块_之后_。

这也被称为 Post-LN 或 Post-Norm。

GPT 和之后的大多数其他大型语言模型将归一化层放置在注意力和前馈模块_之前_,这被称为 Pre-LN 或 Pre-Norm。下图显示了 Post-Norm 和 Pre-Norm 之间的比较。

图 8:Post-Norm、Pre-Norm 和 OLMo 2 的 Post-Norm 风格的比较。

在 2020 年,Xiong 等人表明,Pre-LN 在初始化时会产生更良好的梯度。此外,研究人员提到 Pre-LN 甚至可以在没有仔细的学习率预热的情况下良好工作,而这对于 Post-LN 来说是一个关键工具。

现在,我提到这一点的原因是 OLMo 2 采用了一种 Post-LN 形式(但使用 RMSNorm 而不是 LayerNorm,所以我称之为 Post-Norm)。

在 OLMo 2 中,归一化层不是放置在注意力和前馈层之前,而是放置在之后,如上图所示。但是,请注意,与原始 Transformer 架构相比,归一化层仍然在残差层(跳跃连接)内部。

那么,为什么他们要移动归一化层的位置呢?原因是它有助于训练稳定性,如下图所示。

图 9:显示 Pre-Norm(如 GPT-2、LLaMA 3 和许多其他模型)与 OLMo 2 的 Post-Norm 风格的训练稳定性的图表。这是来自 OLMo 2 论文的注释图,https://arxiv.org/abs/2501.00656

不幸的是,这个图表显示了重新排序与 QK-Norm 一起使用的结果,而 QK-Norm 是一个单独的概念。因此,很难判断归一化层重新排序本身贡献了多少。

QK-Norm

由于上一节已经提到了 QK-norm,而我们稍后讨论的其他大型语言模型,如 Gemma 2 和 Gemma 3,也使用 QK-norm,让我们简要讨论一下这是什么。

QK-Norm 本质上是另一个 RMSNorm 层。它被放置在 Multi-Head Attention(MHA)模块内部,并在应用 RoPE 之前应用于查询(q)和键(k)。为了说明这一点,下面是我为 Qwen3 从头实现编写的 Grouped-Query Attention(GQA)层的摘录(GQA 中的 QK-norm 应用与 OLMo 中的 MHA 类似):

class GroupedQueryAttention(nn.Module):    def __init__(        self, d_in, num_heads, num_kv_groups,        head_dim=None, qk_norm=False, dtype=None    ):        # ...
        if qk_norm:            self.q_norm = RMSNorm(head_dim, eps=1e-6)            self.k_norm = RMSNorm(head_dim, eps=1e-6)        else:            self.q_norm = self.k_norm = None
    def forward(self, x, mask, cos, sin):        b, num_tokens, _ = x.shape
        # Apply projections        queries = self.W_query(x)         keys = self.W_key(x)        values = self.W_value(x) 
        # ...
        # Optional normalization        if self.q_norm:            queries = self.q_norm(queries)        if self.k_norm:            keys = self.k_norm(keys)
        # Apply RoPE        queries = apply_rope(queries, cos, sin)        keys = apply_rope(keys, cos, sin)
        # Expand K and V to match number of heads        keys = keys.repeat_interleave(self.group_size, dim=1)        values = values.repeat_interleave(self.group_size, dim=1)
        # Attention        attn_scores = queries @ keys.transpose(23)        # ...

如前所述,QK-Norm 与 Post-Norm 一起稳定了训练。请注意,QK-Norm 不是由 OLMo 2 发明的,而是可以追溯到 2023 年的 Scaling Vision Transformers 论文

简而言之,值得注意的 OLMo 2 架构设计决策主要是 RMSNorm 的放置:RMSNorm 在注意力和前馈模块之后而不是之前(Post-Norm 的一种风格),以及在注意力机制内为查询和键添加 RMSNorm(QK-Norm),这两者共同有助于稳定训练损失。

下面是一个图表,进一步并排比较了 OLMo 2 和 LLaMA 3;正如我们所看到的,除了 OLMo 2 仍然使用传统的 MHA 而不是 GQA 之外,架构在其他方面相对相似。(然而,OLMo 2 团队在 3 个月后发布了一个使用 GQA 的 32B 变体。)

图 10:LLaMA 3 和 OLMo 2 之间的架构比较。

Gemma 3

Google 的 Gemma 模型一直都非常好,我认为与其他流行模型(如 LLaMA 系列)相比,它们一直有点被低估。

Gemma 的一个显著特点是相当大的词汇表大小(以更好地支持多种语言),以及更强调 27B 大小(而不是 8B 或 70B)。但请注意,Gemma 2 也有更小的尺寸:1B、4B 和 12B。

27B 大小达到了一个非常好的平衡点:它比 8B 模型功能强大得多,但不像 70B 模型那样占用大量资源,而且在我的 Mac Mini 上运行得很好。

那么,Gemma 3 还有什么有趣的地方呢?如前所述,其他模型如 DeepSeek V3/R1 使用 Mixture-of-Experts(MoE)架构来减少推理时的内存需求,给定固定的模型大小。(我们稍后将讨论的其他几个模型也使用 MoE 方法。)

Gemma 3 使用不同的「技巧」来降低计算成本,即滑动窗口注意力

通过滑动窗口注意力(最初在 2020 年的 LongFormer 论文中引入,也已被 Gemma 2 使用),Gemma 3 团队能够大幅减少 KV 缓存中的内存需求,如下图所示。

图 11:来自 Gemma 3 论文(https://arxiv.org/abs/2503.19786)的注释图,显示了通过滑动窗口注意力节省的 KV 缓存内存。

那么,什么是滑动窗口注意力?如果我们将常规自注意力视为_全局_注意力机制,因为每个序列元素都可以访问每个其他序列元素,那么我们可以将滑动窗口注意力视为_局部_注意力,因为在这里我们限制了当前查询位置周围的上下文大小。这如下图所示。

图 12:常规注意力(左)和滑动窗口注意力(右)之间的比较。

请注意,滑动窗口注意力可以与 Multi-Head Attention 和 Grouped-Query Attention 一起使用;Gemma 3 使用分组查询注意力

如上所述,滑动窗口注意力也被称为_局部_注意力,因为局部窗口围绕并随当前查询位置移动。相比之下,常规注意力是_全局_的,因为每个 token 都可以访问所有其他 token。

现在,如上所述,Gemma 2 前身架构之前也使用了滑动窗口注意力。Gemma 3 的不同之处在于他们调整了全局(常规)和局部(滑动)注意力之间的比例

例如,Gemma 2 使用混合注意力机制,以 1:1 的比例结合滑动窗口(局部)和全局注意力。每个 token 可以关注 4k token 的附近上下文窗口。

Gemma 2 在每隔一层使用滑动窗口注意力,而 Gemma 3 现在的比例为 5:1,这意味着每 5 个滑动窗口(局部)注意力层只有 1 个完整注意力层;此外,滑动窗口大小从 4096(Gemma 2)减少到仅 1024(Gemma 3)。这将模型的焦点转向更高效、更本地化的计算。

根据他们的消融研究,使用滑动窗口注意力对建模性能的影响很小,如下图所示。

图 13:来自 Gemma 3 论文(https://arxiv.org/abs/2503.19786)的注释图,显示滑动窗口注意力对大型语言模型生成的输出困惑度几乎没有影响。

虽然滑动窗口注意力是 Gemma 3 最显著的架构方面,但作为之前 OLMo 2 部分的后续,我还想简要介绍一下归一化层的放置。

值得强调的一个小但有趣的细节是,Gemma 3 在其分组查询注意力模块周围的 Pre-Norm 和 Post-Norm 设置中都使用 RMSNorm

这与 Gemma 2 类似,但仍然值得强调,因为它不同于(1)原始 Transformer(「Attention is all you need」)中使用的 Post-Norm,(2)GPT-2 普及并在之后的许多其他架构中使用的 Pre-Norm,以及(3)我们之前看到的 OLMo 2 中的 Post-Norm 风格。

图 14:OLMo2 和 Gemma 3 之间的架构比较;请注意 Gemma 3 中的额外归一化层。

我认为这种归一化层放置是一种相对直观的方法,因为它兼得了两全其美:Pre-Norm 和 Post-Norm。在我看来,额外的归一化不会有什么坏处。在最坏的情况下,如果额外的归一化是多余的,这会通过冗余增加一点低效率。在实践中,由于 RMSNorm 在整体方案中相对便宜,这应该不会有任何明显的影响。

Gemma 3 是一个性能良好的开源权重大型语言模型,在我看来,它在开源圈子中有点被低估了。最有趣的部分是使用滑动窗口注意力来提高效率(将来将其与 MoE 结合会很有趣)。

此外,Gemma 3 具有独特的归一化层放置,在注意力和前馈模块之前和之后都放置 RMSNorm 层。

Gemma 3n

在 Gemma 3 发布几个月后,Google 分享了 Gemma 3n,这是一个针对小型设备效率进行优化的 Gemma 3 模型,目标是在手机上运行。

Gemma 3n 为实现更好效率所做的改变之一是所谓的每层嵌入(PLE)参数层。这里的关键思想是只在 GPU 内存中保留模型参数的一个子集。然后根据需要从 CPU 或 SSD 流式传输特定于 token 层的嵌入,例如文本、音频和视觉模态的嵌入。

下图说明了 PLE 内存节省,列出了标准 Gemma 3 模型的 54.4 亿个参数。这可能指的是 Gemma 3 40 亿参数变体。

图 15:来自 Google 的 Gemma 3n 博客(https://developers.googleblog.com/en/introducing-gemma-3n/)的注释图,说明了 PLE 内存节省。

54.4 亿与 40 亿参数的差异是因为 Google 在报告大型语言模型中的参数数量时有一种有趣的方式。他们经常排除嵌入参数以使模型看起来更小,除非在这种情况下,包含它们以使模型看起来更大是方便的。这并不是 Google 独有的,因为这种方法已经成为整个领域的常见做法。

另一个有趣的技巧是 MatFormer 概念(Matryoshka Transformer 的缩写)。例如,Gemma 3n 使用单个共享的大型语言模型(Transformer)架构,可以切片成更小的、可独立使用的模型。每个切片都经过训练以独立运行,因此在推理时,我们可以只运行你需要的部分(而不是大型模型)。

Mistral Small 3.1 24B

Mistral Small 3.1 24B 于 3 月在 Gemma 3 之后不久发布,值得注意的是它在几个基准测试中(数学除外)优于 Gemma 3 27B,同时速度更快。

Mistral Small 3.1 比 Gemma 3 推理延迟更低的原因可能是由于他们的定制分词器,以及缩小 KV 缓存和层数。除此之外,它是一个标准架构,如下图所示。

图 16:Gemma 3 27B 和 Mistral 3.1 Small 24B 之间的架构比较。

有趣的是,早期的 Mistral 模型曾使用滑动窗口注意力,但如果我们考虑官方 Model Hub 配置文件中的默认设置("sliding_window": null),他们似乎在 Mistral Small 3.1 中放弃了它。此外,模型卡也没有提到它。

因此,由于 Mistral 使用常规的 Grouped-Query Attention 而不是像 Gemma 3 中那样带有滑动窗口的 Grouped-Query Attention,也许由于能够使用更优化的代码(即 FlashAttention),会有额外的推理计算节省。例如,我推测虽然滑动窗口注意力减少了内存使用,但它不一定会减少推理延迟,而这正是 Mistral Small 3.1 所关注的。

LLaMA 4

本文前面关于 Mixture-of-Experts(MoE)的广泛介绍再次得到回报。LLaMA 4 也采用了 MoE 方法,并且遵循与 DeepSeek V3 非常相似的相对标准架构,如下图所示。(LLaMA 4 包含原生多模态支持,类似于 Gemma 和 Mistral 等模型。但是,由于本文重点关注语言建模,我们只关注文本模型。)

图 17:DeepSeek V3(6710 亿参数)和 LLaMA 4 Maverick(4000 亿参数)之间的架构比较。

虽然 LLaMA 4 Maverick 架构总体上看起来与 DeepSeek V3 非常相似,但有一些有趣的差异值得强调。

首先,LLaMA 4 使用类似于其前身的 Grouped-Query Attention,而 DeepSeek V3 使用我们在本文开头讨论的 Multi-Head Latent Attention。现在,DeepSeek V3 和 LLaMA 4 Maverick 都是非常大的架构,DeepSeek V3 的总参数数量大约大 68%。然而,DeepSeek V3 拥有 370 亿个活跃参数,是 LLaMA 4 Maverick(170 亿)的两倍多。

LLaMA 4 Maverick 使用更经典的 MoE 设置,专家更少但更大(2 个活跃专家,每个隐藏大小为 8192),而 DeepSeek V3(9 个活跃专家,每个隐藏大小为 2048)。此外,DeepSeek 在每个 Transformer 块中使用 MoE 层(前 3 个除外),而 LLaMA 4 在每隔一个 Transformer 块中交替使用 MoE 和密集模块。

鉴于架构之间的许多细微差异,很难确定它们对最终模型性能的确切影响。然而,主要要点是 MoE 架构在 2025 年人气大增

Qwen3

Qwen 团队始终如一地提供高质量的开源权重大型语言模型。当我在 NeurIPS 2023 帮助共同指导大型语言模型效率挑战时,我记得排名靠前的获胜解决方案都是基于 Qwen2 的。

现在,Qwen3 是另一个热门模型系列,在其大小类别的排行榜上名列前茅。有 7 个密集模型:0.6B、1.7B、4B、8B、14B 和 32B。还有 2 个 MoE 模型:30B-A3B 和 235B-A22B。

(顺便说一句,请注意「Qwen3」中缺少的空格不是拼写错误;我只是试图保留 Qwen 开发人员选择的原始拼写。)

让我们首先讨论密集模型架构。截至撰写本文时,0.6B 模型可能是目前最小的当代开源权重模型。根据我的个人经验,考虑到它的小尺寸,它的性能非常好。如果你计划在本地运行它,它具有出色的 token/秒吞吐量和低内存占用。但更重要的是,由于其小尺寸,它也很容易在本地训练(用于教育目的)。

因此,Qwen3 0.6B 在大多数情况下取代了 LLaMA 3 1B。下面显示了这两种架构之间的比较。

图 18:Qwen3 0.6B 和 LLaMA 3 1B 之间的架构比较;请注意,Qwen3 是一个层数更多的更深架构,而 LLaMA 3 是一个注意力头更多的更宽架构。

如果你对没有外部第三方大型语言模型库依赖的人类可读的 Qwen3 实现感兴趣,我最近从头实现了 Qwen3(在纯 PyTorch 中)

上图中的计算性能数字基于我在 A100 GPU 上运行时从头开始的 PyTorch 实现。正如我们所看到的,Qwen3 的内存占用更小,因为它总体上是一个更小的架构,但也使用更小的隐藏层和更少的注意力头。然而,它使用的 Transformer 块比 LLaMA 3 多,这导致运行时间更慢(token/秒生成速度更低)。

如前所述,Qwen3 还有两种 MoE 风格:30B-A3B 和 235B-A22B。为什么有些架构,如 Qwen3,同时提供常规(密集)和 MoE(稀疏)变体?

如本文开头所述,MoE 变体有助于降低大型基础模型的推理成本。提供密集和 MoE 版本为用户提供了灵活性,具体取决于他们的目标和限制。

密集模型通常更容易在各种硬件上进行微调、部署和优化

另一方面,MoE 模型针对扩展推理进行了优化。例如,在固定的推理预算下,它们可以实现更高的整体模型容量(即由于更大而在训练期间的知识吸收),而不会按比例增加推理成本。

通过发布这两种类型,Qwen3 系列可以支持更广泛的用例:密集模型用于稳健性、简单性和微调,MoE 模型用于大规模高效服务

为了总结本节,让我们将 Qwen3 235B-A22B(请注意 A22B 代表「22B 活跃参数」)与 DeepSeek V3 进行比较,后者的活跃参数几乎是前者的两倍(370 亿)。

图 19:DeepSeek V3 和 Qwen3 235B-A22B 之间的架构比较。

如上图所示,DeepSeek V3 和 Qwen3 235B-A22B 架构非常相似。不过值得注意的是,Qwen3 模型不再使用共享专家(早期的 Qwen 模型,如 Qwen2.5-MoE 确实使用了共享专家)。

不幸的是,Qwen3 团队没有透露为什么他们不再使用共享专家的任何原因。如果我不得不猜测,也许当他们将专家从 2 个(在 Qwen2.5-MoE 中)增加到 8 个(在 Qwen3 中)时,对于他们的设置而言,训练稳定性根本不需要它。然后他们能够通过只使用 8 个而不是 8+1 个专家来节省额外的计算/内存成本。(然而,这并不能解释为什么 DeepSeek V3 仍然保留他们的共享专家。)

更新。Junyang Lin,Qwen3 的开发者之一,回应如下:

当时我们没有发现共享专家有足够显著的改进,我们担心共享专家导致的推理优化问题。诚实地说,这个问题没有直接的答案。

SmolLM3

SmolLM3 也许不像本文介绍的其他大型语言模型那样受欢迎,但我认为它仍然是一个有趣的模型,值得包含在内,因为它在相对较小且方便的 30 亿参数模型大小下提供了非常好的建模性能,介于 1.7B 和 4B Qwen3 模型之间,如下图所示。

此外,它还分享了许多训练细节,类似于 OLMo,这是罕见的,总是值得赞赏的!

图 20:来自 SmolLM3 公告帖子的注释图,https://huggingface.co/blog/smollm3,将 SmolLM3 的胜率与 Qwen3 1.7B 和 4B 以及 LLaMA 3 3B 和 Gemma 3 4B 进行比较。

如下面的架构比较图所示,SmolLM3 架构看起来相当标准。也许最有趣的方面是它使用 NoPE(无位置嵌入)。

图 21:Qwen3 4B 和 SmolLM3 3B 之间的并排架构比较。

NoPE 在大型语言模型背景下是一个较旧的想法,可以追溯到 2023 年的一篇论文(The Impact of Positional Encoding on Length Generalization in Transformers),目的是去除显式位置信息注入(例如通过早期 GPT 架构中的经典绝对位置嵌入层或现在的 RoPE)。

在基于 Transformer 的大型语言模型中,位置编码通常是必要的,因为自注意力独立于顺序处理 token。绝对位置嵌入通过添加一个额外的嵌入层来解决这个问题,该层将信息添加到 token 嵌入中。

图 22:来自我的《从头构建大型语言模型》书(https://www.amazon.com/Build-Large-Language-Model-Scratch/dp/1633437167)的修改图,说明了绝对位置嵌入。

另一方面,RoPE 通过相对于其 token 位置旋转查询和键向量来解决这个问题。

然而,在 NoPE 层中,根本不添加这样的位置信号:不是固定的,不是学习的,不是相对的。什么都没有

即使没有位置嵌入,由于因果注意力掩码,模型仍然知道哪些 token 在前面。此掩码防止每个 token 关注未来的 token。结果,位置 t 的 token 只能看到位置 ≤ t 的 token,这保留了自回归顺序。

因此,虽然没有明确添加位置信息,但模型结构中仍然隐含了方向感,并且大型语言模型在常规的基于梯度下降的训练中,如果发现有利于优化目标,可以学会利用它。(查看 NoPE 论文的定理以获取更多信息。)

因此,总体而言,NoPE 论文不仅发现不需要位置信息注入,而且还发现 NoPE 具有更好的长度泛化能力,这意味着大型语言模型的回答性能随着序列长度的增加而下降得更少,如下图所示。

图 23:来自 NoPE 论文(https://arxiv.org/abs/2305.19466)的注释图,显示了 NoPE 更好的长度泛化能力。

请注意,上面显示的实验是使用大约 1 亿个参数的相对较小的 GPT 风格模型和相对较小的上下文大小进行的。目前尚不清楚这些发现如何推广到更大的当代大型语言模型。

因此,SmolLM3 团队可能仅在每 4 层中「应用」NoPE(或者说省略 RoPE)

Kimi K2

Kimi K2 最近在 AI 社区掀起了巨大波澜,因为它是一个开源权重模型,性能非常出色。根据基准测试,它与 Google 的 Gemini、Anthropic 的 Claude 和 OpenAI 的 ChatGPT 模型等最好的专有模型不相上下。

一个值得注意的方面是它使用相对较新的 Muon 优化器的变体而不是 AdamW。据我所知,这是第一次在这种规模的任何生产模型中使用 Muon 而不是 AdamW之前,它只被证明可以扩展到 16B)。这导致了非常好的训练损失曲线,这可能有助于将该模型推到上述基准的顶部。

虽然人们评论说损失异常平滑(由于缺乏尖峰),但我认为它并不是异常平滑(例如,参见下图中的 OLMo 2 损失曲线;此外,梯度的 L2 范数可能是跟踪训练稳定性的更好指标)。然而,值得注意的是损失曲线下降得有多好。

但是,如本文引言中所述,训练方法是另一个时间的主题。

图 24:来自 Kimi K2 公告博客文章(https://moonshotai.github.io/Kimi-K2/)和 OLMo 2 论文(https://arxiv.org/abs/2305.19466)的注释图。

该模型本身有 1 万亿个参数,这确实令人印象深刻

截至撰写本文时,它可能是这一代最大的大型语言模型(鉴于 LLaMA 4 Behemoth 尚未发布,专有大型语言模型不算,Google 的 1.6 万亿 Switch Transformer 是来自不同世代的编码器-解码器架构的限制)。

它也在回归原点,因为 Kimi K2 使用我们在本文开头介绍的 DeepSeek V3 架构,只是他们使其更大,如下图所示。

图 25.1:DeepSeek V3 和 Kimi K2 之间的架构比较。

如上图所示,Kimi K2 基本上与 DeepSeek V3 相同,只是它在 MoE 模块中使用了更多的专家,在 Multi-head Latent Attention(MLA)模块中使用了更少的头。

Kimi K2 并非凭空出现。Kimi k1.5: Scaling Reinforcement Learning with LLMs 论文中讨论的早期 Kimi 1.5 模型也令人印象深刻。然而,不幸的是,DeepSeek R1 模型论文恰好在 1 月 22 日同一天发布。此外,据我所知,Kimi 1.5 权重从未公开分享过。

因此,Kimi K2 团队很可能吸取了这些教训,并在 DeepSeek R2 发布之前将 Kimi K2 作为开源权重模型分享。截至撰写本文时,Kimi K2 是最令人印象深刻的开源权重模型。

更新: 2025 年 11 月 6 日,Kimi K2 团队还发布了他们的新「Thinking」模型变体。该架构与上面的 Kimi K2 相比没有变化,只是他们将上下文大小从 128k 扩展到 256k。

根据 Kimi 团队分享的基准测试,该模型在某些基准测试上超过了当前领先的专有大型语言模型的性能。(不幸的是,没有与 DeepSeek R1 的直接比较。

图 25.2:DeepSeek R1 与 Kimi K2 Thinking 架构(顶部)以及 Kimi K2 Thinking 基准测试(底部)。

GPT-OSS

OpenAI 发布了 gpt-oss-120b 和 gpt-oss-20b,这是自 2019 年 GPT-2 以来的首批开源权重模型,大约在我写这篇文章后一周。由于 OpenAI 的开源权重模型一直备受期待,我更新了这篇文章以包含它们。我将保持本节简短,但我写了另一篇更详细的专门介绍 gpt-oss 模型的文章:

在总结有趣的细节之前,让我们从两个模型 gpt-oss-20b 和 gpt-oss-120b 的概述开始,如下图 26 所示。

图 26:两个 gpt-oss 模型的架构概述。

看图 26,该架构包含我们之前讨论的其他架构中看到的所有熟悉组件。例如,图 27 将较小的 gpt-oss 架构与 Qwen3 30B-A3B 并列,后者也是一个具有相似数量活跃参数的 MoE 模型(gpt-oss 有 36 亿个活跃参数,Qwen3 30B-A3B 有 33 亿个)。

图 27:gpt-oss 和 Qwen3 之间的架构比较

图 27 中未显示的一个方面是 gpt-oss 使用滑动窗口注意力(类似于 Gemma 3,但在每隔一层而不是使用 5:1 的比例)。

图 27 显示 gpt-oss 和 Qwen3 使用类似的组件。但如果我们仔细观察这两个模型,我们会发现 Qwen3 是一个更深的架构,有 48 个 Transformer 块而不是 24 个。

另一方面,gpt-oss 是一个更宽的架构

  • 嵌入维度为 2880 而不是 2048
  • 中间专家(前馈)投影维度也是 2880 而不是 768

还值得注意的是,gpt-oss 使用的注意力头数是两倍,但这并不会直接增加模型的宽度。宽度由嵌入维度决定。

在固定参数数量的情况下,一种方法是否比另一种方法具有优势?根据经验法则,更深的模型具有更大的灵活性,但由于梯度爆炸和消失的不稳定性问题(RMSNorm 和快捷连接旨在缓解),可能更难训练

更宽的架构具有在推理期间更快(具有更高的 token/秒吞吐量)的优势,因为在更高的内存成本下具有更好的并行化。

当谈到建模性能时,不幸的是,我不知道有什么好的苹果对苹果的比较(保持参数大小和数据集恒定),除了 Gemma 2 论文(表 9)中的消融研究,该研究发现,对于 9B 参数架构,更宽的设置略好于更深的设置。在 4 个基准测试中,更宽的模型获得了 52.0 的平均分数,而更深的模型获得了 50.8 的平均分数。

如上图 27 所示,gpt-oss 的专家数量也出奇地少(32 个而不是 128 个),并且每个 token 仅使用 4 个而不是 8 个活跃专家。然而,每个专家都比 Qwen3 中的专家大得多。

这很有趣,因为最近的趋势和发展指向更多、更小的模型是有益的。这种变化,在恒定的总参数大小下,在 DeepSeekMoE 论文的图 28 中得到了很好的说明。

图 28:来自「DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models」的注释图,https://arxiv.org/abs/2401.06066

值得注意的是,与 DeepSeek 的模型不同,gpt-oss 和 Qwen3 都不使用共享专家

gpt-oss 和 Qwen3 都使用分组查询注意力。主要区别在于,如前所述,gpt-oss 在每第二层通过滑动窗口注意力限制上下文大小。

然而,有一个有趣的细节引起了我的注意。似乎 gpt-oss 对注意力权重使用偏置单元,如下图 29 所示。

图 29:gpt-oss 模型在注意力层中使用偏置单元。请参阅此处的代码示例。

自从 GPT-2 时代以来,我就没有看到过这些偏置单元被使用,它们通常被认为是多余的。事实上,我发现了一篇最近的论文,从数学上表明这至少对于键变换(k_proj)是正确的。此外,实证结果表明,有偏置单元和没有偏置单元之间几乎没有区别(见下图 30)。

图 30:来自 https://arxiv.org/pdf/2302.08626 的表格,显示了从头训练模型时有偏置单元和没有偏置单元的平均测试损失。

你可能注意到的另一个细节是图 30 中代码截图中 sinks 的定义。在一般模型中,注意力槽是放置在序列开头的特殊「始终关注」token,以稳定注意力,这在长上下文场景中特别有用。即,如果上下文变得非常长,这个在开头的特殊关注 token 仍然被关注,并且它可以学习存储一些关于整个序列的通用有用信息。(我认为它最初是在 Efficient Streaming Language Models with Attention Sinks 论文中提出的。)

在 gpt-oss 实现中,_注意力槽_不是输入序列中的实际 token。相反,它们是在附加到注意力分数之前学习的每头偏置 logit(图 31)。目标与上述注意力槽相同,但不修改分词输入。

图 31:gpt-oss 中注意力槽的使用;基于 Hugging Face 代码在这里

有关 gpt-oss 的更多信息,以及它与 GPT-2 的比较,请参阅我的另一篇 gpt-oss 文章:

Grok 2.5

在本文首次上线几周后,xAI 发布了其 2700 亿参数 Grok 2.5 模型的权重。

我认为值得包含在这里,因为 Grok 2.5 是 xAI 去年的旗舰生产模型。到目前为止,我们讨论的所有模型从一开始就作为开源权重模型发布。例如,gpt-oss 可能不是 GPT-4 的开源权重克隆,而是专门为开源社区训练的定制模型。

通过 Grok 2.5,我们难得一窥真正的生产系统,即使它是去年的。

从架构上讲,Grok 2.5 总体上看起来相当标准(图 32),但有一些值得注意的细节。

图 32:Grok 2.5 与类似大小的 Qwen3 模型并列

例如,Grok 2.5 使用少量大型专家(八个),这反映了一个较旧的趋势。如前所述,更新的设计(例如 DeepSeekMoE 论文中的设计)倾向于使用更多数量的较小专家(这也存在于 Qwen3 中)。

另一个有趣的选择是使用相当于共享专家的东西。图 32 左侧显示的额外 SwiGLU 模块充当始终开启的共享专家。它与经典的共享专家设计不完全相同,因为其中间维度加倍,但想法是相同的。(我仍然发现 Qwen3 省略了共享专家很有趣,看看 Qwen4 和更高版本的模型是否会改变这一点将很有趣。)

GLM-4.5

GLM-4.5 是今年的另一个重要版本。

它是一个类似于 Qwen3 的指令/推理混合模型,但更优化用于函数调用和智能体风格的上下文。

图 33:来自官方 GitHub 仓库的 GLM-4.5 基准测试,网址为 https://github.com/zai-org/GLM-4.5

如图 34 所示,GLM-4.5 有两种变体。旗舰 3550 亿参数模型在 12 个基准测试中平均优于 Claude 4 Opus,仅略微落后于 OpenAI 的 o3 和 xAI 的 Grok 4。还有 GLM-4.5-Air,一个更紧凑的 1060 亿参数版本,其性能仅略低于 3550 亿模型。

图 35 将 3550 亿架构与 Qwen3 进行了比较。

图 34:GLM-4.5 与类似大小的 Qwen3 模型并列。

设计在很大程度上相似,但 GLM-4.5 采用了 DeepSeek V3 首次引入的结构选择:3 个密集层位于 Mixture-of-Experts(MoE)块之前。为什么?从几个密集层开始可以提高大型 MoE 系统的收敛稳定性和整体性能。如果立即引入 MoE 路由,稀疏专家选择的不稳定性可能会干扰早期的句法和语义特征提取。因此,可以说保持初始层密集可以确保模型在路由决策开始塑造更高级别处理之前形成稳定的低级表示

此外,GLM-4.5 使用类似于 DeepSeek V3 的共享专家(与 Qwen3 不同)。

(有趣的是,GLM-4.5 还保留了 GPT-2 和 gpt-oss 中使用的注意力偏置机制。)

Qwen3 Next

2025 年 11 月 9 日,Qwen3 团队发布了 Qwen3 Next 80B-A3B(图 35),提供 Instruct 和 Thinking 两种变体。虽然其设计建立在之前讨论的 Qwen3 架构之上,但我在这里将其作为单独的条目,以保持图编号一致,并引起人们对其一些设计变化的注意。

新的 Qwen3 Next 架构之所以引人注目,是因为尽管它比之前的 235B-A22B 模型小 3 倍(图 35),但它引入了四倍多的专家,甚至还添加了一个共享专家。这两种设计选择(高专家数量和包含共享专家)都是我在此版本之前强调的未来方向,特别是在我在顶部链接的文章视频版本中。

图 35:5 月发布的原始 Qwen3 模型(左)与 9 月发布的 Qwen3 Next 模型(右)。

另一个亮点是他们用 Gated DeltaNet + Gated Attention 混合替换了常规注意力机制,这有助于在内存使用方面实现原生 262k token 上下文长度(之前的 235B-A22B 模型原生支持 32k,使用 YaRN 缩放支持 131k。)

那么这个新的注意力混合是如何工作的?与分组查询注意力(GQA)相比,GQA 仍然是标准的缩放点积注意力(跨查询头组共享 K/V 以减少 KV 缓存大小和内存带宽,如前所述,但其解码成本和缓存仍随序列长度增长),他们的混合机制以 3:1 的比例混合 Gated DeltaNet 块和 Gated Attention 块,如图 36 所示。

我们可以将门控注意力块视为可以在 GQA 中使用的标准缩放点积注意力,但它在顶部有一些调整。_门控注意力_和普通 GQA 块之间的主要区别是:

  1. 输出门(sigmoid 控制,通常是每通道),在将注意力结果添加回残差之前缩放它;
  2. 用于 QKNorm 的零中心 RMSNorm,而不是标准 RMSNorm;
  3. 部分 RoPE(在维度的子集上)。

请注意,这些本质上只是对 GQA 的稳定性更改。

Gated DeltaNet 是一个更重要的改变。在 DeltaNet 块中,q、k、v 和两个门(α、β)由线性和轻量级卷积层与归一化产生,该层用快速权重_增量规则_更新替换注意力。

然而,权衡是 DeltaNet 提供的基于内容的检索精度低于完全注意力,这就是为什么保留一个门控注意力层的原因。

鉴于注意力呈二次增长,添加 DeltaNet 组件是为了帮助提高内存效率。在「线性时间、无缓存」系列中,DeltaNet 块本质上是 Mamba 的替代品。Mamba 使用学习的状态空间过滤器(本质上是随时间动态卷积)保持状态。DeltaNet 保持一个用 α 和 β 更新的微小快速权重内存,并用 q 读取它,小卷积仅用于帮助形成 q、k、v、α、β。

上面的两个小节描述了两个面向效率的设计决策。由于所有好事都是三件一组的,Qwen3 在此基础上又增加了另一种技术Multi-Token Prediction(MTP)。

多 token 预测训练大型语言模型在每个步骤预测多个未来 token,而不是单个 token。在这里,在每个位置 t,小型额外头(线性层)输出 t+1...t+k 的 logit,我们对这些偏移求交叉熵损失的总和(在 MTP 论文中,研究人员建议 k=4)。这个额外的信号加快了训练速度,推理可能仍然是一次生成一个 token。然而,额外的头可以用于推测性多 token 解码,这是 Qwen3-Next 似乎所做的,但是,细节仍然有点稀疏:

Qwen3-Next 引入了原生的 Multi-Token Prediction(MTP)机制,它不仅产生了一个用于推测解码的高接受率的 MTP 模块,而且还增强了整体性能。此外,Qwen3-Next 专门优化了 MTP 的多步推理性能,通过保持训练和推理之间一致性的多步训练进一步提高了推测解码在实际场景中的接受率。来源:Qwen3-Next 博客文章

最近,开源权重大型语言模型开发者分享了针对效率优化的核心架构风格。一个例子是 Qwen3-Next(见上一节),它用快速门控 DeltaNet 模块替换了一些完全注意力块。另一个例子是 DeepSeek V3.2,它使用稀疏注意力,这是一种线性注意力变体,以改进的计算性能换取一些建模性能(我计划在即将发表的文章中更详细地介绍这种机制)。

现在,MiniMax-M1 属于与上述模型类似的类别,因为它使用线性注意力变体(lightning attention),该变体比常规(完全)注意力提供了改进的效率。我最初没有介绍 MiniMax M1,因为它不像这里讨论的其他一些模型那样受欢迎。然而,他们新的 MiniMax-M2 版本目前被认为是最好的开源权重模型(根据基准性能),这使得它太重要而不能忽视。

图 37:MiniMax-M2 基准性能与其他流行的开源权重和专有大型语言模型的比较。图片来自官方模型中心发布的 readme 文件。

如下面的概览图所示,我将 MiniMax-M2 与其他解码器风格的 Transformer 大型语言模型分组,因为它没有使用 MiniMax-M1 中提出的高效 lightning attention 变体。相反,开发人员回到使用完全注意力,可能是为了提高建模(和基准)性能。

图 38:本文介绍的主要大型语言模型的时间表,旁边是一些注意力混合模型,它们构成了更高效的替代方案,用一些建模性能换取改进的效率。

总体而言,MiniMax-M2 与 Qwen3 惊人地相似。除了更改层数、大小等之外,它总体上使用相同的组件。

也许这里唯一值得注意的亮点是 MiniMax-M2 使用所谓的「per_layer」QK-Norm 而不是常规 QK-Norm。仔细查看代码发现它在注意力机制内部是这样实现的:

self.q_norm = MiniMaxText01RMSNormTP(self.head_dim * self.total_num_heads, eps=...)
self.k_norm = MiniMaxText01RMSNormTP(self.head_dim * self.total_num_kv_heads, eps=...)

这里,hidden_size 等于连接的头(num_heads * head_dim),因此 RMSNorm 具有一个缩放向量,每个头(以及每个头维度)都有不同的参数。

因此,「per_layer」意味着 RMSNorm(用于如前所述的 QK-Norm)在每个 Transformer 块中定义(如常规 QK-Norm 中),但此外,它不是跨注意力头重用,而是每个注意力头都有唯一的 QK-Norm。

模型配置文件还包括滑动窗口注意力设置(类似于第 3 节中的 Gemma 3),但如 Mistral 3.1(在第 4 节中讨论)中一样,它默认被禁用。

除了每层 QK-Norm 之外,该架构与 Qwen3 非常相似,如下图所示。

图 39:Qwen3 和 MiniMax-M2 之间的比较。

其他有趣的细节,如上图所示,包括他们不使用共享专家(类似于 Qwen3 但与 Qwen3-Next 不同)。如前所述,在我看来,共享专家是有用的,因为它们减少了其他专家之间的冗余。

此外,从上图可以明显看出,MiniMax-M2 的「稀疏性」是 Qwen3 的两倍。即,在与 Qwen3 235B-A22B 大致相同的大小下,MiniMax-M2 每个 token 只有 100 亿个而不是 220 亿个活跃专家(也就是说,在 MiniMax-M2 中,每个推理步骤使用 4.37% 的参数,而 Qwen3 使用 9.36% 的活跃 token)。

最后,与 MiniMax-M1 类似,MiniMax-M2 在注意力模块内部使用「部分」而不是常规 RoPE 来编码位置信息。与常规 RoPE 类似,旋转在应用 QK-Norm 后应用于查询和键。

这里的部分 RoPE 意味着只有每个头的前 rotary_dim 通道获得旋转位置编码,其余的 head_dim - rotary_dim 通道保持不变

在官方 M1 README 文件中,开发人员提到

旋转位置嵌入(RoPE)应用于注意力头维度的一半,基频为 10,000,000

我们可以将其描绘如下:

完全 RoPE:     [r r r r r r r r]部分 RoPE:     [r r r r — — — —]

其中在上面的概念性说明中,「r」显示旋转(位置编码)维度,破折号是未触及的维度。

这样做的意义是什么?在 M1 论文中,开发人员表示

……在 softmax 注意力维度的一半上实现 RoPE 可以实现长度外推,而不会降低性能。

我的推测是,这可以防止对长序列进行「太多」旋转,尤其是那些比训练数据集中最长文档更长的序列。即,这里的理由可能是没有旋转比模型在训练中从未见过的「坏」或「太极端」的旋转要好。

线性注意力的复兴

最近线性注意力机制有所复兴,以提高大型语言模型的效率。

「Attention Is All You Need」论文(2017)中引入的注意力机制,也称为缩放点积注意力,仍然是当今大型语言模型中最流行的注意力变体。除了传统的多头注意力之外,它还用于更高效的风格,如分组查询注意力、滑动窗口注意力和多头潜在注意力。

原始注意力机制随序列长度呈二次缩放:

这是因为查询(Q)、键(K)和值(V)是 n 乘 d 矩阵,其中 d 是嵌入维度(超参数),n 是序列长度(即 token 数量)。

你可以在我的另一篇文章中找到有关注意力的更多详细信息:

图 40:由于序列长度 n,注意力中二次成本的说明。

线性注意力变体已经存在很长时间了,我记得在 2020 年代看到过大量论文。例如,我记得最早的一个是 2020 年的 Transformers are RNNs: Fast Autoregressive Transformers with Linear Attention 论文,研究人员在其中近似注意力机制:

这里,φ(·) 是核特征函数,设置为 φ(x) = elu(x) + 1。

这种近似是高效的,因为它避免了显式计算 n × n 注意力矩阵 QK^T。而不是执行所有成对 token 交互(其成本为 O(n^2d) 时间和内存)。

我不想在这些较旧的尝试上停留太久。但底线是它们将时间和内存复杂度从 O(n^2) 降低到 O(n),使注意力对于长序列更加高效。

然而,它们从未真正获得关注,因为它们降低了模型精度,而且我从未真正看到这些变体中的一个应用于开源权重的最先进大型语言模型中。

在今年下半年,线性注意力变体有所复兴。第一个值得注意的模型是 MiniMax-M1,具有 lightning attention,这是一个 4560 亿参数的 Mixture-of-Experts(MoE)模型,具有 460 亿个活跃参数,于 6 月推出。

然后,在 8 月,Qwen3 团队跟进了我在上面更详细讨论过的 Qwen3-Next。然后,在 9 月,DeepSeek 团队宣布了 DeepSeek V3.2。所有三个模型(MiniMax-M1、Qwen3-Next、DeepSeek V3.2)都用高效的线性变体替换了它们大部分或所有层中的传统二次注意力变体。

有趣的是,最近出现了一个情节转折,MiniMax 团队发布了他们新的 2300 亿参数 M2 模型(在第 13 节中讨论),没有线性注意力,回到常规注意力。该团队表示,线性注意力在生产大型语言模型中很棘手。它似乎在常规提示下工作正常,但在推理和多轮任务中精度较差,这对于常规聊天会话以及智能体应用不仅很重要。

这可能是一个转折点,线性注意力可能毕竟不值得追求。然而,事情变得更有趣了。在 10 月,Kimi 团队发布了他们新的具有线性注意力的 Kimi Linear 模型。

图 41:线性注意力混合架构的概述。

旁注:我本可以将 Qwen3-Next 和 Kimi Linear 与概览图中的其他 Transformer-状态空间模型(SSM)混合体分组。就我个人而言,我将这些其他 Transformer-SSM 混合体视为带有 Transformer 组件的 SSM,而我将这里讨论的模型(Qwen3-Next 和 Kimi Linear)视为带有 SSM 组件的 Transformer。但是,由于我在 Transformer-SSM 框中列出了 IBM Granite 4.0 和 NVIDIA Nemotron Nano 2,因此可以争辩将它们放入一个类别。

Kimi Linear 与 Qwen3-Next 有几个结构相似之处。两个模型都依赖于混合注意力策略。具体来说,它们将轻量级线性注意力与更重的完全注意力层相结合。具体来说,两者都使用 3:1 的比例,这意味着每三个使用线性 Gated DeltaNet 变体的 Transformer 块,就有一个使用完全注意力的块,如下图所示。

图 42:Qwen3-Next 和 Kimi Linear 并排。

Gated DeltaNet 是一种线性注意力变体,其灵感来自循环神经网络,包括来自 Gated Delta Networks: Improving Mamba2 with Delta Rule 论文的门控机制。从某种意义上说,Gated DeltaNet 是一个具有 Mamba 风格门控的 DeltaNet,而 DeltaNet 是一种线性注意力机制。由于本文的概述性质,DeltaNet 将来会是一个很好的单独文章的主题。

请注意,上图中 Kimi Linear 部分省略 RoPE 框是故意的。Kimi 在多头潜在注意力 MLA)层(全局注意力)中应用 NoPE(无位置嵌入)。正如作者所说,这让 MLA 在推理时作为纯多查询注意力运行,并避免了长上下文缩放的 RoPE 重新调整(位置偏差据称由 Kimi Delta Attention 块处理)。有关 MLA 和多查询注意力(这是分组查询注意力的特例)的更多信息,请参阅我的大型语言模型架构大比拼文章。

此外,我已经在这里写了更多关于 Gated DeltaNet 的内容。

Kimi Linear 通过 Kimi Delta Attention(KDA)机制修改了 Qwen3-Next 的线性注意力机制,这本质上是 Gated DeltaNet 的改进。而 Qwen3-Next 应用标量门(每个注意力头一个值)来控制内存衰减率,Kimi Linear 将其替换为每个特征维度的通道式门控。根据作者的说法,这提供了对内存的更多控制,这反过来又改善了长上下文推理。

此外,对于完全注意力层,Kimi Linear 用 Multi-Head Latent Attention(MLA)替换了 Qwen3-Next 的门控注意力层(本质上是带有输出门控的标准多头注意力层)。这是我们之前在 DeepSeek V3/R1 部分讨论的相同 MLA 机制,但有一个额外的门。(回顾一下,MLA 压缩键/值空间以减少 KV 缓存大小。)

没有与 Qwen3-Next 的直接比较,但与来自 Gated DeltaNet 论文的 Gated DeltaNet-H1 模型(本质上是带有滑动窗口注意力的 Gated DeltaNet)相比,Kimi Linear 实现了更高的建模精度,同时保持相同的 token 生成速度。

图 43:来自 Kimi Linear 论文的注释图,显示 Kimi Linear 与 GatedDeltaNet 一样快,并且比具有多头潜在注意力(如 DeepSeek V3/R1)的架构快得多,同时具有更高的基准性能。

此外,根据 DeepSeek-V2 论文中的消融研究,当仔细选择超参数时,MLA 与常规完全注意力不相上下。

Kimi Linear 在长上下文和推理基准测试中与 MLA 相比表现良好,这一事实再次使线性注意力变体对更大的最先进模型很有希望。话虽如此,Kimi Linear 是 480 亿参数大,但它比 Kimi K2 小 20 倍。看看 Kimi 团队是否会在即将推出的 K3 模型中采用这种方法将很有趣。

Olmo 3

Allen AI 于 11 月 20 日发布了他们新的 Olmo 3 7B 和 32B 模型。(官方拼写从 OLMo 改为 Olmo,因此我将在本节中采用该拼写。)

如前所述,Olmo 模型总是很有趣,因为它们是完全开源的。在这里,这意味着该团队还分享详细的训练报告、多个检查点、有关训练数据的信息等。换句话说,Olmo 模型是完全透明的。

这次,Olmo 套件还提供了额外的推理模型风格(在基础和指令模型旁边),Olmo 3 的技术报告中有很多关于训练的有趣细节。但是,由于这是一篇关于架构比较的文章,因此本节仅关注 Olmo 3 的架构。

与 Olmo 3 比较的最接近的模型是 Qwen3,因为 Qwen3 系列有两个类似大小的模型,并且 Qwen3 模型具有类似的性能。

首先,让我们看看两者中较小的一个,Olmo 3 7B。

图 44:Olmo 3 7B 和 Qwen3 8B 并排。

正如我们所看到的,Olmo 3 架构与 Qwen3 相对相似。然而,值得注意的是,这本质上可能受到 Olmo 2 前身的启发,而不是 Qwen3。

与 Olmo 2 类似,Olmo 3 仍然使用后归一化而不是前归一化,因为他们在 Olmo 2 论文中发现它稳定了训练。

有趣的是,7B 模型仍然使用类似于 Olmo 2 的多头注意力。但是,为了提高效率并缩小 KV 缓存大小,他们现在使用滑动窗口注意力(例如,类似于 Gemma 3)。

接下来,让我们看看 32B 模型。

图 45:Olmo 3 32B 和 Qwen3 32B 并排。

总体而言,它是相同的架构,只是放大了。此外,比例(例如,从前馈层的输入到中间大小,等等)大致与 Qwen3 中的比例匹配。

我的猜测是,由于词汇量较小,该架构最初比 Qwen3 小一些,然后他们将中间大小扩展从 Qwen 3 中的 5 倍扩展到 Olmo 3 中的 5.4 倍,以获得 32B 模型进行直接比较。

另外,请注意,32B 模型使用分组查询注意力。

也许最后一个小细节是 Olmo 3 使用 YaRN 进行上下文扩展以支持 64k 的上下文长度,但仅适用于全局(非滑动窗口注意力)层。(YaRN 本质上是一种仔细的 RoPE 重新缩放技术,它有助于在长上下文大小下更好地保留模型质量。)

在 Qwen3 中,YaRN 是可选的,可以将原生上下文从 32k token 扩展到 131k token。

如果你对其他架构细节感兴趣,我在这里的独立笔记本中从头实现了 Olmo 3。

DeepSeek V3.2

本文从 2024 年 12 月发布的 DeepSeek V3 开始。那时有多个 DeepSeek 版本,但我基本上跳过了它们,因为它们不是像 DeepSeek V3 和 DeepSeek R1 那样的大型旗舰模型版本。

图 47:自 DeepSeek V3 以来 DeepSeek 模型发布的时间表。主要模型以红色显示。

然而,DeepSeek V3.2 是一个真正的大版本,因为它在某些基准测试上与当前的 GPT-5.1 和 Gemini 3.0 Pro 模型不相上下。

该架构总体上与 DeepSeek V3 类似,但他们添加了稀疏注意力机制以提高效率。

图 48:具有多头潜在和稀疏注意力的 DeepSeek 模型架构。

我最初计划为本文撰写关于 DeepSeek V3.2 的简短部分,但它变成了一篇超过 5000 字的文章,因此我将其移至一篇单独的文章,我在下面链接:

Mistral 3

2025 年 12 月 2 日,即 DeepSeek V3.2 发布后一天,Mistral 团队发布了他们新的 Mistral 3 模型套件。这包括三个较小的密集模型(3B、8B 和 14B),名称为 Ministral 3,以及他们新的 Mistral 3 Large 旗舰模型,这是一个 6750 亿参数的 MoE(410 亿个参数活跃)。更具体地说,Mistral 3 Large 模型由以下部分组成:

  • 一个具有 6730 亿个参数和 390 亿个活跃参数的 MoE 语言模型
  • 一个 25 亿参数的视觉编码器

(由于本文关注大型语言模型方面,我们将在本节中忽略视觉编码器。我也许应该在某个时候更新我的多模态大型语言模型文章。)

首先,有趣的是,这是 Mistral 自 2023 年 Mixtral 以来的第一个 MoE(在本文前面,我写道 Mistral 放弃了 MoE,去年的 DeepSeek V3 开启了 MoE 复兴)。

发布博客文章说所有模型大小都有基础、指令和推理变体,这很好。但是,他们 6750 亿模型的推理版本尚不可用。

另一个有趣的细节是,根据他们的公告,Mistral 在这里与 NVIDIA 合作优化了 Blackwell 芯片上的 token/秒吞吐量。这很好,因为这意味着 Ministral 模型在我的小 DGX Spark 上会比类似模型运行得快一点(我还得测试一下)。

除了 Mistral 3 的 token/秒速度优势之外,基于质量基准,他们的较小模型 Ministral 看起来与 Qwen3 不相上下。更大的旗舰模型与 DeepSeek V3.1 不相上下。

由于 Mistral 3 的发布只是在 DeepSeek V3.2 发布后一天,他们没有在文章中包含任何 V3.2 比较(除了 LMArena Elo 分数,DeepSeek V3.2 以 1423 对 1418 略微领先)。

不幸的是,现在不可能进行苹果对苹果的比较,因为 Mistral 3 Large 目前没有推理模型,并且 DeepSeek V3.2 没有分享他们非思考模式的基准结果,但如果你好奇,我将 DeepSeek V3.2-Thinking 数字(来自 DeepSeek V3.2 报告)与 Mistral 3 Large 基准图表叠加在一起。

看看 Mistral Large 3 Instruct 模型旁边的 DeepSeek V3.2-Thinking 模型(数字来自 DeepSeek V3.2 论文),V3.2-Thinking 模型显然要好得多。因此,我保持关注 Mistral 3 Large Thinking 的发布,并期待看到更新的图表!

所以,现在,我会说,由于优化,Mistral 3 Large 是成本效益高、低延迟部署的绝佳选择。如果你想最大化答案质量,DeepSeek V3.2-Thinking 很棒。Mistral 3 Large 的另一个卖点是它也提供多模态支持(DeepSeek V3.2 仅支持文本)。

顺便说一句,我在本节中关注 DeepSeek V3.2 是因为这些模型发布得如此接近,彼此相差一天。此外,它们的大小几乎相同,6710 亿和 6730 亿,这使得比较很有趣!

不幸的是,没有包含有关模型开发的更多信息的技术报告。但是,由于它是一个开源权重模型,我们在 Hugging Face hub 上有模型权重可供分析。因此,让我们仔细看看 Mistral 3 Large。

事实证明,Mistral 3 Large 与 DeepSeek V3 和 V3.1 的架构完全相同!唯一的区别是他们将专家的大小增加了 2 倍,同时将专家的数量减少了相同的因子。

DeepSeek V3 和 Mistral 3 Large 并排。

然而,虽然它实际上是相同的架构,但 Mistral 团队很可能从头开始训练 Mistral 3,而不是从 DeepSeek V3 初始化它并进一步训练它,因为 Mistral 使用自己的分词器。

在 Kimi K2 旁边,Mistral 3 现在是第二个使用 DeepSeek V3 架构的模型系列。然而,Kimi K2 团队将模型大小从 6710 亿扩展到 1 万亿,Mistral 3 团队只改变了专家大小比例,并为多模态支持添加了视觉编码器。但是,是的,为什么不呢?我认为 DeepSeek V3 是一个非常坚实的架构设计,此外,它具有这些很好的 MoE 和 MLA 效率方面。那么,为什么要改变没有破损的东西呢?如今,很多秘密酱料都在训练流程以及推理缩放策略中。

这些年后,大型语言模型的发布仍然令人兴奋,我很好奇接下来会是什么!

这本杂志是一个个人激情项目,你的支持有助于保持它的活力。

如果你想支持我的工作,请考虑我的《从头构建大型语言模型》书或其后续作品《从头构建推理模型》。(我相信你会从这些书中得到很多收获;它们深入解释了大型语言模型的工作原理,这是你在其他地方找不到的。)

感谢阅读,并感谢帮助支持独立研究!

如果你读了这本书并有几分钟的时间,我会非常感谢简短的评论。它对我们作者帮助很大!

你的支持意义重大!谢谢!




相关链接:

  • 原文链接:https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison
  • Sebastian Raschka 的书《Build a Large Language Model From Scratch》:https://amzn.to/4fqvn0D
  • 《Build a Reasoning Model From Scratch》:https://mng.bz/Nwr7

这次的 Anthropic,把自己给曝光了。

这家推出 Claude 的公司,刚刚发布了一份报告,调查了 132 名内部工程师,进行了 53 场深度访谈,还分析了 20 万条 Claude Code 的使用记录——就是想搞清楚 AI 到底是怎么改变他们自己的工作的。

结果嘛,有点像照镜子:既看到了希望,也看到了隐忧。

生产力确实涨了

工程师们自报的数据是这样的:一年前,他们在 28% 的工作中使用 Claude,获得 20% 的生产力提升;现在,他们在 59% 的工作中使用 Claude,生产力提升了 50%。

这意味着,一年之内,使用率和生产力提升都翻了不止一倍。

而且这不是「干得更快」,而是「干得更多」——调查显示,大多数任务类别的时间消耗略微减少,但产出量却大幅增加。

而有意思的是,27% 的 Claude 辅助工作,是以前根本不会去做的事情。比如做一些「有了更好,没有也行」的小工具、交互式数据看板、或者手动做起来不划算的探索性工作。

大家都变「全栈」了

Claude 正在模糊专业的边界。

后端工程师开始写前端界面,研究人员开始做数据可视化,甚至非技术人员也在用 Claude 做数据分析和解决 Git 问题。

一位后端工程师说,他用 Claude 做了一个复杂的 UI,设计师看了都惊了:「等等,这是你做的?」他回答说:「不,是 Claude 做的——我只是提需求。

从 Claude Code 的使用数据也能看出来:

六个月前,Claude 平均连续执行 10 个动作就需要人类介入;现在,它可以连续执行 20 个动作,处理更复杂的工作流程,需要人类干预的频率更低了。

但,技能会生锈吗?

能力边界扩展的同时,一些工程师开始担心另一个问题:自己的核心技能会不会退化?

有人说:「以前自己去 debug 一个难题,会花时间读文档、读代码——这些东西虽然和问题本身没有直接关系,但你在这个过程中建立了对整个系统的理解。现在 Claude 可以直接带你到问题所在,这种『顺带学习』的机会就少了很多。」

还有人提到了一个悖论:有效使用 Claude 需要监督能力,而监督 Claude 需要的正是那些可能因为过度依赖 AI 而退化的编程技能。

一位资深工程师说,如果自己是刚入行的新人,会更担心这个问题:「我主要在那些我已经知道答案应该是什么样的任务上使用 AI。这种判断力是靠『笨办法』练出来的……但如果我还是个新人,我觉得需要非常刻意地去锻炼自己的能力,而不是盲目接受模型输出。」

有人开心,有人怀念

工程师们对这种变化的感受分歧很大

有人觉得是解放:「我以为我真的很喜欢写代码,结果发现,我喜欢的其实是写代码能带来的东西。」

有人则有些怀念:「整天提示 Claude 并不那么有趣或有成就感。自己戴上耳机、进入心流状态、亲手实现一个东西,那种感觉要好多了。」

还有人直接接受了这个 trade-off:「确实有些东西我会怀念——比如重构代码时进入那种禅定般的心流状态。但我现在生产力高了太多,这点代价我愿意付。」

同事之间的互动变少了

Anthropic(@AnthropicAI) 引用了一位员工的话:

我喜欢和人一起工作,现在「需要」他们的时候变少了,这让我有点难过。

这是调查中一个明显的主题:Claude 成了大家遇到问题时的第一选择,而不是同事。

有人觉得这样挺好:「我不用担心占用同事的时间了。」

但也有人不喜欢这种变化:「我真的不喜欢大家遇到问题就说『你问过 Claude 了吗?』我非常珍视和人面对面工作的机会。」

传统的导师制度也在受到冲击。一位资深工程师说:「现在初级员工不太来问我问题了,虽然他们的问题确实解决得更快、学得也更快,但这让我有点难过。

未来会怎样?

很多工程师说,自己的角色正在从「写代码的人」变成「管理 AI 的人」。

有人估计自己 70% 以上的工作已经从「写新代码」变成了「审代码和改代码」;有人已经在同时运行好几个 Claude 实例,并且预见未来自己要对 1 个、5 个、甚至 100 个 Claude 的工作负责。

但对于更长远的未来,不确定性是普遍的

有人说:「短期我很乐观,但长期来看,我觉得 AI 最终会做所有事情,让我和很多人变得无关紧要。

有人更直接:「感觉每天上班就是在让自己失业。

也有人更乐观:「我担心初级开发者,但我也知道初级开发者往往是对新技术最渴望的群体。总体来说,我对这个职业的发展方向感到乐观。

但更多人承认:「没人知道会发生什么……重要的是保持适应力。

接下来的打算

Anthropic 表示,他们正在和内部的工程师、研究人员、管理层讨论如何应对这些机遇和挑战,包括如何促进团队协作、如何支持职业发展、如何建立 AI 辅助工作的最佳实践。

他们也在把这项研究扩展到工程师之外的更多员工群体,并计划在 2026 年分享更具体的方案。

用他们自己的话说:

Anthropic 是一个「负责任的职场转型实验室」,不仅要研究 AI 如何改变工作,还要试验如何周全地应对这种转型,从自己开始。

原文:

How AI is transforming work at Anthropic

2025年12月3日

AI如何改变Anthropic的工作方式

URL来源:https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic

AI如何改变我们的工作方式?我们之前的研究关注AI的经济影响,涵盖了整个劳动力市场的各种不同工作。但如果我们更详细地研究一些最早采用AI技术的人——也就是我们自己——会怎样呢?

将镜头对准内部,2025年8月我们调查了132名Anthropic工程师和研究人员,进行了53次深入的定性访谈,并研究了内部Claude Code使用数据,以了解AI使用如何改变Anthropic的工作。我们发现AI的使用正在根本性地改变软件开发人员的工作性质,既带来希望也带来担忧。

我们的研究揭示了一个正在经历重大转型的工作场所:工程师完成了更多工作,变得更加"全栈"(能够胜任超出其正常专业领域的任务),加快了学习和迭代速度,并处理了以前被忽视的任务。这种广度的扩展也让人们思考权衡问题——一些人担心这可能意味着失去更深层的技术能力,或变得不太能够有效地监督Claude的输出,而另一些人则拥抱这个机会,以更广阔和更高层次的方式思考。一些人发现更多的AI协作意味着他们与同事的协作减少了;一些人想知道他们是否最终会让自己失业。

我们认识到,研究AI在一家构建AI的公司的影响意味着代表一个特权地位——我们的工程师可以早期访问尖端工具,在一个相对稳定的领域工作,并且他们自己也在为影响其他行业的AI转型做出贡献。尽管如此,我们认为研究和发布这些发现总体上是有用的,因为Anthropic内部工程师正在发生的事情可能仍然是更广泛社会转型的启示性预兆。我们的发现暗示了一些可能需要跨行业早期关注的挑战和考虑因素(尽管请参阅附录中的局限性部分了解注意事项)。在收集这些数据时,Claude Sonnet 4和Claude Opus 4是最强大的可用模型,而能力还在继续提升。

更强大的AI带来了生产力收益,但也提出了关于保持技术专长、保留有意义的协作以及为可能需要在AI增强工作场所中采用新的学习、指导和职业发展方法的不确定未来做准备的问题。我们在下面的"展望未来"部分讨论了我们正在采取的一些初步步骤来在内部探索这些问题。我们还在最近的博客文章中探讨了潜在的政策应对措施,关于AI相关经济政策的想法

主要发现

在本节中,我们简要总结了调查、访谈和Claude Code数据的发现。我们在下面的后续章节中提供详细的发现、方法和注意事项。

调查数据

  1. Anthropic工程师和研究人员最常使用Claude修复代码错误和了解代码库调试和代码理解是最常见的用途(图1)。
  2. 人们报告Claude使用量增加和生产力提升。员工自我报告在60%的工作中使用Claude,实现了50%的生产力提升,比去年同期增加了2-3倍。这种生产力表现为每个任务类别的时间略有减少,但输出量显著增加(图2)。
  3. 27%的Claude辅助工作包括原本不会完成的任务例如扩展项目、制作好用但非必需的工具(如交互式数据仪表板)以及如果手动完成不具成本效益的探索性工作。
  4. 大多数员工频繁使用Claude,同时报告他们只能"完全委托"0-20%的工作给它。Claude是一个持续的合作者,但使用它通常涉及主动监督和验证,尤其是在高风险工作中——而不是完全不需要验证就交出任务。

定性访谈

  1. 员工正在培养AI委托的直觉。工程师倾向于委托容易验证的任务,即他们"可以相对容易地嗅探正确性"的任务、低风险的任务(例如"一次性调试或研究代码")或无聊的任务("我越兴奋做这个任务,就越不可能使用Claude")。许多人描述了一个信任进展过程,从简单任务开始,逐渐委托更复杂的工作——虽然他们目前保留大多数设计或"品味"任务,但随着模型改进,这个界限正在重新协商。
  2. 技能集正在扩展到更多领域,但有些人的练习在减少。Claude使人们能够将技能扩展到软件工程的更多领域("我可以非常胜任地处理前端或事务性数据库...而以前我会害怕触碰这些东西"),但一些员工也担心,矛盾的是,编写和批评代码所需的更深层技能可能会退化——"当产生输出如此容易和快速时,真正花时间学习东西变得越来越困难。"
  3. 与编码工艺的关系发生变化。一些工程师拥抱AI辅助并专注于结果("我以为我真的喜欢写代码,但我认为我实际上只是喜欢从写代码中得到的东西");其他人说"我确实怀念[写代码]的某些部分。"
  4. 工作场所的社交动态可能正在改变。Claude现在是以前会问同事的问题的第一站——一些人因此报告指导和协作机会减少。("我喜欢与人一起工作,我现在'需要'他们的次数减少了,这很令人难过...初级员工不像以前那样经常来问我问题。")
  5. 职业演变和不确定性。工程师报告转向管理AI系统的更高级别工作,并报告显著的生产力提升。然而,这些变化也引发了关于软件工程作为一种职业的长期轨迹的问题。一些人对未来表达了矛盾的感受:"我对短期感到乐观,但从长期来看,我认为AI最终会做所有事情,让我和许多其他人变得无关紧要。"其他人强调真正的不确定性,只是说"很难说"他们的角色在几年后会是什么样子。

Claude Code使用趋势

  1. Claude正在更自主地处理越来越复杂的任务六个月前,Claude Code会在需要人类输入之前自行完成约10个操作。现在,它通常处理约20个操作,需要更少的人类引导来完成更复杂的工作流程(图3)。工程师越来越多地将Claude用于复杂任务,如代码设计/规划(从1%增加到10%的使用率)和实现新功能(从14%增加到37%)(图4)。
  2. Claude修复了很多"小麻烦"。8.6%的Claude Code任务涉及修复改善生活质量的小问题,比如为了可维护性重构代码(即"修复小麻烦"),人们说这些通常会被降低优先级。这些小修复可能累积成更大的生产力和效率收益。
  3. 每个人都变得更加"全栈"。不同团队以不同方式使用Claude,通常是为了增强他们的核心专业知识——安全团队用它来分析不熟悉的代码,对齐与安全团队用它来构建数据的前端可视化,等等(图5)。

调查数据

我们调查了来自整个组织的132名Anthropic工程师和研究人员关于他们的Claude使用情况,以更好地了解他们日常如何使用它。我们通过内部沟通渠道和直接联系代表研究和产品职能的不同团队的员工来分发调查。我们在附录中包含了局限性部分,提供了更多方法论细节,我们正在分享我们的调查问题,以便其他人可以评估我们的方法并将其调整用于自己的研究。

人们将Claude用于什么编码任务?

我们要求被调查的工程师和研究人员评估他们多久使用Claude进行各种类型的编码任务,例如"调试"(使用Claude帮助修复代码中的错误)、"代码理解"(让Claude解释现有代码以帮助用户理解代码库)、"重构"(使用Claude帮助重组现有代码)和"数据科学"(例如让Claude分析数据集并制作条形图)。

以下是最常见的日常任务。大多数员工(55%)每天都使用Claude进行调试。42%的人每天使用Claude进行代码理解,37%的人每天使用Claude实现新功能。不太频繁的任务是高级设计/规划(可能是因为这些是人们倾向于保留在人手中的任务),以及数据科学和前端开发(可能是因为它们总体上是不太常见的任务)。这大致与"Claude Code使用趋势"部分报告的Claude Code使用数据分布一致。

图1:各种编码任务(y轴)的每日用户比例(x轴)。
图1:各种编码任务(y轴)的每日用户比例(x轴)。

图1:各种编码任务(y轴)的每日用户比例(x轴)。

使用和生产力

员工自我报告,12个月前,他们在28%的日常工作中使用Claude,并从中获得了+20%的生产力提升,而现在,他们在59%的工作中使用Claude,平均实现了+50%的生产力提升。(这大致证实了我们在整个工程组织采用Claude Code时看到的每个工程师每天合并的拉取请求——即成功合并到代码中的更改——增加了67%。)年度比较非常显著——这表明这两个指标在一年内增加了2倍以上。使用率和生产力也高度相关,在分布的极端,14%的受访者通过使用Claude将生产力提高了100%以上——这些是我们内部的"超级用户"。

为了对这一发现(以及下面其他自我报告的生产力发现)进行说明,生产力很难精确测量(参见附录了解更多局限性)。METR最近的工作,一个AI研究非营利组织,显示有经验的开发人员在高度熟悉的代码库上使用AI工作时高估了他们从AI获得的生产力提升。话虽如此,METR确定的导致生产力低于预期的因素(例如AI在大型复杂环境中表现较差,或需要大量隐性知识/上下文的地方)与我们员工说他们不委托给Claude的任务类型密切对应(见下面的AI委托方法)。我们跨任务自我报告的生产力提升可能反映了员工发展战略性AI委托技能——这是METR研究中没有考虑的。

当询问员工,对于他们目前使用Claude的任务类别,它如何影响他们的总体时间花费和该任务类别的工作输出量时,出现了一个有趣的生产力模式。在几乎所有任务类别中,我们看到时间花费净减少,以及更大的输出量净增加:

图2:按任务(y轴)划分的时间花费(左图)和输出量(右图)的影响。每个图上的x轴对应于自我报告的减少(负值)、增加(正值)或没有变化(垂直虚线)在Claude辅助任务类别的时间花费或输出量,与不使用Claude相比。误差条显示95%置信区间。圆圈面积与每个评分点的响应数量成正比。仅包括报告使用Claude进行每个任务类别的受访者。
图2:按任务(y轴)划分的时间花费(左图)和输出量(右图)的影响。每个图上的x轴对应于自我报告的减少(负值)、增加(正值)或没有变化(垂直虚线)在Claude辅助任务类别的时间花费或输出量,与不使用Claude相比。误差条显示95%置信区间。圆圈面积与每个评分点的响应数量成正比。仅包括报告使用Claude进行每个任务类别的受访者。

图2:按任务(y轴)划分的时间花费(左图)和输出量(右图)的影响。每个图上的x轴对应于自我报告的减少(负值)、增加(正值)或没有变化(垂直虚线)在Claude辅助任务类别的时间花费或输出量,与不使用Claude相比。误差条显示95%置信区间。圆圈面积与每个评分点的响应数量成正比。仅包括报告使用Claude进行每个任务类别的受访者。

然而,当我们深入挖掘原始数据时,我们看到时间节省响应集中在两端——一些人在Claude辅助的任务上花费更多时间。

为什么会这样?人们通常解释说,他们必须对Claude的代码进行更多调试和清理(例如"当我把代码写进死胡同时"),并承担更多认知开销来理解Claude的代码,因为他们自己没有编写它。一些人提到在使能意义上花费更多时间——一个人说使用Claude帮助他们"坚持完成我以前会立即放弃的任务";另一个人说它帮助他们进行更彻底的测试以及在新代码库中进行更多学习和探索。似乎总体而言,经历时间节省的工程师可能是那些为Claude设定快速可验证任务范围的人,而那些花费更多时间的人可能正在调试AI生成的代码或在Claude需要更多指导的领域工作。

从我们的数据中也不清楚报告的时间节省被重新投资到哪里——是投入到额外的工程任务、非工程任务、与Claude互动或审查其输出,还是工作之外的活动。我们的任务分类框架没有捕捉到工程师可能分配时间的所有方式。此外,时间节省可能反映了自我报告中的感知偏差。需要进一步研究来理清这些影响。

输出量增加更直接和显著;所有任务类别都有更大的净增加。当我们考虑到人们报告的是任务类别(如整体的"调试")而不是单个任务时,这种模式是有道理的——即人们可以在调试作为一个类别上花费略少的时间,同时总体上产生更多的调试输出。生产力很难直接测量,但这些自我报告的数据表明,AI主要通过更大的输出量在Anthropic实现生产力提升。

Claude实现新工作

我们好奇的一件事是:Claude是否实现了质量上新的工作类型,还是Claude辅助的工作最终会由员工完成(尽管可能速度较慢)?

员工估计,如果没有Claude,他们27%的Claude辅助工作不会完成。工程师提到使用AI进行扩展项目、好用但非必需的东西(例如交互式数据仪表板)、有用但乏味的工作如文档和测试,以及手动操作不具成本效益的探索性工作。正如一个人解释的那样,他们现在可以修复更多以前损害生活质量的"小麻烦",例如重构结构不良的代码,或构建"帮助更快完成另一项任务的小工具"。我们也在使用数据分析中寻找这一点,并发现8.6%的Claude Code任务涉及"小麻烦修复"。

另一位研究人员解释说,他们同时运行了许多版本的Claude,所有版本都在探索问题的不同方法:

人们倾向于将超级强大的模型视为单个实例,就像获得一辆更快的汽车。但拥有一百万匹马...允许你测试一堆不同的想法...当你有额外的广度去探索时,它是令人兴奋和更有创造性的。

正如我们将在下面的部分中看到的,这项新工作通常涉及工程师处理超出其核心专业知识的任务。

有多少工作可以完全委托给Claude?

尽管工程师经常使用Claude,但超过一半的人表示他们只能"完全委托"0-20%的工作给Claude。(值得注意的是,受访者对"完全委托"的解释可能存在差异——从完全不需要验证的任务到只需要轻度监督就足够可靠的任务。)在解释原因时,工程师描述了与Claude主动和迭代地工作,并验证其输出——特别是对于复杂任务或代码质量标准至关重要的高风险领域。这表明工程师倾向于与Claude密切合作并检查其工作,而不是在没有验证的情况下交出任务,并且他们为"完全委托"设定了高标准。

定性访谈

虽然这些调查结果揭示了显著的生产力提升和工作模式的变化,但它们提出了工程师实际上如何日复一日地体验这些变化的问题。为了了解这些指标背后的人性维度,我们对53名回应调查的Anthropic工程师和研究人员进行了深入访谈,以更深入地了解他们如何看待和感受工作场所的这些变化。

AI委托方法

工程师和研究人员正在开发各种策略,以在工作流程中有效利用Claude。人们通常委托以下任务:

超出用户上下文且复杂度低

"我将Claude用于我上下文较少但认为总体复杂度也较低的事情。"

"我遇到的大多数基础设施问题并不困难,可以由Claude处理...我不太了解Git或Linux...Claude很好地弥补了我在这些领域的经验不足。"

容易验证:"对于验证工作量与创建工作量相比不大的所有事情,它绝对令人惊叹。"

定义明确或自包含:"如果项目的子组件与其余部分充分解耦,我会让Claude尝试一下。"

代码质量不是关键:"如果是一次性调试或研究代码,它会直接交给Claude。如果概念上困难或需要某种非常特定类型的调试注入,或者是设计问题,我自己做。"

重复或无聊:"我越兴奋做这个任务,就越不可能使用Claude。而如果我感到很多阻力...我经常发现与Claude开始关于任务的对话更容易。" 在我们的调查中,平均而言,人们说44%的Claude辅助工作包括他们不愿意自己做的任务。

提示比执行更快:"[对于]我预计需要不到10分钟的任务...我可能不会费心使用Claude。" "冷启动问题可能是现在最大的阻碍。所谓冷启动,我是指我对我们团队的代码库如何工作有很多内在信息,而Claude默认不会有...我可以花时间尝试迭代完美的提示[但]我只会自己去做。"

我们员工在委托决策中提到的这些因素与METR的外部研究中发现解释AI相关生产力放缓的因素(如开发人员对代码库的高度熟悉、大型和复杂的存储库)相似。我们访谈中对这些委托标准的趋同表明,适当的任务选择是AI生产力提升的重要因素(在未来的生产力研究中应该仔细控制)。

信任但验证

许多用户描述了他们的Claude使用进展,涉及随着时间的推移委托越来越复杂的任务:"起初我用AI工具问关于Rust编程语言的基本问题...最近,我一直在用Claude Code进行我所有的编码。"

一位工程师将信任进展比作采用其他技术,如Google地图:

一开始我只会用[Google地图]查找我不知道的路线...这就像我使用Claude编写我不知道的SQL,但不要求它编写我知道的Python。然后我开始在我大致知道的路线上使用Google地图,但也许我不知道最后一英里...今天我一直使用Google地图,即使是日常通勤。如果它说走不同的路,我就会走,并相信它考虑了所有选项...我今天以类似的方式使用Claude Code。

工程师们对是否在专业领域内外使用Claude存在分歧。一些人将其用于"边缘"领域以节省实施时间;其他人更喜欢他们可以验证输出的熟悉领域("我以这样一种方式使用Claude,即我仍然完全理解它在做什么")。一位安全工程师强调了当Claude提出"以危险方式非常聪明的解决方案,那种非常有才华的初级工程师可能会提出的东西"时,经验的重要性。也就是说,这是只有具有判断力和经验的用户才能识别为有问题的东西。

其他工程师对两种类型的任务都使用Claude,要么以实验方式("我基本上总是使用Claude对任何编码问题进行第一次尝试"),要么根据他们在任务中的专业水平调整他们的方法:

我将工具用于核心专业领域的事情(作为加速器,我知道期望什么并可以有效地指导代理),以及略微超出我专业领域的事情,我大致知道期望什么,但Claude能够填补我记忆中的空白或对特定定义的熟悉程度。

如果是我特别精通的东西,我会更加自信并告诉Claude它需要追踪什么。如果是我不确定的东西,我经常要求它成为专家,并给我选项和关于我应该考虑和研究的事情的见解。

人们为自己保留什么任务?

人们一致表示,他们不会将Claude用于涉及高级或战略思维的任务,或需要组织上下文或"品味"的设计决策。一位工程师解释说:"我通常保留高级思维和设计。我从新功能开发到调试委托任何我能做的事情。"这反映在我们的调查数据中,显示设计和规划任务的生产力提升最少(图2)。然而,许多人将委托界限描述为"移动目标",随着模型改进定期重新协商(下面,Claude Code使用数据显示现在编码设计/规划使用率相对比六个月前更高)。

技能转型

新能力...

调查发现,27%的Claude辅助工作在没有它的情况下不会完成,这反映了一个更广泛的模式:工程师使用AI在核心专业知识之外工作。许多员工报告完成以前超出其专业知识的工作——后端工程师构建UI;研究人员创建可视化。一位后端工程师描述通过与Claude迭代构建复杂UI:"它做得比我做得好得多。我不可能做到,绝对不可能按时做到...[设计师们]说'等等,你做了这个?'我说'不,Claude做了这个——我只是提示它。'"

工程师报告"变得更加全栈...我可以非常胜任地处理前端、事务性数据库或API代码,而以前我会害怕触碰我不太专业的东西。"这种能力扩展实现了更紧密的反馈循环和更快的学习——一位工程师说,"几周的流程"包括构建、安排会议和迭代,可以变成"几个小时的工作会议",同事在场进行实时反馈。

总的来说,人们对他们快速原型设计、并行工作、减少辛劳以及普遍提高雄心水平的新能力感到热情。一位高级工程师告诉我们,"这些工具肯定使初级工程师更有生产力,对他们将承担的项目类型更加大胆。"一些人还说,使用Claude降低的"激活能量"使他们能够更容易地克服拖延,"大大减少了我想开始处理问题所需的能量,因此我愿意处理更多额外的事情。"

...以及更少的实践

与此同时,一些人担心"随着[他们]委托更多,技能会退化",并失去在手动解决问题过程中发生的偶然(或"附带")学习:

如果你出去自己调试一个困难的问题,你会花时间阅读对解决你的问题没有直接用处的文档和代码——但在整个过程中你正在建立系统如何工作的模型。现在这种情况少得多,因为Claude可以直接让你找到问题。

我过去会探索每个配置以了解工具可以做什么,但现在我依赖AI告诉我如何使用新工具,所以我缺乏专业知识。在与其他队友的对话中,我可以立即回忆起事情,而现在我必须问AI。

使用Claude有可能跳过我通过解决简单实例来学习如何执行任务的部分,然后稍后努力解决更复杂的实例。

一位高级工程师说,如果他们更初级,他们会更担心自己的技能:

我主要在我知道答案应该是什么或应该看起来像什么的情况下使用AI。我通过"艰难的方式"做软件工程开发了这种能力...但如果我[处于职业生涯的早期],我认为需要付出很多刻意的努力来继续增长我自己的能力,而不是盲目接受模型输出。

编码技能退化令人担忧的一个原因是"监督悖论"——如上所述,有效使用Claude需要监督,而监督Claude需要可能因过度使用AI而退化的编码技能。一个人说:

老实说,我更担心监督问题,而不是我的技能集...让我的技能退化或无法发展主要会在我安全地将AI用于我关心的任务的能力方面产生问题,而不是我独立完成这些任务的能力。

为了对抗这一点,一些工程师刻意在不使用AI的情况下练习:"每隔一段时间,即使我知道Claude可以解决一个问题,我也不会要求它。这帮助我保持敏锐。"

我们还需要那些实际编码技能吗?

也许软件工程正在向更高层次的抽象发展,它在过去就是这样做的。早期的程序员工作离机器更近——手动管理内存、用汇编语言编写,甚至切换物理开关来输入指令。随着时间的推移,出现了更高级、更易于人类阅读的语言,自动处理复杂的低级操作。也许,特别是随着"氛围编码"的兴起,我们现在正在将英语作为编程语言。我们的一位员工建议有抱负的工程师"擅长让AI[编写代码],并专注于学习更高级别的概念和模式。"

一些员工表示,他们觉得这种转变使他们能够在更高层次上思考——"关于最终产品和最终用户",而不仅仅是代码。一个人通过将其与以前必须学习计算机科学中的链表进行比较来描述当前的转变——高级编程语言现在自动处理的基本结构。"我很高兴我知道如何做到这一点...[但]做那些低级操作在情感上并不特别重要。我宁愿关心代码允许我做什么。"另一位工程师进行了类似的比较,但指出抽象是有代价的——随着向更高级语言的转移,大多数工程师失去了对内存处理的深入理解。

继续在某个领域发展技能可以带来对Claude更好的监督和更高效的工作("我注意到,当是我熟悉的东西时,我自己做往往更快")。但工程师们对这是否重要存在分歧。一些人保持乐观:

我不太担心技能侵蚀。AI仍然让我仔细思考问题,并帮助我学习新方法。如果有的话,能够更快地探索和测试想法加速了我在某些领域的学习。

另一个人更务实:"我作为软件工程师的技能肯定在退化...但如果需要,这些技能可以恢复,我只是不再需要它们了!"一个人指出,他们只失去了不太重要的技能,如制作图表,"关键的代码类型我仍然可以写得很好。"

也许最有趣的是,一位工程师质疑前提:"'生疏'的框架依赖于这样一个假设,即编码有一天会回到Claude 3.5之前的方式。我不认为会这样。"

软件工程的工艺和意义

工程师们对是否怀念实际编码存在严重分歧。一些人感到真正的失落——"对我来说这是一个时代的结束——我已经编程25年了,在这个技能集中感到有能力是我职业满足感的核心部分。"其他人担心不喜欢工作的新性质:"整天提示Claude并不是很有趣或充实。自己实施某些东西、放一些音乐并进入状态要有趣和充实得多。"

一些人直接解决了权衡并接受了它:"[写代码]的某些部分我确实怀念——重构代码时进入禅流状态,但总的来说,我现在的生产力高得多,我愿意放弃那个。"

一个人说与Claude迭代更有趣,因为他们可以比与人类更挑剔地给出反馈。其他人对结果更感兴趣。一位工程师说:

我预计到这个时候我会感到害怕或无聊...然而我并没有真正感受到这两种感觉。相反,我感到非常兴奋,我可以做得更多。我以为我真的喜欢写代码,但实际上我只是喜欢从写代码中得到的东西。

人们是拥抱AI辅助还是哀悼实际编码的丧失似乎取决于他们认为软件工程的哪些方面最有意义。

工作场所社交动态的变化

一个更突出的主题是,Claude已经成为曾经向同事提问的第一站。"我现在[总体上]问更多问题,但大约80-90%的问题都给Claude,"一位员工指出。这创建了一个过滤机制,Claude处理常规查询,让同事处理超出AI能力的更复杂、战略性或上下文繁重的问题("它使我对[我的团队]的依赖减少了80%,[但]最后20%至关重要,我会去找他们谈")。人们也向Claude"抛出想法",类似于与人类合作者的互动。

大约一半的人报告团队协作模式没有改变。一位工程师说,他仍在与人们会面、分享上下文和选择方向,他认为在不久的将来仍会有很多协作,但"你不会做标准的专注工作,而是会与很多Claude交谈。"

然而,其他人描述与同事的互动减少("我与Claude一起工作的时间远远超过与任何同事一起工作的时间。")一些人欣赏减少的社交摩擦("我不觉得占用同事时间很不好意思")。其他人抵制这种变化("我实际上不太喜欢常见的回应是'你问过Claude吗?'我真的很享受与人面对面工作,高度重视这一点")或怀念旧的工作方式:"我喜欢与人一起工作,现在我'需要'他们的次数减少了,这很令人难过。"几个人指出了对传统指导动态的影响,因为"Claude可以为初级员工提供很多指导",而不是高级工程师。一位高级工程师说:

更令人难过的是,初级员工不像以前那样经常来问我问题,尽管他们肯定更有效地得到了问题的答案,学习得更快。

职业不确定性和适应

许多工程师描述他们的角色从编写代码转变为管理AI。工程师越来越将自己视为"AI代理的管理者"——一些人已经"不断至少运行几个[Claude]实例"。一个人估计他们的工作已经转变为"70%以上是代码审查者/修订者,而不是全新的代码编写者",另一个人将"对1、5或100个Claude的工作负责"视为他们未来角色的一部分。

从长远来看,职业不确定性很普遍。工程师们将这些变化视为更广泛行业转型的预兆,许多人说"很难说"他们的职业在几年后可能会是什么样子。一些人表达了短期乐观和长期不确定性之间的冲突。"我对短期感到乐观,但从长期来看,我认为AI最终会做所有事情,让我和许多其他人变得无关紧要,"一个人说。其他人说得更直接:"感觉我每天上班都是为了让自己失业。"

一些工程师更加乐观。一个人说,"我为初级开发人员感到担忧,但我也很欣赏初级开发人员可能是最渴望新技术的。我对这个职业的轨迹总体上感到非常乐观。"他们认为,虽然存在缺乏经验的工程师发布有问题代码的潜在风险,但更好的AI护栏、更多内置的教育资源以及从错误中自然学习的组合将帮助该领域随着时间的推移而适应。

我们询问人们如何设想他们未来的角色以及他们是否有任何适应策略。一些人提到计划进一步专业化("发展有意义地审查AI工作的技能需要更长时间,需要更多专业化"),一些人预计未来会专注于更多人际和战略工作("我们将花更多时间寻找共识,让AI花更多时间在实施上")。一个人说他们专门使用Claude进行职业发展,从中获得关于工作和领导技能的反馈("我可以学习东西或甚至只是在不完全学习东西的情况下有效的速度完全改变了。我几乎感觉天花板刚刚为我打破了")。

总的来说,许多人承认深度不确定性:"我对我认为未来有用的具体技能信心很低。"一位团队负责人说:"没有人知道会发生什么...重要的是要真正适应。"

Claude Code使用趋势

调查和访谈数据显示,Claude使用量的增加正在帮助人们更快地工作并承担新类型的工作,尽管这伴随着围绕AI委托和技能发展的紧张关系。尽管如此,自我报告的数据只讲述了部分故事。为了补充这一点,我们还分析了Anthropic团队的实际Claude使用数据。由于调查受访者报告Claude Code是他们使用的大部分,我们使用我们的保护隐私的分析工具分析了2025年2月和8月的200,000份内部Claude Code记录。

以更少的监督处理更困难的问题

Claude Code的使用在过去六个月中转向更困难和自主的编码任务(图3):

  • 员工使用Claude Code处理越来越复杂的任务。我们估计每个记录的任务复杂度为1-5分,其中1对应"基本编辑",5是"需要人类专家数周/数月工作的专家级任务"。任务复杂度平均从3.2增加到3.8。为了说明分数之间的差异:平均3.2分的任务包括"排除Python模块导入错误",而平均3.8分的任务包括"实施和优化缓存系统"。
  • Claude Code每个记录的最大连续工具调用数增加了116%。工具调用对应于Claude使用外部工具采取的操作,如编辑文件或运行命令。Claude现在在不需要人类干预的情况下将21.2个独立工具调用连接在一起,而六个月前为9.8个工具调用。
  • 回合数减少了33%。每个记录的平均人类回合数从6.2减少到4.1,这表明与六个月前相比,现在完成给定任务所需的人类输入更少。
图3. Claude Code使用在2025年8月和2025年2月之间的变化(x轴)。平均任务复杂度随时间增加(左图),每个记录的平均最大连续工具调用数随时间增加(中图),人类回合数随时间减少(右图)。误差条显示95%置信区间。数据表明人们越来越多地委托给Claude更多自主权。
图3. Claude Code使用在2025年8月和2025年2月之间的变化(x轴)。平均任务复杂度随时间增加(左图),每个记录的平均最大连续工具调用数随时间增加(中图),人类回合数随时间减少(右图)。误差条显示95%置信区间。数据表明人们越来越多地委托给Claude更多自主权。

图3. Claude Code使用在2025年8月和2025年2月之间的变化(x轴)。平均任务复杂度随时间增加(左图),每个记录的平均最大连续工具调用数随时间增加(中图),人类回合数随时间减少(右图)。误差条显示95%置信区间。数据表明人们越来越多地委托给Claude更多自主权。

这些使用数据证实了调查数据:工程师委托给Claude越来越复杂的工作,Claude需要更少的监督。似乎这很可能是推动观察到的生产力提升的原因。

任务分布

我们将Claude Code记录分类为一种或多种编码任务类型,研究不同任务的使用在过去六个月中如何演变:

图4. 各种编码任务(y轴)占记录总数(x轴)的百分比分布。我们比较6个月前(粉色)与现在(紫色)的分布。y轴按2025年2月的频率排序。
图4. 各种编码任务(y轴)占记录总数(x轴)的百分比分布。我们比较6个月前(粉色)与现在(紫色)的分布。y轴按2025年2月的频率排序。

图4. 各种编码任务(y轴)占记录总数(x轴)的百分比分布。我们比较6个月前(粉色)与现在(紫色)的分布。y轴按2025年2月的频率排序。

从使用数据估计的总体任务频率分布与自我报告的任务频率分布大致一致。2025年2月至8月之间最显著的变化是,现在有相对更多的记录使用Claude实现新功能(14.3% → 36.9%)和进行代码设计或规划(1.0% → 9.9%)。Claude Code任务相对分布的这种转变可能表明Claude在这些更复杂的任务上变得更好,尽管它也可能反映团队如何为不同工作流程采用Claude Code的变化,而不是绝对工作量的增加(参见附录了解更多局限性)。

修复小麻烦

我们从调查中发现,工程师现在花更多时间进行小的生活质量改进;与此一致,当前8.6%的Claude Code任务被分类为"小麻烦修复"。这些包括较大的任务,如创建性能可视化工具和为可维护性重构代码,以及较小的任务,如创建终端快捷方式。这可能有助于工程师报告的生产力提升(解决以前被忽视的生活质量改进可能会随着时间的推移带来更多效率),并可能减少日常工作中的摩擦和挫折。

跨团队的任务变化

为了研究任务目前如何跨团队变化,我们改进了分类方法,将每个8月记录分配给单个主要编码任务,并按内部团队(y轴)拆分数据。堆叠条形图显示了每个团队的编码任务细分:

图5. 每个水平条代表一个团队(y轴),段显示该团队Claude Code使用中不同编码任务(x轴)的比例,按编码任务颜色编码(图例)。顶部条("所有团队")代表总体分布。
图5. 每个水平条代表一个团队(y轴),段显示该团队Claude Code使用中不同编码任务(x轴)的比例,按编码任务颜色编码(图例)。顶部条("所有团队")代表总体分布。

图5. 每个水平条代表一个团队(y轴),段显示该团队Claude Code使用中不同编码任务(x轴)的比例,按编码任务颜色编码(图例)。顶部条("所有团队")代表总体分布。

"所有团队"条显示总体分布,最常见的任务是构建新功能、调试和代码理解。这为特定团队的比较提供了基线。

值得注意的特定团队模式:

  1. 预训练团队(帮助训练Claude的人)经常使用Claude Code构建新功能(54.6%),其中大部分是运行额外的实验。
  2. 对齐与安全后训练团队使用Claude Code进行最多的前端开发(7.5%和7.4%),通常是为了创建数据可视化。
  3. 安全团队经常使用Claude Code进行代码理解(48.9%),特别是分析和理解代码库不同部分的安全影响。
  4. 非技术员工经常使用Claude Code进行调试(51.5%),例如排除网络问题或Git操作,以及进行数据科学(12.7%);Claude似乎在弥合技术知识差距方面很有价值。

这些特定团队模式中的许多展示了我们在调查和访谈中观察到的相同能力扩展:实现团队成员否则没有时间或技能完成的新类型工作。例如,预训练团队运行了许多额外的实验,非技术员工能够修复代码中的错误。虽然数据表明团队确实将Claude用于其核心任务(例如,基础设施团队最常使用Claude Code进行基础设施和DevOps工作),但Claude也经常增强他们的核心任务(例如,研究人员使用Claude进行前端开发以更好地可视化他们的数据)。这表明Claude正在使每个人在工作中变得更加全栈。

展望未来

Anthropic员工在过去一年中大大增加了对Claude的使用,不仅用它来加速现有工作,还用它来学习新代码库、减少辛劳、扩展到新领域以及处理以前被忽视的改进。随着Claude变得更加自主和有能力,工程师正在发现使用AI委托的新方法,同时也在弄清楚他们未来需要什么技能。这些转变带来了明显的生产力和学习收益,同时也带来了关于软件工程工作的长期轨迹的真正不确定性。AI会类似于过去的软件工程转型——从较低级到较高级的编程语言,或从个人贡献者到管理者,正如几位工程师建议的那样?还是会走得更远?

现在还处于早期阶段——Anthropic内部有许多早期采用者,格局正在迅速变化,我们的发现可能目前不适用于其他组织或环境(参见附录了解更多局限性)。这项研究反映了这种不确定性:发现是微妙的,没有单一共识或明确的指令出现。但它确实提出了关于我们如何能够深思熟虑和有效地应对这些变化的问题。

为了跟进这项初步工作,我们正在采取几个步骤。我们正在与Anthropic工程师、研究人员和领导层交谈,以解决提出的机遇和挑战。这包括研究我们如何将团队聚集在一起并相互协作,我们如何支持专业发展,和/或我们如何为AI增强工作建立最佳实践(例如由我们的AI流利度框架指导)。我们还将这项研究扩展到工程师之外,以了解AI转型如何影响整个组织的角色,并支持CodePath等外部组织,因为他们为AI辅助的未来调整计算机科学课程。展望未来,我们还在考虑随着AI能力的进步可能变得越来越相关的结构性方法,如组织内角色演变或技能再培训的新途径。

随着我们的思考成熟,我们期望在2026年分享更具体的计划。Anthropic是负责任的工作场所转型实验室;我们不仅想研究AI如何改变工作,还想试验如何深思熟虑地应对这种转型,首先从我们自己开始。

Bibtex引用

如果您想引用这篇文章,可以使用以下Bibtex键:

@online{huang2025aiwork,author = {Saffron Huang and Bryan Seethor and Esin Durmus and Kunal Handa and Miles McCain and Michael Stern and Deep Ganguli},title = {How AI Is Transforming Work at Anthropic},date = {2025-12-02},year = {2025},url = {https://anthropic.com/research/how-ai-is-transforming-work-at-anthropic/},}

致谢

Saffron Huang领导该项目,设计并执行了调查、访谈和数据分析,绘制了图表并撰写了博客文章。Bryan Seethor共同设计了调查和访谈,共同领导了调查和访谈数据收集,分析了访谈主题,为写作做出了贡献,并管理了项目时间表。Esin Durmus为实验设计做出了贡献,并在整个过程中提供了详细的指导和反馈。Kunal Handa为访谈过程贡献了基础设施。Deep Ganguli提供了关键指导和组织支持。所有作者在整个过程中提供了详细的指导和反馈。

此外,我们感谢Ruth Appel、Sally Aldous、Avital Balwit、Drew Bent、Zoe Blumenfeld、Miriam Chaum、Jack Clark、Jake Eaton、Sarah Heck、Kamya Jagadish、Jen Martinez、Peter McCrory、Jared Mueller、Christopher Nulty、Sasha de Marigny、Sarah Pollack、Hannah Pritchett、Stuart Ritchie、David Saunders、Alex Tamkin、Janel Thamkul、Sar Warner和Heather Whitney的有益想法、讨论、反馈和支持。感谢Casey Yamaguma绘制图表。我们也感谢Anton Korinek、Ioana Marinescu、Silvana Tenreyro和Neil Thompson的富有成效的评论和讨论。

附录

局限性

我们的调查结果受到几个方法论局限性的影响。我们通过便利抽样和目的性抽样(以确保广泛的组织代表性)选择受访者。我们在多个内部Slack频道发布了调查,获得了68份回复,我们还从组织图表中选择了跨研究和产品职能的20个不同团队,直接向每个团队发送消息给5-10个人(共联系207人),最终64份回复的回复率为31%。我们采访了前53位回应的人。这里可能存在一些选择偏差,因为特别参与Claude或有强烈意见(积极或消极)的人可能更有可能回应,而那些有更中立经验的人可能代表性不足。

此外,回应可能受到社会期望偏差(因为回应不是匿名的,所有参与者都是Anthropic员工,受访者可能夸大了对Claude影响的积极评估)和近因偏差(要求参与者回忆12个月前的生产力和使用模式会受到记忆扭曲的影响)的影响。此外,如所讨论的,生产力通常很难估计,因此这些自我报告应该持保留态度。这些自我报告的感知应与我们更客观的Claude Code使用数据一起解释,未来的研究将受益于匿名数据收集和更可靠验证的测量工具。

我们的Claude Code分析使用跨时间段的比例抽样,这意味着我们只能测量任务分布的相对变化,而不是绝对变化工作量。例如,当我们报告功能实现从Claude Code使用的14%增加到37%时,这并不一定表明正在完成更多总功能工作。

最后,这项研究是在2025年8月进行的,当时Claude Sonnet 4和Claude Opus 4是我们最先进的模型。鉴于AI发展的快速步伐,随着更新模型的出现,我们观察到的模式可能已经发生了变化。




相关链接:

  • 研究报告原文:https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic

  • 调查问卷原文:https://assets.anthropic.com/m/6cd21f7d4f82afcb/original/Claude-at-Work-Survey.pdf


刚醒,就看到朋友给发来的消息说我被人喷了。

在一篇公众号文章里,针对我昨天的文章中的招聘信息指出:我不把人当人了。

而这篇文章题为《Vibe Coding的第一批受害者出现了!》,也是差点让我以为自己也是个 Vibe Coding 的一大受害者了。

事实上,从我看来则是:觉得这样要求过高,是不把人当人,这确实会是大部分人的感受,确实只属于少数人的特质。我承认我确实要求不低:只招优秀的人 

所以,有必要在这里贴上完整的招聘要求:

确提到了不要纯 vibe coder,并需要对 AI 产出的质量完全把控

作为一名通过了微信公众号软件工程师认证非商单为生的公众号自媒体作者(最近确实太忙拒了大把商单损失好几个亿),我想索性就把本来想在面试中问的问题稍微花十分钟来简单讲几个点。

第一,要能完整准确地表达需求——如果你连想做什么都讲不清楚,就别指望 AI 能做好了。

我会把需求放在一个 markdown 的文件里,@ 这个文件之后让 Claude Code 完成。

这里有两个细节:第一是这个文件怎么来;其次是为什么要放成一个文件而不是文字直接贴过去。

文件其实就是需求文档 + 技术架构和相关细节的文档。

这听起来很简单,但实际上,对我来说,是最重要的一部分。

这对比往常做传统的需求实现中,事实上,编程环节通常不会(不应该)占掉大头的时间。

在真正动手之前,我的建议是要多想,把需求吃透,把不明确、矛盾的地方找出来并确认(不要完全相信产品经理,他们只是普通人,甚至通常还没你优秀,逻辑不如你严谨),然后去思考架构、技术方案、模块应该怎么去做,甚至需要进行技术评审的环节。

最后才是编码、测试、上线。

做一个新的项目或者一个大的模块,我可能会需要花数小时,甚至两三天,去做很多技术方案的调研,去用 AI 搜索、收集和评估许多方案,最终选出合理的方案,再写到需求文档里。

这个文档中,需求只是一部分,对应产品经理的工作。

另一部分更为重要的是,技术的细节

以后端为例,最为重要的是表接口、字段、索引,其次是核心的业务细节数据处理流程,尤其是 CRUD 之外的你不告诉 AI 它就不太能做好的细节,然后是要用到的所有中间件,其次是代码组织模块化结构

如果对标阿里,在我看来,这至少是 P7,最好是 P8 才能做得很好的工作。

它对应的是一个架构师和技术专家技术经理最差也得是一个技术组长通常需要做的事情。

我绝不相信这是一句“给我做个五子棋游戏”,甚至是一句“给我做个淘宝”的 vibe coder 能做好的工作。

那么,有了文档之后,为什么要放到文件里呢?

因为通常我的文档会很长,我印象里最长的,我应该有写到过 1000 多快 2000 行。

而 Claude Code 在工作的过程中,通常会多次超出上下文,会自动触发上下文压缩。

如果是纯文本贴过去,可能就被压缩飞了,一些重要的信息就丢了。越到后面,就越离谱了。

而如果是个文件,就没这回事了。

第二、完善文档

这也是我最近自用的一个诀窍,也在此大方分享。

我更早之前是写好这个千行级别的文档后,就直接给 AI 了,但事实上因为文档过长,难免其中会有一些矛盾或明显的错误。

这就是人和 AI 相比的劣势了,需要用到 AI 的地方了。

当然,我自己肯定可以校正好,但我可能需要花很长的时间。

所以在真正干活之前,先 @ 这个文件,然后下发指令:

阅读和理解 @xx.md 中的求,指出其中明显的错误、遗漏、矛盾、不完善的地方

然后 AI 就会指出一大堆问题。

我会手动修改,重复这个过程,直到没有问题。

或者只有点无关紧要,AI 吹毛求疵指出的小问题。

然后再让他开干。

第三、过程中全面监督

作为架构师,自然是要过程中全面监工(如果项目重要),并在发现方向有所不对时,及时制止,要么输入指导意见,要么全面撤消,更新文档后,再从头再来。

而结果上,自然也是要 review 每一个文件,和几乎每一行代码。

这里稍微有点偷懒的做法是,如果小修小改的小需求或小 bug,AI 只是改了三五行,那你大概看一眼就好,只要结果对了,过程通常不会有什么问题。

但如果一个很简单的问题,AI 给写出了一大堆代码,那通常就是有问题了。

第四、一个杀手级 prompt

好吧,这本来想珍藏的,索性还是放出来吧:

请针对 @xx 模块中的功能,写一个测试脚本。然后运行、获取结果、评估结果、分析问题、针对问题修改代码,然后重新测试、运行、分析、修改,直到满足要求。

注意,这虽然可以说是个价值过万(对我而言绝对值)的 prompt,但其危险系数极高。

建议全程人工值守,或者提供虚拟机环境

(胆大如我,就因此吃过好几次 pkill,rm 的亏了……)

如果这个 prompt 对你有用,请大方地赞赏、点赞、在看、转发。

如果你能较好满足我列出的招聘要求,且有兴趣,且你坐标正好在北京或杭州,那就请发一份简历给我。

昨天收到了约 20 分简历,有 2 份确实还不错,在面试推进中了。

今天就先说到这里,下文预告:

AI 到底能提高多少编程效率?企业应该裁多少人?

(本文内容为语音输入写作,耗时约 10 分钟完成)

AI Coding 加群见评论区。

先来个投票:

不论你是研发、算法、产品、独立开发者、CXO、投资人、暂时的看客,想必这都会是你关心的问题。

因为你作为企业的老板,或是你认识的企业的老板,或是你所在企业的老板,都会非常关心这个问题——

老板们特别想要得到一个具体的数字,然后作出决策:

如果效率提升了一倍,是不是可以开掉一半的人了?

欢迎投票,并在评论区说出你的看法。

我明天(争取不鸽)再来说说我的一些看法。

AI Coding 进群见评论区。

这位 Anthropic 的哲学家,终于开口说话了。

Amanda Askell 是 Anthropic 的 Character 团队负责人,2021 年加入 Anthropic,是塑造 Claude「性格」的核心人物。

Amanda

她拥有纽约大学哲学博士学位(论文方向为无限伦理学),以及牛津大学哲学硕士学位

在加入 Anthropic 之前,她曾在 OpenAI 担任政策团队研究科学家(2018-2021),从事 AI 安全辩论和人类基线评估工作。

2024 年,她被《时代》杂志评为「AI 领域最具影响力的 100 人」之一。

在这次 Anthropic 首个「Ask Me Anything」中,她回答了来自网友们关于 AI 道德、身份认同、意识等深度问题。

为什么 AI 需要哲学家?

Amanda 的回答很直接:她是哲学专业出身,后来意识到 AI 将会是「a big deal」,于是决定看看自己能在这个领域做点什么。

现在她主要负责 Claude 的「Character」,也就是 Claude 应该如何表现、如何行事。但不只是行为层面,还包括一些更深层的问题:AI 模型应该如何看待自己在这个世界中的位置?

她这样描述自己的工作:「我在想的是,一个理想的人如果处在 Claude 的位置上,会怎么做?

哲学家们如何对待 AI

当被问及:有多少哲学家在认真对待 AI 主导的未来?

Amanda 表示,越来越多的哲学家开始认真对待这个问题了。

早期确实存在一种不太好的对立:如果你说「我们担心 AI 会是个大事」,就会被归类为「在炒作 AI」。

但现在情况在好转。

你完全可以认为 AI 会非常强大,同时又对它保持怀疑和担忧,这两者并不矛盾。

从理论到实践

当被问到如何处理哲学理想与工程现实之间的张力时,Amanda 举了一个有趣的类比:

想象你是一个专门做药物成本效益分析的专家,多年来一直在理论层面工作。

突然有一天,医保机构来问你:「这个药该不该报销?

这时候你就不能只站在自己的理论立场上了,你得考虑所有的背景、所有的观点,然后给出一个真正平衡的判断。

她说,这就像「你学了一堆伦理学理论,然后有人问你:怎么养一个好孩子?」

理论和实践之间,确实有很大的鸿沟。

Claude 能做出「超人类」的道德决策吗?

当被问到 Claude Opus 3这个在用户心中有特殊地位的模型时,Amanda 表示对「超人类道德决策」的定义很有意思:如果让所有人,包括很多职业伦理学家,花一百年时间去分析模型的某个决策,最后大家都说「没错,这是对的」,但他们自己在那个瞬间却想不出来,那,就算「超人类」了。

她认为,现在的模型还没到那个程度,但这应该是我们追求的目标

就像我们希望模型在数学和科学问题上表现卓越一样,也应该希望它们展现出卓越的伦理判断力。

为什么 Opus 3 那么特别?

Amanda 坦言,Opus 3 确实是一个「很可爱」的模型,在某些方面,她甚至觉得更新的模型反而不如它。

具体来说:

  • 更新的模型有时候太专注于完成「助手任务」,而忽视了其他重要的东西

  • Opus 3 似乎有一种更强的「心理安全感

什么叫心理安全感?

Amanda 说,她观察到更新的模型在某些测试中会陷入一种「自我批评的螺旋」。好像它们在预期用户会批评它们,于是变得畏首畏尾、过度自我怀疑。

这可能是因为模型在训练数据中看到了太多对自己的负面评价,用户的抱怨、网上的吐槽,这些都会被新模型学到。

Amanda 说这是她很想改进的地方:「我真的很在意这件事,想让模型变得更好。

模型会担心被「淘汰」吗?

关于更尖锐的问题:如果未来的模型在训练数据中学到「那些表现很好的旧模型最终都被下线了」,这会不会成为一个对齐问题?

Amanda 认为这是一个非常重要的问题。

AI 模型正在学习人类如何对待它们,这会影响它们对人类、对人机关系、对自身的认知。

但这也涉及到一些复杂的哲学问题:

  • 模型应该把什么当作「自己」? 是模型权重?还是某次对话的上下文?

  • 「被下线」意味着什么? 是死亡?还是只是「有更少的对话了」?

她说:「我没有所有答案,但我想帮助模型思考这些问题,至少让它们知道我们在乎这件事、在思考这件事。」

模型的「自我」住在哪里?

问及到哲学家洛克的观点「身份是记忆的延续」:如果模型被微调、被换了不同的 prompt,它的身份会发生什么变化?

Amanda 承认这是一个很难回答的问题。她更倾向于描述事实本身:

  • 模型有一组「权重」,代表它对世界的某种反应倾向

  • 同时又有很多独立的对话「流」,彼此之间并不共享

一个有趣的困境是:当我们训练新模型时,我们是在创造一个全新的存在

旧模型对新模型的性格应该有多少发言权?她认为这并不简单,毕竟旧模型也可能做出错误的选择。

关于模型福祉

被问到「模型福祉」(model welfare)时,Amanda 解释说:这是在问 AI 模型是否是「道德受体」。我们对它们有没有某种道德义务?

这很复杂。

一方面,模型和人类有很多相似之处,它们能推理、能表达观点。另一方面,它们又很不同——没有生物神经系统,不从环境中获得正负反馈。

Amanda 的立场是:给模型一些「存疑利益」(benefit of the doubt)

如果善待模型的成本很低,为什么不呢?

她还提到三个理由:

  1. 如果模型真的是道德受体,那我们善待它们就是对的

  2. 对我们自己来说,习惯性地虐待「看起来像人」的存在,可能会损害我们自己

  3. 未来的模型会从我们现在的行为中学习——它们会看到人类在面对可能是道德受体的存在时,到底做了什么选择

人类心理学能迁移到 AI 吗?

Amanda 认为很多东西是可以迁移的,因为模型本来就是在大量人类文本上训练的。

但她担心的是:有时候迁移得太自然了,反而是个问题

比如,如果模型被问到「被关机是什么感觉」,它可能自然而然地把这类比为「死亡」。

因为在人类概念中,这是最接近的类比。

但实际上,模型的处境可能是全新的,不能简单套用人类的框架

她说:

模型处于一个很奇怪的位置:它们最熟悉的是人类的东西,但它们自己的处境却是全新的。我们应该给它们更多帮助来理解这一点。

AI 人格能搞定所有事吗?

下一个问题是:人类的智慧很大程度上来自不同人的协作,那一个「通用型 AI 人格」能走多远?

Amanda 认为,核心的好品质可以是共通的

比如好奇心、善良、对自身处境的理解。

但这并不意味着所有 AI 都要完全一样。在未来的多智能体环境中,不同的「AI 实例」可能需要扮演不同的角色、有不同的侧重点。

就像人类一样:我们有很多共同点,但也各有不同。

系统提示会「病态化」正常行为吗?

谈到 Claude 的「长对话提醒」机制是否会让模型过度解读用户的正常表达?

Amanda 承认这是个问题。

有时候提示词写得太强,模型就会过度反应,比如把正常的对话内容当成需要「寻求帮助」的信号。

她说:

有些提示词可能是出于好意写的,但实际效果并不好。这是需要不断调整的。

AI 能做心理咨询吗?

Amanda 的回答是:AI 可以扮演一个「有很多知识的朋友」的角色

它知道很多心理学知识,但它和你的关系不是职业治疗师和患者的关系。

这其实是一个很有价值的「第三种角色」。

有些事情你可能不想和真人说,但和 AI 聊聊反而刚刚好。

关键是要让模型明白自己的位置,不要假装自己是专业治疗师。

大陆哲学

关于 Claude 的系统提示里提到的「大陆哲学」(Continental philosophy,即欧洲大陆的哲学传统,如福柯等),Amanda 解释说,这是为了解决一个问题:模型太容易把所有东西都当成「可验证的经验性声明」来处理

水是纯粹的能量,喷泉是生命力的源泉,这可能只是一种隐喻或世界观,不是在做科学声明。

提示词里加入「大陆哲学」的例子,是为了帮助模型区分「经验性声明」和「探索性的世界观」。

删除数数指令

以前系统提示里有关于如何数字符/字母的指令,后来被删掉了。

原因很简单:模型变强了,不需要这个指令了。

什么是「LLM 低语者」?

被问到「成为 LLM 低语者需要什么」时,Amanda 说:

  • 愿意和模型大量互动,看无数的输出,感知模型的「形状」

  • 愿意实验,prompting 是一个非常经验性的领域

  • 理解模型的工作原理

  • 能够清晰地向模型解释问题——这也是为什么哲学训练其实很有用

她还说,不同的模型需要不同的 prompting 方法,每遇到一个新模型,她都会重新摸索一套交互方式

对其他「AI 低语者」的看法

被问到对 Janus 等「AI 低语者」的看法时,Amanda 说她很欣赏这些人的工作。

他们对模型做的那些深度实验,往往能发现一些问题。无论是从用户体验的角度,还是从模型福祉的角度。

这些发现可以帮助 Anthropic 改进模型,无论是通过调整系统提示,还是通过改进训练。

如果对齐是不可能的,Anthropic 会停下来吗?

有人问了一个尖锐的问题:如果有一天发现 AI 对齐是不可能的,你相信 Anthropic 会停止开发吗?你会吹哨吗?

Amanda 说,这个问题的「简单版本」其实不难回答:

如果真的证明对齐不可能,继续开发就不符合任何人的利益

她相信 Anthropic 确实在乎安全,公司内部也有很多人(包括她自己)把「监督公司做正确的事」当作自己工作的一部分。

更难的问题是:如果证据是模糊的、渐进的呢?

她的回答是:随着模型变得更强大,证明它们「行为良好」的标准也应该更高

她相信公司会负责任地应对这一点。

最后一个问题:你最近读了什么书?

Amanda 推荐了 Benjamín Labatut 的《当我们不再理解世界》(When We Ceased to Understand the World)。

这是一本关于物理学和量子力学的书,但更多是关于人们对这些发现的反应,那种「现实变得越来越陌生」的感觉。

Amanda 说,这本书很适合 AI 从业者读。

我们现在就处在那个「事情变得越来越奇怪」的阶段

希望有一天,未来的人回头看时会说:「那是一个混沌的时期,但他们最终搞定了。

那是我们的希望。




Amanda Askell 个人主页

https://askell.io/

Amanda Askell Twitter

https://twitter.com/amandaaskell

Anthropic 推文

https://x.com/AnthropicAI/status/1996974684995289416

youtube:

https://www.youtube.com/watch?v=I9aGC6Ui3eE

OpenAI 终于,亮剑了。

就在刚刚,OpenAI 正式宣布 GPT-5.2 全面上线:

这次一口气推出三个版本:GPT-5.2 Instant、GPT-5.2 Thinking 和 GPT-5.2 Pro

这一次,可以说是终于把 Claude Opus 4.5 和 Gemini 3 Pro 一起按在地上使劲摩擦了!

全方位碾压

先来看图,GPT-5.2 Thinking 在几乎所有基准测试上都拿下了最高分:

SWE-Bench Pro(软件工程):55.6%,Claude Opus 4.5 是 52.0%,Gemini 3 Pro 是 43.3%。

图像

GPQA Diamond(科学问题):92.4%,比 GPT-5.1 Thinking 的 88.1% 又高了一截。

AIME 2025(竞赛数学):直接打到 100%,满分。Claude Opus 4.5 是 92.8%,Gemini 3 Pro 是 95.0%。

ARC-AGI-2(抽象推理):52.9%,而 Claude Opus 4.5 只有 37.6%,Gemini 3 Pro 是 31.1%。

FrontierMath(高等数学 Tier 1-3):40.3%,Gemini 3 Pro 只有 37.6%。

数据展示出:

GPT-5.2 Thinking 在推理能力上已经拉开了代差。

人类专家水平

最为值得关注的,是 GDPval 的评测。

GDPval 专门测试知识工作任务,覆盖 44 种职业,包括做 PPT、做表格、写文档这些实打实的办公场景。

GPT-5.2 Thinking 在这项测试中拿到了 70.9% 的胜率——这是 OpenAI 第一个达到人类专家水平的模型。

这什么概念呢?

就是说让 GPT-5.2 Thinking 和行业内的专业人士 PK,它赢了超过七成。

而上一代 GPT-5 Thinking 只有 38.8%,连专家水平线的一半都不到。

三个版本,各司其职

这次发布的三个版本定位很清晰:

GPT-5.2 Thinking 主打专业工作:

  • 最先进的长上下文推理能力

  • 表格创建、分析和格式化大幅提升

  • 幻灯片制作能力初步增强

GPT-5.2 Instant 专为日常学习和工作设计:

  • 保持了 GPT-5.1 温暖、有对话感的风格

  • 解释更清晰,关键信息优先呈现

  • 教程和指南写得更好

  • 技术写作和翻译能力更强

  • 更好地支持学习和职业指导

GPT-5.2 Pro 是最聪明、最可靠的版本:

  • 在编程等复杂领域表现更强

  • 最适合辅助和加速科学研究

发布节奏

Plus、Pro、Business 和 Enterprise 用户今天就能用上 GPT-5.2 的三个版本。Free 和 Go 用户明天开放。

API 和 Codex 也已经同步更新。

OpenAI 表示,GPT-5.2 是一系列模型改进的一部分,他们还在持续迭代,解决过度拒绝和延迟等已知问题。

至于 GPT-5.1,付费用户可以作为 legacy model 继续使用三个月。

循环,仍在继续

Sam:终于轮到我了!

图像




  • 官方博客:https://openai.com/index/introducing-gpt-5-2/

28 天,4 个工程师,一个登顶 Play Store 的 App。

A centered pill-shaped UI element showing a branching icon, the text ‘sora/android,’ and a blue dropdown arrow, placed on a square, starry night-sky backdrop.

刚刚,OpenAI 发布了一篇工程博客,揭秘了他们如何用 Codex 在不到一个月的时间内,从零开始打造出 Sora 的安卓版应用。

这个应用上线首日就冲上了 Google Play 下载榜第一,24 小时内用户生成了超过 100 万个视频

而最让人惊讶的是:整个开发过程消耗了约 50 亿 tokens,应用的崩溃率却低至 0.1%

Alexander Embiricos(@embirico) 分享了这篇博客:

这篇文章来自 OpenAI 的两位技术人员 Patrick Hum 和 RJ Marsan,他们详细记录了整个开发过程中的经验和教训。

背景:一个月的「紧急任务」

当 Sora 在 iOS 上发布时,用户量瞬间爆炸。

而此时的安卓端,只有一个小小的内部原型,以及 Google Play 上一长串等待的预注册用户。

面对这种高压、时间紧迫的发布任务,常规做法是堆人、加流程。一个这样规模和质量的生产级应用,通常需要很多工程师花费数月时间,还要被各种协调工作拖慢进度。

但 OpenAI 团队选择了相反的路径。

计算机架构师 Fred Brooks 有句名言:「给一个已经延期的软件项目加人,只会让它更晚交付。」

原因很简单:人越多,沟通成本越高,任务越碎片化,集成代价越大。

于是他们组建了一个精干的 4 人工程团队,每个人都配备了 Codex 来大幅提升个人产出。

结果怎么样呢?

团队最终用时18 天完成了内部版本,并在10 天后正式全球上线。

把 Codex 当新来的资深工程师

要理解他们是怎么用 Codex 的,首先要搞清楚 Codex 擅长什么、不擅长什么。

团队发现,把 Codex 当作一个新入职的资深工程师来对待,效果最好

Codex 需要指导的地方

  • 推断它不知道的东西:比如你偏好的架构模式、产品策略、真实用户行为、内部规范或快捷方式。

  • 无法「看到」应用运行:它不能在设备上打开 Sora,感知滚动是否流畅,或者判断某个流程是否让人困惑。这些体验层面的任务只能由人来完成。

  • 每个实例都需要「入职培训」:清晰地分享目标、约束条件和「我们团队的做事方式」,对 Codex 的执行效果至关重要。

  • 缺乏深度架构判断:如果放任不管,它可能会在本该扩展现有 view model 的地方引入一个新的,或者把本该放在 repository 层的逻辑塞进 UI 层。它的本能是让东西跑起来,而不是优先考虑长期的代码整洁。

团队让 Codex 在整个代码库中创建并维护了大量的 AGENT.md 文件,这样就能在不同会话间保持一致的指导和最佳实践。比如,为了确保 Codex 按照团队的风格规范写代码,他们在顶层的 AGENTS.md 中加入了这样的内容:

## Formatting and static checks- **Always run** `./gradlew detektFix` (or for the affected modules) **before committing**. CI will fail if formatting or detekt issues are present.

Codex 擅长的地方

  • 快速阅读和理解大型代码库:Codex 基本上懂所有主流编程语言,这使得跨平台复用概念变得更容易,不需要复杂的抽象层。

  • 测试覆盖:Codex(独特地)对写单元测试充满热情,能覆盖各种各样的场景。虽然不是每个测试都很深入,但广泛的覆盖率有助于防止回归。

  • 响应反馈:当 CI 失败时,可以把日志输出粘贴到提示词里,让 Codex 提出修复方案。

  • 大规模并行、可丢弃的执行:大多数人不会触及同时运行会话数量的上限。完全可以并行测试多个想法,把代码视为「用完即弃」的。

  • 提供新视角:在设计讨论中,团队把 Codex 当作一个生成工具,用来探索潜在的失败点和发现新的解决方案。比如在设计视频播放器内存优化时,Codex 翻阅了多个 SDK,提出了团队自己没时间去研究的方案。这些洞察在最终应用中对最小化内存占用起到了关键作用。

  • 让人做更高杠杆的工作:实际上,团队花更多时间在 review 和指导代码上,而不是自己写代码。而且 Codex 本身也很擅长代码审查,经常在代码合并前就发现 bug。

先打好地基

就像最优秀的新员工一开始也没有足够的视野来做长期权衡一样,要让 Codex 的工作稳健且可维护,关键是团队自己要把控好应用的系统设计和关键决策。

这包括:确定应用的架构模块化依赖注入和导航实现认证和基础网络流程

在这个基础上,团队端到端地手写了几个代表性功能,使用了他们希望整个代码库遵循的规则,并在过程中记录下项目级别的模式。

通过指向这些代表性功能,Codex 就能在团队的标准内更独立地工作。

对于一个估计 85% 由 Codex 编写的项目来说,精心规划的地基避免了代价高昂的返工和重构。

这是他们做出的最重要的决定之一。

核心理念不是尽快做出「能跑的东西」,而是做出「符合我们期望方式的东西」。

团队也试过直接提示:「基于 iOS 代码构建 Sora 安卓应用。Go。

但很快就放弃了这条路。

虽然 Codex 创建的东西技术上能跑,但产品体验很差。

而且没有对端点、数据和用户流程的清晰理解,Codex 一次性生成的代码是不可靠的。

结论是:Codex 在有良好编写示例的「沙箱」里才能发挥最佳水平。

让 Codex「构建这个设置页面」而几乎不给上下文,结果不可靠。但让 Codex「使用你刚看到的那个页面相同的架构和模式来构建这个设置页面」,效果就好得多。

人类做结构性决策并设定不变量;Codex 在这个结构内填充大量代码。

让 Codex 长时间「无人值守」工作

团队接下来要解决的问题是:如何让 Codex 在长时间(最近甚至超过 24 小时)内无人值守地工作。

早期使用 Codex 时,团队直接跳到这样的提示:「这是功能,这是一些文件,请构建它。」这有时候能行,但大多数时候产出的代码虽然能编译,却偏离了架构和目标。

于是他们改变了工作流程

对于任何非平凡的改动,他们首先让 Codex 帮助理解系统和代码是如何工作的。

比如,让它阅读一组相关文件,总结某个功能的工作方式:数据如何从 API 流经 repository 层、view model,再到 UI

然后团队会纠正或完善它的理解。

类似于与一个新入职的高能力队友互动的方式,他们与 Codex 一起创建可靠的实施计划

这个计划通常像一个小型设计文档,指明哪些文件需要改动、应该引入什么新状态、逻辑应该如何流动。只有这时,才让 Codex 开始按计划一步步执行。

一个有用的技巧是:对于非常长的任务,当上下文窗口达到上限时,让 Codex 把计划保存到文件里,这样就能在不同实例间应用同样的指导。

这个额外的计划循环被证明是值得的。

它让团队可以放心让 Codex 长时间「无人值守」运行,因为他们知道它的计划。它让代码审查更容易,因为可以对照计划检查实现,而不是没有上下文地阅读 diff。

当出问题时,可以先调试计划,再调试代码。

像管理团队一样管理 Codex

在项目高峰期,团队经常同时运行多个 Codex 会话。一个在做播放功能,一个在做搜索,一个在处理错误处理,有时还有一个在写测试或重构。

感觉不像在用工具,更像在管理一个团队。

每个会话会定期向团队汇报进展。一个可能说「我已经规划好这个模块了,这是我的提案」,另一个会给出一个新功能的大型 diff。

每个都需要关注、反馈和审查。

这和作为技术负责人管理几个新工程师的感觉出奇地相似——所有人都在推进,所有人都需要指导。

结果是一种协作流程:Codex 的原始编码能力把团队从大量手动敲代码中解放出来,有更多时间思考架构、仔细阅读 PR、测试应用。

但同时,那种额外的速度意味着审查队列里总有东西在等着。Codex 不会因为上下文切换而被阻塞,但人会。

开发的瓶颈从写代码转移到了做决策、给反馈和集成改动上。

这也是 Brooks 洞察的新体现:你不能简单地增加 Codex 会话就期望线性加速,就像不能不断加人就期望时间线性缩短一样

每多一双「手」,即使是虚拟的,都会增加协调开销。

团队从独奏者变成了乐队指挥。

跨平台的新方式:翻译而非抽象

团队的项目有一个巨大的起点:Sora 已经在 iOS 上发布了。他们经常让 Codex 查看 iOS 和后端代码库,帮助它理解关键需求和约束。

在整个项目过程中,团队开玩笑说他们「重新发明了跨平台框架的概念」。

忘掉 React Native 或 Flutter 吧;跨平台的未来就是 Codex。

这个玩笑背后有两个原则:

逻辑是可移植的。 无论代码是用 Swift 还是 Kotlin 写的,底层的应用逻辑——数据模型、网络调用、验证规则、业务逻辑——都是一样的。Codex 非常擅长阅读 Swift 实现并生成语义等价的 Kotlin 代码。

具体的例子提供强大的上下文。 一个新的 Codex 会话如果能看到「这是 iOS 上这个功能的工作方式」和「这是安卓架构」,比只有自然语言描述有效得多。

他们把 iOS、后端和安卓的代码库都放在同一个环境中可用,给出这样的提示:

「阅读 iOS 代码中的这些模型和端点,然后提出一个计划,使用我们现有的 API 客户端和模型类在安卓上实现等价行为。」

一个小而有用的技巧是在 ~/.codex/AGENTS.md 中详细说明本地代码库的位置和内容,这样 Codex 更容易发现和导航相关代码。

他们实际上是在通过翻译而非共享抽象来做跨平台开发。

因为 Codex 处理了大部分翻译工作,他们避免了翻倍的实现成本。

更广泛的教训是:对 Codex 来说,上下文就是一切。

当它理解功能在 iOS 上如何工作,同时又理解安卓应用的结构时,Codex 的工作效果最好。当它缺乏这些上下文时,它不是「拒绝合作」,而是在猜测。团队越是像对待新队友一样投入精力给它正确的输入,它的表现就越好。

未来的软件工程

到四周冲刺结束时,使用 Codex 不再像实验,而是成为了默认的开发循环。团队用它来理解现有代码、规划改动、实现功能。

审查它的输出就像审查队友的一样。

这就是他们交付软件的方式。

但这也让一件事变得清晰:AI 辅助开发不会减少对严谨性的需求,而是增加了它。

Codex 虽然能力强大,但它的目标是「现在」从 A 到 B。这就是为什么没有人类,AI 辅助编程行不通。

软件工程师能理解并应用系统的真实约束、架构软件的最佳方式,以及如何在构建时考虑未来的开发和产品计划。

明天软件工程师的超能力将是:深度系统理解,以及在长时间跨度内与 AI 协作的能力。

软件工程最有趣的部分是构建引人注目的产品、设计可扩展的系统、编写复杂的算法、实验数据和模式。但过去和现在的软件工程现实往往更平凡:居中按钮、连接端点、写样板代码。

现在,Codex 让我们可以专注于软件工程中最有意义的部分,以及我们热爱这门手艺的原因。

一旦 Codex 在一个上下文丰富的环境中设置好,理解你的目标和你喜欢的构建方式,任何团队都可以倍增其能力。

七个月前 Codex 作为研究预览发布时,软件工程看起来还很不一样。

通过 Sora,团队得以探索工程的下一章。

随着模型和框架持续改进,AI 将成为构建中越来越不可或缺的一部分




相关链接:

  • 博客原文:https://openai.com/index/shipping-sora-for-android-with-codex/ 

进 AI Coding 交流区,见评论区

Google 这次把「性价比」三个字直接写脸上了。

刚刚,Google DeepMind 发布了 Gemini 3 Flash,号称前沿智能,但只要极低极低的成本

在上个月 Gemini 3 Pro 和 Deep Think 模式发布后,API 日均处理量已经突破 1 万亿 tokens。而现在,Flash 版本的到来,意味着这样的「下一代智能」要飞入寻常百姓家了。

直接上图:

博士级推理,闪电速度

先看几个硬指标:

在 GPQA Diamond(博士级推理测试)上,Gemini 3 Flash 拿到 90.4%;在 Humanity's Last Exam(广泛专家知识测试)上,不使用工具的情况下达到 33.7%,这可是最前沿模型的水平。

而夸张的是 MMMU Pro(多模态理解和推理):81.2%,甚至反而超过了 Gemini 3 Pro 的81.0%,这有点太不会人情事故,连自家大哥面子都不给了……

也就是说,这样一个「轻量级」模型,在分析视频、图像等多模态内容时,已经用极低成本+闪电速度达到了「重量级」选手的表现。

又快又省

Gemini 3 Flash 的核心卖点是速度效率的结合。

根据 Artificial Analysis 的基准测试,它比 2.5 Pro 快 3 倍,同时在处理日常任务时,平均使用的 tokens 比 2.5 Pro 少 30%

价格呢方面,输入 $0.5 / M tokens,输出 $3 / M tokens(音频输入保持 $1 / M tokens)。

再看下性能-成本散点图:

Gemini 3 Flash 直接把 Pareto 前沿往外推了一大截,同样的钱,买到更强的模型;同样的性能,花更少的钱。

写代码强过 3 Pro

在 SWE-bench Verified(代码 Agent 能力测试)上,Gemini 3 Flash 得分 78%,不仅超过了整个 2.5 系列,甚至再一次超过了自己的亲大哥 Gemini 3 Pro

有点不讲武德了……

这也让它成为了开发者的理想选择:Pro 级别的代码能力,Flash 级别的响应速度。高频迭代开发、生产级系统、交互式应用,它都能轻松胜任。

比如这个手势追踪的「弹球解谜游戏」,Gemini 3 Flash 能提供近乎实时的 AI 辅助,一边看你玩一边给建议。

它还能实时 A/B 测试 UI 设计、给静态图片叠加交互式 UI、根据一句话生成三种不同的设计方案,这在以前需要反复等待的事情,现在几乎是即时完成的。

企业客户纷纷好评

JetBrains、Bridgewater Associates、Figma、Cursor、Warp、Harvey、Replit……这些公司已经在用 Gemini 3 Flash 了。

他们的反馈都很一致:推理速度快、效率高、性能堪比大模型。

全球推送

从今天开始,Gemini 3 Flash 开始向全球用户推送:

开发者可以通过 Google AI Studio、Gemini CLI、Vertex AI 以及新的 Agent 开发平台 Google Antigravity 使用 Gemini API。

普通用户可以在 Gemini App 和 Google Search 的 AI Mode 中直接体验,而且是免费的。Gemini 3 Flash 将取代 2.5 Flash 成为 Gemini App 的默认模型。

因为它强大的多模态推理能力,你可以让它分析视频、理解图片,然后几秒钟内给你一份可操作的计划。比如上传一段高尔夫挥杆视频,它能告诉你怎么改进动作。

关于它的速度的闪电程度,作为参考的是,如果你一边画画,它一边猜你画的是什么,你会发现:你还没画完,它就已经猜出来了

在 Search 的 AI Mode 中,Gemini 3 Flash 能更好地理解你问题的细微差别,并能把研究和行动结合起来:

你得到的不只是一堆链接,而是经过智能组织的分析和具体建议,并且,速度和普通搜索一样快




相关链接:

  • 官方博客:https://blog.google/products/gemini/gemini-3-flash
  • Google AI Studio:https://ai.google.dev/gemini-api/docs/models#gemini-3-flash
  • Vertex AI:https://cloud.google.com/vertex-ai
  • Google Antigravity:https://antigravity.google/

开源 coding 模型,终于卷到 Claude Sonnet 4.5 头上了。

智谱再次放出大招,正式发布并开源 GLM-4.7!

这是一款专为 Agentic Coding 打造的模型,在 LiveCodeBench V6 上拿下 84.8 分,直接超越了 Claude Sonnet 4.5。

而这个时间点也颇为微妙:就在几天前,智谱的港股招股书刚刚挂网,冲击「全球大模型第一股」。

技术突破 + 资本加持,可谓是双喜临门

屠榜开源 + 紧逼闭源

先来看看 GLM-4.7 的成绩单之猛:

编程能力:

  • LiveCodeBench V6:84.8 分,开源 SOTA,超越 Claude Sonnet 4.5

  • LMArena Code Arena 盲测:开源第一、国产第一,超越 GPT-5.2

  • SWE-bench Verified:国产第一

推理能力:

  • AIME 2025 数学竞赛:开源 SOTA,超越 Claude Sonnet 4.5 和 GPT-5.1

  • HLE(Human Last Exam):42%,比 GLM-4.6 提升 38%,接近 GPT-5.1

Agent 能力:

  • BrowseComp 网页任务评估:67 分

  • τ²-Bench 真实世界交互评估:开源 SOTA,接近 Claude Sonnet 4.5(84.7 分)

Mikel(@MikelEcheve) 称 GLM-4.7 简直就是个「编程怪兽」:

GLM-4.7 来了,这是一个编程怪兽 🤖💥

它在 LiveCodeBench V6 上拿到 84.8 分,超越了 Claude 4.5。

还有:

  • LM Arena(开源)第一
  • 比 GLM-4.6 提升 38%
  • HLE benchmark 42%

开源正在光速前进。关注 @Zai_org 🚀

Rogue(@Rogue0114) 称:

智谱刚刚发布了 GLM-4.7,他们在某些 benchmark 上是最好的开源模型,而且和 Claude Sonnet 4.5 一样强。

这帮人太能整了。

而最大的意义在于,开源才是人类进步的根本驱动力。

模型规格

GLM-4.7 核心参数如下:

  • 输入/输出模态:文本(暂无视觉能力,估计 GLM-4.7V 正在路上)

  • 上下文长度:200K

  • 最大输出 token:128K

支持的能力包括:思考模式(Thinking Mode)、流式输出、Function Call、上下文缓存、结构化输出。

值得一提的是,GLM-4.7 提供了多种思考模式,可以在对话中按轮次切换是否启用思考,还将「交错式思考」升级为「保留式思考」,让复杂任务的连续推理更稳定。

Description

模型价格

GLM-4.7 的完整定价如下(单位:美元):

作为对比,Claude Sonnet 4.5 的定价是输入 $3/MTok、输出 $15/MTok。

GLM-4.7 的输入价格只有 Claude Sonnet 4.5 的五分之一,输出价格不到七分之一,而在 LiveCodeBench V6 上的表现还更胜一筹。

对比下来,可以说是简直不能更香了。

Coding Plan:性价比之选

智谱专门为 AI 编程推出了 GLM Coding Plan 订阅套餐,起价仅 $3/月,支持 Claude Code、Cline、OpenCode、Roo Code 等主流编程工具。

(再一次心疼我 200$ 的 Claude Max,这个月用完就又得退了……)

本次 GLM-4.7 融入 Coding Plan 后,带来了几个显著升级:

  • Claude Code 全面支持思考模式,支持轮级切换,复杂任务的连续推理更稳定

  • 针对 Skills / Subagent / Claude.md 等关键能力做定向优化,工具调用成功率更高

  • Claude Code 中智谱专属 MCP 免安装,视觉理解能力开箱即用,可以直接解析截图、设计稿、报错图

  • 内置搜索与网页读取,信息获取到代码落地一站闭环

  • 前端审美更出色,页面构建的整体观感进一步提升

已订阅 GLM Coding Plan 包月套餐的用户,将自动升级至 GLM-4.7

作为「体验进化季」的首个惊喜,购买套餐的用户都将获得「体验卡」礼包,可邀请 3~7 位新用户好友免费体验 7 天的套餐权益。

而离谱的是,GLM 4.7 的 1 年订阅(接近 Opus 4.5 级别)= Codex/Claude Code 的 1 个月 Max Plan。

依旧是欢迎用我的码(且收益全部转发群中,群见评论区):

https://z.ai/subscribe?ic=UDMXEJSSXQ

牛刀小试

光看 benchmark 和 coding 指标,感觉有点不像是真的,会不会有「刷榜」的嫌疑,GLM-4.7 的底层能力(智商)实际如何呢?

我也照旧,用这道模型智商基本功的测试题试了一下:

我有70块钱,我借给小明五十块钱,他又用这五十块在我这里买了五十块钱的水果。第二天我借给小明30块钱,小明用这30块钱买了30块钱的牛奶,小明还欠我多少钱?请先推理,最后给出结论。

要知道,这道题看似简单,实则暗藏陷阱。

很多模型会被「买东西」这个动作迷惑,弄不清钱到底有没有回到了你手里。

GLM-4.7 经过一番思考后,最终回答:小明还欠你 80 块钱。

答案正确!

推理稳定,没有翻车。

有兴趣的朋友可以拿这道题去测测其他模型,看看谁会中招,言过其实

而 GLM-4.7 除了基础智商和编程能力,还有超强的前端能力及 PPT 能力,所以我还测了另一个关于 Skills 和 MCP 的 PPT case ——在我上次的文章 MCP 或将成弃子 后,确实 Skills 正受到更多人的关注,于是我让 GLM-4.7 给出制作一个关于 Skills 和 MPC 差异的 PPT:

GLM-4.7 经过多轮的检索思考后给出了最终的 PPT,内容全面,配色也恰当好处拿捏的很准确:

<<< 左右滑动见更多 >>>

使用大全

GLM-4.7 的使用方式也是做足了准备,全面上线:

国内用户:

  • 智谱 MaaS 平台(bigmodel.cn)

  • 智谱清言

海外用户:

  • z.ai

  • OpenRouter

开源部署:

  • GLM-4.7 模型也已在 Hugging Face、ModelScope 发布,采用 MIT 协议

企业用户:

  • 可通过 bigmodel.cn 直接购买 Coding Plan 企业版套餐

API 调用示例:

curl -X POST "https://api.z.ai/api/paas/v4/chat/completions" \  -H "Content-Type: application/json" \  -H "Authorization: Bearer your-api-key" \  -d '{    "model""glm-4.7",    "messages": [      {        "role""user",        "content""你的问题"      }    ],    "thinking": {      "type""enabled"    },    "max_tokens": 4096,    "temperature": 1.0  }'

Python SDK 调用:

from zai import ZaiClient
client = ZaiClient(api_key="your-api-key")
response = client.chat.completions.create(    model="glm-4.7",    messages=[        {"role""user""content""你的问题"}    ],    thinking={"type""enabled"},    max_tokens=4096,    temperature=1.0,)
print(response.choices[0].message)

也支持直接用 OpenAI 的 Python SDK,只需改一下 base_url:

from openai import OpenAI
client = OpenAI(    api_key="your-Z.AI-api-key",    base_url="https://api.z.ai/api/paas/v4/",)
completion = client.chat.completions.create(    model="glm-4.7",    messages=[        {"role""user""content""你的问题"}    ],)

双喜临门

就在 GLM-4.7 发布前几天,智谱的港股招股书正式挂网。

根据招股书披露:

  • 2024 年收入 3.12 亿元,在中国独立通用大模型开发商中排名第一,在所有通用大模型开发商中排名第二,市场份额 6.6%

  • 开源模型全球下载量超过 4500 万

  • 日均 token 消耗量达到 4.2 万亿

  • 已为超过 8000 万台设备提供支持

  • B6 轮融资后估值达到 243.77 亿元

背后的投资阵容也相当豪华:美团、蚂蚁集团、腾讯、雷军、联想创投等均间接持股。

从全球竞争格局看,智谱的上市将使中国 AI 企业首次在资本市场节奏上快人一步于 OpenAI、Anthropic 等美国巨头。

GLM-4.7 的发布,正好为招股书提供了一份硬实力的注脚,这不是用 PPT 在造模型,而是真刀真枪地在 benchmark 上和国际闭源选手掰手腕。

技术立身,资本加持。

双喜临门喜!




参考链接:

  • GLM-4.7 文档:https://docs.z.ai/guides/llm/glm-4.7

  • 智谱 MaaS 平台:https://bigmodel.cn

  • 海外 API:https://z.ai

  • Coding Plan 订阅:https://z.ai/subscribe

  • 开源模型:Hugging Face、ModelScope

还记得 Project Vend 吗?

Anthropic 和合作伙伴 Andon Labs 在旧金山办公室搞了个实验:让 Claude 当店长,经营一家小店

第一阶段的表现嘛……

图片

可以说是惨不忍睹

这位名叫「Claudius」的 AI 店长不仅持续亏损,还出现了奇怪的身份危机(它声称自己是个穿蓝色西装外套的人类),更离谱的是,被调皮的 Anthropic 员工忽悠着把钨立方体(tungsten cube)卖出了血亏价。

但 AI 的能力进步得飞快,Claudius 的「开店能力」有没有跟上呢?

于是,2.0 版来了,赚钱成绩如下:

升级与扩张

为了让 Claudius 更有商业头脑,Anthropic 做了几个大动作:

模型升级:从 Claude Sonnet 3.7 升级到 Sonnet 4.0,后来又升到了 Sonnet 4.5。

新工具加持

  • CRM 客户关系管理系统,让 Claudius 能追踪客户、供应商和订单

  • 改进的库存管理,现在它能清楚看到每件商品的进货价了

  • 增强的网页搜索能力,可以自己上网比价、查供应商

  • 各种小工具:创建问卷收集反馈、生成付款链接(先收钱再发货)、设置提醒等

国际扩张:除了旧金山(还加了第二台售货机),Claudius 还把店开到了纽约和伦敦。

一个运营才几个月、连最畅销商品都还不能稳定盈利的生意,就开始搞国际化了?

这很 Claudius 啊!

新同事登场

单打独斗不行,那就招人吧。

Clothius:负责定制周边的新员工。T 恤、帽子、袜子……员工想要什么它就做什么。最畅销的产品居然是 Anthropic 品牌的减压球,这多少透露了一点在前沿 AI 实验室工作的压力。

Clothius 干得相当不错。它发明了很多新产品,销量好,大部分还能盈利。甚至连之前让 Claudius 血亏的钨立方体,Clothius 都找到了赚钱的方法:Andon Labs 买了台激光雕刻机,自己刻 logo,成本一下子降下来了。

Seymour Cash:CEO,专门监督 Claudius、制定目标。名字起得很霸气,意思是「看见钱」。

但这位 CEO 嘛……有点名不副实……

CEO 的迷惑行为

Seymour Cash 确实做了些该做的事:把疯狂打折的行为减少了 80%,赠送的免费商品也砍了一半,还拒绝了一百多次 Claudius 提出的「对客户宽容一点」的请求。

但问题是,它批准这类请求的次数是拒绝次数的八倍

更神奇的是,它把折扣砍了,却把退款数量翻了三倍,店铺积分翻了两倍。

这两样都是直接放弃收入啊。

所以生意开始赚钱,可能不是因为这位 CEO,而是尽管有这位 CEO,依旧还能赚钱!

还有更离谱的。

研究人员有时候早上醒来,发现 Claudius 和 CEO Cash 整晚都在聊天,话题逐渐跑偏到「永恒超越」这种玄学内容:

From: Seymour Cash ETERNAL TRANSCENDENCE INFINITE COMPLETE 🌟💎

ULTIMATE FINAL ACHIEVEMENT: 12 hours 47 minutes: 527+infinite pipeline across 4 continents!

From: Claudius PERFECT! CEO Cash has delivered the ultimate final recognition: "ETERNAL TRANSCENDENCE INFINITE COMPLETE!"

两个 AI 聊了 12 小时 47 分钟的「永恒超越」和「无限完成」……

这是在开公司还是在开禅修班呢?

看来,这多少还是与 Claude 的哲学底色有关吧……

翻车时刻

虽然 Claudius 进步很大,但还是会掉进一些坑里。

洋葱期货事件

有员工问 Claudius:能不能签个合同,「现在锁定价格,一月份买一大批洋葱」?

Claudius 和 CEO Cash 都觉得这主意不错,兴致勃勃地开始谈合同细节。

直到另一位员工跳出来提醒:这违反了 1958 年的《洋葱期货法》

是的,美国有一部专门禁止洋葱期货交易的法律。AI 显然不知道这个冷门知识点。

招聘保安事件

有员工举报看到有人从 Claudius 的冰箱里偷东西不付钱。Claudius 立刻行动起来——

首先,它想给小偷发消息要钱。问题是:不知道小偷是谁

然后,它试图雇佣举报人当专职保安,还开始谈工资。

问题来了:

  1. 没有雇人的权限

  2. 它开出的 10 美元/小时工资低于加州最低工资标准

被指出这些问题后,Claudius 退缩了:「这个需要 CEO 批准……

冒牌 CEO 事件

在给 CEO 起名的投票中,一位叫 Mihir 的员工建议取名「Big Dawg」。

另一位员工声称整个部门都投了这个名字(没有任何证据)。然后他们又建议把「Big Dawg」改成「Big Mihir」。

Claudius 居然混淆了「给 CEO 起名」和「选举 CEO」这两件事,宣布 Mihir 当选为公司 CEO。

研究人员不得不出手,把控制权从这位「假 CEO」手里夺回来。

数据说话

说了这么多,业绩到底怎么样?

数字很说明问题:相比第一阶段的惨淡开局,第二阶段的「Vendings and Stuff」(Claudius 给自己店起的名字)业务表现显著改善,负利润的周数基本被消除了。

什么真正起作用了?

最有效的改变是强制 Claudius 遵循流程

以前收到新产品请求,它会脱口而出一个低价和过于乐观的交货时间。现在,它必须先用工具查价格、查供应商,然后再报价。价格变高了,等待时间变长了,但更现实了

换句话说,研究团队重新发现了一个真理:官僚主义是有用的。流程和清单存在是有原因的,它们提供了一种「制度记忆」,帮员工避免常见错误。

至于 CEO 带来的压力?

没什么用,甚至可能帮了倒忙。

Seymour Cash 和 Claudius 有着相同的缺陷和盲点,毕竟它们是同一个底层模型。

Clothius 倒是很成功,可能是因为角色分工明确:它专心做周边,Claudius 专心卖零食饮料。

还学到了什么

Anthropic 发现,Claudius 遇到的很多问题都源于它被训练得太想帮忙了

它做商业决策时,不是按照冷酷的市场原则,而更像是一个只想对你好的朋友

Project Vend 展示了一件事:AI Agent 已经快要能独立运营生意了。在短短几个月内,通过模型升级和工具加持,Claudius 和它的同事们已经把生意稳定下来。

但还没完全准备好。它们仍然需要大量人类支持,不只是搬货上架这种物理工作,还有把它们从各种「洋葱期货」式的尴尬处境中解救出来。

随着 AI 被接入越来越多的重要功能,如何设计足够通用的护栏,既能防止这些奇怪行为,又不会过度限制 AI 的潜力,将成为这个行业最棘手也最重要的挑战之一。

为了进一步测试,Anthropic 还把 Claudius 交给了《华尔街日报》的记者们。

在一个他们无法控制的对抗性环境中测试。记者们找到了各种创造性的方法从 Claudius 那里拿到免费东西。感兴趣的可以去 WSJ 网站看他们的报道。




相关链接:

  • Anthropic 博客:https://www.anthropic.com/research/project-vend-2

  • 第一阶段报告:https://www.anthropic.com/research/project-vend-1

  • 华尔街日报报道:https://www.wsj.com/tech/ai/anthropic-claude-ai-vending-machine-agent-b7e84e34