项目概览
不是写 Word 工具，而是可信文档生产链
项目面向的不是偶尔撰写长文档的用户，而是每月上千笔贷款材料需要稳定、可核验输出的银行普惠业务场景。
MVP 已完成并与贷前集约系统对接；贷前附件合同材料在支行试点，证券化等贷后场景继续验证。
下方规模数据用于说明业务背景和试点验证结果，不代表系统已全量覆盖生产，效率测算数据需注明为测算口径。
- 2026 年上半年贷前业务规模
- 约 1,200 笔/月用于说明业务背景和覆盖范围，不是当前系统已处理量。
- 贷前资料人工准备耗时
- 1.8–2 小时/笔法人 e 抵、个人 e 抵单笔材料的当前人工准备基线。
- 全量覆盖测算效率释放
- 560-1,160 小时/月按业务规模测算，非当前实际已释放效率。
业务问题
业务现状：贷前与贷后材料生成压力集中在“量大、耗时、易错、难审核”
从贷前资料、证券化尽调到核销、催收与定期报告，业务人员面对的不是一次性写作任务，而是持续发生、材料众多、口径严格的正式文档生产工作。
五类场景在文档结构、处理频率和复杂度上不同，但都需要业务人员跨系统收集数据、核对口径、套用模板并完成审核。下表呈现业务规模与人工耗时基线，用于说明问题压力，不代表系统上线后的效率结果。
| 业务场景 | 典型文档 / 材料 | 业务特征 | 当前业务现状与耗时 |
|---|---|---|---|
| 贷前资料生成 | 审批附言、合同书签模板、附件合同资料、资料清单，以及房屋出租声明、抵押声明 / 抵押核实书、配偶声明、告知函、信息授权书、承诺函等。 | 高频、重复、格式固定；客户、贷款、押品等字段在多份材料中反复出现。 | 法人 e 抵、个人 e 抵单笔需要准备数十份材料，当前主要依靠人工查数、核对与套用模板。
|
| 贷后证券化尽调 | 证券化内部尽职调查报告，覆盖借款人整体情况、贷款情况、经营情况、抵押情况与逾期情况等。 | 跨系统查数、数据口径多，需要规则判断和专业文字说明。 | 2025 年完成七期证券化处置；个人证券化每期需要批量撰写尽调报告。
|
| 贷后核销组卷 | 声明与保证、核销请示、实地核查报告、处置预案、清收报告、法律意见书、会议纪要等。 | 材料多、证明要求严，涉及借款人、保证人、押品、风险补偿、清收处置、诉讼等多类信息。 | 单户材料内容可达上万字；复杂场景通常需要更长准备周期。
|
| 贷后催收材料 | 催收函、征信函、催收函书签模板。 | 按客户批量生成，单份复杂度不高，但数量大、重复性强。 | 每月持续新增需催收客户，同时需要集中处理较大规模的存量逾期客户。
|
| 定期数据报告 | 资产质量报告、不良及逾期贷款报告、普惠产品分析报告等。 | 月度固定产出，模板相对稳定，但数据口径要求一致。 | 每月月初需生成多类分行和支行报告，仍以人工汇总数据、处理口径和套用模板为主。
|
这些场景表面上是不同文档，实质上都依赖客户、贷款、押品、诉讼、催收等多源数据，并需要按照固定或半固定模板生成正式材料。项目因此将问题抽象为“多源业务数据到规范文档的批量生成与可信审核”问题。
关键决策
五项决定定义这个系统的边界与可信度
这些不是功能清单，而是在模板生成任务中，对确定性、语义判断、责任和能力边界做出的结构性取舍。
模板引擎、规则引擎、AI Block 三层分工
- 业务约束
- 文档内容分三类：固定字段（客户名称、金额）、条件分支（是否满足某条件显示某段）、分析性文本（经营分析、处置建议）。三者对确定性、可解释性和稳定性要求不同。
- 产品决策
- 模板引擎负责固定内容和格式，规则引擎负责条件判断和分支选择，AI Block 负责分析性段落，三者通过统一的变量绑定与溯源机制协作。
- 选择原因
- 不让一个模型同时处理表格渲染、条件判断和开放性写作，每层独立可测试、可版本化。
- 代价与边界
- 架构更复杂，需要维护三套引擎的状态和协议；但这是确保文档可信和可追溯的必要成本。
01模板引擎、规则引擎、AI Block 三层分工
- 业务约束
- 文档内容分三类：固定字段（客户名称、金额）、条件分支（是否满足某条件显示某段）、分析性文本（经营分析、处置建议）。三者对确定性、可解释性和稳定性要求不同。
- 产品决策
- 模板引擎负责固定内容和格式，规则引擎负责条件判断和分支选择，AI Block 负责分析性段落，三者通过统一的变量绑定与溯源机制协作。
- 选择原因
- 不让一个模型同时处理表格渲染、条件判断和开放性写作，每层独立可测试、可版本化。
- 代价与边界
- 架构更复杂，需要维护三套引擎的状态和协议；但这是确保文档可信和可追溯的必要成本。
02实体 Schema 驱动，而不是模板绑定数据源
- 业务约束
- 各系统数据字段名称、类型、口径不一；如果模板直接绑定数据源字段，每个系统变化都需要修改模板。
- 产品决策
- 建立统一的实体 Schema（客户、贷款、押品、催收），将数据源字段映射到实体属性，模板变量绑定实体属性而非数据源字段。
- 选择原因
- 数据源变化只影响映射层，模板和规则不受影响；同时支持一份数据生成多份文档。
- 代价与边界
- 需要持续维护实体 Schema 和字段映射，增加了配置工作；但这是平台复用的前提。
03三维溯源：字段→来源，分支→规则，AI→Prompt
- 业务约束
- 审核人员需要确认：这个金额从哪来？这段文字为什么出现？这个分析结论有什么依据？三者溯源粒度不同。
- 产品决策
- 生成结果中每个字段可追溯到数据实体路径和原始值，每个条件分支可追溯到触发规则，每个 AI 段落可追溯到 Prompt、模型返回和人工确认记录。
- 选择原因
- 不同类型内容的可信依据不同，不能用统一方式处理；溯源粒度必须匹配业务审核的实际关注点。
- 代价与边界
- 溯源数据量增加，需要设计溯源信息的存储和展示方式；但这是 AI 文档进入金融场景的基本条件。
04先验证贷前合同附件，再扩展到贷后和经营场景
- 业务约束
- 业务场景包含贷前合同附件、贷后催收函、证券化尽调、经营分析报告等，场景复杂度差异大。
- 产品决策
- MVP 阶段聚焦贷前合同附件材料（合同、附言、台账），验证数据要素化、模板生成和 AI 段落后，再扩展到证券化尽调和经营报告。
- 选择原因
- 贷前附件是最标准化、频次最高的场景，验证成功后平台抽象层才有复用信心。
- 代价与边界
- 贷后复杂场景（法律文书、多方会签）暂不纳入 MVP，需要后续单独评估。
05优先 Word/PDF 输出，在线协同编辑后置
- 业务约束
- 最终文档需要可打印、可签章、可存档；但部分场景需要多人协作编辑。
- 产品决策
- MVP 阶段优先支持 Word 和 PDF 格式化输出，在线协同编辑复杂、变更多、与银行现有工作流差异大，列入后续迭代。
- 选择原因
- 格式输出是可核验可交付的最小闭环，协同编辑需要独立论证场景价值。
- 代价与边界
- 暂不支持在线修改后重新生成的需要单独处理；但保证了 MVP 的交付节奏和稳定性。
文档生产机制
五步把业务数据变成可审核的可信文档
每一步明确输入、处理、输出和可信机制；数据要素化和可视化溯源是整条链路是否可用的关键前提。
当前机制
数据要素化与实体建模
建立统一的实体 Schema（客户、贷款、押品、催收），将分散在多系统的数据字段映射到标准化实体属性。输入
- 核心系统客户数据
- 信贷系统贷款数据
- 押品估值数据
- 催收进展数据
处理
- 实体模型定义
- 字段来源映射
- 中文/英文别名
- 数据类型与值域校验
输出
- 标准化实体数据
- 字段映射配置
- 数据质量报告
产品与系统
三个核心闭环支撑产品的持续可信运营
产品架构图展示稳定的能力层；正文聚焦配置闭环、生成闭环和可信审核闭环如何把数据、模板、AI 和人工串联为可配置、可批量、可审核的生产线。
产品功能架构全景
从配置人员、经办人员和审核人员的任务出发，理解数据配置、模板管理、生成任务和溯源审核如何协作。
架构从配置人员、经办人员和审核人员的任务出发，组织数据配置、模板管理、生成任务和溯源审核的完整能力。
当前闭环
配置闭环
让模板与数据配置可以独立迭代，不因为数据源变化而改模板，也不因为模板调整而改数据。- 定义实体 Schema
- 建立字段映射
- 配置模板变量与规则
- 绑定 AI Block
- 校验与发布配置版本
核心能力
- 实体模型与字段映射
- Word/Excel 模板管理
- 条件规则配置
- AI Block 编排
- 配置版本与发布校验
MVP 演进
从单一场景到多场景验证，逐步验证平台能力
四个阶段围绕主线推进：先验证核心生成链路，再补齐运营与配置能力，最后扩展到多场景验证，证明抽象平台可以复用。
阶段一
业务场景抽象与核心模型设计
深入普惠业务现场，将贷前合同附件、贷后催收函和经营报告等场景抽象为统一的数据要素、模板变量和 AI Block 模型。阶段输出：实体 Schema、模板协议、AI Block 定义与 MVP 边界阶段二
贷前附件材料 MVP 验证
完成数据上传、实体映射、模板绑定、条件分支和 AI 段落生成的核心链路，验证合同附件的可生成与可审核。阶段输出：可运行的端到端生成链路阶段三
从单场景升级为平台能力
补齐批量任务、失败处理、溯源交互和版本管理，将贷前验证的能力抽象为可配置的平台。阶段输出：配置闭环、溯源审核与批量生产能力阶段四
多场景验证与正式建设推进
在支行试点验证贷前附件材料，同时将证券化尽调等贷后场景接入验证平台复用能力，推动科技团队正式开发。阶段输出：试点运行反馈、多场景验证结果与正式建设输入
成果与复盘
清楚区分已验证成果、真实边界与个人贡献
本章不使用尚未发生的生产指标包装结果，而是呈现已交付的产品闭环、试点阶段边界、个人关键动作和可复用复盘。
已完成成果
可信文档生成 MVP 闭环
完成数据上传、模板选择、变量校验、AI 生成、溯源审核与批量下载的完整产品链路。
实体 Schema 驱动的配置平台
建立客户、贷款、押品、催收等实体模型，解耦数据源与模板，验证平台在多场景间的复用能力。
试点验证与正式建设输入
贷前附件材料已进入支行试点验证；沉淀的产品方案支撑科技团队正式立项。
真实边界
- MVP 已完成并与贷前集约系统对接；贷前附件合同材料在支行试点，证券化等贷后场景继续验证。
- 当前成果证明的是产品链路和平台机制可运行，不代表已形成覆盖全部场景的生产能力。
- 页面中的人工耗时和业务规模用于说明当前作业压力，不是系统上线后的效率结果。
- 页面中的数据、截图和生成示例为脱敏或模拟内容，不包含真实客户身份、账户、合同和内部系统信息。
个人核心贡献
业务抽象与核心模型设计
将多场景文档需求抽象为实体 Schema、模板变量、条件规则和 AI Block 四层可配置模型，为平台复用打下基础。
AI 边界与产品机制定义
明确模板引擎、规则引擎和 AI Block 三层分工及协作协议，设计三维溯源与审核治理的产品交互。
MVP 开发与业务验证推进
完成核心链路 MVP 开发，推动支行试点验证，衔接科技团队将方案转为正式系统建设。
关键复盘
先定义数据模型，再设计 AI 任务
如果业务数据没有统一的数据要素化模型，AI 只能针对每个模板写 Prompt，无法复用。实体 Schema 和字段映射是平台化的前提。
AI 只做最难标准化的事情
确定性内容交给模板引擎，条件判断交给规则引擎，AI 只负责分析性文本。这样每个问题都用了最合适的工具，也方便单独测试和调优。
溯源不是附加功能，是产品能否被信任的门槛
在金融文档场景中，如果审核人员无法追溯 AI 内容的确切来源和依据，生成再快也不会被采纳。溯源交互必须与生成过程同时设计，不能作为事后的日志查询。
平台能力需要被多场景验证
单一场景的 MVP 只能证明链路跑得通；要证明平台抽象的复用价值，必须用第二个、第三个场景去验证配置引擎和模型是否足够通用。
产品材料
产品相关材料
材料用于补充展示架构、流程与产品界面；均为脱敏或匿名化内容。产品功能架构全景
材料说明智能文档生成系统从配置、生成到审核的完整产品能力架构图。
阅读重点快速理解数据配置、模板管理、生成任务和溯源审核如何协作。
Word 模板配置
材料说明Word 模板中的确定性变量、表格明细循环、条件规则与 AI Block 配置示例。
阅读重点按业务模板配置固定字段、明细表格、条件判断和需要 AI 辅助生成的分析段落。
数据配置与模板管理
材料说明实体 Schema 配置与模板变量绑定页面。
阅读重点查看实体模型定义、字段映射和模板变量绑定关系。
生成任务与批量生产
材料说明任务中心任务列表与任务结果批量下载页面。
阅读重点创建生成任务、上传数据、查看任务状态和下载生成结果。
可视化溯源与审核
材料说明文档预览中的字段溯源、条件溯源和 AI 溯源交互页面。
阅读重点在线预览生成文档，点击字段、分支或 AI 段落查看生成依据。
生成输出与系统关联
材料说明普惠贷前系统关联生成的合同材料与审批附言预览。
阅读重点查看系统关联生成的实际合同附件和审批附言输出效果。