一个工作流系统每天运行27次，每次都显示COMPLETED（已完成），但其中27个分支从未真正执行过。更令人不安的是，系统并不是在撒谎——它只是诚实地报告了一件没有发生的事。

这个问题的根源，是一个从项目开始就存在、却从未被写入过的枚举值：StepExecutionStatus.SKIPPED。它在代码库中的出现次数是零。

打开网易新闻 查看精彩图片

被跳过的步骤，连数据库行都没有

当某个分支的条件永远无法匹配时，步骤被跳过，运行被标记为成功，没有任何人收到通知。这种情况持续了数周。开发者最初以为数据应该存在于步骤级别的记录中——每个步骤都有自己的状态，SKIPPED就是其中之一。但检查后发现，被跳过的步骤根本不会创建数据库行，循环只是把一个字典追加到内存中的结果列表里，然后继续执行。跳过的唯一痕迹，存在于执行行上的一个JSON片段中。

换句话说，开发者构建了一个枚举值来描述某种状态，却从未真正记录过这种状态。

修复方案与一个被否决的徽章

修复只花了一个下午。现在，被跳过的步骤会写入真实的数据行，并附带原因。运行报告会显示处理、跳过和失败的数量，这些数字直接来源于数据行，因此不会与步骤视图产生偏差。

随后，开发者添加了一个徽章：当一次完成的运行实际未处理任何内容时，系统会明确提示。但审核者在不到一小时内就否决了这个方案，而且他的理由是对的。

零可能是合法的。安静的一天，没有内容可发送，COMPLETED且处理数为0，这是正确的。只有当计数是双向的，警报才有意义：运行报告它处理了什么，数据源报告它移交了什么，两者必须对得上。

一个定时工作流在无事可做时，每个安静的日子都会处理零个任务。徽章会在所有这类运行上触发，一周内就会被静音，然后在真正重要的那天反而不出现。这比什么都不显示更糟，因为它看起来像是覆盖了问题。

徽章被移除。计数保留下来，作为朴素的事实。判断权随徽章一起消失了。

部署脚本的五个绿色勾选

两天后，开发者构建了一个部署脚本：在本地运行测试，任何失败都拒绝部署，最后验证部署是否成功。它打印了五行绿色信息：

  • ✓ 已部署
  • ✓ 服务器在c15b730
  • ✓ 所有容器运行中
  • ✓ agent-mesh.org/health 健康

每一行都是真的。但刚部署的功能是死的。容器在开发者添加所需的环境变量之前就已经启动，代码发布了，却什么都没做。开发者是通过手动请求端点并读取返回值才发现问题的——而脚本没有做这一步。

验证部署成功，不等于验证功能正常。健康检查是通用的，效果检查才是具体的。这两者之间的差距，正是27次假成功和五个绿色勾选共同指向的同一个盲区。