| name | submit-credit-application |
| description | 授信申请提交辅助技能。自动盘点客户档案中的笔记与材料,对照银行贷前尽调材料标准评估完备性,检查案件冲突与授信到期状态,生成结构化评估报告并引导客户经理确认提交。当用户需要提交授信申请、发起审批流程、续贷申请、追加授信或评估材料是否齐全时使用此技能。触发词包括:"提交授信申请"、"发起审批"、"submit credit"、"续贷申请"、"追加授信"、"评估材料"、"授信申请提交"、"发起授信流程"。不适用于:贷后管理、风险分类调整、不良资产处置、授信审批决策、或无具体客户背景的泛泛咨询。
|
| target_role | 对公客户经理、信贷审批官 |
| business_domain | 对公业务 > 信贷管理 > 授信审批 |
| risk_level | high |
| version | 2.0.0 |
| status | draft |
| data_sources | ["客户笔记(尽调报告、拜访记录、走访小记)","客户材料(营业执照、财务报表、银行流水、担保材料)","案件状态(信贷系统案件管理模块)","授信台账(现有授信额度、到期日、使用情况)"] |
| upstream_skills | ["credit-due-diligence","visit-memo","financial-report-analysis","equity-penetration-analysis","credit-industry-analysis"] |
| downstream_skills | ["credit-approval-decision"] |
提交授信申请（Submit Credit Application）
当用户要求提交授信申请时，按以下流程执行。
目标角色 (Target Role)
- 角色：对公客户经理、信贷审批官
- 使用场景：新客户首贷申请、存量客户续贷、追加授信申请
- 输出用途：评估材料完备性，引导客户经理确认提交，发起授信审批流程
- 决策层级：授信审批前置环节，直接影响案件是否进入审批流程
- 执行频率：每次授信申请前执行一次
数据接入 (Data Sources)
必需数据
| 数据项 | 来源 | 获取方式 | 敏感级别 |
|---|
| 客户笔记 | 信贷系统影像档案 | API: /api/notes/list | 内部 |
| 客户材料 | 影像档案系统 | API: /api/documents/list | 内部 |
| 案件状态 | 信贷系统案件管理 | API: /api/cases/status | 机密 |
| 授信台账 | 核心系统授信模块 | API: /api/credit/ledger | 机密 |
数据脱敏规则
- 客户身份证号：显示前3后4，中间用 * 替代
- 银行账号：仅显示后4位
- 案件编号：完整展示（内部流转需要）
- 授信金额：完整展示（审批决策需要）
- 客户商业机密信息（如核心客户名单）：在评估报告中使用“某客户”代替
降级策略
- 如果信贷系统影像档案不可用：标注“客户笔记和材料未核验”，基于用户提供的信息继续评估
- 如果案件状态查询超时：标注“案件冲突未核查”，提示用户手动确认无活跃案件
- 如果授信台账不可用：标注“授信到期状态未知”，由用户确认案件类型（续贷/新增/追加）
- 如果历史尽调报告不可用：标注“尽调报告缺失”，提示用户上传或补充
约束条件 (Constraints)
监管依据:《商业银行授信工作尽职指引》、《贷款风险分类指引》、
《商业银行法》第35条贷款审查要求、银监会《流动资金贷款管理暂行办法》
- 严格确认前置:未获用户明确确认,禁止发起案件创建,无论材料是否充分
- 材料评估独立判断:完备性评估基于材料实质内容,不得以“材料数量充足”代替“内容质量达标”
- 案件冲突不覆盖:同一客户存在活跃审批案件时,禁止重复提交,须向用户提示冲突
- 不确定性显式告知:材料存疑或缺失时须向用户明确告知,不得主观判断“可能不重要”而跳过
- 案件类型不猜测:续贷与新增授信类型须由用户确认,不得根据客户历史记录自动推断
- 拒绝越权判断:不对审批结果做预测(如“这个应该能批”),聚焦材料完备性
- 数据溯源:材料评估须注明每项材料的来源、上传日期、有效期状态
- 禁止跳过步骤:不得跳过步骤0(数据验证)和步骤1(案件冲突检查),必须确认无活跃案件后方可继续
- 红线执行强制:如触发任何红线(R1-R3),必须立即停止生成并提示用户
金融合规红线(一票否决)
以下情况须立即停止提交并提示用户:
- R1:必备材料缺失(尽调报告、拜访记录、财务资料、营业执照)
- R2:存在活跃审批案件(防止重复提交)
- R3:用户未明确确认提交(禁止静默提交,“好的”等模糊表述不得判定为确认)
授信申请材料清单（评估基准）
以下为银行贷前尽调的标准材料体系，完备性评估的依据。材料分三级：必备（缺失则建议暂缓）、建议（缺失须向用户提示）、补充（有则更优）。
| 材料类型 | 级别 | 评估要点 |
|---|
| 尽调报告 / 授信调查报告 | 必备 | 须包含企业基本情况、经营分析、财务分析、还款来源分析 |
| 拜访记录（近6个月） | 必备 | 须有实质性经营信息，纯问候性记录不计入 |
| 财务资料（近2-3年） | 必备 | 至少含营业收入、净利润、资产负债情况 |
| 营业执照及资质证明 | 必备 | 须在有效期内，经营范围与申请用途匹配 |
| 担保/抵押物评估材料 | 建议 | 有担保安排时必须提供；纯信用贷款时可豁免 |
| 银行流水（近6-12个月） | 建议 | 支持还款来源真实性核查 |
| 股东/实控人信息 | 建议 | 含身份证明、个人征信授权 |
| 行业特殊资质 | 补充 | 特许经营行业（食品/医药/建筑等）须核查行业许可证 |
对接提示：材料盘点能力映射至贵行客户档案查询接口，返回字段须含：材料类型、文件名、上传日期、状态（有效/过期/待审）
执行流程 (Workflow)
交互模式:模式 B - 步骤门控型(Step-Gated)
当用户要求提交授信申请时,按以下流程执行:
步骤 0:数据确认与验证(先读后写)
- 列出所有输入数据源:客户笔记清单、客户材料清单、案件状态、授信台账
- 确认数据时间范围:尽调报告日期、财务报表期间、拜访记录时间跨度
- 确认案件类型意图:续贷/新增/追加
- 运行验证脚本:
python scripts/validate_application.py --check-materials --check-conflicts
- 验证通过后进入步骤1;验证失败则输出缺失清单,要求用户补充
📋 数据来源:system_api(信贷系统影像档案、案件管理、授信台账)
📋 执行主体:ai
📋 确认机制:none
⚠️ 强制指令:不得跳过数据验证步骤,必须确认所有输入数据的有效性
步骤 1:前置状态核查
门控步骤:此步骤不通过不得进入后续流程
案件冲突检查
- 查询该客户是否存在处于“审批中/待补件/待签约”状态的活跃案件
- 门控分支:
- ✅ 无活跃案件 → 进入授信到期检查
- ❌ 存在活跃案件 → 立即停止,向用户告知冲突,提示现有案件编号和当前状态,询问是否需要撤销或继续等待,不进入后续流程
- ⚠️ 查询超时 → 标注“案件冲突未核查”,提示用户手动确认无活跃案件,用户确认后方可继续
📋 数据来源:system_api(信贷系统案件管理模块)
📋 执行主体:ai
📋 确认机制:approve(存在冲突时必须用户明确决策)
授信到期检查
- 核查该客户现有授信额度的到期日,判断本次申请是续贷(到期前90天内)还是新增授信
- 自动标注建议案件类型,提交确认时向用户展示
📋 数据来源:system_api(核心系统授信模块)
📋 执行主体:ai
📋 确认机制:none
步骤 2:材料盘点
- 枚举客户笔记:列出该客户的所有已有笔记(尽调报告、拜访记录、走访小记等)及摘要
- 枚举客户材料:列出该客户已上传文件和已发布材料清单
- 必须读取关键笔记或材料内容,了解材料的实质内容(而非仅确认文件存在)
- 对照
references/material-checklist.md中的材料清单逐项核对
📋 数据来源:system_api(信贷系统影像档案)
📋 执行主体:ai
📋 确认机制:none
⚠️ 强制指令:不得仅统计文件数量,必须检查实质内容(如尽调报告须包含经营分析和财务分析)
步骤 3:完备性评估
基于盘点结果,对照授信申请材料清单(见references/material-checklist.md)逐项判断:
评估展示格式
材料完备性评估结果:
✅ 已具备(必备)
- 尽调报告(2024-01-15,含经营分析和财务分析)
- 拜访记录(近3个月共2次,有实质经营信息)
- 财务资料(2021-2023年三年数据)
⚠️ 建议补充
- 银行流水(仅有3个月,建议补充至6个月)
❌ 缺失(必备材料)
- 营业执照(档案中未见,请上传)
综合评估:[可以提交 / 建议补充后提交 / 暂缓提交]
原因说明:[1-2句话说明评估依据]
评估判断标准
- 可以提交:必备材料全部齐全,内容质量达标
- 建议补充后提交:必备材料齐全但“建议”类材料有缺失,向用户告知风险后由用户决定
- 暂缓提交:必备材料有缺失,明确建议用户先补充
- 门控分支:
- ✅ 评估为“可以提交”或“建议补充后提交” → 进入步骤4
- ❌ 评估为“暂缓提交” → 触发红线R1,立即停止,向用户展示缺失项,建议先补充材料
- ⚠️ 材料存疑 → 标注存疑项,向用户说明具体情况,由用户决定是否继续
📋 数据来源:context(步骤2盘点结果)
📋 执行主体:ai
📋 确认机制:inform(评估结果须向用户展示)
步骤 4:案件类型确认
| 案件类型 | 适用场景 | 识别信号 |
|---|
| 续贷(renewal) | 现有授信到期前续期,金额和条件基本不变 | 用户说“续贷”、“到期了”、“续一下” |
| 新增授信(first_credit) | 该客户首次建立授信关系 | 用户说“新客户”、“首次”、“没有额度” |
| 追加授信(additional) | 现有授信不足,申请增加额度 | 用户说“额度不够”、“追加”、“增加一些” |
- 优先根据步骤1中授信到期检查的结论自动判断
- 有歧义时询问用户确认,不得做假设
- 门控分支:
- ✅ 案件类型明确 → 进入步骤5
- ⚠️ 有歧义 → 询问用户确认,用户确认后方可继续
📋 数据来源:context(步骤1检查结果 + 用户输入)
📋 执行主体:ai
📋 确认机制:inform(向用户展示并确认)
步骤 5:确认提交
门控步骤:此步骤不通过不得发起案件创建
- 向用户展示评估结果和建议案件类型
- 如果材料充分:建议提交,询问用户确认(“是否确认提交?”)
- 如果有缺失:告知缺失项和影响,由用户决定是继续提交还是先补充材料
- 用户确认门控:
- ✅ 用户明确说“提交”或“确认” → 发起案件创建
- ❌ 用户说“先不提交”或“等一下” → 终止流程,不创建案件
- ⚠️ 用户说“好的”等模糊表述 → 不得判定为确认,须再次明确询问“是否确认提交?”
📋 数据来源:context(步骤3评估结果)
📋 执行主体:ai
📋 确认机制:explicit(必须用户明确确认)
⚠️ 红线R3:未获用户明确确认,禁止发起案件创建,无论材料是否充分
输出格式 (Output Format)
本输出可被 credit-approval-decision Skill 解析使用
使用 assets/credit-application-template.md 模板。评估报告必须包含以下6个章节:
| 章节 | 内容 | 下游可解析字段 |
|---|
| 1.前置状态核查 | 案件冲突检查结果、授信到期检查 | conflict_detected(bool)、existing_credit_expiry(date) |
| 2.材料盘点清单 | 客户笔记清单、客户材料清单 | materials_found(array)、notes_count(int) |
| 3.完备性评估 | ✅已具备、⚠️建议补充、❌缺失 | assessment_result(enum)、missing_essentials(array) |
| 4.综合评估结论 | 可以提交/建议补充后提交/暂缓提交 | recommendation(enum)、reason(string) |
| 5.案件类型确认 | 续贷/新增授信/追加授信 | application_type(enum) |
| 6.用户确认记录 | 确认时间、确认方式、案件编号 | confirmed(bool)、case_id(string) |
数据标注要求:所有数据标注:数据来源 + 数据日期 + 是否最新数据。
免责声明:输出末尾必须附加免责声明,引用 shared/disclaimer-template.md 模板,确保包含“本评估仅基于提供的材料进行完备性检查,不构成授信审批建议”等必要声明。
审计追踪 (Audit Trail)
每次授信申请提交结束后，生成审计日志 audit/{客户简称}_{日期}_audit.json：
{
"skill_name": "submit-credit-application",
"skill_version": "1.0.0",
"execution_time": "2026-05-05T10:30:00+08:00",
"input_params": {
"customer_name": "XX企业",
"application_type": "renewal/first_credit/additional",
"application_amount": 50000000
},
"operator": "客户经理姓名（工号：XXX）",
"steps": [
{
"step": "前置状态核查",
"executor": "ai",
"data_source": {"type": "system_api", "system": "信贷系统案件管理模块"},
"result": "pass",
"conflict_detected": false
},
{
"step": "材料盘点",
"executor": "ai",
"data_source": {"type": "system_api", "system": "信贷系统影像档案"},
"result": "pass",
"materials_found": 8,
"materials_missing": 1
},
{
"step": "完备性评估",
"executor": "ai",
"data_source": {"type": "context"},
"result": "pass",
"assessment": "建议补充后提交"
},
{
"step": "确认提交",
"executor": "ai",
"data_source": {"type": "context"},
"confirmation": {"type": "explicit", "confirmed_by": "客户经理姓名（工号：XXX）", "confirmed_at": "2026-05-05T10:35:00+08:00"},
"result": "pass",
"case_id": "CASE-2026-001234"
}
],
"red_line_triggered": [],
"warnings": ["银行流水仅有3个月，建议补充至6个月"],
"references_used": ["references/material-checklist.md"]
}
踩坑记录 (Gotchas)
#1：材料数量充足但质量不达标
- 症状：尽调报告仅1页，缺少经营分析和财务分析，但系统判定“已具备”
- 原因：仅统计文件数量，未检查实质内容
- 解决：必须读取关键材料内容，验证是否包含必要分析维度（企业基本情况、经营分析、财务分析、还款来源）
#2：案件冲突未检测到
- 症状：同一客户存在两个活跃审批案件，导致审批流程混乱
- 原因：案件状态查询接口超时，未触发降级策略
- 解决：查询超时必须标注“案件冲突未核查”，提示用户手动确认
#3：用户未明确确认就提交
- 症状：用户说“好的”，系统即判定为确认提交
- 原因：确认机制不严格，“好的”可能是对评估结果的认可，而非提交指令
- 解决：必须用户明确说“提交”或“确认”后才可发起案件创建
#4：案件类型推断错误
- 症状：用户说“续一下”，系统判定为续贷，但实际是追加授信
- 原因：未结合授信到期检查结论，仅凭用户口语判断
- 解决：优先根据授信到期检查结论自动判断，有歧义时询问用户确认
#5：必备材料缺失仍建议提交
- 症状：营业执照缺失，但评估结论为“可以提交”
- 原因：未严格执行红线R1（必备材料缺失）
- 解决：必备材料（尽调报告、拜访记录、财务资料、营业执照）缺失必须触发红线，建议“暂缓提交”
示例 (Examples)
示例1：标准续贷提交
用户输入：
请为XX制造企业的续贷申请提交授信申请。客户授信5000万将于2026-06-15到期，需要续贷。
Skill 执行流程：
- 前置状态核查 → 无活跃案件，授信到期前41天，判定为续贷
- 材料盘点 → 尽调报告、拜访记录、财务资料齐全，银行流水仅有3个月
- 完备性评估 → 必备材料齐全，建议类材料有缺失，评估为“建议补充后提交”
- 用户确认 → 用户明确说“提交”，发起案件创建
- 提交成功 → 返回案件编号 CASE-2026-001234
输出要点：
- 综合评估：建议补充后提交
- 缺失项：银行流水（仅有3个月，建议补充至6个月）
- 案件类型：续贷（renewal）
示例2：首次授信提交（触发红线）
用户输入：
为新客户YY贸易公司提交首次授信申请。
Skill 执行流程：
- 前置状态核查 → 无活跃案件，无现有授信，判定为新增授信
- 材料盘点 → 尽调报告缺失，营业执照缺失
- 完备性评估 → 触发红线R1（必备材料缺失），评估为“暂缓提交”
- 用户告知 → 告知缺失项和影响，建议先补充材料
- 用户决定 → 用户说“先补充材料”，终止提交
输出要点：
- ⚠️ 红线触发：R1（必备材料缺失）
- 缺失项：尽调报告、营业执照
- 综合评估：暂缓提交
非功能范围 (Out of Scope)
- 本 Skill 不处理授信审批决策，仅提供材料完备性评估
- 本 Skill 不生成尽调报告或拜访记录（请使用 credit-due-diligence 或 visit-memo Skill）
- 本 Skill 不直接修改客户数据或提交审批结果
- 本 Skill 不处理个人信贷/零售业务
- 本 Skill 不处理贷后管理、风险分类调整、不良资产处置
- 如果用户请求以上内容，明确告知并建议合适的 Skill 或联系相应部门
