Stitch 的第一版做到了它说要做的事。你在 CI 配置里加两个 job，stitch-monitor 和 stitch-heal，指向一个公开的 Docker 镜像，下一次 lint 规则或测试挂掉时，一个带补丁的合并请求就会出现。对它能处理好的那部分失败，体验接近魔法。
我们把它发出去了。我们在自己的仓库上用它。几个月后，我们攒了一份关于它哪里错了的诚实清单。这篇文章就是那份清单。
它住错了地方
Stitch v1 是你 CI 系统里的一个居民。它作为下游 job 运行，由上游失败激活，所有工作都在流水线环境里做。听起来很干净。它带来的后果被我们低估了。
每次修复都需要一次完整的流水线来回。你的 CI 跑、挂、Stitch 跑、commit、push、你的 CI 再跑。即便在快速 runner 上，反馈循环也是以分钟计，有时是几十分钟。对 Stitch 本该处理的那类错误，缺失的 import、一个 formatter 的分歧、测试 runner 不喜欢的一个类型注解，修复本身只要一秒钟，验证却要永远。人还是在等机器，只是换了个房间。
它假设智能体住在别处
v1 通过 API 和语言模型对话。我们发了 OpenRouter 集成、一个 GitHubAdapter、一个 StitchAgent 类。上手故事是 “自带 API key”。这听起来是个小要求。实际上，它意味着每个想试 Stitch 的团队都要在某个供应商那里开账号、生成 key、存到 CI secret 里，并给 token 做预算。
与此同时，越来越多的开发者已经在笔记本上装了 Claude Code 或 Codex，已经认证过，已经通过个人或团队订阅付过钱。Stitch v1 不知道怎么和这些对话。它让用户付了两次。
它过度工程了它看得见的部分
v1 发了一个正则分类器。一个加权引擎，读 CI 日志，用一百五十条 pattern 跑一遍，把错误分到九个类别：lint、格式、类型、build、CI config、test、复杂类型、逻辑、unknown。每个类别带置信度分数。每个类别对应一个修复策略。
建它很爽。它也大部分是演戏。API 另一端的智能体完全有能力读一份原始日志并弄清出了什么问题。我们的分类器充其量是一种把 prompt 保持短小的手段。最糟时它是一个引入了自己的 bug 的翻译层。当智能体变好时，我们还在留着分类器。毕竟我们已经建好了。
它在知道之前就推送
自动合并是个开关。默认关闭，但有宣传。修复落地、重跑通过，合并请求可以自己关掉。实际上，这个开关是个自己砸脚的陷阱。CI 通过只能证明测试套件满意，不能证明补丁是对的。我们见过这样的情况：智能体通过改断言消掉一个失败的测试，绿灯拿到手，团队彻底失去了那个信号。v1 的回答是 “每个 MR 都审查”。v2 需要不一样的回答。
它对小场景扩展得很差
v1 假设团队有一个能托管它 Docker 镜像的 CI 平台、在每次失败上都有额外算力的预算，还有一个有权限往流水线配置里加 job 的人。对一个三个工程师的初创公司，这是修第一个 bug 之前要跨过的三道坎。对一个做副业项目的个人开发者，这是一堵墙。
Stitch 最擅长的那些失败，五分钟就能清理好的修复，恰恰是小团队最需要帮助的那些场景。而那些团队正是 v1 触达不到的。
我们保留了什么
不是全部。但很多。
核心想法，即 AI 智能体可以读失败日志、理解问题、产出有针对性的补丁，是对的。对验证的坚持，即一个没有干净重跑的补丁不是修复，是对的。在有限尝试之后上报的思路，也是对的。这些原封不动地进入了 v2。
围绕它们的形态没留下。系列下一篇讲的是我们把它带到了哪里。