AI 生成的垃圾代码是流程问题，而非人为问题

在 CI/CD 出现之前，生产环境的稳定性是个人责任。如果有人在周五提交了有问题的代码导致网站崩溃，事后分析的结论往往会指向某个人。当时的文化会将过错归咎于个人：你弄坏的，你负责。

CI/CD 不仅仅是实现了构建和部署的自动化，它还重构了问责制。当每次推送和部署流水线都会运行测试并执行质量准入控制时，“谁提交了 Bug”就不再重要了，重要的是“为什么流水线放行了它”。团队开始共同编写测试、协作维护流水线，将生产稳定性视为一个共享的系统，而不是个人尽职程度的总和。

指责的对象从“人”转移到了“流程”。这才是真正的改变。

现在，同样的转变迫在眉睫，而大多数团队还没有意识到这一点。

指责放错了地方

采用 AI 辅助编码的团队，其 PR（合并请求）交付速度提升了 2 到 5 倍。其中很大一部分代码是由 AI Agent 生成的。当出现次品代码时，事后分析有了新的目标：那个让 Agent 编写代码的开发人员。他们本应审查得更仔细，本应给出更好的提示词，他们太相信输出结果了。

这与 CI/CD 出现之前团队犯的错误如出一辙。它将系统性问题归结为个人问题。

Agent 之所以输出垃圾代码，并不是因为开发人员粗心，而是因为流程中没有任何机制来捕获这些问题。代码未经任何标准校验，就直接从 Agent 进入 PR 并被合并。没有任何“关卡”去询问新的 API 端点是否需要限流；没有检查机制去验证数据库查询是否符合团队既定模式；没有任何机制标记缺失的输入验证。

指责开发人员解决不了这些漏洞，更好的流程才能。

CI/CD 之前的先例

在自动化测试出现之前，团队依赖开发人员手动验证更改。有些人很仔细，有些人则不然。质量成了个人勤勉程度的函数，而非系统设计的产物。每次发生事故后的应对措施都千篇一律：请更仔细一点。

现在关于 AI 编码的讨论也在重复这一套说辞：更仔细地审查 Claude 的输出，不要盲目信任，你仍然需要逐行阅读。这些建议虽然正确，却无法扩展。

依赖个人审查的问题在于，它无法应对大规模的交付量。CI/CD 出现之前，代码吞吐量有限，手动验证尚且可行。CI/CD 消除了这一瓶颈，团队突然面临抉择：是让审查人员数量随吞吐量线性增长，还是将标准编码并实现自动化执行？

选择后者的团队并没有降低质量标准。他们不再依赖每一位开发人员在每一次 PR 中都能记住所有标准，而是将标准直接编码到流水线中。

AI 编码工具也为同样的解决方案提供了支撑。代码吞吐量增长了 2-5 倍，但能进行审查的资深工程师数量却没变。对 AI 生成的每一行代码进行人工审查，不过是“请更仔细一点”的老调重弹。这种方法无法扩展。

系统化解决方案的样子

当 CI/CD 成熟时，质量保证被移入流水线中。测试必须通过，Lint 规则必须符合，安全扫描会拦截合并。这不是因为开发人员变得不仔细了，而是因为在大规模生产中，单靠“仔细”是不够的。

针对 AI 生成代码的系统化解决方案遵循同样的逻辑：显式编码团队标准，然后在每次 PR 时将其作为自动化检查运行。

这意味着要明确写下你的要求。例如：每个新端点都需要限流；新的外部依赖项需要包含理由注释；数据库查询必须遵循团队既定模式；代码变更时必须更新文档。这些并非新颖的标准，而是你的资深工程师在代码审查时会关注的事项——只需将其表述得足够清晰，让自动化系统能够进行评估即可。

AI 检查会在人类审查者看到代码之前，对每个 PR 进行评估。Continue 将这些检查构建为仓库中的版本控制 Markdown 文件，每个文件在每次 PR 时都作为一个完整的 Agent 运行，专门检查你指定的内容。它要么静默通过，要么以具体的建议修复报错。使用编码 Agent 的开发人员无需在每次提交时都记住团队的所有标准，因为流水线会帮他们把关。这不是那种带有个人偏见的通用 AI 审查员，而是你所制定的、始终如一执行的、不会产生“审查疲劳”的标准。哪怕是资深工程师在一天中审查的第八个 PR，这些标准依然能准确命中。

值得一问的问题

CI/CD 并没有彻底消除生产事故，但它改变了事故发生时团队提出的问题。不再是“谁干的？”，而是“是什么环节放行了它？”这种重新定义引领了更好的流水线、更高的标准，以及一种将生产稳定性视为集体责任，而非归咎于最后提交者的文化。

AI 生成的代码正在引发一类新的事故。团队还在问“是谁让 Agent 写这段代码的？”但更有建设性的问题是：“在合并之前，应该是什么机制拦截住它？”

Continue 将每项检查变成你仓库中的 Markdown 文件。定义一个团队在审查中强制执行的标准，将其添加为检查，并在你的下一个 PR 中运行它。