Using AI to write better code more slowly

使用 AI 更慢地写出更好的代码 | 阅读茶渣

阅读茶渣 | 软件及其他黑暗艺术，作者：Nolan Lawson 主页 | 应用 | 代码 | 演讲 | 关于 被削弱的编码艺术 5月25日 使用 AI 更慢地写出更好的代码 发布于 2026年5月25日，作者：Nolan Lawson，分类：软件工程。标签：AI。9 条评论。

很多人似乎相信，AI 编码的意义在于以最快的速度写出低质量的代码。喷出勉强能用的垃圾，打开巨大的 PR，然后未经审查就合并。发版吧！但问题是，LLM 非常灵活。你可以同样有效地使用它们，更慢地写出高质量的代码。

这句话对我来说现在完全显而易见，正因如此，我几乎不想写这篇文章。但似乎有足够多的人相信 LLM 只适合做垃圾喷射器，所以值得提出相反的观点。

如果 Mythos 教会了我们什么，那就是 LLM 智能体非常擅长发现 bug。把它们扔向一个代码库足够多次，它们会发现大量 bug，多到你几乎不知道该如何处理。像许多其他人一样，我也发现这对于非 Mythos 模型也是如此——有些模型在发现细微 bug 或避免误报方面可能比其他模型更好，但事实是，来自 Anthropic 和 OpenAI 的最新公开模型已经足够好，可以在未经审查的代码库中发现大量 bug。

问题不在于发现 bug，而在于对它们进行优先级排序和验证。出于这个原因，我根据这篇文章的核心见解调整了一个 Claude 技能，即：你投入 PR 审查的不同模型越多，你得到幻觉或虚假 bug 的可能性就越小。该技能的内容是（转述）：

运行一个 Claude 子智能体、Codex 和 Cursor Bugbot，以按严重/高/中/低等级排序的方式找出此 PR 中的 bug。一旦它们全部完成，审查它们的发现，进行你自己的研究以排除误报，并撰写最终报告。

基本上就是这样。如果你愿意，可以添加你自己对 bug 的定义——我的定义包含关于 KISS 和 DRY 原则、编写可访问的 HTML/JSX、为 SQL 查询使用适当的索引等规定。根据我的经验，这个技能总能在 PR 中发现大量 bug，而且误报率接近零。它发现的 bug 如此之多，以至于如果你试图全部解决，你会感到无聊透顶。它们范围从关键的安全性或正确性 bug，到更普通的 medium 级别的性能 bug，再到低级的“这个注释有误导性”类型的 bug。

我的典型工作流程是：

让一个智能体修复所有严重和高级别的 bug（在我的指导下采用正确的解决方案），然后重复直到没有严重/高级别 bug
跳过那些不值得投入精力的高级别/中级别 bug（例如，用 100 行代码修复一个狭窄的边缘情况）
如果 PR 有太多严重 bug，以至于我意识到整个方法都是错误的，就放弃该 PR

当我使用这种技术时，我并没有看到我的速度有所提升。相反，审查过程常常会发现预先存在的 bug，所以我最终会陷入一个旁支任务，编写单元测试并修复早于该 PR 的细微缺陷。这与大多数人想到“氛围编码”时所想象的 10 倍生产力的垃圾喷射器式开发方式相反，但我发现它非常令人满意。这是改善代码库整体健康状况的好方法，同时也能让你了解代码库中那些奇怪的角落。

根据我的经验，复杂架构的快乐路径远不如它的失败模式有趣。而在 LLM 出现之前，这通常也是我熟悉代码库的方式：理解假设在何处失效，然后亲自动手修复。如果你是那种怀疑 AI 编码对任何事情有用的人，那么我怀疑这篇文章不会说服你。但如果你是那种使用智能体编写数百行代码、自己却几乎不理解 PR 的开发者，我邀请你放慢一点速度，尝试这种更慢的“氛围编码”风格。让一个智能体解释你的 PR 是如何工作的，以及它可能如何失败。如有必要，让它编写带有 Mermaid 图表的 Markdown 文档。使用 Matt Pocock 的 /grill-me 技能，直到你完全理解整个 PR 的方方面面。

就原始代码行数而言，你可能不会更高效。你可能为了发现你的整个计划从一开始就是错误的而消耗大量 token。但我发现这种编码风格更像是我在 LLM 出现之前就已经试图进行的编程的超级增强版：谨慎、有条理、追求质量、专注于为下一个编码者把事情做得更好。所以，深吸一口气，慢下来，尝试这种技术，看看你是否不喜欢更慢地写出更好的代码。

Using AI to write better code more slowly

使用 AI 更慢地写出更好的代码 | 阅读茶渣

相关回应