交付证据、签收动作与交接清单的最小集合

交付证据、签收动作与交接清单的最小集合

''结论'': 对固定范围服务，默认验收要真正可执行，不能只写“客户确认即可”，而要同时定义三件事：
# ''证据包'': 让客户能核验你确实交付了什么（最终文件/链接、前后对比、测试/日志/数值、范围映射清单）。
# ''签收动作'': 让客户完成一个明确、可留痕的确认动作（确认收到、确认通过或列出硬缺陷、签字/回复触发尾款）。
# ''交接清单'': 让交接可一次性检查（交付物是否齐全、访问/权限是否转移、已知限制和排除项是否写明、变更请求是否与验收分离、尾款触发条件是否明确）。
''原则'': 证据包解决“看什么”，签收动作解决“怎么确认”，交接清单解决“什么时候算完成”。三者缺一，默认验收就会退化成口头争议。

研究型服务的验收标准要写成“可判定条件”

研究/检索型产品化服务更容易被问“这算不算做完”。因此验收标准不能写成主观感受，而要写成可以逐项勾选的条件：
# ''范围内交付物齐全'': 一页结论摘要、证据表、问题边界、约定的澄清/交接动作全部存在。
# ''关键事实可复核'': 关键判断对应到来源、链接、引用或内部计算，不允许只有口头结论。
# ''硬缺陷缺席'': 没有明显事实错误、错引、漏掉约定主题或交付格式缺失。
# ''变更已分流'': 新增问题、额外主题、额外对象、额外时间窗不计入当前验收。
# ''签收动作完成'': 客户已确认收到，或在约定期限内未提出可核验的硬缺陷/关键缺失。

研究型服务的最小签收物

可把签收物收束为四件：
# ''最终版结论包'': 一页摘要 + 证据表 + 问题边界。
# ''交付清单'': 列出所有已交付文件、链接、版本号、时间戳。
# ''缺陷/争议记录'': 若客户不签收，只接受能指向具体缺陷的反馈。
# ''变更请求列表'': 所有新增工作单列出来，不能混进验收争议。

为什么要把验收和变更分离

如果客户在验收阶段加入新需求，服务就会从“结案确认”退化成“无限扩写”。把新增需求单独做成变更请求，才能维持研究型服务的明确排除项与研究型服务的最小交付包。

可直接放进 offer 的签收句式

''当你收到最终版结论包后，请在 3 个工作日内回复以下之一：''
# ''确认通过''；
# ''列出可核验的硬缺陷或关键缺失''；
# ''列出需另行确认的变更请求''。
''如在期限内未收到上述硬缺陷或关键缺失，则默认验收通过；新增需求将按变更请求另行报价。''

纸面判定结果

用 5 个可观察变量（范围内交付物、证据包、硬缺陷、变更分流、客户动作）做枚举后，验收规则可被压缩成单一路径：只有“范围齐全 + 证据齐全 + 无硬缺陷 + 客户已签收/期限到期”才算通过；其余都应被判为拒收、待决或变更。
这使交付证据、签收动作与交接清单的最小集合不仅是概念建议，而且是可执行的判定表。