“AI垃圾代码”涌入评审队列：生成速度越过人工理解上限，软件质量门如何重建？
· 来源：msn.com
AI编程智能体把“写出代码”变成低成本能力后，真正稀缺的环节正转向验证、责任追溯与以自动化护栏支撑的人类决策。
当代码生成速度远快于工程师逐行理解、追问和验证的速度，代码评审正在遭遇新的供给冲击。围绕“AI slop（AI垃圾内容）正在改变工程师审查代码方式”的讨论，焦点并不只是机器写出的代码是否能编译，而是大量看似完整、局部合理的改动进入合并队列后，团队如何继续确认它们满足业务意图、架构约束、安全要求以及长期可维护性。
GitHub 正将这一变化产品化。其 Copilot 页面显示，开发者可以把任务交给 Copilot、Anthropic 的 Claude 和 OpenAI Codex 等智能体，让它们在后台规划、检索并执行；GitHub 也提供用于跟踪多个智能体工作、审查变更和合并成果的工作区。换言之，开发流程的瓶颈正从编辑器里的代码补全，延伸至拉取请求、测试、审查和发布的整个链条。若每个智能体都能低成本发起大量改动，传统依赖资深工程师逐段阅读 diff 的质量门就会首先承压。
问题在于，“通过测试”并不等于“值得合并”。生成式工具尤其擅长产出格式正确的样板代码、重复封装和貌似周全的异常处理；但它也可能引入不必要的抽象、与既有模块重复的能力、对边界条件的错误假设，或在依赖、权限和数据流中留下难以从表面识别的风险。这类代码未必立刻报错，却会扩大后续维护者理解系统的成本。代码量因此不再是产出指标，变更是否更小、更清晰、可证明且可回滚，才应成为评审的核心问题。
这也重新划分了责任边界。智能体可以是代码的生成者，却不能天然成为风险的承担者；提交、批准和上线的责任仍须落在明确的人和组织流程上。对高风险改动而言，评审不应只看到最终 diff，还应能够追溯任务说明、模型或智能体、所用工具与权限、执行命令、测试证据及人工批准记录。GitHub 的企业治理功能已强调审计日志、访问控制和集中管理，这些能力的重要性会随智能体自主性提高而上升。
重建质量门，首先需要把验证前移并尽可能确定化。编译、类型检查、格式化、静态分析、依赖与密钥扫描、单元及集成测试，应成为智能体提交前的硬性门槛；对支付、权限、数据迁移等关键路径，还应加入针对业务不变量的测试、隔离环境验证和分阶段发布。人工评审则应从机械挑错转向审查设计取舍：为什么需要这一改动、是否复用了现有能力、测试覆盖了哪些失败场景、出现异常如何回退。
开源项目“Awesome Harness Engineering”把这类外围能力概括为“harness engineering（智能体支架工程）”：围绕模型设计上下文交付、工具接口、规划工件、验证循环、记忆、沙箱和权限系统。该项目在抓取时显示约4.1千个星标、502个分叉，所列内容也将 CI 集成、可观测性、人工在环和评测列为关键组成。它提示企业，不能只采购一个更会写代码的模型，还要建设让模型受约束、可观察、可复核的运行环境。
最终，AI不会取消代码评审，而会迫使评审从“阅读所有代码”升级为“审查证据链和系统边界”。团队若仍用提交行数衡量效率，可能只是在更快地积累技术债；若能以变更风险分级、自动化验证覆盖、可追溯性和线上质量指标衡量结果，生成能力才可能转化为可持续的软件交付能力。
—— 综合整理自：MSN、GitHub Copilot、GitHub 项目 awesome-harness-engineering、Tony Bai 文章归档