最初发表于 devopsdiary.blog。“安静的岁月”系列第 R24 篇。

这篇文章的草稿标题从四月起就一直躺在我的发布日历里：“我60天内建了24个仓库。”每隔几周我瞥一眼，数字就又错了。24 变成了 30，然后是 41。60 天拉长到了五个月。我一直没写，这反而成了我从未做出的最佳编辑决定，因为在某个时刻，故事不再是那个数字。

这个数字确实存在。AIEOS（我在几周前介绍的框架）现在有 41 个仓库：一个15层软件交付生命周期模型、一个多代理工具集、一个浏览器控制台、一个名为 Sherpa 的 CLI 指南、13 个工具适配器，以及一个可以无人值守地执行任务的控制平面。每个仓库都在 CI 下运行。适配器生成签名的 Sigstore 证明。编排核心达到 100% 行覆盖率，在 Windows 和 Linux 上都有 452 个测试通过。

但真正值得问我的数字是另一个：零。那是7月1日我审计时，适配器一致性通过的次数，背后是两个月的绿色勾选标记。这两个数字之间的差距教会我的，比41个仓库还要多。

奥马哈的三月是很好的建造天气

天是灰的，气温34华氏度，没别的事可做。

一月是九次提交地捅捅这个想法。二月是搭脚手架。三月是358次提交，跨越24个仓库，其中22个在1号还不存在。到4月9日，所有八个流水线层都建好了。全年580多次 GitHub 贡献，几乎都在这个窗口期内。我做软件已经30年，从没以这样的速度产出过。没人能靠手做到。

老实说：我几乎没写代码。我写了规则、模板、提示和验证器，然后让模型按这些去生成，每一个制品在下一个开始构建前都已冻结。所以当人们问“AI 辅助开发的夸张速度是否真实”时，我能从另一面回答。是真实的。那从来不是我的问题。

我的问题是这三年一直在问其他团队的问题：你怎么知道这些东西真的有效？

两个月的绿色，零次真正通过

7月1日，我去验证一个据说已经完成的适配器，发现流水线里有个步骤跳过了签名。不是红的，是跳过了。

把这个线索拉到全部13个适配器上，画面就崩了。每个一致性任务都跑在 continue-on-error: true 下，这个设置会强制步骤无论实际结果如何都报告成功。签名步骤被真正通过的条件所门控，而每次最新运行中都被跳过了。只有条件为假时门控才会跳过。一致性从没通过过。一次也没有。任何适配器都没有。我在自己文档里描述的“吃自己的狗粮”循环并不存在，而且永远不会有人告诉我。

根本原因几乎平淡得可笑。一个适配器的 CI 任务从没安装 pytest，所以适配器没什么可运行的，四个标准全失败。另外十一个读取了测试工具从未发送过的输入键。KeyError，在做任何工作前，每次运行都这样，从四月底开始。

审计后12天，我发表了一篇文章，采用 Sonar 的术语“验证债务”来描述代理产出物与实际验证之间的差距。我想记录一下：我在写这个定义时，自己正背着两个月的验证债务。

修复从拆除伪装开始。整个整改里最高价值的变化，就是删掉一行 YAML：真正通过才会签名，真正失败才会大声中断构建。然后是工具集重构，让每个测试套件声明自己的输入契约，并为需要容器镜像或真实端点的适配器提供真实夹具。到7月5日，所有13个适配器都从真正的通过中产生了签名的符合性证明。

BEFORE JULY 1 (masked)

  conformance fails
        |
        v
  continue-on-error: true
        |
        +--> step reports "success" --> green checkmark
        |
        '--> signing step (gated on a genuine pass):
             SKIPPED, every run. No attestation, ever.


AFTER (unmasked)

  conformance fails  --> build breaks, loudly
  conformance passes --> signed attestation uploaded

Enter fullscreen mode Exit fullscreen mode

一个 YAML 键，就是证据与装饰的区别。被跳过的签名步骤，是流水线里唯一诚实的信号。

绿色现在有意义了。

框架一直在抓自己的作者

v1.3 于7月中旬发布，带着我喜欢的声明：三个驱动器（Sherpa 用于引导会话，控制台用于点击操作，“暗工厂”用于无人值守运行）共享一个引擎。然后我用真实模型跑了第一次吃狗粮测试，通过的运行同时否定了这个声明。控制台需要一个流程文件，而这个文件在框架里只存在于控制台自己的测试夹具中。它从未加载过真实套件。三个驱动器共享一个引擎，对其中两个成立，而我自己的验证运行是唯一知道这一点的原因。

同一次运行，更糟的发现。强制“冻结后提升”的函数（框架的第二诫命）有一个完整的测试套件，却零个生产调用者。测试得很彻底。从未被调用过。不变量仍然成立，但只是因为一个无关的 bug 碰巧挡住了同一条路径。如果“安全属性由另一个缺陷维持”这句话没让你不安，请再慢慢读一遍。

同一周我给 CI 加了 Windows 运行器。它启动45秒后就因编码差距失败，这导致了套件有史以来第一次完全正确的 Windows 运行：435 个测试，没有任何环境拐杖。此后两天内关闭了十个差距，每一个都是先用失败测试证明，再关闭，而不是在提交信息里断言关闭。跟踪它们的登记册里写的是名称、日期和证据，而不是形容词。

速度真正买到的是什么

五月我写过“代理占20%的工作，平台占另外80%”。当时说的是别人的代理。我自己的也一样，而我专门构建平台侧，就是为了让那80%不是临时拼凑的。

当人们问五个月全速 AI 辅助构建是什么感觉时，我现在的回答是：生成是最便宜的部分，便宜到仓库数量都不再有趣。绿色勾选标记是某人配置过的一个声明。证据是经得起证伪尝试的东西，而这两者之间的距离，就是一行未审查的 YAML 键。一个不会在自己身上运行的治理系统，只是一份幻灯片。我的系统在七月抓了自己四次（被掩盖的一致性、幻影驱动器、未执行的不变量、编码 bug），每一次抓捕都尴尬了大约一小时，然后就成了永久的承重结构。

那个过时的标题把数量当成了成就。五个月后，数量是组织里最无趣的产物。我真正想给你看的，是7月1日那次把自己的勾选标记称为骗子的审计，以及之后让说谎变得结构上困难的流水线改动。AI 会很乐意为你建41个仓库。但你是否能信任它们，仍然是你的工作。

Todd Linnertz 是一位拥有三十年企业工程经验的高级解决方案工程师。他是 AIEOS 的创建者，一个面向软件交付团队的开源 AI 治理系统。可在 devopsdiary.blog 和 github.com/wtlinnertz 找到他。