CI/CD 技能
解决 CI/CD 管道问题的技能集。
触发条件
- 「CI 失败了」「GitHub Actions 失败了」
- 「构建错误」「测试未通过」
- 「修一下管道」
功能详情
| 功能 | 详情 | 触发词 |
|---|---|---|
| 失败分析 | 参见 references/analyzing-failures.md | 「看日志」「查原因」 |
| 测试修复 | 参见 references/fixing-tests.md | 「修测试」「给个修复方案」 |
执行步骤
- 测试 vs 实现判定（步骤 0）
- 对用户意图进行分类（分析或修复）
- 判定复杂度（见下文）
- 根据上述「功能详情」读取相应的参考文件，或启动 ci-cd-fixer 子代理
- 确认结果，必要时重新执行
步骤 0：测试 vs 实现判定（质量判定关卡）
CI 失败时，首先进行原因区分：
CI 失败报告
↓
┌─────────────────────────────────────────┐
│ 测试 vs 实现判定 │
├─────────────────────────────────────────┤
│ 分析错误原因： │
│ ├── 实现错误 → 修复实现 │
│ ├── 测试过时 → 向用户确认 │
│ └── 环境问题 → 修复环境 │
└─────────────────────────────────────────┘
禁止事项（防篡改）
⚠️ CI 失败时的禁止事项
以下「解决方案」是禁止的：
| 禁止 | 示例 | 正确的做法 |
|------|------|-------------|
| 跳过测试 | `it.skip(...)` | 修复实现 |
| 删除断言 | 删掉 `expect()` | 检查预期值 |
| 绕过 CI 检查 | `continue-on-error` | 修复根本原因 |
| 放宽 lint 规则 | `eslint-disable` | 修复代码 |
判断流程
🔴 CI 失败了
**需要判定**：
1. **实现错误** → 修复实现 ✅
2. **测试预期值过时** → 向用户确认
3. **环境问题** → 修复环境配置
⚠️ 禁止篡改测试（跳过测试、删除断言）
属于哪种情况？
需要批准的情况
如果不可避免地要修改测试/配置：
## 🚨 测试/配置变更审批请求
### 原因
[为什么需要这个变更]
### 变更内容
[差异]
### 替代方案评估
- [ ] 是否已确认可以通过修复实现解决
等待用户明确批准
Git log 扩展标志的运用（CC 2.1.49+）
在 CI 失败时，利用结构化日志定位原因提交。
定位原因提交
# 以结构化格式分析提交
$ git log --format="%h|%s|%an|%ad" --date=short -10
# 按拓扑顺序进行时序分析
$ git log --topo-order --oneline -20
# 关联变更文件与原因
$ git log --raw --oneline -5
主要应用场景
| 用途 | 标志 | 效果 |
|---|---|---|
| 定位失败原因 | `--format="%h | %s"` |
| 按时间追踪 | --topo-order | 考虑合并顺序的追踪 |
| 了解变更影响 | --raw | 详细显示文件变更 |
| 排除合并分析 | --cherry-pick --no-merges | 只提取实际提交 |
输出示例
🔍 CI 失败原因分析
最近的提交（结构化）：
| Hash | Subject | Author | Date |
|------|---------|--------|------|
| a1b2c3d | feat: update API | Alice | 2026-02-04 |
| e4f5g6h | test: add tests | Bob | 2026-02-03 |
变更文件（--raw）：
├── src/api/endpoint.ts (Modified) ← 类型错误出现
├── tests/api.test.ts (Modified)
└── package.json (Modified)
→ a1b2c3d 这个提交极有可能是原因
类型错误：src/api/endpoint.ts:42
子代理协作
满足以下条件时，使用 Task 工具启动 ci-cd-fixer：
- 修复 → 再执行 → 失败的循环发生了 2次或以上
- 或错误涉及多个文件的复杂情况
启动模式：
Task tool:
subagent_type="ci-cd-fixer"
prompt="请诊断并修复 CI 失败。错误日志：{error_log}"
ci-cd-fixer 以安全第一为原则运行（默认 dry-run 模式）。
详情参见 agents/ci-cd-fixer.md。
面向 VibeCoder
🔧 CI 坏了时的说法
1. **「CI 挂了」「变红了」**
- 自动测试失败的状态
2. **「为什么失败了？」**
- 希望调查原因
3. **「帮我修好」**
- 自动尝试修复
💡 重要：禁止「敷衍了事」的修复
- ❌ 删除测试、跳过测试
- ⭕ 正确修复代码
如果你觉得「测试可能有问题」，
先确认再决定怎么处理吧