很多制造业 AI 项目并不是模型演示失败，而是 Demo 通过后仍没有进入真实业务：数据没有稳定来源，动作没有合适权限，异常找不到责任人，验收也只剩“看起来不错”。这四处断点任何一处没有接上，项目都很容易停在展示层。
演示成功，不等于业务链已经跑通
演示通常使用提前准备的样本、有限场景和明确问题。真实运行则会遇到版本变化、字段缺失、权限差异和规则外情况。判断项目是否越过演示阶段，可以先看四项证据：输入能否持续取得、动作能否在授权范围内执行、失败后是否有人接手、结果能否按统一口径验收。
如果这四项还只能靠项目成员临时解释，就不应急着扩大范围。可以先参考制造业 AI 试点启动前的四张清单，把目标、数据、责任和验收补成可检查的材料。
断点一：数据能展示，却不能稳定进入任务
Demo 可以手工上传一份干净文件，业务现场却可能同时存在邮件附件、表格、ERP 记录和口头变更。真正要确认的不是“模型能否读懂样本”，而是：
- 哪个系统或文档是可信来源；
- 谁负责维护字段和版本；
- 缺项、冲突和过期数据如何暴露；
- 输入变化后，任务是否会使用错误版本继续执行。
数据问题没有解决时，继续调提示词往往只能改善演示，无法改善运行。
断点二：能给建议，却没有安全的动作权限
项目进入业务链后，读取、生成、提交和回写是不同等级的动作。账号能查数据，不代表可以修改订单；能生成草稿，不代表可以替责任人批准。
权限设计要从具体动作出发，明确调用人的身份、可访问范围、需要审批的节点和操作留痕。权限不足时应停止并提示，而不是绕过控制。可以把首个试点限制在“读取—整理—生成待确认结果”，等证据稳定后再讨论受控执行。
断点三：正常路径有人演示，异常路径没人负责
业务真正消耗时间的，往往是规格冲突、资料缺失、系统状态不一致和临时变更。若流程只定义正常路径，异常就会重新落回群聊和人工追问。
每类异常至少要有触发条件、责任人、交接材料和恢复方式。AI 可以标出证据不足、汇总冲突和形成待处理清单，但不能替业务负责人判断规则外事项。首个任务如何选择，可以使用16 分任务评分表先缩小范围。
断点四：只有主观评价，没有验收证据
“回答不错”“节省时间”都不足以支撑上线。验收应回到任务结果，例如字段是否有来源、关键遗漏能否暴露、权限是否越界、失败是否交给正确的人、操作是否可追溯。
建议把正常任务、缺失输入、权限不足和规则冲突分别做成测试样本。只有正常样本通过而失败样本无法解释，项目仍不具备稳定运行条件。
修复顺序：先补最短的一段，不要同时做大
比较稳妥的顺序是：先锁定一个高频任务，明确可信输入和交付结果；再补权限与人工确认点；随后覆盖常见异常；最后用同一批测试样本验收。灵核数智的岗位级 AI 数智员工可以围绕具体岗位组织工具、技能和作业指导书，但前提仍是业务边界已经写清。
如果项目目前只能回答“模型效果怎么样”，却答不出数据从哪里来、谁批准动作、异常交给谁以及怎样算通过，下一步不是增加更多功能，而是先把这四个断点逐一接上。
