夜雨聆风首户贷 AI 预审助手 · 产品设计篇
小微企业信贷审批完整流程（12 步）
预审边界
交互流程图
📌 ③ 文档解析（智能文档处理 IDP · AI）：
微信/支付宝截图、银行流水 PDF、票据照片经视觉模型做两路处理：
-结构化 KV 抽取 → 关系库/特征库（供 ④ 规则引擎算数、供 ⑤ 语义层画像）；
-切片 + embedding → 向量库（仅 ⑤ 语义层 RAG 检索）。规则引擎只读结构化字段，不消费向量。
📍④ 规则引擎+评分卡（确定性层 · 系统自动）：
红线筛查（命中即终止）+ 硬性准入裁决 + 反欺诈/多头阈值判定 + 评分卡量化——所有硬性、可量化的判断在此完成（使用 ③ 解析出的结构化流水）。
🤖 ⑤ AI 预审助手（语义层）：
仅对通过规则引擎的客户，做经营画像、尽调指引、受理建议，全链路留痕。
中断点：
材料不完整 → 补件；规则引擎红线筛查命中 → 立即终止；文档解析置信度不足 → 人工确认。
对话脚本 A：正常流程 —— 早餐店老板的首贷
📌 产品对标：本文"小微首贷·个人经营贷（信用）"对标行业首贷专属产品，如建行"首户快贷"、农行"首户e贷"、建行"信用快贷"（信用经营贷普遍 3% 起、实控人连带担保）。
对话脚本 B：受理但存疑 —— 数字达标，故事存疑
📌 本例最能体现预审助手价值：系统判定硬指标达标、可受理；但经营画像与勾稽分析进一步挖出 4 项"数字合规但真实性存疑"的软性疑点，把风险从"放款后"提前到"尽调前"。
完整交互链路
三个按钮的设计逻辑
- 无条件每笔必过人：
每笔预审报告必须人工确认后才能进入尽调。对应金发 8 号文"AI 只能辅助，不能替人拍板" - 三条记录不可撤销：
决策人 ID + 时间戳 + 确认意见，构成完整 audit_trail - 语义降级：
Gate 使用"确认受理/修改后受理/退回"而非"通过/不通过"。预审结论不承担审批责任 - 涉及授权即归档：
AI 预审涉及客户征信、税务等多维度数据授权查询，无论 Gate 何种决策，预审报告 + gate_decision + audit_trail 均归档至 信贷系统LMS。退回标注"预审退回"（非"信贷拒绝"），确保数据授权链路完整闭环
审批岗视角
预授信与正式授信的制度衔接
预审 Agent 输出的「预授信建议额度（封顶值）+ 准入结论 + 尽调指引」，性质为 营销前置参考，不具授信法律效力，不替代任何审批决策。正式授信须进入行内完整授信审批流程，最终额度、利率、条件以审批结论为准（可能上调、下调或否决）。
报告归档（archive_to_lms）
预审报告以 PDF 形式归档至 LMS，是流程中唯一的写入操作；无论 Gate 何种决策（确认受理/修改后受理/退回）均归档，退回标注"预审退回"（非"信贷拒绝"）。接口定义、参数与网关校验详见技术篇。
通知机制（三条通道同时触达）
★ 为什么这是关键闭环
预审 → 尽调 任务自动流转
现场核查清单（GPS 打点留痕）
Agent 自动生成的 6 类尽调指引
附 · 一份真实风格的预审报告样例
鲜丰果蔬批发中心（首户）与晨光餐饮店"干净通过"不同：它同样"建议受理"，却把 6 类风险信号精准推给现场——证明 AI 预审不是橡皮图章，而是把"该查什么"提前交给尽调人员。下面是 Agent 在 审批岗确认 前输出的完整报告（客户经理手机端内容），也是上方 6 类尽调指引的源头数据。
闭环价值
预审 Agent 把"能不能贷"的判断前移到受理之前，让客户经理在见客户前就拿到一份有数据支撑的报告和一份有目标的现场核查清单；尽调人员带着"地图"去现场，不再凭经验"盲走"；审批岗看到的是"AI 预审 + 现场核实"相互印证的完整证据链。
三道角色各司其职，AI 全程辅助、不替代任何一道人工决策——这正是金发〔2026〕8 号文"AI 辅助、人兜底"的可落地注脚。