先把问题描述完整
代码由谁写，都需要结合实际运行条件检查。AI 参与开发时，可以让它协助定位，但你需要给出足够具体的现象。
例如：本地输入数量 10、单价 12、运费 8 能得到 128；线上点击计算后没有结果。记录线上地址、浏览器、操作步骤、发生时间和页面提示，保存当前版本。报错截图和日志先去掉密钥、个人信息。
第一步：用相同步骤再试一次
先确认问题是否稳定出现。用新的浏览器窗口打开，填同一组输入；若涉及账号，记录使用的测试账号角色，不公开凭证。
问清楚“哪里开始不同”：页面打不开、按钮没反应、请求失败，还是请求成功但结果不对？每一种情况需要看的地方不同。
第二步：按现象缩小范围
| 现象 | 优先查看什么 |
|---|---|
| 首页正常，刷新某个地址失败 | 页面路由与托管配置 |
| 页面有内容，点击后没有结果 | 浏览器错误、请求状态与按钮逻辑 |
| 本地请求成功，线上请求失败 | 正式接口地址、环境配置与访问条件 |
| 保存后重新打开，数据不见了 | 数据是否真正写入、正式存储配置 |
| 不同账号看到同一批资料 | 服务端登录身份与数据查询范围 |
这些是排查方向，需要实际记录来确认。浏览器的控制台和网络面板可以看页面错误与请求状态；有后端时，还要查看对应时间的服务端日志。
第三步：对比本地与线上条件
让 AI 列出本项目用到的依赖、启动命令、配置名称、接口和数据来源，对比正式环境。只检查配置是否存在、格式是否正确，不把密钥贴进对话。
再看最近改过什么。尝试一次只处理一个有依据的原因，保留修改记录。若线上影响使用，可以先恢复已知可用版本，再在副本中排查；涉及数据的改动，要先确认备份和恢复办法。
第四步：修复后回到原来的输入
修复不能只看报错消失。重新执行最开始那组步骤，确认实际结果与预期相符，再测试相近功能：换一组输入、刷新后重试、触发失败提示。涉及账号的，用不同身份分别试。
若发现其他账号资料可被访问，要检查每个相关取数入口。本站虚构教学示例说明了怎样设计这类复查用例，并未提供一个已通过实测的生产系统。
最后留一条排错笔记
记下现象、确认的原因、改动、重试结果和仍需处理的问题。以后升级、迁移或加功能时，这条记录能帮助你复查。完整发布检查可用上线清单。
常见问题
本地能用，为什么线上不行？
可能涉及配置、依赖、文件路径、接口、数据或登录条件的差异。先用相同输入复现，再逐项对比，不能只凭现象确定原因。
把报错贴给 AI，就可以直接让它重写吗？
先补齐预期、复现步骤、最近改动和相关错误信息，让它说明依据与准备修改的范围。保留上一版，修复后重试原步骤和相关功能。
换账号后看到别人的资料怎么办？
先限制相关访问，保留必要的排查记录，检查服务端身份与数据权限。不要只修改页面提示；涉及真实数据时按实际影响进一步处理。
