第 20 章 遥测驱动与逆向投喂：帮 AI 长出"千里眼"

**公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

课程讲解

20.1 用运行证据检验代码、配置与环境假设

错误可能来自逻辑、配置、数据、并发或外部服务。没有项目统计，不能断言大多数错误属于某一类。模型可分析已提供的代码和日志，但没有获授权运行证据时，无法知道现场状态。遥测用于检验原因，不是替某种原因预先作证。

Bug 的”藏身之处”：AI 看不见的五个维度。

1. 时间维度（The Temporal Dimension）。代码的执行顺序在多线程、异步编程中充满不确定性。两个事件的前后顺序差几毫秒，可能就会导致截然不同的结果——这就是所谓的”竞态条件”（Race Condition）。

• AI 的盲点：AI 阅读代码时默认是线性的、静态的。它无法”看到”真实世界中一个网络回调函数可能在一个用户点击事件处理到一半时突然插入执行，从而污染共享状态。
• 典型 Bug：一个前端应用在页面加载时同时发出两个 API 请求：获取用户信息（A）和获取用户购物车（B），购物车依赖于用户信息。由于网络波动，请求 B 比 A 先返回，代码因拿不到用户信息而崩溃。这个 Bug 在绝大多数情况下不会复现。

2. 状态维度（The State Dimension）。一个长时间运行的应用，其内部状态会随着时间不断累积演变。一个 Bug 可能只在系统运行了 72 小时、处理了 100 万个请求、内存占用达到某个临界值之后才会触发。

• AI 的盲点：AI 看到的永远是代码的”初始状态”或”理想状态”。
• 典型 Bug：一个计数器服务在高并发下由于没有使用原子操作，计数值越跑越不准。这个问题在低并发的开发环境中永远无法复现。

3. 外部依赖维度（The Dependency Dimension）。你的代码只是庞大软件生态系统中的一个节点，依赖于操作系统、第三方库、外部 API、数据库、缓存服务……任何一个环节出问题，都会波及你的代码。

• AI 的盲点：AI 不知道你调用的支付 API 今天下午 3 点到 4 点因服务商机房断电一直返回 500。
• 典型 Bug：一个 Python 应用在开发者的 macOS 上运行良好，部署到 Linux 服务器后，处理文件路径的函数因没有考虑 \ 和 / 的差异而崩溃。

4. 配置维度（The Configuration Dimension）。同样一套代码，在不同的配置（环境变量、功能开关、A/B 测试分组）下行为可能天差地别。

• AI 的盲点：AI 看不到生产环境里 FEATURE_FLAG_NEW_CHECKOUT 被设置为 true，从而激活了一套全新的、未经充分测试的结算流程。
• 典型 Bug：代码在测试环境完美运行，一上线立刻引发大量订单失败。排查数小时才发现是生产环境的数据库连接池大小配置过小，在高流量下被迅速耗尽。

5. 用户输入维度（The User Input Dimension）。你永远无法预料用户会如何”玩坏”你的软件——输入 Emoji、超长字符串、甚至恶意脚本。

• AI 的盲点：AI 生成代码时总是倾向于处理”阳光路径”，假设用户输入了格式良好的 Email 和密码，不会主动防御用户输入 '; DROP TABLE users; --。
• 典型 Bug：一个图片上传功能，在处理文件名包含特殊 Unicode 字符（如 U+202E，从右至左覆盖符）的图片时，导致整个文件系统 API 调用失败。

结论：面对这些”环境依赖型” Bug，仅仅把错误日志和代码片段扔给 AI 是远远不够的——这就像只给医生看一张 X 光片，却不告诉他病人的年龄、病史和生活习惯。我们的任务，就是通过”遥测”，为 AI 提供一份包含时间、状态、依赖、配置和输入的、立体的、全息的”病历报告”。

20.2 结构化日志的植入策略（分级记录、上下文注入、事件驱动）

忘掉 console.log("here") 吧。这种”非结构化”的日志对于人类勉强可读，对于 AI 来说则是几乎无法解析的”垃圾文本”。它们就像一堆杂乱无章的手写便条，而不是一份条理清晰的报告。

结构化日志（Structured Logging）是指将日志信息以一种一致的、机器可读的格式（通常是 JSON）进行记录。每一条日志不再是简单的字符串，而是一个包含丰富”元数据”的对象：

示例类型：参考。 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。

❌ 非结构化日志：
[2023-11-01 10:30:15] ERROR: User login failed for user test@example.com from IP 192.168.1.10.

✅ 结构化日志（JSON 格式）：
{
  "timestamp": "2023-11-01T10:30:15.123Z",
  "level": "ERROR",
  "message": "User login failed",
  "context": {
    "event_type": "USER_LOGIN_ATTEMPT",
    "username": "test@example.com",
    "source_ip": "192.168.1.10",
    "reason": "INVALID_PASSWORD"
  }
}

结构化日志对 AI 来说，是一份可以直接”理解”和”分析”的数据。植入策略要像设计 API 一样设计你的日志：

策略一：分级记录，明确意图。

不要把所有日志都记为 INFO。使用标准日志级别表达每条日志的重要程度：

• DEBUG：仅在开发环境中用于诊断的、极其详细的信息；
• INFO：记录应用生命周期中的关键”里程碑”事件；
• WARN：发生了预期内的、可恢复的”异常”，但应用仍能继续运行；
• ERROR：发生了导致当前操作失败的严重错误，核心功能可能受损；
• FATAL/CRITICAL：发生了导致整个应用实例崩溃的灾难性错误。

AI 如何使用日志级别：当你给 AI 一份日志时，它会首先关注 ERROR 和 FATAL 级别的事件，快速定位问题焦点；然后通过 INFO/WARN 理解操作的上下文脉络。

策略二：上下文注入，丰富细节。

每一条日志都应包含尽可能多的、与当前操作相关的”上下文”：

• Who?（用户）：user_id, session_id, tenant_id；
• Where?（位置）：service_name, module_name, function_name；
• What?（关联实体）：order_id, product_id, request_id；
• How?（参数）：关键的函数参数、请求体中的重要字段（注意脱敏）。

AI 如何使用上下文：上下文信息是 AI 进行”关联分析”的关键。当 AI 看到 user_id: 9527 的登录失败日志与 user_id: 9527 的异常订单日志出现在同一时间段，它就可以建立因果关联。

策略三：事件驱动，命名标准化。

与其记录模糊的”做了某事”，不如将日志视为一个个离散的、有明确名称的”事件”：

示例类型：参考。 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。

❌ 坏的 message:  "Saving user"
✅ 好的 event_type: "USER_PROFILE_UPDATE_STARTED"

❌ 坏的 message:  "User saved"
✅ 好的 event_type: "USER_PROFILE_UPDATE_SUCCEEDED"

❌ 坏的 message:  "Error saving user"
✅ 好的 event_type: "USER_PROFILE_UPDATE_FAILED"

使用 NOUN_VERB_STATE（名词_动词_状态）的格式是一个很好的实践。标准化的事件名让 AI 可以更容易地理解一个业务流程的完整生命周期。

策略四：日志即遥测，而非调试。

植入日志的目的，不是为了你将来”可能”要去排查，而是为了让系统在运行时”讲述”它自己的故事。这意味着你应该在代码的”关键路径”和”决策点”上主动地、慷慨地记录：每个 API 请求的入口和出口；每个重要业务流程的开始、成功、失败；每次与外部系统交互前后。_started / _succeeded / _failed 的事件三元组，是结构化日志最基本也最强大的范式。

20.3 全链路追踪：用 trace_id 捕获竞态条件

结构化日志解决了”单点”信息的丰富度问题。但要捕获那些与”时间”和”顺序”相关的 Bug（如竞态条件），我们需要全链路追踪（Distributed Tracing）。

其核心思想非常简单：为一个完整的用户操作（比如一次 API 请求）分配一个唯一的标识符 trace_id，并让这个标识符跨越所有服务和调用。

【一个简化版的例子】：

1. 用户点击”购买”按钮，前端生成一个 trace_id: "abc-123"；
2. 前端发出 API 请求 POST /orders，在 HTTP 头中携带 X-Trace-Id: abc-123，并记录日志 ORDER_SUBMIT_STARTED；
3. 后端订单服务收到请求，从 HTTP 头解析出 trace_id，记录日志 ORDER_RECEIVED；
4. 订单服务调用支付服务，在 RPC 请求中继续传递 trace_id，记录 PAYMENT_PROCESSED；
5. 支付服务处理请求并返回，全程记录 trace_id: abc-123。

全链路追踪的威力：当你想调查 trace_id: "abc-123" 这次操作到底发生了什么时，你将得到一个按时间顺序精确排序的、跨越前端、订单服务、支付服务的完整操作流。

AI 如何利用这个事件流来捕获竞态条件：假设遇到了”用户的账户被重复扣款”的 Bug。没有 trace_id，你会在日志里看到两条几乎一模一样的支付记录，无法区分它们是同一次操作还是两次独立操作。而有了 trace_id：

示例类型：参考。 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。

10:30:15.100Z | INFO | ORDER_SUBMIT_STARTED | trace_id: a-1, ...
10:30:15.150Z | INFO | ORDER_SUBMIT_STARTED | trace_id: b-2, ...
10:30:15.200Z | INFO | ORDER_RECEIVED     | trace_id: a-1, ...
10:30:15.250Z | INFO | ORDER_RECEIVED     | trace_id: b-2, ...
...
10:30:15.500Z | INFO | PAYMENT_PROCESSED   | trace_id: a-1, ...
10:30:15.550Z | INFO | PAYMENT_PROCESSED   | trace_id: b-2, ...

当你把这段日志交给 AI 时，它的推理过程会是：识别异常模式（50 毫秒内启动了两次独立的订单提交操作）→ 关联上下文（两次操作最终都导致支付成功）→ 提出假设（前端没有对提交按钮做”防抖”或一次性锁定处理，用户快速双击被系统视为两次独立购买）→ 建议解决方案（在提交按钮的点击事件处理函数中增加状态锁，第一次点击后立即禁用按钮，直到 API 请求返回）。

trace_id 就像一根魔法丝线，将散落在各个系统、各个时间点的”珍珠”（日志事件），串成了一串清晰可辨的”项链”（操作流）。那些隐藏在时间缝隙中的”魔鬼”（竞态条件），在全链路追踪面前将无所遁形。

【注入指南】三大类场景的日志埋点方案：

• 场景一：关键业务流程（Business Transactions）——完整记录核心业务（注册、下单、内容发布）的端到端生命周期。入口点记录 _STARTED 事件并生成 trace_id；服务层在关键业务决策点和外部依赖交互前后记录事件；出口点记录 _SUCCEEDED/_FAILED 事件（按业务异常 WARN、系统错误 ERROR 分级）。
• 场景二：异步与后台任务（Async & Background Jobs）——追踪没有直接用户交互的后台任务。任务入队时生成 job_id 和 trace_id 作为元数据传递；Worker 取任务时恢复 ID 注入日志上下文；长任务周期性记录”心跳”进度；支持重试的任务记录 _RETRYING 事件。
• 场景三：前端用户交互（Frontend User Interactions）——重建用户在浏览器中的完整操作路径。会话开始生成 session_id；记录核心交互事件（PAGE_VIEW, BUTTON_CLICK, FORM_SUBMIT）；用 axios 拦截器或 fetch 封装自动为 API 请求生成 trace_id；全局捕获未处理异常（window.onerror）并附带会话”面包屑”。

20.4 逆向投喂：直接把崩溃日志扔给 AI，而非口头描述

想象你去看医生。描述 A（口头描述）：“医生，我最近感觉不太舒服，有点头晕，肚子也不太好。“描述 B（数据驱动）：“医生，这是我过去一周的血压、心率和体温的测量记录，另外这是我的血常规化验单。我不适的症状通常发生在午饭后两小时左右。“答案不言而喻——描述 B 提供了一份客观、量化、包含时间和上下文的数据，医生可以立刻从中寻找”异常模式”。

我们向 AI 报告 Bug 时也是同理。

低效的”口头描述”模式：

你：“我的用户报告说，当他们上传一个大文件的时候，有时候进度条会卡在 99%，然后就失败了，但有时候又可以。代码看起来没什么问题，你能帮我分析一下可能是什么原因吗？”

这段话犯了几个致命的错误：充满了”不确定”词汇（“有时候""可能会""好像是”——对概率模型来说这是巨大噪音）；包含了”主观判断”（“代码看起来没什么问题”——这个未经证实的假设可能直接启动 AI 的确认偏误）；缺乏”可复现”的上下文（多大的文件？什么格式？网络环境如何？——关键环境变量全部缺失）。面对这样的描述，AI 只能像一个搜索引擎，罗列一堆”文件上传失败的常见原因”，距离你那个具体的 Bug 十万八千里。

高效的”逆向投喂”模式：

由于系统已预先植入良好的结构化日志，当问题发生时，我们不是去”猜测”，而是去”提取”——从日志系统中提取与那次失败操作相关的、带同一个 trace_id 的完整日志流，然后把这份原始、未经篡改的数据直接”扔”给 AI：

你（对 AI 说）： Context: We are investigating a file upload failure. I have extracted the complete, structured log stream for a failed operation, identified by trace_id: “trace-xyz-789”.

Your Role: Act as a Senior Site Reliability Engineer (SRE). Your task is to analyze these logs, identify the root cause of the failure, and propose a specific solution.

Log Data: [粘贴完整的结构化日志 JSON 数组]

Analysis Request: Based solely on the provided log data, please answer:

1. What is the precise point of failure?
2. What is the most likely root cause?
3. Propose a code-level fix for the identified service.

为什么这种方式如此高效：事实驱动，而非观点驱动（你给的是冰冷的客观”证据”，迫使 AI 的分析完全基于数据而非”通用知识”）；上下文自包含（日志里已包含诊断所需的一切关键信息：操作开始、文件大小、分块逻辑、外部依赖交互、重试逻辑、最终失败原因）；问题被精确定位（AI 不需要猜测问题出在前端、后端还是网络）。

基于这份数据，AI 的诊断将是外科手术般的精准——直接指出失败的精确位置（第 50 个分块上传失败）、最可能的根因（S3 端限流或客户端超时配置过短）、以及具体的代码级修复方案（增加 S3 客户端超时、实现指数退避重试）。

别再跟 AI”聊”Bug 了，开始给它”喂”数据。

20.5 识别日志中的假象：掩盖真问题的不必要 fallback

直接投喂日志虽然强大，但并非万无一失。一个设计不良的系统，其日志本身也可能在”说谎”。最常见的”谎言”来自代码中过于宽泛、不加区分的”错误处理”和”降级逻辑”（Fallback）。

一个健壮的系统应该在发生错误时尽可能保持运行，通常通过 try…catch 块和降级机制实现（如推荐系统连不上个性化引擎时”降级”为显示通用热门列表）。这种机制对”用户体验”是好的，对”问题诊断”却可能是灾难——它会掩盖真正的错误根源，用一个看似”正常”的 INFO 日志（“Fallback to generic recommendations”）覆盖掉一个本该是 ERROR 的严重问题（“Recommendation engine connection refused”）。

日志假象的典型模式：

• 模式一：万能的 catch 块。把”数据库超时""第三方 API 认证失败""空指针异常”等所有性质完全不同的错误，都”压扁”成一条模糊的 OPERATION_FAILED 日志。当 AI 看到这条日志时，它丢失了所有判断错误根源的关键信息。
• 模式二：静默的失败（Silent Failures）。缓存更新失败后只记一条 WARN 就继续，不重新抛出错误。主流程日志看似一切正常、用户操作”成功”，但系统的一个重要部分已处于不一致状态。AI 分析主流程日志时会被完全误导。

如何训练 AI 成为”日志侦探”：

• 技巧一：要求 AI 寻找”模式断裂”。在投喂日志后追加指令：“In addition to finding errors, analyze the sequence of events. Are there any expected INFO logs that are missing? Is there a point where the log pattern naturally breaks from the typical success-case pattern?”这会让 AI 去找”本该发生但没有发生”的事——比如 CACHE_UPDATE_STARTED 后没有 CACHE_UPDATE_SUCCEEDED，从而推断缓存更新被”静默地”失败了。
• 技巧二：交叉验证代码与日志。当你怀疑日志存在”假象”时，把相关代码片段和日志一起投喂，让 AI 阅读 try 块里的代码，列出所有可能被 catch 捕获的具体错误，与当前问题对照。这等于给了侦探一个嫌疑人名单，让他可以和现场证据比对。
• 技巧三：主动询问”降级路径”。“Does this log stream suggest that any system fallback or graceful degradation logic was triggered? If so, what was the original failure that triggered this fallback?”这个提问直接引导 AI 寻找 WARN 级别或包含 “fallback""generic""default” 关键词的日志，并将它们与之前的 ERROR 事件关联起来。

一个合格的 AI 协作者不能盲目信任日志。你必须始终保持健康的”怀疑论”，引导 AI 穿透日志表象，挖掘出那个被拙劣错误处理逻辑掩盖的、最初的”第一案发现场”。

20.6 形成闭环：跑真机 → 取日志 → 喂 AI → 根因推理 → 验证

我们已经掌握了”取证”（遥测）和”分析”（投喂）的关键技能。现在，将它们串联成一个完整的、可重复的、高效的”人机协作排障闭环”：

示例类型：参考。 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。

Step 1: 复现与触发     Step 2: 提取与隔离     Step 3: 投喂与引导
（跑真机，稳定复现）  （用 trace_id 取日志）  （结构化投喂 + 精准提问）
     │                        │                        │
     ▼                        ▼                        ▼
Step 5: 验证与修复     ◄──── Step 4: 推理与假设
（先验证后修复，        （人类评估 AI 的根因假
 回归测试，更新日志）      设，批判性思维，最终决策）

• Step 1 复现与触发（你的角色：测试工程师）——在尽可能接近生产环境的”真机”或 Staging 环境上稳定复现问题。如果问题是偶发的，尝试找到触发它的特定条件；触发前确保遥测就绪、必要时把日志级别临时调高到 DEBUG。
• Step 2 提取与隔离（你的角色：数据分析师）——从海量日志中精确提取与那次失败操作相关的完整、干净的日志流。根据时间戳、user_id 找到 trace_id，导出从 _STARTED 到 _FAILED 的所有相关日志，保存为独立文件，不要手动修改或删减，保持原始性。
• Step 3 投喂与引导（你的角色：AI 交互专家）——用”逆向投喂”模板，明确赋予 AI 专家角色（SRE、DBA 等），直接粘贴日志数据，提出具体的封闭式问题。若怀疑日志有假象，使用”侦探”技巧追问。
• Step 4 推理与假设（你的角色：资深工程师/架构师）——接收并评估 AI 给出的”根因推理”和”修复假设”。AI 不是神，它的假设也可能错，批判性思维至关重要。最终的”采纳哪个假设”的决策必须由你来做。
• Step 5 验证与修复（你的角色：开发者）——先验证，后修复！根据假设设计最小化实验（如假设”数据库连接池耗尽”，就写脚本在测试环境疯狂创建连接看能否复现）。假设被验证后采纳修复方案，做回归测试确保 Bug 真正修复且未引入新问题。修复的同时改进日志埋点——这是持续提升系统可观测性的宝贵实践。

这个闭环将人与 AI 的优势完美结合：AI 的长处是处理海量结构化数据、快速模式匹配、渊博的跨领域知识；人类的长处是对特定业务领域的深入理解、批判性思维与直觉、在不确定性中做出最终决策的勇气与责任感。

【排障案例】一次完整的”黑盒”崩溃修复全流程复现（教学重组案例）

让我们把所有理论应用到一个完整的案例中（以下为教学重组案例：情节由多次真实排障的典型片段重组而成，数字为演示量级，非某次具体事件的记录）。

背景：你是一个电商平台的后端工程师。运维团队报告：生产环境的 Order Service（订单服务）每天午夜 12 点左右出现几分钟的 CPU 100% 飙升，伴随大量 API 超时错误，然后服务自动重启恢复。没人知道原因。

Step 1：复现与触发。问题是定时发生的，“复现”相对容易。你的任务是做好”取证”准备：确认日志级别已到 INFO；将与”定时任务/批处理”相关模块的日志级别临时提升到 DEBUG；设置告警在 CPU 使用率超过 95% 时通知你。

Step 2：提取与隔离。午夜 12 点 05 分告警响起，服务在几分钟”假死”后被容器编排系统自动重启。你锁定时间范围 23:55–00:05。先过滤 level: ERROR，发现大量”Request timeout after 30s”，但随便挑一个 trace_id 查看，只显示请求进来后就没下文了——这条路走不通。你改变策略，不再关注”失败的请求”，而是寻找”系统在那个时间段到底在主动做什么”——搜索 event 名包含 JOB/TASK/SCHEDULE 的日志。你找到一条 NIGHTLY_REPORT_GENERATION_JOB_STARTED，后面跟着大量 DEBUG 日志显示这个 Job 在疯狂循环处理数据。你隔离出该 Job 的完整日志流。

Step 3：投喂与引导。你把 JOB_STARTED 到崩溃前的所有相关日志投喂给 AI，角色设为”Senior Go Performance Engineer”，提问：1. 基于时间戳，找出循环中最耗时的操作；2. CPU 高的可能原因；3. 提出 Go 代码级优化。

Step 4：推理与假设。AI 给出分析：CALCULATING_USER_REPORT 是明显瓶颈——对 vip-user-1 耗时 82 秒（数据库查询 FETCHING_USER_ORDERS 只花了 6 秒）；系统为单个用户获取 15,000 条订单，然后花很长时间在 Go 应用内做内存聚合计算——把大量数据拉到应用层内存做 CPU 密集计算，是典型的性能反模式。建议把计算下推到数据库层，用一条带聚合函数（SUM/AVG/COUNT）和 GROUP BY 的 SQL 查询。你审查后认为假设非常合理，决定采纳。

Step 5：验证与修复。验证：无需等到午夜——你在本地指向一个包含大量订单数据的测试库，手动触发 Job，同时打开 profiler。果然，CPU 时间 100% 消耗在一个遍历海量订单对象的大 for 循环里。假设被验证了！修复：你对 AI 说”你的假设是对的，这是那个有问题的 Go 函数，请帮我重构成你建议的 SQL 聚合方式”。AI 生成新的高效代码。回归测试：原来 82 秒的处理缩短到不到 500 毫秒，CPU 使用率几乎没有波动。更新日志：为新聚合 SQL 增加一条 DEBUG 日志记录执行耗时，未来变慢可被立刻发现。

第二天午夜，你安心地睡了一个好觉。早上醒来，监控图表一片平静。一个困扰团队数周的”幽灵” Bug，通过一个清晰的、人机协作的、由真实数据驱动的流程，被彻底、优雅地解决了。

第六部分完成。你已经掌握了流程约束的两大利器：剥夺执行权（“三步走”标准流：调研 → 谋局 → 落地，把 AI 的”快”引导到”高质量的深度思考”上）与遥测驱动（结构化日志、全链路追踪、逆向投喂、识别日志假象、形成排障闭环）。

现在，让我们进入第八部分：质量与风险治理——建立永久的自动防线。在那里，你将学会把质量从”我觉得没问题”变成”系统证明没问题”。

暂停整理：先完成本章最小闭环

先只写出“运行信号”与“因果诊断”之间的一条关系，并把它填进遥测诊断闭环。确认这一步有输入、判断和证据后，再加入“证据回写”；三项尚未连通时，不进入独立练习。

独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 chapter-20.md，写上版本、决定、证据和缺项。

为‘界面提交成功但没有记录’列三种原因，设计含trace_id、阶段和结果的脱敏日志；写最小复现与验证顺序。

本章必交产物：遥测诊断闭环

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

• O1: 遥测诊断闭环画出“运行信号”“因果诊断”“证据回写”的前向路径和返回路径
• O2: 遥测诊断闭环为每一环写明输入、判断、输出和负责人
• O3: 产物记录一个信号、竞争假设、验证动作和回写位置

查看参考反馈（先独立作答）

参考反馈

分别检查界面状态误报、API拒绝、存储失败。关联同一trace_id，记录状态码和阶段而非密钥、邮箱或原始工单。先复现再缩小范围，错误可能来自代码、配置或平台，不先入为主。把最少获授权日志提供给AI，保留失败可见性。

自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。