给编程 Agent 划清修复与重构边界
文章以 Agent 修复空订单崩溃时顺带修改七个文件为例，说明无关清理会扩大审查范围。作者援引 Google 小变更原则，主张将缺陷修复与重命名、整理导入及重构拆开提交。
原文暂未完整获取，基于公开信息的快读
让编程 Agent 修一个空订单崩溃，交回的分支却改了七个文件：修复之外，还有变量重命名、导入排序和逻辑抽取。dev.to 的这篇文章用这个场景提醒开发者：测试通过，不代表改动适合一起审查。作者援引 Google 的代码审查指南，主张把缺陷修复与无关清理拆开。
目前能确认什么
节选中的问题是 calculateTotal() 遇到空订单时崩溃，修复是在函数开头增加守卫语句，也就是先处理特殊输入，再进入后续计算。Agent 同时把 amt 改成 amount、整理 cart.ts 的导入，并将相邻的折扣逻辑抽成 helper。
这些改动的目的不同。审查者既要判断崩溃是否解决，又要确认重命名和逻辑搬移有没有改变行为；回滚混合提交时，无关整理也会一起撤销。
据节选引用，Google 提倡一个 CL（changelist，变更集）只处理一件事，通常应将重构与功能修改、缺陷修复分开。但指南也允许顺带进行局部变量改名等小清理。
对 Agent 一律采用更严格的拆分要求，是作者的主张，并非 Google 指南的原话。
我的判断
对程序员最有用的，是把「完成修复」定义清楚：提交应包含修复及对应测试，发现的其他问题列入交付说明，写明位置和原因，另行处理。
审查边界应按改动目的划分，不能只数文件。修复可能需要跨文件修改；同一文件里也可能混入无关重构。因此，文件统计适合发现疑点，不能单独证明越界。
节选尚未展示完整论证，也没有提供拆分成本的实测依据，作者所说的成本很低不能当作普遍结论。此外，文中关于 Claude Code 读取 AGENTS.md 的具体条件，仍需官方文档确认。指令文件可以表达约束，最终是否遵守，还得检查实际 diff。