principle-sequence-verifiable-units

将工作拆分为可验证的单元

按顺序将工作拆分为小单元，每个单元结束时都处于可检查的状态，并且在当前单元通过检查前不要继续。无论是执行工作还是交付成果，都应遵循同样的纪律。

原因： 在导致问题的单元中发现故障，定位成本很低。等一批工作完成后才发现故障，问题就会被掩盖，而且你已经在有问题的基础上继续构建。将这些单元按顺序组织成交付内容，让审核者可以重现整个过程，就能把“相信我”变成“看它先变红，再变绿”。

执行。 在全面检查、迁移或任何一系列类似修改中，每完成一项修改，都要先验证，再开始下一项。绝不要先批量修改，最后再统一验证。每个单元都要遵循“修改前后对照”的流程：确认当前状态良好，进行一项修改，运行检查，然后再继续。先将变更变基到干净的主干上，这样每次检查都是针对真实基线进行的。如果由某个工具来执行修改，那么逐单元检查几乎不费力；但仍要运行检查。

交付。 按照能够证明工作有效的顺序组织提交和 PR。标准顺序是先提交失败的测试，再在其上提交修复。第一个单元表明问题确实存在（红），下一个单元表明问题已解决（绿），这样审核者就能同时看到问题和证明。其他顺序包括：先删除，再重塑；先捕获基线，再实施处理；先搭建脚手架，再实现功能。每个提交都应独立成立，整个顺序读起来就像一份论证。

模式：

• 选择以检查结束的最小单元：一次修改及其测试，或一个可独立成立的提交。
• 每次继续前都要验证。每个单元都从红变绿，绝不拖到最后统一检查。
• 安排单元顺序，让整个序列本身就能建立信心：无论是你在执行时，还是审核者阅读提交序列时。

这是对 prove-it-works 原则技能的顺序安排补充；该技能确保每次检查都切实有效，而 build-the-lever 原则技能则让逐单元检查成本更低。