测试没跑出结果，不能算通过

AI 说「检查通过」，但测试命令根本没跑，这次验证算什么？原文给出的答案很明确：没有采集到证据，就不能判定通过。缺少脚本、依赖服务没启动、测试没进入目标分支，都应该留下可见的验证缺口。

这篇文章值得程序员读的地方，是它把「代码看起来没问题」和「行为经过验证」分开了。尤其在 AI 编程中，一段语气肯定的完成说明，很容易让人误以为测试已经执行。判断依据应该回到可复现的命令、原始输出和实际覆盖的行为。

没有结果，为什么不能算通过

通过是一项需要证据支撑的判断：命令确实执行了，执行结果能够证明被检查的行为符合预期。空结果不满足这个条件。没有执行、没有测量，也就没有可以检查的原始记录。

没有发现失败，不能自动推导出已经验证成功。

原文区分了两种状态：缺失脚本的检查标记为 unverified，也就是尚未验证；没有足够验证证据时，结论是 inconclusive，也就是无法定论。后者不代表代码一定有错，而是目前没有依据判断它对不对。

作者还强调，这个结论由确定性规则产生，不需要模型参与。大白话解释，就是先按证据是否齐全来判断，不让 AI 根据代码观感或解释能力，把缺失的测试结果补成通过。

这套区分在 AI 代码审查里尤其有用。模型可以提出「这里可能有问题」，也可以解释「这段逻辑应该成立」，但这些都属于假设，不能替代实际运行得到的结果。

命令跑过了，也不等于目标行为验证过了

原文列出的证据缺口有四类：项目没有测试脚本；配置了命令，但在当前环境中没有产生可用于验证的运行结果；动态测试没有进入待审查分支；检查依赖的服务没有运行。

它们不一定说明代码有缺陷，却都说明验证流程还没完成。

其中最容易漏掉的是分支问题。测试套件运行过，只能说明其中实际执行到的行为获得了相应证据。如果待审查的分支没有进入，就不能把整套测试的成功结果直接套到这个分支上。

因此，一条有用的验证记录至少需要可复现的命令和原始进程输出，还要确认检查触及了目标行为。只有一句「测试通过」，既无法复查执行过程，也很难定位遗漏。

原文给出的补齐路径很直接：添加或修复缺失脚本，让命令能够执行；运行并保留原始输出；确认覆盖待审查的分支或行为；最后重新执行审查，让确定性规则更新结论。

部分验证就保留为部分验证。剩余检查没跑完，模型补一段解释也不能填平缺口。

我的判断

我赞同作者对证据边界的要求。它解决的是一个很具体的问题：团队看见绿色标记后，会据此决定是否继续交付。如果这个标记连「检查是否执行」都没交代清楚，后续判断就失去了基础。

但这里需要补上两个边界。

首先，终端没有打印内容，与测试没有执行，是两件事。原文的核心论点针对没有验证证据的情况，不能机械理解为「没有日志就一定没跑」。判断时仍要核对实际执行记录，以及检查是否覆盖目标行为。

其次，有命令、有输出，也不等于验证已经充分。作者提到了分支覆盖，却没有展开如何确认覆盖范围，也没有说明断言是否足以证明业务行为正确。证据存在，是评估证据质量的起点。

原文以 Powerduck 为例，称它会保留缺失证据，并显示需要补充的命令。不过，文章没有提供产品实测过程、判定规则细节或对照数据。因此，可以接受这条验证原则，但还不能据此认定某个工具比现有 CI 或人工审查更可靠。关于缺口往往到生产环境才暴露的描述，也属于经验判断，文中没有给出统计支持。

能拿来做什么

• 让 AI 完成前端或 Node 项目修改后，要求它分别交代执行了什么命令、得到什么结果、还有哪些检查未完成。没有运行条件时，明确保留为尚未验证。
• 检查项目的测试脚本和依赖服务是否可用。遇到脚本缺失或服务未启动，先补齐运行条件，再重新验证，不把执行受阻记成通过。
• 审查条件分支修改时，核对测试是否进入了对应路径。整套测试运行成功，也要确认这次修改涉及的行为确实被检查。
• 在审查记录中保留可复现命令和原始输出，并将部分验证单独说明，让接手的人知道哪些证据已有、哪些仍需补齐。