历史文章。 描述的是 v1 架构，包括加权正则分类器和由 CI 触发的单分支模型。这篇里讲的大部分在 v2 里都被刻意移除了；参见 删掉我们的正则分类器 和 本地优先 CI：那次转向 了解什么取代了它们以及为什么。
当一条 CI 流水线挂了，团队里就得有人停下手上的事，读日志，弄清楚什么坏了，修好，推上去，再等流水线通过。在大多数工程团队里，这个循环一天要重复好几次。
AI 智能体可以把整个循环自动化。Stitch 是这样做的。
第 1 步：检测失败
Stitch 作为下游 job 运行在你的 CI 流水线里。当上游 job 失败时，Stitch 激活。它不轮询、不用 webhook。它由 CI 系统本身触发，这意味着零延迟，也没有外部依赖。
第 2 步：读取并解析日志
CI 日志一团乱麻。里面有 ANSI 颜色码、时间戳、进度条，以及成千上万行输出。Stitch 剥掉噪声，提取出相关的错误签名。
它按类型给错误分组：lint 失败、类型检查错误、测试失败、依赖问题、build 错误。每个类别对应不同的诊断策略。
第 3 步：诊断根因
这是 AI 模型该干活的地方。Stitch 把清洗过的错误上下文连同相关源文件发给语言模型。模型看不到整个仓库，它只看到错误 trace 里提到的文件，加上它们的直接依赖。
这种限定范围的上下文是故意的。它防止模型因为不相关的代码产生幻觉，也让 token 使用量保持可预测。
第 4 步：生成并验证修复
模型产出一个补丁。Stitch 在本地应用它，再跑一遍失败的检查。如果检查通过，修复会被 commit 并 push。如果失败，Stitch 会报告诊断和尝试过的修复，让人可以带着完整上下文接手。
这一步验证至关重要。一个没有经过测试的 AI 生成修复，只是一个建议。Stitch 把每一次修复都当作一个必须验证的假设。
第 5 步：分组与去重
当多个 job 因同一个根因失败时，Stitch 会把它们分组。如果五个测试文件都因为一个缺失的 import 失败，Stitch 会把 import 修一次，并为五个 job 都报告这次修复。没有重复 commit，没有冗余工作。
护栏
Stitch 在严格边界内运行：
- 每条流水线一个分支。 一次流水线运行的所有修复都进同一个分支、同一个合并请求。
- 不做 force push。 永远不。
- 限定范围的文件访问。 智能体只读错误 trace 里提到的文件。
- 可配置的自动合并。 默认关闭。MR 落地前由你审查。
结果
用 Stitch 的团队反馈，琐碎 CI 失败带来的上下文切换变少了。对 lint 错误、缺失 import、类型不匹配这些常见问题，修复-推送-等待的循环从 15 分钟降到 2 分钟以内。更重要的是，开发者能专注于真正重要的工作。
CI 流水线总会挂。问题是每一次失败是不是都得有人待在回路里。