自动化检查

自动化检查是在环境中运行的确定性验证，例如测试、类型检查、lint、构建和提交前钩子。它只给出通过或失败，不需要主观判断。这是智能体无需他人参与即可自行纠错的信号。偶发失败的测试属于损坏的检查，而不是“非检查”；自动化检查在设计上应当具有确定性。

自我纠错以循环方式工作。智能体作出改动，把检查作为工具调用运行，失败输出随即进入上下文窗口——例如带有文件名和行号的类型错误，或同时给出预期值与实际值的失败断言。这些信息足以让智能体修复问题并再次运行检查，如此反复直到通过，全程无需人工介入。确定性让这个循环值得信任：相同代码总会得到相同结论，因此“通过”才真正有意义。偶发失败的检查会污染循环——智能体可能“修复”原本正确的代码，也可能靠反复重试越过真实故障。

这就是良好检查构成代码库 AX 重要部分的原因。严格类型、快速测试套件和 linter 能让仓库中的智能体在你看到结果前自行发现大多数错误；如果仓库什么都没有，智能体只能直接交付自己生成的内容。这种差异在 AFK 运行中最重要，因为检查是运行期间唯一发生的验证。但检查只能发现它明确断言的内容——全部变绿只说明被断言的性质成立，并不代表代码整体正确。那些需要判断力才能填补的空白，属于自动化审查和人工审查。

避免：使用“反馈循环”或“反压”，因为二者会把检查与审查混为一谈。也不要简单称为“测试”——测试属于自动化检查，但自动化检查并不只有测试。

用法：

“智能体在 AFK 运行中一直交付损坏的代码。”

“沙箱中接入了哪些自动化检查？”

“只有单元测试。”

“加入类型检查和 lint——在 PR 产生之前，它就能依据这些结果自行纠错。”