许多开发者担心，将代码外包给 AI 工具会导致质量下降，产生大量虽然产出极快、却充满缺陷的代码，而决策者为了效率往往会忽视这些瑕疵。
如果采用编程智能体明显降低了你产出的代码或功能质量，你应该直接面对并解决这个问题：找出流程中哪些环节损害了输出质量，并修复它们。
使用智能体交付更烂的代码是一种“选择”。我们完全可以选择交付更好的代码。
避免背负技术债
我喜欢从“技术债”的角度来思考如何交付更好的代码。技术债通常是折衷方案的结果：因为按“正确的方式”做太花时间，所以我们被迫在时间压力下妥协，并祈祷项目能活到以后有机会还债的那一天。
缓解技术债的最佳手段，就是从一开始就避免背负它。
根据我的经验，有一类常见的技术债修复工作属于“原理简单但耗时巨大”：
-
API 设计缺陷： 最初的 API 设计没考虑到后来出现的重要场景。修复它需要改动几十处代码，于是为了省事，我们加了一个略有不同的新 API，从而忍受重复。
-
命名不当： 早期对某个概念的命名有误（例如用了
teams而不是groups），但要在全局清理这个命名工作量太大，所以我们只改了 UI 界面。 -
功能冗余： 随着时间推移，系统中出现了多个雷同但略有差异的功能，需要合并和重构。
-
文件臃肿： 某个文件已经增长到了几千行代码，理想情况下应该拆分成独立的模块。
这些改动在概念上都很简单，但都需要专门的时间投入。在面临更紧迫的任务时，这些工作往往很难获得优先级。
编程智能体可以胜任这些工作
这类重构任务是编程智能体的理想应用场景。
启动一个智能体，告诉它要改什么，然后让它在后台的分支或工作区里自行忙碌去吧。
我通常使用异步编程智能体来处理这些，比如 Gemini Jules、OpenAI Codex 网页版或 Claude Code 网页版。这样我可以运行这些重构任务，而不必中断我笔记本电脑上的工作流。
然后在 Pull Request（拉取请求）中评估结果：如果不错，就合并；如果差一点，就通过提示词告诉它哪里需要改进；如果很烂，直接丢弃。
这些代码改进的成本已经降得如此之低，以至于我们完全可以对微小的“代码异味（Code Smells）”和不便之处保持零容忍态度。
AI 工具让我们考虑更多选项
任何软件开发任务都有多种实现方案。最严重的技术债往往源于规划阶段的错误选择——比如漏掉了显而易见的简单方案，或者选了一个后来发现并不契合的技术栈。
LLM 可以确保我们不会遗漏那些之前未曾留意的方案。它们通常会推荐训练数据中常见的方案，而这些往往是那些最可能行之有效的“无聊技术（Boring Technology）”。
更重要的是，编程智能体可以辅助探索性原型开发。
做出自信技术决策的最佳方式，就是通过原型证明其适用性。
“对于一个预期有数千并发用户的网站，Redis 是活动流（Activity Feed）的好选择吗？”
确认这一点的最佳方式是编写一个系统仿真模型，并对其进行压力测试。
编程智能体只需一个精心编写的提示词就能构建这种仿真，将实验成本降至几乎为零。既然如此廉价，我们可以同时运行多个实验，测试多种方案，从而选出最适合的那一个。
拥抱“复利工程循环”
智能体会遵循指令。我们可以根据以往的经验教训，不断演进这些指令，以便在未来的运行中获得更好的结果。
Every 公司的 Dan Shipper 和 Kieran Klaassen 将他们与编程智能体协作的方法称为“复利工程（Compound Engineering）”。他们每完成一个编程项目都会进行复盘，称之为“复利步骤（Compound Step）”——他们会将行之有效的经验记录下来，供未来的智能体运行参考。
如果我们想从智能体那里获得最佳结果，就应该致力于随时间推移不断提升代码库的质量。微小的改进会产生复利效应。过去耗时的质量提升工作，现在的成本已经降到了让你没有任何借口不投入的地步。 编程智能体意味着我们终于可以同时拥有“高质量”和“新功能”。
原文：Agentic Engineering Patterns by Simon Willison
关注公众号「Python之禅」，回复「1024」免费获取Python资源
