同事在群里说“已发，请查收”，接收者回“收到”，这只能说明消息被看到，不能说明交付物已经能用。一次交付应把提交、检查和接受三个状态分开：谁提交了哪份东西，谁按什么标准检查，最后是否满足当前用途。以下方法适用于总部IM等团队聊天场景，使用普通文字就能执行，不依赖客户端自带审批或任务系统。
一、检查前先确认，这次究竟验收什么
从原先约定的用途和范围中选出可观察的标准，避免临到提交才追加要求。例如“准备一份门店培训讲义”还不够明确，可以补为“面向新入职店员，包含开店准备、接待流程和异常上报；交付可编辑源稿及供阅读的PDF，由培训负责人确认内容”。这只是示例，实际标准应由双方事先商定。
如果双方对“做得好”的理解不同，先看一页样例或一个小范围结果，再完成全部内容。样例可以帮助对齐格式与深度，但不等于其余内容自动通过。没有约定的新增内容应另行讨论，不能直接按原任务漏交处理。
先把用途、范围和检查标准放到一起（原创示意图）。
二、提交消息里写清版本、入口和已知缺口
不要让接收者在多条消息里寻找“最终版”。一条提交消息可以写成：“【提交检查】门店培训讲义v0.3，文件名《新店员培训_20261016_v03.pdf》，源稿与PDF已放在约定资料位置。本轮补齐接待流程；异常联系人名单仍待运营确认，已标注。请培训负责人检查流程是否完整，计划10月19日17:00前反馈。”
这里的时间是示例。正式提交时写明实际检查人和双方能接受的反馈节点；不要直接替对方承诺完成时间。资料含客户或员工信息时，按获准范围交付，不为省事发给整个群。产品的文件限制和权限能力需按实际版本确认，可参阅本站功能介绍。
三、接收者按三层检查，别只看能否打开
第一层是拿得到：接收者能否在其实际设备和账号下找到并打开正确版本。提交者自己能打开，不能代替接收者的验证。第二层是内容对得上：是否覆盖约定范围，关键日期、数字、引用和联系人是否仍有效。第三层是用得起来：例如培训讲义能否按顺序讲解、PDF是否缺页、源稿能否按约定方式修改。
按用途选择必要检查即可，不必把每次小交付变成全面审计。无法完成某项验证时，说明“未检查”和原因；不要把“没有发现问题”写成“所有内容保证正确”。
可访问、符合范围、适合用途，是不同的检查问题（原创示意图）。
四、退回时写可复核的问题，不只写感觉
“不够专业，再优化”很难执行。更有用的写法是：“第4页异常上报没有写接收角色，与已约定的范围不符；请补上角色及非工作时段的联系办法。第7页有一句措辞建议，属于可选优化，不影响本轮接受。”把必须修正与可选建议分开，提交者才能安排顺序。
问题说明保留位置、观察到的现象、预期结果和本次影响。能用虚构样例说明的，不附真实客户数据。若反馈实际上改变了原用途，例如从内部培训改为对外材料，应重新确认范围和排期，而不是要求对方无限修改。
说明问题在哪里、为什么影响本次使用、怎样判断已修好（原创示意图）。
五、明确接受范围，并安排剩余事项
最后的回复可写：“v0.4已按清单检查，开店与接待流程部分接受；异常联系人名单尚未确认，该部分暂不用于正式培训。由运营负责人补充后，培训负责人单独复核。”如果全部符合约定，就明确写“本轮交付接受”，同时指出采用哪个版本。
验收结论不等于可以公开资料，也不等于其他场景同样适用。把采用版本、未结问题和后续负责人放在同一条消息里，并按团队约定保存到可检索的位置。这样下一次有人问“这份能不能用”时，答案来自明确的检查记录，而不是一句含义不清的“收到”。