企业 AI 交付的五个协作接口：字段级清单与验收硬线

企业 AI 交付的五个协作接口：字段级清单与验收硬线

企业 AI 项目最常见的失败形态不是跑不起来，是跑起来了没人用。系统在线，接口正常，监控没报警，业务侧的实际操作仍然停在旧流程上。这种状态在合同里不算失败，在财务上也停不下来，只能一天天耗着。

把这类项目切开看，断点不在模型、不在工程实现，多数落在五个协作环节上：需求怎么翻、决定谁来做、数据怎么给、验收怎么签、知识怎么交。这篇按工程规范的方式处理这五件事，每个环节给出可填字段、判定口径和出错信号。视角仍是甲方推进侧，不涉及具体技术选型。

一、先界定：这里的接口不是 API

先说清概念，否则后面全部走偏。

▸ 协作接口：甲乙双方之间固定下来的交换动作，形态是一份文件、一次签字、一个响应时限。它的作用是把口头共识变成可追溯记录。

▸ 技术接口：系统之间的数据交换通道，形态是 HTTP 接口、消息队列、文件同步。它的作用是让数据流动。

两者容易混，因为都叫接口，都需要提前定义。区别在于失效后的表现：技术接口失效，监控会报警，日志里能查到 4xx 或超时；协作接口失效，没有任何报警，只表现为进度正常而业务不用。

一个项目的技术接口通常有人负责，协作接口通常没人负责。这是本文要解决的问题。

判断一个协作接口是否成立，只看四个问题能不能给出确定答案：谁做、什么时候交、交什么、谁签字。四个问题里有任何一个答不上来，这个接口就是空的，哪怕开过三次会。

二、五个接口与交付物的总览

接口	归谁（落到人）	交付物	关键字段数	失效后的可观测信号
1 需求	唯一业务对接人	场景定义卡	5	会上反复改口；对方方案出现甲方没写过的流程
2 决策	一号位或书面授权人	决策清单	3 + 时限	等"上面"答复超过一周；决策散在多个群聊
3 数据	IT 或数据 Owner	数据接入清单	4 列	首周就要全量数据；反复"再补一点"
4 验收	甲方业务对接人（唯一签字人）	验收节点表	6 列	只有上线验收；标准写成"好用""智能"
5 交接	甲方指定接手人	交接清单加归属说明	3 类资产	撤场后无人敢改；文档只有截图没有规则

顺序不能乱。需求没定，验收就没有可核对物；决策没定，验收就没人敢判；数据没定，验收就没有依据；交接没定，验收完就进不了下一段。五个接口是依赖链，不是并列清单。

三、接口 1：需求接口，场景定义卡的五个字段

归谁：唯一的业务对接人，具体到一个名字。写成"业务部门对接"等于没有对接，因为部门不会复述场景，也不会在出错时被追责。

动作：把业务诉求翻成四问。输入是什么（哪些单据、哪个系统、日均多少条）；输出给谁（哪个岗位、什么形式、看哪一栏）；判断标准是什么（什么算对、什么算错，各举三个真实例子）；例外怎么办（拿不准时走谁）。

字段	必填内容	判定标准	常见填错
输入源	单据类型 + 系统名 + 日均条数	数字可核，能对应到一个可导出对象	写"客户数据"，无法定位
输出物	形态（表单/字段/结论）+ 交付位置	有明确的落点，不依赖口头转述	写"一个智能助手"，无落点
使用人	岗位名 + 具体人数	能说出这个岗位现在怎么干这件事	写"业务人员"，范围过宽
判断标准	正例 3 个 + 反例 3 个	例子来自真实单据，可回查	写"准确率要高"，不可判
不做什么	明确排除项，至少 3 条	每条能对应一个具体的越界请求	留空，或写"视情况而定"

第五栏是这份卡的价值所在。范围膨胀型项目的共同特征不是对方贪多，是甲方没人有权说"这个不做"。把排除项写在纸上，等于提前把拒绝权落到了文件里。

验收口径：让对方复述你的场景，用词和你一致。注意方向，不是你听懂他，是他听懂你。他复述时如果自动换了一套说法，那套说法就是他理解的需求，两周后会出现在方案里。

四、接口 2：决策接口，三项权限与响应时限

归谁：一号位，或书面授权的一个人。授权必须落在文件上，靠默认生效的授权在出现分歧时一文不值。

只有三件事必须甲方定，其余可以下放：这一期做什么、不做什么（场景边界）；什么算过关（验收口径）；要改哪个岗位的动作、由谁通知到人（流程变更授权）。

决策项	决策人	响应时限	记录位置	越界的表现
场景边界	一号位或授权人	2 个工作日	决策清单第 1 条	第三版方案比第一版多出四项功能
验收口径	同上	2 个工作日	决策清单第 2 条	验收前一天还在讨论"什么算通过"
流程变更授权	同上	3 个工作日	决策清单第 3 条	岗位动作改了，只有项目组知道

验收口径：每个迭代周期有且仅有一次正式决策记录。注意"仅有一次"的含义不是不许改，是任何改动都要落在同一条记录上，形成版本，而不是散在七八个群聊里各说一句。这一条能直接决定项目后期是否陷入"当初到底说好的是什么"的追问。

响应时限建议写具体数值。写"尽快"等于没有时限，而等项目的一方在等待时，工期仍在消耗。

五、接口 3：数据接口，最小必要字段与授权粒度

归谁：IT 或数据 Owner，同样落到人。写"IT 部门"会出现一种典型僵局：每个 IT 都认为这事该别人批。

三条原则：

▸ 按场景列字段，不按系统打包给。 打包给的结果是授权范围过大，审批卡住，最后给了一批用不上的数据，真正需要的字段仍然缺。

▸ 给法三选一，写明更新频率。 接口对接、定期导出文件、脱敏副本，三种方式的运维成本与合规风险不同，选定一种并写清频率（每日/每周/按需）。

▸ 一次授权覆盖一个场景。 不要让业务每次要数据都重走一遍流程，否则接口会退化成人工审批通道。

列	填写要求	示例粒度	出错信号
字段	字段名 + 类型 + 是否必填	投诉单号、受理时间、结案状态	只写"客户信息"
来源系统	系统名 + 表或接口位置	工单系统的结案表	写"内部系统"
脱敏规则	脱敏方式 + 保留位数	手机号保留后四位，姓名保留姓	空白，或写"按公司规定"
授权人	姓名 + 授权日期 + 有效期	张三，2026-09-01，本场景有效	写"已获批准"

验收口径：场景跑完之后，你能说清用到哪几个字段、谁批的。说不清就是没管住。这一条同时是合规检查的入口，一旦出事，这四个信息就是全部凭据。

另有一类高频问题：同一个词在不同部门口径不同。"客户"在销售那里指签约主体，在客服那里指来电人，在财务那里指付款方。这类差异必须在接入清单里显式区分，否则后期对不上数，会被误判为模型问题。

六、接口 4：验收接口，六列节点表与硬线分级

归谁：甲方业务对接人是唯一签字人。服务商只举证，不表决。这一条在会议纪要由对方撰写、通过与否由对方汇报的流程里，会迅速失效：三个月后甲方发现自己只负责点头，而点头已经被当作验收结论。

列	填写要求	不合格写法
节点	时间段 + 该段目标	写"第一阶段"
可核对物	第三方可复核的实物	写"完成汇报"
硬线项	1 到 2 项，不过不进下一段	列七八项全部必过
通过标准	可计算或可判定的阈值	写"好用""智能""满足需求"
整改与复核日	带条件通过时的整改内容 + 日期	只写"待优化"
签字人	姓名 + 职务	写"项目组"

硬线为什么要分级。 把每一条都设成一票否决，实际结果不是质量更高，是每个节点都过不去，项目死在流程里；另一条路径是为了推进，签字时把标准逐项解释掉，最终一项也没守住。合理配置是每个节点只设一到两项不过就不进下一段的硬性要求，其余允许带条件通过，但必须写清整改内容与复核日期。

值得列为硬线的通常是三类：权限边界、数据合规、能否关停。这三类出事不是返工能解决的。

可核对物的判定。 截图不算，进度汇报不算，会议结论不算。算的是日志、单据、前后对比表、测试集通过率。一个简单的自检：这个东西换一个没参与项目的人来看，能不能独立判断通过与否。不能，就还不是可核对物。

节点表的版本管理。 这张表在项目周期内会改，改动本身不可怕，改动无记录才可怕。建议三条约定的写法：每次修改单独升版本号，保留上一版；修改必须写明触发原因（是变更单还是判定标准调整）；已签字的节点不因新版本而回溯失效，除非变更单明确标注需要重算。这三条的目的只有一个，让"当初签的是什么"在任何时点都能被复原。缺了它，验收节点表会变成一份反复覆盖的文档，事后无法作为依据。

签字栏的写法。 写姓名加职务，不写"项目组""业务方""双方代表"。原因很直接：验收记录的价值在于可追溯，而组织名称无法被追问。实操中还有一个细节，签字只需要一个人，不需要凑齐多个部门。多签的结果通常是责任分散，谁都能说这不是我定的。

七、接口 5：交接接口，三类资产与可迁移性判据

归谁：甲方指定的接手人，签合同时就该有名有姓。等项目结束再找人，实际结果是没人接。

资产类别	具体条目	归属需写明	可迁移判据
数据与知识	语料、标注结果、评测题目、字段字典、脱敏规则	归甲方 / 归乙方 / 共有	能否导出为通用格式并复现评测
判断规则与工作流	何种情况给何结果、哪些必须人工复核、异常路径	归甲方	接手人能否解释"为什么这么定"
评测与监控基线	可重复跑的测试题、当前通过率、告警阈值与阈值来源	归甲方	换供应商后能否用同一套题对比新旧效果

三类资产里最容易漏的是第三类。前两类看起来是"交付物"，第三类是"能力基线"，没有它，甲方无法判断换人之后变好了还是变差了，也无法判断日常波动是正常还是异常。

统一判据只有一句：换一家供应商，这三样能不能带走、能不能读懂。带走但读不懂，等于没交；读得懂但带不走，等于被锁住。

八、跨接口的三个结构错位

上面五个接口解决的是"动作固定在谁身上"，但错位的成因在结构层。不认这一层，接口会被当成填表任务。

▸ 信息错位。现场信息在甲方，专业判断在乙方。乙方进场能看到的只有甲方愿意给的部分。IT 说数据不能出库、业务说客户名单不能外流、销售说这批客户分类与系统不一致，这些约束如果在第一周没有变成文字，乙方只能按最理想的假设设计。

▸ 激励错位。乙方收入按里程碑结算（合同签、方案过、系统上线），甲方收益按业务指标结算（处理时长、错误率、岗位负荷）。两个节点之间通常隔两三个月。这段时间里乙方有动力尽快上线，甲方有动力再改一版，双方都不算错。

▸ 语言错位。乙方交付的是模型指标（准确率 92%），甲方需要的是岗位动作（这类工单不用人工复核）。中间缺一层换算：92% 落在哪几类单子上，剩下 8% 由谁兜。不换算，验收必然各说各话。

对策不是加强沟通。沟通解决态度，错位是结构，结构只能靠固定动作解决，而固定动作就是前面五个接口。

九、90 天里程碑与甲方投入档位

给一个可执行的节奏。用 90 天试点模型做骨架：1-15 诊断选场景、16-45 PoC、46-75 上线、76-90 复盘。四段是双方的对表节点，不是乙方的施工进度表。

档位	场景数	周期	业务对接人	IT 或数据接口人	决策人	走的节点
轻量验证	1	4 到 6 周	30% 工时	10%	每周 30 分钟	节点一至二，三与四合并收尾
标准交付	2 到 3	8 到 12 周	50% 工时	30%	每周 1 次	完整四节点，可压间隔不减节点
多场景并行	4 以上	90 天以上	每场景各 1 名	专职 1 名	每 2 周 1 次	完整四节点，按场景并行

一个反直觉的结论：宁可把场景做小、档位降一档，也不要按高档签约、按低档配人。范围按标准交付签、人按轻量验证配，是第三周开始欠账的典型起点，而且欠的账会在节点三集中爆发。

对接人中途换岗的，接手人应在一周内读完场景定义卡与决策清单并签字确认。不签，前面定下的口径会在交接中走形，且无法追溯是谁改的。

十、失败模式对照

症状	断掉的接口	处置动作
每次汇报都在讲新功能，说不清当前版本含什么	2 决策	补齐排除项，明确拒绝权归属
能演示，业务说不是这个意思	1 需求	回到场景定义卡，重填判断标准三正例三反例
进度正常，业务就是不肯用	3 数据	核查字段口径与更新频率，检查是否有未登记的手工补数
有上线会，没有验收会	4 验收	拆四节点，先补节点一与二的记录
撤场后没人敢改一条提示词	5 交接	按三类资产重做交接，补评测基线
同一问题在不同会上有不同答案	2 决策	建立单一决策记录，禁止群聊口头确认

十一、政策背景与边界

政策文件里先给这类扎在现场的角色一个名字：FDE（前线部署工程师）。名字出自文件，职责由项目定义。工信厅科函〔2026〕414号（2026 年 8 月 27 日发文，2026 年 8 月 31 日官网发布）提出服务商应扎根用户现场、保障场景落地，同文提及"小快轻准"的产品服务方向。这两句话通常被读作对服务商的要求，但现场是甲方的地方：门开不开、数据给不给、流程改不改，三件事服务商都决定不了。落到执行层，它要求的是双向动作。

需要说明的是，这是政策背景，不是资质认定。文件讲的是资源池摸排建档与专项行动，不是牌照，也不构成对任何机构或个人的服务资质认定。

十二、结论

五个接口的交付物加起来不超过五页纸：一页场景定义卡、一张三项决策清单、一张四列数据清单、一张六列验收节点表、一份三类资产交接清单。都不需要工具，都不需要预算。

真正难的只有两件事：在没有外部压力时把它写下来；在有人推着往前走时，坚持"没签字就不进下一段"。

三句判断留在这里：只有最后一次验收的项目，等于没有验收 ；验收单最值钱的不是通过率，是哪一条没人肯签字 ；任何不落在纸上的变更，最后都会变成扯皮的材料。

如果第一份文件就填不出来，问题不在文件。多半是这个场景还没有诊断清楚：这件事现在要多久、错多少次、谁在干，三个数说不出来，后面所有字段都只能填口号。这就是先诊断，再落地的含义。

唐欢（弯弯）｜企业AI落地顾问 让企业把 AI 真正用到业务里

弯弯的产业AI实战