自己写代码、自己审 PR、自己发版：万星项目 Magpie 是如何跑通 AI 自主维护闭环的？
先说结论：AI 写代码真正的分水岭，从来不是“能不能生成代码”，而是“能不能收敛系统”。开源 19 天斩获 11,000+ Stars 的本地网关 Magpie，没有依赖复杂的编排框架，而是靠一套近乎残酷的证伪机制与“事不过三”错题本，跑通了目前开源界最纯粹的软件闭环。
图 1：自主编程智能体闭环工程与自愈流水线概念图
绝大多数团队在使用 AI 进行工程开发时，都会撞上一堵无形的墙——我们可以称之为“第三天诅咒”：
第一天惊艳：丢一个模糊的需求，Agent 几十秒内敲出完整的模块骨架，类型与注释一应俱全；
第二天狂飙：让它接管多文件复杂业务，提交记录疯狂刷屏，看似生产力暴增；
第三天崩溃：本地测试全绿，上线直接白屏；修好 A 模块导致 B 模块崩塌，修好 B 又把 A 覆写回去。代码库陷入不可逆的熵增死循环。
代码生成（Generation）的边际成本已经被大模型压到了极低，但代码审查与回归验证（Verification）的认知摩擦力却呈指数级上升。
没有约束的 AI，本质上是一台最高效的“技术债务印钞机”。
这也是为什么当知名开源作者 yetone 的网关项目 Magpie 在 19 天内发布了 1,200 多个版本、狂揽 11,000+ Stars 时，同行第一时间质疑其为“快餐代码”。
但真正拆解其底层工程设计后会发现，它之所以没有在海量提交中爆裂，是因为建立了一套极其冷酷的机器原生负反馈体系（Harness Engineering）。
1 物理证伪：旧代码必须当场真挂
在传统 AI 编程流中，最致命的陷阱是“让 AI 自由补齐单元测试”。
大模型作为生成器，会极其顺从地编写出一堆刚好能通过自身错误逻辑的“假绿测试”——大量的全量 Mock、恒真断言，在本地跑出一片祥和的绿色，实则毫无测试覆盖度可言。
要对抗这种自欺欺人，唯有引入波普尔的证伪主义：一个新测试如果不能在物理上证伪旧代码，它就不具备任何工程价值。
在 Magpie 的代码规范体系中，PR 审查（全部由 Agent 自主执行）设立了两道不可通融的硬防线：
- 回退挂测（Red Check）：
审阅代码时，Agent 必须把修改前的旧代码放回去运行新写的测试，测试必须当场真挂（Fail），且报错信息必须明确指出是哪个预期行为出现了损坏。测试被跳过或编译报错一律视为无效。 - 人为击穿（Break Check）：
故意在代码关键分支改坏断言，物理验证测试用例是否真能报警。
翻看仓库中真实合并的 PR 审查记录（如 PR #1339），Agent 在合并前留下的审查评论没有任何客套，每一项检查都留有不可篡改的证据：
工程规范明确规定：没跑过的检查必须显式声明为 Not run，严禁掩耳盗铃。未经过真机实测的功能，不得向用户承诺可用，也不得在其上继续派生代码。
2 动态错题本与“事不过三”法则
很多人试图通过编写一份数千行、无所不包的“超级 Prompt”来规范 Agent 的行为。这在系统论中属于典型的死局：静态规则永远无法穷举长尾故障，反而会严重稀释大模型的注意力上下文。
Magpie 的解法是将规则拆为“三级阶梯”，让规范在实战事故中动态生长：
- L1 极简路由（CLAUDE.md / AGENTS.md）：
入口文件仅两行引用，路由表只负责指路（改核心看docs/subsystems/，写代码看docs/code-standards.md，审查外部提交看docs/contributors.md），绝不在主入口堆砌具体规则。 - L2 动态错题本（LESSONS.md）：
这是整套系统最核心的进化器官。每天深夜，Agent 自动对全天的所有 Commit 启动“夜审”，专查三件事：哪些修复后来反复返工？哪些改动根本不该合入？哪些验证流于形式？
只要揪出一次典型反例，就记录一条结构化条目（事故成因、修复提交、做对的例子），并标上 Seen 1×：
- L3 刚性硬化（“事不过三” Seen 3× 法则）：
如果某条教训在 3 个不同日子的夜审中被重复捕获，证明该错误属于系统性高频缺陷。此时系统触发升格机制：该规则从错题本移出，强制转正硬化为docs/code-standards.md里的全局标准规范！
通过这种机制转正的 8 条硬规则，每一条都是被现实打出来的真理：
- 同类 Bug 必须全量拔除（不能只修报错截图里的那一个 Agent，兄弟模块必须同步排查）；
- 改动必须重推导衍生下游（修改公式或布局断点必须重新运行所有关联页面的测试）；
- main 分支挂掉的测试即当前最高优先级 Bug（严禁将红灯当成偶发 Flake 忽略）。
3 单日 170 版狂飙与 CI 物理急刹
任何自执行系统一旦缺乏物理节流机制，必然滑向不可控的发散。
在 Magpie 的开发演进史中，2026 年 10 月 5 日曾经是一场灾难：当天 Agent 狂飙突进，单日提交了 220 个 Commits、发布了 170 次版本。其中近四分之一的版本在给当天刚发出的 Bug 打补丁。
故障根因不在模型智商，而在 CI 的物理配置：
GitHub Actions 默认开启了快速推送自动取消（cancel-in-progress），导致前一次测试还没跑完就被下一次 push 掐断。一个仅在 Linux 平台出现的底层编译错误，整整在 15 个连续版本中一路飘红却无人察觉。
10 月 6 日凌晨，项目引入了第一版错题本，并在 CI 配置中落下了决定性的物理刹车：
对 main 分支彻底关闭并发取消。打 Tag 之前，CI 必须全绿跑完，被后续提交打断的测试结果一律作废！
刹车踩下的效果通过数据展现得淋漓尽致：
图 2：Magpie 每日发版数量与自愈拐点（数据通过 git-for-each-ref 提取自 github.com/yetone/magpie 官方 Tag 提交历史，由笔者独立统计绘制）
从单日 170 版的失控狂飙，断崖式收敛至 41 版、14 版，并最终平稳运转在每日 15~26 个经过全量绿灯验证的高可信版本。
4 AI 负责循环，人类退守三道防线
在这套由 Agent 全权承包“写、审、合、发”的体系里，人类究竟该站在什么位置？
根据作者 yetone 本人的公开复盘，他在本地利用 Claude Code 搭配 Opus 5.5 模型，并行开启了 3 个长程循环（Loop）：
- Loop 1：监控 GitHub Issues 与 PR，实际在本地跑测试验证逻辑，兼顾 Discord 社区需求；
- Loop 2：监控推特上的真实 Bug 报告，通过轻量模型过滤杂音后执行定向修复；
- Loop 3：定时清理屎山代码与恶意 PR，总结经验更新错题本，并将低质贡献者拉黑：
人类工程师彻底退出了逐行敲写业务逻辑的低效泥潭，转而退守三道具有物理决定权的绝对阵地：
- 真实物理运行底座：
拒绝纯粹的虚拟 Mock，必须由人类搭建起横跨 macOS 物理机、Windows 物理机及内置 Linux 虚拟机的真实三端硬件环境，强迫 Agent 必须在物理机上复现并修复问题。 - 审美品味与不可逆决断：
前期通过头脑风暴将架构偏好与审美标准注入模型记忆；日常仅在夜间对 Agent 较弱的 UI/UX 进行人工调优；并通过Don't reverse deliberate decisions戒律，严禁 Agent 擅自推翻人类已拍板的产品设计。 - 安全与依赖的绝对闸门：
对.github/工作流改动、外部网络回传、凭据读取或新增第三方二进制依赖，设立一票否决的熔断门禁。
5 关于自主闭环的工程思考
Magpie 的实践，撕开了下一代智能体工程化协作的真实切口。但如果冷静审视，这套模式在大规模团队推行时依然横亘着几处物理瓶颈：
- 长程跨会话上下文的符号衰减：目前依然依赖自然语言 Markdown 传达规范。代码量一旦跃升至百万行级别，局部修改与全局架构的对齐依然存在漂移风险；
- 多开发者并发写入的合并墙：单机并行 Loop 相对可控，但多团队同时高频提交时，回退测试与分支 Rebase 的开销会迅速激增；
- 复杂视觉 GUI 的自动化天花板：窗口层叠透明、复杂微交互与跨屏拖拽，现阶段依然是端到端脚本测试的盲区，仍需人类眼球兜底。
AI 编程不是魔法，它是更纯粹的系统工程。
如果你也正挣扎在 AI 编程的“第三天死循环”里，不妨暂时停下对更大 Prompt 的追求：去给你的代码库建立第一条“不通过就不能合并”的 Red Check，去建一本只记录返工与脆弱验证的错题本。
参考来源与权威信源
- 开源代码仓库: yetone/magpie (GitHub)
- 作者原帖与复盘: yetone 工作流公开复盘 (X)
浙公网安备 33010602011771号