使用 AI 更慢地编写更好的代码

首页 应用 代码谈论 « 编码艺术的衰落 5 月 25 日 使用 AI 更慢地编写更好的代码 由 Nolan Lawson 在软件工程领域于 2026 年 5 月 25 日发布。标签：人工智能。 4 Comments 许多人似乎相信人工智能编码的目的是尽可能快地编写低质量的代码。吐出勉强过得去的废话，打开大量的 PR，然后未经审查地合并它们。发货吧！但问题是，LLM 非常灵活。您可以同样有效地使用它们来更慢地编写高质量代码。在这一点上，这个说法对我来说似乎是完全显而易见的，因此我几乎不想写这篇文章。但似乎有足够多的人相信法学硕士只能作为污水大炮，因此值得提出相反的理由。如果说 Mythos 教会了我们什么的话，那就是 LLM 代理非常擅长发现 bug。将它们扔到代码库足够多次，它们会发现如此多的错误，以至于您几乎不知道如何处理它们。和其他许多人一样，我也发现非 Mythos 模型也是如此——有些模型可能比其他模型更擅长发现细微的错误或避免误报，但事实是，Anthropic 和 OpenAI 的最新公共模型足以在未经审查的代码库中发现大量错误。问题不在于发现错误，而在于确定它们的优先级并对其进行验证。出于这个原因，我有一项从本文的核心见解中改编而来的克劳德技能，即你在公关审查中投入的模型越多、不同，你出现幻觉或虚假错误的可能性就越小。该技能说（释义）：运行 Claude 子代理、Codex 和 Cursor Bugbot 来查找此 PR 中按严重/高/中/低排名的错误。全部完成后，审查他们的发现，进行自己的研究以排除误报，并撰写最终报告。基本上就是这样。如果你愿意的话，你可以添加你自己对“bug”的定义——我的有关于 KISS 和 DRY 原则的规定，编写可访问的 HTML/JSX，为 SQL 查询使用适当的索引等。根据我的经验，这种技能总是能在 PR 中发现大量的 bug，并且误报率接近于零。它会发现如此多的错误，如果你试图解决所有错误，你会感到无聊而毫无意义。它们的范围从关键的安全性或正确性错误到更普通的中级性能错误到低级的“此评论具有误导性”类型的错误。我的典型工作流程是： 让代理修复所有关键点和高点（在我对正确解决方案的指导下），然后重复，直到没有关键点/高点 跳过不值得挤压的高点/中点（例如，用 100 行代码来修复狭窄的边缘情况） 如果 PR 有太多关键点，以至于我意识到整个方法都被误导了，则放弃 PR 当我使用此技术时，我不一定会看到我的速度有所提高。如果有的话，审查过程经常会发现预先存在的错误，所以我最终会进行一个无关紧要的支线任务，即编写单元测试并修复 PR 之前的微妙缺陷。这与大多数人在考虑 Vivi 编码时所想象的“10 倍生产力”的大炮开发风格相反，但我发现它非常令人满意。这是改善代码库整体健康状况的好方法，同时还能教您了解其中的奇怪角落。根据我的经验，复杂架构的幸福路径不如其故障模式有趣。在法学硕士之前，这通常是我熟悉代码库的方式：了解假设在哪里失效，然后亲自动手修复它。如果你是那种对人工智能编码有什么好处持怀疑态度的人，那么我怀疑这篇文章能否说服你。但是，如果您是那种使用代理编写数百行 PR 的开发人员，而您自己几乎无法理解，那么我会邀请您放慢速度，尝试另一种更慢的“氛围编码”风格。询问代理人你的公关是如何运作的以及它可能会失败的原因。如有必要，让它用 Mermaid 图表编写 Markdown 文档。使用 Matt Pocock 的 /grill-me 技巧，直到你从头到尾理解整个公关。就原始代码行而言，您可能不会更加“高效”。您可能会烧毁大量代币，只是为了发现您的整个计划从一开始就是错误的。但我发现这种编码风格是我在获得法学硕士之前就已经尝试过的那种编程的更强大的版本：仔细、有条理、注重质量、专注于为下一个编码员提供更好的东西。因此，深呼吸，放慢速度，尝试这种技巧，看看你是否不喜欢更慢地编写更好的代码。与此帖子相关的 4 条回复。由 heckj 发布于 2026 年 5 月 25 日上午 9:32 我发现同样的技术——进行多次扫描——对于各种审查都非常有效；我用同样的方法对语法、标点、拼写等进行编辑审查。我意识到的一件事是，擦除*之间*扫描的上下文也有帮助。我已经开始将我的代码审查切换为并行运行的“5-7 个不同的镜头”——寻找差异