用可检验的假设排查问题

提出修复前先描述故障

有效的排查请求说明预期行为、观察到的行为和影响范围。提供版本、相关输入和错误。向 AI 工具提供日志前，移除凭据和私密记录。

“导出坏了”几乎没有提供方向。更好的描述是：“导出在本地成功。在预发布环境中，最近一次部署后，相同的经理请求返回 403。其他路由仍正常工作。”

这个描述不能确定原因，但指出了可以指导调查的差异。

保留多个可能解释

要求智能体提出少量合理原因，并列出每个原因的证据。不要让它立即认定第一个看似可信的解释。

对于这个虚构的导出故障，可能原因包括服务身份缺少权限、角色映射改变，或请求被发送到错误环境。每种解释都会对应不同证据。

这个表只是起点。403 响应可能来自不同层。在认定应用授权失败前，先找出哪个组件产生了响应。

选择安全的观察方式

先选择成本较低、能够区分解释的观察。比较已部署版本和不含秘密信息的配置。检查相关错误和请求标识符。尽可能在获准的测试环境中重现问题。

不要仅为了观察错误是否消失，就授予宽泛权限。这会改变安全边界，也可能掩盖实际缺少的权限。如果删去敏感内容的错误信息和请求路径已经足够，就不要把完整生产日志粘贴给模型。

说明什么证据会削弱每个假设。这有助于智能体修正解释，而不是维护最初答案。

每次只修正一个原因

证据指向一个可能原因后，做针对性修正。不要同时修改权限、升级库并重写处理函数。否则，即使症状消失，也不知道哪项修改起了作用。

验证原始失败条件，也检查相邻边界。如果修复了经理的访问权限，还要确认未经授权的用户仍会被拒绝。

对于反复出现的缺陷，在能够检出它的层添加回归检查。单元测试不能发现所有部署配置错误。有些故障需要集成检查，或受控的部署后验证。

没有新证据时停止反复尝试

智能体可以生成许多修复变体。更多尝试不一定改善诊断。如果同样的故障再次出现，询问下一次尝试会提供什么新观察。

为不确定的调查设置时间或尝试次数上限。达到上限时，报告当前证据、已排除的假设和未解决的问题。这样其他人可以继续，而不必重复相同实验。

恢复后，记录原因，以及使问题进入受影响环境的条件。修复消除当前缺陷；有用的后续工作则降低同类故障再次出现的可能性。