这条讲的是一个人给自己搭的 AI 开发工具，规则就一句：AI 的活儿没有机器能验证的证明，一律当没验证；不可逆操作必须有人明确批准。出处是 Erik Hill，上个月发在 dev.to，标题叫「I built an AI dev harness that isn't allowed to trust itself」。
我一开始也以为又是那种多 agent 加流程编排的东西，让几个角色互相聊、聊完就当完成。这种我看过不少。读到第三段才确认这条值得点——作者不怎么谈模型多强，谈的是他把「证明」做成了关闭工作项的前置条件。不是「差不多能跑了」就关，是必须有个证明文件躺在磁盘上，自动检查确认过，才能关。
作者管其中一个机制叫差异预言机。核心逻辑实现两次，两个版本互相模糊测试，不一致就说明至少有一个错了。这思路不算新，差分测试在数据库、编译器里早就用烂了，但放在 AI dev harness 里是冲着「模型输出不可靠」去的。两个实现不会同时犯同一个错，模糊测试一撞，错的那个就露头。比让模型自己写测试、自己跑、自己说「过了」要硬得多。
还有个细节我读到的时候停了一下：重大变更关闭之前，有个「冷评论者」会来审。开一个零上下文的强模型会话，把这个变更从头看一遍，可以退货要求返工。关键是零上下文——这个评论者没参与过前面的讨论，没有「我已经投入这么多」的惯性，也不会被前面形成的判断带偏。
我一直觉得 AI 评审最大的坑就是自审。模型自己写的代码，自己审，总能找出理由说「还行」。冷评论者把这条路直接堵了。
然后是「无证明，不关闭」。工作项想在系统里关闭，磁盘上必须有自动检查能确认的证明文件。作者还把证明和来源绑死：设备上的验证截图得做过去敏感处理，然后绑到确切的 git SHA、屏幕尺寸、编辑方法上。不是一张截图糊上去就算证明，是谁在哪个版本上怎么改的，都能对上。
这套东西他不是跑了几天就写篇文章。作者给了一串数字——4 月到 7 月，大约 200 个工作弧、190 个人工门控检查点、74 次冷评论审查、13 次定期自我评估，积累了大约 200 个文件的证明档案和大约 90 个来源清单。都是一个人跑出来的。
我读到这里的时候有个念头：这套东西放到团队里能不能扛住。作者自己在文章末尾也说了几条他认为适用于团队的原则——AI 输出在验证前一律当未验证、门禁要建在功能之前、失败要响亮而不是静默、不可逆路径上留住人。但这些都是他一个人跑出来的。一个人，门禁自己定，自己守，证明的成本自己扛。真放到多人团队里，谁来说「这个证明不算数」？拒绝的权力如果分散了，门禁会不会变成走形式？
这条我先不展开。作者没在团队里验证过，我也没法替他补。
还有个东西跟「不信任」是同一个逻辑：作者有个公开的模型漂移面板，每天对 16 个 LLM 在冻结的确定性评分套件上打分，不用 LLM 当裁判。我第一反应是这面板跟他的 harness 是一回事——连模型好不好都不肯让模型自己评。用确定性的套件，不用会漂移的模型去打分。现在到处在讲「用 LLM 评估 LLM」，他直接绕开了。不是不信面板上的模型，是不信「模型当裁判」这件事本身。
他的可验证成果也不浮夸。文章里列了，在 SeraphLight Studios 名下把街机游戏 Tap Dodge Rush 端到端发到了 Google Play，还给 TeaVM 合并过一个单字符 bug 修复。单字符 bug 修复——这我挺喜欢。不是那种「重构了整个系统」的空头回报，就是一个字符，修了。说明这套工具不是只产空转的工作弧，是真能往外交付东西的。
冷评论者这个机制，我在评论区看到有人提了个更进一步的思路：让两个独立的策略各自生成验收集，只把分歧的部分交人工裁决。作者回应说这个想法有价值，但还没实现。这是评论区里比较有干货的一条。
这条我没法跑，只能读。读下来的判断是：它解决了一个具体问题——怎么让 AI 干活的质量不被「看起来对了」糊弄过去。差异预言机、零上下文审、门禁，单独拎出来都有来历，有意思的是这些老东西被装进一个「不许信任自己」的 harness 里，而且作者真拿它干成了事——发了游戏、修了 bug、跑了 200 个工作弧。把怀疑落成机制，而不是嘴上说「AI 要谨慎使用」。
不点链接也能带走一句：下次搞 AI 工作流的时候，别急着加角色和 prompt，先想哪个环节需要一份机器能验证的证明，把「无证明不关闭」写进流程里。