可核对要求 · 验收方式 · 责任边界
交付标准：把交付到什么程度写成可以逐条核对的要求
验收环节的分歧，多半来自交付前没有把“做到什么程度算完成”写清楚。这一页把光棍影的交付要求拆成可以逐项打勾的短句，同时写明验收方式、修改范围和双方各自负责的部分，方便你在推进过程中随时回来核对，而不是等到最后一天才一起讨论。
交付标准是怎么被用起来的
标准不是签完就放进抽屉的文件。推进到执行阶段后，每完成一个可交付部分，双方都会拿这一页对照一次：客户方按编号核对内容是否齐全，光棍影按同一份编号说明这一项为什么这样处理。核对通过的部分进入下一步，没通过的部分当场记录待办，不留在口头描述里。
这样做的直接好处是收尾阶段不用再翻聊天记录。哪一项在什么时候确认、由谁确认、确认后是否发生过变更，都能在交付记录里找到对应条目。
可核对要求逐条列表
以下八条是交付时最常被拿出来核对的内容。每条都给出编号、要求描述和核对方式，编号在全过程中保持不变，方便双方在沟通记录里直接引用。
-
01
约定范围内的内容是否全部完成
对照启动前确认的工作范围清单，逐项确认是否都已产出，不遗漏、不擅自缩减。
核对方式：逐项比对范围清单与交付物清单，两边条目一一对应。
-
02
交付物文件是否齐全且可打开
交付的每个文件都能正常打开、内容完整，不出现损坏、缺失或无法读取的情况。
核对方式：客户方在约定设备上逐个打开确认，异常项当场记录。
-
03
命名与整理方式是否与约定一致
文件命名规则、目录结构和版本编号按约定执行，方便客户方后续自行查找和归档。
核对方式：抽查若干文件，确认命名规则与约定的版本编号方式一致。
-
04
内容是否与确认过的版本相符
交付内容以最后一次双方书面确认的版本为准，未确认的改动不计入本次交付。
核对方式：比对确认记录中的版本编号与交付物标注的版本编号。
-
05
关键信息是否与客户方提供的一致
名称、术语、数字口径等由客户方提供的信息，交付时与原始资料保持一致。
核对方式：抽取关键信息与客户方提供的原始资料逐条比对。
-
06
使用说明是否随交付物一并提供
需要客户方后续自行维护或操作的部分，附上简短的说明，写清操作顺序和注意事项。
核对方式：确认说明文档存在，并按说明实际操作一遍验证是否可行。
-
07
遗留问题是否已列出并标注状态
过程中未解决的事项集中列出，标明当前状态与处理建议，不隐藏在正文里。
核对方式：查看遗留问题清单，确认每条都有状态标注和后续安排。
-
08
确认结果是否留有书面记录
每一项的核对结论都落到书面记录里，写明核对时间、核对人和结论。
核对方式：检查交付记录是否覆盖全部编号，结论栏是否填写完整。
验收方式与确认流程
验收分四步走，每一步都有明确的输入和输出。走完这四步，本次交付的结论就是确定的，不需要再靠记忆判断。
-
第一步
提交交付物与清单
光棍影按约定方式提交全部交付物，同时附上对应编号的交付清单和遗留问题说明。
-
第二步
客户方逐项核对
客户方按清单编号逐条核对，把通过项和不通过项分别标记，不通过项写明具体原因。
-
第三步
集中确认与答疑
双方就未通过项集中沟通一次，区分属于约定范围内的修正，还是需要另行确认的新增内容。
-
第四步
形成验收结论
修正完成后再次核对，形成书面验收结论，写明通过范围、遗留事项和后续安排。
修改范围与超出范围的处理
修改是合作里最容易产生分歧的部分。把“哪些属于约定范围内”和“哪些需要另行确认”分开写清楚，双方在提出修改时就能先自行判断。
约定范围内的修改
- 对已确认内容中的错误、遗漏或与原始资料不符之处进行修正。
- 对表述不清、容易产生歧义的部分做文字层面的调整。
- 对格式、命名、整理方式等与约定不一致的地方做统一处理。
- 在双方确认过的版本基础上，做不影响整体结构的小幅调整。
这类修改按编号记录，完成后在交付记录中标注已处理。
超出范围时的处理
- 涉及新增内容、改变整体方向或调整已确认结构的，先评估再确认。
- 需要额外投入的部分，说明工作内容和影响范围后再决定是否推进。
- 与本次交付无关的新需求，单独记录，不并入当前验收流程。
- 无法在本次周期内完成的，写明原因和可行的后续安排。
这类情况先沟通确认，再决定是否进入下一轮工作。
双方责任边界与不包含事项
下面这张对照表把工作分成两侧。分清楚不是为了划清界限，而是为了让每一件事都有明确的负责人，避免出现两边都以为对方在处理的情况。
不包含在交付范围内的事项
以下内容不在本次交付范围内，如确有需要，会单独说明并另行确认：客户方内部审批流程的推进、第三方平台的审核结果、客户方自行修改后的内容准确性、交付物在客户方业务中的实际使用效果，以及超出约定范围的新增内容。