AI 生成的功能报错了，如何用浏览器状态码定位问题
训练营开发注册功能时，有同学看到编辑器里一片红色提示，就直接让 AI 连续修复；也有人只看 AI 说“已经完成”，没有真正打开页面。两种做法都绕开了最关键的一步：观察用户实际遇到的现象。
浏览器开发者工具是前后端项目最直接的诊断入口。
前置条件
- 前端和后端都已经启动，并记录实际端口。
- 能够稳定复现问题，知道执行了什么操作。
- 不在截图或日志中泄露 Token、Cookie、密码和个人数据。
- 修改前先保存当前 Git 状态。
第一步：确认真实运行表面
先回答四个问题：
- 浏览器访问的 URL 和端口是什么？
- 当前终端运行的是不是刚修改的代码？
- 页面刷新后问题是否仍然存在？
- 无痕窗口或关闭缓存后表现是否一致？
很多“修了却没变化”的原因，是浏览器仍在访问旧服务或错误端口，而不是代码修改失败。
第二步：在 Network 面板复现
打开开发者工具，切换到 Network，清空旧记录，然后重新执行一次注册、登录或查询操作。
选择失败请求，记录：
- Request URL 和 Method。
- Status Code。
- Request Payload 或 Query 参数。
- Response 内容。
- Timing 和是否被浏览器阻止。
这五项通常足以判断问题来自请求未发出、路径错误、参数错误、认证失败还是服务端异常。
常见状态码怎样理解
400 Bad Request
请求已经到达服务端，但参数、格式或业务校验不符合要求。检查前端提交字段、Content-Type 和后端返回的具体错误信息。
401 Unauthorized
请求缺少有效认证。检查登录状态、Authorization 头、Cookie 是否发送，以及 Token 是否过期。不要为了“先跑通”直接关闭认证。
403 Forbidden
身份可能有效，但没有执行该操作的权限。检查角色、资源归属和服务端权限判断。
404 Not Found
优先核对请求路径、后端路由前缀、代理配置和服务端是否真的启动。前端页面 404 与 API 404 需要分开判断。
409 Conflict
常用于重复资源或状态冲突，例如账号已经存在。它可能正是需求规定的正确异常结果，不一定是系统故障。
500 Internal Server Error
服务端处理过程中出现异常。浏览器只能告诉你请求失败，真正原因通常在后端终端日志或服务器日志里。
第三步：把前后端证据关联起来
如果请求返回 500，记录发生时间和请求参数，再去后端日志寻找对应异常堆栈。数据库连接、非空约束、字段长度和空指针都可能在这里暴露。
如果 Network 完全没有请求，问题更可能在前端事件、表单校验或按钮覆盖层。
如果 API 单独调用成功，页面仍然失败，则检查前端解析、状态更新和渲染逻辑。
给 AI 的高质量问题报告
不要只说“注册报错了”，可以提交：
这份信息把 AI 从猜测拉回了可复现事实。
修复后的回归
修好一个错误后，不只重试刚才的成功场景：
- 合法注册成功。
- 重复账号仍返回正确错误。
- 非法参数仍被拒绝。
- 页面提示与接口响应一致。
- 数据库没有产生重复或半成品记录。
- 旧功能没有被本次修改破坏。
常见误区
- 看到 500 就修改前端参数，却没有查看后端日志。
- 为消除 401 暂时删除认证逻辑，留下安全问题。
- 只截图页面，不提供请求和响应。
- AI 修复后没有确认当前服务已经重启。
- 把状态码当成唯一真相，忽略响应体和业务语义。
课后练习
在自己的练习项目中制造三个可控错误：请求路径错误、参数缺失、服务端抛出异常。分别用 Network 和日志定位，写出三份最小问题报告，再让 AI 修复并完成回归。