银行 · 行业场景库

岗位依据

岗位依据与数据 · WorkBuddy · 银行场景库

4 个子角色为什么这样切，依据在哪

公开的组织架构与操作规程写的是「公司金融部—授信审批部—风险管理部」前中后台分离、双人审查、贷审会多数决。但真实运行是另一回事：农商行一线自述「既当柜员、又当客户经理、还兼任保洁和保安」；多家农商行的贷后检查由客户经理本人承担，「管贷分离」执行不理想；某农商银行全行消保服务岗只引进 1 人，却要应对监管转办、十五日办结时限、月度分析与年度评价四件事。某城商行披露客户经理平均需登录 3-4 个系统、操作环节超过 20个——这已是数字化程度较好的城商行。

所以这套场景库按一笔贷款从申请到投诉的生命周期划分，而不是按组织架构图的部门划分：贷前凑材料写报告的（客户经理与尽调）、上会前挑毛病并给条件找参考的（审查审批）、放款前逐条核凭证与放款后盯资金流向的（放款与贷后）、贷款出了问题接住客户和监管的（消保投诉）——这四类活在中小银行里往往由两三个人接力完成，区别只在什么时候来、错了会怎样、产出物是什么。全部 8 个场景共用同一家虚构银行与同一笔贷款，数据互相咬合，演示时可以从一单投诉倒着讲回到尽调漏掉的疑点。

客户经理与贷前尽调

Account Manager & Due Diligence

在客户不配合、材料永远缺三项的前提下，交出一份经得起审查岗追问的调查报告。

2 个场景

这个子角色为什么真实存在：操作规程要求 A/B 角双人调查、报告签字盖章、五个工作日出报告；真实状态是一名客户经理同时压着四笔业务，报告写到凌晨是常态申请材料清单 20 余项（审计报告、半年流水、征信授权、购销合同、权属证明），材料收集本身就是最大的时间黑洞厂商披露尽调环节 80% 人力时间花在报告撰写与数据录入上，而非见客户与判断风险

公开来源：某农商行《企业贷款操作规程》：受理2个工作日、调查评价5个工作日、A/B角客户经理制且报告须签字盖章、审查双人制、贷审会5个工作日对公客户经理一日纪实：手上同时压4笔待推进贷款（A报告初稿未完成、B资料缺三项、C待回复风控5个问题、D刚收材料），叠加监管检查「无休止补台账、调档案、写整改说明」某金融科技厂商披露：对公信贷审核资料90%为PDF/图片等非结构化数据；尽调环节80%人力时间用于报告撰写与数据录入

它实际在用的数据：本行信贷系统里的存量客户档案与历史授信批复（客户经理有权限但散在各处）客户提交的审计报告 PDF、半年流水 Excel、购销合同扫描件（格式不一的原始件）人行征信报告、税务发票数据、抵押登记凭证（分别躺在征信查询岗、放款中心、政务系统）微信工作群里散落的风控质询与补充材料通知

关键字段与口径：调查报告九大项法定内容：治理与团队资信、行业、财务、关联方、用途、还款来源、担保等（《流贷办法》第十六条）每个关键数据段须附来源引用（财报页码/征信条目/合同编号），A/B 角签字栏与日期栏

本组场景：

• CM-01 基于本行档案的尽调报告初稿 —— 数字全部来自本行系统、每段可溯源 · 优先级 7.3
• CM-02 尽调五摊资料聚合 —— 资料齐备度面板，缺什么、找谁要 · 优先级 7.3

升为客户真实案例还缺什么：要真正跑起来，需要客户经理提供：本行调查报告模板一份、近三个月做过的任一笔对公贷款的全套材料（脱敏即可）、信贷系统导出的存量客户列表。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

授信审查审批

Credit Review & Approval

在别人写好的报告里挑出真问题，并把历史上给过的条件找出来供贷审会参考——结论由人签字，责任终身。

2 个场景

这个子角色为什么真实存在：规程要求双人审查、贷审会多数决、委员匿名表决且对结果终身负责——责任压力集中在这一环节头部农商行才有「三台六岗、三名独立审查人共同决策」，多数中小行审查岗是一个人对着几十页材料，且要看多个支行的项目本行的历史批复是独有的风控资产，但散落在信贷系统与纸质档案里，同类客户批过什么条件全凭老审查员的记忆

公开来源：某农商行指导意见：贷审会匿名表决、委员对表决结果终身负责、一把手不参与审议只对结果一票否决某农商行「三台六岗」：营销/审批/贷后三平台及六专业岗，大额复杂业务三名以上独立审查人共同决策——反证多数农商行未实现岗位分离某城商行披露：客户经理平均登录3-4个系统、操作环节超20个；同一客户行业投向在不同系统经常矛盾

它实际在用的数据：本行近三年全部授信批复（含前提条件、约束指标、否决理由）——躺在信贷系统附件里上报的调查报告、客户财务材料、征信报告本行不良贷款复盘记录与被监管指出过的历史问题

关键字段与口径：审查报告五方面：基本要素、主体资料、贷款政策、贷款风险、审查结论批复文书：金额、期限、利率、担保条件、前提条件（如办妥他项权证后方可放款）、放款审核要求

本组场景：

• AP-01 授信审查疑点清单 —— 在别人写好的报告里挑出真问题 · 优先级 5.9
• AP-02 历史批复条件检索 —— 同类客户当年批过什么条件，一查便知 · 优先级 7.0

升为客户真实案例还缺什么：需要审查岗提供：近三年批复文书汇编（脱敏）、本行审查报告模板、一两个历史否决案例的完整材料。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

放款与贷后管理

Disbursement & Post-loan Management

在放款业绩压力和十五个工作日检查时限的两头挤压下，把批复条件逐项核成实质凭证、把本行流水里的挪用痕迹找出来。

2 个场景

这个子角色为什么真实存在：「批复条件全部勾选完成、放款不久风险暴露」是大量不良复盘的共同起点；只办抵押受理登记未取得他项权证就放款是典型变通官方文章承认贷后检查闭门造车、小额贷款从未检查；审计局案例实锤「贷后检查报告套用模板」，罚单逐个点名客户经理本人资金转入同名账户后跨行追踪断裂，一线原话「睁一只眼闭一只眼」——本行流水内的异常链路是唯一可计算的部分

公开来源：金溪县贷款管理办法：首笔发放后15个工作日内首次检查、此后至少每季一次；检查报告及材料须移交入档某地审计局公开案例：A农商行客户经理套取信贷资金190万元，审计原话「贷后检查报告套用模板」「贷后检查执行流于形式」某媒体：借款人通过同名账户划转规避受托支付，资金转入同名账户后银行无法追踪实际去向，风险无法及时识别

它实际在用的数据：批复文书与前提条件清单、抵押登记受理凭证与他项权证扫描件（放款中心档案）本行账户流水（放款账户的进出明细）——挪用痕迹在本行侧的可计算数据贷后检查计划台账（Excel，谁用谁维护，检查前突击补是常态）借款人的水电、税务、社保代扣数据（本行代发代扣渠道沉淀）

关键字段与口径：贷后检查报告四段结构：基本情况→贷款检查情况（用途/本息/押品）→检查分析→检查结果（五级分类认定意见）检查频率：首次（放款后15个工作日内，查用途与流向）+定期（每季/每半年分档）+风险触发加查；报告须移交入档

本组场景：

• PO-01 批复条件落实核查 —— 已落实/形式资料/缺实质证据，三色核到底 · 优先级 8.0
• PO-02 基于本行台账的贷后检查报告 —— 数据自动填充，消灭只改日期的雷同报告 · 优先级 11.0

升为客户真实案例还缺什么：需要放款中心提供：任一笔已放款对公贷款的批复文书、放款流水（脱敏）、对应贷后检查报告一份、本行贷后检查模板。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

消费者权益保护专员

Consumer Protection Officer

全行一到两个人，接住 12378 转办的每一单工单，在十五日时限内交出三要素齐全的答复函，还要扛住年度监管评价。

2 个场景

这个子角色为什么真实存在：全行消保岗仅 1-3 人，JD 里制度、审查、投诉、报送、宣教、监管沟通全部归一个人法规硬时限：事实清楚的投诉 15 日内作出处理决定并告知，答复须含核实情况/依据理由/救济途径三要素，登记存档备查某省全省农商行一年监管转办投诉仅 263 件——痛点不在量，在时限倒计时没人盯、历史答复口径散在旧文档里、溯源整改没人做

公开来源：某农商银行2024年消保服务岗JD：全行引进1人，管制度制订、消保审查、投诉处理、监管报送、金融宣教、与监管沟通全部事项，要求法律职业资格优先《银行业保险业消费投诉处理管理办法》：15/30/60 日办结时限、答复须含核实情况/依据理由/救济途径三要素、登记与档案制度某省农信2024年全省农商行监管转办投诉仅263件且办结率100%——中小银行消保痛点不在量，在时限、文书与问责

它实际在用的数据：投诉工单系统/《投诉台账.xlsx》（工单号、来源、收到日期、类型、状态）历史答复函与处理口径（散在历年文件夹里，是本行独有的私有资产）涉诉业务凭证、合同文本、录音双录、涉事条线说明（分散在柜面、远程银行、法务四处）

关键字段与口径：答复函三要素：核实情况、决定依据和理由、救济途径（核查/调解/仲裁/诉讼）；告知方式留痕栏台账必备列：工单号、来源（12378/来电/来访）、收到日期、15日时限倒计时、类型、状态、办结日期、超时标红

本组场景：

• CP-01 投诉工单分类分办与超期预警 —— 15 日时限倒计时，一屏盯到底 · 优先级 9.6
• CP-02 基于历史口径的投诉答复函初稿 —— 三要素齐全、口径有出处 · 优先级 11.0

升为客户真实案例还缺什么：需要消保岗提供：近一年投诉台账（脱敏）、两三份历史答复函原件、本行答复函模板、监管转办函样例一份。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

不做什么

明确不做的伪需求 · WorkBuddy · 银行场景库

22 个伪需求以及为什么不做

客户看到「四十个场景」的第一反应不是「好全」，而是挑最不靠谱那个来问。

一个伪需求会削弱旁边所有真场景的说服力 —— 所以这一页存在的意义，是让 15 个真场景更可信。

银行是伪需求的重灾区，因为它两头受压：一边是六千余张年度罚单，一边是厂商「一天干完原来一周的活」的方案书。判断只需要三句话：这张表现在有人看吗？这个数据现在有人维护吗？如果 Agent 明天就把这件事做完了，下游的人会不会因此改变行为？第三句答不上来，就不要做。另有四类需求不是伪需求，是红线——代签审批、代出授信结论、代答监管问询、对客承诺——这四类不做的原因不是做不到，是责任不能由系统承担。

3

法则一 · 一段脚本更快更准更便宜

4

法则二 · 需物理感知或对外担责

8

法则三 · 真实瓶颈不在这一步

!

最典型的一条：办公用品领用登记电子化

它看起来完全合理：纸质登记乱、统计麻烦、月底要追问还剩多少。

但制度里写着「月度汇总提交采购与财务作成本核算依据」——

现实中签完字这件事就结束了，汇总表没有人看。

把一张没人看的表加速录进系统，等于加速垃圾数据入库。

真正有价值的是另一个问题：为什么某个部门的耗材是别人的三倍。

清单逐条说明

最后一列是客户主动提出时的回应口径 —— 不是拒绝，是把他引到真场景上

伪需求命中法则

更优解 / 真实瓶颈在哪客户提出时怎么回应

AI 代签审批、代放款红线 · 签字即担责审批人签字承担行政与刑事责任，罚单普遍「机构+个人」双罚（某农商行一张罚单点名 5 名个人）现场话术：我们做的是放款前核查清单（PO-01），把「能不能放」的证据摆齐，签字和指令永远是人。AI 直接出授信结论、给额度红线 · 核心决策担责授信结论由审查岗与贷审会负责终身，监管与行业共识明确核心决策链条不容系统担责现场话术：AI 出的是疑点清单（AP-01）和历史条件参考（AP-02），结论栏留空——这恰恰是能落地的形态。AI 代答监管问询、代交监管报送红线 · 对监管陈述担责对监管提交的材料由负责人签章担责，未经核实的内容构成虚假陈述风险现场话术：AI 只做资料聚合、编目与初稿，核实与签发是人。监管问询调的是资料，不是答案。AI 对客承诺（智能客服赔偿/息费减免）红线 · 对外承诺银行是 AI 客服投诉最集中的行业，监管明确「AI 回答不代表公司立场」不能作为免责理由现场话术：对客环节必须人工。AI 只做内部坐席辅助与工单预填

（CP-01 的边界就是这么画的）。1104/EAST 报表字段级校验交给大模型法则一 · 确定性规则任务字段校验是确定性规则，脚本/规则引擎更快更准更便宜；有从业者已用脚本把复核从五天压到五分钟现场话术：这是脚本的活，别用大模型。AI 的位置在「口径差异解释」和「异动说明初稿」。反洗钱可疑交易报告全自动生成法则一+二 · 识别靠规则引擎可疑交易识别是规则引擎的活，报告需合规岗签责，生成环节价值薄且合规敏感现场话术：识别和报告先让现有系统跑，我们不做这个。通用行业研究报告、通用文案生成法则一 · 无私有数据输入通用大模型免费可得，且没有本行数据输入，无付费理由现场话术：这个通用工具已经够用，我们的功夫花在本行台账和档案上——那是通用工具够不着的。信贷档案 OCR 批量录入（独立的 OCR 项目）法则一 · 规则任务OCR 本身是规则任务；价值在于为尽调与贷后场景供数，不该独立立项现场话术：要跑的是尽调（CM-01）和贷后（PO-02），档案识别是它们的输入，不是卖点。抵押物价值自动评估定价法则二 · 评估资质担责押品评估须有资质的评估机构出具并担责，AI 无资质也不能担责现场话术：AI 做的是比价底稿（AP-01 里那套同区处置价对照），评估值还得评估机构出。五级分类自动认定法则二· 认定担责分类认定是信贷主管与风险部的责任，直接影响拨备与监管指标现场话术：PO-02 给的是「分类建议+流水依据」，认定栏留空——建议有出处，认定有人签。智能外呼营销/催收机器人法则二 · 对外承诺风险AI 外呼的承诺口径失控已是投诉重灾区，2026 年人机协同国标刚划了红线现场话术：对客动作我们不碰。催收场景里 AI 能干的是记录分析，不是打电话。贷款合同自动签署、电子签自动触发法则二 · 法律效力动作签署是有法律效力的动作，触发权与核验义务不能交给系统现场话术：放款指令、合同签署一律人工——PO-01 核查单的终点就是「人签字」。客户拜访模拟、营销话术 AI 陪练法则三 · 一线已证伪银行一线实证反馈「提升有限，模型幻觉反而增加人工校验负担」现场话术：这个场景行里试过的同行普遍说没效果。您真正没人干的活是批复条件落实核查，要不看这个？智能网点数字人大堂经理法则三 · 瓶颈不在接待网点引流的瓶颈不在「没人接待」，数字人落地效果差的案例普遍现场话术：与其做大堂数字人，不如把晨会简报和台账这些每天真在发生的活接住。信贷资金跨行全链穿透追踪法则三 · 数据可得性资金跨行、提现后链路断裂是数据可得性问题，需要监管层面的全行业机制，不是算法问题现场话术：AI 能做的是本行账户内的异常链路清单（已并入 PO-02 的流水分析）——跨行部分如实标注「链路止于划出」。雷同贷后报告的「提速版」法则三 · 瓶颈不在写作速度报告雷同不是写的人懒，是没人看、数据也拿不全——提速一百倍还是没人看现场话术：我们做的是数据驱动版（PO-02）：数字来自本行台账、异常可追溯，雷同的根子没了。AI 预测宏观/行业周期做信贷决策法则三 · 问责机制审批人不信任也无法为模型预测担责，真实瓶颈是数据与问责机制现场话术：能落地的是行业速览叠加本行存量客户案例——判断还是人做。员工培训考试题自动生成（独立场景）法则三 · 价值密度低生成可行但价值密度低，单独立项撑不起预算现场话术：作为消保条线的附带能力送，不单独立项。「一键上会」的终稿直交贷审会法则三+红线 · 流程责任贷审会材料的完整性核验与签批链是流程责任，跳过复核的「终稿」没有行里敢用现场话术：我们交的是初稿+疑点清单，复核、签批、上会一个环节都不少。建全行数据中台再上 AI法则三· 前车之鉴某城商行 2000 万的中台三年使用率不到 15%——IT 主导建设、业务继续用 Excel现场话术：不要求先建中台。原件直接扔进来，按场景逐个跑通，跑一个立一个。员工情绪监测、离职预测红线+法则三 · 隐私与信任员工行为数据的使用本身有合规与信任风险，且不解决业务问题现场话术：这个不做。我们碰的都是业务单据，不碰人。智能风控评分模型自建法则三 · 组织承接力中小行缺数据底座与科技团队，模型上线后无人维护的案例普遍（智能客服三个月准确率从 90% 掉到 60%）现场话术：不建模型。用规则核对+本行历史数据，业务人员自己就能维护。

声明这套东西不承诺什么

主动讲限制比被问出来强得多

这是演示与验证资产，不是已接入生产系统的软件所有 Live Demo 页面展示的是「应该怎么跑、每一步看什么、交付什么」，使用的是真实业务格式的脱敏构造数据，不冒充任何客户的生产数据。不承诺效率提升百分比本场景库不出现任何「几天压到几分钟」「节省百分之九十」这类数字 —— 没有用客户自己的单据实测过，这种数字说出来就是砸口碑。我们讲的是可核实的能力差异：参与角色怎么变、覆盖范围多大、产出多少条。拿不到的数据会明确说拿不到借款人他行账户流水、抵押物实时市价、跨行资金去向 —— 这些情况会在报告里写清「本项无法分析，本行侧链路止于划出」，而不是估一个数填上去。高风险动作只建议不执行授信结论、放款指令、贷款分类认定、提前收贷决定、对监管报送、对客答复 —— 这六类动作本场景库全部只出清单和依据，不代替人做决定，也不自动执行。产出是初稿与清单，最终签字权在人所有正式交付物都留有编制 / 审核 / 会签 / 批准签批栏，推荐意见、完成质量评定、责任认定这几栏一律留空 —— 自己给自己打分的报告，没人会信。

那哪些是真场景？15 个逐条打过分的场景，全部保留了评分口径可核

回到场景总览 →

来源说明

本场景库的痛点均有公开来源可查。网页版已对来源中的具体机构做了脱敏处理，不再逐条列出。

场景审核

场景审核 · WorkBuddy · 银行场景库

先过场景不急着做素材

共 8 个场景。逐个点「保留 / 待讨论 / 后置」，

结果只保存在本机浏览器，可以复制出来。

建议的判断顺序：先问这件事没做好谁会生气（痛感）→

再问错了能不能当场看出来并改（能不能交给 Agent）→

最后问客户手上现有的文件够不够跑（落地难度）。

需要客户先做数据治理的场景，不要放在第一批。

清空选择

返回总览

客户经理

客户经理与贷前尽调

在客户不配合、材料永远缺三项的前提下，交出一份经得起审查岗追问的调查报告。

2 个

CM-01

7.3

基于本行档案的尽调报告初稿 —— 数字全部来自本行系统、每段可溯源调查报告看起来是写作活 · 实际上八成时间在抄材料和录数据

保留

待讨论

后置

CM-02

7.3

尽调五摊资料聚合 —— 资料齐备度面板，缺什么、找谁要尽调最难的不是判断 · 是凑齐散在五个地方的材料

保留

待讨论

后置

审查审批

授信审查审批

在别人写好的报告里挑出真问题，并把历史上给过的条件找出来供贷审会参考——结论由人签字，责任终身。

2 个

AP-01

5.9

授信审查疑点清单 —— 在别人写好的报告里挑出真问题审查岗的职责是挑毛病 · 但一个人的眼睛盯不过三个支行的上报项目

保留

待讨论

后置

AP-02

7.0

历史批复条件检索 —— 同类客户当年批过什么条件，一查便知本行三年的批复是最值钱的风控资产 · 但它躺在系统附件里没人能检索

保留

待讨论

后置

放款贷后

放款与贷后管理

在放款业绩压力和十五个工作日检查时限的两头挤压下，把批复条件逐项核成实质凭证、把本行流水里的挪用痕迹找出来。

2 个

PO-01

8.0

批复条件落实核查 —— 已落实/形式资料/缺实质证据，三色核到底批复条件全部打勾完成 · 不等于条件全部落实完成

保留

待讨论

后置

PO-02

11.0

基于本行台账的贷后检查报告 —— 数据自动填充，消灭只改日期的雷同报告贷后检查报告人人都在写 · 审计局的原话是「套用模板」

保留

待讨论

后置

消保投诉

消费者权益保护专员

全行一到两个人，接住 12378 转办的每一单工单，在十五日时限内交出三要素齐全的答复函，还要扛住年度监管评价。

2 个

CP-01

9.6

投诉工单分类分办与超期预警 —— 15 日时限倒计时，一屏盯到底消保岗只有一两个人 · 但每一单工单的时钟都在走保留

待讨论

后置

CP-02

11.0

基于历史口径的投诉答复函初稿 —— 三要素齐全、口径有出处答复函看着是一封信 · 实际是监管评价里「纠纷化解」的计分题

保留

待讨论

后置

审核进度未选择 8

交付说明

交付说明 · WorkBuddy · 银行场景库

银行场景库怎么用这套东西

这是一套售前演示与客户验证资产，不是已经接入客户生产系统的软件。

包含 4 个子角色、8 个场景、24 个内容页、

8 个 Skill 包与配套素材和预期输出。

8完整场景

24三件套页面

22明确不做的伪需求

39可核验来源

路径三种人怎么看

客户初次看

从总览按子角色选场，先看「场景引入」。三分钟看清这件事现在什么样、痛点依据在哪、产出是什么。

打开场景总览

现场演示

打开「Live Demo」逐步讲。重点讲 Agent 在哪一步拦住了 ——

一、个会在该停的地方停下来的助手，比一个永远给得出答案的助手可信得多。

看一个完整 Demo

内部选型

在「场景审核」页逐场标保留 / 待讨论 / 后置，复制结果后再决定哪些进入真实素材制作。

打开场景审核

话术现场必备的三句话

开场 · 先说 AI 做不到什么

把限制先摆出来：不承诺效率百分比、拿不到的数据会说拿不到、高风险动作只建议不执行。

主动说限制比被问出来强得多 —— 而且这一句会把后面所有内容的可信度垫起来。

中场 · 用一句话帮客户剔掉伪需求

客户提到某个表单类需求时，问一句：「这张表现在有人看吗？看完做了什么决定？」

答不上来就当场建议先不做。这一下建立的是顾问式信任 ——

客户会开始相信你不是来卖东西的。

收尾 · 三个问题要金额

「你们上一年抽查过多少份贷后检查报告、发现过几份雷同的？被监管点名之前，有没有人逐条核对过批复条件的实质凭证？投诉台账里的时限倒计时列，现在是哪位在维护？」

三、问都答不上来，场景就成立了。

状态已完成与未冒充完成

已经完成4 子角色 × 8 场景完整内容每场景：场景引入 / Live Demo / 能力沉淀 三页每场景：Skill 包（含输出骨架与渲染脚本）、素材、预期输出痛点逐条挂来源，可点开核对22 个伪需求逐条说明命中哪条排除法则岗位依据页说明子角色为什么这样切

明确未冒充完成尚未接入任何客户的生产系统素材是真实业务格式的脱敏构造数据，不是客户生产数据场景尚未用客户自己的原始文件实跑过（这是下一步）有来源支撑不等于完成客户一手验证没有实测前不出现任何效率提升百分比授信结论、放款指令、贷款分类认定、提前收贷决定、对监管报送、对客答复一律人工

下一步怎么往前推

第 1 步过场景8 个逐场标保留 / 待讨论 / 后置

第 2 步选 3 到 5 个按客户类型组合，优先零集成的

第 3 步要一手材料真实文件、审批链、一次出过问题的案例

第 4 步用客户文件实跑记录结果、返工点、真实耗时

第 5 步再谈系统对接此时才评估 API、权限与回写