AI Bug 修复工作流：复现、隔离、修补与验证

记录确切版本、命令或请求、脱敏输入、实际输出、预期输出、时间和相关版本信息。密钥和无关客户数据必须在进入代理会话前删除。

把故障缩小到无需生产权限也能重复出现。如果它仍然间歇发生，应记录频率和相关条件，而不是虚构确定原因。

让代理定位入口、状态变化、错误处理和相关近期变更，并引用代码位置、分开观察与假设。对于有已知正常版本的回归，可在条件允许时使用历史和可自动判断的 bisect 检查。

原因说明要解释输入为何到达失败、当前行为为何违背契约，以及什么证据能够推翻该假设。修改校验、重试或授权逻辑前，维护者必须确认业务预期。

存在多个合理原因时，应增加观测或更窄测试，而不是让代理选择最容易修改的代码。

把改动限制在因果路径和回归测试；除非契约变更经过审查，否则保持公共接口不变。清理、依赖升级和大范围重构应拆成独立变更，便于审查与回滚。

重跑原始复现，证明回归测试在没有修复时会失败，并执行相关包或服务检查。检查日志和副作用是否产生新错误；跨 API 边界的故障还需验证成功与错误响应。

汇总原因、修补、验证命令、影响版本、回滚计划和缺口；发布后监控相同故障特征。如果新证据否定了原解释，应重新诊断，而不是继续堆叠未经审查的猜测修补。