第六章：文件修改与审阅：如何把风险降到最低

6.1 核心原则：你审阅的是“差异”，不是“解释”

Claude 可以写很多解释，但真正决定质量的是 diff：

• 改了哪些文件
• 删除/新增了什么逻辑
• 是否引入了额外风险（例如：改动扩散、边界被打穿）

所以在每个关键节点，你都应该要求：

请先给我 /diff，我审阅通过后再继续下一步。

6.2 小步改动：一次只改一个主题

最常见的失败模式是：修 bug 的同时顺手重构半个项目。结果是：

• 审阅困难
• 回滚困难
• 测试失败时难定位

推荐工作方式：

• 第一轮：只修 bug（最小可用）
• 第二轮：补测试/补边界
• 第三轮：再重构与清理

6.3 明确“禁止动作”

如果你不写禁止动作，Claude 很可能会“顺手帮你优化”。建议你把禁令写在任务里：

禁止：
1) 新增依赖
2) 修改配置与基础设施目录
3) 大规模重命名/格式化全仓库

6.4 审阅清单（你可以照着逐条过）

• 变更是否集中在目标相关文件？
• 是否引入了新的公共 API/行为变化？
• 错误处理是否更清晰而不是更隐蔽？
• 是否补上了边界条件（空值/异常/大数据）？
• 是否存在“硬编码”导致的环境耦合？

6.5 让 Claude 输出“审阅摘要”

除了 /diff，你还可以要求一个结构化摘要，便于团队协作：

请按以下格式总结改动：
1) 改动文件列表
2) 行为变化（用户可感知）
3) 风险点与回滚方式
4) 已运行的验证命令与结果

6.6 本章小结

这一章的目标只有一个：把风险降到最低。

• 关键节点先 /diff 再继续
• 小步改动，一次只改一个主题
• 禁止动作写清楚，避免改动扩散
• 用审阅清单确保质量可控

下一章我们把“验证”体系化：如何让 Claude 帮你稳定地跑命令与测试，让每次交付都可复现、可回滚。