样例包被放行，常见理由不是它真的可验收，而是"看起来像那么回事"。要让它变成可检查的东西，得先把判定规则和交付格式写进需求说明。需求里没写的部分，执行者会替你决定；等到样例出来再讨论，讨论就没有落点。
需求说明要写清的八项
任务定义与边界。 正例、负例之外，还要写"不确定/无法判断"这一类怎么处理。这一类不写，供应方只能自己替你决定，结果会在长尾样本上散开------每个执行者的判断尺度不同，最后交回来的数据在边界处没有统一口径。
标注单元。 按整图、按框、按时间段还是按句；一个单元允许多个标签还是只能一个；标签之间是否互斥。单元不清，工作量估算和质量判断都会失真：同一个任务，按整图算和按框算，交付物的粒度完全不同。
标签集与定义。 每个标签给一句可操作的定义，至少配一个边界例子，说明易混标签怎么区分。只给标签名，等于把定义交给了执行者。
抽样与来源条件。 允许哪些来源、哪些来源需要排除、同一来源重复出现时怎么处理。来源口径不一致，会直接改变数据分布，而这在样例阶段未必看得出来。
交付格式。 字段名、编码、坐标或时间基准、类别 ID 与类别名的对应、文件组织方式。格式要在下单时固定，不留给交付时协商。
质量判据与复核方式。 自检怎么做、抽样复核怎么抽、出现分歧以哪条定义为准、由谁裁定。判据可以是流程性的，不必编造一个通过率数字。
变更与返修规则。 需求变更如何记录、返修范围如何界定、返修后是否需要重新抽样。
来源与使用范围的记录方式。 要求供应方随交付提供来源清单与使用条件说明，便于后续追溯。
一个假设例子
假设某团队首批样例里，争议样本全被判成了正例，原因是需求没写"不确定"如何处理。他们把这一项补进需求后重新要样例，验收讨论才有落点。这个例子只解释判断顺序，不代表任何真实供应方或项目。
样例包的验收顺序
先确认样例是不是与正式交付同一流程、同一人员配置产出，而不是专门挑出来的好例子。再看争议样本和边界样本有没有被覆盖，分歧是否有记录。然后按交付格式逐字段对照，确认能直接读进下游流程。最后核对来源清单是否随样例一起给到。
这个顺序的意义在于：前一步不成立，后一步的结论就不可靠。样例再漂亮，如果是挑出来的，它说明不了正式交付会是什么样；格式再整齐，如果争议样本没覆盖，也看不出判定规则是否够用。
样例通过只代表本次样例符合约定，不代表整批合格，也不代表后续批次不需要抽样。
可带走的需求骨架
任务定义与边界（含不确定类）＋标注单元与互斥关系＋标签定义与边界例子＋来源与抽样条件＋固定交付格式＋复核与裁定规则＋变更返修规则＋来源与使用范围记录。
这几项填满，样例包才谈得上验收。填不满的部分，要显式写成待定，并约定由谁决定------是需求方自己定，还是双方共同确认，而不是默认由执行者代填。待定项和已定项分开列，验收时才知道哪些缺口是已知的、哪些是漏写的。
按这份骨架填写，不承诺一定拿到合格数据；它解决的是"验收有没有依据"，不是"数据一定合格"。