CI Doctor 运行失败诊断

解决什么问题

CI 失败排查是日常运维里最磨人的环节之一。一次 Workflow 挂掉之后，开发者通常要手动打开 Actions 页面，在几十个步骤里翻日志，凭经验猜测原因，最后在 Issue 里写一句模糊的“请检查环境配置”。当失败反复出现时，这种做法既浪费时间，又容易漏掉真正的根因——尤其是跨分支、跨 PR 的偶发失败，人眼很难从历史运行记录里识别出规律。

技能如何工作

CI Doctor 面向的是作为“CI 故障调查员”的 Agent，核心是一条自动化排查流水线：

• 监控运行记录：持续关注 GitHub Actions 的运行状态，不需要人工盯着面板刷新。
• 抓取失败日志：对失败的运行自动拉取日志内容，而不是只报一句“Build failed”。
• 追踪重复模式：从历史运行中识别反复出现的失败模式，区分偶发故障和系统性问题。
• 创建调查 Issue：把结论和具体下一步操作写进 Issue，并附上可点击的运行 ID 链接，方便直接跳转复查。

整套流程依托 gh CLI 与 GitHub Agentic Workflows 扩展，配合受支持的 AI Provider Token，在仓库内即可闭环运转。

适用边界与注意点

这个技能的定位是故障调查，不是 GitHub Agentic Workflows 的产品展示页。实际使用时需要注意：

• 目标仓库需要已启用 Actions，且环境中预装 gh 与相关扩展，前置条件缺失会直接卡住流程。
• AI 分析依赖 Provider Token 的可用性，Token 额度或权限受限时，日志分析环节可能不可用。
• 调查 Issue 的质量取决于日志本身是否完整；CI 没有输出足够信息时，Agent 也无法凭空推断。
• 重复模式的识别依赖足够的历史运行数据，刚启用 Actions 的仓库可能暂无足够样本。