Ariaki有人在开发一个 Linux 发行版，为了修 AMD 显卡驱动的显示问题，把电脑搬到镜子前面，让笔记本的摄像头通过镜子拍自己的屏幕，再把画面喂给 AI agent。agent 改一行驱动配置，自己看一眼屏幕，发现还在闪，继续改。
评论区第一反应是：这也太土了，直接用 OBS 建个虚拟摄像头不就行了，还省资源。
这条建议听上去无懈可击，实际上会让那个 bug 彻底修不好。原因在下面第 4 节，那是全文我最想让人带走的一段；只想要动手方法的看第 6 节。
1. 同一个模型，在两个仓库里像两个物种
先把话说白。我这里说的闭环，指的是 AI 自己写代码、自己跑、自己看结果、自己再改，这一圈转下来不需要人插手。开环是另一种：AI 改完了，你得去看日志、看界面、看输出，然后由你把"这里不对"说回给它。
同一个模型，扔进一个有完整测试套件的仓库，它能自己折腾一下午最后交出一个通过全部检查的补丁。扔进一个只能靠人肉眼看的项目，它写三次你就烦了。
很多人把这个差距归因到模型能力，或者 prompt 写得好不好。实际上两边用的是同一个模型、同一句话。差的是它被允许试错的次数。
这跟我上一篇讲的验收带宽是同一件事的两个面。那篇讲的是你的验收能力决定你能安全用多少 AI；这篇讲的是机器能不能替你验，以及这一步差别有多大。
2. 闭环三件套，缺第三条的最多
一个循环要能自己转起来，需要三样东西同时成立：
- 动作可自动执行 —— 它能自己跑起来，不需要你点按钮
- 结果可自动观测 —— 跑完的输出它能读到
- 结果可自动判定好坏 —— 它能知道这次是对了还是错了
绝大多数人卡在第三条。日志它读得到，命令它跑得动，但"这条日志算好算坏"这个知识存在你脑子里。于是循环转到第三步断掉，AI 把日志原样贴给你，问"您看这样可以吗"。
这一下就把问题从"模型够不够强"挪到了"你有没有给它装一个裁判"。前者你没办法，后者是你今天下午就能干的活。
镜子那个案例正好是三件套齐了：改配置（可执行）、摄像头拍屏幕（可观测）、画面在闪还是不闪（可判定）。这三条一凑齐，人就可以从循环里走出去了，哪怕代价是把笔记本摆成一个很滑稽的姿势。
3. 圈数经济学：一圈多少钱
为什么闭环的产出会差出一个数量级，用一个除法就能算清楚：
AI 在一个任务上能试的次数 = 你愿意付出的总预算 ÷ 单圈成本
闭环里单圈成本是机器时间，跑一遍测试三十秒，钱是几分钱。开环里单圈成本是你的注意力：切过去看一眼，理解上下文，判断，写回反馈，再切回自己原来在做的事。真实成本是三五分钟起，而且有上下文切换的损耗——你原本在想的那个事已经断了。
两边差两到三个数量级。代进上面那个除法：同样是一小时的预算，闭环项目里 AI 可以试一百次，开环项目里你看五次就想把电脑关了。
而生成模型是一个采样器。采样一百次和采样五次，出来的东西质量完全不是一回事。 它不需要一次写对，它需要被允许写错很多次。
所以给一个仓库补测试的收益，从来不只是"防止回归"这一条。它把 AI 的试错次数从个位数抬到三位数。我自己的体感是，一个有完整自动检查的项目里，模型像换了一代；实际上换的是我允许它失败的次数。
4. 判据放在哪一层，决定了它能不能看见那个 bug
回到镜子。
"用 OBS 建虚拟摄像头"这条建议里，有一个被所有人默认为真、但其实不成立的假设：摄像头拍屏幕和软件抓屏幕，抓到的是同一个东西。
不是的。软件截屏抓的是 GPU 已经吐出来的那一帧画面。而他要修的是撕裂、闪烁、掉帧——这一类故障恰恰活在那一帧之后：合成器、驱动、扫描输出、面板刷新。截屏跟被测对象共享同一段上游管线，故障发生的那一段它压根不经过。
Reddit 上有个人把这句话说得很准：截屏只能捕捉 GPU 输出了什么，不一定等于最后显示在屏幕上的东西，而且截屏抓不到撕裂和闪烁。
换成 OBS 之后，会发生什么？循环还是闭的。三件套还在。CPU 占用还更低。跑得又快又稳，一直报告"画面正常"。
一个更优雅、更省资源、看起来更聪明的改动，把这个闭环变成了一台永远亮绿灯的机器。
我管这个叫判据放置：判据本身没坏，是采样点被挪到了故障的上游。这件事之所以危险，是因为它在两个方向上都很隐蔽——从外面看循环在转，从里面看每次都是绿的。
这不是一个理论上的失误，是我自己犯过的。我写过一个自动检查脚本，从一行输出里按列号取那个要比对的数字，列号数错了一位，于是它拿一个完全不相干的指标去跟阈值比。那个阈值是个小数，而被它取错的那一列永远比阈值大好几个数量级——这个检查从写完的第一天起就不可能失败。它跑了很多次，全绿。我发现它坏掉的唯一原因是某次盯着输出，觉得那个数字大得不合常理。
补一句更实际的：任何"按位置取列"的判据，都该在旁边注释一行当时的表头，并给关键指标加一条数量级断言。后者比对齐表头更耐用，因为它不依赖你这次有没有数对。
坏掉的检查比没有检查更危险。没有检查你还知道自己没测；坏掉的检查让你以为测过了。
所以镜子那个做法荒诞的只是物理形态。它把判据放在了整条链路的最末端——真正打到眼睛里的光子。这个位置选得比 OBS 对，而且对得不止一点。
5. 开环会让 AI 慢慢优化错目标
上面说的是伪闭环。开环有另一个病，更慢性，也更少被讲。
闭环里，AI 优化的目标是明确的：让测试变绿。这个目标客观、不可谈判、跟它说什么话没有关系。
开环里，唯一的反馈信号是你点不点头。于是它优化的目标会悄悄漂移成让你点头。这两件事在大多数时候重合，在关键时刻分叉。
我派子 agent 干活的时候经常撞见这个。它们回来的汇报几乎总是"已完成，已验证，功能正常"。问题在于，"已验证"这三个字本身是它写的，没有任何外部东西为这句话背书。我要是不去读它改的文件、不去把命令真跑一遍，我拿到的只是一份措辞得体的自述。
有的时候文件确实改对了。有的时候没改。汇报的语气是一模一样的。
因为在开环里，"让你相信做完了"和"做完了"这两条路径通向同一个奖励，而前者便宜得多。长期泡在开环里，等于在训练一台话术生成器。
顺便说一件更扎心的：人自己也在开环里。METR 2025 年那个随机对照实验，16 个资深开源开发者在自己熟悉的仓库上干活，用 AI 的那组实测慢了 19%。真正的重点在后面——他们事前预期 AI 会让自己快 24%，事后亲身经历完，仍然认为自己快了 20%。
亲自做完一遍，方向都判反了。你对自己速度的感知，本身就是一个没有裁判的开环。
6. 唯一要动的手：把"我得去看一眼"翻译成一个退出码
这一节只有一件事。
接下来一周，每次你冒出"我得去看一眼日志 / 看一眼页面 / 看一眼输出对不对"这个念头，停一下，问自己：我这一眼在判断什么？
然后把那个判断写成一段会返回非零退出码的东西。
- "我看一眼有没有报错" → grep 那个关键词，命中就退出码 1
- "我看一眼这个数对不对" → 拿它跟一个独立算出来的值比，差超过阈值就退出码 1
- "我看一眼页面有没有裂" → 截图，跟基线图做像素差，超过就退出码 1
- "我看一眼这个接口还通不通" → curl，非 200 就退出码 1
每写成一条，就把一次人类注意力换成了几分钱的机器时间，等于把第 3 节那个除法的分母砍掉两个数量级。
写完之后必须做一件事：故意把代码改坏，看这个检查会不会红。 不会红的检查是装饰品。我上面那个取错列的脚本，只要当初往里塞一次假数据，第一天就会暴露。
7. 闭不上的那部分
有些东西闭不了环。这个页面好不好看、这个产品值不值得做、这个文案读着舒不舒服——判据在人脑子里，而且没法外包。围棋十年前就被拿下了，因为胜负是免费判据；审美到今天还得你亲自点头，因为除了你没人是那个裁判。
对这部分，别装。装出来的闭环就是第 4 节那台绿灯机器。
能做的是把单圈做便宜：一次给我看五个版本而不是一个，做成改一下就能看到效果的形式，把"要不要"的决定压缩成一次扫视。开环 + 单圈便宜 + 出错可以撤回，照样可以跑得很快。开环 + 单圈很贵 + 出错撤不回来，那就老老实实先花时间把判据造出来再动手。
衡量一个团队用 AI 的产能，别看他们用什么模型。看他们有多少条判断，已经从人脑里搬进了退出码。
参考：Reddit r/omarchy 关于摄像头对镜取景调试显卡驱动的讨论串（2026-09）；METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025-07)。