AI 验证循环度量 AI 编码代理能否在没有人工协助的情况下搭建项目、运行项目并验证自己的修改。这是自主代理工作的关键所在——能够检验自身工作的代理，其成果会不断累积；做不到这一点的代理只是在生成看似合理的文本——因此它在 AI 就绪度徽章中承载最高的权重。
- 类别：AI 就绪度（类别内占 40%）
- 在总指数中的权重：0%——属于独立的 AI 就绪度徽章
- 指标键名：
ai_verify_loop
数值如何计算
| 组成部分 | 权重 | 证据 |
|---|---|---|
| 一条命令的引导启动 | 22.5 | Makefile、Taskfile、justfile、mise 或 noxfile |
| 自动化测试 | 27 | 代理可用于自检的测试套件（与工程实践共享） |
| Lint / 格式化配置 | 13.5 | 与工程类的 linter 信号共享 |
| 静态类型检查 | 13.5 | 静态类型语言，或类型检查配置（mypy、pyright、tsconfig、py.typed） |
| 可复现环境 | 13.5 | devcontainer、Dockerfile、Nix 或依赖锁定文件 |
| OpenSSF Scorecard：Pinned-Dependencies | 10 | Scorecard 的 0–10 结果，换算为 10 分 |
Pinned-Dependencies 属于共享证据：它为代理验证循环补充供应链可复现性方面的信息，同时仍是安全类的完整组成部分。当 Scorecard 不可用或报告 n/a 时，该组成部分被排除。
为何这个循环决定代理的有用程度
每个组成部分各自消除自主工作的一种失败模式：
- 引导启动——代理无需考古即可从克隆走到运行。
- 测试——代理能够证明一项修改达成了预期效果。
- Lint 与类型——整类错误在评审之前即被机械化地捕获。
- 可复现环境——“在代理的沙箱里能跑”意味着在别处也能跑。
值得注意的是，这与服务人类贡献者的基础设施完全相同——该指标不奖励任何超出严谨项目既有配置之外的代理专属花样。一个扎实的 工程质量项目通常在此处起点就很高。
如何解读结果
- 信号确认的是该循环的存在，而非其速度或覆盖率——这是整枚徽章基于存在性的诚实原则。
- 验证循环得分高而代理上下文只是占位文件，通常说明这是一个工程完善、只是尚未编写代理指引的项目——这是成本最低的改进项。
提升数值
- 添加一个提供
install、test与lint目标的 Makefile（或 justfile/Taskfile）。 - 维护一套可在本地用一条命令运行的自动化测试。
- 采用类型检查——即使是最简化的 mypy/tsconfig 配置也计入。
- 提交锁定文件、Dockerfile 或 devcontainer，以保障环境可复现。