机场从一个可复现的问题开始
让 AI 帮忙改代码时，先说明什么操作触发了问题、现在发生什么、预期应该怎样。只说“这个网站有 bug”，工具可能会根据猜测改动不相关部分。一个清楚的输入例子、错误信息和最小操作路径，通常比上传整个项目更能帮助定位。
例如，搜索框输入文字后按回车会关闭弹窗，预期是保持弹窗并展示结果。这样的描述同时包含触发条件、实际表现与目标，可以据此检查修改是否有效。不要把解决这个问题与重写整个界面混成一次没有边界的任务。
准备能恢复的工作环境
在修改前保存当前工作，确认哪些文件已有自己的未完成改动。使用版本控制或工作副本，让后续能比较前后差异。不要让工具把你尚未保存的变化误当作可以清理的临时内容，也不要直接在正式服务的数据上试验。
- 记录当前可运行版本和启动方式。
- 保存需要保护的文件、配置和本地改动。
- 明确允许修改的范围与不能改变的行为。
- 准备测试用的非敏感输入。
- 确认发生错误时如何恢复到修改前状态。
如果是公司或客户项目，还应先确认代码和数据能否交给所用工具处理。移除密钥、生产连接信息和私人记录，具体准备方法可参考上传前的数据清单。
先让工具解释，再要求最小修改
可以先让 AI 指出相关文件、事件流程和可能原因，要求依据现有代码说明。解释是否贴合项目，能帮助你判断它有没有真正看到正确位置。若工具无法访问代码，应提供必要片段和环境信息，不让它假设不存在的函数或配置。
请先定位搜索框回车后关闭的原因，说明相关事件怎样触发。随后给出解决这一问题所需的最小修改，保留关闭按钮与键盘退出功能。完成后列出修改文件和验证步骤，不扩大到其他界面重构。
这种任务说明并不限制工具只能改一行，而是要求每项改动与目标有关系。确实需要调整多个文件时，让它解释依赖关系，而不是把变更数量本身当作好坏标准。
阅读差异，而不只读完成说明
代码看起来整齐、注释充分或回答自信，都不能证明行为正确。打开实际差异，检查哪些内容新增、删除和移动。特别留意依赖变化、数据写入、权限请求、网络调用和错误处理，确认这些变化属于本次任务。
AI 可能生成不存在的接口、使用与当前版本不匹配的参数，或为了消除报错移除必要校验。遇到陌生库或命令时，回到官方文档核对用途。不要因为工具给出一条可复制命令，就在没有理解影响范围的情况下运行。
测试应该验证用户行为
先验证原来的问题确实被解决，再检查紧邻功能有没有被破坏。对于搜索示例，可以分别检查输入、回车、清空、关闭按钮和键盘退出。只检查代码是否包含某个新函数，无法证明用户操作已经正常。
- 使用原来的触发步骤确认问题不再出现。
- 检查正常输入、空输入和较长输入等相关边界。
- 运行项目已有且与改动相关的检查。
- 观察错误提示与日志，不把“没有崩溃”当作完整成功。
- 必要时在不同屏幕或环境中核对受影响行为。
没有执行的测试应明确记录，不能把建议运行的命令写成已经通过。对可逆的小文案修改，也不必机械增加一套与实现完全相同的测试；检查应服务于实际风险和功能。
代码运行成功之后，还要看结果
脚本退出码正常，可能只说明命令执行结束；网页返回成功状态，也不代表页面布局、内容和链接正确。根据任务类型检查最终产物，例如导出的文件能否打开、表格是否保留格式、页面操作是否符合预期。
如果修改涉及数据转换，先用小份测试数据对比输入和输出，检查缺失值、重复值和编码。不要直接覆盖唯一的原始文件。对于删除、迁移或发布等难以撤销的操作，应先准备具体可审阅结果，再按自己的授权流程执行。
保留有用的交付记录
完成后记录问题、修改范围、验证方法、仍受环境限制的部分和恢复方式。说明应让没有参与对话的人也能理解这次变化。比起保存一整段 AI 对话，这样的简短记录更方便未来维护。
工具给出的第二次审查可以帮助寻找遗漏，但不能替代自己的判断与实际验证。无论使用 GitHub Copilot 还是其他辅助工具，开发者都应审查与验证收到的建议。把 AI 当作可以快速提出改动的协作者，配合清楚的边界、差异检查和行为验证，才更容易获得可维护的代码。
