Stitch 2.0 发布了。如果你一直在关注这个系列，短版本是：你在那些复盘里读到的所有东西，现在都落地了。
如果你没有关注，这篇文章是一个独立的总结。Stitch 现在是什么，和 v1 有什么不同，以及如何在接下来的三十秒内试用它。
Stitch 2.0 是什么
一个运行在你笔记本上的命令行工具。它读取你仓库里已经存在的 CI 配置，解析你定义的 job，在几秒钟内在本地跑完 verify 类型的 job（lint、typecheck、test、build）。当某个 job 失败时，Stitch 把这次失败交给你已经安装的 AI 智能体（Claude Code 或 Codex）。智能体修复问题，Stitch 重新跑一遍 job。通过了就结束。
一条命令即可安装和运行：
npx stitch-agent run claude无需 API key。无需 Docker 镜像。无需新的流水线 job。无需配置文件。你已有的 CI，跑在你已经在用的机器上，搭配已经开在你屏幕上的智能体。
相比 v1 改了什么
给用过 Stitch v1、想知道什么不一样的同学，简短清单：
- 语言。 v1 是 Python，在 PyPI 上分发。v2 是 TypeScript，在 npm 上分发。包名仍然是
stitch-agent。 - 执行模型。 v1 作为流水线失败触发的 CI job 运行。v2 从你的终端本地运行。流水线保持不变。
- 智能体集成。 v1 通过 API 和模型对话，用你提供的 key。v2 委托给你已经安装的 Claude Code 或 Codex，使用你已有的订阅。
- 配置表面。 v1 要求你在 CI YAML 里加两个 job（
stitch-monitor、stitch-heal）。v2 完全不需要改动你的 CI。 - 错误分类。 v1 有一套 150 条 pattern 的正则引擎，把错误分成九类。v2 全都没有。诊断由智能体直接处理。
- 自动合并。 v1 有一个开关。v2 只在干净分支上、且你传了
--auto-commit时才会自动 commit 加 push。默认关闭。 - 交互式 TUI。 v1 的输出是 CI 日志。v2 有实时终端 UI，包含流水线阶段条、job 状态表和 driver 面板。
- 监听模式。 v2 新增。文件保存时重新校验受影响的 job。
为什么是完整重写而不是迁移？因为这些变化大多不是功能，而是形态。一个要跑在 CI 环境里的库，结构上就和一个要跑在编辑器旁边的 CLI 不一样。想把 v1 改造成 v2 比从头写 v2 更慢。我们先试过慢的那条路。这个系列的前几篇文章解释了我们是如何得出这个结论的。
这是给谁的
我们在重写时心里想的画像：
- 你在一个或多个带 CI 流水线的仓库里工作。
- CI 因为琐碎原因失败的频率足以让你注意到。
- 你日常已经在用 Claude Code、Codex 或其他 AI CLI 智能体。
- 你不想为了发现自己漏了个分号而等一次远程流水线来回。
如果这是你，Stitch 2.0 一条命令就能用。
下一步
Stitch 2.0 是本地优先形态的第一个发布版本。从这里开始的路线图比 v1 更短、更简单，这是故意的。我们接下来想加的东西：
- 更多 CI 平台。 目前支持 GitLab CI 和 GitHub Actions。接下来是 CircleCI、Drone 和自托管 runner。
- 更多智能体。 当前的 driver 是 Claude Code 和 Codex。再接入其他基于 CLI 的智能体只是一种小范围的模式匹配。
- 更好的 job 推断。 用来区分 verify 和 infra job 的启发式规则已经不错，但并不完美。一些奇特流水线上的边缘情况还需要打磨。
- 团队共享。 不是面板，不是服务。只是一种方式，让一条
.stitch.yml策略在仓库里共享，不用每个开发者重新摸索一遍。
我们刻意不加的东西也值得点名。没有托管服务。没有账户。没有遥测。不拿你的代码做训练。如果这些改变，会是一个独立的产品，独立的名字。
试试看
npx stitch-agent run claude如果你有十分钟和一个挂掉的流水线，就够了。仓库在 github.com/x24labs/stitch-agent。issues 开放，欢迎贡献。
感谢你读完整个系列。对于 “为什么非得重写” 这个问题，诚实的回答是：在亲眼看着错误的形态发布之前，正确的形态并没有摆在我们面前。v2 才是我们一开始就想做的那个版本。只是要先做出 v1 才能知道。