AI Agent每天产出百万行变更时传统代码审查为何撑不住质量人类历史上很长一段时间我们靠代码审查来判断质量有人把你写的东西读一遍确认它干净、有思考、够快、能理解、测试也过关。可对Agent来说这个办法立刻失效——代码量太大谁都读不完。结果是越来越多的质量检查必须搬到Agent外围的harness、环境和操作系统里。我依然会读代码、做审查但现在会非常刻意地选择哪些地方可以用约束来代替人眼。软件质量已经变成你给Agent设下的约束本身。约束如何把“提案”变成可上线的变更约束通过测试和确定性规则直接定义系统允许做什么。正是靠持续维护这些约束我们才能在Agent每天产生几十万甚至上百万行变更的情况下仍然稳定交付生产级软件。这些约束就是质量门禁形式很多常规单元测试、属性测试、验收测试突变测试——生成代码变体再跑同一套测试确认没有漏掉的bug代码质量指标比如圈复杂度和行长度用来保证可读性。约束还决定系统会接受并应用哪些提案。当变更从解释器走到Agent控制器、再走向生产时我们已经做了足够多的检查确认它安全、正确、范围可控、对团队有用。Agent可以提出任何东西。真正决定它能不能上线的是你的约束。这个模型带来很多好处但也留下明显空白。一个是自主性Agent可能把意图执行得很好却在信息缺失或任务模糊时失败——既包括任务本身也包括harness、环境和其他组件对它的参数化。人类写不好代码的很多原因Agent同样会踩脆弱的环境扛不住脚本压力、非确定性构建、权限缺失、测试太弱。这反过来要求我们建设更好的环境让Agent能做真实工作、拿到可信反馈、失败时破坏面尽可能小。我们真正想要的环境是Agent能干活、反馈可靠、失败代价可控。另一个问题是信任。再聪明、再稳健的现代Agent也不能直接把意图交出去而不检查正确性。信任从一开始就存在但必须靠硬证据赢得。质量不是单一指标而是一组可调节的信号有些约束在工作开始前就塑形有些在Agent工作时给反馈有些决定输出能不能跨过生产边界。经验告诉我比起只靠单元测试更有效的是有一套更广、但刻意选择的检查集合。每个检查承担不同责任从类型安全、性能到后期安全扫描。团队也可以自己定义约束比如用ESLint这类工具强制架构规则。很多工具已经内置钩子可以在出错时把Agent或人拉进来。目前有用的Agent输出和垃圾代码之间的差距很大程度上仍取决于操作这个循环的团队技能。AI带来了高吞吐量和速度但也让人类不可能再审查每一个变更。你必须刻意分配注意力。如果把人工检查塞进一个以机器速度运转的系统别惊讶它会拖慢整体效率。人类注意力稀缺且昂贵应该主动导向那些真正需要判断力的细微问题。下游的人只在自动化护栏失效时才被拉进来。未来的“代码审查”会完全不同。正确性只是一个维度你可能还关心可维护性、性能、安全、效率和可理解性。就像正确性可以拆成多种信号质量的其他维度也一样。约束的数量重要更重要的是它们是否足够严格能达到你对生产就绪的标准。软件质量不是单一指标而是一组对你和团队重要性各不相同的信号。背压如何贯穿整个交付管道背压可以通过多种工具实现编译器拒绝无效代码、测试失败、安全策略拦截坏实践、CI拒绝部署。理想情况下它存在于循环的每个环节而不是所有工作结束后的一次性审查。约束和背压让Agent在问题变成灾难前就抓住坏工作。如果变更量超过工具的消化能力我们就会建队列依赖以人类速度运转的验证系统。要扩展就必须把尽可能多的验证推进到循环内部而不是等到最后。如果自动化检查能跟上整个交付系统的速度和吞吐就能上去如果验证循环撑不住就得做几件事扩大验证系统的容量降低Agent生成新变更的速率或者降低质量门槛让验证不那么用力推回。从扩展角度看这三件事都要准备好。同时也不要忽略在某些方向上放松约束其实能让我们做得更多——比如用Agent swarm或自动化软件工厂让变更生成不再等人工逐条审查。在某些地方给更多自由同时在其他地方收紧约束。通过对最在意的地方施加更强约束可以在不牺牲质量的前提下最大化吞吐。这些决策里有大量权衡。最明显的是质量不同维度之间的交易安全很重要但我们也必须在安全与按时交付之间做选择。从创新优先到质量优先中间是一条连续光谱我们得决定自己站在哪里。我们希望环境和系统能把清晰的反馈送回给Agent或团队让人专注于品味、意图和架构这些更主观的事情。如果能帮人类始终待在安全约束范围内就不必每次都费力去排查哪里出了问题。刻意决定哪里加强、哪里放松软件质量还包括可维护性、良好性能、安全、效率和易于理解。所有帮助我们达到这些标准、并保持生产流动的约束都会在交付管道里形成背压。我们必须刻意决定哪里施加强约束哪里移除或放松。只在同时服务“质量”和“吞吐”两个目标的地方加强如果某个约束对两者都没贡献就考虑拿掉。随时准备根据情况提高或降低标准。不同位置的这些约束才是质量真正长出牙齿的地方。很多时候我们可以通过部署新工具或强化现有工具制造更多背压和约束。这些信号应该尽早、通过所有可能路径出现而不是等到CI在管道尽头说“不修就不能部署”。系统最终的约束是我们自己愿意为构建和运营这个系统所做的决策与行动负责。但和其他约束一样我们也要仔细权衡自己的判断要压制多少、背压多少、充当最终检查多少。质量就在我们给Agent设下的约束里。当你思考自己应用的质量时先把这个问题陈述清楚再做出你自己的约束驱动计划。你现在的Agent循环里哪一类约束最薄弱是早期的类型与测试还是生产边界的安全与性能欢迎直接说具体场景我们一起拆。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。 AI Agent每天产出百万行变更时：传统代码审查为何撑不住质量
AI Agent每天产出百万行变更时传统代码审查为何撑不住质量人类历史上很长一段时间我们靠代码审查来判断质量有人把你写的东西读一遍确认它干净、有思考、够快、能理解、测试也过关。可对Agent来说这个办法立刻失效——代码量太大谁都读不完。结果是越来越多的质量检查必须搬到Agent外围的harness、环境和操作系统里。我依然会读代码、做审查但现在会非常刻意地选择哪些地方可以用约束来代替人眼。软件质量已经变成你给Agent设下的约束本身。约束如何把“提案”变成可上线的变更约束通过测试和确定性规则直接定义系统允许做什么。正是靠持续维护这些约束我们才能在Agent每天产生几十万甚至上百万行变更的情况下仍然稳定交付生产级软件。这些约束就是质量门禁形式很多常规单元测试、属性测试、验收测试突变测试——生成代码变体再跑同一套测试确认没有漏掉的bug代码质量指标比如圈复杂度和行长度用来保证可读性。约束还决定系统会接受并应用哪些提案。当变更从解释器走到Agent控制器、再走向生产时我们已经做了足够多的检查确认它安全、正确、范围可控、对团队有用。Agent可以提出任何东西。真正决定它能不能上线的是你的约束。这个模型带来很多好处但也留下明显空白。一个是自主性Agent可能把意图执行得很好却在信息缺失或任务模糊时失败——既包括任务本身也包括harness、环境和其他组件对它的参数化。人类写不好代码的很多原因Agent同样会踩脆弱的环境扛不住脚本压力、非确定性构建、权限缺失、测试太弱。这反过来要求我们建设更好的环境让Agent能做真实工作、拿到可信反馈、失败时破坏面尽可能小。我们真正想要的环境是Agent能干活、反馈可靠、失败代价可控。另一个问题是信任。再聪明、再稳健的现代Agent也不能直接把意图交出去而不检查正确性。信任从一开始就存在但必须靠硬证据赢得。质量不是单一指标而是一组可调节的信号有些约束在工作开始前就塑形有些在Agent工作时给反馈有些决定输出能不能跨过生产边界。经验告诉我比起只靠单元测试更有效的是有一套更广、但刻意选择的检查集合。每个检查承担不同责任从类型安全、性能到后期安全扫描。团队也可以自己定义约束比如用ESLint这类工具强制架构规则。很多工具已经内置钩子可以在出错时把Agent或人拉进来。目前有用的Agent输出和垃圾代码之间的差距很大程度上仍取决于操作这个循环的团队技能。AI带来了高吞吐量和速度但也让人类不可能再审查每一个变更。你必须刻意分配注意力。如果把人工检查塞进一个以机器速度运转的系统别惊讶它会拖慢整体效率。人类注意力稀缺且昂贵应该主动导向那些真正需要判断力的细微问题。下游的人只在自动化护栏失效时才被拉进来。未来的“代码审查”会完全不同。正确性只是一个维度你可能还关心可维护性、性能、安全、效率和可理解性。就像正确性可以拆成多种信号质量的其他维度也一样。约束的数量重要更重要的是它们是否足够严格能达到你对生产就绪的标准。软件质量不是单一指标而是一组对你和团队重要性各不相同的信号。背压如何贯穿整个交付管道背压可以通过多种工具实现编译器拒绝无效代码、测试失败、安全策略拦截坏实践、CI拒绝部署。理想情况下它存在于循环的每个环节而不是所有工作结束后的一次性审查。约束和背压让Agent在问题变成灾难前就抓住坏工作。如果变更量超过工具的消化能力我们就会建队列依赖以人类速度运转的验证系统。要扩展就必须把尽可能多的验证推进到循环内部而不是等到最后。如果自动化检查能跟上整个交付系统的速度和吞吐就能上去如果验证循环撑不住就得做几件事扩大验证系统的容量降低Agent生成新变更的速率或者降低质量门槛让验证不那么用力推回。从扩展角度看这三件事都要准备好。同时也不要忽略在某些方向上放松约束其实能让我们做得更多——比如用Agent swarm或自动化软件工厂让变更生成不再等人工逐条审查。在某些地方给更多自由同时在其他地方收紧约束。通过对最在意的地方施加更强约束可以在不牺牲质量的前提下最大化吞吐。这些决策里有大量权衡。最明显的是质量不同维度之间的交易安全很重要但我们也必须在安全与按时交付之间做选择。从创新优先到质量优先中间是一条连续光谱我们得决定自己站在哪里。我们希望环境和系统能把清晰的反馈送回给Agent或团队让人专注于品味、意图和架构这些更主观的事情。如果能帮人类始终待在安全约束范围内就不必每次都费力去排查哪里出了问题。刻意决定哪里加强、哪里放松软件质量还包括可维护性、良好性能、安全、效率和易于理解。所有帮助我们达到这些标准、并保持生产流动的约束都会在交付管道里形成背压。我们必须刻意决定哪里施加强约束哪里移除或放松。只在同时服务“质量”和“吞吐”两个目标的地方加强如果某个约束对两者都没贡献就考虑拿掉。随时准备根据情况提高或降低标准。不同位置的这些约束才是质量真正长出牙齿的地方。很多时候我们可以通过部署新工具或强化现有工具制造更多背压和约束。这些信号应该尽早、通过所有可能路径出现而不是等到CI在管道尽头说“不修就不能部署”。系统最终的约束是我们自己愿意为构建和运营这个系统所做的决策与行动负责。但和其他约束一样我们也要仔细权衡自己的判断要压制多少、背压多少、充当最终检查多少。质量就在我们给Agent设下的约束里。当你思考自己应用的质量时先把这个问题陈述清楚再做出你自己的约束驱动计划。你现在的Agent循环里哪一类约束最薄弱是早期的类型与测试还是生产边界的安全与性能欢迎直接说具体场景我们一起拆。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。