跳转至

AI 应该帮助我们产出更好的代码

原文标题：AI should help us produce better code 原文链接：https://simonwillison.net/guides/agentic-engineering-patterns/better-code/ 原文作者：Simon Willison 访问日期：2026-03-25 原文发布日期：2026-03-10 原文最后修改：2026-03-11 译文版本：v0.1

译文说明

本文为 Simon Willison《Agentic Engineering Patterns》系列 1.4 篇《AI should help us produce better code》的示范中文版。本文沿用本项目既定术语约定，将 Agentic Engineering 统一译为“智能体工程（Agentic Engineering）”，将 Coding Agent 统一译为“编码智能体”，将 technical debt 统一处理为“技术债务”。标题中的 produce 保留“产出”的工程语感，强调作者谈的不只是“写代码”本身，也包括重构、技术选型和持续提升代码库质量。

正文

所属主题：核心原则 上一篇：把你会做的事囤起来 下一篇：反模式：有些事要避免

很多开发者担心，把代码工作外包给 AI 工具之后，质量会下滑：它会高速产出糟糕的代码，快到足以让决策者愿意忽略其中的缺陷。

如果采用编码智能体，确实会明显拉低你产出的代码和功能质量，那你就应该正面解决这个问题：找出流程里到底哪些环节伤害了输出质量，然后把它们修掉。

借助智能体交付更差的代码，是一种选择。我们同样也可以选择交付更好的代码。

避免背上技术债务

我喜欢从技术债务的角度来理解“产出更好的代码”这件事。我们之所以背上技术债务，本质上是因为做了权衡：如果要“按正确的方式”去做，耗时太久，于是我们只能在当前的时间约束下工作，同时祈祷项目能活得足够久，等以后再把这笔债还上。

缓解技术债务的最好办法，是一开始就别把它背上。

以我的经验来看，有一类技术债务修复特别常见：事情本身不复杂，但非常耗时间。

  • 我们最初的 API 设计没有覆盖后来冒出来的一个重要场景。要把那个 API 修正过来，就得改动几十处代码，于是更快的做法往往是再加一个只差一点点的新 API，然后带着重复实现继续往前走。
  • 我们在早期给某个概念起了个糟糕的名字——比如应该叫 groups，却先叫成了 teams——但要把这套命名在整个代码库里清理干净，工作量太大，所以最后只在 UI 里改了。
  • 我们的系统随着时间推移，长出了重复但又略有差异的功能，现在需要把它们合并并重构。
  • 我们有个文件已经膨胀到几千行代码，理想情况下应该把它拆成多个独立模块。

这些改动在概念上都很简单，但仍然需要有人专门花时间处理。而在还有更紧迫问题要解决时，这类投入通常很难被优先排上日程。

编码智能体可以替我们处理这些事

像这样的重构任务，是编码智能体的理想应用场景。

启动一个智能体，告诉它该改什么，然后让它在后台某个 branch 或 worktree 里自己跑就行。

我通常会用异步编码智能体来做这类事，比如 Gemini Jules、OpenAI Codex web 或 Claude Code on the web。这样我就能在不打断自己笔记本电脑工作流的前提下，把这些重构任务挂到后台去跑。

在 Pull Request 里评估结果。如果结果不错，就把它合进去；如果已经八九不离十，就再给它补一轮 Prompt，告诉它该改哪里；如果结果很差，那就直接扔掉。

这些代码改进的成本已经降得非常低了，低到我们完全可以对轻微的代码异味和各种小不便采取零容忍态度。

AI 工具让我们能考虑更多选项

任何一个软件开发任务，在解决路径上都有大量不同的选项。很多最严重的技术债务，其实都来自规划阶段做了糟糕的选择：要么漏掉了一个明明很简单的方案，要么选了某项技术，后来才发现它并不真正适合当前问题。

LLM 可以帮助我们避免漏掉那些原本没进入视野、但其实很显然的方案。它们只会建议那些在训练数据里足够常见的方案，但这往往也正是最有可能奏效的 Boring Technology。

更重要的是，编码智能体还可以帮助我们做探索性原型开发。

要想有把握地做出技术选型，最好的办法，是先用原型证明它确实适合当前用途。

对于一个预计会有数千并发用户的网站活动流来说，Redis 会是一个好的选择吗？

最可靠的确认方式，就是先把那个系统的模拟搭起来，再对它跑一轮负载测试，看看究竟哪里会先出问题。

编码智能体可以靠一条精心写好的 Prompt 就搭出这种模拟系统，这会把这类实验的成本压到几乎可以忽略不计。既然它们这么便宜，我们还可以同时跑多个实验，测试不同方案，再挑出最适合当前问题的那个。

拥抱复合工程循环

智能体会遵循指令。我们完全可以随着经验积累，不断进化这些指令，让它们在未来运行时拿到更好的结果。

Every 的 Dan Shipper 和 Kieran Klaassen 把他们公司与编码智能体协作的方法描述为 Compound Engineering。他们完成的每一个编码项目，最后都会有一次回顾；他们把这个环节称为 compound step：把真正有效的做法提炼出来，记录成文，供未来的智能体运行复用。

如果我们想从智能体那里拿到最好的结果，就应该努力让代码库的质量随着时间持续提升。小的改进会不断复利。那些过去很耗时的质量提升动作，现在成本已经低到了一个没有理由不在交付新功能的同时，也顺手投资代码质量的程度。编码智能体意味着，我们终于可以两者兼得。