有一次，我在看一份自动生成的草稿验收结果。屏幕上的结论很干脆：不可打开。可我继续往下看，身份信息对得上，核心结构完整，引用、媒体和元数据一致性也都通过了。真正触发红灯的，只是一个辅助目录没有出现。
这让我产生了一个很不舒服的感觉：这份结果明明已经具备使用条件，却被一项不影响打开的缺项判成了坏结果。检查程序没有“算错”某个文件，而是把不同性质的判断挤进了同一个失败开关。它看起来更严格，实际上让验收失去了分辨率。
一个红灯，掩盖了几种不同的事实
这次问题的表面，是预检发现了一个缺失项；真正的问题，是它没有先问这个缺失项会影响什么。辅助目录可能是后续整理、诊断或补充检查需要的材料，但它不是打开草稿、读取核心结构和完成基本使用所必需的承重部分。
原来的逻辑把所有缺失都写进硬失败列表。只要列表不为空，最外层的可用结论就会变成否定。于是，核心检查全部通过和辅助材料暂缺，在结果上获得了同样的权重。
验收最危险的错误，不是漏掉一个提示，而是把提示误写成阻断。
如果不处理这个问题，后面会出现两种连锁反应。第一，自动流程会拒绝本来可以继续处理的草稿，人工会被迫回头寻找一个不影响使用的目录。第二，真正的核心故障和普通缺项都会显示成同一种失败，维护者反而更难判断应该先修什么。红灯变多了，信息却变少了。
这件事让我重新意识到，自动化验收不是把检查项越多越好。检查项的价值，取决于它是否被放在正确的责任层里。
先找承重门，再谈完整性
我后来把验收重新拆开，先定义一组真正决定“能不能用”的承重门。它们包括身份是否正确、核心结构是否成立、引用是否能对应、媒体是否存在并可关联，以及元数据是否保持一致。只有这些基础条件成立，草稿才有资格被判断为可用。
这个顺序很重要。因为“可用”回答的是一个窄问题：结果现在能不能被打开、读取和继续处理。它不是在回答“所有预期材料是否都齐了”，也不是在回答“诊断信息是否已经完美”。如果把这些问题混在一起，任何一个次要缺项都会有权推翻最核心的事实。
我选择让可用结论只由承重门决定，是因为这个结论要服务于最直接的消费者：后续流程能不能接着走。一个辅助目录缺失，最多说明后续还需要补充或查看原因，却不能凭空证明核心草稿不可打开。
这里的保守，不是遇到任何异常都停下，而是只对真正可能造成损坏的条件保守。身份错了，可能处理了错误对象；核心结构坏了，可能无法读取；引用或媒体断裂，可能导致内容缺失；元数据不一致，可能让后续处理产生错误归属。这些才是承重门。
严格不是可用的另一个名字
承重门建立以后，还会有一层容易被忽略的判断：预期文件是否齐全。某些项目要求输出目录中必须包含额外文件，或者要求整套产物达到一个更完整的状态。这个要求当然可以保留，但它回答的是“是否严格满足预期”，不是“是否已经可用”。
修复后的做法，是让预期层单独产生严格结论。承重门通过而预期项缺失时，可用结论仍然为真，严格结论则为假。这样，自动流程可以根据自己的责任选择消费哪个结果：要继续打开和处理，就看可用；要交付完整包或进入更高标准的发布环节，就看严格。
可用、严格和提示不是同一个布尔值的不同说法，而是写给不同消费者的3种承诺。
这一区分也避免了另一个误会：严格为假，不等于系统坏了；可用为真，也不等于所有工作已经完成。它们分别描述不同的完成度。把两者拆开，反而更容易让上游流程做出正确选择，因为每个结论的责任边界变清楚了。
最容易误判的错误捷径
最容易走的错误捷径，是把所有缺失项塞进一个失败布尔值，然后告诉自己：检查越严格，结果就越可靠。这个想法听起来很安全，因为它似乎杜绝了遗漏。但它把“可能需要关注”和“现在不能继续”混成一件事，最后得到的是误杀，而不是可靠。
另一种捷径，是看到验收不通过就直接把所有缺项都升级成核心故障。这样做短期内很省事，不用为每个检查项定义影响范围，可代价是每一次非关键变动都可能阻断整个链路。系统越复杂，这种做法越难维护，因为规则会不断增加，失败开关却始终只有一个。
我没有选择这种一刀切的方案，是因为它无法解释这次最关键的事实：身份、核心结构、引用、媒体和元数据一致性都已通过，只有辅助目录缺失。既然不同事实的后果不同，验收结果就不能只保留一个总开关。
表面上我是在修一个预检判断，其实我是在修一份契约。契约要说明每项检查失败后，谁需要停下、谁可以继续、谁只需要收到提醒。没有这个说明，任何“更严格”的实现都可能只是把责任推给下游。
提示层要留下原因，而不是制造噪音
辅助目录缺失最后被放进了提示诊断清单。它没有消失，也没有被悄悄忽略；它仍然会出现在结果里，只是不再翻转可用结论。这个处理方式看似温和，实际更诚实：系统承认有差异，同时准确说明差异的后果有限。
提示层的价值，就在于保留那些值得追踪、但不应阻断当前工作的事实。它可以帮助人工复盘，也可以给后续补齐任务提供线索。如果未来证明某个辅助目录其实会影响某类特定流程，再把它升级到预期层或承重层，也有明确依据，而不是凭感觉改红灯。
这一步还要求诊断信息本身可读。不能只输出“缺失”两个字，而要让人知道缺的是什么、属于哪一层、会不会影响当前打开、下一步应该补什么。一个提示如果不能改变行动，就只是噪音；一个失败如果不能说明阻断原因，也只是情绪化的否定。
用互斥边界测试锁住语义
重新分层以后，最重要的不是代码看起来更整齐，而是要证明3层之间不会互相越权。为此，我把边界压缩成3种互斥情况来测试：只缺辅助项时，可用应为真；只缺预期项时，可用仍为真、严格应为假；缺核心项时，可用必须为假。
这组测试的意义，不是覆盖尽可能多的文件名，而是锁住每一层的责任。辅助缺项不能翻转可用，预期缺项可以影响严格，核心缺项必须阻断。只要这3条被固定下来，未来增加检查项时，就必须先回答它属于哪一层，以及它能影响哪个消费者。
修复后的门禁测试共58项通过，真实草稿复检时可用结论也恢复为真。这个结果让我更放心的地方，不只是数字，而是它同时证明了两件事：边界测试保住了新语义，真实输入没有再被辅助缺项误杀。
一个流程成熟的标志，不是它能在理想输入上通过，而是它能把相似的异常分到不同责任里。
这套方法并不局限于草稿验收。文件导出、数据同步、构建产物、备份校验都可能遇到同样的问题：有些缺项阻断使用，有些缺项只影响完整交付，还有些缺项只是提醒后续排查。只要先问“这个条件失败后，谁必须停下”，分层就有了依据。
下次我会怎么做
下次设计自动化验收时，我会先写结论的消费者，再写检查项。先确认哪些条件决定结果能不能打开和继续处理，再确认哪些条件决定是否满足完整交付，最后把只需要跟踪的差异放进提示层。顺序不能反过来，否则很容易从文件清单出发，最后让清单替代了真实目标。
我还会为每个检查项补一句影响说明：失败会不会破坏核心使用？会不会只影响严格交付？还是只需要提醒？如果一句话说不清，就说明这项规则还没有准备好进入自动门禁。
实现后，我会至少保留互斥边界测试，并用一个真实结果复检。自动测试负责守住语义，真实复检负责确认输入世界没有额外差异。两者缺一不可：只有边界测试，可能看不见现实数据；只有真实复检，又可能把偶然通过误认为规则正确。
这件事让我最后留下的判断是：验收不是为了尽快说“不”，而是为了准确说明“现在能做到什么”。真正可靠的质量门，会把硬故障、严格缺项和可追踪提示分开，让每个结论只承担它应该承担的责任。