这个案例说明什么
验收不是签字，是把交付物和合同一条条对上。材料齐不齐、指标有没有、来源真不真，每一项都能用可复核的方法查清楚。
服务对象
委托单位的两项委托开发课题：物料智能管理课题、钢材数据产品课题
我的角色
委托方项目经理，负责验收材料核查和风险把关，由开发方按清单修改。
1现象
- 两项课题的终验节点 6 月 30 日已过，逾期责任需要厘清。
- 核查时，物料课题终验材料到位 10 / 13，钢材课题仍为 0 份。
- 合同约定的三项核心技术指标，在交付材料里一次也没出现。
- 材料里声称使用的一个组件，在公开渠道查无此物。
2方法
- 跨文档一致性核查全部 Word 材料转成纯文本，逐项交叉比对合同、方案、测试报告和说明书。
- 公开渠道核查对材料里提到的组件和服务，逐个在 GitHub、npm、DNS 上核实是否真实存在。
- 合同逐页核对合同是扫描件，逐页读图核对条款，不依赖转写。
- 逾期条款解读逐条解读合同的逾期与违约条款，列出 11 条风险和应对。
3量化结果
- 14项终验材料问题高风险 3 项、中风险 4 项
- 11条逾期风险及应对
- 12项修改清单反馈开发方
- 10 / 13物料课题材料到位
4交付物
- 两项课题验收状态快照
- 合同逾期条款解读与风险清单
- 终验材料一致性核查与源码交付建议
- 终验材料问题核对清单，验收跟进台账
合计 14 项。来源：终验材料问题核对清单（2026-08-31）
关键决策与取舍
源码交付要可验证
要求每个代码仓库出 git bundle，并附源代码交付说明，验收时能还原提交历史。
运行时框架如实写
实际用的是开源 Agent 框架，材料里就如实写明，不包装成自研。
发函措辞不轻易用「顺延」
一旦写了顺延，就等于放弃了对逾期的主张。措辞按合同条款来定。