科研技术服务的交付不应只有一个演示结果或报告文件。可维护、可复现的项目通常需要同时交付源代码、模型与配置、数据记录、运行环境、测试证据、软件或设备资料、技术文档和知识转移材料。具体清单应在项目启动时确认，而不是在结束时临时补写。
按成果类型设置交付目录
| 成果类型 | 建议交付物 | 主要验收证据 |
|---|---|---|
| 源代码 | 目录、依赖、构建脚本、接口和许可证 | 从干净环境构建并运行 |
| 算法与模型 | 配置、权重、训练记录、推理代码和版本 | 在约定样本上复现指标 |
| 数据 | 数据字典、来源、处理记录、版本和授权边界 | 抽样核对字段、数量和处理链 |
| 实验与评测 | 测试集、指标公式、基线、日志和误差分析 | 独立运行评测脚本并核对结果 |
| 软件与接口 | 安装包、接口文档、权限、日志和异常处理 | 按用户流程完成测试用例 |
| 机器人与设备 | 标定、接线、通信、地图、参数和运行步骤 | 在约定工况执行测试 |
| 部署与运维 | 环境清单、部署脚本、备份、监控和恢复说明 | 在目标环境完成部署与恢复演练 |
| 项目文档 | 需求、方案、里程碑、变更、测试和验收记录 | 文档与最终代码和配置一致 |
复现验收比现场演示更重要
现场演示只能证明当时环境中的一次运行。复现验收要求项目单位或双方指定人员按照文档，在约定环境中从输入数据运行到输出结果，并核对版本、参数、日志和指标。对于随机训练或不确定性较高的过程，还应约定重复次数和允许波动范围。
如果某些步骤只能由开发者个人完成，说明知识尚未真正交付。应将隐藏依赖、手工操作、账号权限和外部服务写入环境与操作说明。无法复现的部分应明确列为限制或待办，不能用截图替代。
测试证据需要对应实际使用场景
指标只对文章或报告中记录的样本、环境和版本有效。把受控测试结果直接解释为所有现场表现，会扩大结论边界。验收报告应同时记录通过项、条件通过项、未通过项和未验证项。
- 记录测试样本的来源、版本、范围和排除条件；
- 说明指标公式、阈值、基线和统计口径；
- 保留失败样本、异常日志和原因分类；
- 区分离线评测、仿真、台架、样机和现场结果；
- 写明未测试的设备、环境、数据和性能范围。
知识产权和第三方依赖也属于验收内容
项目需要明确自研代码、项目单位原有材料、开源组件、商业软件、预训练模型和数据集的来源与许可。源代码交付不表示第三方资产的权利自动转移；可复制、可修改和可部署的范围应以许可证和合同为准。
账号、密钥、证书和设备授权不应直接写入源代码或公开文档。交付时应通过受控方式移交，并记录更换、吊销和保管责任。对于无法随项目转移的外部服务，应给出替代方案或持续费用说明。
验收后还需要完成知识转移
维护边界需要可执行。应区分原范围缺陷、新需求、环境变化和第三方升级，并为每种情况约定处理方式。这样项目单位才能在人员变化后继续运行，而不是长期依赖某个开发者的个人环境。
- 项目结构、关键设计决策和已知限制说明；
- 常用运行、配置、数据更新和故障排查演示；
- 维护人员权限、备份、监控和日志位置；
- 缺陷处理、需求变更和支持期限；
- 最终版本、哈希、交付清单和签收记录。
常见问题
只交付源代码是否足够？
通常不够。还需要依赖、环境、配置、数据说明、测试证据和运行文档，否则项目单位可能无法构建、复现或维护。
验收指标应在什么时候确定？
应在开发前或可行性验证后尽早确定。项目结束时再定义指标容易造成样本、范围和责任争议。
无法公开的数据如何验收？
可以在授权的受控环境内运行评测，保留哈希、统计摘要、脚本、日志和签字记录，不必把原始数据写入公开材料。
下一步
可在项目启动阶段使用本文清单确定交付目录、复现步骤和验收证据；已有项目也可据此开展交付缺口审查。