半年、五个客户、四套方案：B 端 AI 落地的真实纹理

B 端 AI 落地到底难在哪？不是模型不够强，也不是客户没预算。

有一组来自企业财务 AI 方向的一线记录很值得拆开细看：一家 AI 创业公司，半年时间，五个客户，四套方案。它几乎把 B 端 AI 落地能遇到的典型困境都走了一遍。这篇把它里面的硬货拆出来，聊聊我的看法。

背景：什么是企业财务 AI Agent 中台

一句话说清楚这家公司的定位：在企业现有财务系统之上，加一层 AI 决策辅助层。不替代 ERP，做 ERP 之上的智能化增强。

五个核心场景：发票处理、凭证生成、纳税申报、现金流预测、智能分析——覆盖企业财务从「原始单据」到「分析报告」的完整链路。

听起来很清晰对吧？但真正开始干活才发现：场景能不能落地，不取决于架构图画得多漂亮，取决于能不能找到第一个愿意让你试的客户。

五个客户，五种困境

fig. 行业完全不同，问题高度一致

家电制造巨头，第一个真正意义上的客户。SAP 做总账、自研系统管经销商、BI 出报表，再加多家银行的资金管理系统——典型的多系统数据孤岛。客户的问题很直接：「你们能不能用 AI 帮我们做对账？」

分析之后发现，难点不在「比对数据」，而在「判断差异」。同一笔对不上的账，财务 A 判定为「经销商未及时打款」通知催收，财务 B 判定为「编码映射有误」手动调整——两种判断都可能正确，但判断标准存在于每个人的大脑里，而不是系统的规则表里。

这里有一个很关键的洞察：企业不缺规则，缺的是把规则从人脑子里抽出来、变成系统能执行的东西。

股份制银行，资金管理部门的深度交流。确认了三个优先场景：跨行流水对账、还款核销、智能付款排程。但银行客户有三个鲜明特征：合规压倒一切（任何判断被监管质疑，必须有完整审计追溯链）、系统复杂度极高（几十个子系统的生态）、决策链很长（业务、IT、合规、风控、采购挨个审批）。一个清醒的判断是：这是长线客户，短期不出收入，但跑通一个场景，等于拿到金融 AI 市场的通行证。

电商上市公司，港美股双上市、年营收近百亿、近千人技术团队。对接人是风控总监，需求是非经营性采购的「三单匹配」——采购申请单、合同、付款凭证的一致性校验。印象最深的是对方说的一句话：「我们有将近一千人的技术团队，但我不知道该让他们做什么。」 这家公司不缺技术能力，缺的是业务设计能力。

汽车金融公司，来自一场行业展会。五十多家企业里，真正有明确 AI 需求的不多，但来的都带着真实痛点，不是为了赶风口。这位对接人说：「我在专业程度上不那么在行，但我的工作是判断这件事值不值得推到下一层。」——这句话道出了 B 端销售的本质：你不是在说服对接人，而是在帮对接人说服他的上级。

城商行，绿色金融方向。业务分三个环节：寻绿（放款前找线索）、识绿（放款时判定性）、确绿（放款后校验标签）。方案是三 Agent 架构共享统一底座。值得注意的是：家电项目的规则引擎、Workflow 编排、判断卡片、前端嵌入模式，直接迁移到了银行场景——行业完全不同，技术架构复用度约七成。

七条规律

四个客户项目跑下来，能总结出七条高度一致的规律：

1. 多系统数据孤岛——不是缺 AI，是数据没打通；
2. 不是没有标准，是标准因人而异——同一个差异，不同财务结论不同；
3. 客户不要 AI 替代人，要 AI 帮人统一判断——不要自动过账，要告诉财务「这笔差异最可能的原因是什么」;
4. 大厂通用方案被主动拒绝——「太通用」，客户从买品牌转向买深度；
5. 对接人不专业但能卡你——让他能把你的价值复述给上级，是 B 端 AI 销售最核心的能力；
6. 客户买的不是功能，是结果——「原来对账差异要三方协同查半天、现在三十分钟出结果」才卖得动；
7. 先证明能力，再谈扩展——先一个场景验证，再逐步展开。

两个值得记住的概念

受控流程型 Agent。 这是一种从实战里长出来的产品定位：在高合规、高准确性要求的领域，Agent 不应追求完全自主决策，而应在受控的流程框架内执行辅助判断。

fig. 规则引擎处理确定的，大模型处理不确定的，人工兜底

当整个行业都在讲 AGI、讲全自主的时候，说「我们不追求全自主，我们追求可信赖」听起来不够性感。但我的看法是：这恰恰是 from the field 的结论和 from the deck 的故事的区别——财务领域，可信赖比全自主重要得多，签字权必须留在人手里。

工作方式的反转。 传统软件里产品和开发边界清晰：产品定义做什么，技术定义怎么做。Agent 时代这个边界模糊了——能力边界取决于模型输出质量，而输出质量取决于喂了什么数据、写了什么提示词，这些是产品和技术共同完成的。

fig. 传统项目是需求→方案→开发，Agent 项目是假设→验证→方案

有一个很真实的冲突：方案写了一半被程序员堵回来，「先出详细方案再开发」对「先搭最小链路验证」——两个人在两个时代对话，没有对错。Agent 项目的正确顺序是假设→最小链路→验证→基于结果出方案，顺序整个是反的。解决方式也简单：别争，先跑。

我的几点看法

「落地难」的归因非常准确。 数据是分散的（散落在十几个系统里，字段名不一致、编码不同、更新频率各异）、标准是人定的（流程是长出来的，不是设计出来的）、决策者不懂 AI（CFO 不知道企业哪里能用）、信任建立慢（财务数据是核心资产）。模型从来不是瓶颈，瓶颈是数据工程、流程标准化、市场教育、信任建立——谁愿意做这些脏活累活，谁就能占先机。这和我之前在车企智能客服改造里观察到的一模一样。

客户筛选比客户获取更重要。 有一个反向案例值得记住：连锁零售客户的多平台对账，看起来正好是擅长的问题，但深入分析发现数据抽取无解（平台 API 拿不到、RPA 难过隐私权限）、预算又太低。对客户诚实地说「花这个钱意义不大」，比强推一个注定失败的项目更利于长期信任。这种克制在创业公司里非常稀缺——因为每个销售机会都显得珍贵。

对 PM 这个职业的含义。 这组记录顺带回答了一个行业争论：「产品经理要不要懂技术？」——在 Agent 时代，不是要不要的问题，是不懂技术就画不出一个能跑通的方案。理解模型行为、理解提示词、理解数据归一化，这些正在从「加分项」变成「基础项」。

结尾

产品、方案、架构图会过时，但从一线摸到的这些规律——数据孤岛、判断标准、受控 Agent、工作方式反转——会留在每个认真看过的人手里。

落地这件事，从来不是靠更聪明的模型，是靠更懂现场的人。