交付签收单怎样记录保留意见

收到源码包、后台账号或设计文件时，可以先确认收到了什么，再记录验证了什么。若尚未测试某个功能，或双方对结果有分歧，签收单应把这些状态分开写，供后续处理时对照。具体签收方式、权利义务和法律效果需要结合双方约定确认，不能仅凭一份通用模板判断。

先区分收到、已验证和待处理

收件部分记录交付日期、交付方、接收方、文件或账户清单、版本标识和存放位置。接收人只核对能否获取材料时，就写明核对到这一层，不把“文件可下载”写成“系统验收通过”。密码和令牌不进入签收单正文，另行按授权流程传递。

验证部分引用实际执行的用例编号、环境和结果。没有条件测试的项目标为“未验证”，写明缺少的账号、数据或外部配合；已经发现问题的项目标为“待处理”。这几类状态分别记录，不用一个笼统的“基本完成”掩盖未核对的范围。

保留意见指向具体证据

例如在假设项目中，搜索页可以打开，但未登录账号仍能搜到不公开资料。保留意见可写为“权限用例S-03结果与需求R-08不符，详见测试记录”，再列双方意见和待确认事项。示例用于说明记录方式，不代表任何真实客户系统存在该问题。

截图、日志或录屏注明对应版本和操作时间，涉及个人资料时先脱敏。不要只写“搜索不好用”，也不要在没有核验时归咎于某个人。若一方认为属于范围外需求，另一方认为属于缺陷，就同时记录依据，保留尚未达成一致的状态。

复测后追加结果，保留原记录

给待处理项指定对接人，约定下一步动作和核对节点。节点是双方实际确认的安排，不照抄固定天数。修订后引用新的交付版本，按原用例复测；环境不同则记录差异。仅收到修复说明，不能直接把问题改为已解决。

追加复测日期、执行人、结果和残留问题，保留原签收及意见版本。涉及付款、责任或权利保留的具体文字，由双方结合合同核对，必要时寻求专业意见。记录的目的在于明确事实与未决范围，不预设签字就放弃权利，也不保证写了保留意见就产生某种法律结果。