FDE 项目怎么验收？一份可执行的验收标准清单

结论先给：验收标准必须在项目启动前书面确定；交付当天再谈，它就不是标准，而是争议。 一份能用的标准要说清三件事：用哪份数据衡量、按什么口径判定、谁有权说“通过”。下面按功能与效果、系统与集成、组织与使用三组给出清单，文末附模板与失败信号清单。

关于验收的抱怨高度一致：客户一句“这里再改一下”，验收就得往后推；一屋子人开会，只要有一个人提出问题就没人签字 —— 签了字，出问题就找他。这不是人品问题，是结构问题。

为什么验收一定会扯皮

标准没有前置。 合同写的是“完成开发”“效果达到预期”。双方到签字那天才第一次对齐语义，而筹码已经变了：系统做出来了，尾款还没付。

没有可测量的口径。 合同写了“准确率不低于 90%”，却没写在哪份数据上测、谁标注、分歧谁裁定。换一份数据，90% 能变成 60%，也能变成 98%。

没有人对“完成”有定义权。 没有唯一责任人的验收会是最“安全”的结构：提问的人不担成本，签字的人担全部责任，于是没人签字。

代价可以量化：超过 60% 的企业 AI 尝试停留在试点阶段。停下来的不都是技术做不到：有一部分是没人能定义“做完了”，项目只能挂在“还在优化”的状态里，不能验收，也不能停。

清单第一组：功能与效果

1. 评测集双方共同确认，独立于开发过程。 覆盖常规样本、边缘情况、明确反例；每条样本的判定要能回答是/否，需要分档就写清处置 —— 低于哪个值算不通过，而不是“继续优化”。
2. 冻结时间写进合同。 启动前冻结，之后新增样本归入下一版；否则总能找到新的失败样本，验收永远结束不了。
3. 谁保存。 甲方保存冻结版本，双方各留带校验值的副本；修改要记录版本、时间、原因、同意人。
4. 留一个基线。 用同一批样本跑一遍现有人工流程并记录。比的是相对基线的改善：要求“AI 必须比人准”，会否决掉很多值得做的项目。
5. 写清哪类失败不可接受。 某类样本上系统性出错是阻断性缺陷；长尾样本偶发出错通常是可以带着上线的已知限制。

清单第二组：系统与集成

判断标准只有一条：甲方的人能不能在没有原开发者的情况下跑下去。

1. 监控与日志。 谁能不看代码就回答“处理多少、失败多少、失败在哪一类”；日志存哪、留多久、谁能看。
2. 评测套件。 作为可重复运行的交付物交出；验收条件之一是甲方的人独立跑通一次，而不是看演示。
3. 集成逻辑。 接口清单、权限申请路径、重试与降级行为写进文档；不接受只有原作者知道怎么改的实现。
4. 运行手册。 出问题谁看、看什么、何时升级，以及已知失效模式与对应处置。
5. 成本模型。 单次处理的计算与许可成本、月成本随处理量变化的曲线；交一个甲方自己能算的公式，不是一个总数。
6. 持续运行的归属。 部署只占约 20% 的成本，另外 80% 是让系统在模型升级、数据漂移和边缘情况中持续运行（Computerworld 报道中 Solidroad 的 John Sangyeob Kim 口径，参考后续 18 个月）。多数合同只给第一部分定价，标准里要写明这 80% 归谁。

清单第三组：组织与使用

1. 把用者的名字写下来。 不是“业务部门”，是岗位和人；培训的验收条件是他能独立完成一次完整操作，包括出错处置。
2. 维护责任人。 甲方第一响应人、供应方第二响应，名字落在文档里。
3. 三个月回看。 第 30、60、90 天各看什么指标、谁组织、什么结果触发什么动作（继续、调整、停用）。
4. 允许“停用”写进标准。 如果上线后确实没人用，谁判断、何时判断、怎么处理 —— 这比假装它一定被用下去便宜。
5. 范围变更的入口。 谁有权提新需求、走什么流程、对工期和验收的影响怎么算。验收会不能同时是需求评审会，这是最常见的失控原因。

验收会怎么开

谁在场。 三类人缺一不可：有权当场签字的人（不是“回去汇报”）、每天用系统的人、能判断技术实现的人。缺第二类签完字没人用，缺第三类会陷入“这算不算 bug”。

别让签字变成全体一致。 设一个唯一责任人，通常是用者所在部门负责人。其余意见分两类：阻断性缺陷（对照标准没做到，有复现路径）、非阻断意见（记录，进入下一阶段，不延长验收）。

每个问题当场归类。 会上问题只有三种：缺陷（标准要求了但没做到）、新需求（走变更）、误解（当场澄清），由唯一责任人裁定并写进纪要。三类混着讨论是最常见的失败：一个新需求足以让验收推迟一个月。

给一个期限和默认结论。 例如提交验收后 5 个工作日内未提交书面阻断性缺陷即视为通过 —— 这比任何催促都有效。

一页纸模板

项目：                          验收日期：
本次验收范围（写明不在范围内的场景）：
唯一签字责任人（姓名 / 岗位）：

一、评测集
  位置：            版本或校验值：          冻结日期：          保存方：
  判定口径（每条样本如何判是/否）：

二、指标与基线
  | 指标 | 基线（当前值） | 目标值 | 测量方式 | 数据来源 |

三、交接物（交付日期与甲方独立验证方式）
  [ ] 监控与日志    [ ] 评测套件    [ ] 集成逻辑与接口文档
  [ ] 运行手册      [ ] 成本模型

四、结论
  [ ] 通过    [ ] 有条件通过（阻断性缺陷关闭后自动通过）
  [ ] 不通过（写明依据的条款）

五、遗留与回看
  非阻断意见：
  第 30 天：          第 60 天：          第 90 天：
  维护责任人：甲方              供应方

这八条信号说明验收会变成扯皮

1. 到了交付日，标准还是“效果达到预期”这类形容词。
2. 评测集是验收前一周由供应方单方面整理的。
3. 会上问题一半以上是第一次出现 —— 过程里没有阶段性验证。
4. 要签字的人不是用系统的人，而且他要“回去汇报”。
5. 有人当场提出范围外的新需求，并被要求当场给工期。
6. 没有人能回答“上线后由谁维护”。
7. 讨论里反复出现“这块再优化一下”，无法判定完成与否。
8. 验收会开过两次以上，每次结论都是“下次再看”。

命中三条以上先别开会：重写标准比再开一次会便宜。

常见问题

验收标准什么时候定？ 签合同前写好，最晚不晚于启动会。技术方案可以改，标准的口径不要改；“上线后看效果再定标准”的项目，最后都在争论标准。

PoC 验收和生产验收能合成一次吗？ 不建议。PoC 回答“值不值得继续投入”，标准是验证性指标加否决条件；生产验收回答“交付是否完成”，标准是三组清单。合并后，本该停下的项目会因为“验收失败”这个选项不存在而继续花钱。

提出验收后一直不给结论怎么办？ 先分清是阻断性缺陷（修）、新需求（走变更），还是没人愿意承担签字责任（组织问题，回到唯一责任人这一条）。同时在合同里写默认条款：约定期限内未书面回复视为通过。

---

验收标准不是防着谁，而是把“做完了”从形容词变成条款。我们的习惯是启动前把这份清单填一遍：填不出来的格子，通常就是后来延期的地方。

不确定该不该做，可以先看《FDE 是什么？前沿部署工程师完整指南》与《FDE 和外包到底有什么区别》。想了解交付方式，见我们的交付方式和 FDE 外包服务；有具体场景欢迎联系我们做一次诊断。