失败根因卡：这个项目不是模型差，而是没有结构化业务数据。订单状态、审批、销售跟进、回款分散在 ERP、钉钉、Excel 和财务软件里，AI Agent 只能回答文档，不能推动业务。补救重点不是换模型，而是建立只读数据层、权限边界和一个可核对的异常场景。
| 自检项 | 能继续做 Agent 的信号 | 需要先补课的信号 |
|---|---|---|
| 数据源 | CRM/ERP/进销存里有稳定字段 | 关键数据在个人 Excel 和群聊 |
| 权限 | 谁能看客户、订单、金额有规则 | AI 账号默认能看全部 |
| 动作闭环 | 输出后有人处理并回写结果 | 只生成建议没人认领 |
| 验收 | 识别、核对、待办、回写均可验证 | 只看演示效果 |
如果正处在试点前，可以先读 AI Agent 落地路线图、AI Agent 前置自检、企业数据治理第一步 和 AI Agent 权限审计。
老板问延期订单，聊天框答不上来
客户最初的目标是让 AI Agent “帮老板看业务”。第一版只有聊天入口，可以回答制度、产品资料和常见问题；老板问“哪些订单可能延期”，系统却没有依据。
原因不在模型：订单状态在 ERP，审批在钉钉，销售跟进在 Excel，回款在财务软件。没有稳定字段和权限边界，AI 只能基于文档组织一段文字，不能判断业务风险。
救火只选订单延期预警
第二版没有继续扩充问答范围，而是把目标缩到订单延期预警。项目先打通订单交期、采购到料、生产进度、发货状态和责任人，再让 AI 解释风险原因和建议动作。
AI 每天输出的是风险清单：哪些订单延期概率高、卡在哪个环节、应该找谁处理、昨天的处理有没有结果。它不再试图回答所有经营问题，而是在单一场景中完成“数据—判断—动作—复查”。
先建只读数据层，而不是开放写权限
数据还不稳定时，不应直接让 AI 改订单、发通知或自动审批。这个项目先把订单、采购、生产、发货和回款的关键字段每天同步出来，形成可核对的业务快照；AI 只解释风险，不直接修改源系统。
这样既便于老板和业务负责人核对判断，也避免错误解释破坏业务数据。等风险识别和责任闭环稳定后，再考虑让 AI 发待办、写备注或触发审批。
只读数据层不等于大型数据平台。单一场景只需要订单号、客户、交期、物料到料状态、生产进度、发货状态、责任人和更新时间等稳定字段。数据少而稳定，比数据多而混乱更适合试点。
试点前做五项数据体检
不要先问“用哪个模型”，先回答五个问题：业务对象是什么，数据在哪里，字段是否稳定，权限边界能否区分，AI 输出后有没有人处理。订单延期预警的核心对象不是聊天记录，而是订单、物料、采购、生产、发货和回款。
如果这些对象仍分散在 Excel、ERP、钉钉审批和财务软件里，第一阶段就不应承诺“智能经营助理”。先取得稳定快照，再做解释、归因和建议，才能让演示中的样例能力进入真实业务。
验收看四个动作，不看回答有多像人
第二版验收关注四项：风险订单识别是否准确，风险原因是否能被业务核对，责任人是否收到待办，第二天是否能看到处理结果。
如果 AI 只生成分析文字，没有人认领，也没有结果回写，它仍然只是聊天工具。模型能力固然重要，但数据质量、权限、责任人和复查机制共同决定 Agent 能不能办事。
