交付前最怕漏项，让 AI 拿清单逐条对一遍

我见过不少项目，出问题的不是技术难度，是「以为有人管」。合同里写了三次现场培训，实际排了两次；说好交付时给一份操作手册，交完才想起来手册还没写；客户在第三次会上提过一句「我们这边要双人复核」，这句话没进纪要，最后验收时成了硬伤。

这些事有个共同点：不是做不到，是没人把它当成一条需要打勾的条目。项目越大，这种条目越多，越依赖某个人的记性。

交付前的检查，比的不是谁细心，是谁手里的清单更完整。

这篇讲交付质检这个岗位：它对照什么、喂它什么、五步怎么走，以及哪三句话它说了不算数。

先把边界划清楚。它不做质量判定，不签验收单，不替项目负责人决定「这个能不能过」。它只干一件事：把合同、订单、会议纪要里所有对客户的承诺抠出来，摆成一张表，逐条对现在手上有什么、还差什么。

它的唯一结果是：每一条承诺都能找到对应的交付件，或者明确标成「缺」。注意是「能找到对应」，不是「应该没问题」——后者是一种安慰，前者是一个证据。

为什么非要把这条边界划死？因为一旦让它承诺「保证验收通过」，它就会开始帮你把缺的说成不重要的。等到验收桌上客户提起那一条，你已经没有时间补了。

五类材料。少一样，它就只能在文件表面打转，检查不出真正会卡住验收的东西。

这五样里真正决定成败的，是第五样。合同是标准文本，写得很全；客户真正的在意点，往往藏在某次会上的一句补充里。这类话必须被摘出来、写进清单，否则它就只存在于当时在场那三个人的记忆里。

历史问题这一类常被省掉，其实性价比最高。同一个行业做过的项目，验收时被挑的毛病高度相似。把过去三年的验收问题汇总一遍，本身就是一份现成的检查表。

硬纪律：每条承诺都要标出处——合同第几条、哪次会议、谁说的。指不出来源的，一律按「待确认」处理。

流程五步：收齐交付件、抠出承诺、逐条比对、标风险、出确认单。

第一步收齐交付件，看似简单，实际经常卡住。要的不是「大概都在这儿」，而是一份明确的目录：哪几份文件、什么版本、什么时候交的。文件名里带日期，是这件事最省力的做法。

第二步抠出承诺，是整个岗位最见功夫的一步。合同里明写的容易找，难的是那些以「配合」「协助」「根据需要」开头的话——这些词看着软，验收时最硬。

第三步逐条比对，只允许三种结论：已交、未交、交了但不符。不允许写「基本完成」，这四个字在验收桌上没有任何意义。

第四步标风险，重点标两类：一类是补起来要时间的，一类是补起来要客户配合的。前一类今天就得动，后一类今天就得开口问。剩下的可以按常规排。

第五步出确认单，一页纸，交给项目负责人。这一页纸上只该有两个数字：还有几条没闭环，其中最晚的一条什么时候能闭环。数字比形容词有用得多。

这段直接复制去用。留意第七条——让步接收必须交回给人，这是这条流水线唯一的出口。

第五条最容易被忽略。检查做完不落到一页纸上，它就只是一次内部讨论，讨论完了谁也不会照着动。

它能把清单摆全、把缺口标出来，但下面三句，它没有资格替你开口。

第一句：「这个客户不会在意。」客户在意什么，只有客户能回答。用这句话跳过一条承诺，等于替客户做了决定。

第二句：「这条其实已经算完成了。」算不算完成，看的是验收标准，不是交付方的心情。差一个签字、差一次培训，就是没完成。

第三句：「延期两天问题不大。」影响大不大，取决于客户那边的排期，不在你这边。这话该由项目负责人去跟客户谈，不是写进内部检查表里。

说到底，交付质检这活的价值不在查出多少问题，在于让「还差什么」在还有时间的时候被说出来。等到验收桌上一段段翻，查得再细也没用了。它负责把缺口摆上桌，你负责决定补还是谈。