历史文章。 这是 v1 发布公告，保留下来是为了记录 Stitch 的起点。v1 是一个 Python 包，作为 CI job 运行，通过 PyPI 分发。Stitch 此后经历了彻底重写，当前版本请看 Stitch 2.0 发布，我们为什么要重写请看 Stitch v1 做错了什么。
CI 流水线会挂。每个团队每周都会遇到：某个 flaky 的测试、一个缺失的依赖、一条有人忘掉的 lint 规则。修起来通常不难，但代价不小：上下文切换、等待重跑、从正事上分心。
Stitch 是一个专门处理这种情况的开源 AI 智能体。它观察你的 CI 流水线，检测失败，定位根因，并推送修复。不需要人为介入。
工作原理
你在现有 CI 配置里加两个 job。第一个是你原来的流水线，第二个是 Stitch。当你的流水线挂了，Stitch 会接手这次失败，读取日志，弄清出了什么问题，并生成补丁。
它不靠猜。它读真实的错误输出，追溯到源头，打出有针对性的修复。如果修复有效，它会推送 commit。如果无效，它会把它的发现报告出来，你能带着完整上下文接手。
它和别的不一样在哪
大多数 CI/CD 工具关注编排：跑这个，再跑那个，部署到这里。Stitch 关注的是恢复。它不是你流水线工具的替代品，而是一个补充，让你现有的流水线具备自愈能力。
关键设计决策：
- 没有服务器要管。 Stitch 作为 CI job 运行，不是服务。没有基础设施需要维护。
- 除了两个 job 之外无需配置。 丢进你的
.gitlab-ci.yml或 GitHub Actions 工作流，就完事了。 - 客户端零 JavaScript。 着陆页和文档都是完全静态的。
- 开源，MIT 许可证。 你的 CI 恢复流程属于你自己。
适合谁
那些已经厌倦了盯着流水线的团队。如果你曾经一周修过三次同一个 lint 错误，或者等了 20 分钟重跑只是为了发现一个缺失的 import，Stitch 就是为你这种工作流而造的。
它支持 GitLab CI 和 GitHub Actions。支持其他 CI 平台在路线图上。
下一步
Stitch 正在活跃开发中。核心的检测和打补丁循环已经稳定。接下来的工作包括面向大规模流水线的代理轮换、更智能的多 job 分组，以及一个用于自定义修复策略的插件系统。
今天就试试。两个 job，就是全部配置。