用持续 AI 打击代码混乱
在过去 25 天里，我利用 Claude Code 在多个 git 工作树（worktrees）中并行生成了近 70 万行代码。我不知道阅读完所有这些代码需要多久，但我敢肯定，那绝对超出了我的时间储备。
我同样可以肯定的是，在这 70 万行代码中，许多（或许是大多数？）都是“垃圾代码”。
重复的逻辑、混乱的抽象、无用的注释、安全漏洞、低效的数据库查询——即使是最聪明、最昂贵的 AI 代理，除非你对其严加管束，否则它们不可避免地会产出这些标准的“垃圾”。
在 Continue，我们的团队共同对抗代码垃圾。我们将共同的标准编码进一个代理中，并在我们提交的每一个 PR（拉取请求）上运行它。我们称之为“防垃圾代理”（Anti-Slop agent）。
防垃圾（Anti-Slop）云端代理是如何工作的
理念很简单：将您团队的标准编码到一个自动化云代理中，该代理在您看到 PR 之前就会运行。将您的最佳实践转化为 AI 审查员。
我们的防垃圾代理会在 CI 中针对每个 PR 运行。它会检查变动的文件，识别出“垃圾代码”模式，并进行清理。如果代码已经很整洁，它就不会做任何操作。
以下是该提示词（Prompt）的核心内容：
遵循反 AI 垃圾规则（Anti AI-slop rule）：清理任何损害可读性和可维护性的 AI 生成代码模式。查看此 PR 中更改的文件。如果有任何包含垃圾模式的文件，请进行针对性的修改以进行清理。每次最多修改单个文件。如果无需更改，则什么也不做。
然后，我们会在特定代码库的基础上，定义什么对我们而言是“垃圾”。例如 TypeORM 的 N+1 查询，或者在代理忘记检查我们共享包时产生的重复方法等。
为什么这有效
现成的代理擅长通过静态分析来捕捉 Bug。但随着我们向代理委派更多的编程工作，代码审查需要超越捕捉 Bug 的范畴。我们需要将团队的知识和最佳实践编码进代理中——就像高级工程师通过审查过程将辛苦积累的代码库知识传授给初级工程师一样。
问题在于，你无法将所有这些内容一股脑塞进编程代理的上下文窗口（Context Window）中。比起要求编程代理记得在完工后清理自己，使用一个带有全新上下文窗口的新代理既更可靠也更便宜，而且人类审查起来也更容易。透过窄小的镜头，一次关注一个问题，比试图同时在大脑中处理所有事情要容易得多。对于代理而言也是如此。
因此，你需要一个独立的审查步骤。理想情况下，将其拆分为由团队负责并不断迭代的离散重点领域。在 CI 中运行它，意味着无论是否有人记得在本地运行检查，代码始终是稳健的——这正如标准的 CI/CD 最佳实践一样。
这些代理检查并不能取代人工审查。它们旨在处理代码审查中经常出现的琐碎、吹毛求疵的反馈。相反，你可以专注于真正重要的事情，比如系统架构。
这就是持续 AI（Continuous AI）
这就是我们所说的持续 AI：代理能够根据开发工作流和外部环境发出的信号自动运行。PR 打开，代理进行审查；触发警报，代理进行分拣。你的工具发出信号，代理采取行动。你可以在我们的指南和这篇博客文章中阅读更多关于持续 AI 级别的内容。
防垃圾代理只是最简单的例子之一，但这种模式是可以扩展的。安全检查、性能审计、文档更新、依赖关系审查，每一个都可以是你的团队拥有并进行迭代的独立代理。
目标不是取代开发人员，而是将已经发生的重复性工作编码进持续运行的系统中，以便人类可以专注于那些真正需要人类判断力的事情。
自己尝试
你可以通过点击下方链接并连接你的 GitHub 来亲自尝试防垃圾代理。它将被添加为仓库的 CI 检查，并在每个 PR 上运行，帮助你抵御“代码垃圾”。