演示文章：本文为站点展示而写的原创实践内容，不代表真实新闻事件、产品发布或统计结论。
先说明这次改动要解决什么
只把一段差异交给 AI，它可能更关注命名和排版，而不清楚真正需要检查的行为。可以先提供一个具体场景：改动前用户遇到什么问题，改动后应该发生什么，以及哪些相邻行为需要保持。
再补充关键调用方、数据约定和已经做过的验证。审查者知道边界，才更容易把注意力放在真正可能出错的地方。
把审查分成几个问题
- 新行为是否符合需求，有没有遗漏边界条件？
- 错误和空结果是否能被正确处理？
- 输入输出是否仍符合调用方的约定？
- 修改是否引入了不必要的重复、隐含状态或额外依赖？
- 测试结果能支持哪些结论，还有哪些没有覆盖？
不必要求它一次列出尽可能多的问题。可以让每条建议都包含触发条件、实际影响和对应位置，并允许明确说明证据不足。
审查意见还需要验证
模型提出的问题应回到代码和运行结果中核实。不要为了消除一条未经证实的建议，就改变已经明确的业务行为。
最后，将确定需要修复的问题与可选的风格建议分开处理。一次审查的价值，在于减少重要缺陷，而不是把所有文件都改成另一种写法。