过去两年，我们在一些化工、制造业行业链主的客户现场做 FDE 交付。 这些企业并不缺数字化基础，也不是没有系统、没有数据。恰恰相反，它们往往有复杂的业务流程、多个存量系统、大量历史记录、层层审批链路，以及一批真正懂业务但很难把经验写成规则的专家。 第一次进场时，客户问我们的问题通常很具体： “我们能不能做 RAG？” “Text-to-SQL 能不能上？” “合同审查能不能用 AI 做？” “是不是把文档喂进去就行？” “RAG 是不是就是训练 AI？” “模型以后足够强了，是不是就不用继续投入了？” “这个准确率能做到多少？” “AI 的 ROI 怎么和领导证明？” 这些问题都很真实。但真正进入现场后，我们发现，客户一开始问的往往是技术问题，项目真正卡住的却是业务问题。 AI 部门说的是技术场景：问答、问数、RAG、Agent、工作流。 业务领导说的是业务场景：合同审查、财务分析、智能审核。 一线员工关心的则是更具体的任务：这张单据能不能过？这份材料有没有风险？这个结论能不能直接拿去处理？ 如果这些语义层没有对齐，AI 项目很容易从一开始就跑偏。 所以我们在现场形成了一套工作方式：先像咨询一样，和客户一起梳理战略重点、业务流程和场景优先级；再像实施团队一样，从数据、规则、入口、权限、反馈和验收往下落。 不是一上来就搭 Agent，也不是一上来就做工作流。先要弄清楚：到底要解决什么业务问题？现在的数据能支撑到哪一步？AI 应该嵌入原流程，还是通过 API 接入现有系统，或者重新做一个 AI 原生的小产品？ 这两年下来，我越来越觉得，FDE 做的不是把 AI 技术搬进企业，而是把企业的业务问题翻译成 AI 可以参与、可以交付、可以持续变好的闭环。
一个现场案例：共享财务智能审核
有一个共享财务职能审核项目，很典型。 客户最初的需求可以概括成一句话： 我们想要一个 AI 自学习的智能审核，最好能把人工都替代。 听起来很明确，但拆开以后，每个词都需要重新定义。 审核什么？ 怎么叫自学习？ 人工到底能不能被替代？ 哪些单据可以自动判断？ 哪些必须人工复核？ AI 判错以后怎么办？ 验收时看准确率，还是看风险有没有漏过去？ 这个项目主要审核费用类单据，比如差旅费、住宿费、餐费等。餐费里就有很典型的场景：如果一顿肯德基人均 300 元，单看它是一张餐费单据可能没问题，但结合常识、制度、金额区间和业务场景，它显然需要被拦出来。 问题是，客户现场的数据并没有想象中那么完整。 系统里主要保存的是最终通过后的单据。没有退单记录，没有人工审核意见，没有修改痕迹，也没有完整附件。也就是说，我们看到的多是“最后被允许通过的结果”，而不是“为什么有些单据不该通过”的过程。 这时候，如果简单说“让 AI 从历史数据里学习审核规则”，其实是不严谨的。因为只有正样本，没有负样本，没有退单原因，也没有关键附件，AI 不可能凭空倒推出完整的不通过规则。 所以我们没有硬和技术较劲，而是调整了落地路径： 制度规则先打底，通过单据做合规画像，附件抽样补齐变量，人工经验补充典型负样本，AI 负责结构化整理和候选规则生成，人工确认后进入规则库。上线以后，再通过人工复核、bad case 和反馈机制持续迭代。 这件事的本质，不是让 AI “神奇地学会审核”，而是设计一个能持续长出审核能力的业务闭环。
AI 落地必须回答的 8 个问题
1.企业是不是 AI-ready？
AI-ready 不是有没有模型 API，也不是有没有一个知识库平台。 更关键的是：业务流程有没有被定义清楚，关键数据有没有留痕，系统能不能接入，业务专家能不能参与确认，结果有没有人负责，错误能不能被反馈回来。 在财务审核项目里，客户不是不能做 AI，而是不适合直接跳到“全自动自学习审核”。更合理的起点，是先建立规则库、审核助手和反馈闭环。
2.到底应该做什么场景？
场景不能只从技术热词里选。 RAG、Text-to-SQL、Agent 都不是场景，它们只是技术形态。真正的场景应该落到业务任务里：谁在什么流程节点，因为缺少什么信息或判断，导致效率、质量、风险或体验出了问题。 共享财务审核之所以适合做，是因为它高频、规则密集、风险可控，而且有明确的业务闭环。
3.数据怎么来？没有现成数据怎么办？
现场经常不是“没有数据”，而是“数据不能直接用来解决这个问题”。 这个项目里，历史通过单据可以用来分析正常报销画像，但不能直接训练通过/不通过模型。制度文件、通用审核规则、通过单据画像、附件抽样识别、人工补充案例，合在一起才构成可用的数据输入。 所以数据不是客户扔过来一张表就结束了。FDE 要做的是把业务痕迹转成可用资产。
4.业务专家的经验怎么被 AI 学会？
很多企业最有价值的知识，不在文档里，而在审核人员的判断里。 比如哪些餐费看起来异常，哪些住宿水单需要特别关注，哪些发票字段组合不合理，哪些情况属于例外。 这些经验不能只靠访谈一次性抽取。更好的方式是让专家参与候选规则确认、典型案例标注、例外情况补充和 bad case 复盘。专家经验会逐渐沉淀成规则、样例、记忆和运营动作。
5.人在流程里到底是什么角色？
很多客户一开始会说“最好把人工替代”。 但现场交付里，更重要的问题是：人到底应该是审批者、协作者，还是兜底者？ 在财务审核早期，人不应该被直接拿掉。AI 可以做初审、风险提示、规则命中、附件缺失提醒和处理建议；人负责确认、复核、例外判断和最终责任。随着规则库、样例库和反馈数据成熟，再逐步扩大自动化范围。
6.AI 怎么进入现有工作流？
AI 如果变成一个额外打开的新入口，很容易没人用。 这个项目最后选择嵌入原报销系统。AI 在原有审核流程中输出审核结论、风险点、命中规则、所需字段、附件缺失项、处理建议和解释依据。 用户不需要跳到另一个系统里“问 AI”，而是在原本处理单据的位置，直接看到 AI 给出的审核辅助。这一点很重要：AI 不是多一个工具，而是进入原来的工作现场。
7.智能体怎么验收？
审核类 AI 不能只看一个准确率。 因为不同错误的代价不一样。AI 把本来能通过的单据拦下来，是误拦，影响效率和体验；但 AI 把本来不该通过的单据放过去，是漏拦，影响风险控制。 所以我们引入了类似混淆矩阵的验收方式：区分 AI 判不通过且人工确认不通过、AI 判通过且人工确认通过、AI 误拦、AI 漏拦。 对这类场景来说，验收不是问“总体上准不准”，而是先问清楚：哪一种错最不能接受。早期宁可让 AI 稍微谨慎，也不能让高风险单据轻易漏过去。
8.上线以后，bad case 怎么闭环？
AI 上线不是结束，而是开始。 每一次 AI 判错、人工改判、规则冲突、字段缺失、附件识别失败，都应该进入运营闭环。它们不是零散反馈，而是规则库、样例库、记忆和数据采集机制的迭代资产。 真正有价值的产品能力，不只是 RAG 或 Agent 本身，而是能把散乱知识变成可运营知识，把 bad case 变成持续迭代资产，把专家经验沉淀成系统能力。
最后的感受
做 AI 项目，最容易走偏的是和技术较劲。 模型还不够聪明，RAG 还不够准，Agent 还不够自动，工作流还不够复杂。 但在客户现场，真正要先回答的是：这个 AI 有没有解决一个真实业务问题？它有没有形成业务闭环？这个闭环嵌入现有流程以后，是提升了原流程，还是制造了新的负担？ 很多时候，AI 落地不是先追求一个最强模型，而是先把业务问题定义清楚，把数据来源补齐，把专家经验沉淀下来，把人机分工设计好，把验收标准说清楚，把 bad case 运营起来。 AI 不是做个 Demo。 AI 落地，是把一个模糊的业务现场，变成一个可验证、可迭代、可托付的系统。
