项目概览
不是写 Word 工具，而是可信文档生产链
项目面向的不是偶尔撰写长文档的用户，而是每月上千笔贷款材料需要稳定、可核验输出的银行普惠业务场景。
MVP 已完成并与贷前集约系统对接；贷前附件合同材料在支行试点，证券化等贷后场景继续验证。
下方规模数据用于说明业务背景和试点验证结果，不代表系统已全量覆盖生产，效率测算数据需注明为测算口径。
- 2026 年上半年贷前业务规模
- 约 1,200 笔/月用于说明业务背景和覆盖范围，不是当前系统已处理量。
- 单笔附件材料生成耗时变化
- 30-60 分钟→约 2 分钟试点阶段单笔对比结果，不代表正式上线后的稳定数值。
- 全量覆盖测算效率释放
- 560-1,160 小时/月按业务规模测算，非当前实际已释放效率。
业务问题
文档不是写出来的，而是在多个系统之间拼出来的
普惠业务人员每天要在核心系统、信贷系统、押品系统、催收系统之间查数，再填入格式固定但内容随客户变化的合同、附言和报告。这个过程中，查数据、填模板、写分析、审核校验是四层独立但相互依赖的劳动。
已有条件是数据存在于各业务系统中，Word/Excel 模板有稳定格式，AI 也能辅助分析。真正缺失的是一座桥，把业务数据、模板结构、规则逻辑和 AI 能力连接成一条可批量、可追溯的生产线。
数据获取链路长，跨系统查数、口径不一致
一笔贷款材料需要从 4-6 个系统获取客户信息、贷款要素、押品估值、催收进展，数据口径与业务编排经常需要人工判断。
- 具体表现
- 经办人员打开多个系统页面，复制粘贴后核查口径是否正确。
- 根本原因
- 缺少统一的实体数据模型和字段映射，各系统数据出口独立。
- 业务影响
- 单笔材料准备耗时 30-60 分钟，批量场景下严重影响作业效率。
- 支撑证据
- 2026 年上半年贷前业务月均约 1,200 笔，每笔需要多份附件材料。
模板填写和报告撰写质量不稳定
分析性内容（经营分析、风险判断、处置建议）依赖经办人员经验和文字能力，不同人员输出质量差异大。
- 具体表现
- 同类业务不同人员撰写的分析理由和结论不一致，审核反复退回修改。
- 根本原因
- 判断逻辑分散在制度文件和个人经验中，未转化为结构化规则和 AI 任务。
- 业务影响
- 审核核验成本高，报告质量难以标准化管理。
- 支撑证据
- 贷前附件合同材料在支行试点中，生成耗时从 30-60 分钟降至约 2 分钟。
生成结果缺少可解释性，审核需要反复溯源
手工填写时审核人能看到哪个字段是查出来的；AI 生成后，字段、条件和段落都变成了不确定的来源。
- 具体表现
- 审核人员对生成内容有疑问时，需要回原系统重新查数核实。
- 根本原因
- 生成链路中缺少字段来源、规则匹配和 Prompt 调用的完整记录。
- 业务影响
- AI 生成的信任度不够，审核成本不降反升。
- 支撑证据
- 试点中上线可视化溯源，字段可点击查看数据来源和生成依据。
问题不是缺少数据或者 AI，而是缺少将数据要素化、模板可配置、规则可解释和 AI 可溯源统一起来的生产机制。
关键决策
五项决定定义这个系统的边界与可信度
这些不是功能清单，而是在模板生成任务中，对确定性、语义判断、责任和能力边界做出的结构性取舍。
模板引擎、规则引擎、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 编排
- 配置版本与发布校验
引擎与技术
先看清数据如何流动，再进入技术分层
系统运行机制图展示从数据入口到文档出口的完整流转；技术架构图展示支撑这套机制的分层设计。
系统运行机制与数据流全景
从数据上传、模板选择、变量校验到 AI 生成、溯源预览和批量下载的完整流转路径。
从数据上传入口开始，经过字段映射、模板绑定、变量校验、规则分支、AI 生成到溯源预览和批量下载的完整数据流。
- 数据上传后先经过字段映射与校验，不通过则标记失败不进入生成
- 模板变量与数据实体绑定后，由规则引擎判断条件分支
- 确定性内容由模板引擎填充，分析性文本由 AI Block 生成
- 每个字段、分支和 AI 内容均保留来源、规则和 Prompt 的三维溯源
MVP 演进
从单一场景到多场景验证，逐步验证平台能力
四个阶段围绕主线推进：先验证核心生成链路，再补齐运营与配置能力，最后扩展到多场景验证，证明抽象平台可以复用。
阶段一
业务场景抽象与核心模型设计
深入普惠业务现场，将贷前合同附件、贷后催收函和经营报告等场景抽象为统一的数据要素、模板变量和 AI Block 模型。阶段输出：实体 Schema、模板协议、AI Block 定义与 MVP 边界阶段二
贷前附件材料 MVP 验证
完成数据上传、实体映射、模板绑定、条件分支和 AI 段落生成的核心链路，验证合同附件的可生成与可审核。阶段输出：可运行的端到端生成链路阶段三
从单场景升级为平台能力
补齐批量任务、失败处理、溯源交互和版本管理，将贷前验证的能力抽象为可配置的平台。阶段输出：配置闭环、溯源审核与批量生产能力阶段四
多场景验证与正式建设推进
在支行试点验证贷前附件材料，同时将证券化尽调等贷后场景接入验证平台复用能力，推动科技团队正式开发。阶段输出：试点运行反馈、多场景验证结果与正式建设输入
成果与复盘
清楚区分已验证成果、真实边界与个人贡献
本章不使用尚未发生的生产指标包装结果，而是呈现已交付的产品闭环、试点阶段边界、个人关键动作和可复用复盘。
已完成成果
可信文档生成 MVP 闭环
完成数据上传、模板选择、变量校验、AI 生成、溯源审核与批量下载的完整产品链路。
实体 Schema 驱动的配置平台
建立客户、贷款、押品、催收等实体模型，解耦数据源与模板，验证平台在多场景间的复用能力。
试点验证与正式建设输入
贷前附件材料在支行试点，生成耗时缩短至约 2 分钟；沉淀的产品方案支撑科技团队正式立项。
真实边界
- MVP 已完成并与贷前集约系统对接；贷前附件合同材料在支行试点，证券化等贷后场景继续验证。
- 当前成果证明的是产品链路和平台机制可运行，不代表已形成覆盖全部场景的生产能力。
- 效率数据为试点阶段单笔对比和业务规模测算，不是正式上线后的稳定生产指标。
- 页面中的数据、截图和生成示例为脱敏或模拟内容，不包含真实客户身份、账户、合同和内部系统信息。
个人核心贡献
业务抽象与核心模型设计
将多场景文档需求抽象为实体 Schema、模板变量、条件规则和 AI Block 四层可配置模型，为平台复用打下基础。
AI 边界与产品机制定义
明确模板引擎、规则引擎和 AI Block 三层分工及协作协议，设计三维溯源与审核治理的产品交互。
MVP 开发与业务验证推进
完成核心链路 MVP 开发，推动支行试点验证，衔接科技团队将方案转为正式系统建设。
关键复盘
先定义数据模型，再设计 AI 任务
如果业务数据没有统一的数据要素化模型，AI 只能针对每个模板写 Prompt，无法复用。实体 Schema 和字段映射是平台化的前提。
AI 只做最难标准化的事情
确定性内容交给模板引擎，条件判断交给规则引擎，AI 只负责分析性文本。这样每个问题都用了最合适的工具，也方便单独测试和调优。
溯源不是附加功能，是产品能否被信任的门槛
在金融文档场景中，如果审核人员无法追溯 AI 内容的确切来源和依据，生成再快也不会被采纳。溯源交互必须与生成过程同时设计，不能作为事后的日志查询。
平台能力需要被多场景验证
单一场景的 MVP 只能证明链路跑得通；要证明平台抽象的复用价值，必须用第二个、第三个场景去验证配置引擎和模型是否足够通用。
产品证据
产品证据与截图
截图只用于证明产品机制；页面数据与对话内容均为匿名化合成素材。产品功能架构全景
页面说明智能文档生成系统从配置、生成到审核的完整产品能力架构图。
用户任务快速理解数据配置、模板管理、生成任务和溯源审核如何协作。
证明机制证明产品不是单一生成工具，而是覆盖配置、生产和审核三个闭环的可运营平台。
数据配置与模板管理
页面说明实体 Schema 配置与模板变量绑定页面。
用户任务查看实体模型定义、字段映射和模板变量绑定关系。
证明机制证明数据要素化和模板配置是解耦的，数据源变化不影响模板。
生成任务与批量生产
页面说明任务中心任务列表与任务结果批量下载页面。
用户任务创建生成任务、上传数据、查看任务状态和下载生成结果。
证明机制证明生成过程是任务化、可追踪的，支持批量执行和结果管理。
可视化溯源与审核
页面说明文档预览中的字段溯源、条件溯源和 AI 溯源交互页面。
用户任务在线预览生成文档，点击字段、分支或 AI 段落查看生成依据。
证明机制证明每个输出都有可追溯到数据来源、规则依据和 Prompt 调用的三维证据链。
生成输出与系统关联
页面说明普惠贷前系统关联生成的合同材料与审批附言预览。
用户任务查看系统关联生成的实际合同附件和审批附言输出效果。
证明机制证明生成结果与业务系统完成对接，文档可直接进入业务使用流程。