用 AI 做项目验收材料：完整清单

「东西都做完了，材料你整理一下。」这句话一般出现在验收前一周，而它实际需要的时间是三个月。验收材料的难点从来不在写，在补：变更确认散在三个人的邮箱里，测试记录只活在群聊里，性能数据是三个月前跑的，环境早换了。AI 能帮你把清单列全、把结构搭起来、把对照表填好，补不回来的部分它也没办法。下面按四步走。

验收看的是证据链，不是交付物

交付物证明东西存在，证据链证明东西是按约定做出来的。验收方要签的那张纸，背后得能回答四个问题：约定的是什么、做了什么、怎么证明做到了、没做到的部分怎么处理。四个问题各对应一组材料，缺哪组，验收就卡在哪组。

多数项目在第三个问题上失分。功能演示能证明「能跑」，证明不了「在约定条件下稳定跑」；后者要靠测试记录、压测报告、缺陷清单。这些材料的共同特点是只能当场留，事后补不出来。

四步走完，从清单到答辩

四步的产出物一层比一层具体，前两步是找齐，后两步是说清：

第三步的对照表是整包里最值钱的一页。它的作用不是证明你做了，是让对方不用翻两百页附件就能确认。写法上一条要求一行，右边三列：交付内容、证据位置、遗留说明。遗留说明这一列别空着，空着等于告诉对方「这里有问题但我不想说」。

清单要按「谁签字」倒推

验收通常不止一个人签字：业务方确认功能，技术方确认指标，采购或财务确认合同条款履行。三方关注点不同，要的材料也不同。业务方要场景演示和操作手册，技术方要接口文档、测试报告、部署说明，采购方要变更记录和验收单。

所以清单的第一层不该按材料类型分，该按签字人分。分完再合并同类项，你会发现同一份测试报告出现在两个分组里，这很正常——它同时服务两个判断。让 AI 做这一步很合适：把项目简述、约定交付内容、甲方类型交代清楚，提问时该交代哪几类背景说得很清楚，交代到位它就能给出一份相当完整的初稿，你再按实际情况删改。

对照表怎么写才站得住

三个要点。一是逐条对应，约定的每一条都要有回应，包括那些「双方口头同意不做」的——口头同意也要落到纸上，写进变更记录。二是证据可定位，写「见测试报告第 12 页」而不是「有测试报告」。三是差异要写清，做到八成的地方就写八成，「已实现，边界条件下存在延迟」比「已完成」安全得多。

这份表也是自查工具。填到某一行动不了笔，说明那块要么没做，要么没留证据。两种情况都还有时间处理，前提是你在验收前一个月填，而不是前一天。

过程材料补不出来，这是最硬的约束

会议纪要、变更确认、问题处理记录，这三类材料的共同点是依赖当时的人和当时的语境。事后补写的纪要，参会人不认；事后补的变更单，没有对方签字；事后补的问题记录，时间戳对不上。验收方核对时看的就是这些细节。

把归档变成周例行的动作：每周五花二十分钟，把本周的邮件、纪要、变更、缺陷截图归到对应目录。让 AI 生成一份「本周该归档什么」的清单，比让它月底帮你整理有效得多。这件事的价值不在整齐，在于三个月后你还能证明当时发生了什么。

它能理全，不能替材料担保真实

模型会编。它编的往往不是整段材料，是那些看起来该有、实际没有的细节：一个不存在的测试轮次、一个凑整的性能数字、一条格式规整但没有出处的标准条款。这类内容混进材料里，风险比缺材料高得多——缺了是遗漏，编了是造假。

所以它生成的所有数字都要回到原始记录核对，模型为什么会一本正经地编造这件事决定了你不能靠「看起来合理」来判断。核对成本不低，但比返工低。想让它少编，可以把项目文档先喂进去再提问，基于取回材料作答的做法能压掉一部分凭空补充。另一条边界是责任：验收能不能过，取决于项目本身做没做好，工具只影响材料齐不齐、说得清不清楚。这一条没有例外。

速查：验收前该过的四道关

• 清单按签字人分三层，别按文件类型分。
• 每一条要求都要有一行对照，证据精确到页码。
• 所有数字回到原始记录，凑整的数一律重查。
• 归档放到每周五，别留到验收前一周。