写了 118 个功能点的 AI 需求文档,为什么还是验收不了?

我做过一套工业系统，19 个页面、34 个接口、118 个功能点，一条一条从实机里抠出来，写成了一份需求规格说明书。

写完那天我没觉得轻松，反而有点凉：如果明天把这份文档交给验收组，他们大概率验收不了。

因为它写清了系统「应该做什么」，却没写清「做到什么程度算做到了」。

这不是文档水平的问题。工业 AI 项目大面积延期、验收扯皮、最后停在「能演示、不能上线」，根子几乎都在同一处——我们拿确定性软件的模板，去套一个概率性系统。

确定性软件的需求是布尔值：功能有或没有，点了有没有反应，通过或不通过。

AI 的需求是分布的：识别率 92% 和 96%，不是同一个产品的两个版本，是两个不同的产品，成本差几倍，适用场景也不同。

模板不改，验收就永远落在一句「感觉还行」上。而「感觉还行」在工业场景里，不是一个可以签字的结论。

一、三个根因

表 1　工业 AI 需求文档无法验收的三个根因

第三条值得单独说一句，因为它最反直觉。

漏掉一个端子，人工复核能补回来；认错一个端子并且给出高置信度，全流程没有一个人会去查——直到出事。所以工业 AI 的失败模式，不是「不够聪明」，是「错得很自信」。

而绝大多数需求文档，对这种失败模式一个字都没提。

二、写法一：每个需求条目必须是三列

功能清单之所以验收不了，是因为它只有两列：编号、描述。两列的表格只能表达「做没做」，表达不了「做到什么程度」。

把它拆成四列，问题会消失一大半。

不合格写法

AI-001　系统应支持自动识别图纸中的端子号与线号。

表 2　需求条目四列化模板

关键在第 4 列。我发现大多数文档根本没有第 4 列。

「拒答」应该是 AI 需求里的一等公民。一个不会说「我不知道」的 AI 系统，在工业场景里是不可用的——它必须有能力把自己不知道的东西交出来，而不是猜一个看起来合理的答案。

一个容易被忽略的连带效果：写了拒答条件之后，指标会「变好看」。因为最难的样本被合法地移出了分母。这不是作弊，前提是你同时写了拒答率的上限——比如「拒答率不得超过 8%，超过即视为能力不足」。两条一起写，才是完整的。

三、写法二：准确率必须分层，不允许只报一个数

「整体准确率 92%」是工业 AI 文档里最危险的一句话。因为工业场景里，不同错误的代价差两个数量级，而平均数恰好会把差异抹平。

正确的做法是分层，并且把三件事写死。

表 3　分层指标示例（数值仅说明口径，非真实项目指标）

分层之外，还有三件事必须在文档里明确，否则指标永远可以吵：

第一，分母是谁。 500 张图里 480 张含有端子，准确率的分母是 480 还是 500？这一句不写清，两个数字能差 4 个百分点，而且双方都能自证合理。

第二，测试集谁提供。 训练集可以由乙方出，测试集必须由甲方出、且乙方在验收前未见。否则测的不是能力，是记忆。

第三，字段级还是条目级。 一条记录里五个字段错一个，条目级算全错，字段级只算错了 20%。两个口径在实测里能差十几个百分点。这不是文字游戏，这是几十万的差价。

四、写法三：必须写一份「不可接受的错误」清单

这一节是我认为最值得直接抄走的部分，因为它在国内的工业 AI 文档里几乎是空白。

所有需求文档都在写正向需求，几乎没有一份写负向需求。但工业 AI 的真实风险全在负向。

表 4　负向需求（不可接受错误）清单模板

写这份清单的时候，有一个取舍原则必须先确定：宁可漏，不可错，还是宁可错，不可漏。

在人能兜底的环节，漏识别的代价是一次人工成本；在没人会复核的环节，错识别的代价是一次事故。所以阈值该往哪边偏，取决于下游有没有人。

这条原则没有普适答案，但必须在文档里明确选一边。选不出来，说明流程本身还没想清楚——这时候不该继续写文档，该去现场。

五、写法四：人机责任分界表

没有「复核人」这一列的需求，本质上是在要求系统自己承担责任。

而系统不能承担责任，只有人能。这是工业 AI 和消费级 AI 最大的区别：消费级 AI 错了，用户自己承担；工业 AI 错了，得有人签字。

表 5　人机责任分界表模板

三个字段缺一不可：置信度——没有置信度的 AI 输出，等于没有刻度的尺子；依据——能点回到原图的哪一处；复核入口——复核人从哪进、改完怎么留痕。

还有一句话建议直接写进文档：「AI 识别、计算与排查结论一律标注『辅助分析，需人工复核』，不进入安全级闭环，不替代保护逻辑，不直接下发控制指令。」 这句话看着像免责，其实是需求——它定义了系统的能力边界，而这正是 AI 项目最容易被含糊过去的地方。

六、三段可以直接抄的文字

6.1 验收准则的写法

不合格

系统应具备较高的识别准确率，满足生产使用要求。

合格

在甲方提供的 500 张测试图纸（覆盖三类图幅，不含手写修改图）上，端子识别准确率 ≥ 95%，线号识别准确率 ≥ 90%，端子排归属一致率 ≥ 98%；任一项低于阈值即本项验收不通过。测试集于验收前封存，乙方未见。

差别不在措辞，在三件事：把「高」换成了数字，把「生产使用要求」换成了可执行的判定条件，把「样本谁出、什么时候封存」写死了。

6.2 每个指标都要有公式

一致率 = 完全匹配的字段数 ÷ 应识别字段总数

然后紧跟一句限定：本条采用字段级口径，非条目级。

看起来很啰嗦，但这一行能省掉验收会上两个小时的争论。

6.3 遗留问题表的用法

表 6　遗留问题（待确认事项）追踪表

不确定的东西不要删，也不要用确定的句式写进正文，单独列表。

这不是拖延，是把不确定性显性化。我在自己的文档里立过一条纪律：凡界面未展示、资料未覆盖的口径，一律不写入功能描述，统一列入遗留问题。

原因是：写进正文的猜测，三个月后会变成「需求就是这么写的」；放进遗留问题的空白，三个月后会变成一次澄清会。

前者是债，后者是工作。你选哪个，决定了这份文档三个月后是资产还是麻烦。

七、一个反常识

写得越「完整」的 AI 需求文档，越容易验收失败。

因为「完整」通常是靠把不确定的地方用确定句式写掉换来的。每消灭一个【待确认】，你可能只是多埋了一个三个月的坑。

一份好文档的样子不是没有空白，是每个空白都有编号、有责任人、有关闭条件。

判断方法很简单：把文档里所有【待确认】标出来数一遍。如果数量是 0，这份文档大概率不可信——要么写的人什么都懂了（极少见），要么他把自己不懂的部分藏进了正文（很常见）。

八、最后一句

需求文档的最后一章通常是验收准则。这个顺序是错的。

应该先写验收：先问「什么算做成了」，再问「要做哪些功能」。因为功能清单可以无限膨胀，验收标准不能。先定后者，前者会自己收敛。

工业 AI 最难的部分从来不是模型，是「什么叫对」。

这件事模型答不了，只有既懂工艺、又肯把话说死的人能答。

而这恰好是过去几年最没人愿意认真做的一件事。

如果你也在写这类文档，欢迎把你卡住的那一条发给我。我们可以一起看看，它能不能被写成可验收的样子。

我的公众号同名：「需求翻译官」，每周一篇可抄模板，和模板背后的取舍逻辑。

—— 需求翻译官 · 先定义，再验收

边界声明： 本文所有示例均为脱敏改写，不含任何具体项目、机组、单位名称、设备型号与工程参数。文中出现的准确率、阈值、样本量等数值，均为说明口径而设的示例值，非任何真实项目的验收指标。文中所述方法基于工业仪控类信息系统的需求实践，向其他行业的迁移需结合本行业的安全分级与复核流程重新定义，不可直接套用。