项目概览
从“人力集约”走向“数智化能力集约”
这不是把六项系统操作简单从支行客户经理搬给分行集约岗，而是把任务流转、资料组织、数据复用和责任确认一起产品化。
这不是把六项系统操作简单从支行客户经理搬给分行集约岗，而是把任务流转、资料组织、数据复用和责任确认一起产品化：一期先建立可发起、可分配、可跟踪的流程骨架；二期再把图片/PDF 转为可分类、可抽取、可追溯的可信数据要素，让多个贷前作业共享同一笔贷款的资料与数据。
项目聚焦法人 e 抵、个人 e 抵贷前集约场景。分行集约岗集中承接法人建信、押品录入、台账录入、合同录入、线上抵押登记申请、作业监督六项标准系统作业，但只负责代执行与暂存；支行客户经理仍保留客户经营、尽调、业务事实确认和最终审批提交责任。项目的核心目标，是把支行专班依赖熟练人员的“人力集约”，升级为可复制、可管理、可继续自动化的“能力集约”。
- 抵押类处理周期
- 约 5—8 → 3—5 个工作日既有支行专班业务基线，非系统上线成效。
- 单笔客户经理事务性工时
- 约 5.66 小时用于说明集约方向价值，正式价值需试点重新测量。
- 复杂场景无序影像
- 约 100 张 / 笔用于解释二期资料智能整理的关键性。
业务调研与问题发现
集约方向已经验证，但真正需要沉淀的是平台能力
支行已经通过“前台营销 + 中台集约”验证了专业分工的价值。项目启动后，我进一步进入业务现场，通过跟岗、访谈和流程建模还原真实作业，重点判断：哪些经验可以标准化、哪些事务可以集约，以及支行人力模式如何进一步升级为分行可复制的平台能力。
01｜前台营销 + 中台集约，方向已经被业务验证
客户经理
- 客户触达
- 融资沟通
- 实地尽调
- 风险判断
中台集约岗
- 标准系统操作
- 合同处理
- 影像处理
- 流程跟进
通过专业分工，把客户相关和需要业务判断的工作更多保留在前台，把可标准化的系统事务集中处理。
- 抵押类业务处理周期
- 5–8 天 → 3–5 天
- 旺季标准化业务处理
- 200+ 笔
- 前台营销工时释放
- 800+ 小时
*以上数据为支行既有人力集约模式的业务基线，用于说明集约方向的可行性，并非本项目系统上线成效。
02｜先还原真实作业，再判断系统应该解决什么
项目并不是收到“做 AI / 做平台”的需求后直接开始设计，而是先进入支行现场，回答谁在做、怎么做、在哪些系统做、依赖什么资料，以及耗时和异常发生在哪里。
- 01
跟岗实操
跟随中台人员实际办理贷款，观察真实操作顺序与系统动作
- 02
人员访谈
访谈客户经理、中台及相关业务人员，理解任务、诉求与隐性规则
- 03
流程建模
按客户、客户经理、中台、审批与系统交互，还原业务流程图
- 04
材料梳理
梳理资料、字段、节点耗时和异常场景
- 业务流程图
- 系统交互清单
- 资料 / 字段清单
- 节点耗时与异常基线
业务流程图
把角色分工、系统交互与节点耗时放在同一张图中，定位交接与重复操作。点击预览可放大阅读完整流程。
03｜问题不在某个页面，而在能力没有被沉淀
组织集约 ≠ 能力集约
专班通过岗位分工和人员熟练度提升了效率，但关键流程、资料规则和操作经验仍大量依赖熟练人员。
人员可以集中，经验必须进一步沉淀。资料与数据仍在人工搬运
客户、企业、押品、贷款和合同信息散落在纸质资料、扫描件和多个业务系统中，同一事实仍需要反复查找、复制和录入。
后续需要沉淀的是可复用的资料与业务数据，而不只是附件。分行化以后，协作必须产品化
支行专班可以依靠同地办公和熟练人员直接沟通；当集约岗位上收到分行后，任务状态、资料交接、审核退回和责任链不能继续依赖“人找人”。
原来隐藏在线下协作里的能力，需要被系统显性承载。一个看似减负的动作，可能只是把工作转移给另一个角色
- 一次上传
- 近百张无序影像
- 人工重新整理
为减少客户经理整理资料的时间，可以一次性扫描上传整笔贷款资料。但扫描图片通常没有文件名，多份多页合同混在一起时，单笔可能形成近百张无序影像。
如果系统只是完成“上传—下载”，分行集约岗仍需要重新找图、分类、排序和重组合同。
真正要减少的是全链路无价值人工，而不是某一个岗位的操作次数。
从“人力集约”升级为“能力集约”
如何把已经验证有效的“前台营销 + 中台集约”，从依赖人员经验的人力集约，升级为由流程标准、资料规则、统一数据和线上协作共同支撑的分行级能力集约。
人力集约
- 岗位分工
- 熟练人员
- 线下协作
能力集约
- 流程标准
- 资料标准
- 统一数据
- 平台协同
SOLUTION DESIGN
从人力集约到能力集约：把组织、流程与资料数据沉淀成平台能力
调研后，我们没有把问题拆成一组孤立功能，而是沿着“先明确责任边界、再搭建流程骨架、最后沉淀资料与数据能力”的路径推进。目标不是简单把客户经理的工作搬到分行，而是让分行集约具备可复制、可协同、可持续优化的平台能力。
整体建设逻辑：组织与责任先明确，流程负责协同，资料与数据形成作业底座，标准化以后再逐步向自动化演进。
01｜先定责任：明确什么可以集约
客户经理继续承担客户经营、尽调、业务事实确认和最终提交；分行集约岗集中承接可标准化、事务性的系统作业。
作业可以集约，业务责任不能简单转移。02｜流程是骨架：让支行与分行在线协同
将业务发起、任务分配、待办处理、暂存审核、退回补件、消息提醒和状态跟踪统一纳入线上流程，让原来依赖“人找人”的协作转变为可追踪的任务机制。
组织位置变化以后，任务、状态与责任必须被系统显性承载。03｜资料与数据是底座：让一笔贷款的数据真正复用
汇聚客户资料、客户经理补充信息和业务系统数据，通过 OCR、分类、字段抽取与人工确认形成统一数据要素，再用于业务材料生成、标准影像资料包以及法人建信、押品、台账、合同等集约作业。
资料不是终点，形成可复用的可信业务数据才是。NEXT｜自动化演进
后续规划当流程、字段和资料都逐步标准化后，再进一步通过 API / RPA 实现外部系统自动录入、影像上传和辅助暂存。
先标准化，再数字化，再智能化与自动化；真正要减少的是全链路无价值人工，而不是把工作从客户经理转移给集约岗。Next → 产品与系统设计：这些能力最终如何落成一个可运行的平台？
关键产品决策
面对真实约束，为什么这样选
这一章不是功能清单，而是面对规模、语义复杂度、金融合规与持续迭代约束的产品取舍：左侧决策列表，右侧单项详情。
一期和二期分开
- 业务约束
- 3 月需要先形成可运行的集约流程，而资料、AI、数据治理和外部系统联动复杂。
- 产品决策
- 一期只解决流程配置、任务流转和责任状态；二期独立建设资料与数据智能化。
- 选择原因
- 先建立流程骨架，避免流程、OCR、数据治理和自动化一次性堆叠导致范围失控。
- 代价与边界
- 一期投产后仍存在较多人工资料与数据操作，但换来了“先跑通业务，再升级能力”的稳定路径。
01一期和二期分开
- 业务约束
- 3 月需要先形成可运行的集约流程，而资料、AI、数据治理和外部系统联动复杂。
- 产品决策
- 一期只解决流程配置、任务流转和责任状态；二期独立建设资料与数据智能化。
- 选择原因
- 先建立流程骨架，避免流程、OCR、数据治理和自动化一次性堆叠导致范围失控。
- 代价与边界
- 一期投产后仍存在较多人工资料与数据操作，但换来了“先跑通业务，再升级能力”的稳定路径。
02不是所有资料都交给大模型
- 业务约束
- 身份证、营业执照、合同流水号、日期、金额等大量问题具有稳定格式或确定性标识。
- 产品决策
- 确定性规则 / 正则 / 模板优先；复杂资料分类和非固定语义再由大模型兜底。
- 选择原因
- 规则更稳定、快、可解释；大模型集中处理真正需要语义理解的部分。
- 代价与边界
- 需要建设 Taxonomy、Schema、规则和配置体系，但换来可维护性与可扩展性。
03上百张无序影像怎么处理
- 业务约束
- 一次性扫描会产生大量无命名图片；多份多页合同混在一起时，单笔可能约 100 张。
- 产品决策
- 双通道：客户提供材料走 OCR / 智能分类 / 字段抽取；行内合同优先识别稳定流水号，再按合同种类和页码归组、排序、命名。
- 选择原因
- 确定性信息不值得交给 LLM 猜；先利用业务中已有稳定信号，再使用语义能力。
- 代价与边界
- 流水号异常、首页不足以判断或低置信结果仍需人工兜底。
04一定做统一数据要素
- 业务约束
- 如果 OCR 只输出文字或字段，后续六项流程仍要重新找数据、重新复制。
- 产品决策
- 把 OCR / AI、用户填写、人工修正和后续接口数据汇聚为单笔贷款的可信数据要素，并保留来源、确认状态和任务快照。
- 选择原因
- 只有进入统一数据层，资料识别才能真正驱动法人建信、押品、台账、合同、材料生成和未来自动化。
- 代价与边界
- 人工确认值需要保护；多来源冲突、必填缺失必须显式治理。
05AI 不能直接完成正式业务
- 业务约束
- 银行信贷场景错误成本高，现有审批责任和客户经理业务事实确认责任不能被模型绕过。
- 产品决策
- AI 负责识别、抽取和辅助生成；集约岗负责系统操作并暂存；客户经理审核业务事实并最终提交。
- 选择原因
- 用 Human-in-the-loop 把模型不确定性纳入作业流程，而不是把 AI 当最终决策者。
- 代价与边界
- 牺牲一部分“全自动化率”，换取责任清晰、可复核和可追责。
06RPA 后置
- 业务约束
- GC / 电子签约等外部系统存在接口、页面、权限和流程稳定性约束，正式试点尚未开始。
- 产品决策
- 当前先把资料治理、统一数据和流程闭环做稳；三支行试点稳定后再按真实节省工时、失败率和人工接管率决定 RPA 排期。
- 选择原因
- 底层数据和流程不稳定时，RPA 只会更快地重复错误操作。
- 代价与边界
- 当前 RPA 未实现，不在网站上包装成既有能力。
最重要的产品准则：项目不以“客户经理操作最少”或“AI 使用最多”为唯一目标，而以“全链路人工是否真正下降 + 责任是否清晰 + 结果是否可复核”为准。
从一期流程骨架到二期智能底座
一期解决“事情怎么走”，二期解决“事情拿什么资料和数据走”
最终目标是让一笔贷款的多个流程共享同一套资料与可信数据。
平台建设演进路径
一期流程集约化 → 二期资料与数据智能化 → 融合为数据驱动的集约作业平台。
从一期流程集约化到二期资料与数据智能化，再到数据驱动的集约作业平台；网页不重复铺开图中的全部细节。
- 一期管流程状态，二期管资料与数据。
- 两者通过业务编号与数据面板引用融合。
- 不把二期 AI 状态塞进 BPM，也不让二期承担流程审批。
当前闭环
端到端业务闭环
让整笔贷款资料从上传到审核提交，走完可追踪、可复核的六个环节。- 客户经理上传整笔资料
- 智能整理恢复资料与合同边界
- 字段抽取进入可信数据
- 六项集约作业代执行并暂存
- 外部系统录入与结果核对
- 客户经理复核并提交审批
核心能力
- 建立资料任务、保留原始文件边界
- 合同流水号规则识别 + 客户材料 OCR / 分类
- Schema 驱动抽取、校验与统一数据要素
- 一期任务与状态承载，二期资料和数据被多流程引用
- 平台提供资料包、可信字段与材料；不虚构系统直连
- 记录待审核、提交、退回与操作留痕
一期｜流程骨架
流程定义 / 版本、任务分派、我的发起 / 待办 / 已办、表单与资料挂接、状态生命周期。重点回答：谁发起、分给谁、做到哪、谁审核。
业务中枢｜一笔贷款
以 loan_business_no 作为合同号生成前的关联中枢；多个流程实例共享一份长期资料任务和一套数据要素，合同号产生后再与 contract_no 关联。
二期｜智能作业底座
资料上传、OCR、分类、字段抽取、人工复核、可视化溯源、统一数据要素、文件整理和业务材料生成。重点回答：资料是什么、字段是什么、依据在哪、怎么复用。
后续｜自动化评估
在试点流程和数据稳定后，再评估外部系统 API / RPA。自动化不是前置目标，而是建立在可信数据和稳定流程之上的下一阶段能力。
核心产品与业务架构
系统不是围绕“六个菜单”组织，而是围绕“一笔贷款”组织
流程可以独立，资料与数据必须共享。
普惠贷前集约运营平台总体架构
从作业入口、流程中心、资料与数据中心到外部核心系统的总体架构。
围绕一笔贷款组织作业入口、流程中心、资料与数据中心、智能能力与外部核心系统，治理能力贯穿底层。
一笔贷款是主对象
多个 Flowable 流程实例可以独立存在，但共享同一笔贷款业务上下文；避免每个流程重复上传、识别和维护字段。
一期 / 二期职责解耦
一期管流程状态，二期管资料与数据。两者通过业务编号与数据面板引用融合，不把二期 AI 状态塞进 BPM，也不让二期承担流程审批。
外部核心系统仍是真实作业系统
GC、电子签约等当前仍由集约岗人工操作并暂存。平台提供任务、资料、可信数据与生成材料，不虚构已经全面系统直连。
治理能力贯穿底层
权限与角色、配置与版本、操作留痕、人工复核和异常处理不是附加功能，而是企业级作业可控的必要条件。
用户、岗位与责任边界
支行客户经理
上传 / 补充资料、发起流程、查看进度、审核集约岗暂存结果、提交审批。
- 最终责任边界
- 对客户信息与业务事实负责；保留最终审核与提交责任。
分行集约岗
集中处理六项系统作业，查看资料 / 要素 / 证据，在 GC / 电子签约操作并暂存。
- 最终责任边界
- 对代执行、录入过程和暂存结果负责，不直接替代客户经理提交。
集约管理岗
任务分配、异常协调、人员负荷、流程监控（规划）。
- 最终责任边界
- 一期流程监控管理暂未开发，不写成现有成果。
配置 / 系统管理
维护业务流程、资料 Taxonomy、字段 Schema、规则、接口 / 模型配置。
- 最终责任边界
- 维护配置有效性，不代替业务人员确认单笔贷款事实。
POST-LOAN EXPLORATION
从贷前延伸到贷后：让风险作业从“人工查数”走向“数据驱动执行”
在贷前集约之外，我还参与了普惠贷后集约调研及集中催收、风险预警等数字化支持。重点并非风险模型和催收策略本身，而是围绕贷后生命周期、多系统取数、作业名单、批量材料、任务执行和过程留痕，探索如何通过数据与系统能力支撑分行级贷后集约运营。
01｜从正常管理到不良处置：先理解完整贷后生命周期
通过贷后集约调研，进一步梳理贷款从正常存续、风险预警到逾期、不良及后续处置的业务生命周期，理解不同阶段风险管理目标与作业方式的变化。
- 正常存续
监测经营、还款及资产状态
- 风险监测 / 预警
发现异常风险信号
- 风险核查与处置
核实风险事实并采取措施
- 逾期催收
推动回款并逐步升级处置
- 不良管理 / 清收
进入专项风险与资产处置
- 核销等后续
满足条件后进入后续资产管理
查看完整阶段、触发时点与主要业务动作
02｜从业务流程中寻找数据与自动化切入点
实际参与重点集中在催收、预警及材料生产等高频作业环节，核心是减少跨系统查数、重复 Excel 加工、批量材料制作和过程留痕中的低价值人工。
集中催收｜数据驱动作业执行
围绕客户、借据、欠息、历史催收等多源数据进行加工整合，支持催收清单、批量函件、短信名单、寄送及结果留痕等作业，减少人工取数、Excel 匹配和重复材料处理。
把业务确定的催收要求进一步转化为可批量执行的数据与作业链。
集中预警｜多源数据与核查支持
围绕待预警客户，整合贷款形态、欠息、历史逾期、企业经营状态及贷后管户等信息，形成统一的预警作业数据，并探索基于明确业务规则生成部分标准反馈内容，为支行风险核查、反馈与后续跟踪提供数据支持。
减少风险人员跨系统反复查询，把更多时间留给真正的风险核实与处置判断。
贷后材料智能生成｜从人工编制到数据驱动生成
围绕催收函、征信函、核销组卷等材料密集型场景，探索将客户、贷款、合同及催收记录等业务数据结构化后，结合模板、规则和 AI 自动生成标准材料或报告初稿，减少跨系统查数、复制粘贴和人工编制。
确定性内容优先模板与规则，生成性内容再由 AI 辅助，并保留人工复核。
03｜我的切入点：把业务规则转化为可执行的数据与系统能力
- 风险数据 / 业务规则
- 风险模型 / 风险分层风险识别与策略制定
- 我的主要参与范围数据 · 系统 · 自动化作业支撑
- 预警核查 / 催收执行
- 结果反馈与过程留痕
这段经历让我重点理解了风险策略之后的落地链路：一条业务规则如何通过数据、系统和分支行作业真正被执行、反馈并留痕。
04｜从点状减负到平台化运营
贷后集约运营平台能力架构
在催收、预警等实际作业中，我们发现单点自动化只能解决局部重复劳动。基于已有实践，进一步参与讨论了分行级贷后集约平台方案，希望把零散的数据加工和自动化能力进一步沉淀为数据、任务、流程、智能工具和运营管理能力。
- 01贷后数据底座
客户 / 借据 / 合同 / 担保 / 逾期 / 欠息 / 风险分类
- 02作业库 / 清单库
催收 / 预警 / 核销等业务清单与数据包
- 03流程协同中心
任务分发 / 支行反馈 / 分行审核 / 提醒督办 / 留痕
- 04智能文档与 OCR
资料识别 / 字段抽取 / 函件与报告辅助生成
- 05业务应用中心
催收 / 预警 / 核销 / 证券化 / 风险补偿等场景
- 06管理驾驶舱
流程进度 / 超时任务 / 材料 / 责任人 / 执行情况
处理结果、任务状态和材料记录重新回流数据底座，逐步沉淀为客户贷后生命周期记录。
催收、预警及部分材料 / 自动化能力已有实际实践基础；完整贷后集约平台仍处于方案讨论与细化阶段，尚未进入完整开发实施。
包含总体架构、运行机制、核心模块、典型场景与阶段建设路径
资料、数据与 AI 如何协同
一份贷款资料如何变成可复用、可复核、可继续进入业务的可信数据
这一章不是解释 OCR / LLM 是什么，而是回答：一份贷款资料如何被转化成“可复用、可复核、可继续进入业务”的可信数据。AI 输出不是终点，只有进入统一数据要素并完成来源、确认状态和人工责任治理之后，识别结果才真正成为业务能力。
当前机制
资料接入与影像治理
先把“一次性扫描的图片堆”恢复成有边界、可作业的资料对象。输入
- 整笔贷款资料
- 原始影像 / PDF
- 资料任务
处理
- 建立资料任务并保留原始文件边界
- 合同优先识别稳定流水号并按种类、页码归组排序
- 客户材料走 OCR / 智能分类恢复资料类型
输出
- 结构化资料清单
- 分类与命名结果
- 页码、坐标与置信度
规则、AI、人工的任务分工
规则 / 模板
合同流水号、标题词 / 排除词、正则、格式、必填、命名、排序、固定模板生成。适合确定性强、可验证的任务。
AI / OCR
OCR 负责“看见文字”；大模型主要处理标题不固定、表达变化大的复杂资料分类、字段兜底和半结构化文本辅助。
人工
关键字段、低置信、来源冲突、必填缺失、未知资料与正式业务提交。人工确认值默认受到保护，不被自动重跑静默覆盖。
路由原则
先利用业务稳定信号，再决定是否调用模型；模型不稳定或无法确认时降级人工，而不是强行给答案。
配置中心：AI 不是写死 Prompt，而是配置驱动
资料 Taxonomy
新增资料类型优先“加配置”，不重新写一套识别代码。
- 核心配置
- 资料大类 / 类型、分类关键词、必要 / 辅助 / 排除词、正则、语义描述、置信度阈值。
字段 Schema
统一字段口径，并将字段定义与算法解耦。
- 核心配置
- 字段编码、类型、必填、来源、抽取策略、是否进入数据要素、复核阈值。
策略配置
按问题确定性选择最合适的处理方式。
- 核心配置
- 固定版式、关键词邻近、正则、规则、LLM 兜底、人工录入。
命名 / 交付规则
把识别结果转化为可下载、可上传、可归档的标准资料包。
- 核心配置
- 命名模板、引用字段、重名策略、合同归组 / 排序规则。
接口 / 模型配置
让模型可替换，而不让业务规则绑死某个模型。
- 核心配置
- OCR 接口、AI provider / 模型、超时、启停与版本。
项目推进与价值验证
这是“业务流程 + 产品系统 + 组织模式”同步推进的项目
结果必须分清：业务基线、已交付产品、组织推进和待试点价值。
2026.01
业务现场调研
支行跟岗、访谈、流程观察，形成流程 / 系统 / 资料 / 字段 / 耗时事实。阶段输出：调研事实与流程模型2026.01—02
一期方案
聚焦法人 e 抵、个人 e 抵；统一六项流程和“集约岗暂存—客户经理审核提交”责任链。阶段输出：产品方案与流程设计2026.03
一期测试 / 投产
核心流程功能测试与投产；流程监控管理暂未开发。阶段输出：一期核心流程投产2026.04—05
组织方案 + 二期启动
同步评估集约团队、科技赋能和人员规模；二期转向资料、数据、AI / 自动化。阶段输出：组织方案与二期立项2026.06
二期 MVP
完成资料上传、OCR、分类、抽取、溯源、统一数据要素、文件整理 / 文档生成闭环。阶段输出：可运行二期核心 MVP2026.06 以后
试点筹备
集约团队方案通过；三家支行进入正式集约运营试点准备。阶段输出：试点筹备与跨部门协同
四层成果口径
A｜已验证业务基础
支行既有专班已证明“前台营销 + 中台集约”方向具备价值；5—8 天 → 3—5 天、约 5.66h / 笔属于项目建设前的业务基线。
B｜已完成产品交付
一期核心流程已投产；二期完成“资料 → OCR → 分类 → 抽取 → 溯源 → 数据要素 → 材料”的核心 MVP。
C｜已完成组织推进
六项标准作业口径和责任边界得到统一；分行集约团队方案通过，三家支行进入试点筹备。
D｜仍待正式验证
三支行规模化运营效果、AI 长周期准确率、集约岗人均处理能力、真实全流程时长下降与 RPA ROI。
后续正式试点应该验证什么
客户经理是否进一步减负
5.66h 属于既有专班基线，尚缺系统化试点前后对照。
- 核心指标
- 事务性耗时、重复录入次数、资料准备时间、补件沟通次数。
集约岗是否真正提效
一次性上传可能转移工作量，需要二期资料智能整理后实测。
- 核心指标
- 单笔处理时长、并发任务量、资料查找 / 整理耗时。
AI 是否达到业务可用
核心链路已跑通，但尚需正式样本按资料类型建立稳定指标。
- 核心指标
- 分类准确率、字段抽取准确率、低置信复核率、关键字段修正率。
是否值得推进 RPA
RPA 当前未实现，应在真实流程稳定后再决定排期。
- 核心指标
- 高频稳定步骤占比、单笔节省时长、失败率、人工接管率。
不把目标值、MVP 演示效果、组织编制变化或支行既有集约成绩包装成系统上线 ROI。能主动说清“什么已经验证、什么尚未验证”，本身就是企业 AI 产品成熟度的证据。
我的贡献与项目复盘
用“我做了什么 → 证明什么能力 → 有什么证据”展示个人贡献
不写“沟通能力强、执行力强”这类自我评价，而是用证据说明个人不可替代价值与可迁移方法。
已完成成果
一期核心流程投产
聚焦法人 e 抵、个人 e 抵，统一六项流程与“集约岗暂存—客户经理审核提交”责任链，核心流程功能完成测试并投产。
二期核心 MVP 闭环
完成资料上传、OCR、分类、字段抽取、可视化溯源、统一数据要素、文件整理与业务材料生成的核心链路。
组织与试点推进
统一六项标准作业口径与责任边界，推动分行集约团队方案通过，三家支行进入试点筹备。
真实边界
- 流程监控管理尚未开发；GC / 电子签约 RPA 当前未实现，不在网站上包装成既有能力。
- 二期当前属于核心能力 MVP / 方案验证，正式企业级融合和规模化使用仍需试点继续验证。
- 多页 PDF 当前优先读取 / 识别第一页完成文件级分类；首页不足以判断时进入人工或扩展识别。
- 关键业务字段仍需人工确认；AI 不进行授信审批和最终风险决策。
- 约 5—8 天 → 3—5 天、约 5.66h / 笔为既有支行专班业务基线，非系统上线成效。三家支行正式运营试点筹备中，正式试点效率与 AI 准确率仍待验证。
个人核心贡献
业务问题定义
支行跟岗、访谈、系统操作观察、流程 / 资料 / 字段 / 耗时建模。
- 证明的能力
- 不是听需求，而是从业务现场发现真实问题。
- 可展示证据
- 调研报告、业务流程图、流程耗时与问题清单。
产品决策
一期 / 二期拆分、前期产品范围、六项流程、暂存 / 审核责任链、RPA 后置。
- 证明的能力
- 能在复杂约束下做范围与优先级判断。
- 可展示证据
- 关键决策卡、一期二期演进图。
AI 任务拆解
区分 OCR、规则 / 正则、大模型、模板和人工适用场景。
- 证明的能力
- 懂 AI 边界，不把所有问题都交给模型。
- 可展示证据
- AI 任务地图、百张影像双通道方案。
产品 / 数据架构
设计一贷多流程、长期资料任务、统一数据要素、Taxonomy、Schema、配置与溯源。
- 证明的能力
- 不只是页面型 PM，能构建企业级对象与数据机制。
- 可展示证据
- 总体架构图、对象关系图、配置 / 溯源截图。
MVP 落地
利用 AI 编程实现二期核心链路，让业务人员看到可运行产品。
- 证明的能力
- 能够把产品假设前置验证，而不是只停留在 PRD。
- 可展示证据
- 脱敏 Demo、页面截图、MVP 运行链路。
项目推进
连接普惠、科技、人力与试点支行，推进一期投产、二期 MVP、组织方案和试点准备。
- 证明的能力
- 能够推动复杂业务产品进入真实组织环境。
- 可展示证据
- 项目时间线、试点准备材料。
关键复盘
业务标准先于 AI
流程、资料 Taxonomy、字段 Schema 和岗位边界不统一时，模型再准确也不知道结果应该进入哪个流程、由谁确认。
数据要素先于 RPA
自动化的前提不是“页面可以点”，而是输入数据和业务规则稳定；否则 RPA 只是把错误更快地搬进系统。
确定性问题优先规则
合同流水号、格式、必填、命名和固定模板用规则更稳定；AI 应聚焦非结构化语义任务。
高风险业务保留人工责任
关键字段、异常和正式提交必须有明确责任人；AI 需要证据、复核、修改留痕和失败回退。
产品材料
产品相关材料
材料用于补充展示架构、流程与产品界面；均为脱敏或匿名化内容。平台建设演进路径
材料说明从一期流程集约化到二期资料与数据智能化，再到融合为数据驱动集约作业平台的演进图。
阅读重点快速理解一期、二期与最终融合的关系。
平台总体架构
材料说明围绕一笔贷款组织的作业入口、流程中心、资料与数据中心与外部核心系统。
阅读重点理解平台如何承载多流程并共享资料与数据。
核心业务对象与标识关联
材料说明一贷一主档、一贷一资料任务、一贷多流程与一套统一数据要素的关联关系。
阅读重点理解为什么一笔贷款可以同时承载多个流程。
百张无序影像智能整理机制
材料说明行内合同与客户材料的双通道整理机制图。
阅读重点理解约 100 张无序影像如何被恢复成可作业对象。
智能资料工作台与分类溯源
材料说明文件—智能结果—原始证据的三栏协同，展示资料分类结果与溯源信息。
阅读重点查看某份资料被识别为什么类型、依据来自哪里。
字段提取与可视化溯源
材料说明字段抽取结果回到原始文件的页码与 OCR 区块并高亮。
阅读重点点击字段直接定位原图证据，确认抽取依据。
统一数据要素与人工复核
材料说明可信字段、来源与人工确认状态的复核视图。
阅读重点核对关键字段、来源冲突与确认状态。
材料生成
材料说明基于当前任务已确认的数据要素，关联生成审批附言与抵押合同材料，并在同一界面保留原始资料溯源预览。
阅读重点查看统一数据要素如何继续驱动审批附言和合同材料生成。