演示成功，不等于部署完成

演示程序读取一张样例发票，提取金额，并把整洁的摘要写入审批系统。真实流程里，发票从三个渠道进入，有些属于另一个法律实体，而且审批系统只接受具备特定角色的用户。提取仍然准确，工作流却无法完成。这是示例，不是客户案例。

一场关于将 AI 部署到老业务系统的讨论指出，本地数据、既有软件和工作习惯是部署中棘手的部分。发言人描述的是一家公司的做法，不是通用成功率。有用的区分是证明一个组件可用，还是让它真正把工作做完。

演示可以挑选环境

演示能挑干净的输入，预先授权账户，跳过队列，重置失败运行，并由创作者解释模糊输出。为了证明能力，这些选择合理；若团队把能力测试当成运营就绪的证明，就危险了。

以发票为例，提取只是一步。组织还需明确哪个收件箱是权威来源、如何识别重复、提交后金额能否修改、谁可以批准，以及写入失败时去哪里。生成摘要再漂亮，也无法替这些问题作答。

从一件工作到达开始，追踪到结果被接受，边界就清楚了：

演示能力 准备好的输入

本地集成 数据 权限 恢复

实际工作流 被接受的结果

只有本地数据、权限与故障恢复把已证明的能力接入实际操作人员的工作流，它才能产生可接受的结果。

阶段	演示的问题	部署的问题
输入	模型能读这个样例吗？	能接收所有获授权的格式并拒绝其他格式吗？
背景	能找出金额吗？	能匹配正确的供应商、实体和政策版本吗？
行动	能生成摘要吗？	能只执行获准行动并避免重复吗？
失败	演示者能重试吗？	谁发现卡住的任务、修正后安全恢复？
采用	输出看起来有用吗？	负责人真的在工作队列中使用并信任它吗？

这是概念性比较，不表示 AI 项目有某个实测失败率。

追踪本地状态

数据集成常被叫作“最后一段路”，仿佛产品做完后只需接根线。本地数据模型却可能改变产品本身的含义。一家企业可能在发票进入收件箱时就视为“已收到”，另一家则要等它与采购订单匹配。系统根据错误状态行动，即便 API 调用技术上成功，也会造成业务错误。

问清每项事实从哪里来、谁可以修正，再问事实互相矛盾时系统怎么办。源记录在模型起草审批后改变，草稿是否应失效？任务排队期间权限被撤销，工作进程在行动前会不会再查一次？这些不是部署后的润色，而是部署本身。

工作流发现文章从更早一步开始，观察操作人员实际做什么。这里的问题是：一项演示过的能力，要满足什么条件才能在那条工作流中继续成立？

先验证能力，再测试整条工作流

小型原型可能是最快的办法，能先回答模型是否胜任核心任务。第一天不必具备全部生产控制。错误在于不检查后续工作，就把它排成微不足道的收尾。

有用的原型会声明边界：“读取批准的样例发票，建议字段，不执行任何外部行动。”下一步可以使用获授权的实时记录，但先关闭写入。只有弄清数据匹配、权限和恢复后，才允许写入审批系统。每一步回答不同问题。

部署也有人这一侧。经常处理模糊发票的人，需要能修正建议、看见改动，并知道系统是否会重复犯错。如果新工作流增加的检查比省下的还多，实际使用会反映出来。不要从一次成功演示推断有人采用。

上线关口可以变成一个运营问题：没有演示创作者在场，另一位获授权的操作人员能否完成一件工作并从失败中恢复？他应该找得到原始输入、看得见拟议行动、能辨认权限依据并路由失败。回滚演练也重要，因为首次成功并不能说明重复或部分写入时会怎样。在现有工作流实施 AI 的指南提供更广的推进框架；这个关口应保持狭窄，重点反复测试最可能打断正常路径的例外。

该计数的不是生成的输出，而是真实流程中被接受、且例外有明确处理路径的工作项。路径未通之前，演示是一个组件的有用证据，不是任务已完成的证据。