先写测试集，再写系统

一个功能，在你能描述它怎么失败之前，都不算说清楚。先写验收行、再写系统行，就是逼着这句话在改动还不要钱的时候说出口。改动不要钱的窗口只有开工前那一小段。

三类用例，最常被跳过的是中间那类

正向：按预期把活干成。用真实数据导一份名单，人数对、总分和手算一致。

反向：该拒绝、该追问、该转人的输入。缺学号的记录，科目对不上课程表的成绩表，越权去查不属于自己账号的订单。正确行为往往是停下来问一句，这必须写成「通过」，而不是记成缺陷。

边界：空值、零分、缺考、重复、学号前导零，满分和缺考挤在同一列里。边界是客户数据最脏的地方，也是演示永远不会走到的地方。

反向用例被跳过，是因为它逼着建造者把「什么叫错」写下来，而那个定义正是客户验收时会用的定义。往后拖，等于把这个定义挪到验收会上，由更累的那一方来定。那不是谈判，是一场签了字的掷硬币。

验收表：一行一个状态

表只有三栏——检查项、预期结果、实际结果与证据——但每一行必须落到四种状态之一：通过、失败、未验证、不适用。第四种是最能救项目的一种。原版产品没有实现的接口，写成「不适用：原版未提供」，永远不写成通过。把「没有」记成「成功」的表，不是弱一点的验收，是假的验收。

一份课堂工具的交付用了十八行：入口与浏览器；导入前的备份有来源和时间；原始导出未被覆盖；班级、学期、考试正确且没有混进示例数据；人数算式成立（原有加新增等于最终有效）；同一学号不重复、同名靠学号区分；至少抽查五条记录的字段，含前导零；默认值核实过；成绩按学号姓名匹配；满分、零分、缺考、空白能区分且总分与手算一致；更正只影响指定的考试、学生和科目；保存、等待、刷新、再导出；在隔离环境里恢复并核对三条记录；接口分页与权限范围；接口幂等与冲突；断网、超时、过期、限流下的失败处理不损坏原数据；历史考勤映射；最终备份。

十八行不是官僚。每一行都是一个人五分钟内能证伪的断言。要花一小时搭环境才能验的那一行，属于自动跑脚本，不该待在签字表里。

客户自己那一套，才算验收

测试集有两套。自测集交出去，让客户挑遗漏，这是礼貌，也顺手把知识交了过去。客户保留另一套独立验收集，验收之前不给你看，那才是考试。理由跟信任无关：建造者的题目里编进了建造者对流程的理解，而客户绕开流程的那些土办法，恰恰是这套理解漏掉的部分。

一个有用的设计比例：大约 85% 的题目应当有确定答案，这样分数才有意义；剩下那部分只记录分歧，不打分。这个数字是设计目标，不是法律门槛，它的用途是让分数可解释。

还有一句必须写进验收报告、而团队总是省掉的话：这次通过，不保证下周还通过。模型更新、源资料改版、上游接口换版本，都会让结果移动。一份暗示永久有效的验收报告，等于给以后留一场维护纠纷。

两栏，让记录保持诚实

每次交付都以一页分两栏收尾。第一栏写实际验证了什么，第二栏写没有验证、不作保证。

在一份参考交付里，已验证一栏写的是：固定源码提交、核对十三个文件并保留原始许可；一台机器、一个浏览器；导入两名虚构学生，等待后刷新仍在；导出与恢复；本机中转在 127.0.0.1:8787 有响应，但没有使用真实厂商凭证。未验证一栏写的是：六款国内 Agent 客户端的安装与扣费、macOS 与 Linux 与手机、真实厂商 Key 与流式输出、全部排座规则，以及因为没有现成测试套件而未做的完整回归。

最有用的其实是夹在两栏之间的那一节：发现并有意保留的行为。保存有约 250 毫秒延迟，导入后极快刷新会丢两条记录；备份文件里可能含 API Key；姓名掩码不等于去敏。这些写成已知限制，就是设计输入；被客户先发现，就成了缺陷。

签字要有的三个字段

验收人、日期、未完成项与下一步。第三个字段空着的表不是验收通过，是盖了个章。而且签字只在签的人是将要操作这套系统的人时才算数，采购方签的字只证明买过了。

这也是为什么验收表和四周法则是同一件工具：表决定它能不能被用，周数决定它是不是真的被用。每一行都要能回到它来源的口径表，整份记录又应当放进交接里，而不是当成里程碑的附件。哪一行说不出证据放在哪，就删掉那一行并写明原因；诚实的空缺比舒服的对勾值钱。