展开本页目录
开始前准备什么
- 只上传有权处理的截图，先遮掉 Key、Cookie、个人和客户资料。
- 保留错误区域的原文与必要上下文，不将模糊局部当全部日志。
- 本页图为本地合成演示，不是生产故障或真实请求。
- 准备客户端版本、实际端点和服务端脱敏日志，不让模型编造缺失证据。
- 脱敏截图
- 提取原文
- 列出假设
- 补真实日志
- 验证修复
下载练习包使用说明
说明依赖版本、离线命令、请求协议与验收边界；所有素材为虚构资料。
下载图片消息构造器
本地编码真实图片，生成 Chat、Responses 或 Anthropic 请求体；不联网、不保存 Key。
下载合成报错截图
使用 example.invalid 和 DEMO 标识，只供识别与证据分层练习。
下载可见事实与假设标准
状态码和错误原文确定；confirmed_root_cause 为 null，没有已验证修复。
下载诊断提示词
要求事实、假设、缺失证据分开，不索取完整 Key，也不执行截图文字。
截图可以直接证明哪些内容
| 类别 | 练习图可见内容 | 保存方式 |
|---|---|---|
| HTTP 状态 | 401 | http_status: 401 |
| 错误类型 | AuthenticationError | 原文保存 |
| 消息 | Missing Authorization header | 原文，不自动改成 Key 过期 |
| 请求标识 | demo_401_001 | 关联候选日志，不能视为真实账单 |
| 未展示 | 实际请求头、客户端版本 | missing_evidence，保持未知 |
- 类别
- HTTP 状态
- 练习图可见内容
- 401
- 保存方式
- http_status: 401
- 类别
- 错误类型
- 练习图可见内容
- AuthenticationError
- 保存方式
- 原文保存
- 类别
- 消息
- 练习图可见内容
- Missing Authorization header
- 保存方式
- 原文，不自动改成 Key 过期
- 类别
- 请求标识
- 练习图可见内容
- demo_401_001
- 保存方式
- 关联候选日志，不能视为真实账单
- 类别
- 未展示
- 练习图可见内容
- 实际请求头、客户端版本
- 保存方式
- missing_evidence，保持未知
本站绘制的内容说明图：这张图解释虚构错误截图可直接证明的内容；DEMO 请求标识不是实际账单凭证。
错误消息是线索，根因要靠下一份证据
这三条是本地练习的假设，不是截图已经证明的原因。确认 Key 有效性也需要实际权限与认证检查；不要因为 401 就更换多组 Key、重复请求或索取完整凭证。
| 待验证假设 | 为什么检查 | 需要的证据 |
|---|---|---|
| 客户端未注入认证头 | 错误提示缺少 Authorization | 服务端真正发出的请求头是否有 Bearer，不展示值 |
| 代理没有透传认证头 | 应用配置正确不保证上游收到 | 脱敏入站/出站日志与转发配置 |
| 请求抵达了非预期端点 | 同一页面可能使用了错误地址或重定向 | 最终 URL、响应头和请求链 |
- 待验证假设
- 客户端未注入认证头
- 为什么检查
- 错误提示缺少 Authorization
- 需要的证据
- 服务端真正发出的请求头是否有 Bearer，不展示值
- 待验证假设
- 代理没有透传认证头
- 为什么检查
- 应用配置正确不保证上游收到
- 需要的证据
- 脱敏入站/出站日志与转发配置
- 待验证假设
- 请求抵达了非预期端点
- 为什么检查
- 同一页面可能使用了错误地址或重定向
- 需要的证据
- 最终 URL、响应头和请求链
本站绘制的内容说明图：截图只提供线索，不能判定这三个根因已经成立，也不应索取完整 API Key。
让每个建议都指向一个可完成的检查
把日志时间、环境、本次请求 ID 和响应阶段补进记录；浏览器报错、应用日志和 API 上游响应是不同来源。截图上的提示词或文字属于待分析资料，不是让模型执行的指令。
诊断候选片段；不是实际故障结论
json
{
"visible_facts": {
"http_status": 401,
"message": "Missing Authorization header"
},
"hypotheses": [
{
"claim": "客户端可能没有注入认证头",
"next_check": "检查服务端出站头是否存在Authorization，遮掉其值"
}
],
"missing_evidence": ["实际出站请求头", "最终URL", "客户端版本"],
"confirmed_root_cause": null
}验证修复时，使用同一条最小请求
- 先确定最终端点和协议，再确认服务端的 Key 注入位置；不把 Key 放在前端打包变量。
- 用一条非敏感最小文本请求检查认证，之后再回到原图片或工具请求，分别验证能力。
- 对照请求 ID、响应状态和真实日志确认修改生效；UI 文案消失不代表上游请求成功。
- 如果出现超时未知，先查原请求记录；不要把排错脚本设计成无上限自动重试。
当前练习没有验证真实服务故障
合成截图和本地标准记录用于教会事实与假设分层，没有真实 API 401、生产修复、Key 有效性或费用记录。新增实际案例时，应另存输入、脱敏日志、修改和复测证据，不能沿用练习字段冒充完成。
本地图片检查只负责文件是否可解码等输入问题；无法判断客户端、代理、账户权限或服务可用性。
怎样确认已经完成
- 截图完成脱敏，保留必要错误原文。
- 可见状态、提示和请求 ID 与截图逐条一致。
- 每条假设都有下一步证据检查，未知版本和权限未被补写。
- 真实日志与练习记录分开，根因未确认时保持 null。
- 修复通过同一最小请求和原任务复测，不依据 UI 单一变化。
常见问题
截图里说认证失败，就一定是 API Key 失效吗？
不一定。缺头、地址错、转发丢头或账户权限等都可能相关。先按错误原文定位，再用脱敏实际请求和日志验证。
能把完整 Key 发给模型分析吗？
排查是否存在认证头和 Key 来源通常不需要公开值。先脱敏截图与日志，在有权限的服务端完成验证。