AI TrendTrackers

过去一年里，几乎所有工程负责人都被问过类似的问题：“你们的 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…

2026 年的 Android，正在迎来一次前所未有的 AI 大改造。 距离 Google I/O 开幕只剩下一周时间，但 Google 显然已经等不及了。由于今年关于 AI 的内容实在太多，这家公司决定提前“剧透”Android 的未来方向。而从目前公开的信息来看，未来 Android 的核心关键词几乎只有一个：AI。 Google 正在把 Gemini Intelligence 深度植入 Android 系统，让手机从“工具”逐渐转向“主动协助者”。它不只是帮你回答问题，而是准备真正接管部分操作流程、理解上下文、跨 App 执行任务，甚至提前预测你的需求。 最明显的变化之一，是 Android 即将全面强化 App 自动化能力。 事实上，Google 早在 2026 年初就已经开始测试相关功能，当时主要针对 DoorDash、Uber 等应用，并优先开放给 Pixel 与 Samsung Galaxy 用户。不过初版体验并不好，执行缓慢、识别错误频繁，也缺乏真正的实用性。但 Google 表示，在过去几个月里，他们一直在重新训练系统，并优化跨应用操作逻辑。 而现在，Android 想做的已经不只是简单点餐或打车。 举例来说，未来 Gemini 可以自动从 Gmail 中找到你的课程大纲，然后跳转到购物 App，把所需教材自动加入购物车。又或者你拍下一张旅行宣传册照片，Gemini 能够理解目的地、预算与旅行风格，再直接在 Expedia 之类的 App…

如果你看到这样一句话： “AI Agent 才是软件开发的未来。开发者已经不再必要，他们只会拖慢企业前进的速度。” 你会有什么反应？ 我给出的答案可能有些反直觉。如果你是一位真正资深的软件开发者，而且你完全认同这句话，那么我反而会开始怀疑你的专业能力；但如果你并不是长期负责复杂系统的人，却觉得这句话非常合理，那么我认为，你大概率是正确的。乍一看，这种说法似乎自相矛盾，但它其实揭示了当前 AI 讨论里一个非常核心的问题：同一句话，在不同的人耳中，往往代表着完全不同的含义。 我本身是一名文案写作者，因此我习惯从“受众”角度理解问题。在我看来，现在关于 AI 的很多争论，并不是谁更懂技术，而是不同人实际上在面对不同的问题。对于许多资深开发者来说，他们已经亲自体验过各种 AI Agent、代码生成模型和自动化工作流，也确实感受到了这些工具惊人的效率，但与此同时，他们又隐约感觉到哪里“不太对劲”。问题在于，大多数人并不能准确地把这种直觉表达出来，于是这篇文章的目的，就是尝试替这些开发者把那种难以描述的不安翻译成人类语言。 很多人会感到疑惑：既然如此，为什么又有不少知名工程师、技术意见领袖，甚至经验丰富的开发者，也在不断宣称“程序员将死”？ 我认为，原因其实并不复杂，因为不同的人所面对的“工作循环”本身就不同，而这会彻底改变他们理解 AI 的方式。 为了说明这一点，我先讨论什么才是真正的资深开发者。很多人以为，资深开发者最重要的能力是写出复杂架构、设计高级系统、掌握大量技术细节，但我认为，真正成熟的资深开发者往往最擅长的事情，恰恰是“避免开发”。 我把自己在团队里见到的资深开发者分成了两类。 第一类人总是在讨论新的工具、新的框架、新的最佳实践，他们会不断提到某家公司采用了什么架构、某篇 HackerNews 文章推荐了什么技术方案，或者最近又出现了什么令人兴奋的新东西。这类人通常经验丰富，也很擅长社交，但我并不喜欢他们，因为他们的思维模式总是在往系统里“增加东西”。 而另一类开发者则完全不同。他们最常说的话是：“我们真的需要这个吗？”、“如果不做会怎么样？”、“能不能先凑合一下，等以后真正重要了再说？”我非常认同这种开发者，因为他们真正害怕的是一件事情：复杂度。 在真正长期维护过大型系统的人眼里，复杂度几乎是一切问题的源头。每增加一个特殊逻辑、一个新的数据库表、一个新的服务模块，系统都会变得更难理解一点、更难调试一点、更难维护一点。复杂度并不会立刻毁掉系统，它更像一种慢性病，刚开始时团队感觉不到问题，但随着时间推移，整个系统会逐渐变成没人真正理解的巨大黑盒。最终，任何小改动都可能引发连锁反应，每一次上线都像是在拆炸弹，而团队的开发效率也会被慢慢吞噬。 然而，令人尴尬的是，公司里的大多数人并不能真正理解这种恐惧。原因在于，他们害怕的根本不是复杂度，而是不确定性。 我把企业简化成两个循环。第一个循环属于市场、销售、产品经理和 CEO。在这个循环里，人们最关心的问题是：“这个方向到底行不行？”、“用户会不会买单？”、“这个功能有没有价值？”他们最大的敌人，是市场不确定性。因为没有任何商业决策能够保证成功，所以唯一能做的事情，就是不断尝试、不断上线、不断获取反馈，然后根据反馈快速调整方向。在这种环境里，速度自然就成了最重要的东西，因为谁能更快进入市场，谁就更有机会降低不确定性。 而 AI 恰恰极大强化了这种逻辑。AI 可以帮助团队更快生成代码、更快做原型、更快验证需求，因此从业务角度来看，它几乎像一种革命性的生产力工具。很多人因此开始相信：既然 AI 已经可以高速生成代码，那么软件开发本身似乎也会越来越廉价。 但问题在于，当公司真正拥有客户之后，第二个循环就会出现。 这个循环不再关心“探索”，而是开始关心“稳定”。系统必须持续运行，支付不能中断，线上服务必须可靠，Bug 必须有人能修，代码必须有人看得懂，新人也必须能够接手系统。于是，资深开发者开始拼命控制复杂度，因为他们真正负责的，并不是“把功能做出来”，而是“保证整个系统能够长期稳定运行”。 这时候，双方的矛盾就出现了。 业务团队关心的是如何更快降低市场不确定性，而资深开发者关心的是如何控制系统复杂度。于是双方虽然都在讨论“开发”，但实际上讨论的根本不是同一个问题。业务团队希望的是“更快上线”，而资深开发者担心的是“系统越来越危险”。当资深开发者不断强调维护成本、长期复杂度和技术债务时，这些话对于业务部门而言往往毫无说服力，因为他们真正焦虑的是：如果现在不上线，会不会直接失去市场机会。 我对此给出了一个非常精准的总结：你不能用自己的问题，去解释别人的问题。 资深开发者之所以总是显得“保守”“拖慢进度”，并不是因为他们不懂业务，而是因为他们一直在用“复杂度管理”的语言沟通，而公司其他人真正关心的，却是“如何更快减少不确定性”。这两套语言天然无法对接，于是沟通自然失败。 真正优秀的资深开发者，其实非常擅长一件事情：用尽可能少的建设，完成真正需要完成的目标。当团队想做复杂的新功能时，他们可能会先在现有界面放一个按钮测试用户行为；当团队想搭建完整的数据分析系统时，他们会先思考：“我们到底想验证哪个决策？”很多时候，他们甚至会直接使用 Google Forms 之类现成工具，因为他们非常清楚，公司真正需要的往往不是“完整系统”，而只是“验证问题”。 于是我提出，每个资深开发者都应该学会一句话： “Can we try something quicker?” “我们能不能先试一个更快的方法？” 这句话之所以厉害，是因为它同时满足了双方的需求。它既承认业务真正需要的是速度，也保留了工程上的克制；它没有直接否定需求，而是把“减少复杂度”重新翻译成了“更快降低不确定性”。我认为，这才是资深开发者真正缺失的沟通能力。 而文章最有意思的部分，其实是关于 AI 的最后讨论。很多人现在会说，既然…

Anthropic 最近因为一项安全研究登上了新闻头条：他们声称 Claude Mythos 完成了“首个由 AI 发现并成功利用的远程内核漏洞”。 这个说法听起来相当震撼。 于是我们开始追踪：Mythos 究竟是怎么做到的？ 结果发现，它找到的其实是一个已经存在了将近 20 年、几乎明晃晃摆在那里却没人注意到的老漏洞。 下面我们来拆解 Mythos 到底做了什么，以及这件事真正意味着什么。 Claude Mythos 到底发现了什么？ 在 Anthropic 关于 Claude Mythos 的最初文章中，他们提到了多个由 Mythos 发现并利用的漏洞。 其中技术细节最完整的，是 CVE-2026-4747 —— 一个存在于 FreeBSD 网络文件系统中的远程代码执行漏洞（RCE）。 这类网络文件系统广泛部署于企业和科研机构的本地存储系统中，因此影响范围并不小。 漏洞本身是一个非常经典的“教科书级”漏洞：栈缓冲区溢出（stack overflow）。 更关键的是，FreeBSD 默认并未启用某些现代安全防护机制，例如： 这使得漏洞利用难度进一步降低。 问题核心出现在 svc_rpc_gss_validate() 函数中。 函数内部会把 RPC Header 重建到一个仅有 128 字节的栈缓冲区 rpchdr[] 中： 其中： 但程序随后直接执行： 却完全没有检查 oa_length 是否超过剩余空间。…