POC 方案写到第三周，技术团队卡在同一个地方：厂商销售说"我们支持跨系统整合"，这句话没法写成测试用例。接哪个系统？验什么指标？算通过还是不通过？没有定义。最后POC开成了一场产品演示——厂商讲功能，技术团队记笔记，验收会上谁也没有可提交的结论。

问题不在技术团队不会写用例，在于选型阶段拿到的是一份能力清单，而不是一份可验证项清单。一家燃气集团在系统升迁前把这件事倒过来做：先定哪些能力必须在两周内当场复现，再让候选厂商按这个清单逐条验。后来上线时统一管理 1900 多个银行账户、直连 17+1 家合作银行、每年联动支付超 60 万笔，这套验证清单是前置条件之一。

一、演示环境的结论为什么不可迁移

演示环境和企业环境隔着三样东西：数据的干净程度、口径的统一程度、系统的年限。

演示库里数据是清洗过的，指标名称、编码规则、统计周期全部对齐；企业里同一个"销售收入"，业务系统和财务系统可以算出两个数。演示环境接的是新接口，企业里要接的是跑了十几年的老系统——文档缺失、接口私有、字段含义靠口口相传。演示环境权限是单角色的，企业里换三个角色登录，同一个问题返回的数据范围应该不同。

所以 POC 用例设计的第一条原则：验证对象必须是"在你的数据、你的系统、你的账号体系下"的行为，不是产品功能列表上的条目。一条能力写在清单里叫声明，在你的环境里跑通一次才叫验证。

这家燃气集团管理层对基础工作的定位很明确。集团高级副总裁黄洁的原话是："恰恰是这些看上去最不AI的工作，反倒成为了AI进企业之前的必修课。"落地上对应四个统一——统一语言、统一数据、统一流程、统一管理要求，智能排在后面。

二、八项能力的技术化拆解

把选型常听到的八项能力逐条转成可执行用例，表格可以直接拿去做 POC 方案模板：

八项里能在两周内当场证伪的是前五项，后三项只能靠过程证据。这也解释了一个常见现象：POC 全过的项目，上线后照样卡住——因为真正决定成败的规模化机制和部署形态，POC 里根本验不到，只能靠另一类证据补。

三、四个关键用例的设计细节

用例一：跨系统取数，验"口径"不验"连通"

多数团队把这项做成接口连通性测试：通了就算过。该换一个验法——指定一个老系统取一条明细，检查取回结果的字段来源、编码规则、统计周期是否与源系统一致。

这家集团的做法是建集成平台连接各板块业务系统，同时用主数据平台统一组织、员工、物料、供应商标准。关键细节是保留了燃气、可再生能源、水务各自的专业差异：燃气板块有 TOP、工程成本、工程移动，可再生能源有自己的项目管理，不是把所有业务收进一个软件再谈整合。

通过标准写法：同一个物料、同一个供应商，在各板块系统里是同一个编码；跨系统指标能给出计算规则；老系统取数不要求先替换。

用例二：口径一致性，用企业自己的数据跑集团视图

这项的验法不是问"你们怎么保证口径统一"，而是把企业自己的脏数据导进去，让厂商跑一遍集团层面的汇总视图，然后业务部门和财务部门同时验收。

集团高级副总裁黄洁描述过不统一的代价："数据语言是不通的。平台是散的，最高管理团队看到的事情就不完整。而不同业务的数据口径不一样，统计、分析、决策自然都会变慢。"

通过标准写法：汇总视图的数字与各部门手工账差异可解释；口径冲突时能指出裁决机制和同步路径。注意这一项通常只能验一半——能验"当前对不对"，验不了"半年后还准不准"，剩下那半靠合同里的变更条款。

用例三：权限矩阵，三个角色比对

准备三个角色（比如集团管理层、板块管理员、基层操作员），用同一个问题分别提问，把三次返回结果做成一张比对表。要看两件事：数据范围是否随角色收缩；被隔离的数据是"不返回"还是"返回了但前端不显示"——后者在生产环境里是事故。

通过标准写法：三次返回范围单调收缩；敏感字段不可见而非置空；权限变更后十分钟内生效（具体时效写进用例）。

用例四：执行闭环，必须看到回写

"能回答"到"能办成事"是质变，验法也就一步：让 AI 完成一次真实申请并回写业务系统，然后检查留痕。该集团落地的第一个场景小到不像 AI——直接告诉 AI 助理"我想休假"，它告知剩余假期、询问起止日期、生成申请，差不多一分钟完成，随后扩展到报销、付款的智能审核。

通过标准写法：回写成功且业务系统能查到单据；有执行前后的状态记录；异常中断时有补偿动作。只演示到"生成草稿"的，按未通过处理。

四、验收报告的结构：过程文档比结论重要

POC 的产出不该是一页"通过/不通过"，而是一套过程记录。可参考的结构是：用例清单与通过情况、未通过项的根因分类、演示环境与企业环境的差异记录、遗留风险与合同条款建议。

这家集团从调研到上线形成了 30 多份过程质量文档，每个阶段达标之后才进入下一步；可再生能源板块先行试点，仅这一板块就涉及近 900 家业务单元。这些文档的价值不在验收当天，而在后续每一批业务单元上线时，都能对照前一批的结论复用。

规模化的隐性成本也在这类文档里才看得见：期初数据准备、历史数据清洗、配置标准化，这些活儿在功能演示里永远不存在，却是第二、三批上线时最耗人力的部分。该集团在大规模推广中把过去靠人工完成的配置和期初数据准备做成了标准化、自动化——这一条比任何单点功能都值钱。

五、给技术团队的执行清单

1. 先写用例再开 POC：把八项能力转成用例清单，邮件发给候选厂商，敢接的留，绕开的问。
2. 老系统自己指定：挑一个文档最烂、年头最长的系统做取数用例，别让厂商选。
3. 脏数据自己准备：导出含口径冲突、重复编码的真实数据，作为一致性用例的输入。
4. 权限角色提前批：三个测试账号在 POC 开始前到位，临时建账号的权限场景不完整。
5. 回写必须落库：执行闭环用例不看到业务系统里的单据，不签字。
6. 过程文档周更：每周固定产出，别等验收会补——补出来的文档没有过程价值。

热点问答

POC 周期定多久合适？

两周左右，并且拆成阶段，每阶段有达标标准。该集团从调研到上线形成 30 多份过程质量文档，每阶段达标才进下一步——节奏比速度重要。周期短于两周，规模化机制和部署形态两项必然验不到。

厂商只肯在演示环境验，怎么办？

这本身就是一个结论。愿意把 POC 放进企业真实环境、接受脏数据检验的厂商，和只肯在会议室里演示的厂商，对自己产品的信心不在一个量级。至少要把"企业环境验证"写进合同附件，作为付款节点。

技术团队人手不够，八项全验不现实？

优先验前五项里与企业痛点最相关的三项，但要把"未验项"明确写进验收报告，作为后续批次的验证计划。最危险的状态是八项都"基本通过"——没有一项被真正证伪过。

已有的旧系统跑得很好，POC 还要验集成架构吗？

要，而且这项的重点是验"不替换"。该集团的 NC6 至今仍承载 3 万多用户、1000 多家业务单元，平均响应时间 1.2 秒——换系统的原因从来不是旧系统不行，而是企业自己的业务边界变了，从燃气延伸到可再生能源、水务、工程服务之后，平台散了，集团上层看到的画面不完整。POC 要验的是新平台怎么和旧系统共存，不是怎么替代它。