企业官网建设流程全解析

这两年，“金融大模型规模化落地”这句话，从PPT上的愿景词，变成了消金公司KPI表里实打实的数字。消费金融大概是金融圈里离AI最近的细分领域——业务场景密集、客户量巨大、人工作业环节多，而且每个环节都能换算成成本和时效。我在这一行做了几年算法和智能运营，亲历了一个“智能客服试点”从零到一，再一步步铺到贷前审核、贷后触达、质检合规好几条业务线的全过程。过程谈不上多优雅，但坑踩得足够多，经验和教训足够拿出来聊聊。

这篇适合那些正准备把大模型从“演示Demo”推向“生产系统”的团队，也适合产品、风控、贷后运营的同学了解AI应用到底能干什么、不能干什么。我会把我们自己跑过的真实路径、算过的账、还有那些踩完才懂的细节，尽量用大白话摊开来讲。想看宏大叙事可以直接关页面了，这里只有能落地的实操经验。

1. 为什么说消金行业是大模型落地的最佳试验场

1.1 业务链路短、数据密集、人工成本高

很多人问我，为什么大模型落地案例里，消费金融的出现频率这么高？原因其实很简单：这个行业有着天然适合大模型生长的土壤。

先看业务链路。消金的单笔金额通常不大，但笔数极其庞大，这意味着每一单都要有标准化的审核、客服、还款管理流程。以贷前资料审核为例，一张收入证明、一份银行流水、一页社保缴纳记录，过去基本靠人工肉眼核对。一个人一天能审多少单？熟练的老员工撑死几十单。业务高峰时，审核团队要加班加点，人力成本直线上升，而且人看多了必然会疲劳，漏看错看很难完全避免。

再看数据密集度。消金业务从进件、授信、放款到贷后管理，沉淀了海量的结构化数据和非结构化文档。客户申请书、收入证明、银行流水、通话记录、投诉工单、催收录音，这些东西以前都躺在数据库和文件服务器里睡大觉。而大模型最擅长的恰恰就是处理这些非结构化的文本和文档，能把人话和图片里的信息抽出来、整理好、再变成业务决策的依据。

还有人工成本。消金行业的利润率并不高，对单笔成本极其敏感。很多机构一年要处理几千万次客户请求、几百万份资料，哪怕每个环节只省下几块钱，乘以业务量后都是一个非常可观的数字。大模型投入产出的逻辑在这个行业里特别清晰，这也是它能从试点走向规模化的根本动力。

1.2 边际成本与规模复利：一笔容易算清的账

大模型跟传统软件有个本质区别——它的边际成本非常低。你部署一套智能客服，不管是服务1万个客户还是100万个客户，模型本身的推理成本增长是缓慢的，而人工服务的成本几乎是线性增长的。这种边际成本结构，让消金公司很容易算清楚账。

举个例子就明白了。假设每月进来30万张收入证明材料，人工审单人均时薪折算下来，每单的审核综合成本大概在3到5元之间。引入大模型做预审后，模型先完成字段抽取、信息一致性比对、风险点摘要，人工只需要看模型标出来的异常件。哪怕模型只能把三成单子做成“无风险直过”，那也意味着每个月省下十万元级别的人工投入。一年下来，就是一笔实实在在的利润。

这种规模复利在其他行业很难看到。银行对公业务单笔金额大但笔数少，大模型省下的那点时间在总成本里占比不高；互联网大厂的AI应用虽然用户多，但多数不直接对应业务成本项，ROI反而不如消金行业这么直观。

1.3 跟银行、互联网大厂落地的关键差异

在消金公司做AI落地，跟在银行或者互联网大厂做AI落地，完全是三种打法。

银行的顾虑更多在数据安全和高可用，它们往往倾向于采购庞大的数智平台，项目周期长、决策链条重，模型能力再好，一层层的采购审批就够你喝一壶的。互联网大厂则相反，技术底子厚、人才储备强，很多团队习惯从零开始造轮子，反而忽略了业务侧真正需要什么。

消金公司介于两者之间：没有银行那么重的历史包袱，决策链条相对短；但是科技团队规模有限，不会像大厂那样什么都自研。这种局面决定了我们不可能靠堆人去解决问题，必须善用成熟的外部模型基座和工程能力，把精力放在业务场景的理解和落地路径的拆解上。说白了，在消金行业做AI，拼的不是模型参数有多强，而是谁能把模型能力快速嵌进业务流程，让一线员工真真切切感受到效率提升。

2. 大模型在消金行业的六大核心应用场景盘点

2.1 智能客服与坐席实时辅助：最容易见效的场景

智能客服是大模型在消金行业落地最早、也最成熟的方向。但我想说，真正产生业务价值的不是那个对客机器人，而是藏在背后的坐席实时辅助系统。

先说对客机器人。传统FAQ机器人最大的痛点是意图识别不准、答非所问，客户问十句它只会答三句，最后还是要转人工。大模型加上RAG知识库之后，对客户问题的理解和回答流畅度有了质的提升。但消金行业的客服场景对准确性要求极高，涉及费率、还款日、逾期影响这类问题，答错一个字都是事故。所以我们把对客机器人的定位严格限制在“标准解释+信息查询”，涉及账户操作、协商方案的一律转人工，在模型能力边界外留一道闸。

而坐席实时辅助才是真正的提效利器。客服坐席在接电话时，系统实时把客户语音转写成文字，大模型根据转写内容、客户历史信息、知识库条款，秒级生成回复要点、应对话术和政策依据，直接推送到坐席工作台的侧边栏。新人坐席拿到这个提示，相当于身边全天候坐了一位业务专家。老坐席也能少翻几个系统、少查几次知识库，把精力集中在跟客户沟通上。

落地的关键指标有三个：机器人解决率、坐席平均通话时长、一次解决率。我们曾经做过对比，开通实时辅助的坐席组，通话平均时长缩短了15%到20%，挂机后还要回查系统的时间基本被消灭了。尤其到了业务高峰期，新员工也能快速上手接电，培训周期直接缩短了一半以上。

这里有一个必须提醒的坑：实时转写对ASR（语音识别）的准确率要求很高，尤其遇到方言、吞音、嘈杂环境，转写质量一崩，大模型再强也白搭。我们的做法是，ASR结果会附带置信度分数，置信度低的时候宁可给坐席一个“本条内容仅供参考”的兜底提示，也不强撑着生成话术。另外，实时辅助对延迟容忍度极低，超过2秒坐席基本不会看，这意味着整个链路要做并行化和缓存优化，这个问题后面我还会细说。

2.2 贷前资料解析：从“人盯人”到“机审+人复核”

贷前资料审核是整个信贷流程中最耗时、最枯燥、也最容易出错的环节之一。客户提交的收入证明、工作证明、社保记录、银行流水，各种格式五花八门，有扫描件、有拍照件、有PDF、有截图，过去全靠审核员一张一张打开看。

大模型介入之后，我们做了一套“非标文档解析引擎”。流程大致是：先把图像做OCR识别和版面还原，再把识别出的文本块交给大模型做要素抽取，输出统一的JSON结构，包含申请人姓名、单位名称、职位、收入金额、开证明日期、印章有无等字段。模型还会顺带做一致性校验，比如收入证明上的金额与银行流水入账金额是否匹配，社保缴纳单位与工作单位是否一致，发现矛盾就在摘要里标红提示。

这个场景最容易踩的坑是“高估OCR的还原能力”。很多团队一上来就让大模型直接读OCR的裸文本，结果表格线和图片夹杂在一起，字段错位严重，模型抽出来的数据乱七八糟。正确的姿势是先做图像分类，区分“单证类”“流水类”“截图类”，再走不同的表格还原和字段切分逻辑，最后才轮到模型做语义抽取。还要配一套针对乱码、错位的清洗规则，脏数据进模型之前先过滤一遍。

另一个关键点是“人机协同”的分工设计。模型的作用是预审和标注，不是取代人工决策。我们的方案是“全量预审+异常转人工”，模型跑完所有进件，生成一份结构化的预审摘要和风险提示，审核员按风险等级排序处理，重点关注模型标红的异常件。低风险件直接进入下一个审批节点，人工抽检比例可以降下来。这套机制跑通后，审核团队的人均日处理量提升了大约两倍，加班情况基本消失了。

2.3 贷后触达场景的实时话术与策略控制

贷后管理，尤其是逾期客户的触达，是消金行业另一个大模型深度参与的战场。这个场景对AI应用的要求跟贷前完全不同——它不仅考验模型能力，更考验对合规红线的把控能力。

很多机构每天要打几万通触达电话，坐席人员的流动性又大，新人上来连话术都背不熟，容易讲着讲着就慌了。我们在坐席端部署了实时话术辅助：系统根据客户的逾期天数、历史还款行为、当前情绪状态，实时推荐应对话术和还款方案。比如逾期3天以内的客户，推荐温和提醒话术；逾期超过30天的客户，模型会根据策略库提示坐席分几步走，先了解还款困难原因，再给出分期或减免方案的政策边界。

这个场景里，大模型生成的每一句话都要过一道策略校验服务。比如客户问“能不能少还点”，模型不能自己拍脑袋回答，只能从预设的话术模板和政策参数里选择方案。承诺还款金额、减免比例这类信息必须从策略服务获取，模型负责组织语言，不负责产生业务规则。这一层隔离极其重要，否则模型一旦自由发挥乱承诺，后面全是纠纷。

除了合规问题，贷后场景的数据还特别偏向口语化、情绪化。客户可能骂人、可能哭诉、可能绕来绕去说不到重点，模型需要具有一定的情绪识别和对话引导能力。我们的做法是把客户情绪识别作为一个独立的分类模型输出，再把这个情绪标签喂给大模型，让它调整话术的语气和节奏。情绪激烈时先共情安抚，情绪平缓了再推进还款方案的沟通。

当然，所有触达过程都会被录音并由大模型实时转写质检，出现威胁、辱骂、诱导以贷还贷等违规话术会被自动抓取，直接推送给质检专员处理。合规是贷后的大前提，所有模型能力都要在这个前提下起舞。

2.4 智能质检与客诉分析：把“抽检”变成“全量初筛”

传统客服质检是一个靠人堆的场景。几万通录音，质检员只能按比例抽听，大约抽3%就顶天了，剩下97%的录音里有什么问题基本靠运气。漏掉的违规话术、服务态度问题、客户情绪积压，很多都在这97%里悄悄发生。

大模型改变这个局面的方式很直接：先把所有录音全量转写成文本，再用模型做分类和风险打标。模型可以识别坐席是否打断客户、是否使用禁用话术、是否未按规定告知关键信息，也能判断客户语气中的不满、焦虑、投诉倾向。质检员不再需要逐条听录音，而是看模型生成的质检结果列表，只对机器标记出的风险录音做人工复核。抽检覆盖率从3%提升到100%机器初筛加8%人工复核，风险事件发现率提高了几个数量级。

客诉工单分析也是同理。过去客诉分类靠人工打标签，标准不一、效率低下。大模型可以直接读完工单全文，自动归类投诉原因、提取客户诉求、标注情绪激烈程度，再按月汇总成客诉热力图，让产品部门一眼看到问题集中在哪几个环节。

但这个场景容易产生一个尴尬：模型检出问题，业务方却“不认账”。因为模型对风险的定义跟业务人员的判断存在偏差，模型说有风险的地方，业务人员觉得没啥大不了。我们的解法是：模型输出的每条风险判断都必须附带依据，指向具体的转写文本片段，让复核人一眼看到“这里为何被判为风险”，争议句就拿出来做人机共识校准。先让业务方信任模型，流程才有继续优化的空间。

2.5 文档作业自动化：把法务和运营从重复劳动里解放出来

消金业务里有一类不起眼却很耗人的工作——文档作业。协商还款协议、结清证明、债务情况说明、诉前调解材料，每个月要生成几千份甚至上万份，早期全靠法务和运营同事复制粘贴、改名字改日期，枯燥不说，还容易出错。

大模型在文档生成场景的表现是最稳定的，因为这类内容有极强的结构化和模板化特征。我们把一整套文档生成流水线搭起来：业务系统传入客户基本信息、还款计划、协商条件等结构化数据，模型把数据填充到预置模板里，再生成必要的段落文字，最后由法务线上复核、电子签章、归档发送。模型承担的是“数据到初稿”的翻译工作，法律效力相关的最终确认权始终掌握在法务手里。

这里面有个细节需要注意：模板不是写死的字符串拼接，而是由模型根据不同的案件类型动态选择段落组合。比如客户是首逾还是多期逾期，是否曾经失联，是否需要生成特殊的风险告知，模型需要理解业务规则并做出判断。这就得靠一套“规则引擎+模型”的混合架构：规则引擎负责硬性条件判断，模型负责软性文字生成，双方各管一摊，出了问题也容易定位。

另一个容易被忽视的点是版本管理。法律文书格式一旦调整，模板变量、措辞、条款顺序都要跟着变。如果只在提示词里改，后续很容易漏改其中一个。我们把这些文档模板做成了独立配置项，版本号跟着业务系统走，模型只是执行者，不负责“记得上次模板是什么样”。这套思路对于任何强合规场景都适用。

2.6 数据查询助手：让业务人自己捞数

最后这个场景可能不那么“性感”，但实际价值很高——数据分析师助手。消金公司的运营、产品、风控同事经常要查数，比如“近7天某个渠道的进件量和通过率是多少”“逾期M1回收率环比变化”，以前只能提工单让数仓团队跑SQL，一条数据要等半天。

大模型Agent出现后，我们用“NL2SQL”的思路做了一个内部自然语言查数工具。业务人员用大白话提问，Agent把问题拆解成指标、维度、时间范围，自动生成SQL并查出结果，再返回文字结论。逻辑上并不复杂，落地时却有个大坑：指标口径不统一。

同一个“进件量”，有人按提交时间统计，有人按审核时间统计；同一个“通过率”，分母是否剔除重复进件、测试单、无效申请，不同团队理解都不一样。模型charged生成SQL之前，必须先匹配一个指标口径词表，把问题里的业务名词翻译成标准化的字段定义，再由规则层拼接查询模板，而不是让模型自由发挥写SQL。这个前置处理做不好，查出来的数跟业务方脑子里的数对不上，工具就会被弃用。

这个场景的规模化价值在“赋能”而不是“替代”——让业务人员自己具备取数能力之后，数仓团队每天被零碎需求轰炸的时间大幅减少，能腾出手来做更深入的数据分析，间接收益比直接省人力还要可观。

3. 规模化落地的基础工程：选型、指标与成本

3.1 模型选型与部署方式：没有标准答案但有取舍

消金公司做大模型选型，绕不开三条路线：纯云端API、私有化部署开源模型、开源模型加专有小模型混合。

纯云端API的优势是效果强、上手快，但问题也很明显——客户数据和隐私不能随意出域，金融行业对数据安全的要求卡得很死，单纯依赖公网API承接敏感业务基本过不了合规关。我们见过不少团队一开始图省事接了云端API做Demo，等到真上线评审时被打回，前面的工作全白费。所以我的建议是，动工之前先找合规和安全的同事确认数据流向边界，再决定技术路线。

私有化部署开源模型是当前消金行业的主流选择。不是说开源模型效果比闭源好，而是它能让数据在自有环境里闭环，而且可以针对业务数据做定制微调。消金场景的很多任务是“文档理解+信息抽取+摘要生成”，这类任务对模型的逻辑推理要求不高，但对输出稳定性和格式规范性要求很高。中尺寸的开源模型经过针对性微调之后，表现完全够用，不需要每次都拉满千亿参数的大模型。

混合路线则更适合高频复杂场景。用一个轻量分类模型做意图路由，把简单问题交给低成本模型处理，复杂推理才上大模型。比如客服入口先由意图模型判断“这是个查询问题还是投诉问题”，查询走知识库检索加小模型回答，投诉才进大模型生成安抚和解决方案。这套路由架构能把成本降下来不少。

选型时可以重点看这几个指标：上下文长度（决定能塞进多少历史对话和文档内容）、输出JSON的稳定性（决定解析层要不要做大量兜底）、并发推理吞吐量（决定能不能扛住业务高峰）、以及对私有化环境的适配度。先跑一批自己业务场景的评测集，比看任何榜单都管用。

3.2 一套能兑现ROI的效果指标体系

很多团队做大模型项目，汇报时只会说“回答准确率95%”。问题是，业务老大听完只会问一句：准确率提升了，跟收入、成本、风险有什么关系？所以我们在规模化落地之前，先干了一件事：围绕每个业务场景定义一套“业务语言”的指标体系。

客服坐席辅助场景，核心指标是坐席对模型建议的采纳率、平均通话时长、一次解决率；贷前解析场景，核心指标是单均审核时长、操作员人均日处理量、人工抽检通过率；质检场景，核心指标是抽样覆盖率、风险事件发现率、质检人效比。先有指标，再谈模型技术指标，技术指标是为业务指标服务的。

具体操作上，我们用对照组实验来校准收益。同样一批坐席，一半开助手，一半不开，跑两周之后看通话时长和人效差异，再扣除工具使用习惯差异、业务波动等因素，得出净收益。这套方法不需要用复杂的因果推断，足够说服管理层拍板扩大推广。

3.3 RAG与Agent编排的工程要点

知识问答类场景几乎绕不开RAG（检索增强生成）。但RAG不是简单把文档切成块丢给向量库就完事。消金行业的知识库有大量政策条款、产品规则、FAQ，不同文档之间的口径可能不一致，陈旧条款和新条款可能同时存在。我们需要建一套“知识治理”机制：先做知识入库清洗，标明发布时间和适用范围；检索时优先召回时效性高、业务匹配度高的文档；模型生成答案时必须给出引用来源，用户可以直接点开原文核对。

Agent编排则是另一个层面。做数据查询助手、文档作业自动化这些场景时，模型要在多个工具之间做选择和调用。我的观点是：业务链路越关键，越不能给模型太多自由。每个Agent应该有自己的状态机，明确每一步能做什么、不能做什么。比如查询Agent只能调用指定的查询函数和指标口径表，不允许自己发明字段；触达辅助Agent只能从策略服务获取方案，不允许自己编造减免规则。自由发挥留给角色扮演类应用，业务流程里要的是确定性。

3.4 成本测算逻辑：别让推理账单吃了利润

大模型规模化的一个隐性杀手是推理成本失控。很多团队开会只谈模型效果，没人算过每笔请求到底花了多少钱，等到月底账单出来才发现成本高得吓人。

这里分享一个简单的测算口径。以坐席实时辅助场景为例，一次调用输入大约包含历史对话转写文本、政策命中片段、客户基础信息，平均在1500到2000个token之间；模型生成的输出建议话术，大概300到500个token。按中等规模模型私有化部署每百万token几十元到上百元的推理成本估算，单次调用的模型成本在0.1元到0.2元之间。如果一天几万个坐席调用，日成本就是几千元，一个月下来十几万元，这是必须提前算进项目预算的。

成本控制有几个抓手。第一，压缩输入内容，历史对话不需要全部塞进去，按策略只保留最近的几轮关键信息，输入token能减少一半以上；第二，精细化管理调用路由，能用规则或轻量模型解决的，不要大模型出场；第三，设置缓存和批处理机制，相同知识点的问题合并处理；第四，单独监控“有效调用率”，大量无效调用混在里面会让单均成本虚高，把钱花在了没有业务收益的请求上。

4. 推进节奏与组织保障

4.1 试点场景的选型逻辑

同时有六个场景想做，预算和人力却只够先试一个，选哪个？我们内部有一套选型打分卡，核心看四个维度：业务影响面、数据基础质量、KPI可量化程度、人工兜底能力。

影响面要大，最好覆盖几百人甚至上千人的作业环节；数据质量要好，历史单据、录音、工单都有完整的积累；KPI要可量化，节省多少秒、提升多少单、降低多少成本，指标必须能被数字证明；人工兜底能力要强，模型出错了能有人接住，不至于直接酿成安全事故。综合打分后，我们第一个选的场景是坐席实时辅助，而不是全流程智能客服。原因很简单：实时辅助场景里坐席是最后一道把关人，模型给的建议强行推送的，坐席可以自行判断，风险完全可控。

4.2 双轨并行与灰度切换

试点初期不建议直接替代原有流程，一定要做“双轨并行”。老的作业系统照跑，模型在旁路同步输出，专家和业务骨干每天抽样对比模型结果和真实作业结果，把差异点一条条记录下来。双轨期一般跑两到四周，攒够一定量的badcase样本后，再决定要不要切换。

切换也不是一把梭。先切5%到10%的低风险流量，观察一段时间，确认各项指标稳定后再慢慢扩大。灰度期间要设好监控看板：接口成功率、响应时长、模型输出合规率、业务方投诉量，任何一个指标出现异常都可以一键回滚。金融业务对稳定性的要求极高，宁可灰度期拉长一点，也不要让一次线上事故毁掉整个项目组的信任。

4.3 模型运营机制：Prompt也是代码

大模型上线后，真正的重头戏是运营。很多项目死就死在“模型上线即终点”——没人管、没人迭代、效果下滑没人发现。

我们的做法是把模型配置当作代码来管理。每一个场景对应一套独立的Prompt配置，版本号、修改人、上线时间、关联的评测集全部记录在案。Prompt的任何改动都必须走评审流程，先离线跑回归评估集，确认不损伤其他场景后再上线。每周固定做badcase复盘，从线上日志里捞一批模型表现不佳的样本，分类归因，再针对性修正Prompt或补充知识库内容。

模型效果还会随着业务环境和数据分布变化自然衰减。比如新的产品政策出台后，模型不知道新规则，回答就会出问题。所以每次业务规则变动，都要同步更新知识库和评测集，把模型运营纳入业务变更流程的一部分，而不是等出了问题再来补救。

4.4 合规评审与内容风控机制

金融行业的AI应用，合规永远排在效果前面。每个模型上线前都要过一套内容安全测试集，包含敏感词、拒答、隐私泄露、承诺性表述等类型的测试用例。模型输出的内容还要经过一层规则过滤，命中禁用语就直接拦截，不给推送。

数据安全上要做到三个“不”：原始客户信息不进模型训练集、对话请求中所含个人信息按要求脱敏、模型日志中的敏感字段加密存储。处理贷后触达场景时，所有涉及承诺还款方案的内容都由策略服务统一控制，模型只做语言组织，不做方案设计。一步都不能省。

5. 常见问题与排查技巧实录

5.1 模型幻觉怎么拦

大模型的幻觉问题在消金场景是致命的。客户问逾期几天上征信，模型张口就来一个错误天数，轻则投诉，重则纠纷。我们的防线是层层拦截的。

知识库引用溯源是第一道防线。模型回答必须附带知识库原文出处，内容中涉及费率、日期、政策等硬性信息，系统会从原文中匹配关键片段做比对，不一致就对坐席提示风险。第二道防线是规则白名单，凡是能枚举的硬性参数都走规则或数据库取值，不让模型从记忆里生成。第三道防线是置信度判断，模型输出得分低于阈值时，默认给“请以人工回复为准”的兜底文案。重要场景宁可答不了，也不能答错。

5.2 业务方说“效果还行但ROI算不过来”

这个问题太常见了。团队忙活几个月，Demo很惊艳，一到汇报ROI就抓瞎。根源在于一开始没有对准业务KPI。

做项目之前就跟业务方一起把改善目标写下来：通话时长缩短15%、单均审核成本下降30%、质检人力节省一半。模型上线之后就盯这些数，而不是盯模型的准确率。业务方要的不是一个聪明的模型，而是一个能帮他们完成绩效指标的“生产力工具”。一旦指标对齐，ROI根本不用你解释，看报表就行。

5.3 系统上线了但没人用

坐席和审核员的真实心态：工具不好用，宁可用自己熟悉的老办法。我们的第一版实时助手功能放在一个独立弹窗里，结果打开率不到四成。后来把提示内容直接嵌入坐席原本的工作台侧边栏，跟客户信息展示放在一起，不需要额外操作就能看到提示，打开率立刻到了九成。

推广期还要安排“种子用户”机制。每个小组挑一两个接受度高的业务骨干先深度使用，跑出真实效果案例后由他们向组内分享，比任何自上而下的宣贯都有用。大模型工具对一线人员来说是个新东西，焦虑和抵触很正常，关键是把学习成本降到最低。

5.4 模型输出不稳定，JSON老是解析失败

做结构化输出时这是最大的坑。让模型“保证输出JSON”基本是伪命题，解析层不能依赖模型的自觉。我们的做法：用上下文约束加输出校验，模型生成后先做一次JSON解析尝试，失败就触发自动重试并附加上一轮错误信息；重试仍失败就走降级逻辑，转交规则模板处理。后置解析的重点是不让任何一次模型输出因为格式问题阻塞业务流程。

5.5 一次真实事故复盘：接口超时拖垮了整个坐席工作台

最后讲一次我们自己的事故。某次大版本上线后，实时辅助接口的并发处理能力没跟上，晚高峰时响应耗时飙到5秒以上，而且因为设计时把接口调用和坐席工作台主流程放在了同一条链路上，结果模型响应慢了，坐席的页面也跟着卡，客户都等得不耐烦了，坐席还在转圈。那天晚上的投诉率直接翻了一倍。

事后我们做了三件事：第一，大模型调用全部改成异步模式，模型响应慢就慢，坐席工作台不再阻塞；第二，设置超时熔断，超过1.5秒就返回兜底提示，不让模型拖累核心作业流程；第三，加了一层并发限流，高峰时段排队请求自动丢弃并降级，保证系统整体稳定。这次事故让我们明白了一个原则：AI是给业务加分的，不是给业务流程添堵的。任何大模型的调用都不能成为关键路径上的单点故障。

最后再分享一点个人体会

做了这几年消金大模型落地，我最大的感受是：大模型永远只是“发动机”，真正跑的其实是业务流程、数据基础和团队协作这辆“整车”。同样的模型底座，有人能跑出几倍的人效提升，有人只能做出一个没人点开的Demo，差别不在模型，在落地的方法论。

如果让我给准备动手的团队提三条建议：先找数据最干净、ROI最好算的场景试点，而不是最炫酷的场景；先在组织里统一“怎么衡量成功”的指标口径，再写一行模型代码；先设计好人工兜底和合规评审机制，再谈自动化和效率提升。个人经验是，只要这三件事做到位，即使模型效果只算及格，项目也能顺利跑起来，后面再慢慢迭代优化也不迟。