核心用法
Rails CI Fixer 是一款面向 Rails 项目的自动化 CI 修复技能，通过分层升级循环（tiered escalation loop）自主处理 PR 中的持续集成失败。其工作流程分为三个阶段：
Attempt 1-2（快速修复）：使用轻量级模型（如 Claude Haiku、GPT-4o-mini）处理常见失败。首先通过 gh run view 拉取失败日志，过滤关键错误信息；然后由快速代理尝试修复，本地验证通过后执行 bundle exec rspec 和 bundle exec rubocop -A，最后提交至功能分支并监控 CI。
Attempt 3（深度调试）：若快速修复失败，启动调试子代理，在失败点注入 pp 或 raise inspect 收集运行时状态，再升级至强力模型（Claude Sonnet/Opus、GPT-4o）进行诊断。
Attempt 4（人工介入）：三次尝试失败后，向人类报告故障详情、尝试记录和调试输出，停止自主修复。
显著优点
1. 成本优化：分层策略优先使用廉价模型，仅在必要时升级，显著降低 API 调用成本
2. 安全边界明确：强制遵循"仅推送功能分支、永不合并、人类终审"原则，避免自动化越权
3. 输入安全意识：明确将 CI 日志视为不可信输入，防范提示注入攻击
4. Ruby/Rails 生态深度集成：原生支持 Bundler、RSpec、RuboCop 工具链
潜在缺点与局限
- GitHub 平台绑定：依赖
ghCLI 和GH_TOKEN，不支持 GitLab、Bitbucket 等其他平台 - 调试侵入性：Attempt 3 需修改源代码插入调试语句，可能污染提交历史
- 复杂失败处理有限：涉及基础设施（Docker、Postgres、网络）的错误被明确过滤，需人工处理
- 无合并权限设计：虽提升安全性，但也意味着无法完全无人值守完成合并流程
适合人群
- 维护大型 Rails 代码库、CI 失败频繁的开发团队
- 希望减少 "fix typo/lint" 类机械性人工干预的技术负责人
- 已采用 GitHub Actions 且具备标准化分支保护规则的工程组织
常规风险
1. 凭证泄露：GH_TOKEN 需严格限制为 repo 作用域，避免使用 org 级令牌
2. 修复质量不确定：轻量级模型可能生成表面通过但逻辑错误的修复
3. 调试代码残留：子代理注入的 pp/raise 若未清理可能进入生产代码
4. 日志解析盲区：过滤规则可能遗漏特定格式的错误信息