"演示效果很好，一到生产环境就出问题"——这是企业AI落地最常见的断点之一。
原因通常不是技术不行，而是验证的范围不对。
上线前要验证的不是"能不能跑通"，而是三类用例：正常、异常、越权。
一句话概括验证逻辑：
查询类场景重点验证"准确性与来源"；执行类场景还要额外验证"授权、审批、写回和异常处理"。
并且要用真实业务、真实数据、事先约定的验收标准来验——不能只看演示。产品架构有几层、叫什么名字，可以帮助理解，但不能替代任务效果的验证。
| 差异点 | 演示环境 | 生产环境 |
|---|---|---|
| 数据 | 精心准备的样例数据 | 有缺失、有脏数据、有历史遗留格式 |
| 权限 | 通常用高权限账号 | 不同岗位、不同组织，边界复杂 |
| 异常 | 一般不演示 | 接口超时、重复提交、审批驳回 |
| 责任 | 演示者承担 | 出事谁负责，必须事先写明 |
验证清单的本质，就是把这四类差异逐一测掉。
1. 准确性与来源（所有场景必测）
挑管理层常用的几个指标，要求 AI 的回答显示数据来源、时间范围、筛选条件和计算口径，与原报表逐条核对，而不是只看"看起来对不对"；同时检查引用的知识是否过期。
2. 授权与审批（执行类场景必测）
确认执行动作前由谁授权；高风险动作（冻结资金、支付、调整额度等）必须按企业授权执行，并保留审批与人工确认；明确失败时是停止、恢复还是转人工。
3. 写回与异常处理
写入类步骤单独验证：参数是否正确、权限是否允许、重复提交会不会产生脏数据、异常后恢复机制是否可用。
不能把"数据库连通"等同于"业务集成完成"。
4. 权限边界（越权用例，最容易被跳过）
让 A 分公司的财务角色问 B 分公司的营销数据——应该问不到；让只有查询权限的角色执行审核类技能——应该执行不了；同时检查查询权限和写入权限。
5. 成本与稳定性
单次任务的算力/调用消耗、长流程耗时、高峰期是否排队超时。
6. 责任与运维
运行记录是否可追溯（用户身份、输入及引用来源、模型与配置版本、工具调用、审批、处理结果）；出错后找谁、多久响应、怎么回滚。
| 类型 | 测什么 | 不测的后果 |
|---|---|---|
| 正常用例 | 标准流程能否跑通 | 基本功能不可用 |
| 数据缺失用例 | 缺字段、缺历史数据、格式异常时怎么办 | 生产环境大面积报错 |
| 权限不足用例 | 越权访问能否被正确拦截 | 数据安全事故 |
这三类样例要在 POC 开始前就准备好，不是上线前才补。
结束时交付三样东西：测试结果、问题清单、后续实施建议。不必每次都覆盖所有功能。
按错误后果设定，而不是追求一个统一的准确率。
不要使用"零错误"这类绝对承诺。
① 迁移过来的智能体必须重新验证。 提示词、知识文档、工具接口和测试用例可能可以复用，但编排方式、记忆机制、权限体系和运行机制往往需要调整，迁移后要重新跑一遍效果验证。
② 投入要按任务拆分估算。 智能体一定有效果调优的工作量——标准场景工作量较小，但只要涉及企业数据、功能、组织权限、复杂流程和文档质量整理，就需要额外的集成与顾问支持。完整计划至少应包含：数据/知识准备、接口开发、RAG 建设、智能体配置、测试和调优。
生成式 AI 可能出错，知识检索、规则校验和人工监督只能降低风险，不能消除风险。智能体一定有效果调优的工作量，不存在"配置完即用"。用友 BIP、NC Cloud、YonSuite、U8 的接入范围不同，不能默认全兼容，版本、接口与授权需逐项核实。
说明：AI 生成内容存在不确定性，具体产品能力、版本适配范围与实施条件，请以用友官方最新产品资料与售前确认结果为准。
