用智能体工程提升代码质量

很多开发者担心，把代码外包给 AI 工具会导致质量下降——快速产出糟糕的代码，而决策者可能因为速度够快就忽略其缺陷。

如果采用编码智能体确实降低了代码和功能的质量，你应该直接解决这个问题：找出流程中哪些环节损害了输出质量，然后修复它们。

用智能体产出更差的代码是一种选择。我们完全可以选择产出更好的代码。

避免背上技术债

我喜欢从技术债的角度思考如何产出更好的代码。我们背上技术债是因为权衡取舍：用“正确的方式”做事耗时太长，所以只能在时间限制内工作，并祈祷项目能撑到将来还债的那天。

避免技术债最好的方法，就是一开始就别背上它。

根据我的经验，有一类常见的技术债修复属于“简单但耗时”的改动。

• 最初的 API 设计没覆盖后来出现的重要用例。修复这个 API 需要改动几十处代码，于是干脆新增一个略有不同的 API，忍受重复代码。
• 早期给某个概念起了个糟糕的名字（比如用 teams 而不是 groups），但清理整个代码库里的命名工作量太大，所以只在 UI 层修复。
• 系统里逐渐出现了重复但略有差异的功能，需要合并和重构。
• 某个文件膨胀到几千行代码，理想情况下应该拆分成独立模块。

这些改动在概念上都很简单，但需要投入专门的时间，而面对更紧迫的问题时，往往很难为此找到理由。

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

这类重构任务正是编码智能体的理想应用场景。

启动一个智能体，告诉它要改什么，然后让它在一个分支或工作树里默默运行。

我通常用异步编码智能体来做这个，比如 Gemini Jules、OpenAI Codex web 或 Claude Code on the web。这样我可以在笔记本电脑上运行重构任务，同时不打断自己的工作流。

在 Pull Request 里评估结果。如果不错，就合并。如果接近完成，就给它提示，告诉它哪里需要调整。如果结果很差，直接丢弃。

现在代码改进的成本已经降到如此之低，我们可以对轻微的代码异味和不便采取零容忍态度。

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

任何软件开发任务都有多种解决方案。一些最严重的技术债源于规划阶段做出了糟糕的选择——比如错过了一个显而易见的简单方案，或者选了一项后来发现并不完全合适的技术。

大语言模型（LLM）能帮助我们确保不会错过那些之前可能没注意到的明显解决方案。它们只会建议训练数据中常见的方案，而这些往往是更可能奏效的“无聊技术”。

更重要的是，编码智能体可以辅助进行探索性原型开发。

做出可靠技术选择的最佳方式，是用原型证明它们适合目标。

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

最可靠的方法是搭建一个系统模拟，然后对它进行负载测试，看看哪里会出问题。

编码智能体可以根据一个精心设计的提示构建这类模拟，将实验成本降到几乎为零。而且因为成本如此低廉，我们可以同时运行多个实验，测试几种方案，选出最适合我们问题的那一个。

拥抱复合工程循环

智能体遵循指令。我们可以根据以往的经验，不断演化这些指令，以便在未来运行时获得更好的结果。

Every 公司的 Dan Shipper 和 Kieran Klaassen 将他们与编码智能体协作的方法称为复合工程（Compound Engineering）。他们完成的每个编码项目都以回顾总结收尾，他们称之为复合步骤（compound step），即把有效的方法记录下来，供未来的智能体运行使用。

如果我们想从智能体那里获得最佳结果，就应该致力于持续提升代码库的质量。微小的改进会不断累积。过去那些耗时的质量提升工作，现在成本已经降到没有理由不在开发新功能的同时投资于质量。编码智能体意味着我们终于可以两者兼得。