网站报错或行为不对时，怎样让 AI 有依据地定位问题？
从复现步骤、预期与实际差异出发，收集正确位置的证据，每次验证一个根因假设。
本页目录
直接回答
先把“哪里不对”变成可重复的现象，再找证据。浏览器 Console、服务端终端以及线上日志各有用途，排查材料应提供技术环境、完整相关报错和刚才的操作。实践修正：Bug 和报错不是互斥类别，Bug 可能引发错误，也可能让程序安静地产生错误结果；没有红字不能证明功能正确。有效排查要同时比较预期、实际结果和数据状态，而不是让 AI 看到报错后立即改一大片代码。
适用场景
- 页面白屏、按钮无响应或输出结果不对
- AI 连续修改，始终没有稳定复现和修复
- 本地可用而线上不可用，或只有某些用户失败
一步一步做
记录最短复现过程
写明环境、页面地址、登录状态、输入和每一步操作，分别描述预期与实际。说明是否每次出现、第一次出现时间和最近变更。尽量用不会暴露用户信息的最小样例，并保存失败现场，避免刷新后丢失关键证据。
到故障发生的位置找证据
界面交互先看浏览器 Console 和 Network；服务端接口看运行终端或部署平台运行日志；无法部署看构建日志。记录相关请求的状态、返回和请求 ID。浏览器扩展报错可能是噪声，要确认与目标页面调用链有关。
让 AI 提出可证伪的假设
要求先读取相关实现和调用方，列出最有依据的原因及各自验证方式。例如缺变量、权限失败、数据为空、版本不匹配。每个假设都应说明什么观察会支持或否定它，不把概率排序当成已经查明。
一次做一个最小修复
找到共同根因后在共享位置修复，不给每个调用方堆不同补丁。配置问题就修配置，不先升级全部依赖。保留必要错误处理，禁止通过关闭类型检查、吞掉异常或伪造数据让错误表面消失。
回到原步骤验证业务结果
重复原来的失败输入，检查结果、数据库和外部调用是否都符合预期，再检查直接受影响的相邻行为。重要逻辑补一个能复现旧问题的回归验证。记录修复依据和没能检查的环境，避免“没有报错了”成为唯一结论。
把报错放回同一次操作的调用链
先打开开发者工具再重现：Console 找页面文件与行号，Network 找该操作的请求和响应；服务端报错到相同时间或请求 ID 的运行日志找，依赖安装或编译失败则看构建日志。GET 页面返回 200 仍可能在渲染时抛异常。扩展的 content_script、拦截器提示可能与业务无关，可用关闭扩展的独立测试环境对照，不能为消除红字直接移除业务防护。诊断时可在隔离练习环境模拟缺配置，不能故意把正式环境改坏。
案例拆解
假设示例：本地成功、线上模型调用失败
点击生成后返回 500，浏览器只知道请求失败。查看同一请求的运行日志发现服务端没有读到所需变量，再对比部署环境配置，确认预览环境有变量而生产环境没有。修正对应环境并重新部署后，用原输入取得真实模型结果，才可判断修复。反复调整页面 fetch 代码或更换 UI 组件都不会解决这个根因。
补充假设示例：访问 /blog 得到 200，但页面引用不存在的 BlogdddList 导致白屏。把 Console 的文件和行号与最近改名的组件对照，修复引用后再检查列表确实出现。另一条来自扩展的拦截日志若在干净环境消失，应单独记录，不把它当白屏根因。
行动检查
可复制模板
可复现的排错请求
工作模板
环境与版本：［从项目实际读取］
页面／接口：［位置］
复现步骤：［从干净起点开始］
预期：［结果］；实际：［结果］
相关报错和请求记录：［脱敏材料］
最近改动：［文件或提交］
请先定位调用链并验证根因，暂不重构。一次做最小修复，再重复原流程检查业务结果，补必要回归验证并报告证据。
日志位置与证据链
操作时间、环境、URL、账号状态：
最小复现动作：
页面Console：［相关错误、业务文件:行号，已脱敏］
Network：［请求路径、状态、响应类型、业务字段、请求ID］
服务端运行日志：［同一时间/ID］
构建日志：［若构建失败，首个有因果关系的错误］
可能的扩展噪声及对照结果：
最近改动与一个根因假设：
最小验证→修改→原步骤复验：
无法取得的证据：
易错点
- 把所有日志直接复制给 AI：先去除凭据和私密内容，保留相关上下文。
- 遇到依赖问题就删除配置或升级全部库：先确认项目工具链和实际错误。
- 关闭报错或返回默认成功：这会把显式失败变成难以发现的数据错误。