principle-sequence-verifiable-units

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

将工作安排为一连串小单元，每个单元结束时都要有可检查的状态；当前单元未通过检查前，不要继续推进。

如果后续工作依赖尚未验证的假设，就先处理失败后会使最多工作作废的那项。选择能够证伪它的最小有效单元。对于不确定的集成，先通过真实边界验证一条精简路径，再构建其余部分。

原因： 在引发问题的单元处发现故障，定位成本很低。等一批工作完成后才发现故障，问题就会埋在其中，而且你已经在有问题的基础上继续构建。将这些相同的单元按顺序编排成交付成果，让审查者可以重现，就能把“相信我”变成“看着它先变红，再变绿”。

执行。 在全面检查、迁移或任何一系列类似编辑中，每次更改后都要先验证，再开始下一项。每个单元都遵循“更改前后检查”的流程：确认状态良好，只做一项更改，运行检查，然后继续。先将分支变基到干净的主干上，确保每次检查都以真实基线为准。如果有工具负责执行编辑，逐单元检查几乎不费工夫。仍然要做。

交付。 按照能够证明工作正确的顺序，堆叠提交和 PR。典型结构是先提交失败的测试，再在其基础上提交修复。其他故事顺序包括：先做减法，再进行重塑；先采集基线，再实施处理；先搭好脚手架，再实现功能。每个提交都应独立成立，整个顺序读起来就像一段论证。

这一排序原则与 prove-it-works 原则技能相辅相成，后者确保每次检查都真实有效；也与 build-the-lever 原则技能相辅相成，后者让逐单元检查的成本更低。