先找回“原来能用”时的参照

让 AI 加一个字段、调整页面或修复报错之后，登录、查询或后台保存突然异常，首先要把变化停在可以理解的位置。保留当前代码、错误记录和已有的版本历史，找出最近一次正常工作的版本，并写清最初希望增加什么功能。

接着沿同一条操作路径对比：谁在什么页面做了什么，过去出现什么结果，现在变成什么。能复现的差异，比“整个系统被改坏了”更容易指向具体问题。没有完整版本记录时，也可以从部署包、备份和现有日志逐步还原线索。

把修改放回业务链路中检查

先阅读实际差异，再看文件之间的联系。例如一个表单保存问题，可以顺着页面字段、接口参数、权限判断、数据库写入和返回结果逐层核对。除了直接修改的文件，还要留意新增依赖、配置变化、数据结构和被删除的校验。

GitHub 的 AI 代码审查指南提醒，应核对代码与需求及原有架构是否一致，并留意不存在的 API、被忽略的约束以及被删除或跳过的测试。[1] 因此，解释看起来合理只是一条线索，最终仍要回到运行行为和原有业务规则。

让 AI 帮助分析，让证据决定结论

可以让 AI 整理改动、追踪调用关系，或根据官方文档补充陌生组件的背景。给它明确的目标、相关代码和已观察到的现象，再要求说明每个判断依赖什么证据。对于版本相关行为，查阅与当前环境相符的文档，并用小范围复现验证。

排查时保留几个可检验的假设：字段是否改名、接口是否仍返回原格式、依赖版本是否兼容。一次验证一个关键差异，记录成立或排除的理由。这样后续调整能接着已有结论推进，也减少新修改把旧线索覆盖的机会。

根据影响范围选择修复或回退

原因已落到明确位置时，可以保留有用改动，只修复造成回归的部分。如果变化范围很大、业务持续受影响，则先评估可用的恢复版本。选择要结合当前数据、依赖关系和停用功能的影响，不能只依据代码改了多少行。

回退前尤其要核对数据库迁移和新增数据：旧程序与现在的数据是否仍能配合？已提交的内容如何保留？先在隔离环境确认路径，再记录准备调整的文件、配置和退回方法。每一步都应能说明为什么改，以及改完准备看什么。

验证原功能，也验证相邻功能

沿最初失败的路径重新操作，再覆盖受同一接口或数据结构影响的功能。视实际情况检查正常输入、异常输入、不同权限和重复提交，并观察对应日志。GitHub 同样将功能检查与静态分析作为审查的组成部分；已有测试是否仍有效，也需要一起确认。[1]

修复记录保留四件事：确认的原因、实际改动、验证结果，以及尚待观察的范围。把这次遇到的业务约束补进项目说明，下一次借助 AI 修改时，就有更清楚的上下文和可重复的验证依据。