AI TrendTrackers

下面这段话： 除了忽略训练成本之外，Amodei 在论证中另一个非常可疑的假设，是推理（inference）的毛利率。在他的“风格化（stylized）”例子里，他假设毛利率为 67%，而这恰恰直接决定了他们是否有能力为下一代模型训练提供资金。可当资金更充裕的竞争对手明明知道，他们可以对 Anthropic 施加极大的压力，把推理毛利率压到……比如 30% 时，我们怎么还能假设毛利率会一直这么高？如果 Anthropic 无法从当下这一代模型获得足够的毛利润，那它训练下一代模型的手脚就会被绑住。 在我发布那篇文章三天后，《The Information》报道了 OpenAI 的财务情况，其中有一段摘录让我特别在意： “OpenAI 告诉投资者，其运行 AI 模型的成本——也就是推理（inference）——在 2025 年翻了四倍。因此，该公司调整后的毛利率（adjusted gross margin）——定义为收入减去推理成本——从前一年的 40% 下降到 33%。这低于其对 2025 年设定的 46% 毛利率目标。” 《The Information》提到，OpenAI 认为毛利率下降主要是因为“公司不得不在最后一刻购买更昂贵的算力，以应对其聊天机器人和模型需求高于预期的情况”。这一点确实在某种程度上支持了 Dario Amodei 关于推理与训练之间“地狱级需求预测（hellish demand prediction）”的观点。但很难不去想：即便你把需求预测做得更好，找到“正确平衡”可能仍然同样困难，这未必能缓解毛利率压力。 当然，OpenAI 随后面不改色地承诺，他们预计未来 5 年推理毛利率会提升到 52%–67%。我要强调这一点：**在今天，OpenAI（或任何其他公司）并不能单方面决定今年的毛利率是多少，更别说决定明年、甚至 2030 年的毛利率了。**除了“地狱级需求预测”的挑战之外，模型竞赛本身仍然极其竞争激烈，而这正是当下毛利率最核心的驱动力。 毛利率的本质：定价权与成本结构 归根结底，毛利率的提升主要取决于两件事： 即便你能对推理需求做到完美预测，你资金更雄厚的竞争对手仍然可以选择维持低价——因为他们有许多其他内部现金流来源。这当然可能迫使 OpenAI 与 Anthropic 更快地下调 API 价格，远快于他们愿意的速度。 当更富有的竞争对手（例如 Alphabet）不仅资金更充足，而且成本结构还更优时，这个问题会进一步恶化。原因是…

基于与 OpenAI Codex 团队工程负责人一次对话的洞察：他们如何协作、如何使用 AI、团队结构、开发理念，以及更多内容 引言 AI 不再只是工程师手里的工具，它也正在深刻影响工程团队的组织结构、决策方式，以及软件是如何被构建出来的。 我在许多初创公司和中型公司里都看到了这种变化：它们试图通过创建“AI 原生”的工程团队来调整组织结构。但在我看来，真正把这件事做到位的团队并不多，而 OpenAI 的 Codex 团队是其中最典型、最彻底的例子之一。 在 Codex 应用、IDE 扩展、以及开源编码智能体等产品背后，是一个相对精简的小团队——大约 40 人——却以极高的自治度、速度与信任运行。他们的工作覆盖低层系统工程、大规模分布式基础设施、产品设计、研究与用户体验等多个方向，并且在几乎所有工作中都大量使用 AI。 Codex 团队最有趣的地方不仅是他们做什么，而是他们如何做。他们把 AI 当作工作流的核心层：从规划与入职培训，到代码审查、测试、优先级管理，AI 都深度参与其中。 Codex 团队规模约 40 人 Codex 团队大约 40 人，内部又划分为多个更小的子团队，分别负责不同项目，比如：开源编码智能体、Codex 的 IDE 扩展、Codex 应用本体，以及其他项目。 他们强调授权与本地决策。整体感觉更像“现代版本的贝尔实验室（Bell Labs）”。 个体被充分信任去做决定，因为变化的速度要求他们必须如此。 整个 Codex 团队只有 1 位产品经理，2 位设计师，其余大多是具备不同专长的工程师。 Thibault 提到一个例子，能非常具体地说明他们的产品经理为什么效率惊人。 他们的产品经理为什么能如此高效 Codex 团队的产品工作几乎由一位产品经理在驱动。这位 PM 借助 Codex，把自己“扩展”成了类似…

编译器在计算机科学里占据着一个特殊的位置。它是计算机科学教育中的经典课程。亲手写一个编译器，几乎像是一种成人礼。因为你必须直面软件到底是如何工作的：语言、抽象、硬件，以及人类意图与机器执行之间的边界。 编译器曾经帮助人类与机器对话。如今，机器开始帮助人类构建编译器。 我职业生涯中很大一部分时间都在做编译器与编程语言相关的工作，所以当 Anthropic 发布 Claude C Compiler（简称 CCC）时，我格外留意。我的基本结论很简单：这是真正的进步，是行业的一个里程碑。我们并没有走到世界末日，但这也绝不是纯炒作，所以大家先深呼吸一下。 AI 能构建一个 C 编译器并不“彻底革命”，但它确实揭示了 AI 编程已经走到什么程度，以及下一步可能走向哪里。 在展开之前，我先给出我的核心要点总结： 什么是编译器？为什么它能成为 AI 的基准测试？ 要理解 Claude C 编译器为什么重要，我们得先理解：为什么编译器本身是一个如此“揭示智力”的测试对象——无论是对人类还是对人工系统。 编译器位于多个困难领域的交叉点：形式语言设计、大规模软件架构、严苛的性能约束，以及毫不留情的正确性要求。 大多数应用程序可以容忍一些 bug，编译器不行。一个错误的变换可能悄无声息地产生错误程序，影响无数用户的生产力。编译器的每一层都必须维持严格的不变量，并与其他层配合协作。 历史上，这也是编译器成为计算机科学教育“成人礼”的原因。它迫使工程师跨越抽象层思考：把文本变成结构，把结构变成意义，把意义变成经过优化的机器行为。 这个过程映射到更深的一件事：把人类意图翻译成精确执行。这也是为什么编译器对于 AI 系统整合来说，是一个独特而有趣的基准。 更早一代的 AI 编程工具，在局部任务上已经很厉害：写函数、生成脚本、补齐缺失代码。这类任务主要考验模式识别与短程推理。 Claude C 编译器则代表了不同层级的进展。它展示了一个 AI 系统能够在整个工程系统范围内保持连贯性：协调多个子系统、维持架构结构、通过测试与失败在时间维度上迭代逼近正确性，并在复杂反馈回路中运作。AI 正在从代码补全走向工程参与。 更深层的原因在于：编译器的工程架构通常高度清晰且结构化。编译器有分层抽象、一致命名、可组合的 pass，以及确定性的反馈标准（“能工作”或“不能工作”，成功标准很清楚）。这些属性让编译器对人类可学，也让在海量源码上训练的机器学习系统同样更容易“学会”。 从这个角度看，CCC 其实也是对几十年软件工程实践的一次验证：编译器工程师发展出的抽象足够结构化，以至于机器如今能够在其中推理并行动。这是一个非常惊人的里程碑。但它同样暗示着一个重要限制。 走进 Claude C 编译器内部 CCC 最有趣的一点在于：Anthropic 公开了完整的源码历史。与许多 AI 演示不同，这不是一个“包装好的成果”或单一基准分数，而是一个任何人都能检查的工程产物：整个仓库，包括提交历史、设计文档与未来计划，都可以直接审阅。这意味着我们能真正研究系统是如何构建一个编译器的。我也确实花了一些时间做了这件事。 第一个重要提交几乎是“一次性”把系统的基本架构定了下来。从一开始，CCC 就遵循经典编译器结构。仓库里的主要子系统都配有相当出色的设计文档，包括： 整个仓库里做出的选择，几乎都反映了成熟的编译器实践：大学课程里教的东西，以及…

引言 你的 PostgreSQL 数据库不断增长，即使表中的行数基本保持不变。磁盘占用持续上升，查询开始变慢，你开始怀疑到底发生了什么。 这不是 Bug——这叫做 bloat（膨胀），而且它是 Postgres 核心设计的一部分。 要理解它为什么会发生，我们必须跟随一行数据的生命周期：从它被写入物理文件的那一刻开始，到它变成“死亡空间”为止。这段旅程始于最底层的物理存储结构：页（Page）与元组（Tuple）。 目录 1. 物理层：页与元组 Postgres 将表存储为磁盘上的文件，这些文件被划分为固定大小的页（8KB 块）。在每个页内部，存放的是 元组（tuple）——也就是你的行在磁盘上的物理版本。 可以把一个页想象成一个容量有限的盒子。当你插入一行数据时，Postgres 会把一个元组写入第一个有空闲空间的页。如果该页已满，就会分配一个新页并追加到表文件末尾。 每个元组不仅包含你的业务数据，还包含元数据，用于决定哪些事务可以看到这条数据（这将在 MVCC 部分解释）。 这种基于页的架构对膨胀的形成有关键影响： 💡 关键洞察 磁盘使用量由元组版本的总数决定，而不是你能查询到的行数。一个有 100 万行的表，如果存在大量死亡元组，可能和一个 1000 万行但干净的表占用同样的空间。 但页本身并不会导致膨胀。真正的根源，是 Postgres 如何处理并发：MVCC。 2. MVCC 与旧数据为何不会立即消失 Postgres 使用 多版本并发控制（MVCC），使读操作不会阻塞写操作，写操作也不会阻塞读操作。 机制很简单：不原地修改数据，而是创建新版本。 在物理层面发生的事情如下： UPDATE 不会修改原数据 当你更新一行时，Postgres 不会找到原有元组并修改它，而是创建一个全新的元组（可能位于不同页）。旧元组会被标记为过时，其 xmax 字段记录执行更新的事务 ID。 DELETE 不会真正删除数据 删除一行时，Postgres 不会从页中移除元组，只是设置 xmax 表示哪个事务删除了它。数据仍然留在磁盘上，占用空间。 结果：元组不断累积…

目前，Project Silica 的硬件距离商业化还差一步。 长期归档存储一直面临诸多挑战。我们希望存储介质既拥有极高的密度，又能在数百年甚至更长时间内保持稳定，并且理想情况下，在未被访问时不消耗任何能源。围绕这一目标，业界提出过许多设想——甚至连 DNA 都曾被考虑过——但其中一个最简单的思路，是将数据刻写进玻璃中。许多类型的玻璃在物理和化学层面都非常稳定，而且在其内部刻写结构相对容易。 此前已经有大量前期研究，展示了玻璃存储系统的不同技术环节。而在本周三发表于《Nature》的论文中，微软研究院宣布推出 Project Silica，这是一个完整的工作系统演示，能够在小块玻璃板中读写数据，其存储密度超过每立方毫米 1 Gigabit。 写入玻璃 我们通常认为玻璃易碎、容易破裂，甚至有人误以为玻璃会在几个世纪内缓慢“流动”——尽管后者其实是个神话。事实上，“玻璃”是一类材料，不同的化学物质都可以形成玻璃态结构。通过选择合适的原材料，可以制造出一种如研究人员所描述的那样“在热学和化学上高度稳定，并且能够抵抗水汽渗透、温度波动以及电磁干扰”的玻璃。当然，它仍然需要小心处理以避免物理损伤，但在长期存储的需求下，玻璃提供了理想的稳定性。 将数据写入玻璃，理论上只是“刻写”而已。但刻写传统上是一个缓慢的过程，这一直是挑战之一。飞秒激光的出现改变了这一局面。飞秒激光的脉冲持续时间仅为 10^-15 秒级别，每秒可发射数百万次脉冲。这不仅显著缩短了写入时间，还能将刻写精确聚焦在极小区域，从而提高潜在的数据密度。 读取数据则有多种方案。我们已经成功利用激光从光盘中读取数据，尽管速度较慢。理论上，只要能够识别玻璃内部刻写的微小结构，就可以实现读取。 在这些技术基础之上，Project Silica 在理论层面已经具备条件。关键问题在于：如何将这些技术整合为一个可运行的系统。出于谨慎考虑，微软决定以两种不同方式来回答这一问题。 构建真实系统 这两种方案的核心区别，在于如何将一个数据单元（称为“体素”，voxel）写入玻璃。 第一种体素方案基于“双折射”（birefringence）原理。双折射是指光子在材料中的折射率取决于其偏振方向。利用偏振激光，可以在玻璃中刻写出具有双折射特性的体素，并生成小于衍射极限的微结构。具体实现中，首先用一个激光脉冲在玻璃内部形成椭圆形空洞，然后再用第二个偏振脉冲诱导双折射特性。体素的“身份”由椭圆的方向决定。由于可以区分多个方向，每个体素就能够存储多于 1 bit 的信息。 另一种方法则通过调节激光脉冲能量，改变材料的折射程度。同样，这些体素也能够区分超过两种状态，从而在单个体素中存储多个数据位。 微软 Flight Simulator 的地图数据被刻写在 Silica 存储介质上。图片来源：Microsoft Research 读取数据时，Silica 使用能够识别折射率差异的显微镜技术。对于显微成像爱好者来说，这意味着他们采用的是“相差显微镜（phase contrast microscopy）”。显微成像的能力决定了在一块玻璃中可以堆叠多少层体素。刻写时，各层之间保持足够间距，确保显微镜每次聚焦时只对准单一层面。刻写过程中还会加入特殊标记符号，帮助自动化显微系统精确定位玻璃中的特定区域。随后系统逐层调整焦平面，逐步扫描堆叠结构并捕获包含不同体素层的图像。 为了分析这些显微图像，微软使用了卷积神经网络。该模型会整合位于焦平面内以及临近焦平面的图像数据。之所以有效，是因为邻近体素会以微妙方式影响当前体素的呈现形态，而 AI 系统在获得足够训练数据后，可以识别这些细微差异。 系统的最后一个关键部分是数据编码。Silica 在存储原始比特流之前，会加入低密度奇偶校验码（LDPC）进行纠错——这与 5G 网络所使用的纠错方式相同。随后，相邻比特被组合成符号，以充分利用体素能够存储多位信息的能力。当符号流生成后，数据就可以被写入玻璃。 性能表现 写入过程仍然是系统的瓶颈。因此，微软开发了能够同时使用四束激光对单块玻璃进行写入的硬件，并控制热量不过度积累。这使写入速度达到 66 兆比特每秒。研究团队认为，未来还可以再增加多达十几束激光。 之所以需要更高写入速度，是因为单块玻璃板的存储容量可高达 4.84TB（尺寸为 12 厘米 × 12…

是否可能发布得太多——或者太快？ 是的。大概是的。遗憾的是。 如今，只需要少数几个判断力不错、而且拥有大量 token 的人，就能完成过去需要整个产品组织才能完成的工作。结果是，由大语言模型（LLM）驱动的软件，比历史上任何时候都更便宜地被构建、也更快地扩展。 然而，一旦跨过某个阈值，产品速度就不再继续复利增长，而是开始彼此竞争。此时，限制你的不再是“你能发布多少新东西”，而是“你的用户能够吸收和采用多少”。 作为一家痴迷于快速发布的公司，我们对这个问题体会得非常深刻。因此，我想分享我们正在如何应对它，希望你也能从中受益。 约束理论（Theory of Constraints） 由于 PostHog 是一款工作工具，而不是生活方式品牌，即便是最狂热的用户，也不可能每周采用无限多个新功能。 在实践中，B2B SaaS 用户的采用节奏通常是： 其他一切，都会被忽略，直到有人明确解释清楚“为什么它重要”。这正是一个典型的瓶颈。 幸运的是，瓶颈是有解法的。制造业早已发现这一点，并将其总结为一个概念：约束理论（TOC）。其中有一条原则在这里尤其关键： 当上游产出增加，但下游能力没有相应提升时，系统就会失稳。 在我们的场景中，这种失配表现为： 当你意识到这一点，TOC 还能帮助你理解这种能力错配会带来哪些具体后果。 当发布速度超过采用速度时，会发生什么？ 1. 队列堆积 在制造业中，这种情况表现为库存积压；在软件中，它会形成一个“隐形待办清单”——你的工作已经完成了，但在“用户认知与理解”层面却尚未完成。 结果是影响力被稀释：发布了大量进展，但用户真正感受到的进展却更少。 2. 价值实现时间被拉长 随着这个隐形积压不断扩大，从“功能可用”到“真正有用”之间的时间差持续拉长。 你的团队不断发布新代码，但每一个新能力都需要更久才能被用户理解并真正使用。用户逐渐跟不上变化节奏；支持与销售花更多时间解释背景；市场营销开始追赶发布，而不是放大它们的影响。 3. 产品质量开始退化 当瓶颈被过载时，质量会通过被迫的权衡而下降。 在软件中，这种退化表现为： 你的产品不断变大、变强，但并没有成比例地变得更清晰。 那是不是意味着应该慢下来？ 绝对不是。 放慢速度，是公司在“没想法了”时才会做的事，而显然这并不是问题。幸运的是，约束理论对“不该做什么”说得也非常清楚： 提升非瓶颈环节，是在浪费资源。真正能改善系统的，是抬升瓶颈本身。 产品采用是一件“一个人一次”的事情，而每个用户的认知带宽都是有限的。所以真正的问题不是“要不要慢下来”，而是： 如何在不牺牲速度的前提下，提高采用能力？ 真正的瓶颈：用户注意力 如果你正在构建任何严肃的产品，并且正在用 AI 提高产出，你迟早都会撞上这堵墙。 在 PostHog，我们仍在不断摸索最佳路径，但有几件事已经变得异常清楚。 1. 把注意力当作稀缺资源（因为它确实是） 小型自治团队天然会围绕自己负责的那一小块产品进行优化。他们拥有某个功能，并持续把它做得更好。 但用户并不是以“功能所有权”的方式体验产品的。他们是通过有限的注意力，被动接收你所有的产品变化。 正是在这里，系统开始失衡。 常见的失败表现 这些方式能捕获的注意力是有限的。一旦发布速度足够快，就连最投入的用户也会产生“功能疲劳”。…

去网上搜一下“async agents（异步代理）”这个词，你会看到几十篇文章在用这个说法。那些少数愿意给出定义的文章，谈的似乎也都不是同一件事。它出现在产品发布里、HN 讨论串里、架构博客里，总是被很随意地提起，好像含义不言自明。所以我想搞清楚：到底哪一种定义才算“正确”。 我看到最常见的定义是：异步代理就是“会运行一段时间的代理”。一个长时间运行的任务会让人感觉“异步”。如果它能在你去上厕所或去续一杯水的时候继续干活，那就很像异步。确实，任务跑得足够久，你就有机会去做别的事。但那到底要跑多久才算？一个一秒就完成的代理和一个跑一小时的代理，前者是同步、后者才是异步吗？我能不能在运行代理之前加一个 sleep 语句，就把它变成异步代理？这听起来并不令人满意。 我反复遇到的第二种定义是：异步代理是“跑在云端的代理”。Devin 是远程运行的，所以它是异步。Claude Code 是本地运行的，所以它不是。但如果我开一台 EC2，SSH 进去，装上 Claude Code，然后在那台机器上运行——我是不是就把它“变成”异步代理了？工具本身没变，只是运行它的机器变了。这不可能是核心。 第三种定义则是：异步代理是“事件驱动”的——不是由你手动触发的那种。一条 PR 合并了，代理就启动。一个 cron 定时任务触发了，代理就到 Slack 给你发消息。这种感觉确实很异步，因为在那一刻不是你在敲命令。但 cron 也可以启动任何程序。触发是异步的，并不意味着被触发的程序本身就是异步。这是调度（scheduling），不是代理自身的属性。 这些定义都不能说“完全错”，但它们都不像定义。它们只是在描述一些特征——这些特征恰好与人们想指代的东西相关联。那我们回到最基本的概念。 什么是代理？什么是异步？正如 Simon Willison 所说，代理就是一个“在循环里调用工具的 LLM”。我会更进一步说：代理还需要“上下文的连续性”。如果我启动两个不同的 Claude Code 会话，那就是两个不同的代理。如果我在某个 Claude Code 实例里输入 /clear，我就杀死了一个代理并生成了一个新的代理。让它成为“那个代理”的，是上下文。 接下来是异步。技术上的定义是：事件会独立于主程序流程发生。关键洞见在于：一个 async 函数本身并不会“自带异步魔法”。它是否异步，取决于它相对于调用方（caller）的位置。调用方如果不等待，它就独立运行；调用方如果等待，它就等同于同步。异步的部分不在函数本身，而在调用方选择“不阻塞（not block）”的决定。 想想在代理出现之前，写代码是什么样：你在敲字；工作在发生。你停下敲字；工作就停。一次只能推进一个任务，一切都同步。 当编码代理出现后，它解锁了新东西：异步工作成为可能。你可以把工作委派出去，并不等待它完成。你可以给代理一个任务，去做午饭，然后回来看到一条完成的 PR。第一次，你的工作可以在你做别的事的时候继续推进。 但这并不意味着代理“天生异步”。你也可以转过头用同一个代理问一个很快的问题，然后等待它回答。在那一刻，你是同步地使用它。代理没有变，变的是你的行为。 所以大家总在说的“异步代理”到底是什么？它其实在观察者的眼里。真正的异步代理，其实是我们一路上交到的朋友。 不过认真说，没有任何代理是天生异步的。这取决于你等不等它做完。 异步地使用代理如果你选择异步地使用代理，你会解锁一个强大的能力：并发（concurrency）。你可以把多个任务委派给多个代理，让它们同时推进。但一旦这么做，你会撞上一个现实问题：它们都在你机器上的同一份代码库里工作。这不是真实工程团队的工作方式。每个工程师都有自己的电脑、自己的代码副本、自己的分支。 那为什么不让大家像 Google Docs 那样实时编辑同一份代码库呢？看起来似乎能消灭一整类问题：合并冲突、相互覆盖的修改、分支分叉……基本上就是 Git 逼你处理的那一堆事。协作式编码以前有人试过，而且没流行起来，是有原因的（Replit 早期就是这么做的）。问题在于：没有隔离，一个人的半成品就可能把另一个人的“可工作代码”弄坏。你需要让每个任务都活在它自己的环境里，这样它才能独立地构建、测试、验证。 代理也会遇到同样的问题。它们需要各自的代码库副本来推进，而不会踩到彼此。这就是为什么像…

你可能已经注意到，Anthropic正在发生一些事。他们就像一艘即将点火升空的宇宙飞船。整篇文章只是“蜘蛛感应”（spidey-sense）之类的东西。别想太多。只是直觉。说白了，就是“氛围感”（vibes）。 如果你做一做“信封背面”的粗算（back-of-envelope math），估一估作为业内人士进入Anthropic有多难，再把它与你在高中或大学球员阶段进入美式橄榄球联盟（NFL）的概率相比，你会发现两者相当。到目前为止，我见到的Anthropic同事都是“最强中的最强中的最强”，甚至比谷歌巅峰期还要夸张。（证据：谷歌录用了我。我就是最“刮锅底”的那批。） 大家都在向那里聚拢，而这部电影我之前已经看过不止一次。 过去四个月里，我有幸与Anthropic里将近40人做过相对坦诚的长谈——从联合创始人和高管，到整支团队，再到公司各部门的个体：AI研究、工程、GTM（go-to-market）、销售、编辑、产品等等。那里也有不少我的朋友，曾在以前的项目里共事过。 Anthropic作为一家公司，非同寻常地“难以渗透”。那里的员工都明白，只要闭嘴、埋头干活，他们就会成为亿万富翁甚至更进一步，所以他们有充足的动机照做。即便他们愿意跟你聊天，也很难真正撬开他们的话匣子。 但我还是做到了。通常在人们跟我接触14秒内，就会意识到我“无害”。到了我这把年纪，我长出了一种好奇的能力：无论对方是谁，只要聊上几句就能让人感觉良好，同时也让我们俩都感觉良好。（你大概也有这种能力，只是不知道怎么用。） 和足够多的人聊过、听过他们的长谈视角后，我开始怀疑：软件开发的未来，是“蜂群思维”（Hive Mind）。 又喜又悲 要想勾勒此刻Anthropic的完整画面，你得变成克洛德·莫奈，用印象派的方式去画，一笔一笔的大笔触。这一节就是一笔，讲的是“情绪”。 在我看来，几乎所有人都洋溢着鲜活的快乐。那股空气里的电火花，和1998年亚马逊的感觉一样。只是那会儿还没有厄普顿·辛克莱（Upton Sinclair）和所谓“人力资源（HR）”，所以电火花大多来自一楼酒吧的电线短路。 但无论是早期的亚马逊，还是今天的Anthropic，所有人都知道，某件了不起的事情即将发生，它会永远改变社会。（同时，他们也知道，无论接下来什么降临，对社会来说都将“极度阿拉丁”（极端复杂/矛盾/黑色幽默）。） 在Anthropic，我遇到的每一个人、每一支团队，无一例外，都带着一种甜中带悲的超然之感。他们给我的感觉像是一群被赋予“把与文明层面同等重要的某物带入现实”的人；他们兴奋，但也都带着一种古老精灵式的、旧世界将逝的庄重。我说不清那究竟是什么。 但我开始怀疑，他们对很多公司真的抱有“同情”。因为我们没把这件事当回事。2026年将会是几乎把很多公司“打到崩溃”的一年，而许多公司毫无所觉。Anthropic试着提醒大家，可这就像对百年没见过海啸的村庄大喊“海上地震来了”。 “氛围思维”（Vibe Mind） 只要你和Anthropic的人聊，总会聊到“混沌”。这家公司并不像同体量的公司那样运营。其他公司在这个规模上往往很快就变得“专业化”、部门化、可问责、成熟、诸如此类。我不觉得Anthropic现在对那些“套装流程”有多少兴趣。 当然啦，涉及他们的生产系统时，他们当然极其严肃，板起脸来，有世界级的SRE和扩展工程师。只不过，你也懂。让这条“大狗”摇尾巴的，其实是各式各样形态的Claude，那才是让蜂巢嗡嗡作响的“工作生成器”。 所以当我笼统地说“Anthropic完全靠氛围运行”时，我相信在靠近外缘的地方一定有例外：在那里他们会与外部世界建立更硬化的接口，无论是生产、GTM，还是产品营销。公司在那些边缘位置可能更“正常”。 但在核心，他们显然正处在（也许刚刚进入）一个“黄金时代”，下一节我会讲。那里既翻涌又起泡。 员工们常把它描述为“完全靠氛围驱动的蜂群思维”，这不是我强加给他们的词汇，而是他们自己的观察。组织会反映领导者的样子，所以这显然是由领导层在引导，而且大概率是刻意为之。并不是所有蜜蜂体型都一样，你能看到蜂群里分布着一些“图中的枢纽节点”，在维持整体稳定。 但如果你干扰蜂群的运作，打破这种平衡，你就会被温柔地推到边缘，甚至更外面。离心机会把你甩到外围，被“氛围”席卷着远离。 它看起来很脆弱，也许存在我们尚未知晓的“规模天花板”。但他们迄今一直维持着它，我也对他们的做法有一些想法。 如何终结一个黄金时代 我要插一句，与“蜂群思维”并不完全同向，但Anthropic把另一种属性展现得太清楚了，值得暂停一下，一起审视。 “黄金时代”是指一段持续数年的密集创新、品类创建、速度与产出暴涨的时期。公司层面的黄金时代有个特性：会在很短时间内吸引全行业的顶尖人才。Anthropic如今正经历着这一点。 我在亚马逊时经历了他们的黄金时代——我2005年离开时，那股劲头还没过去。后来我在谷歌也经历了他们的黄金时代，持续到2011年4月。之后，我眼看着谷歌钙化、分隔、几乎无法跨职能协作；与此同时，亚马逊还在持续执行与创新。 再给你第三个例子：在2000年代初，微软因为打输了Sun的Java诉讼，于是聚集了行业内无数顶尖人才，去用CLR与C#/.NET重塑软件开发的未来。那可能是他们能遇到的“最好的坏事”，有好几年一切都很魔幻，他们产出的东西塑造了整个行业。那几年他们是思想领袖。后来很多人“出逃”去了谷歌，一切烟消云散。 我花了很多年琢磨谷歌为何、如何会走到那一步。直到我看到Anthropic正在发生的事，一切才“咔哒”对上。 谷歌在转向利润为中心时，就扼杀了他们的创新机器——这导致“工作量与人数”的比例发生了转折。 谷歌早期CEO埃里克·施密特的口号是“让一千朵花盛开”。他的解释是：通过鼓励创新、下注许多项目来“制造运气”，希望其中一些会开花结果。谷歌能这么干，是因为他们在Web这片新绿地里财源滚滚。 2011年4月，拉里·佩奇接任CEO，他的口号变成：“把更多木头放到更少的箭上”（More Wood Behind Fewer Arrows）。他觉得——事实上也没错——那些不受约束的20%项目和Google Labs并没有产出真正的“爆款”。所以拉里大幅约束被资助的工作，20%项目逐步消亡。自那以后，公司变得“政治化”，丧失了大部分创新引擎，黄金时代也随之结束。 杀死20%项目本身，是导致崩塌的原因吗？未必。反例是亚马逊从未有过20%项目。它的创新与兴奋的黄金时代持续了很久，远远超过我2005年离开后的那些年。所以问题不在这里。那么亚马逊拥有而谷歌没有的是什么？ 一个线索来自我的同事雅各布·加布里尔森，他大概在2015年前后是亚马逊的首席工程师。当时谷歌已经像混凝土一样坚硬。我跟他说，谷歌的人常常会为了项目争斗，雅各布告诉我亚马逊从不这样，因为——用他的话说——“这里的每个人都总是略微超额订阅（slightly oversubscribed）。” 现在你就明白魔法如何开始、又如何结束了。黄金时代里，“工作多于人”。而当它崩塌，是因为“人多于工作”。 我知道我在“混单位”，但不这么说就很难把话说顺。你懂的。 拉里·佩奇在2011年4月对公司说：“别做新东西了，我们只做X、Y、Z。”可他们一个工程师都没裁，只是把“可做的工作量”砍掉了足足50%甚至更多。你再也不能随便做你想解决的问题了。于是，很快大家“分不到活”。 那就是终局的起点。一旦“活儿”不够，人们就开始为剩下的活儿争斗。接着就是帝国搭建、领地意识、政治斗争、土地掠夺，以及莉迪娅·阿什教我的“舔曲奇”（Cookie Licking）——微软人发明的说法，指那些“占着项目但永远不做的人”。 这些“坏事”，在今天许多公司里是常态。有人形容在微软就像一粒金属中的分子，你的胳膊肘与别人的紧紧卡在一起。具有讽刺意味的是，微软的曲奇如今似乎都被舔过了。 在Anthropic，他们正处在黄金时代的正中央：几乎所有方向上，“可做的活儿”都远多于“能做的人”。就像他们站在一个不断膨胀的球体表面。 因此，尽管有混乱、也不可避免地有成长的阵痛（跟我在亚马逊IPO后“Get Big Fast”阶段时的体验颇为相似），但从来没有理由为“工作”争斗。工作是无限的。 于是每个人都能有很多机会把自己的想法拿到阳光下，而“蜂群思维”会对其做出评判。 “小结版” 我非常怀疑，Anthropic的运作方式，很快会成为所有成功公司在未来几年里的主流，尽管它与当今大多数公司的运作方式大相径庭。…

停止生成，开始思考2026年2月8日标签：AI、工程 在我的职业生涯中，我一直自认为能紧跟行业的最新发展：参加各种会议、关注并结识那些撰写技术规范的聪明人、在Slack上第一个向同事分享CSS或JS新特性的消息。能在只需兼容最新版Chrome的内部工具上工作、在生产环境中尝试仍属实验阶段的“锚点定位”功能——那种乐趣无与伦比。 因此，当我发现自己开始觉得“被时代甩在后面”、好像“错过了什么”时，这种感觉相当不安。尽管我不愿承认，但越来越多的人疯狂依赖由大语言模型（LLM）生成的代码，而我却无法理解其中的逻辑。 我一直在用Copilot——最近也用Claude——把它们当作“加辣版自动补全”或偶尔的调试助手。但每次我尝试让它做一点稍微复杂的事，它就完全崩溃。别误会，我知道很大一部分问题在于我使用方式不对，但我很难说服自己花大量时间去琢磨如何让一台机器写出我自己在更短时间内就能完成的代码。 你得给它足够的上下文——但又不能太多，否则它会“过载”。你得写出一大段提示词来安抚AI那脆弱的自尊心，比如“你是一位分布式系统专家”，仿佛它是一个不自信的平庸程序员。 可我何不直接写那段代码，反而更快？ 看到越来越多工程师选择“生成代码”而不是“写代码”，我开始纳闷：为什么大家愿意放弃工作中最有趣的部分（写代码），而只留下最无聊的部分（代码审查）？ 也许有人真的喜欢给计算机写角色扮演剧本吧。我不知道。但我觉得危险的是，人们正心甘情愿——甚至自豪地——让生成代码充斥他们的产品。 我听过的几种辩解 “这就是我们的工业革命！就像机械化一样。”在很多方面，这话确实没错。 首先，想想工业革命对气候变化的贡献，再看看支撑AI软件的数据中心的能源消耗，这种相似性很明显。诚然，如今并非所有电力都来自化石燃料，这算是点进步，但我们仍在浪费惊人的资源，用来生成“虾仁耶稣”的图片。 机械化让商品更便宜、更普及，但质量却下降：自19世纪末以来就是一场“向下竞赛”。如今你能在SHEIN上花比一杯咖啡更少的钱买到一条“易燃”的裤子。机械化导致技能劳动的衰退，公司把工厂外包到欠发达国家，剥削低薪工人赚更多钱。 生成代码就像快时尚：乍看之下还行，但经不起时间考验，仔细一看漏洞百出。而且，就像快时尚一样，它常常抄袭别人的设计，对环境造成负担。 但有个关键区别。机械化是用机器取代了制造流程中的人力，让机器完成同样的工作。就像用脚本或代码生成工具写模板代码。这类过程的关键在于可重复——每次输出一致。如果出错，人类能打开机器，找到问题。 而LLM的输出是非确定性的，内部机制又不透明。一个每次结果都不同、还充满“幻觉”的机械化过程——根本没用。 “LLM只是另一层抽象，就像高级语言取代汇编一样。”确实，写Java或Go时我不必了解汇编。我最接近“汇编”的，大概就是编织图案说明书吧。 编程语言的演变，让我们逐渐不必操心底层细节：我不用管理内存回收或分配——运行时会自动处理。但我仍需思考代码结构、性能、系统架构、可维护性与交付速度之间的平衡。做Web开发时，我们得考虑浏览器兼容性、可访问性、安全性与性能。 我见过LLM造成的最大问题是：工程师把原本该自己思考的部分外包给机器。LLM不能推理系统架构该如何设计——因为它不会思考。如果我们不思考，而它也不思考，那就没人思考。没人思考的软件，绝不会有好结果。 以英国“邮局丑闻（Horizon scandal）”为例：因为软件漏洞导致员工被错误指控挪用公款，许多无辜职员入狱。我们比以往任何时候都更需要对软件负责。 十三个人因为那个系统的错误而失去了生命。 问题在于我们自己糟糕的代码 你也许会说：现在的人类开发者写的代码也一样糟糕——不可访问、性能低下、臃肿的JavaScript。那又有什么区别？ 没错。这正是问题所在。LLM是在未经我们明确许可的情况下，从这些糟糕代码中学习的。我们教会了它输出同样糟糕的东西。它注定会重复人类的错误——再加上别的LLM生成的错误——这正是有人戏称的“人类蜈蚣式知识链”。我们自己代码都不够好，哪来资格要一台机器更快地写出同样糟糕的东西？ 如果你觉得“到目前为止还行”，那就去问问使用辅助技术的人；问问网络连接差的国家；问问在英国城市里靠移动数据上网的人；问问被人脸识别或甚至自动干手机系统歧视的人；再问问那些邮局职员。 我们没有学习、没有改进，反而把错误交给了不懂思考的算法。 “四只眼睛好，两只眼睛坏” 去年在FFConf上，Jessica Rose和Eda Eren做了一场精彩的演讲，讲述AI编程助手如何让我们逐渐失去技能。其中有一张幻灯片让我印象深刻： “你没有亲手写的代码，你就无法理解。你无法维护你不理解的代码。” 当我审查同事提交的PR时，会有一种信任感——因为那是一个经过思考的人写的代码。虽然也有例外，但若某人总提交糟糕的PR，经理自然会介入。 而开源维护者如今面对大量低质量的AI生成PR。作为贡献者，无论代码是否由LLM生成，你都要为自己提交的代码负责。审查者也有部分责任，但至少有两双眼睛在看。 现在有公司在社交媒体上炫耀他们让Claude在Slack里生成代码并直接创建PR。Claude自动写完代码，再自动发起PR。这时责任全落在审查者身上。如果规则不够严格，一个人就能让Claude生成并自己批准——于是我们失去了一双“人眼”，团队的知识共享也随之减少。 代码审查不仅仅是查漏洞，更是分享理解。虽然有公司完全不做PR、直接提交到主分支，但我见过唯一可行的做法是工程师持续配对编程——这样才能保持对改动的共同理解。 我不是反对进步，我是反对炒作 我必须强调：我并不“反对LLM”。我反对的是把它们包装成“人工智能”——因为它根本不智能。它只是机器学习的一种形式。“生成式AI”不过是一个非常强大的马尔可夫链，人们对它的期望远远超过现实。 我也不反对用生成式AI快速制作原型——比如线框或交互演示，这很合理。我的担忧在于：有些人以为可以靠“感觉提示”（vibe code）直接生成可上线的软件，或者把编程中最重要的“思考过程”完全交给机器。 Mikayla Maki提出了一个非常好的观点：始终让人类参与其中，把AI代理当作一个你不完全信任的外部协作者。 只让它执行你自己已经掌握的任务——因为理解才是关键。 我会继续使用我的“加辣自动补全”，但我绝不会把思考外包。停止生成，开始理解——也别忘了我们当初为什么热爱这份工作。

我至今仍对AI用户之间的巨大差异感到震惊。我认为，这种差距很大程度上解释了媒体对AI及其生产力影响的报道为何常常令我困惑。 现在我很清楚地看到，AI用户（以及他们所在的组织）大致分为两类。 首先是“高级用户”，他们全身心投入到新AI技术的应用中——例如Claude Code、MCPs、各种技能系统等。令人意外的是，这些人往往并非技术背景出身。我看到的非技术背景用户远比我想象的多，他们在终端中使用Claude Code处理各种非软件工程任务。金融岗位似乎从中获得了巨大的价值（这也不奇怪，因为一旦习惯了像Python这样完整的编程生态系统，Excel在金融分析中的限制就会显得格外明显）。 其次，是那些只用ChatGPT或类似聊天AI的人。我认识的许多人仍属于这一类，这让我颇为意外。 M365 Copilot的困境 让我震惊的一点是：微软的Copilot表现非常糟糕。它在企业市场拥有庞大的份额，因为它被捆绑在各种Office 365订阅中，但它的体验却像一个拙劣克隆的ChatGPT界面（而ChatGPT本身在企业效率上也并不算出色）。其中的“智能代理”功能更是令人发笑，与命令行中的代码代理（包括微软自己GitHub上那个名字混乱的Copilot CLI）相比简直天差地别。 更具讽刺意味的是，微软自己正在向内部团队推广Claude Code[1]——尽管他们几乎可以零成本使用Copilot，并且还是OpenAI的重要股东。这恰恰说明他们已经落后了多远。 问题在于，在许多企业环境中，Copilot往往是唯一被允许使用的AI工具。你若使用其他AI工具，轻则要花费巨大精力去申请审批，重则可能会丢掉工作。Copilot运行缓慢，其代码执行工具功能不完善，在处理稍大一些的文件时几乎必然崩溃——显然是因为内存与CPU资源被极度限制。 这对很多企业来说正成为一种“生存风险”。高层决策者使用这些工具得不到理想效果，于是干脆否定AI的价值，或者花费巨资请大型咨询公司协助，却依旧收效甚微。 企业面临的结构性风险 大型企业的IT政策往往造成一系列灾难性的限制，使得员工无法有效使用更先进的AI工具。 首先，他们通常拥有极为封闭的工作环境，本地连最基本的脚本解释器都无法运行（若幸运的话，能用VBA，但往往也被组策略限制）。其次，他们依赖的传统软件缺乏“内部API”，这意味着即使能运行智能代理，代理也无从连接关键工作流程。 最后，他们的工程部门往往高度割裂，甚至被完全外包，所以即便想构建一个安全的AI代理运行环境，内部也无人能实现。 安全顾虑确实存在。没人希望员工随意让代码代理直接操作生产数据库——风险太高。而我之前也提到，构建安全的沙盒代理并不容易[2]。 但问题是，缺乏内部工程能力，就无法打造能安全调用企业数据的AI基础设施。 巨大的差距 我与一些规模较小、没有这些“包袱”的公司交流过，他们在AI应用上发展极快。两种公司之间的差距非常明显。 一方面，你能看到微软那糟糕的Excel Copilot整合（公平地说，谷歌Sheets的Gemini整合也不好）。你可以想象财务总监尝试用它时，它把最基本的任务都搞砸，于是他们再也不会碰它。 另一方面，你会看到一个非技术出身的高管，却能熟练使用Claude Code并在本地运行Python。我最近就帮过一位高管，几乎“一次成型”地把一个包含30个工作表、复杂到令人头疼的Excel财务模型转换成了Python脚本。 当模型进入Python后，借助Claude Code，你就等于拥有了一个随身的数据科学团队。你可以轻松运行蒙特卡洛模拟、导入外部数据、构建网页仪表板，并让Claude Code与你一起分析业务模型的弱点。这种体验令人惊叹——看到一个人意识到自己竟能如此高效，而不再被Excel束缚。 结果是，小公司员工的生产力远远高于大型企业中的同类岗位。过去，小公司的人常常羡慕大企业的资源与团队，但如今我觉得情况正在反转。 未来的趋势 我逐渐看清了未来工作的形态。首先，真正的突破往往来自员工自发的尝试，而非高层制定的“AI战略”。我看到的最大生产力提升，来自小团队自己为熟悉的流程打造AI辅助系统——他们对流程了如指掌，因此能快速见效；而外包的软件团队往往对业务一无所知，效率极低。这与过去企业“数字化转型”项目的自上而下模式完全相反。 其次，拥有内部系统API的公司，远比没有API的公司更具优势。这可能只是一个只读数据仓库，供员工通过AI查询；也可能是复杂的业务流程都通过API暴露出来。 再次，这一切都需要安全机制包裹。我认为，运行代码代理的托管虚拟机（配合合理的网络限制）会是一个不错的方案——至少在只读报表场景下可行。而对于创建或编辑数据的操作，我们还没找到非技术用户能安全使用的模式（至少目前还没有）。 最后，那些老旧的企业SaaS供应商要么拥有强大的客户锁定力，要么极度脆弱——这取决于视角。多数产品并非“API优先”设计，它们的API多为开发者准备，不适合成千上万的员工以各种低效方式调用。但如果这些系统是企业的“真相源头”，就几乎不可能迁移，也因此成为生产力提升的瓶颈。 相比之下，小公司使用的现代产品往往天生拥有完善的API——因为它们不是几十年前拼凑出来的。 知识工作的未来 未来的知识工作模式将是：用户发出指令，AI代理连接系统API，实时生成结果。 换句话说，用户发出提示（prompt），代理综合信息、连接API、并按需输出结果。 我逐渐意识到：当你拥有一个带编程语言与API访问权限的安全沙盒环境，再配合智能代理框架，其结果之强大令人难以置信。它几乎可以替代现有的所有生产力软件——无论是传统的Microsoft Office，还是各类网页应用。它可以生成任何报告，并以任何格式导出。对我而言，这正是知识工作的未来。 如今，这种分化是真实存在的，而且正在迅速加速。我不认为历史上曾有任何一个时代，小团队能如此轻松地击败规模比自己大一千倍的公司。