产品转向很少是从一张幻灯片开始的。它通常是从一条挥之不去的抱怨开始。
对 Stitch 来说，那条抱怨是延迟。即便 v1 工作得完美，反馈循环仍然是一次流水线来回。我们把它包装好、写进文档、接受它。用户没有。那些试过 Stitch 并喜欢它的人，还是把同一个问题推回给我们：我为什么要等 CI 来发现一个缺失的 import？我在自己机器上一秒钟就能跑同样的 linter。
我们一直给自己的答案是 “因为智能体需要 CI 环境”。当我们把诚实的答案写下来时，它其实是 “因为我们决定让智能体住在那里”。这两件事不是一回事。
那个观察
开发者本来就已经在本地跑 AI 智能体。Claude Code 驻扎在终端里。Codex 也是。两者都已认证、都已配置、都已经能访问开发者当前正在编辑的仓库。
这些东西在 CI 环境里都没有。为了把它们搬过去，你得把其中一部分重新拼一遍，还拼得糟糕。API key、镜像仓库、缓存依赖、挂载的 secret。全都是为了在一台 runner 上，近似开发者眼前已经有的那个东西。
这次转向，等我们终于说出口时，尴尬地简单。别再把智能体塞进流水线。让流水线在本地运行，挨着开发者已经拥有的那个智能体。让它们直接对话。
这解锁了什么
一旦你说出 “Stitch 跑在本地”，v1 的很多问题就不再是问题。
延迟塌缩。 job 和编辑器跑在同一台机器上。一个原本要等九十秒排队 runner 的 lint job，半秒就跑完。原本需要三轮流水线来验证的修复，在本地三轮就搞定。反馈以秒计，不再以分钟计。
API key 消失。 智能体已经通过开发者的 Claude Code 或 Codex 订阅认证。Stitch 不需要自己的 key，不存，也不问。上手就是 npx stitch-agent run claude，就这一条。
你现有的 CI 配置就是配置。 .gitlab-ci.yml 或 .github/workflows/*.yml 里不用加任何东西。Stitch 读你已经写好的文件，在你的机器上跑同样的 job。你仓库里的那条流水线仍然是事实的来源。
基础设施 job 留在远端。 部署、发布、镜像推送，这些都不该跑在笔记本上。v2 通过 job 名字检测它们并跳过。你在本地拿到 verify job 的执行，你的 CI 保留 infra job。什么都没重复，什么都没坏。
隐私不再是销售话术。 本地执行意味着你的日志、你的源码、你的修复永远不离开这台机器，除非你配置了把它们发到别处的通知渠道。没有 Stitch 后端可以泄漏任何东西，因为根本没有 Stitch 后端。
这约束了什么
本地优先不是白送的胜利。它意味着 Stitch 在你工具运行的地方运行。如果你的 CI 需要一个特定的 Docker 镜像来编译二进制，那你的本地机器得能做同一件事，否则这个 job 就没法在本地校验。实际上，典型的语言工具链都没问题，冷门 build 环境会比较痛。
它还意味着 Stitch 是一个人用的工具，不是团队服务。没有共享面板，没有组织级指标，没有中心控制面。这是刻意的取舍。取舍是 “你的 CI、你的机器、你的智能体、你的节奏”。如果你想要的是一个托管的合并时自动修复服务，Stitch 不是你要的那个形态。
第二个洞察
这次转向带来的第二个、更安静的洞察，是关于 Stitch 是给谁用的。
v1 一直假设一个有流水线预算的团队。v2 对一个周末项目的个人开发者也同样好用。代码不在意这一点。同一条 npx 命令，同一种终端里的智能体体验，同样零配置。我们一直在为那个我们希望有的客户做优化，而不是我们一直看着尝试 Stitch、却被它劝退的那个开发者。
本地优先让产品对任何已经拥有一个仓库和一个智能体的人都触手可及。而这越来越等于是所有人。
下一篇会更小、更技术：一个我们花了三个月搭好、然后一个下午就删掉的分类器。