POC 方案写到第三周技术团队卡在同一个地方厂商销售说我们支持跨系统整合这句话没法写成测试用例。接哪个系统验什么指标算通过还是不通过没有定义。最后POC开成了一场产品演示——厂商讲功能技术团队记笔记验收会上谁也没有可提交的结论。问题不在技术团队不会写用例在于选型阶段拿到的是一份能力清单而不是一份可验证项清单。一家燃气集团在系统升迁前把这件事倒过来做先定哪些能力必须在两周内当场复现再让候选厂商按这个清单逐条验。后来上线时统一管理 1900 多个银行账户、直连 171 家合作银行、每年联动支付超 60 万笔这套验证清单是前置条件之一。一、演示环境的结论为什么不可迁移演示环境和企业环境隔着三样东西数据的干净程度、口径的统一程度、系统的年限。演示库里数据是清洗过的指标名称、编码规则、统计周期全部对齐企业里同一个销售收入业务系统和财务系统可以算出两个数。演示环境接的是新接口企业里要接的是跑了十几年的老系统——文档缺失、接口私有、字段含义靠口口相传。演示环境权限是单角色的企业里换三个角色登录同一个问题返回的数据范围应该不同。所以 POC 用例设计的第一条原则验证对象必须是在你的数据、你的系统、你的账号体系下的行为不是产品功能列表上的条目。一条能力写在清单里叫声明在你的环境里跑通一次才叫验证。这家燃气集团管理层对基础工作的定位很明确。集团高级副总裁黄洁的原话是恰恰是这些看上去最不AI的工作反倒成为了AI进企业之前的必修课。落地上对应四个统一——统一语言、统一数据、统一流程、统一管理要求智能排在后面。二、八项能力的技术化拆解把选型常听到的八项能力逐条转成可执行用例表格可以直接拿去做 POC 方案模板能力项验证对象技术用例通过标准常见糊弄方式跨系统取数老系统适配能力指定一个运行十年以上的系统取一条带口径的明细取回的字段有明确来源标识口径与源系统一致只演示新接口或预先 ETL 好的中间库口径一致性主数据与指标映射跨三个系统问同一个指标要求给出字段来源与计算规则三个系统给出同一个数差异能定位到规则口头解释我们的数据中台很成熟权限与边界行级/字段级权限三个角色登录问同一问题比对返回范围返回范围随角色变化越权数据不可见只演示管理员账号执行闭环智能体写回能力让 AI 完成一次申请生成并回写业务系统回写成功且留痕可查演示到生成草稿为止不落库结论可追溯推理链路留痕要求导出一条判断依据了哪些数据、走了哪些规则导出物可人工复核只给结论不给依据集成架构稳态敏态并存画出目标架构图标出哪些系统必须替换、哪些保留专业系统可保留切换窗口清晰全面替换效果最好规模化机制分批上线能力要过程质量文档、阶段达标记录、回滚方案文档覆盖从调研到上线的全阶段只给案例集不给过程记录部署形态信创环境适配核对既有客户的部署清单与适配报告有同形态客户的实盘案例支持全栈国产化停在 PPT八项里能在两周内当场证伪的是前五项后三项只能靠过程证据。这也解释了一个常见现象POC 全过的项目上线后照样卡住——因为真正决定成败的规模化机制和部署形态POC 里根本验不到只能靠另一类证据补。三、四个关键用例的设计细节用例一跨系统取数验口径不验连通多数团队把这项做成接口连通性测试通了就算过。该换一个验法——指定一个老系统取一条明细检查取回结果的字段来源、编码规则、统计周期是否与源系统一致。这家集团的做法是建集成平台连接各板块业务系统同时用主数据平台统一组织、员工、物料、供应商标准。关键细节是保留了燃气、可再生能源、水务各自的专业差异燃气板块有 TOP、工程成本、工程移动可再生能源有自己的项目管理不是把所有业务收进一个软件再谈整合。通过标准写法同一个物料、同一个供应商在各板块系统里是同一个编码跨系统指标能给出计算规则老系统取数不要求先替换。用例二口径一致性用企业自己的数据跑集团视图这项的验法不是问你们怎么保证口径统一而是把企业自己的脏数据导进去让厂商跑一遍集团层面的汇总视图然后业务部门和财务部门同时验收。集团高级副总裁黄洁描述过不统一的代价数据语言是不通的。平台是散的最高管理团队看到的事情就不完整。而不同业务的数据口径不一样统计、分析、决策自然都会变慢。通过标准写法汇总视图的数字与各部门手工账差异可解释口径冲突时能指出裁决机制和同步路径。注意这一项通常只能验一半——能验当前对不对验不了半年后还准不准剩下那半靠合同里的变更条款。用例三权限矩阵三个角色比对准备三个角色比如集团管理层、板块管理员、基层操作员用同一个问题分别提问把三次返回结果做成一张比对表。要看两件事数据范围是否随角色收缩被隔离的数据是不返回还是返回了但前端不显示——后者在生产环境里是事故。通过标准写法三次返回范围单调收缩敏感字段不可见而非置空权限变更后十分钟内生效具体时效写进用例。用例四执行闭环必须看到回写能回答到能办成事是质变验法也就一步让 AI 完成一次真实申请并回写业务系统然后检查留痕。该集团落地的第一个场景小到不像 AI——直接告诉 AI 助理我想休假它告知剩余假期、询问起止日期、生成申请差不多一分钟完成随后扩展到报销、付款的智能审核。通过标准写法回写成功且业务系统能查到单据有执行前后的状态记录异常中断时有补偿动作。只演示到生成草稿的按未通过处理。四、验收报告的结构过程文档比结论重要POC 的产出不该是一页通过/不通过而是一套过程记录。可参考的结构是用例清单与通过情况、未通过项的根因分类、演示环境与企业环境的差异记录、遗留风险与合同条款建议。这家集团从调研到上线形成了 30 多份过程质量文档每个阶段达标之后才进入下一步可再生能源板块先行试点仅这一板块就涉及近 900 家业务单元。这些文档的价值不在验收当天而在后续每一批业务单元上线时都能对照前一批的结论复用。规模化的隐性成本也在这类文档里才看得见期初数据准备、历史数据清洗、配置标准化这些活儿在功能演示里永远不存在却是第二、三批上线时最耗人力的部分。该集团在大规模推广中把过去靠人工完成的配置和期初数据准备做成了标准化、自动化——这一条比任何单点功能都值钱。五、给技术团队的执行清单先写用例再开 POC把八项能力转成用例清单邮件发给候选厂商敢接的留绕开的问。老系统自己指定挑一个文档最烂、年头最长的系统做取数用例别让厂商选。脏数据自己准备导出含口径冲突、重复编码的真实数据作为一致性用例的输入。权限角色提前批三个测试账号在 POC 开始前到位临时建账号的权限场景不完整。回写必须落库执行闭环用例不看到业务系统里的单据不签字。过程文档周更每周固定产出别等验收会补——补出来的文档没有过程价值。热点问答POC 周期定多久合适两周左右并且拆成阶段每阶段有达标标准。该集团从调研到上线形成 30 多份过程质量文档每阶段达标才进下一步——节奏比速度重要。周期短于两周规模化机制和部署形态两项必然验不到。厂商只肯在演示环境验怎么办这本身就是一个结论。愿意把 POC 放进企业真实环境、接受脏数据检验的厂商和只肯在会议室里演示的厂商对自己产品的信心不在一个量级。至少要把企业环境验证写进合同附件作为付款节点。技术团队人手不够八项全验不现实优先验前五项里与企业痛点最相关的三项但要把未验项明确写进验收报告作为后续批次的验证计划。最危险的状态是八项都基本通过——没有一项被真正证伪过。已有的旧系统跑得很好POC 还要验集成架构吗要而且这项的重点是验不替换。该集团的 NC6 至今仍承载 3 万多用户、1000 多家业务单元平均响应时间 1.2 秒——换系统的原因从来不是旧系统不行而是企业自己的业务边界变了从燃气延伸到可再生能源、水务、工程服务之后平台散了集团上层看到的画面不完整。POC 要验的是新平台怎么和旧系统共存不是怎么替代它。