这篇回答一个问题：当一家银行把大模型铺到几百个场景时，交付工作到底长什么样。
最值得拿走的是工行的三条规模化证据链——场景数、调用量、成功率三个口径互相咬合：覆盖超 400 个场景、端到端成功率 90%、累计调用突破 10 亿次且场景数同比增长 67%。容易误读的是把「场景数」当效果本身：场景数量只是覆盖度指标，能不能持续跑通要看成功率与调用的真实性，本文会拆这三个数字各自度量什么。
增量在于：站内讨论 FDE 多以硅谷客户案例为样本，这篇全部用国内银行公开披露的数据，说明 FDE 类角色的价值主张（场景发现、数据接入、评测、运维）在国内头部机构以「岗位内部化」形态呈现，这与国际的厂商驻场形态不同。
建议你读完做一件事：对照工行的三条口径，检查自己项目的度量体系里是否同时有覆盖度、质量、使用量三类指标，缺哪类就补哪类。
—— FDEChina编辑部 · 实战派
背景：银行是大模型场景落地最密集的行业
在国内 toB 大模型落地版图里，银行业是披露最充分、场景密度最高的行业之一。据新华网 2025 年 9 月报道，工商银行建成企业级千亿金融大模型「工银智涌」，赋能 20 余个主要业务领域、200 余个场景，并推进「领航 AI+」行动。另一侧，据移动支付网 2026 年 3 月报道，招商银行已落地 856 个大模型应用场景，并宣布打造「业内第一家智能银行」。数百个场景在同一机构内同时建设与运营，这意味着大模型交付已经从「试点思维」进入了「工程化思维」。
这个背景值得多讲一层。银行是典型的强监管、强流程、多系统行业：核心系统、信贷、风控、客服、财富管理各有独立系统与数据域，任何一个 AI 能力要进入业务流程，都要穿过数据权限、审计、复核等多道闸门。因此，银行业做到的场景数与调用量，代表的是「最后一公里」工程能力的天花板样本——模型能力各家的差距在缩小，把能力铺进几百个业务环节的组织能力才是拉开差距的地方。Forward Deployed Engineer（FDE，前置部署工程师）所代表的那类工作——把模型能力翻译成可运行的业务场景——在这种规模化中被大量需要，只是存在形态与国际市场不同，这一点在下文展开。
问题：场景规模化之后的交付之痛
单个场景的 demo 早已不是问题，真正的难题随规模化而来。第一是场景筛选：哪些业务环节值得上模型、按什么顺序上，错误的选择会让资源迅速耗散——数百个候选环节里，重复度高、判断规则清晰、容错可控的环节才是先行的，这与站内 场景发现 playbook 的筛选逻辑一致。第二是数据与系统接入：几百个场景意味着几百条与行内系统、数据权限、合规审查的对接路径，接入工作量随场景数线性增长，而协调成本随系统间依赖超线性增长。
第三是质量与运维：场景上线后的成功率、回滚、评测回归，在金融行业有严格的审计要求，任何一个面向客户的场景出问题都可能构成风险事件。第四是度量：管理层需要知道投入产出口径，否则数百个场景的建设无法持续获得预算。这四个问题没有一个是模型问题，全部是工程与组织问题——「模型很强」与「场景很痛」之间的距离，正是这些问题的总和。
方案：企业级平台 + 场景滚动扩容 + 智能体体系
从公开披露看，工行的路径可以概括为「平台打底、场景滚动、智能体收敛」。平台层是企业级千亿金融大模型工银智涌，作为统一底座支撑各业务领域复用；场景层从 20 余个主要业务领域、200 余个场景起步滚动扩容；能力形态上则向智能体收敛——据中国电子银行网 2025 年 10 月报道，工行已打造上千个专业领域智能体。把同类业务问题抽象成智能体而非逐场景开发，是规模化阶段的典型收敛策略。
招行的路径则是「全栈自研」：据深圳金融监管局发布的信息，招行打造全栈自研大模型技术体系，推动大模型从技术创新走向业务一线；移动支付网的报道则显示其以 856 个落地场景为基础推进「智能银行」定位。两条路径的共同点是：都把大模型当作企业级基础设施来建设，而不是逐个场景外购方案。区别在于技术栈的来源——工行路径强调企业级平台统一赋能，招行路径强调全栈自研，这背后是两家银行不同的科技组织传统，但交付工程的内核是同构的。
实施：规模化交付需要什么样的角色
把数百个场景铺下去，靠的不是一次性大项目，而是持续的场景工程。对照公开数字看实施形态：据新浪财经 2025 年 8 月报道，工银智涌累计调用量突破 10 亿次，应用场景同比增长 67%、调用频次提升 120%，并向 30 余家中小银行开放 API。场景数同比增长 67% 意味着平均每个季度都在新增数十个场景——这种节奏下，交付工作必然被拆解为可复制的流水线：需求界定、数据接入、评测基线、上线验收、持续监控。站内的 评测基线 playbook 与 POC 验收清单描述的就是这条流水线里的关键工序。
值得注意的是角色位置的组织差异。国际市场上，这类能力通常由模型厂商的 FDE 驻场提供——实验室把工程师派到客户现场做交付；而在国内头部银行，公开信息显示场景交付由行内科技团队与外部厂商共建完成，FDE 能力在这里呈现为「岗位内部化」：银行内部需要的是能同时理解模型能力边界、数据架构与业务流程的复合角色。与此同时，国内厂商侧也在补齐这类岗位——字节、腾讯等公司已直接挂出 FDE 类岗位（见站内 FDE 中国本土化分析），甲乙两侧同时扩编说明这类能力是行业性的缺口，而非单家机构的特殊需求。
结果：三个口径咬合的规模证据
工行公开的效果证据可以用三个互相咬合的口径呈现。覆盖度口径：大模型覆盖超 400 个场景（中国电子银行网，2025-10-20），对照新华网报道的 200 余个场景，半年左右的扩容轨迹清晰可见。质量口径：端到端成功率 90%（同上来源）。使用量口径：累计调用量突破 10 亿次、场景数同比增长 67%、调用频次提升 120%（新浪财经，2025-08-01）。细分证据还有两条：据中国金融网「2025 年银行业人工智能十大典型应用案例」专题，工行新增 AI 财富助理等 100 余个应用场景，企业级智能风控平台覆盖全部境内分行及 130 多个风控场景。
招行一侧的公开数字是 856 个落地场景与「智能银行」定位（移动支付网，2026-03）。需要强调的是口径边界：场景数度量覆盖度而非收益，成功率度量质量而非业务价值，调用量度量活跃而非效果——三者合起来才构成完整画像，单独引用任何一个都可能高估或低估交付水平。这种「多口径互相咬合」的披露方式本身值得学习，它是 FDE 交付 ROI 框架里强调的度量分层在真实机构身上的映照。
约束：金融行业的交付边界
银行场景的交付约束比一般行业更硬。第一是合规与审计：模型输出进入业务流程前需要明确的复核机制，端到端成功率 90% 的另一面意味着仍有需要人工兜底的部分，交付设计必须把「剩余 10%」的处理路径写清楚。第二是数据权限：场景越多，跨部门数据授权的协调成本越高，权限谈判往往比技术对接更耗时，相关检查项见站内 数据合规检查清单。
第三是长尾运维：上千个智能体意味着上千条监控与回归测试路径，没有平台化的评测与可观测体系，规模化反而会放大风险——这也是评测能力在金融交付中被提到如此高位置的原因。第四是生态约束：向 30 余家中小银行开放 API，意味着交付标准要从行内工程延伸为对外服务标准，对稳定性、版本管理与文档质量提出更高要求，行内交付团队事实上承担了对外产品团队的职责。
可复用经验
第一，规模化的前提是平台化：先把企业级底座与评测体系建好，再滚动上场景，顺序反了会在几百个场景时失控。第二，度量要三条口径同时建：覆盖度（场景数）、质量（成功率）、使用量（调用量），只报一个数字的汇报经不起追问。第三，智能体是场景收敛后的好形态：把同类场景抽象成专业领域智能体，比逐场景堆方案更利于维护与复用。第四，交付流程要流水线化：需求界定、评测基线、验收、监控各有明确工序与产出物，规模化时质量靠流程保证而不靠个人英雄，工序参考见站内 FDE 项目启动模板与 交付交接清单。
对从业者而言，FDE 类角色在大客户内部化的趋势值得认真对待——去甲方做 AI 场景交付，正在成为与厂商驻场并列的职业路径，可参考站内 FDE 职业路径与 FDE 能力模型。厂商侧如何承接同类需求、客户侧如何度量效果，可对照 NBIM 案例复盘与 国内私有化交付样本。
来源
- 新华网：银行大模型应用「加速跑」——工银智涌赋能 20 余个业务领域、200 余个场景（news.cn，2025-09-10）
- 中国电子银行网：工行大模型端到端成功率 90%、覆盖超 400 个场景、上千个专业领域智能体（cebnet.com.cn，2025-10-20）；中国金融网：2025 年银行业人工智能十大典型应用案例（financeun.com）
- 移动支付网：招行已落地 856 个大模型应用场景（mpaypass.com.cn，2026-03）；深圳金融监管局：招行全栈自研大模型技术体系（jr.sz.gov.cn）；新浪财经：工银智涌累计调用量突破 10 亿次（finance.sina.com.cn，2025-08-01）