AI 辅助开发进入「可以信赖」的门槛了吗？开源大牛本周各自给出了答案

本期看点

本周有几条线索值得并排看。

DHH 用了整整一周时间测试 GPT5.5 和 GitHub Copilot，给出了带具体命中率的评测；Mitchell Hashimoto 发布了一套「用 AI 生成可丢弃垃圾代码来验证 SDK 设计」的方法论；Kelsey Hightower 在播客里直接说了他认为写代码从来就不是瓶颈；Mark Erikson 用一篇长文记录了从因 AI 抑郁到深度使用的完整心路。

安全领域则出现了一个有意思的对照实验：Mozilla 用 Anthropic Mythos 在两个月里发现了 271 个 Firefox 漏洞，几乎无误报；同一个 Mythos，cURL 维护者 Daniel Stenberg 扫了 178,000 行代码，5 个声称漏洞仅 1 个确认为真实 CVE。两边工程条件的差异，比结论本身更值得读。

DHH：这周他测了三个 AI 工具，都给了分

DHH（David Heinemeier Hansson，Ruby on Rails 创始人、37signals 联合创始人兼 CTO）本周在 X 上发了一批技术帖，主题集中在他正在日常使用的 AI 工具。这批帖子不是感想，而是带数据的观察。

GPT5.5 评测：DHH 表示连续使用 GPT5.5 低推理（low reasoning）模式超过一周，评价是「非常好、非常高效」。他特别说「没有一次冲动想切回 Opus」，认为 GPT5.5 的输出比 Kimi（指 Moonshot AI 的 Kimi K2 系列）更简洁，称其为 OpenAI 的「巨大飞跃」。1

DHH @dhh·5w

I've been driving GPT5.5 on low reasoning for the last week+ and it's very good, very efficient. Haven't been tempted to reach for Opus at all. And it's more succinct than Kimi too. Huge leap forward for @OpenAI 👌

View on X

正在加载内容卡片…

Copilot 评测：五月九日，DHH 观察到 GitHub Copilot 近几周出现了明显变化，代码审查命中率从之前的 1/10 跳到了 7/10，能「持续发现真实问题」。2 他在同一条帖子里也给了一个批评：Copilot 会重新抛出已被用户手动否决的建议，去重逻辑需要改进。这个观察很具体——从「基本无用」到「实用工具」的跨越，命中率是唯一有参照系的数字。

RSpec → Minitest 转换案例：五月十二日，DHH 引用了开发者 Igor Alexandrov 的一个实测案例：用 Claude 将 SafariPortal 的 RSpec 测试套件转换为 Minitest，7,003 个测试用例的跑测时间从 16 分 52 秒降至 111 秒，性能提升约 9 倍（5,698 次运行，19,375 条断言）。3 DHH 的评论是：「我已经试图告诉大家 20 年，fixtures 和避开 RSpec 才是正确路线。但没有任何论证比让 AI 帮你做转换、然后亲眼看到性能提升更有说服力。九倍！」

这个案例的意思不只是「AI 可以做重构」，而是 AI 正在把原本需要共识的技术选型辩论，变成一个可以实测的工程决策。

项目动态：Omarchy（DHH / Basecamp 团队维护的开源 Linux 发行版）发布 3.8 版，新增提醒、天气、系统默认设置（浏览器 / 终端 / 编辑器）、无加密安装选项，以及集成转码流程。4

Mitchell Hashimoto：先让 AI 写一堆垃圾代码，然后扔掉

Mitchell Hashimoto（Ghostty 创建者，HashiCorp 联合创始人，Terraform、Vagrant、Vault 的创造者）本周发布了一条关于 AI 辅助插件系统开发的方法论线程，技术细节密度高。

他目前在做一个未公开的新项目，核心工作之一是设计插件 SDK。他的方法是：先手工搭出最小可用的 SDK 框架，然后把 AI agent 放进去，让它批量生成一次性（他的原话是 slop）插件实现，用于测试 SDK 的人体工学。不是用 AI 构建最终产品，而是用 AI 生成「可丢弃的探针」。5

他从分析这些「AI 垃圾插件」中提取共性 pattern——哪些 API 调用方式让 AI 也觉得繁琐、哪些接口会触发重复模板——然后迭代改进 SDK 设计。AI 代码最终全部丢弃，但通过它暴露的设计问题留下来。

这套方法他类比为「README 驱动开发」和 Terraform 早期用 shell 脚本做 PoC 的实践。6 三者的共同逻辑是：在大量实现工作开始之前，先用成本最低的方式验证接口设计是否舒适。

他说得很清楚：

"In this example, I'm transparent that the frontend is slop so they can know that'll get better (I'll rewrite it) but that we're really exercising and testing the core primitives and making sure those feel good."
「这个例子里，我对外明确说了前端是 slop，让他们知道那部分之后会改（我会重写），但我们真正在做的是压测核心原语，确认这些用起来顺手。」

对比他早年的经历：「用 Terraform 那会儿，构建一个最小可用插件至少要花几十分钟。AI 解决了这个问题，这次体验好多了。」数十分钟的 PoC 成本，现在可能压缩到几秒钟的 prompt 成本，设计迭代循环因此可以跑得更快。

他同时强调：slop 只适合内部验证，不应该直接发给用户。这不是关于 AI 代码质量的结论，而是关于「什么阶段用什么代码」的工程纪律。

Kelsey Hightower：写代码从来就不是瓶颈

Kelsey Hightower 与主持人 Alexa Griffith 在 Alexa's Input (AI) 播客对谈

图片来自：Beyond the Clouds with Kelsey Hightower // Alexa's Input (AI) Podcast

五月十日，Kelsey Hightower（Kubernetes 布道者，前 Google 杰出工程师，Kubernetes The Hard Way 作者，2023 年正式退休）做客 Alexa Griffith 主持的 Alexa's Input (AI) Podcast，进行了一次 66 分钟的深度对话。这是他退休后为数不多的播客露面，也是五年后回访同一档节目。7

他在节目里的核心论断是：写代码的速度从来就不是软件工程的真正瓶颈。

"Writing code faster, I don't think was really truly ever the problem. It's the mess that we make."
「写代码更快，我认为从来就不是真正的问题。是我们制造的混乱。」

他的推论是：代码越多，维护负担越重，攻击面越大，需要管理的系统也越复杂。所以他认为工程师应该追求「用最少的工作量创造最大的影响」，而不是「产出更多代码」。他把那种只会持续产出代码、陷入无意义忙碌的状态叫做「busybot」。

在讨论 AI 对工程职业的影响时，他给出了一个具体的思维实验：

"If everyone in the world has access to the AI that can create near-perfect software... then the value of that is nothing. So then what value is left? Your ability to make decisions."
「如果全世界的人都能用上能生成近乎完美软件的 AI，那这件事本身的价值就归零了。剩下的价值是什么？是你做决策的能力。」

他用 Louis Vuitton 做了个类比：顶级皮具设计师的核心价值不在于缝制皮包，而在于设计决策。AI 让「缝制代码」这件事的边际价值趋近于零，但「决定做什么、为什么做」的价值不会随着 AI 的普及而稀释。

他还批评了工程团队的一个常见盲点：人们会为 AI 精心准备文档、上下文和清晰的提示词，却持续对真人同事做不到同等水平的沟通。这个讽刺他说得直接：

"The way people have been pouring resources into artificial intelligence, but then continue to ignore real intelligence."
「人们把资源倾注给人工智能，却持续忽视真实智能。」

对于入行五年左右的工程师，他给出了三条并行建议：成为技术历史的「史学家」（学习 C、内核、内存管理等基础）、熟练使用 AI 工具、通过参与开源 AI 项目做风险对冲。这三条建议的逻辑是：理解底层才能判断 AI 在哪里出错，参与开源才能保持对工具的主动权。

Mozilla vs cURL：同一个 AI，两个截然不同的安全审计结果

这是本周信息密度最高的对比。Anthropic Mythos（Anthropic 旗下专注代码安全审计的 AI 系统）在两个真实项目上被独立测试，结论相反，但原因清楚。

Mozilla Firefox：271 个漏洞，几乎无误报

Mozilla 在 Ars Technica 的采访中披露了一次为期两个月的 AI 安全审计项目。8 项目负责人 Brian Grinstead（Mozilla 杰出工程师）带领团队，使用 Mythos 加上 Claude Opus 4.6，在 Firefox 代码库中发现并修复了 271 个安全漏洞：180 个 sec-high、80 个 sec-moderate、11 个 sec-low。团队公开了 12 份完整 Bugzilla 报告（含触发测试用例）用于证明透明度。

Grinstead 对误报率的描述是：「几乎没有误报。」

关键工程决策不在于用了哪个模型，而在于他们如何包装这个模型。Mozilla 自建了一套 agent harness：将 Mythos 嵌入一个循环 Agent 系统，让它能读写文件、运行 Firefox 的 sanitizer build，并根据 yes/no 反馈迭代。成功标准是确定性的——「如果你能让 sanitizer build 崩溃，你就赢了。」此外还加了第二个 LLM 对第一个 LLM 的输出评分验证，高评分才给予与传统方法同等的置信度。

Grinstead 在采访里直接驳斥了「营销噱头」的质疑：「这里没有任何营销角度。我们的团队已经完全接受了这种方法。我们试图传播的是关于这种技术的信息，而不是关于任何特定的模型供应商或公司。」8

Mozilla 团队也坦承了早期失败：没有 harness 包装时，AI 生成的漏洞报告细节经常是幻觉——这就是他们最初踩到的「AI slop」问题，也是后来加入 sanitizer 反馈循环的原因。

cURL：5 个声称漏洞，仅 1 个是真的

同一个 Mythos，在 cURL 代码库上的结果截然不同。五月十一日，cURL 创始人和唯一长期维护者 Daniel Stenberg 在博客发布了测试报告。9

Mythos 扫描了 cURL 的 src/ 和 lib/ 子目录，共约 178,000 行 C 代码，报告发现 5 个「已确认」安全漏洞。Stenberg 和安全团队逐项深入审查：3 个是 API 文档里已经明确说明的已知限制（误报）、1 个是普通 bug 而非安全漏洞，仅剩 1 个确认为真实漏洞，严重程度为 low。

Daniel Stenberg 在 Mastodon 发起的社区投票：1,127 人参与，40% 预测 Mythos 会发现 10 个漏洞，32% 预测 1 个——结果与 32% 的预测接近

图片来自：Mythos finds a curl vulnerability - daniel.haxx.se

Stenberg 的结论是：「围绕这个模型的大肆炒作，迄今为止主要是营销。我没有看到证据表明这个设置在发现问题方面达到了比其他工具明显更高或更先进的程度。」9

他同时指出，Mythos 还给出了约 20 个「非漏洞 bug」，描述详细，误报极少——这部分他评价「检测标准相当高」。他对 AI 安全工具整体是肯定态度，说不用 AI 代码分析器就等于给攻击者留时间。只是 Mythos 没有超出 cURL 项目之前已经在用的其他工具（AISLE、Zeropath、OpenAI Codex Security）。

顺便说，Stenberg 是通过 Linux Foundation 的 Alpha Omega 项目获得 Mythos 访问权限的，由于延迟最终由第三方代为执行扫描。

cURL 项目多层安全防护措施全景：代码风格检查、人工评审、大量测试、静态分析、fuzzing、签名发布、CVE 流程、安全审计

图片来自：Mythos finds a curl vulnerability - daniel.haxx.se

两个结果为什么不一样

对比这两个案例，关键变量是 agent harness 的设计——运行时反馈回路的有无，直接决定了 AI 能否区分「代码逻辑问题」和「真实可触发的安全漏洞」。Mozilla 给 Mythos 配了一套完整的工具调用环境（能运行真实 build、获取 yes/no 成功信号、多轮迭代），成功标准是机器可判断的；cURL 的扫描是静态代码分析，没有运行时反馈循环。这个条件差异，比「哪个 AI 更强」的问题更值得在做安全审计方案时认真考虑。

Mark Erikson：从因 AI 抑郁到深度使用，一个维护者的心路报告

Mark Erikson 是 Redux、Redux Toolkit、Reselect、Immer 等 React 生态核心库的维护者，这些库的总周下载量超过 600 万次。五月七日，他发布了一篇长文——「My Thoughts on AI, Part 1: Fears, Opinions, and Mental Journey」——记录了从 GPT-2 时代（2019 年）到今天对 AI 的完整态度演变。10

他在文章里坦承：2025 年 3 月，持续的 AI 冲击让他陷入了人生第一次短暂的抑郁状态。他对 AI 的核心恐惧不是 Skynet，而是具体的三件事：代码质量崩塌、初级工程师的成长路径被摧毁、以及自己「不再能亲手写代码的失落感」。

转折点是 2025 年 4 月的 React Miami 会议，他在那里自行调整了 mindset。2025 年 8 月开始用 KiloCode（基于 Claude Sonnet）辅助理解代码，到 2026 年初已经在深度使用 Claude Code 做架构研究、代码生成和重构。

让他真正接受 AI 的关键 insight，他概括为：「可维护性才是 mindset」——AI 生成的代码必须像人写的一样可读、可测试、可维护。用对待初级工程师 PR 的审查态度看 AI 输出，而不是因为「它是 AI 生成的」就特别警惕或特别放松。

他对 hallucination 的态度转变也值得关注：从「出现幻觉 = AI 不可用」，到「幻觉只是需要被发现和修正的 bug，只要你有审查能力就好」。真正促使他改变预设的，是用 AI 重构 Immer 时，AI 给出了一个他没想到的、更优雅的架构方案。

文章同时发布了第二部分「AI Thoughts Part 2: Agent Workflow & Tools」，详述具体技术工作流，但本周索引的是第一部分的完整路径。

本周其他动态

Adam Wathan（Tailwind CSS 创始人）：Tailwind CSS v4.3 于五月十三日发布，新增 scrollbar 工具类、zoom 工具类、tab-size 工具类及若干小型改进。11 发布博文：tailwindcss.com/blog/tailwindcss-v4-3

五月九日，Wathan 还批评了一种流行的 AI 使用方式——抓取他人网站的 DESIGN.md 然后让自己的网站「看起来像别人网站的劣质版本」，并直接问：「有人真的想要这种结果？」12

Brendan Eich（JavaScript 创造者，Brave CEO，Mozilla 联合创始人）：五月十二日发了一条关于搜索引擎竞争的线程，论点是 Brave Search 证明了构建完全独立且具竞争力的搜索引擎在技术上可行；Google 的真正优势在于分发渠道和变现能力，而 EU DMA（欧盟数字市场法案）的监管框架没有触及这两个核心杠杆。13

Tim Sweeney（Unreal Engine 创始人，Epic Games CEO）：五月十四日发文称 Apple 对「下一代开发工具」的打压是「对所有开发者自由的威胁」。14 同日另发帖认可 Godot（开源 3D 游戏引擎）的增长表现：「令人印象深刻。」15

Chris Lattner（LLVM、Swift、Mojo 创始人，Modular CEO）：Mojo 1.0 进入 Beta 阶段（Beta 1），Modular 官方发布公告，Chris Lattner 转推。这是 Mojo 迈向年内正式发布 1.0 的第一步。16

Guillermo Rauch（Next.js、Vercel 创始人）：五月十四日分享 Vercel AI Gateway 的生产数据洞察：Google Gemini 3 Flash 在 token 使用总量上领先，Anthropic Claude 系列在编程支出和消费金额上占主导，OpenAI 自 GPT5.4 以来快速增长，开源模型持续获得份额。原话：「AI 竞赛比看起来更具流动性。」17

Andrew Nesbitt（ecosyste.ms 创始人）：五月十三日报告了一条独立学术验证。慕尼黑工业大学和 fortiss 的研究团队在 arXiv 发表论文（arXiv:2605.06164），基于 718,750 个 PyPI 包和 200 万条依赖边建模，对比了三种开源支持机制：Tidelift、GitHub Sponsors 和 ecosyste.ms Python 基金。ecosyste.ms 仅选取了 97 个包，但在模拟中覆盖了 PyPI 总体改进影响的 25.9% 和退化影响的 38.0%，每包效率最高。18 Nesbitt 的重点是：依赖图而非下载量或 star 数，才是衡量开源项目真正重要性的正确维度。

封面图：图片来自 Beyond the Clouds with Kelsey Hightower // Alexa's Input (AI) Podcast