从红色 CI 到绿色 PR — 自动、安全且有据可循

Source: Dev.to

GitHub Copilot CLI 挑战提交
这是对 GitHub Copilot CLI 挑战 的一次提交。

我构建的内容

我构建了 copilot-ci-doctor，这是一款使用 GitHub Copilot CLI 作为核心推理引擎的 CLI 工具，用于诊断并修复 GitHub Actions CI 失败。

该工具不需要手动在嘈杂的日志中翻找或猜测解决方案，而是将一次失败的 CI 运行转化为结构化、基于证据的工作流：

失败 → 证据 → 推理 → 安全修复 → CI 通过 → 拉取请求

给定一次失败的工作流，copilot-ci-doctor：

• 收集标记的 证据包（仓库元数据、失败的作业、日志、工作流 YAML）
• 使用 GitHub Copilot CLI 对失败进行推理
• 用简体中文解释 CI 为什么会失败
• 生成 最小、安全的补丁 diff 并附带置信度分数
• 迭代应用修复，直至 CI 通过
• 自动在 main 分支上打开 Pull Request

这 不是 日志摘要或自动补全。Copilot 被用作 推理引擎，必须使用证据来证明其结论。

演示

40 秒端到端演示（推荐观看）：
👉

单条命令 → 失败的 CI → Copilot 推理 → 安全修复 → CI 通过 → PR

npx copilot-ci-doctor demo

演示展示的内容：

• 创建一个故意破坏的 GitHub Actions 工作流的演示仓库
• CI 失败 ❌
• copilot-ci-doctor 进入自动循环：
  • 分析失败
  • 解释根本原因
  • 提出最小补丁
  • 应用并推送修复
  • 等待 CI 重新运行
• 过程重复（如有需要会进行多次迭代）
• CI 变为绿色 ✅
• 自动打开包含修复的 Pull Request

演示处理了 真实的 GitHub 延迟，展示了完整的生命周期，包括：

• 多次 CI 失败
• diff 预览
• 迭代记分板
• 最终 PR 链接

源码与演示资源：
npm 包：

我对 GitHub Copilot CLI 的体验

这个项目从根本上改变了我对 GitHub Copilot 的看法。

我不再把 Copilot 当作 写代码 的工具，而是使用 GitHub Copilot CLI 来 推理系统。

Copilot CLI 的使用方式：

• 分析 CI 证据并形成 排序假设
• 用简体中文解释失败（包括 为什么本地通过而 CI 失败）
• 生成 最小的统一 diff，而不是完整重写
• 为每个修复附加置信度分数和风险等级

为确保可靠性：

• 每个 Copilot 响应都遵循 严格的 JSON 合约
• 每个结论都引用证据 ID（E1、E2、…）
• 在应用前对补丁 diff 进行验证和标准化
• 单调用模式 将分析、解释和补丁生成合并，令 token 使用量降低约 60%

最终得到的工作流让 Copilot 的表现更像是一位 谨慎、可解释的 CI 工程师，而不是普通助手。

这次挑战促使我超越自动补全，探索 Copilot CLI 如何安全地自动化复杂、真实的开发者工作流。