调试与失败诊断

调试提示应包含实际失败证据和期望行为。先让 Copilot 解释根因及验证方法，再评估修改，避免只根据报错文本做表面替换。

修复无效 JSON

把出错的 JSON 与解析错误一起提供，要求指出无法解析的位置并给出最小修正。官方天气数据示例的错误是字符串缺少结束引号；这类问题与字段内容是否合理是两个层次。

修复后先用项目已有的解析过程验证语法，再检查字段类型和业务约束。能够解析并不意味着单位、时间、字段含义或必填项符合调用方要求；Copilot 的解释也不能代替实际解析结果。

处理外部 API 限流

官方示例使用 Python 应用调用天气 API，讨论增加重试和指数退避。使用时，应提供具体响应状态、限流说明及当前请求代码，让 Copilot 根据该 API 的规则提出处理方案。

注意官方示例代码的适用边界：其中 status_forcelist 是 (500, 502, 504)，没有包含 429。因此不能仅复制代码就宣称已经处理 HTTP 429 限流。示例的重试次数和退避系数也不是 Copilot 产品的默认值。

验收时分别检查实际限流响应能否进入处理分支、重试是否有终止条件、最终失败如何反馈，以及请求是否允许重试。本节讨论应用调用外部服务时的限流，不提供绕过 Copilot 订阅额度的方法。

用 CI 运行记录定位差异

CLI 教程通过内置 GitHub MCP 获取 workflow runs、job 日志和状态，再结合本地文件调查。可以要求查看当前分支最近一次失败，并用 @ 引用相关实现和测试文件。

推荐顺序：

1. 找到具体失败运行、job 和测试，不只引用 workflow 名称。
2. 对照最近通过的运行，检查代码、环境与事件顺序差异。
3. 让 Copilot 说明日志如何支持根因，区分已经观察到的事实与待验证假设。
4. 修改最小相关范围，并运行受影响测试。
5. 使用 /diff 检查修改；本地通过后仍需在相应 CI 环境复验。

官方使用 !pytest test_order_service.py 演示从 CLI 会话运行测试。它只适用于使用 pytest 且存在该测试文件的项目；应替换为项目已有的测试入口。

时区造成的一天偏差

官方案例中，本地与 CI 对“今天”的解释在午夜附近不一致，导致日期比较失败。调查时检查环境时区、取当前时间的位置，以及测试是否依赖真实时钟。修复方向包括统一时区或注入可控制的时钟，让测试验证同一时间基准。

不要仅把预期日期加减一天。这样会保留原来的环境依赖，使错误在另一个时间点重新出现。

异步完成造成的偶发失败

另一个案例在后台任务完成前就断言状态。比较日志中的事件顺序，可以发现断言读取到的是中间状态。

修复应等待可观察的完成条件，并在超时后明确失败。官方轮询示例中的等待间隔和超时只是示例参数，不是产品默认；任意延长固定 sleep 也不能证明竞争条件已消失。重新运行相关测试并检查失败路径，确认等待没有把真正的挂起隐藏起来。