AI TrendTrackers

直到今天，我依然很难相信自己已经几乎不再亲手写代码了。更准确地说，我难以相信自己过去竟然长期依靠手写代码工作。软件开发这件事已经发生了根本性的变化，而过去那些被我们视为理所当然的工程价值观，究竟还有哪些依然重要，也成了我近来反复思考的问题。 在开始讨论之前，为了避免有人质疑我只是纸上谈兵、没有真正交付过东西，我先列举一下过去几个月里自己参与的项目： 经过这一阶段的实践，我越来越确信一件事：如今的编码 agent 所写出的代码质量，已经与我自己编写的代码相当，很多时候甚至更好；而过去需要数周才能完成的工作，它们往往几分钟就能交付。既然写代码本身不再是主要瓶颈，那么许多原本根本不会开始的项目，现在也终于有机会被完成。 这些项目大多是公开的，任何人都可以直接查看代码验证我的说法。我并不是在炫耀什么，而是真切地感到震惊。在我的职业生涯里，从未出现过如此巨大的开发体验跃迁——一种工具不仅让开发速度成倍提升，同时还能提高最终交付的软件质量。 以 Athena Crisis 为例。这是一个诞生于 AI 时代之前的项目，最初完全由我手工编写。后来因为一直抽不出时间维护，我干脆让 Codex 持续循环执行“发现问题—修复问题”的流程。最终它修复了七十多个 Bug，增加了新功能，补充了测试，而完成这些工作的同时，我甚至还能在别的项目里等待其他 agent 的执行结果。结果是，Athena Crisis 现在比过去任何时候都更快、更稳定、功能也更丰富。除此之外，它还顺手优化了 CI 流程，改进了 Steam 上传流水线，为一些复杂的多人交互场景补齐了测试，甚至还帮我开发了一个专门用于比较两百多个像素图标版本差异的小工具，从而彻底更新了游戏的视觉风格。如果没有编码 agent，这些事情根本不会发生。 我现在如何使用 LLM 回头看一年前的工作方式，变化已经非常明显。 那时候我几乎不在本地运行模型，通常会把上下文严格限制在某个模块或函数范围内，并且为同一个问题生成多个候选方案进行比较。 而现在，我几乎完全依赖 Codex CLI，并搭配 GPT 5.5 high 模式。只要代码库本身拥有足够完善的约束和护栏，模型通常能够在一次尝试中直接给出正确方案，甚至不需要复杂的提示词设计或者精细的任务拆解。我发现推理等级过低会明显影响代码质量，而 xhigh 模式则往往过于缓慢，并且喜欢把简单问题复杂化。过去一段时间里我试过很多模型，但无论从速度、正确率还是协作体验来看，目前都没有哪个产品能够与 Codex 相提并论。 很多人喜欢同时在同一个项目中开启多个 agent 会话，借助 worktree、代码副本或者其他方式并行开发，但我发现自己在这种模式下效率并不高。因为我仍然坚持阅读所有代码，而在同一个项目里同时处理多个互不相关的改动，会让我频繁切换思维上下文，反而拖慢速度。 相比之下，我更喜欢在不同项目之间切换。 通常我的桌面会同时打开多个 Ghostty 窗口，每个项目占据一个窗口，左边是 Codex，右边是终端。借助这种方式，我能够同时推进三到六个项目，而真正的瓶颈往往不再是代码实现，而是方案讨论与代码审查。 这种工作方式甚至改变了我对工作环境的偏好。 过去我非常喜欢只带一台笔记本随处办公，但现在我越来越依赖大屏幕。因为同时管理多个项目之后，空间本身开始成为一种认知工具。我会不自觉地把不同项目固定在屏幕上的特定区域：fate 总是在中上方，Void 往往位于左侧，而 Athena Crisis 则固定在右边。奇怪的是，这种空间映射似乎真的能够帮助大脑更有效地切换任务。…

该公司警告称，技术进步速度正在迅速加快，AI 系统很快可能具备自我改进能力，其演进速度甚至会超过社会管理和控制风险的能力。 Anthropic Anthropic 正呼吁全球主要 AI 实验室讨论建立一种协调且可验证的暂停机制，以应对先进 AI 系统带来的潜在风险。 Anthropic 提议，全球顶尖人工智能公司应共同制定一种协调机制，在必要时暂停先进 AI 系统的开发。该公司认为，AI 技术的发展速度已经快到可能使人类失去控制能力的程度。 这家 Claude 聊天机器人的开发公司周四在博客中表示，随着最前沿 AI 系统执行任务的能力越来越强、速度越来越快，“对于整个世界而言，拥有减缓甚至暂时暂停其发展的选项，将是一件好事”。 Anthropic 表示，其内部研究机构计划与其他组织合作研究这一问题，并采取行动推动建立可信的减速或暂停机制，不过并未透露具体实施方式。 Anthropic 的竞争对手 OpenAI 则在周三发布的一份报告中提出了不同看法。OpenAI 认为，最终应由民主政府而非私人企业单独决定 AI 发展的规则、安全保障机制以及问责体系。 OpenAI 表示： “我们认为，关于 AI 创新速度的决定，不应由任何一家实验室、公司或特殊利益集团单独掌控。” Anthropic 在文章中指出，AI 模型的能力正在迅速提升，尤其是在独立完成编程等软件任务方面的效率增长极快。按照当前的发展趋势，只要拥有足够的算力支持，未来 AI 系统可能具备设计和开发下一代 AI 系统的能力，这一过程被称为“递归自我改进（recursive self-improvement）”。 Anthropic 认为，能够自行构建后继版本的 AI 将成为重要的技术里程碑，并可能在科学研究、医疗健康等领域带来巨大收益。但与此同时，这种能力也可能增加人类失去对 AI 系统控制权的风险。 科技行业中长期以来一直有人对此类情景提出警告。 Anthropic 的表态恰逢另一项引发关注的研究发布。本周，多伦多大学研究团队展示了一种利用 AI 工具构建的新型 AI“蠕虫（worm）”。这种恶意程序能够在设备之间传播时不断调整攻击策略，并逐步接管大规模计算网络。 该研究负责人 Nicolas…

本文前半部分将介绍 HBM、制造工艺、供应商之间的竞争格局、KVCache Offload、预填充与解码分离（Disaggregated Prefill Decode）、宽专家并行（Wide EP）与高 Rank EP。后半部分则会深入探讨 HBM 的未来，包括 HBM4 引入自定义 Base Die 所带来的革命性变化、OpenAI、Nvidia 与 AMD 等不同 AI 加速器在定制 HBM 方面的布局、Shoreline 面积问题、内存控制器卸载、Repeater PHY、LPDDR 与 HBM 混合方案，以及各种“海岸线扩展”技术。 此外，我们还将讨论 SRAM Tag、Memory-Under-Compute、供应链影响，以及三星面临的挑战。 HBM 简介 随着 AI 模型复杂度持续提升，AI 系统对于内存提出了更高要求：更大的容量、更低的延迟、更高的带宽以及更好的能效。不同类型的存储器各有取舍：SRAM 速度极快但密度很低；DDR DRAM 容量大且成本低廉，但带宽不足；而如今最主流的方案则是片上 HBM，它在容量与带宽之间取得了最佳平衡。 HBM 通过将多颗 DRAM 芯片进行垂直堆叠，并结合超宽数据通路，在带宽、密度与能耗之间实现了理想平衡，因此成为 AI 工作负载最合适的内存方案。尽管 HBM 的制造成本远高于 DDR5，价格也存在显著溢价，但市场需求依旧强劲。当前所有主流生成式 AI 训练与推理加速器均采用 HBM。各家加速器路线图也呈现出一致趋势：通过增加堆叠数量、提高层数以及采用更高速的新一代 HBM，持续提升单芯片的内存容量与带宽。相比之下，依赖其他内存形式的架构通常会遭遇明显的性能劣势。 本文将分析 HBM…

过去一年里，几乎所有工程负责人都被问过类似的问题：“你们的 AI 生产力提升了多少？” 提问者期待的往往是一个醒目而简单的数字，但现实远比这种叙事复杂得多。关于 GenAI 在软件工程中的影响，研究证据远没有新闻标题和厂商宣传所呈现得那样一致。因此，本周的问题是：关于 AI 与开发者生产力的那些流行观点，到底有哪些得到了研究支持？ 背景 围绕 GenAI 的行业讨论，发展速度已经远远超过了相关研究的积累速度。 今天，许多企业的采购决策、人员规划以及季度 OKR，都在受到产品演示、个别案例以及少量受控实验的影响，而这些实验往往是在高度简化的任务环境中完成的。随后，工程负责人又被要求把这些零散信息转化成适用于自己团队的判断。 问题在于，许多最流行的论断实际上建立在并不成立的假设之上。 如果开发者一天的大部分时间根本不是在写代码，那么编程助手究竟能带来多大改变？如果仪表盘上显示的是“AI 生成代码行数”，那么这个指标究竟衡量了什么？随着越来越多研究者开始观察真实团队的工作方式，一些广为流传的叙事正在受到挑战。 研究发现 在最近发表于 ACM Queue 的一篇文章中，多位知名生产力研究者（其中包括 SPACE 框架的共同作者）系统梳理了软件工程领域关于 GenAI 最顽固的八个神话。 他们综合分析了近年来的大规模研究成果，其中包括微软于 2025 年开展的一项覆盖 450 多名工程师的研究、开发者访谈，以及大量现场研究（field research）的综合结果。 神话一：开发者大部分时间都在写代码 事实并非如此。 微软 2025 年的研究显示，开发者平均只有大约 14% 的工作时间真正用于编写代码。更早的研究结果也与此相符：状态较好的一天里，这个比例约为 18%；状态较差的一天里，则只有 11%。 换句话说，开发者一天的大部分时间实际上消耗在会议、设计讨论、代码审查、沟通协作以及各种非编码活动上。 神话二：写代码才是开发流程的主要瓶颈 如果编码本身只占工作时间的大约 15%，那么即使 AI 能把编码速度提升一倍，总体生产力提升也很难超过 15%。 更重要的是，加快代码生成速度往往只是把压力转移到了后续环节。代码审查、测试、集成和上线等流程仍然需要同样的时间，因此开发中的“外循环（outer loop）”并没有发生本质变化。 很多团队看到代码生成速度变快，却误以为整个交付流程都变快了，而实际情况往往并非如此。 神话三：代码行数是衡量 AI 价值的最佳指标 这是目前最流行、也最值得警惕的误区之一。…

AI agent 之所以能够让工作变得更轻松，本质上是因为它们在人与任务之间增加了一层又一层的委托机制；然而这些委托层最终会沉淀为依赖，而依赖又会逐渐演变成风险。 Mitchell Hashimoto 最近提出了一个听上去几乎有些离经叛道的建议：停止更新依赖。从软件行业过去几十年的经验来看，这种说法几乎称得上疯狂。尤其是在 Mythos 出现、AI 已经开始大幅降低零日漏洞发现成本的当下，这种观点似乎更加难以接受。不过，如果回头看看今年春天 npm 生态发生的一系列安全事故，你会发现 Hashimoto 的主张或许并不像表面看起来那么极端，反而透露出一种重新掌控风险的思路。 他的原则很简单：Fork 你所依赖的项目，把代码裁剪到只保留自己真正需要的部分，然后除非用户确实受到影响，否则不要轻易更新。按照他的逻辑，更新依赖不应该成为一种默认动作——无论是因为 GitHub Dependabot 自动提交了升级 PR，还是因为上游发布了一个号称更安全的新版本。如果你决定升级，那么理解整个传递依赖树中相关变更的责任在于你自己，而不在维护者身上。 对于一个长期把“最新版”等同于“最安全版”的行业而言，这种观点听起来难免有些危险。但今年春天发生的几起事件恰恰说明，现实情况并没有那么简单。 在今年最严重的两起 npm 供应链攻击中，受害最深的往往不是那些长期停留在旧版本上的项目，而是那些积极跟进最新发布版本的用户。当 HTTP 客户端库 axios 遭到入侵时，攻击者成功发布了两个被植入恶意代码的版本。在大约三个小时的窗口期内，任何执行全新安装的机器都会自动获得一个远程访问木马；相反，如果你的项目已经锁定在一个干净版本上，并且没有重新安装，那么整场攻击几乎与你无关。几周之后，在 node-ipc 投毒事件余波未平之际，Mini Shai-Hulud 蠕虫又借助 TanStack 生态开始传播，并进一步波及 Mistral、UiPath 以及大量每周下载量达到数百万次的软件包。 面对这样的攻击，应该如何防御？ 答案或许出人意料：有时候，什么都不做反而更安全。 因为抵御 Mini Shai-Hulud 最有效的措施既不是漏洞扫描器，也不是恶意代码特征库，而是一个简单得近乎无聊的机制——冷却期。StepSecurity 在向客户提供新版本之前，会先将其冻结一个可配置的时间窗口，通常约为十天。在这段时间里，用户获得的始终是最后一个已知安全版本，因此完全避开了恶意发布；而其他没有采用这一机制的人，则不得不亲身经历整个事故。 换句话说，真正发挥作用的防御策略恰恰是那个在软件工程历史上常常被视为保守甚至愚蠢的原则：不要仅仅因为某个版本更新了，就立即采用它。 颇具讽刺意味的是，当整个行业开始拥抱 AI 开发时，许多团队给出的答案却是继续引入更多依赖。而问题在于，我们真的清楚这样做会带来什么后果吗？ 依赖树已经逃离了包管理器 过去几十年里，软件行业一直在通过开源库来共享那些缺乏差异化价值的基础能力，而这总体上是一件好事。毕竟没有多少团队愿意重新实现 TLS、日期解析、日志框架或者其他基础设施——当然，那些把编译 Gentoo 当作爱好的人可能是个例外。 开源协作之所以能够成功，正是因为不同的人专注于不同的领域，然后将成果共享给整个生态。然而共享的从来不只是代码本身，我们同时也在共享维护者账号、包管理器、CI/CD 流水线、发布脚本以及各种围绕软件构建起来的基础设施。 现代软件工程最令人惊叹的地方在于，一个规模不大的团队往往能够利用数千个自己从未编写过的组件，构建出世界级产品；但风险也恰恰来源于此。随着 AI…

多年来，工程生产力的核心始终是减少软件开发生命周期中的各种摩擦，而 AI 编程工具则被寄予厚望，用来加速实现阶段的工作、提升开发者产出。然而，当这些工具在 Dropbox 工程团队中被广泛采用后，我们逐渐意识到：加速代码生成只是把瓶颈推向了后续环节。 AI 极大提升了代码编写速度，但代码流动得越快，代码评审队列、CI 系统、验证流程、发布协调以及生产运维所承受的压力也就越大。挑战已经不再只是帮助工程师更快写出代码，而是如何让整个软件开发生命周期能够吸收、验证并安全地交付大幅增加的工作量。正是这种认知，推动 Dropbox 从单纯采用 AI 工具，迈向对工程系统与工作流程更全面的演进。 在这篇文章中，我们将分享 Dropbox 如何从辅助工程师工作的 AI 工具，逐步转向能够执行特定任务的 agentic 系统；我们如何构建支撑这些工作流的平台；以及工程师如何调整自己的工作方式，与这些系统协同合作。 从 Copilot 到 Agent 第一代 AI 编程工具主要是在现有开发流程中帮助工程师完成工作，例如解释代码、生成代码片段以及回答问题。这类工具非常有效，但它们本质上仍然是工程师身边的 Copilot。 Agent 的出现改变了这种交互模式。一个 agent 可以接收一个边界明确的任务，检查代码库、修改文件、运行测试、针对失败结果不断迭代，并最终返回一个供人工审核的成果物。工程师依然对需求意图、系统架构、代码质量以及发布决策负责，但具体的实现流程已经发生了显著变化。借助 agentic 开发模式，工程师能够并行推进更多工作、探索更多方案，并把过去大量消耗时间和注意力的重复执行工作交给系统完成。 然而，随着 agent 持续提升代码产出速度，负责审查、验证和交付这些代码的周边系统也开始承受越来越大的压力。代码评审系统、测试基础设施、验证流程、发布机制以及生产运维体系，都必须适应规模远超以往的 AI 辅助产出。 这种变化也迫使我们重新审视围绕这些工具构建的整体工程环境。更多代码和更多 Pull Request 并不一定意味着更高的客户价值。与此同时，由于 agentic 工程改变了工程师规划、审查、验证和负责工作的方式，因此赋能和培训的重要性已经与工具本身同等重要。 Nova：我们的 Agent 平台 Nova 是这种转变最具代表性的例子之一。Nova 是 Dropbox 内部的编程 agent 平台，我们构建它的目标，是让工程师能够使用自然语言描述任务，并在一个受控环境中运行 AI…

我之前写过一篇关于 Google、Yahoo、Microsoft 和 Apple 正在如何改造 email 的文章。当时我提到，这几家公司已经不再只是简单的“邮件传输层”，而是逐渐变成了品牌与用户之间真正的中介者：它们会解析、排序、总结，甚至越来越多地开始替用户“回答”邮件。 而如今，同样的事情也正在 push notification 上发生。 只不过，这一次控制整个渠道的公司从四家变成了两家。Apple 和 Google 掌握着全球唯二真正重要的 push 管道，而你曾经发送过的每一条通知，都必须经过它们。在过去几年里，那个位于“消息送达”和“锁屏展示”之间的 on-device model，已经开始主动对通知进行总结、重排，甚至在某些场景下直接重写内容。 很多人至今仍然把 push notification 理解成一种“发送即送达”的渠道，但现实其实已经越来越像 email：平台不再只是负责运输，而是开始主动决定，哪些内容值得被用户看到、应该以什么形式被看到，以及它究竟值不值得打断用户。 而对于所有依赖 push 做增长、留存和营销的人来说，这件事的重要性可能远超想象。 Push 最初其实是一个电池问题 Push notification 的诞生，本质上其实是为了解决电池问题。 2009 年 6 月，Scott Forstall 在 WWDC 上解释说，iPhone 根本无法承受所有应用都各自维持一个后台轮询连接，不断向远程服务器查询新消息。那样做的结果，只会让设备续航迅速崩溃。 Apple 最初原本计划在 2008 年 9 月推出 push 服务，但后来因为决定重构底层基础设施以支持更大规模，而推迟了发布。最终诞生的方案，就是 Apple Push Notification Service（APNs）：每台设备只与 Apple 建立一个持久…

最近关于 Anthropic 的一个传闻非常引人注目：他们很可能即将迎来历史上第一个盈利季度。与此同时，越来越多企业开始发现，内部员工对 LLM 的使用，正在让 AI 成本以一种远超预期的速度膨胀。大量公司突然意识到，AI 已经不再是一个“试验性预算”项目，而是正在迅速演变成新的基础设施开支。 我越来越倾向于认为，这背后真正发生的事情其实非常简单： OpenAI 和 Anthropic 都已经找到了 product-market fit。 而且，这次并不是 ChatGPT 那种“用户很多但不知道怎么赚钱”的 consumer PMF，而是真正能够大规模转化为收入、并可能最终覆盖巨额基础设施投入的 enterprise PMF。 企业客户现在实际上正在按 API 原价付费 我目前同时订阅了 Anthropic 的 $100/月 Max plan，以及 OpenAI 的 $100/月 Pro plan。如果你是 coding agent 的重度用户，那么这两个订阅几乎可以说是不可思议地便宜。 我最近在自己的笔记本上运行了 ccusage 工具，估算了一下过去 30 天里，如果完全按照 API token 原价计费，我到底会花多少钱。结果显示： 也就是说，在过去一个月里，我总共消费了价值 $2,180.16 的 token，但实际只支付了 $200。 而更关键的是，我甚至算不上那种全天候持续跑 agent 的疯狂用户。我只是一个相对重度、但仍然属于正常工作流范围内的使用者而已。…

这或许算不上什么真正的大问题——甚至可以说，把它当成问题本身就是一种特权——但最令人烦躁的消费体验之一，就是你叫了一辆 Uber Black，结果发现来接你的是一台 Tesla Model Y（好在 Uber 去年终于停止让新的 Model Y 加入 Black 级别）。狭窄而不舒服的后排、廉价的塑料内饰，以及司机尚未完全适应 Tesla 激进动能回收时带来的晕车感，几乎已经成了固定搭配。 不过，Model Y 居然曾经能被归到 Black 档，本身就说明了 Elon Musk 打造出来的品牌力量。早在 2016 年，当 30 万人在几个小时内各掏 1000 美元预订一辆尚未发布的 Model 3 时，我曾经解释过这种现象的根源：因为它是 Tesla。 Musk “Master Plan”的真正回报，在于 Tesla 已经意味着某种东西：当然，它代表环保与可持续性，但更重要的是，Tesla 同时也意味着惊人的性能，以及 Silicon Valley 式的酷感。毫无疑问，Tesla 从高端市场切入，确实帮助它沿着成本曲线一路下探；但真正让 27.6 万人在甚至没见过实车的情况下就预订 Model 3 的，是 Musk 对“毫不妥协的电动车”的坚持——毕竟，它是 Tesla。 也正是这种品牌光环，让一辆说实话相当普通的车进入了 Uber Black 名单。真正让这些车有吸引力的，其实是它们作为“轮子上的电脑”的属性。我认识不少非常有钱的人，他们开…

AI 正在以一种非常奇怪的方式改变科学，而且这种变化既不是很多人想象中的“机器科学家取代人类”，也不是另一派人口中的“高级自动补全终于开始污染学术界”那么简单。真正发生变化的东西，其实是科学发现内部的一种结构，而且这个结构已经存在了几十年，只不过过去它运行得非常慢、非常昂贵、非常局部化，而今天，大语言模型突然让其中一个环节的成本急剧下降，于是整个系统的行为方式开始出现质变。 Donald Knuth，88 岁，《计算机程序设计艺术》的作者，算法分析领域的奠基人，出了名的 AI 怀疑论者，一个几乎代表“传统计算机科学黄金时代”的人物，居然认真阅读了一份 Claude Code 的对话日志，而且不是随便扫两眼，而是逐行检查，因为里面真的出现了让他感到意外的东西。数学家 Filip Stappers 用 Claude Opus 4.6 做了三十一轮组合数学探索，其中第十五轮里出现了一个此前没人明确写下来的结构模式。Knuth 不但认可这个模式，还亲自完成了证明，最后写成论文，并把它命名为 “Claude’s Cycles”。 很多人在这里会立刻滑向两个极端。 第一种叙事非常熟悉：AI 已经成为科学家，人类只是提示词操作员。模型提出了洞见，人类负责阅读结果，科学发现已经自动化。另一种叙事则完全反过来：语言模型根本不理解数学，它只是概率生成器，真正做科学的是研究者，模型只是一个会拼接 token 的随机鹦鹉。 这两种说法听起来都很完整，但问题在于，它们都在试图回答一个错误的问题：“AI 到底有没有在做科学？”真正值得观察的对象其实不是 AI，也不是人，而是两者之间形成的那个循环。 这个循环的结构非常稳定：人类提出问题，模型生成候选答案，某种验证机制过滤这些答案，然后人类决定哪些结果值得继续推进。这个结构在 Knuth 与 Claude 的案例里存在，在陶哲轩与 Lean 的协作里存在，在 AlphaFold 的蛋白质结构预测里存在，在 DeepMind 的 GNoME 材料发现系统里也同样存在。真正完成“发现”的，从来都不是某个单独主体，而是整个 loop。 这件事非常关键，因为它决定了我们应该如何理解 AI 对科学的影响。很多人习惯性地把科学发现想象成一种高度人格化的行为：某个天才突然洞察宇宙真理。但现代科学早就不是这种模式了。真正的大规模科学活动，本质上是一个由提问、生成、筛选、验证、迭代构成的复杂系统，而 AI 恰好在其中最适合“高吞吐量试错”的那个环节上表现出了惊人的效率。 Claude 的案例其实已经很典型。Stappers 做的不是一次“灵感对话”，而是三十一轮系统性探索。模型不断提出候选结构，人类不断筛选和判断，最终 Knuth 对其中幸存下来的结果完成严格证明。这里最重要的角色不是“科学家”或者“AI”，而是 proposer 和 verifier…