六百个 Pull Request、近两周时间、一次前端框架的完整迁移——完成这件事的，绝大部分不是人。开发者 steipete 复盘了自己的实验：他用 AI 长循环，把开源项目 OpenClaw 的前端从 Lit 框架迁移到 Solid 2.0，而他本人在整个过程中大约每两天才检查一次进度。
据复盘，迁移启动后约 7 小时，第一个 PR 就被提交出来；6 天 17 小时后，代码库移除了对 Lit 的直接依赖；全程累计约 600 个 PR，其中 255 个是明确的迁移 PR、352 个是后续的 UI 重构 PR，高峰时一天能产出 92 个。最能说明问题的是一个硬指标：引用 Lit 的文件数量从 796 个一路降到了 0。换句话说，这不是一次「看起来差不多」的糊弄式迁移，而是以可核查的数字收尾的彻底替换。
看点一：长循环能跑通，靠的是可验证的终点
框架迁移之所以适合交给 agent 长循环，是因为它有一个毫不含糊的验收标准：依赖清零、文件清零、测试通过。agent 每一轮干完活，都能用客观指标判断自己离终点还有多远，而不是靠感觉。这类任务的共同点是边界清晰、工作量大、重复性高——正是人类工程师最不想干、又最容易出错的活。给 agent 一个能自我校验的目标，它才能在无人盯守的情况下连续跑上六天。
看点二：人的角色从执行者变成审查者
在这场迁移里，steipete 的工作不再是逐行改代码，而是定方向、看节奏、每两天抽查一次产出。600 个 PR 平均下来，人的审查成本被摊得很薄，但关键节点一个没落下。这其实预演了未来很多团队的工作形态：工程师的价值越来越体现在定义问题、设计验收标准和把控最终质量上，而不是亲手完成每一次重复劳动。
想复刻这个玩法，先挑对任务
不是所有工作都适合长循环。适合的画像很明确：目标可以用数字或测试来定义、子任务彼此独立、失败了能回滚。下次遇到依赖升级、接口批量改造、老框架迁移这类活，不妨先花半天把验收标准和持续集成检查写扎实，再让 agent 分段提交 PR、你只做抽查。把验收做在前面，是这套打法真正的门槛，也是它能跑六天不翻车的原因。