企业官网建设流程全解析

一份贷前尽调报告传统要写 2 到 3 天，其中真正做判断的时间大概半天，剩下的是登录五六个系统下载数据、复制粘贴进模板、调格式。卡点不在写作效率，在三件事上：行外数据接不进来、交付物要的是文档不是表格、审批和审计要证据链。本文从工程角度拆解Data Agent怎么做这件事：多源数据怎么接入和解析、交叉验证怎么标风险点、行内模板怎么编译成 Word、每个数据点怎么带出处、报告怎么进审批系统。文末附自家数据自算公式。

一、问题定义：这是数据接入和文档生成问题，不是写作效率问题

先把场景边界收窄。这里说的尽调报告，是对公和小微客户的贷前调查报告，交付物是一份按行内模板排好、带结论和授信建议、能直接进审批系统的 Word 文档。

工程上，这个场景有三个不友好的约束：

• 数据源一半在行外，形态还各不相同。人行征信是 PDF 报告，司法涉诉是网页，工商股权是接口或网页，流水是 Excel 或者 PDF 导出，税务凭证是客户授权提供的扫描件。这些数据不在任何一个库里，也没有统一的结构。
• 交付物是文档，不是数据集。审批人要的是一份有公司概况、股权结构、财务分析、风险点、授信建议的完整报告，不是几张表。表格和文档之间隔着一层排版和叙事结构。
• 产物要能被复核。审批人拿到报告第一件事是重新核数，审计要问数据出处。报告里的每个数字都要能点回原始凭证，否则这份报告在贷审会上没有效力。

传统流程的耗时分布，落在这三条约束上：

所以这个场景的性质是：数据源异构、交付物是文档、产物要可审计。解法是把行外数据接进来解析成结构、把文档按模板编译出来、把每个数据点挂上出处。这是数据管道加文档生成加工作流的问题，不是让大模型写得更快的问题。

二、系统设计：五段拆解

2.1 多源数据接入与解析

数据源按接入方式分三类，每类的解析链路不同：

工程上的难点集中在行外那几类。征信 PDF 版式固定但字段多、跨页表格要拼接；流水导出格式各家银行都不一样，需要版式识别而不是固定坐标切分；司法网页要处理反爬和分页。解析结果统一落到本体层，字段口径对齐后才能和行内数据放在一起做交叉验证。

2.2 交叉验证与风险点标注

数据落库后不是直接填模板，先跑一遍交叉验证规则。规则是配置在语义层的确定性判断，不是模型打分：

流水进账总额 与 纳税申报收入 差异率 > 阈值（示例 30%） → 标注"收入与流水不匹配" 对外担保余额 / 净资产 > 阈值（示例 50%） → 标注"对外担保集中" 命中涉诉或执行记录 → 标注"司法风险" 关联企业存在经营异常或失信记录 → 标注"关联方风险" 合同金额 与 发票金额 长期缺口 → 标注"购销真实性存疑"

每条命中都带具体数值和阈值，进报告的风险点清单。这里要强调一点：标注的是"异常信号"，不是"风险结论"。是否构成实质风险由客户经理和审批人判断，系统只负责不漏。

2.3 模板编译与文档生成

行内尽调模板是 Word，段落结构固定，每段的取值来源不同。做法是把模板的占位符和数据字段在语义层建映射，生成时按映射取值填充，输出仍是 Word，可以直接进审批系统。

映射关系举例：

生成的是草稿。客户经理需要补的是现场调查情况、面谈记录、抵押物评估，以及最终授信建议。这三块是模板里唯一不自动填的部分。

2.4 溯源链设计

这是整个设计里最硬的一环。报告里每个数据点带一个 source 引用，指向原始凭证：哪个字段来自哪份征信的哪一页、哪笔流水、哪个判决文书的案号。

数据点 → source_id → 原始凭证（PDF 页 / 流水行 / 网页快照）

审批人和审计在报告里点开任意一个数字，都能看到它的来源。这条链是 AI 报告能进审批系统的前提。大模型直接生成的内容天然不可溯源，所以数据点必须是编译填充的，不能是生成出来的。

2.5 审批工作流对接

报告生成不是终点。提交、审批、意见回填、版本迭代要走完整链路，承载这部分的是工作流表：报告提交后进审批系统，审批意见回填到对应段落，客户经理按意见补充后生成新版本，版本可追溯。

没有这一步，客户经理还是要在报告系统和审批系统之间搬运，闭环断在最后一公里。

三、收益模型与自算公式

年化人力当量释放 ≈ N × t ÷ 250（工作日）× 复用率 × C（人均年全成本）

代入示例：

12000 × 2 ÷ 250 × 0.6 × 24 万 ≈ 1380 万 ≈ 1400 万

等价换算：12000 份 × 2 天 = 24000 人天/年，约 96 人年，按复用率 60% 折算约 58 人年的产能回到客户经理手上。

口径别搞错。这个 1400 万是人力当量释放口径，是"少干了多少活"，不是增量收入。拿它当"多赚的钱"对外讲，是口径错误。省下来的时间能不能变成存款和收入，取决于客户经理是否拿去做管户和营销，那是管理动作。

自家代进去算：N 是 6000 份还是 24000 份，t 是 1.5 天还是 2.5 天，复用率 0.5 还是 0.8，C 是 18 万还是 35 万，自己算。N=6000、t=1.5、复用率 0.5、C=18 万算出来约 320 万；N=24000、t=2.5、复用率 0.8、C=35 万算出来约 6700 万。

以上全部为示例口径，只是举例不是承诺。这个场景的好处是每个数都能现场计时验证，不需要你信任何归因模型。

四、合规边界与权限

行列权限按客户经理管户范围、分行范围、条线范围三层配置，所有查询、生成、提交动作留痕可审计。

五、为什么通用查数工具做不了

四个跨不过去的点：

行外数据接入和解析。尽调最缺的数据一半在行外，征信是 PDF、司法是网页、工商是接口。通用查数工具只能查已经连进库的结构化表，这些既接不进来也解析不了。没有征信、没有涉诉、没有股权穿透，报告就是半个报告。

交付物是文档不是表格。尽调场景要的是成稿，不是出表。从数据集到带结论、带建议、能进审批的 Word 报告，中间隔着模板编译和叙事结构。

溯源链。没有出处，AI 报告在银行永远只是草稿。审批人重新核数的成本，比他自己写一遍还高。

工作流闭环。报告生成加审批流转是一个整体。拆开做，客户经理还是要在两个系统之间搬运。

六、怎么试

这个场景当天就能验，现场计时即可，不需要等 30 到 60 天看效果。

先做一次 30 分钟需求对齐，不带销售，只看场景适配度：你家尽调模板的标准化程度、行外数据源有没有可用的授权接口、审批系统能不能对接。

合适的话做概念验证：拿客户经理手头一份真实尽调案例，现场对比传统方式写一份和极昆仑iInsight 生成一份，计时加核对数据点覆盖率。

两件事先说清楚，免得期待错位：

1. 概念验证验证的是数据抓取覆盖率（征信、工商、司法、流水数据点全不全）、溯源准确性（每个数能不能点回原始来源）、模板匹配度（生成的报告符不符合行内模板）、风险点标注的合理性。这些当场能核。
2. 概念验证不承诺客户经理能多创造多少收入。那是管理动作，取决于释放的时间是否投入管户和营销，不是产品单方面能保证的。这个场景能承诺的是省了多少时间、数据点是否可溯源，这两项当场可验。

涉及行外数据的验证要过数据授权路径，人行征信走合法授权，司法工商走公开接口。验证阶段也可以先用脱敏或样例数据演示全流程，再用真实数据验证。