# Part 6 · 调试与信息窗口：程序员的"透视眼" > **本篇定位**：写 AI 应用的核心能力，不是写代码，而是**知道去哪里看反馈**。学完本篇，你能用 7 个信息窗口定位 90% 的问题。 > **阅读时长**：25 分钟 > **心流产出**：在本机分别打开所有 7 个信息窗口并截屏，形成你的"调试面板清单"。 --- ## 一、为什么"看反馈"比"写代码"更重要？ 程序不会说话，但它会通过**各类"信息窗口"**告诉你它在做什么、哪里出错。 **AI 应用出错时，90% 的时间不是在"修代码"，而是在"找该看哪个窗口"。** 本篇按"信息流动路径"由外向内整理 7 个必备工具。 --- ## 二、7 个信息窗口速览 | # | 工具 | 重要度 | 你能看到的 | | --- | --- | --- | --- | | 13 | **UI Feedback**（界面反馈） | ⭐⭐⭐⭐ | 用户可见的界面变化 | | 14 | **Console**（浏览器控制台） | ⭐⭐⭐⭐⭐ | 前端 JS 日志与报错 | | 15 | **Network**（浏览器网络面板） | ⭐⭐⭐⭐⭐ | 全部网络请求与响应 | | 16 | **Terminal**（终端） | ⭐⭐⭐⭐⭐ | 后端运行日志 | | 17 | **Server Logs**（服务器日志） | ⭐⭐⭐⭐ | 线上持久化日志 | | 18 | **SDK Debug Logs** | ⭐⭐⭐ | SDK 底层通信日志 | | 19 | **AI Service Dashboard** | ⭐⭐⭐⭐ | API Key 用量与服务状态 | --- ## 三、必须主动去看的 3 个窗口 > 不去看 = 闭着眼睛开车。 ### 1. Console（浏览器控制台） ⭐⭐⭐⭐⭐ **打开方式**：浏览器按 `F12`（或右键 → 检查）→ 切换至 `Console` 标签。 **可查看内容**： - **红色报错**：JS 语法错误、未定义变量、网络请求失败。 - **自定义日志**：`console.log('用户输入:', input)` 的输出。 - **AI 调用痕迹**：前端代码 `console.log('Prompt:', prompt)`，调试 AI 行为时极其有用。 > **一句话**：**Console 是前端逻辑的"黑匣子"。** ### 2. Network（浏览器网络面板） ⭐⭐⭐⭐⭐ **打开方式**：与 Console 同一开发者工具内，切换至 `Network` 标签。 **可查看内容**： - **所有网络请求**：页面加载资源、AI API 调用等。 - **Payload 与 Response**：请求体（发送数据）与响应体（AI 返回的原始 JSON）。 - **状态码**： | 状态码 | 含义 | | --- | --- | | `200` | 成功 | | `401` | API Key 错误或缺失 | | `429` | 请求频率超限（被限流） | | `500` | 服务端异常 | > **一句话**：**Network 是验证前端与 AI 服务是否"正常对话"的核心面板。** ### 3. Terminal / 命令行（终端） ⭐⭐⭐⭐⭐ **形态**：黑底白字的命令行窗口，运行后端程序（Python、Node.js 等）。 **可查看内容**： - **后端日志**：`print()` 或 `console.log()` 输出。 - **完整报错堆栈**：崩溃时的错误信息及出错行号。 - **运行信号**：`Server running on port 3000` 等启动成功提示。 > **一句话**：**Terminal 是判断后端"存活状态"的依据。** --- ## 四、从最外层到最内层的 4 个信息窗口 > 按"信息流动路径"由外向内排列。 ### 4. UI Feedback（界面反馈） ⭐⭐⭐⭐ **形态**：用户直接可见的界面变化。虽面向用户，但需开发者主动设计与处理： | 反馈类型 | 形态 | 缺失代价 | | --- | --- | --- | | **Loading 状态** | 按钮变灰、转圈动画、"AI 思考中..." | 用户反复点击、以为没响应 | | **错误提示** | Toast 消息条或弹窗，如"网络错误，请重试" | 用户不知道发生了什么 | | **空状态** | 列表无数据时显示引导语 | 用户以为系统坏了 | | **成功提示** | 操作生效后的短暂确认 | 用户不确定是否成功 | > **一句话**：**良好的 UI 反馈，是人和程序之间最基本的"礼貌"。** ### 5. Server Logs（服务器日志） ⭐⭐⭐⭐ **形态**：部署在服务器上的程序产生的持久化日志，级别分明： | 级别 | 含义 | 何时看 | | --- | --- | --- | | **DEBUG** | 最详尽的调试信息 | 排查疑难问题 | | **INFO** | 常规运行信息 | 日常巡检 | | **WARN** | 警告（如配额接近上限） | 主动预警 | | **ERROR** | 捕获到的异常 | 故障分析 | > **一句话**：**Server Logs 是线上应用的"健康档案"。** 本地开发阶段用 Terminal 即可，部署上线后此工具变为必备。 ### 6. SDK / Library Debug Logs（开发工具包调试日志） ⭐⭐⭐ **形态**：SDK 自带的底层通信日志，需手动开启（如设置环境变量 `OPENAI_LOG=debug`）。 **可查看内容**： - **HTTP 请求头**：验证 `Authorization` 是否携带 API Key。 - **请求体与响应体的原始 JSON**。 - **重试信息**：网络异常时的自动重试记录。 ```bash # 开启 OpenAI SDK 调试日志 export OPENAI_LOG=debug python ai_chat.py ``` > **一句话**：**AI 调不通时，开启此日志可定位最底层通信问题。** 常规开发不需开启，仅在排查疑难问题时使用。 ### 7. AI Service Dashboard（AI 服务商控制台） ⭐⭐⭐⭐ **形态**：注册 API Key 的服务商管理后台（如 `platform.openai.com`）。 **可查看内容**： - **用量与花费**：当日累计消耗与剩余额度。 - **速率限制**：当前请求频率与上限。 - **服务状态**：服务商是否全局宕机。 > **一句话**：**这是 API Key 的"银行账户与体检中心"。** --- ## 五、信息流动全景图 ``` ┌─────────────────────────────────────────────────┐ │ 用户界面（UI） │ │ ↕ 看到/操作 │ ├─────────────────────────────────────────────────┤ │ 浏览器开发者工具 │ │ Console Network │ ├─────────────────────────────────────────────────┤ │ 后端服务（运行中） │ │ Terminal → Server Logs │ │ ↕ SDK Debug Logs │ ├─────────────────────────────────────────────────┤ │ AI 服务商 │ │ API 请求 → AI Service Dashboard │ └─────────────────────────────────────────────────┘ ``` **从外到内，任何一环出问题都会暴露在对应窗口。** --- ## 六、本篇动手任务（20 分钟） ### 任务 A：截屏你的 7 个调试面板 分别打开并截屏： 1. 你开发过的任意网页的 Console。 2. 同一网页的 Network（截一个 API 请求详情）。 3. 你的 Terminal（运行 `python -c "print('hello')"`）。 4. 任意一个 AI 服务商的 Dashboard。 5~7. UI 反馈 / Server Logs / SDK Debug Logs 至少各见一次真实例子。 把这 7 张图保存到一个文件夹，**这就是你的"调试面板速查卡"**。 ### 任务 B：故意制造一个 401 错误 把 `OPENAI_API_KEY` 改成 `sk-bad-key`，跑你的聊天工具，**观察**： - Terminal 的报错信息。 - Network（如果走前端）的 401 状态码。 - Console 的报错。 **你在 3 个窗口同时看到同一个错误的"多维呈现"——这是排查 AI 问题的标准体感。** --- ## 七、进入下一篇 7 个窗口已就位。进入 [Part 7 · 标准化排查流程 + 实战](./p7-排查流程与实战.md)，我们把它们串成一条"程序员透视眼"流水线，**用一个真实案例完整演示**。