本文定位：失败复盘。它不是产品宣传稿，而是把一个常见的企业数字化问题拆成“背景—症状—方案—结果—经验”，方便你对照自己的情况判断。
一、背景：问题不是突然出现的
客户最初想做 AI Agent，目标是“帮老板看业务”。第一版供应商做了一个聊天入口，可以回答制度、产品资料和常见问题，但老板问“哪些订单可能延期”，系统答不上来。
二、关键症状：真正卡住业务的地方
问题不在模型，而在数据。订单状态在 ERP，审批在钉钉，销售跟进在 Excel，回款在财务软件。AI 没有稳定的数据源，只能基于文档聊天。
三、落地/救火路径：先收口，再扩展
救火时我们先把目标缩小到一个场景：订单延期预警。把订单交期、采购到料、生产进度、发货状态和责任人打通，再让 AI 解释风险原因和建议动作。
四、结果：能被管理动作验证的变化
第二版上线后，AI 不再试图回答所有问题，而是每天输出风险清单：哪些订单延期概率高，卡在哪个环节，应该找谁处理，昨天的处理有没有结果。
五、给同行的建议：别先追求大而全
AI Agent 的关键不是聊天框，而是数据—判断—动作—复查的闭环。如果没有业务数据，越强的模型也只能说漂亮话。
六、可直接照抄的检查清单
| 检查项 | 要问的问题 | 不合格信号 |
|---|---|---|
| 业务目标 | 这次项目到底要让哪个指标变好？ | 只说“提升效率”，没有具体场景 |
| 数据来源 | 关键数据现在在哪里、谁负责维护？ | 数据散在个人 Excel 和聊天记录里 |
| 责任闭环 | 异常出现后谁处理、多久复查？ | 只有提醒，没有责任人和复查机制 |
| 上线范围 | 第一阶段哪些必须做、哪些先不做？ | 一期就想覆盖所有部门 |
| 管理承接 | 上线后在哪个会议、哪个岗位使用？ | 系统上线后没人固定看 |
七、AI Agent 试点前先做数据体检
我们现在判断一个企业能不能做 AI Agent，不会先问“用哪个模型”，而是先做数据体检。至少要回答五个问题：业务对象是什么，数据在哪里，字段是否稳定，权限边界能不能区分，AI 输出后有没有人处理。比如订单延期预警这个场景，核心对象不是“聊天记录”，而是订单、物料、采购、生产、发货和回款。
如果这些对象还散在 Excel、ERP、钉钉审批和财务软件里，第一阶段就不要承诺“智能经营助理”。更现实的做法是先建一个只读数据层，把关键字段同步出来，保证每天有稳定快照，再让 AI 做解释、归因和建议。AI 不直接改数据，只输出风险清单和建议动作，由责任人确认后再回写。
这也是为什么很多 AI 项目看演示很惊艳，上线后却只会聊天。演示用的是整理好的样例数据，真实企业面对的是缺字段、重编码、权限不清和责任人不明确。先把数据闭环做小，AI Agent 才有机会从“会说”变成“能办事”。
八、AI 项目救火要从“只读数据层”开始
很多企业一上来就想让 AI 改订单、发通知、自动审批，但在数据还没稳定前，这样做风险很高。这个项目救火时，我们先做只读数据层，把订单、采购、生产、发货和回款的关键字段每天同步出来，形成可核对的业务快照。AI 只基于快照解释风险，不直接修改源系统。
这样做有两个好处。第一，老板和业务负责人可以核对 AI 的判断是否可信；第二，即使 AI 解释错了，也不会破坏业务数据。等风险识别准确率和责任闭环稳定后，再考虑让 AI 发待办、写备注或触发审批。
只读数据层不是大数据平台，它可以很小。第一阶段只要覆盖一个场景所需字段，例如订单号、客户、交期、物料到料状态、生产进度、发货状态、责任人和更新时间。数据少但稳定，比数据多但混乱更适合 AI Agent 起步。
九、AI Agent 验收要看“动作闭环”
AI 能回答问题不等于落地。这个项目第二版验收时，我们看四个指标：风险订单识别是否准确、风险原因是否能被业务核对、责任人是否收到待办、第二天是否能看到处理结果。
如果 AI 只是生成一段分析文字，没有人处理，也没有结果回写，那它仍然只是聊天工具。真正的 AI Agent 应该进入“数据—判断—动作—复查”的闭环。模型能力重要，但业务数据、权限、责任人和复查机制同样重要。
十、落地前可以先问自己的五个问题
第一，当前最痛的业务动作是什么，是销售漏跟、库存不准、项目亏损、数据口径不一，还是系统没人用？如果一句话说不清，说明项目目标还需要继续收敛。第二，这个动作今天的数据在哪里，是系统里、Excel 里、微信群里，还是某个人脑子里？数据越分散，第一阶段越要小。第三，谁是这个数据的负责人，谁有权决定字段口径和流程变化？没有负责人，系统上线后也会变成无人维护的表。
第四，异常出现后谁处理，处理结果回写到哪里？很多数字化项目只做到“发现问题”，没有做到“问题被处理并复查”，价值会卡在最后一公里。第五，老板或管理层准备在哪个会议里固定使用这套系统？如果上线后没有会议承接，大家很快会回到原来的汇报方式。
这五个问题的答案，比功能清单更重要。功能清单决定开发什么，五个问题决定系统上线后有没有人用、有没有人维护、有没有管理动作跟上。
十一、适合先做小诊断的企业画像
如果你的企业已经有一些系统，但数据分散、口径不一、老板看数还要等人导表，适合先做诊断；如果你的企业还主要靠 Excel、钉钉群和人工审批，也适合先做诊断，因为这时最重要的是确认第一阶段到底该系统化哪一段。
不适合一上来做大项目的情况也很明确：目标太泛，只说“全面数字化”；内部没人能拍板；历史数据没人愿意清；业务部门只想让 IT 自己解决；老板希望一次上线解决所有问题。遇到这些情况，先做 1 到 2 周的小范围梳理，反而比直接开发更省钱。
开沿通常会把诊断结果拆成三张图：业务流程图、数据流转图、一期范围图。三张图对齐后，再决定用标准 SaaS、低代码、钉钉二开、系统集成还是定制开发。这样做慢在前面，快在后面，也能减少上线后推倒重来的概率。
补充一点：第一阶段还要提前约定复盘节奏。上线后的前四周，建议每周固定看一次使用数据、异常清单和业务反馈，把必须改的小问题快速收掉，把“以后再说”的需求放进二期池。这样既能保护一期范围，也能让业务团队看到系统是在持续服务他们，而不是上线后就没人管。
十二、开沿的建议
如果你看到这里，最该做的不是立刻问“做一套多少钱”，而是先把当前流程画出来：数据从哪里来，谁加工，谁决策，谁执行，结果回写到哪里。只要这条链路不清楚，系统越复杂，后期越难维护。
开沿更愿意先做小范围诊断：选一个高频场景，确认数据和责任是否能闭环，再判断适合低代码、标准 SaaS、二开还是定制。这样预算更可控，也更容易让团队真正用起来。
