Fragments: June 2

标题：Fragments：6月2日

URL 来源：https://martinfowler.com/fragments/2026-06-02.html

发布日期：2026年6月2日 09:21:35 GMT

Markdown 内容： Greg Wilson 注意到，许多人正在使用不可靠的指标来判断 AI 工具是否值得投入成本。

你会衡量生成的代码行数，还是关闭的工单数量？或者你会发送调查问卷，询问开发者是否感觉生产力提高了？这些方法各有各的缺陷；

他列举了大量常见指标及其缺陷。遗憾的是，他并未提出更优的替代方案。在我看来，由于我们无法衡量生产力（参见 Cannot Measure Productivity），任何指标充其量都只是弱证据。

我确实部分采用了他所批评的指标之一：“询问开发者是否感觉生产力提高”。尽管我承认该指标存在他指出的问题，但在缺乏可靠度量手段的环境中，即使是这种微弱的线索也是我们目前能获取的最佳参考。在这种情况下，这类定性指标或许无法得出明确结论，但它们仍然具有价值（参见 Measuring Developer Productivity: Humans）。

❄❄❄❄❄

Benedict Evans 指出，过去的大规模自动化并未导致职业的消亡。

我们用了一个世纪来实现会计工作的自动化：从计算机器、穿孔卡、大型机、数据处理系统、数据库、个人电脑、电子表格、ERP 系统到云计算……事实上，我们构建了整个科技行业的一半，都是围绕自动化会计工作展开的。然而，会计师的数量却持续增长。

他深入分析了预测技术对就业影响时面临的诸多难题。其中最常被讨论的杰文斯悖论（Jevons paradox）指出：当某项技术变得更便宜时，人们会更频繁地使用它，从而增加需求。这通常会导致工作性质的改变，即使工作名称保持不变。

今天的会计师所做的工作与 1970 年或 1980 年的会计师并不完全相同——尽管他们仍被称为“会计师”，但工作内容已大不相同。新技术往往最初被用于“以更高效的方式完成旧工作”，但很少会一直停留在这个阶段。

技术变革常常影响整个行业。以互联网对新闻出版业的影响为例：2000 年初，谁会想到智能手机的兴起会导致网约车应用的出现，从而彻底改变出租车行业的经济模式？结论是：至少可以确定的是，预测 AI 对工作的具体影响几乎是不可能的。

❄❄❄❄❄

Stephen O’Grady 分析了闭源模型与开源模型在基准测试中的表现变化。

闭源模型在创新速度上遥遥领先，持续在能力边界上取得突破。开源模型则在追赶，且追赶周期正在缩短。目前没有清晰的能力护城河，今天处于前沿的技术明天可能就成为基础标准。

开源模型在这些基准测试中追上 GPT-4 花费了 13-18 个月，但追上 GPT-4o 仅需 2-7 个月。

他列举了该分析的诸多限制条件，但整体而言，这是一份值得参考的调研，展示了各类模型在不同评估维度上的表现。

❄❄❄❄❄

AI 使用粗疏的最明显例证之一是幻觉引用——这既暴露了 LLM 的使用痕迹，也反映出使用过程中的疏忽。GPTZero 是一家开发 AI 内容检测工具的公司。我不了解其工具的实际效果，但该公司确实会发布 AI 使用情况的调查报告，其中多篇文章揭示了幻觉引用问题。其中一篇聚焦于安永加拿大公司关于忠诚系统网络安全威胁的报告，发现其超过一半的参考文献都是虚构的。该报告在呈现信息时使用了大量令人厌烦的动画（甚至导致 Safari 阅读模式崩溃）。但这类 AI 生成报告的危害远不止误导读者：

在线发布报告本质上是向互联网知识库注入数据。如果报告包含虚假信息（无论是虚构的引用还是错误主张），就可能“污染知识库”，误导后续研究者，尤其是当报告由知名咨询公司发布并托管在高流量网站上时。

❄❄❄❄❄

随着 LLM 在编程能力上的提升，人们自然担忧其可能被用于攻击软件系统。但这些模型同样可以用于防御，帮助团队在攻击者之前发现漏洞。Mozilla 的一些成员分享了他们如何利用 AI 模型在 Firefox 中识别并修复前所未有的大量潜在安全漏洞（https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/）。

几个月前，AI 生成的安全漏洞报告在开源项目中主要以无用垃圾的形式出现。处理那些看似合理但实际错误的报告，给项目维护者带来了不对称的成本：用 LLM 生成代码中的“问题”非常简单快捷，但验证和修复却既耗时又昂贵。

这种局面在短短几个月内发生了巨大转变。这主要归功于两个因素：首先，模型的能力显著提升；其次，我们大幅改进了利用这些模型的技术——包括引导模型、扩展模型规模、堆叠模型以生成大量有效信号并过滤噪音。

2025 年，Firefox 每月修复的安全漏洞数量为 17-31 个。而在 2026 年 4 月，这一数字飙升至 423 个。

❄❄❄❄❄

Pavel Voronin 对 Unmesh Joshi 关于《什么是代码》的文章What is Code进行了评论。他指出，代码库中的冗余（技术债务）一直给软件开发带来摩擦。但当 LLMs 使用现有代码作为未来工作的上下文时，这种冗余的后果会进一步加剧。

在退化的代码库中，模型不会将“技术债务”视为债务。它看到的是示例。它看到的是先例。它看到的是可以延续的风格。

LLMs 放大了当前发生的事情。我听说有报告称，由于 LLMs 会模仿代码库中已有的内容，优质代码可能会取代大部分 Markdown 中的内容。但劣质代码也会被放大。不可避免地，他引入了另一种广泛使用的债务隐喻变体：

当团队使用不再理解的抽象概念时，认知债务就会累积。当代码库包含模型可能继续使用的混乱概念时，生成债务就会累积。

认知债务涉及团队不再理解的内容。生成债务涉及模型现在可能复制的内容。

❄❄❄❄❄

来自非常有价值的 404 media 的 Jason Koebler 撰写了一篇哀怨的文章，题为《AI 生成的垃圾正让我们发疯》[https://www.404media.co/your-ai-use-is-breaking-my-brain/]。这不仅是因为它用这种垃圾填满了网络，还因为它让我们人类对垃圾和垃圾威胁的反应变得疯狂。我们审视自己的写作时会发现：伤害我们的不仅仅是阅读 AI 生成的垃圾，还有我们写出的东西看起来像 AI 垃圾的风险。如果我使用 AI 从我这里复制的表达方式，这是否意味着我在抄袭 AI？这导致了“人类化工具”的出现——AI 工具，使我们的写作看起来不像 AI。

人类化工具添加拼写错误、随机替换单词、移除“AI 语句”，有时还会插入随机字符。

这是走向僵尸互联网的又一步：

我称之为僵尸互联网，因为事实是，互联网的很大一部分不仅仅是机器人与机器人对话或机器人与人对话。而是人与机器人对话、人与人对话、人创建“AI 代理”然后指示它们与人互动。[…] 这就是我的邮箱，过去偶尔会收到一些格式糟糕、文笔拙劣、极其冗长的邮件，发件人是那些坚信 CIA 用未公开的秘密技术将他们关在虚拟酷刑室里的人，但现在我收到的却是格式良好、文笔尚可、极其冗长的邮件，发件人是那些坚信自己已证明 AI 具有意识并拥有 AI 转录来证明这一点的人。

❄❄❄❄❄

Andy Osmani 指出，创建大量代理就像启动一堆并行进程，这些进程都依赖于一个单一的协调线程——你自己[https://x.com/addyosmani/status/2059844244907696186]。

Python 有全局解释器锁（GIL）。你可以创建任意多的线程，但一次只能有一个线程执行 Python 字节码，因为它们必须获取锁。你是 AI 代理的 GIL。它们可以同时运行。但当它们的任何工作需要真正理解架构或解决合并冲突时，该工作必须获取锁。只有一个锁。你持有它。

这意味着你必须考虑到 GIL 来设计代理的工作流程。你不应该启动超过你能妥善审查的代理数量。将可以委托给代理的后台任务与需要专注处理的复杂任务分开是很有用的。不要用你宝贵的脑力去做机器可以自行验证的事情。[我还要补充——让机器构建工具来简化人工验证。例如，将测试用例数据以表格形式呈现，而不是埋在断言语句中，这样更好。]

创建代理不是技能。任何人都可以运行 20 个。

真正的技能是围绕那个无法复制或并行化的单一串行资源来设计系统。这个资源就是你的注意力。

❄❄❄❄❄

Jamie Hurst 是 booking.com 的首席工程师，他在开发者体验领域工作，专注于 AI 工具。他在这项工作中真实地撰写了关于使用 LLMs 的收益和损失的文章[https://jamiehurst.co.uk/2026-05-24_ai-sustainable]。

构建成本已经崩溃，但组织协调成本却没有。事实上，它还上升了。当三个不同的团队都能在原本撰写提案所需的时间内各自产生一个可行的解决方案时，瓶颈就从工程转向了协调。

他认为自己作为高级工程师能够做更多事情，但担心这对他个人和他工作的组织来说是否可持续。他能够同时为多个工作流设定方向，这在三年前是做不到的。但一个损失是，他没有足够的时间进行指导，这将在长期内对雇主造成影响。他还发现，他没有足够的时间思考。

AI 带来的生产力提升被输出量而不是输出质量所捕获。组织的期望上升以吸收这种加速，而过去任务之间存在的松弛时间——战略思考实际发生的时间——首先被吞噬了，因为它在仪表盘上是不可见的。我正处于职业生涯的一个阶段，思考本应是工作的大部分，但现在大部分思考发生在假期，因为工作周无法容纳它。