title: "AI排查后端500 | 从堆栈到根因" category: 人工智能 tags:

上一篇讲前端白屏。

这一篇讲后端最常见的报错：

500 Internal Server Error。

用户看到 500，通常只知道：

接口炸了。

但后端工程里，500 只是一个结果。

背后可能是：

空指针。
数据库连接失败。
SQL 约束错误。
第三方 API 超时。
环境变量缺失。
JSON 解析失败。
权限判断异常。
文件路径不存在。
内存不足。
代码版本和数据库迁移不匹配。

这类问题特别适合用 AI。

但前提是你给的不是一句：

接口 500，怎么修？

而是一份排错包。

1. 500 排错最重要的是请求上下文

后端日志里只看 stack trace 不够。

你要告诉 AI：

哪个接口。
什么方法。
什么参数。
哪个用户。
什么时间。
是否所有请求都失败。
最近改了什么。

模板：

【请求】
- Method:
- URL:
- Query:
- Body 脱敏后:
- User / tenant 脱敏后:
- Request ID:
- 时间:

【返回】
- Status: 500
- Response body:

【日志】
- 同一 request_id 的后端日志
- stack trace
- 上游/数据库/第三方 API 错误

【最近变更】
- 代码：
- 配置：
- 数据库迁移：
- 依赖升级：

【边界】
- 不输出真实 Key
- 不删除数据
- 先给只读验证步骤

AI 有了 request_id，才能把一堆日志串起来。

没有 request_id，它只能在日志里猜。

2. 先让辅助模型整理日志

后端日志通常很长。

不要一上来把几千行交给 Fable 5。

先让低成本模型做：

请从下面日志中提取与 request_id=xxx 相关的错误。
只输出时间、级别、模块、错误类型、关键堆栈、上游调用。
不要判断根因。

输出最好是表格：

时间 模块 错误 证据
21:03:11 api/user TypeError Cannot read property id
21:03:11 db QueryFailed duplicate key
21:03:12 gateway 500 request_id=xxx

然后再让 Fable 5 判断：

哪个是根因。
哪个是连带错误。
哪个是噪音。

这就是 4SAPI 路由的价值。

3. 给 Fable 5 的根因判断 Prompt

你是后端 500 排查工程师。

请根据请求信息、日志摘要、堆栈、最近变更，判断最可能根因。

要求：
1. 按概率排序给出 3 个候选根因。
2. 每个根因必须引用证据编号。
3. 先给只读验证步骤。
4. 不要建议删除数据、重启生产数据库、回滚生产，除非明确标注为人工确认动作。
5. 如果证据不足，列出还需要补充的日志或命令。

输出：
- 一句话结论
- 根因排序
- 验证步骤
- 最小修复建议
- 是否需要回滚

这条 Prompt 的核心是：

先验证，再修复。

不要让模型看到 500 就直接给改代码方案。

4. 常见根因一：环境变量缺失

线上 500 很常见的原因是：

本地有 .env。
线上忘了配。

表现可能是：

Cannot read properties of undefined。
Missing DATABASE_URL。
Invalid API key。
JWT_SECRET is required。

AI 排查时要看：

日志里是否出现 env 名称。
部署平台环境变量是否存在。
代码读取环境变量的位置。
是否只有线上报错。

给 AI 的安全做法：

只给环境变量名称，不给真实值。

例如：

已配置：
DATABASE_URL=[已配置]
JWT_SECRET=[未配置]
SAPI_API_KEY=[已配置，不展示值]

不要把真实数据库连接串贴给模型。

5. 常见根因二：数据库迁移没跑

代码已经上线，但数据库结构没跟上。

常见日志：

column "xxx" does not exist
relation "xxx" does not exist
Unknown column
no such table
PrismaClientKnownRequestError

AI 排查路径：

1. 看报错字段或表名。
2. 对照最近 schema / migration。
3. 看生产是否已执行迁移。
4. 看代码版本是否依赖新字段。
5. 给出只读检查命令。

注意：

不要让 AI 直接跑生产 migration。

让它先输出：

需要人工确认的迁移动作。
可能影响的数据。
回滚方案。

数据库迁移不是普通修复。

它可能不可逆。

6. 常见根因三：第三方 API 失败

很多后端 500 其实是第三方 API 异常。

比如：

支付接口超时。
短信接口失败。
对象存储上传失败。
模型 API 返回 401/429/500。

这类要看：

上游响应码。
超时时间。
重试次数。
是否有 fallback。
是否把上游错误直接抛给用户。

如果是大模型 API 调用失败，4SAPI 日志特别有用。

你可以查：

request_id
model
status_code
error_code
input_tokens
output_tokens
retry_count
fallback_model

然后让 Fable 5 判断：

是 Key 问题、模型名问题、限流、超时，还是上游临时故障。

不要让后端把所有模型 API 异常都变成一个模糊 500。

最好在服务端做错误映射：

401 -> 配置错误
429 -> 限流或预算
504 -> 超时
5xx -> 上游异常

7. 常见根因四：输入数据异常

有些 500 只在特定用户、特定订单、特定文件出现。

这通常不是系统全挂。

而是某条数据触发了边界情况。

比如：

用户名为空。
订单状态不合法。
上传文件没有扩展名。
数组为空但代码取第一项。
金额字段是字符串。
旧用户数据缺少新字段。

给 AI 的材料要脱敏：

用户 ID: [user_123]
订单 ID: [order_456]
字段结构：保留 key，敏感 value 替换。

不要把真实手机号、邮箱、地址、身份证、支付信息丢给模型。

AI 只需要结构，不需要隐私。

8. 常见根因五：错误处理太粗

很多后端 500 的问题，不只是“有 bug”。

而是错误处理没有分层。

比如：

用户参数错，也返回 500。
权限不足，也返回 500。
第三方超时，也返回 500。
数据库唯一约束冲突，也返回 500。

Fable 5 可以帮你审查错误处理：

请审查这段 API handler 的错误处理。
目标是把用户输入错误、权限错误、上游错误、数据库错误和未知错误区分开。
不要重构业务逻辑，只给最小改造建议。

这类任务很适合高级模型。

因为它不只是修一个报错，而是改善长期可维护性。

9. 只读验证命令示例

不同项目不同，但思路相同。

看日志：

docker compose logs --tail=200 app

按 request_id 查：

grep "request_id=xxx" app.log

看服务状态：

docker compose ps

看最近部署：

git log --oneline -5

看环境变量是否存在，不输出值：

printenv | grep -E "DATABASE_URL|JWT_SECRET|SAPI_API_KEY" | sed 's/=.*/=[set]/'

注意：

只确认是否 set，不输出真实值。

这个习惯很重要。

10. 4SAPI 怎么配合后端排错

如果后端 500 与模型 API 有关，4SAPI 能提供：

调用时间。
模型名称。
状态码。
错误码。
token 用量。
重试次数。
fallback 记录。
Key 分组。
项目标签。

建议在后端请求里打通：

业务 request_id -> 4SAPI task_id

这样后端日志里出现：

request_id=api_123
model_task_id=llm_456

你就能把业务错误和模型调用串起来。

否则排查时会变成两边翻日志。

11. 后端 500 复盘模板

修完以后，让 AI 帮你生成复盘。

请根据这次 500 排障记录生成复盘文档。

包括：
1. 影响范围
2. 时间线
3. 根因
4. 直接修复
5. 防止复发的改动
6. 需要补充的监控
7. 是否需要补测试
8. 涉及的 4SAPI 调用日志 task_id

要求：
区分事实和推测。
不要输出真实密钥或用户隐私。

复盘的价值是：

下次同类 500 不再从零开始。

12. 总结

后端 500 不是结论。

它只是入口。

AI 排查 500 的正确方式是：

用辅助模型整理日志。
用 Fable 5 判断根因。
用复核模型审查修复风险。
用 4SAPI 记录模型调用和成本。

给 AI 的材料要包括：

请求上下文。
堆栈。
最近变更。
环境变量状态。
数据库状态。
第三方 API 返回。
边界条件。

最后记住：

500 先查证据链，不要先重启服务。

下一篇写 Docker 容器起不来。

因为很多后端 500 的上游根因，最后都会落到容器、环境变量和服务启动状态上。