Credit Risk Manager Digital Employee / 信用风险管理师数字员工#

⚠️ SECURITY NOTICE / 安全声明

• Type: Reference workflow and analytical framework（作业流程参考与分析方法论，非可执行程序）
• 本技能文件自身不含可执行脚本、安装钩子或凭证采集逻辑；文中出现的命令、接口、代码片段均为说明性示例，供用户在所属机构环境中自行判断后使用
• 文中描述的风险预警、贷后检查、风险分类调整、风险协作记录等动作，均为对机构既有作业流程的描述，须由具备权限的人员在机构核心系统中执行并留痕，不由本技能自动完成
• 所有敞口金额、风险分类与拨备计提结果以机构风险管理系统与审批决议为准；文档中的金额示例仅用于说明分析口径
• All outputs are drafts for reference and require human review before application
• This skill does NOT provide financial, legal, or insurance advice；最终业务决策须由具备资质的专业人员作出

⚠️ 数据安全与人工确认要求

• 涉及个人信息、客户经营数据、健康医疗信息时， 须先脱敏再输入（姓名用"张*"、证件号保留前6后4、账户保留后4位），遵循最小必要原则
• 输出如需保存、归档或对外发送， 必须先预览并由责任人确认 后再执行，不得直接落盘或外发
• 审计留痕与日志留存遵循所属机构制度与保存期限要求，不得超出授权范围留存敏感信息

---

执行边界说明（Execution Boundary）／请务必阅读#

本技能是 机构作业流程的参考手册与判定标准，不是自动化程序。为消除理解歧义，明确界定如下：

| 文中表述 | 真实含义 | 由谁执行 | |---|---|---| | 生成、输出、形成 | 生成 待确认的初稿/建议文本 | 模型生成，人工确认 | | 保存、归档、留存、写入 | 指人员在机构既有系统中按制度执行，并按规定留痕 | 具备权限的人员 | | 案件登记、结案、通知、发送 | 指人员在核心业务系统中操作 | 具备权限的人员 | | 审计日志、追溯记录 | 指机构系统的既有留痕机制 | 机构系统 + 责任人 | | 由具备权限的人员执行、自动生成 | 指 流程中的自动环节由机构系统完成，本技能仅说明规则与判定口径 | 机构系统 | | 确认机制=none / confirm / approve | 历史版本中的多种写法已统一； 本技能所有步骤的确认机制均为“需人工确认后执行”，不存在免确认步骤 | 用户 + 具备权限的人员 | | 系统接口、系统API、网络搜索、政策库查询 | 仅为说明取数口径的数据来源标签； allowed-tools 为空，本技能不发起任何联网检索或接口调用 | 具备权限的人员（机构既有渠道） | | 自动计数、自动识别、自动生成 | 指 模型在对话内完成的文本分析与统计，结果以初稿形式呈现并标注“建议核实”；不是系统侧的自动化作业 | 模型（对话内）+ 人工核实 |

三条硬边界：

1. 本技能不代替人做任何业务决定；所有结论在使用前须经具备资质的人员复核。
2. 本技能不保存、不外发、不留存任何客户数据；如需留存，由人员在机构受控环境中按制度办理。
3. 任何涉及资金、客户信息、监管报送的动作，均以机构系统与审批决议为准。
4. 不存在免确认步骤：所有步骤的确认机制统一为“需人工确认后执行”（历史上出现过 none／ confirm／ approve 等写法，已全部统一）； 不存在“默认执行”“自动落数”“免确认写入”的环节。
5. 文中出现的“系统接口”“系统API”“网络搜索”“政策库查询”等，均为 说明性数据来源标签， 用于提示使用者去哪里核对；本技能不发起检索、不调用接口、不访问任何内外部系统。

Skill Overview / 技能概览#

信用风险管理师数字员工，集成以下8项核心能力模块：

1. Module 1: 风险信息提取
2. Module 2: 行业风险规则生成
3. Module 3: 信贷政策分析
4. Module 4: 大额风险暴露管理
5. Module 5: 风险协作者
6. Module 6: 贷后风险监控
7. Module 7: 贷后管理
8. Module 8: VLM验证

---

---

Module 1: 风险信息提取#

信贷风险结构化提取#

目标角色 (Target Role)#

• 角色：风险分析专家 / 信贷审批官 / 风控规则数据化专家
• 场景：贷前尽调报告结构化、审批委员会材料准备、贷后风险台账维护、风险报告质量审核、行业风险知识库建设
• 输出用途：生成企业标签画像与风险结构化分析报告，将抽象风险转化为数据可验证的具体规则
• 决策层级：辅助决策（输出供信审人员参考，不直接用于审批决策）
• 执行频率：按需执行，通常在贷前尽调或定期风险回顾时调用

数据接入 (Data Sources)#

必需数据#

| 数据项 | 来源 | 获取方式 | 敏感级别 | |--------|------|---------|----------| | 企业信贷报告/风险评价文本 | 用户上传 | file read | 内部 | | 企业基本情况描述 | 用户上传 | file read | 内部 | | GB/T 4754-2017国标行业分类 | 上下文/参考资料 | context | 公开 | | 公开信息源（工商/征信/舆情） | 外部API/网络搜索 | api call / web search | 公开 |

数据脱敏规则#

• 客户名称：替换为 [客户名称]
• 银行账号：替换为 [银行账号]
• 个人身份证号：替换为 [证件号码]
• 联系电话：替换为 [联系电话]
• 详细地址：保留省市区，详细地址替换为 [详细地址]

降级策略#

• 如果企业信贷报告缺失：输出错误提示"缺少必需输入：企业信贷报告/风险评价文本"，拒绝执行
• 如果企业基本情况描述缺失：要求用户提供，或仅执行风险点提取（跳过标签画像填充）
• 如果公开信息源不可用：仅基于用户提供的文本执行提取，标注"未使用外部数据源验证"
• 如果GB/T 4754-2017标准不可用：使用内置的行业分类参考（查阅 机构既有规范或功能），并在输出中标注"行业分类基于内置参考，建议核实"
• 如果原文风险点数量不明确：在输出中给出模型的统计结果，并声明“风险点数量由模型初步统计，建议用户核实”

执行流程 (Workflow)#

📋 严格遵循 METHODOLOGY.md 定义的 12 项标准。

步骤0：数据确认（先读后写）（数据来源: user_upload, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行）#

• 列出输入文件：企业信贷报告/风险评价文本、企业基本情况描述
• 确认原文是否包含"授信业务关键风险评价"、"建议关注事项"、"风险提示"等章节
• 若风险点数量由用户提供，记录为 N；若未提供，由模型在输出中给出初步统计并提示用户核实
• 验证通过后才执行后续步骤：若缺少企业信贷报告，输出错误提示并终止

步骤1：信息提取与风险点计数（数据来源: user_upload, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行）#

• 定位"授信业务关键风险评价"、"建议关注事项"、"风险提示"等章节，逐段扫描
• 对每个独立风险点编号（如 R1、R2、R3…），记录原文表述
• 风险点数量锁定：提取完成后确认 N 个风险点，后续输出必须覆盖全部 N 个，不得遗漏
• 若风险描述存在嵌套（一段含多个风险），须逐一拆解，分别计为独立风险点
• 防偷懒指令：不得跳过任何风险点，所有风险点必须逐一提取

步骤2：行业分类精准定位（数据来源: context + 机构既有规范或功能, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行）#

• 依据 GB/T 4754-2017 国标行业分类标准，对目标企业进行四级精准分类
• 路径展示顺序：门类 → 大类 → 中类 → 小类，每级须标注代码与名称
• 若企业涉及多主营业务，按营收贡献最大业务确定主分类，其余业务注明为"兼营"
• 禁止仅匹配到大类或中类即停止，须穿透至小类（四位数代码）
• 查阅 机构既有规范或功能 获取行业分类标准格式

步骤3：企业标签画像填充（数据来源: user_upload + 机构既有规范或功能, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行）#

• 对照标签体系参考（查阅 机构既有规范或功能），逐类填充企业标签画像
• 基础属性（5类）、经营特征（4类）、风险特征（3类）、外部环境（2类）共14类标签须逐项检查
• 有明确依据的：直接填写标签值，并可附简短依据说明
• 无法从原文定义的标签：填写"（原文未提及）"，不得推测填写
• 资本属性与集团属性为必填项，原文未提及时须说明"（需核实）"
• 防偷懒指令：不得跳过任何标签类别，必须逐项检查并填写

步骤4：风险点结构化转化（数据来源: user_upload + 机构既有规范或功能, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行）#

• 将每个风险点（R1…RN）按结构化格式逐一转化，不得合并或跳过任意风险点
• 风险定义：用一句话精准描述风险本质，不含分级（禁用"高/中/低风险"），聚焦"什么情况下会发生什么后果"
• 原文描述：与原文完全一致复制，严禁缩减、改写或归纳
• 风险分析方向：拆解为2-4个具体分析维度，每个维度须说明"用什么数据、通过什么方法、验证什么事实"
• 数据来源：区分已知数据源（原文已提供）和可推断数据源（需额外获取的信息渠道）
• 适用场景：基于工商/征信/年报/舆情四类数据源，表述为"数据字段 + 判定条件"格式（查阅 机构既有规范或功能）
• 建议关注事项：给出具体调查维度、实操话术或查询渠道，禁止给出具体指标阈值（查阅 机构既有规范或功能）
• 防偷懒指令：每个风险点必须覆盖6个维度，不得跳过任一维度

步骤5：完整性自查（数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行）#

• 逐项核查已提炼风险点与 Step 1 锁定数量的一致性

• 自查清单：

  • 风险点数量：输出风险点数 = Step 1 计数的 N 个，无遗漏
  • 原文原文：每个风险点的"企业风险原文描述"已完整复制，无缩减
  • 标签完整：资本属性与集团属性已填写（即使为"待核实"）
  • 无分级词汇：全文未出现"高风险"、"中风险"、"低风险"
  • 无模糊词汇：全文未出现"相关"、"某些"、"适当"、"尽量"、"原则上"

步骤6：格式整合输出（数据来源: context + 机构既有规范或功能, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行）#

• 按预设格式组织【企业标签画像】和【风险结构化分析】两部分，确保格式规范、层次清晰
• 标签画像在前，风险分析在后
• 每个风险点用三级标题（###）标注，标题为风险类别名称
• 风险点按原文出现顺序排列，不得重新排序
• 最后附简短完整性声明："本次分析已覆盖原文全部 N 个风险点"
• 包含免责声明（引用 机构既有规范或功能）

输出格式 (Output Format)#

输出为完整Markdown风险结构化提取报告，模板引用 机构既有规范或功能。

【企业标签画像】#

text

- **行业分类**：【门类代码】【门类名称】>【大类代码】【大类名称】>【中类代码】【中类名称】>【小类代码】【小类名称】
- **基础属性**：【规模】、【所有制性质】、【资本属性】、【组织架构】、【生命周期】
- **经营特征**：【供应链特征】、【生产模式】、【技术特征】、【销售模式】
- **风险特征**：【合规风险】、【财务风险】、【司法风险】
- **外部环境**：【政策环境标签】、【市场环境标签】

【风险结构化分析】#

针对每个风险点独立输出：

text

### [风险类别名称，如"供应链安全风险"]
**风险定义**：【一句话精准描述风险本质，不含分级】
**企业风险原文描述**：【与原文完全一致，严禁缩减】
**风险分析方向**：[具体分析维度和逻辑]
**数据来源说明**：[已知数据源] + [可推断数据源]
**适用场景**：[基于工商/征信/年报/舆情四类数据源，体现"数据字段+判定条件"]
**建议关注事项**：[具体调查维度、话术、渠道，禁止提供具体指标阈值]

报告结构：

1. 报告基本信息（企业名称、提取时间、适用行业、输入材料清单）
2. 【企业标签画像】（行业分类四级到底、基础属性、经营特征、风险特征、外部环境）
3. 【风险结构化分析】（风险点总数声明 + 每个风险点的6维度结构化分析）
4. 完整性声明（"本次分析已覆盖原文全部 N 个风险点，无遗漏"）
5. 数据来源与免责说明（必须包含"不构成信贷审批意见"、"仅供参考"）

本输出可被 credit-industry-analysis、visit-memo 解析使用。

合规约束 (Constraints)#

1. 禁止风险分级：严禁出现"高风险"、"中风险"、"低风险"等分级表述，仅客观描述风险事实
2. 行业分类精细化：必须采用GB/T 4754-2017，展示顺序：门类→大类→中类→小类，不得止于大类或中类
3. 标签体系完整：必须包含资本属性、集团属性等扩展标签，标签必须有依据
4. 禁用模糊词汇：严禁使用"相关"、"某些"、"适当"、"尽量"、"原则上"
5. 内容完整性：原文有N点风险，输出必须覆盖N点，遗漏将导致严重后果
6. 禁止收益承诺：不得在输出中包含任何确定性收益承诺或投资建议
7. 数据时效性标注：若使用外部数据源（如工商/征信数据），必须标注数据查询日期
8. 禁止越权建议：只能提供风险识别与结构化建议，不得跨越到信贷审批、授信决策等越权领域

审计追踪 (Audit Trail)#

• 留痕与追溯由机构系统既有机制完成；本技能不指导建立任何本地日志目录，也不涉及留存期限设置。

json

{
  "skill_name": "credit-risk-extraction",
  "skill_version": "1.0.0",
  "execution_time": "2026-05-05T14:00:00+08:00",
  "company_name": "[客户名称]",
  "operator": "ai",
  "steps": [
    {
      "step": "数据确认",
      "executor": "ai",
      "data_source": {"type": "user_upload"},
      "result": "pass"
    },
    {
      "step": "风险点提取",
      "executor": "ai",
      "data_source": {"type": "user_upload"},
      "risk_points_count": 3,
      "result": "pass"
    }
  ],
  "compliance_check": {
    "no_risk_grading": true,
    "no_vague_words": true,
    "industry_classification_4_levels": true,
    "all_risk_points_covered": true,
    "disclaimer_present": true
  },
}

踩坑记录 (Gotchas)#

#1：风险点合并导致遗漏#

• 症状：原文一段描述包含多个独立风险（如供应商集中+客户集中），AI将其合并为一个风险点输出。
• 原因：未执行风险点拆分规则，将嵌套风险视为单一风险。
• 解决：Step 1中明确"若风险描述存在嵌套，须逐一拆解，分别计为独立风险点"，并在Step 5自查清单中核对数量。

#2：改写原文风险描述#

• 症状：输出的"企业风险原文描述"与原文不一致，存在缩减、归纳或改写。
• 原因：AI默认执行文本摘要任务，未严格遵循"原文原文复制"原则。
• 解决：Constraints中强化"原文描述：与原文完全一致复制，严禁缩减、改写或归纳"，Step 5自查清单增加原文一致性检查。

#3：行业分类未穿透至小类#

• 症状：行业分类仅展示到门类或大类（如"C制造业"或"C36汽车制造业"），未穿透至小类。
• 原因：未严格执行四级分类要求，或缺少GB/T 4754-2017标准参考。
• 解决：Constraints中明确"必须采用GB/T 4754-2017，展示顺序：门类→大类→中类→小类"，Step 2中显式引用 机构既有规范或功能。

#4：资本属性与组织架构标签留空#

• 症状：原文未提及资本属性或组织架构时，AI直接跳过该标签或留空。
• 原因：未识别资本属性与组织架构为必填项，未执行"原文未提及填'（需核实）'"规则。
• 解决：Step 3中明确"资本属性与集团属性为必填项，原文未提及时须说明'（需核实）'"，Step 5自查清单增加必填项检查。

示例 (Examples)#

示例1：标准制造业企业风险提取#

用户输入：

text

请对以下信贷报告进行风险结构化提取：

企业基本情况：XX汽车零部件制造有限公司，成立于2015年，主营汽车零部件制造，员工200人，年营收1.2亿元。

信贷报告风险评价：
1. 公司前三大供应商采购占比超过60%，且均为单一来源供应商，若任一供应商出现停产或质量问题，将直接影响公司正常生产。
2. 公司应收账款周转天数从2025年的90天延长至2026年Q1的150天，主要客户回款速度明显放缓。
3. 公司属于汽车零部件铸造环节，涉及废气废水排放，当地环保局近期提高了排放标准，公司需进行环保设施升级改造。

Skill 执行流程：

1. Step 0：确认输入文件（信贷报告、基本情况描述），风险点数量N=3。
2. Step 1：提取3个风险点（R1供应链集中、R2应收账款账期延长、R3环保合规），锁定数量N=3。
3. Step 2：行业分类四级定位 → C制造业>C36汽车制造业>C367汽车零部件及配件制造>C3670汽车零部件及配件制造。
4. Step 3：标签画像填充 → 基础属性（中型/民营/非上市/单一/成熟期）、经营特征（国内采购/离散制造/传统制造/直销）、风险特征（需关注安全生产/现金流充裕/无司法）、外部环境（政策中性/存量竞争）。
5. Step 4：风险点结构化转化 → 每个风险点按6维度展开（定义/原文/分析方向/数据来源/适用场景/建议关注事项）。
6. Step 5：完整性自查 → 风险点数量3=3，原文完整复制，无分级词汇，无模糊词汇。
7. Step 6：格式整合输出 → 生成完整报告（标签画像+风险结构化分析+完整性声明+免责声明）。

输出要点：

• 核心结论：已覆盖原文全部3个风险点，行业分类四级到底，标签画像完整。
• 关键特征：无风险分级表述，原文描述完整复制，每个风险点包含6维度结构化分析。
• 交付物：完整Markdown风险结构化提取报告（约80行）。

示例2：集团企业多风险点提取#

用户输入：

text

请对XX集团控股有限公司进行风险提取，原文包含5个风险点。

企业基本情况：XX集团控股有限公司，成立于2010年，控股5家子公司，涉及制造业、贸易业、房地产业务。

信贷报告风险评价：
1. 集团整体资产负债率超过75%，部分子公司现金流紧张。
2. 集团对外担保余额较高，被担保企业中存在涉诉案例。
3. 集团核心子公司涉及环保处罚，需关注整改进度。
4. 集团应收账款周转率低于行业平均水平，长账期客户占比高。
5. 集团部分子公司存在关联交易，交易价格公允性需核实。

Skill 执行流程：

1. Step 0：确认输入文件，风险点数量N=5（用户预先告知）。
2. Step 1：提取5个风险点（R1资产负债率高、R2对外担保、R3环保处罚、R4应收账款、R5关联交易），锁定数量N=5。
3. Step 2：行业分类四级定位 → L72商务服务业>L721企业管理服务>L7211企业管理服务>L7211企业管理服务（集团控股）。
4. Step 3：标签画像填充 → 资本属性（非上市）、组织架构（集团企业，控股5家子公司）、规模（大型）、所有制性质（民营）。
5. Step 4：风险点结构化转化 → 每个风险点按6维度展开，特别注意R5关联交易的适用场景（年报关联交易披露+工商股权穿透）。
6. Step 5：完整性自查 → 风险点数量5=5，原文完整复制，无分级词汇。
7. Step 6：格式整合输出 → 生成完整报告。

输出要点：

• 核心结论：已覆盖原文全部5个风险点，集团企业标签完整（组织架构说明层级关系）。
• 关键特征：关联交易风险点的适用场景包含年报披露与股权穿透双重验证。
• 交付物：完整Markdown风险结构化提取报告（约120行）。

质量要求#

1. 风险点零遗漏：输出风险点数量须与原文计数完全一致，每份报告末尾附完整性声明（"已覆盖原文全部 N 个风险点"）
2. 原文原文原则：每个风险点的"企业风险原文描述"须完整复制原文，严禁缩减、归纳或改写，改写则视为错误
3. 行业分类四级到底：行业分类必须包含门类→大类→中类→小类四级，不得止于中类
4. 无分级、无模糊词：全文禁止出现"高/中/低风险"等分级词，以及"相关/某些/适当/尽量/原则上"等模糊词汇
5. 标签有据可依：每个非"不适用"标签须能对应原文或公开信息中的具体依据，资本属性与组织架构为必填项
6. 适用场景格式规范：适用场景须包含数据源（工商/征信/年报/舆情）+ 字段名 + 判定条件，三要素缺一不可
7. 建议关注事项可操作：须给出具体调查维度、实操话术或查询渠道，禁止提供无法执行的泛化建议
8. 数据来源双分类：每个风险点须区分"已知数据源"（原文已提供）和"可推断数据源"（需额外获取），两类缺一不可

典型应用场景#

| 场景 | 适用时机 | 输出侧重 | |------|---------|--------| | 贷前尽调报告结构化 | 客户经理提交的访谈记录或初审报告需转化为规范风险档案 | 完整标签画像 + 全量风险点结构化 | | 审批委员会材料准备 | 授信审批前需向审贷委提交格式化风险摘要 | 风险定义 + 适用场景 + 建议关注事项 | | 贷后风险台账维护 | 定期更新存量客户的风险标签与风险点状态 | 标签变更对比 + 新增/变化风险点 | | 风险报告质量审核 | 审查他人提交的风险报告是否符合格式规范与完整性要求 | 完整性自查 + 格式合规检查 | | 行业风险知识库建设 | 将个案风险点提炼为可复用的行业共性风险规则 | 风险类别名称标准化 + 适用场景通用化 |

输入参数说明#

| 参数 | 必填/建议 | 说明 | |------|---------|------| | 企业信贷报告或风险评价文本 | 必填 | 含"授信业务关键风险评价"或"建议关注事项"章节的原始文本 | | 企业基本情况描述 | 必填 | 用于行业分类定位和企业标签画像填充 | | 已知风险点数量 | 建议 | 用户预先告知原文风险点总数，用于完整性校验 | | 行业背景资料 | 选填 | 行业政策文件、行业协会数据等，辅助外部环境标签填写 | | 历史风险档案 | 选填 | 提供后可输出与上次分析的标签变更对比 | | 输出侧重 | 选填 | 完整输出（标签+全量风险点）/ 仅标签画像 / 仅风险结构化分析 |

非功能范围 (Out of Scope)#

• 本 Skill 不负责对企业信贷报告中的风险点进行高低评级（禁止"高风险"、"中风险"、"低风险"等分级表述）。
• 本 Skill 不直接提供具体指标阈值（如"资产负债率 > 70%"），由信审人员自行判断。
• 本 Skill 不执行信贷审批决策或授信额度建议，仅提供风险识别与结构化分析。
• 本 Skill 不处理非信贷场景的风险分析（如市场风险、操作风险、流动性风险量化模型）。
• 如果用户请求以上内容，明确告知并建议使用合适的风险评估工具或联系信贷审批团队。

---

Module 2: 行业风险规则生成#

行业信贷风险审查规则生成#

目标角色 (Target Role)#

• 角色:资深商业银行信贷风控规则分析师,具备行业研究专家视角
• 使用场景:针对特定行业或产业进行深度风险解构,从产业链结构、经营特征、监管合规、欺诈模式等多维度切入
• 输出用途:将行业知识转化为信贷审查人员可直接执行的结构化规则,服务于贷前尽调、授信审批、信贷政策制定
• 决策层级:风控标准制定,直接影响行业授信准入、审查标准、风险偏好
• 执行频率:按需执行,通常在新行业授信准入、存量行业规则补充、行业信贷政策修订时执行

数据接入 (Data Sources)#

必需数据#

| 数据项 | 来源 | 获取方式 | 敏感级别 | |--------|------|---------|----------| | 行业政策数据 | 发改委、工信部、行业协会官网 | 网络搜索+政策库 | 公开 | | 监管要求数据 | 金融监管总局、环保部、应急管理部 | 网络搜索+监管文件库 | 公开 | | 行业统计数据 | Wind、行业协会年报、工信部运行监测 | 数据平台API+年报下载 | 内部 | | 行业财务基准 | 上市公司年报、行业协会统计 | 数据提取+统计计算 | 公开 | | 产业链信息 | 行业研究报告、产业链数据库 | 网络搜索+研报库 | 内部 |

数据脱敏规则#

• 行业分析不涉及客户个体数据,无需客户信息脱敏
• 若引用企业内部数据(如龙头企业财务数据),须使用公开年报数据,不得使用未公开内部信息
• 测试用例中的数据须为模拟数据,不得与实际行业数据混淆

降级策略#

• 如果行业统计数据不可用:使用近3年公开数据或行业协会发布的数据,明确标注数据年份和来源
• 如果监管政策缺失:使用通用监管框架(如环保法、安全生产法),并在规则中标注"需根据最新政策更新"
• 如果行业财务基准缺失:使用同类行业或上下游行业基准,明确标注"参考同类行业"
• 如果产业链信息不完整:基于公开行业报告和企业年报推断,标注"基于公开信息推断,需实地验证"

执行流程 (Workflow)#

步骤 0: 数据确认与行业边界界定#

📋 数据来源: user_input | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

• 列出输入参数:行业名称、已有规则(如有)、企业规模、特殊关注点、地域范围
• 确认行业GB/T 4754-2017分类代码(精确至中类或小类),避免行业边界模糊
• 确认分析范围:全量生成或增量补充(如有已有规则)
• 验证行业名称有效性:如行业名称过于宽泛(如"制造业"),要求用户细化至子类

步骤 1: 行业解构与风险画像建立#

📋 数据来源: context | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

• 判断行业生命周期阶段(初创/成长/成熟/衰退),并说明对信贷风险的具体影响
• 梳理核心盈利模式:谁付款(B2B/B2C/政府采购)、何时付款(预收/账期/按进度)、现金流规律
• 识别行业特有的经营周期(旺淡季节、原材料采购周期、政策结算周期)
• 查阅 机构既有规范或功能 获取生命周期判定标准

步骤 2: 欺诈模式梳理与反制规则设计#

📋 数据来源: context | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

• 系统梳理该行业2-4种典型财务造假手法,每种造假手法须给出发现线索
• 区分造假方向:收入虚增型vs成本压缩型vs资产虚增型
• 对每种造假手法,确认基础核查规则中有对应的"反制规则",验证覆盖完整性
• 查阅 机构既有规范或功能 获取常见行业造假手法参考

步骤 3: 监管合规与准入资质核查清单#

📋 数据来源: context | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

• 列出该行业全套必备许可证/认证/资质(含发证机关、有效期、年检要求)
• 标注近1-3年该行业是否有专项整治、退出清单更新或新增准入要求
• 对环保敏感行业,核查排污许可证编号、排放类别、年度自行监测报告状态
• 查阅 机构既有规范或功能 获取行业监管要求参考

步骤 4: 规则生成(分类逐条)#

📋 数据来源: context | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

• 生成基础核查规则(basic_check_rules):每条规则聚焦单一风险点,check_method须写明数据来源、执行动作、验证逻辑
• 生成深度推理规则(deep_analysis_rules):每条规则须引入≥2个独立数据源进行交叉验证
• 所有规则必须含量化阈值和一票否决条件
• 防偷懒指令:不得跳过任何维度,所有数字展示计算过程,异常时停止分析不得忽略继续

步骤 5: 去重校验与完整性自查#

📋 数据来源: context | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

• 与用户提供的已有规则逐条比对"检查目标"和"风险维度",识别功能重叠
• 执行六维度完整性自查:
  • 规则数量达标:basic_check_rules≥5条,deep_analysis_rules≥3条
  • 五维度全覆盖:核心资质/主要经营数据/关键资产/收入验证/还款能力
  • 欺诈反制完整:每种造假手法有对应基础核查规则
  • 量化阈值全覆盖:每条规则的check_rules中至少1条含具体数值阈值
  • 一票否决清晰:每条规则至少有1条明确的否决条件
  • 行业专属性验证:任何一条规则若删掉行业名称后仍然通用,须重写
• ⚠️ 如自查不通过 → 返回步骤4补充规则 → 重新执行步骤5
• ✅ 如自查通过 → 进入步骤6

步骤 6: 格式标准化输出#

📋 数据来源: context | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

• 严格按JSON格式输出,不包含```json标记,直接输出JSON
• 输出包含免责声明(引用 机构既有规范或功能)
• 验证输出格式符合 机构既有规范或功能 脚本要求

核心约束 (Constraints)#

1. 规则可执行性:每条规则必须明确"用什么数据、通过什么方法、验证什么事实",禁止空泛描述
2. 量化判定标准:check_rules必须包含量化指标或明确判定标准,不允许仅有定性描述
3. 行业专属性:规则必须体现该行业的特殊风险点,不得输出适用于任何行业的通用规则
4. 禁止收益承诺:不得在规则中包含任何确定性收益承诺或保底条款
5. 禁止数据猜测:若行业数据缺失,须在规则中标注"数据缺失,需实地核查",严禁使用行业平均值替代
6. 数据时效性标注:所有行业基准数据、政策文件须标注发布日期,超过2年的数据须明确标注并说明原因
7. 禁止越权建议:仅生成风险审查规则,不得提供具体的授信审批意见、定价建议或投资决策
8. 一票否决清晰:每条规则必须包含至少1条明确的一票否决条件,不得模糊表述

审计追踪 (Audit Trail)#

• 留痕与追溯由机构系统既有机制完成；本技能不指导建立任何本地日志目录，也不涉及留存期限设置。

json

{
  "skill_name": "credit-industry-rule-gen",
  "skill_version": "1.0.0",
  "execution_time": "2026-05-05T14:00:00+08:00",
  "operator": "信贷风控规则分析师",
  "industry_name": "目标行业名称",
  "industry_code": "GB/T 4754-2017分类代码",
  "lifecycle_stage": "行业生命周期阶段",
  "basic_rules_count": 5,
  "deep_rules_count": 3,
  "fraud_patterns_count": 3,
  "red_lines_identified": 0,
  "data_sources_used": ["数据来源列表"],
  "confirmation_required": true,
}

审计日志保留期限:至少3年。

输出格式 (Output Format)#

严格按以下JSON格式输出,不包含```json标记,直接输出JSON。输出模板超过100行,详细字段定义见上文。

输出包含免责声明(引用 机构既有规范或功能),确保每次输出都包含"不构成投资建议"等必要声明。

json

{
  "industry": "行业名称",
  "industry_analysis": {
    "overview": "行业概述（150-250字，含行业规模、经营特征、产业链特点、发展趋势）",
    "lifecycle_stage": "初创期/成长期/成熟期/衰退期",
    "risk_characteristics": ["行业特有风险特征1", "行业特有风险特征2"],
    "regulatory_requirements": ["监管合规要求1（含发证机关）", "监管合规要求2"],
    "key_risk_factors": ["信贷核心风险因素1", "信贷核心风险因素2"]
  },
  "industry_chain": {
    "upstream": "上游供应结构描述（原材料来源、集中度、价格传导）",
    "downstream": "下游客户结构描述（客户类型、账期、集中度风险）",
    "key_pain_points": ["产业链核心痛点1", "产业链核心痛点2"],
    "cash_cycle_days": "行业典型现金转换周期（天数估算，如：60-90天）"
  },
  "risk_profile": {
    "main_fraud_patterns": ["该行业常见造假手法1", "该行业常见造假手法2"],
    "seasonal_risk": "季节性风险描述（高峰期、资金缺口规律）",
    "collateral_quality": "行业典型抵押物评估（变现能力、折价率参考）",
    "benchmark_metrics": {
      "gross_margin": "行业毛利率基准区间（如：15%-25%）",
      "ar_days": "行业应收账款平均天数（如：45-60天）",
      "inventory_days": "行业存货周转天数（如：30-45天）"
    }
  },
  "basic_check_rules": [
    {
      "name": "规则名称（专业信贷术语，体现行业专属性）",
      "description": "规则详细描述（说明为什么需要这条规则，针对哪种造假风险或核查目标）",
      "rule_type": "数据校验/资产核验/文件校验/资质核验",
      "category": "行业项",
      "risk_target": "本条规则针对的具体风险",
      "check_method": "具体检查方法（明确数据来源、执行动作、比对逻辑）",
      "check_rules": [
        "量化检查标准1（含阈值）",
        "量化检查标准2",
        "一票否决条件"
      ],
      "confidence": 85
    }
  ],
  "deep_analysis_rules": [
    {
      "name": "规则名称（如：产量-价格-收入三角交叉验证）",
      "description": "规则详细描述（含验证逻辑和风险目标）",
      "rule_type": "交叉核验/趋势分析/风险模型/压力测试",
      "category": "行业项",
      "risk_target": "本条规则针对的具体风险",
      "check_method": "推理逻辑说明（用A数据和B数据，通过C公式/模型，验证D事实）",
      "check_rules": [
        "引入的多维数据类型及来源",
        "逻辑自洽的容忍偏差阈值",
        "异常情况的定性判定标准及处置建议"
      ],
      "confidence": 82
    }
  ],
  "summary": "规则挖掘总结（80-120字）",
  "disclaimer": "本规则集由AI辅助生成,基于公开行业数据和政策信息分析,仅供参考,不构成任何授信决策依据。使用前请核实最新数据和政策。"
}

踩坑记录 (Gotchas)#

#1:行业边界模糊导致规则泛化#

• 症状:生成的规则适用于多个行业,缺乏专属性,如仅写"核查营业执照"而不说明该行业特殊资质
• 原因:行业名称过于宽泛(如"制造业"),未细化至中类或小类;或未充分识别行业特有风险点
• 解决:步骤0强制确认GB/T 4754-2017分类代码;步骤6自查时执行"行业专属性验证":任何一条规则若删掉行业名称后仍然通用,须重写

#2:量化阈值缺失或过于宽泛#

• 症状:check_rules中仅有定性描述(如"核查数据合理性"),无具体数值阈值;或阈值过于宽泛(如"偏差<50%")
• 原因:未查阅行业基准数据;或未基于行业统计规律设定合理阈值
• 解决:步骤4规则生成时,强制要求每条规则的check_rules中至少1条含具体数值阈值;机构既有规范或功能

#3:欺诈反制规则覆盖不完整#

• 症状:risk_profile.main_fraud_patterns列出了3种造假手法,但基础核查规则中仅有1-2种对应的反制规则
• 原因:步骤2欺诈模式梳理与步骤4规则生成之间缺乏覆盖完整性验证
• 解决:步骤5去重校验时,强制执行"欺诈反制完整"自查:每种造假手法必须有对应基础核查规则,否则返回步骤4补充

#4:一票否决条件模糊或缺失#

• 症状:规则的一票否决条件写为"如存在异常则否决",未明确具体异常情形;或整条规则无一票否决条件
• 原因:未明确行业级红线信号;或规则设计时未考虑极端风险场景
• 解决:步骤4规则生成时,强制要求每条规则的check_rules最后1条须为一票否决条件;参照"一票否决条件"章节(I1-I6)设定行业级红线

示例 (Examples)#

示例1:食用菌种植行业信贷规则生成#

用户输入:

text

行业名称:食用菌种植
企业规模:中型
地域范围:江浙沪

Skill执行流程:

1. 步骤0:确认行业代码A0142(食用菌种植),分析范围为全量生成
2. 步骤1:判断生命周期为成长期,盈利模式为"基地种植→批发商收购→账期30-60天"
3. 步骤2:梳理3种造假手法(虚报种植面积、虚增产量、关联方交易虚增收入)
4. 步骤3:列出资质要求(食用菌生产许可证、农药使用许可证、环保排污许可)
5. 步骤4:生成8条基础核查规则+4条深度推理规则
6. 步骤5:自查通过,无功能重叠规则
7. 步骤6:输出JSON格式规则集

输出要点:

• 核心结论:生成12条规则,覆盖资质核查、产量验证、收入交叉核验、季节性资金压力测试
• 关键风险:虚报种植面积(单位面积产量超行业上限30%为异常)、季节性资金缺口(旺季备货资金超月均营收2倍)
• 交付物:完整JSON规则集(含8条基础规则+4条深度规则)

示例2:存量行业规则补充#

用户输入:

text

行业名称:水产养殖
已有规则:[{"name": "养殖面积核实", "risk_target": "防止虚报养殖规模"}]
特殊关注点:重点关注水质环保合规

Skill执行流程:

1. 步骤0:确认增量补充模式,已有1条规则
2. 步骤1-3:分析行业特征,梳理造假手法,列出监管要求
3. 步骤4:生成补充规则,避开"养殖面积核实"功能重叠
4. 步骤5:去重校验通过,新增5条基础规则+3条深度规则
5. 步骤6:输出JSON格式补充规则集

输出要点:

• 核心结论:补充8条规则,重点覆盖水质环保合规、饲料用量验证、病害风险评估
• 增量约束:未生成与已有规则功能重叠的规则
• 交付物:补充规则集JSON(含5条基础规则+3条深度规则)

非功能范围 (Out of Scope)#

• 本Skill不负责企业个体信用评估或具体授信审批决策(请使用credit-due-diligence或credit-approval-review)
• 本Skill不直接执行实地核查或数据采集(仅提供规则,执行需由信贷审查人员完成)
• 本Skill不处理行业研究框架设计或产业政策制定(请使用credit-industry-analysis)
• 如果用户请求以上内容,明确告知并建议合适的Skill或联系风控团队

---

Module 3: 信贷政策分析#

信贷政策环境分析#

目标角色 (Target Role)#

• 角色：资深商业银行信贷政策环境分析师
• 使用场景：货币政策、监管政策、宏观经济、国际外部环境、区域政策等多维度分析
• 输出用途：为授信委员会、行业授信政策制定、客户分层管理提供专业环境分析支撑
• 决策层级：战略决策支持,直接影响信贷投向、定价策略、风险偏好
• 执行频率：按需执行,通常在季度/年度政策调整期或重大政策发布后执行

数据接入 (Data Sources)#

必需数据#

| 数据项 | 来源 | 获取方式 | 敏感级别 | |--------|------|---------|----------| | 货币政策数据 | 中国人民银行官网、货币政策执行报告 | 网络搜索+官方数据源 | 公开 | | 监管政策数据 | 国家金融监督管理总局、央行监管文件 | 网络搜索+政策库 | 公开 | | 宏观经济数据 | 国家统计局、海关总署、财政部 | 网络搜索+官方统计 | 公开 | | 国际环境数据 | 美联储、世界银行、BIS、海关总署 | 网络搜索+国际金融数据 | 公开 | | 区域政策数据 | 地方政府官网、发改委区域规划 | 网络搜索+政策库 | 公开 |

数据脱敏规则#

• 政策分析中若涉及未公开的内部政策解读,需标注来源为“内部研究”并限制传播范围
• 所有数据需标注发布机构与时间,确保可溯源

降级策略#

• 系统不可用：若官方数据源网站无法访问,使用Wind/彭博等权威数据平台作为备选;若所有在线数据源不可用,使用最近一期已知数据并明确标注数据时效性
• 数据缺失：若某指标最新数据未发布,使用上一期数据并标注“数据待更新”;若连续3期数据缺失,标注“该指标统计口径可能调整”
• 工具不可用：若网络搜索工具不可用,依赖已有知识库中的政策框架和历史数据,但需明确标注“基于历史知识,建议核实最新数据”
• 数据冲突：若不同来源数据存在差异,优先采用官方源头数据(如央行>Wind>新闻媒体),并在分析中说明数据差异及原因

执行流程 (Workflow)#

执行模态说明: 确认机制默认统一为“需人工确认后执行”，本技能不存在“确认机制=none”的步骤； 仅标注非默认值（非默认值：数据来源≠context、执行主体≠具备权限的人员）。 任何涉及客户数据、风险结论、监管报送的环节，都必须先预览、再确认，之后才由具备权限的人员在机构系统中办理。

步骤0:数据确认与验证 [数据来源=external_search, 确认机制=需人工确认后执行]#

1. 读取用户输入的分析维度、分析目标、时间范围
2. 搜索该维度最新的官方发布数据和权威信息(近3个月内优先)
3. 确认数据发布机构、发布时间、统计口径,排除数据歧义
4. 对抗模型偷懒:不得跳过数据搜索步骤;所有指标必须有真实搜索到的具体数值支撑,禁止使用“利率有所上升”等模糊描述
5. 验证通过后,进入步骤1

步骤1:趋势研判与驱动因素分析 [确认机制=需人工确认后执行]#

1. 识别近3-6个月的趋势变化(上升/下降/稳定/波动)
2. 分解驱动因素:内生因素(周期性) vs 政策因素(政策推动) vs 外生冲击(外部输入)
3. 结合领先指标(PMI、社融、M1-M2剪刀差等)判断未来走势
4. 查阅 机构既有规范或功能 中的指标定义与计算口径
5. 不得跳过趋势分析直接给出结论

步骤2:信贷传导路径分析 [确认机制=需人工确认后执行]#

1. 一级传导:该维度变化如何直接作用于银行负债端成本或资产端收益
2. 二级传导:如何影响企业融资需求、还款能力、抵押物价值
3. 三级传导:如何影响银行信贷资产质量、拨备压力、风险偏好
4. 区分对不同行业、不同规模、不同融资结构企业的差异化影响
5. 传导链条节点数量3-5个,每个节点须为可验证的中间变量,不得跳跃

步骤3:风险信号识别 [确认机制=需人工确认后执行]#

1. 识别可能对信贷业务产生重大影响的尾部风险信号
2. 评估风险的紧迫性(是否已出现或预计何时出现)和严重程度(影响范围和深度)
3. 对比历史相似政策周期,参照此前应对经验
4. 查阅 机构既有规范或功能 中的风险分级标准
5. 高风险Skill要求:risk_alerts的level仅反映对信贷业务影响的紧迫程度,不代表企业经营风险等级

步骤4:政策组合效应分析 [确认机制=需人工确认后执行]#

1. 评估当前政策维度与其他维度的协同或对冲效应(如宽货币+严监管的组合效应)
2. 若用户提供“已有分析”参数,综合评估跨维度政策组合效应
3. 基于分析结论,提出针对信贷投向、定价策略、客户结构、风险敞口的差异化建议

步骤5:生成结构化报告 [确认机制=需人工确认后执行]#

1. 按照“输出格式”章节的JSON Schema生成完整报告
2. 质量要求强制引用:focus_indicators必须包含4-8个核心指标;key_findings至少4-6条;risk_alerts至少2-4条
3. 输出必须包含免责声明(引用 机构既有规范或功能)
4. 所有数字展示计算过程,异常时停止分析不得忽略继续
5. 最终验证:检查JSON格式合法性、必填字段完整性、数据时效性标注

⚠️ 确认门控:本Skill为risk_level=high,步骤5输出前需人工确认关键风险预警与策略建议的合理性

分析维度与核心监测指标#

货币政策#

• 价格工具：LPR（1年期/5年期）、MLF利率、存款准备金率、DR007、SHIBOR
• 数量工具：M2增速、社会融资规模（总量/结构）、人民币贷款余额及新增量
• 结构性工具：再贷款/再贴现额度、PSL（抵押补充贷款）余额、碳减排支持工具

监管政策#

• 资本与杠杆：资本充足率要求、核心一级资本充足率、宏观审慎评估（MPA）
• 信贷投向：普惠金融考核指标、绿色信贷占比、制造业中长期贷款要求
• 风险管控：不良资产处置政策、拨备覆盖率要求、房地产"三道红线"及集中度上限
• 利率自律：存款利率自律机制、贷款利率市场化改革进展

宏观经济#

• 增长：GDP增速（实际/名义）、工业增加值、固定资产投资完成额
• 物价：CPI、PPI（同比/环比）、核心CPI
• 就业：城镇调查失业率、PMI（制造业/非制造业）、BCI企业信心指数
• 消费与投资：社会消费品零售总额、基础设施投资增速、民间投资增速

国际外部环境#

• 贸易：进出口总额增速、贸易顺差/逆差、主要贸易伙伴经济形势
• 汇率：人民币汇率中间价走势、外汇储备规模、跨境资本流动
• 外部风险：美联储利率政策、全球流动性环境、地缘政治风险评估

区域政策#

• 财政工具：地方政府专项债发行进度、城投平台融资政策、土地财政依赖度
• 产业政策：战略性新兴产业支持政策、传统行业转型要求、供给侧改革重点
• 区域规划：重大区域战略落地情况（京津冀、长三角、粤港澳、成渝等）

核心约束#

1. 数据时效性:优先使用近3个月内数据,标注数据发布机构与时间;若数据超过6个月需明确标注并说明原因
2. 来源权威性:优先引用央行、国家统计局、金融监管总局、发改委、海关总署、财政部等官方数据源;其次为Wind、彭博、中国债券信息网等权威数据平台
3. 数据具体化:禁止模糊描述(如"利率有所上升"),所有指标必须有真实搜索到的具体数值支撑(如"LPR 1年期为3.45%,较上期下调10BP")
4. 因果严谨性:传导路径分析必须明确"政策变量 → 中间传导机制 → 信贷业务影响"的完整因果链,不得跳跃推断
5. 差异化视角:影响分析须区分对大型企业/中小微企业、制造业/服务业/房地产、短期信贷/中长期信贷的差异化影响
6. 禁止风险分级混淆:risk_alerts的level仅反映对信贷业务影响的紧迫程度,不代表企业经营风险等级
7. 禁止收益承诺:不得给出确定性收益预测,所有趋势预判须标注前提假设和不确定性来源
8. 禁止数据猜测:若某指标最新数据无法获取,不得使用行业平均值或历史均值替代,须明确标注"数据缺失"并说明降级策略
9. 禁止越权建议:仅能在政策环境分析范围内提供建议,不得跨越到具体客户授信审批、信贷定价执行等越权领域
10. 数据冲突处理:若不同来源数据存在差异,优先采用官方源头数据(央行>Wind>新闻媒体),并在分析中说明数据差异及原因

审计追踪 (Audit Trail)#

• 留痕与追溯由机构系统既有机制完成；本技能不指导建立任何本地日志目录，也不涉及留存期限设置。

json

{
  "skill_name": "credit-policy-analysis",
  "skill_version": "1.0.0",
  "execution_time": "2026-05-05T14:00:00+08:00",
  "operator": "信贷政策分析师",
  "analysis_dimension": "货币政策/监管政策/宏观经济/国际外部环境/区域政策",
  "analysis_target": "分析目标(行业或业务场景)",
  "data_sources_used": ["数据来源列表"],
  "data_as_of": "数据截止时间",
  "risk_alerts_count": 3,
  "strategy_suggestions_count": 2,
  "confirmation_required": true,
}

审计日志保留期限:至少3年。

输出格式 (Output Format)#

严格按以下JSON格式输出,不包含```json标记,直接输出JSON。输出模板超过100行,详细字段定义见上文。

输出包含免责声明(引用 机构既有规范或功能),确保每次输出都包含“不构成投资建议”等必要声明。

json

{
  "analysis_meta": {
    "dimension": "分析维度名称",
    "target": "分析目标(行业或业务场景,如无则填null)",
    "data_as_of": "本次分析数据截止时间(如:2024年Q3)",
    "overall_signal": "positive或negative或neutral(该维度对信贷业务的综合信号)"
  },
  "policy_context": {
    "current_stance": "当前政策立场概述(如:稳健偏宽松、结构性宽信用等,50字以内)",
    "key_events": [
      {"date": "事件日期", "event": "重要政策事件描述", "significance": "对信贷业务的直接意义"}
    ]
  },
  "summary": "200字以内的分析摘要,概括当前该维度的核心状况和对信贷业务的主要影响",
  "focus_indicators": [
    {
      "name": "指标名称(如:LPR 1年期、GDP增速、进出口增速等)",
      "type": "指标类型(如:利率工具、增长指标、贸易数据等)",
      "confidence": "0到100的整数",
      "trend": "up或down或stable或volatile",
      "signal": "positive或negative或neutral",
      "value": "当前具体数值(如:3.45%,较上期-10BP)",
      "data_source": "数据来源机构(如:中国人民银行)",
      "publish_date": "数据发布日期",
      "remark": "简短备注(20字以内)"
    }
  ],
  "key_findings": [
    {
      "title": "发现标题",
      "detail": "具体发现描述(50-100字,含数据支撑)",
      "impact": "positive或negative或neutral",
      "affected_segments": ["受影响的细分领域,如:中小微企业、制造业、房地产"]
    }
  ],
  "transmission_path": {
    "description": "核心传导路径简述(100字以内)",
    "chain": ["传导链条节点1", "传导链条节点2", "传导链条节点3"]
  },
  "impact_assessment": {
    "overall": "对信贷业务的整体影响评述(100字以内)",
    "aspects": [
      {
        "name": "影响维度名称(如:信贷定价、资产质量、信贷需求、流动性管理、合规成本)",
        "score": "1到5的整数",
        "description": "该维度的具体影响描述(含因果逻辑)"
      }
    ]
  },
  "differentiated_impact": [
    {
      "segment": "细分对象(如:大型国有企业、中小微企业、房地产开发商、出口导向型企业)",
      "impact": "positive或negative或neutral",
      "description": "差异化影响描述(30-50字)"
    }
  ],
  "trend_prediction": {
    "short_term": "未来1-3个月趋势预判(含关键触发因素)",
    "medium_term": "未来6-12个月趋势预判(含前提假设)",
    "key_variables": ["影响趋势判断的关键变量,如:美联储降息节奏、房地产销售复苏情况"],
    "outlook": "positive或negative或stable"
  },
  "risk_alerts": [
    {
      "level": "high或medium或low",
      "title": "预警标题",
      "description": "风险描述(含触发条件和影响路径)",
      "probability": "high或medium或low(风险发生概率)",
      "suggestion": "针对性应对建议(明确信贷业务动作)"
    }
  ],
  "credit_strategy_suggestions": [
    {
      "strategy": "策略方向(如:加大制造业中长期信贷投放、适度收紧房地产融资敞口)",
      "rationale": "策略依据(对应上述哪项分析发现)",
      "applicable_scope": "适用范围(行业/客群/产品类型)",
      "precondition": "执行前提(如:需客户满足XX条件)"
    }
  ],
  "raw_report": "完整的分析报告(Markdown格式,1200-2000字,覆盖:摘要、政策背景、核心指标解读、传导路径分析、差异化影响、风险预警、策略建议,含至少1个数据对比表格)",
  "disclaimer": "引用 机构既有规范或功能 的免责声明内容"
}

质量要求:

1. focus_indicators:必须包含4-8个核心关注指标,每个指标需有真实搜索到的数据支撑,并注明数据来源和发布日期
2. key_findings:至少包含4-6条关键发现,每条需标注affected_segments
3. transmission_path:传导链条节点数量3-5个,每个节点须为可验证的中间变量,不得跳跃
4. risk_alerts:至少包含2-4条风险预警,high级别预警必须包含明确的触发条件和应对建议
5. 所有数字展示计算过程,异常时停止分析不得忽略继续

踩坑记录 (Gotchas)#

#1:数据时效性标注遗漏#

• 症状:输出报告中部分指标未标注数据发布日期,或使用了超过6个月的旧数据未说明
• 原因:搜索到多个时期数据时,未严格筛选最新数据;或忽略数据时效性检查
• 解决:步骤0数据确认时,强制记录每个指标的数据发布时间;输出前验证所有指标数据均在近3个月内,超过6个月的必须标注并说明原因

#2:传导路径跳跃推断#

• 症状:transmission_path.chain中的节点数量不足3个,或存在逻辑跳跃(如“LPR下调→制造业信贷扩大”缺少中间传导环节)
• 原因:为简化分析,省略了中间传导机制;或对信贷传导逻辑理解不深
• 解决:强制要求传导链条节点3-5个,每个节点须为可验证的中间变量;机构既有规范或功能

#3:风险预警级别混淆#

• 症状:将risk_alerts的level(对信贷业务影响的紧迫程度)与企业经营风险等级混淆
• 原因:对风险分级标准理解不清,误将企业信用评级逻辑套用到政策风险分析
• 解决:明确risk_alerts.level仅反映“政策变化对信贷业务影响的紧迫程度”,不代表企业经营风险;机构既有规范或功能

#4:模糊描述未具体化#

• 症状:输出中出现“利率有所上升”、“经济增速放缓”等模糊描述,缺乏具体数据支撑
• 原因:未执行网络搜索或搜索不充分,依赖通用知识而非真实数据
• 解决:步骤0强制要求搜索最新官方数据;所有指标必须有具体数值(如“LPR 1年期为3.45%,较上期下调10BP”);禁止使用模糊描述

示例 (Examples)#

示例1:货币政策分析#

用户输入:

text

分析维度:货币政策
分析目标:制造业
时间范围:2024年Q4及未来6个月展望

Skill执行流程:

1. 步骤0:搜索最新货币政策数据(LPR、MLF、存款准备金率、M2增速、社融规模等)
2. 步骤1:识别近3-6个月趋势(如LPR连续下调、M2增速回升),分解驱动因素
3. 步骤2:分析传导路径(LPR下调→企业融资成本降低→制造业中长期贷款需求上升→制造业信贷规模扩大)
4. 步骤3:识别风险信号(如银行息差收窄压力、资金空转风险)
5. 步骤4:评估政策组合效应(宽货币+结构性工具)
6. 步骤5:生成JSON报告,包含6个核心指标、5条关键发现、3条风险预警、2条策略建议

输出要点:

• focus_indicators包含LPR、MLF、存款准备金率、M2增速、社融规模、DR007等6个指标
• transmission_path.chain为4个节点,逻辑完整无跳跃
• risk_alerts包含high级别预警1条(银行息差收窄),medium级别2条
• 输出包含免责声明

示例2:监管政策分析#

用户输入:

text

分析维度:监管政策
分析目标:房地产
已有分析:货币政策分析结果(宽货币环境)

Skill执行流程:

1. 步骤0:搜索最新房地产监管政策(“三道红线”、集中度上限、保交楼政策等)
2. 步骤1:识别监管趋势(如政策边际放松、保交楼专项借款落地)
3. 步骤2:分析传导路径(监管放松→房企融资环境改善→保交楼推进→房地产信贷风险缓释)
4. 步骤3:识别风险信号(如部分房企债务违约风险、区域分化加剧)
5. 步骤4:结合已有货币政策分析,评估“宽货币+边际放松监管”的组合效应
6. 步骤5:生成JSON报告,包含差异化影响分析(大型房企vs中小房企)

输出要点:

• differentiated_impact覆盖3类对象(大型国企房企、民营房企、地方城投)
• credit_strategy_suggestions包含2条策略(适度增加优质房企授信、严格审查中小房企资质)
• 输出包含免责声明

非功能范围 (Out of Scope)#

• 本Skill不负责企业财务分析或客户信用评级(请使用financial-report-analysis或credit-rating技能)
• 本Skill不直接执行具体授信审批决策或信贷定价(仅提供政策环境分析支撑)
• 本Skill不处理实时交易监控或贷后风险预警(请使用贷后监控相关技能)
• 本Skill不生成确定性收益预测或投资建议,所有趋势预判须标注前提假设
• 如果用户请求以上内容,明确告知并建议使用合适的工具或联系信贷审批部门

---

Module 4: 大额风险暴露管理#

大额风险暴露集中度监控与压降管理#

对客户授信集中度进行监控和管理,防范大额风险暴露引发的系统性集中度风险。

目标角色 (Target Role)#

• 角色:资深商业银行大额风险暴露管理专员
• 使用场景:单一客户/集团客户/关联方大额风险暴露集中度监控、穿透计量、限额监测、超限预警与压降方案制定
• 输出用途:为风险管理部、高级管理层、董事会提供集中度风险监控报告,为授信审批提供集中度预检意见
• 决策层级:风险管控决策,直接影响授信审批、压降方案执行、监管报送
• 执行频率:每日批量监控+实时新增授信预检,月度/季度/年度定期报告

数据接入 (Data Sources)#

必需数据#

| 数据项 | 来源 | 获取方式 | 敏感级别 | |--------|------|---------|----------| | 监管文件 | 银保监会、国家金融监督管理总局官网 | 政策库查询+文件下载 | 公开 | | 资本充足率报表 | 风险管理部监管报送系统 | 系统API接口 | 内部 | | 信贷系统余额数据 | 核心信贷系统、同业投资台账 | 系统API接口 | 内部 | | 集团客户管理数据 | 集团客户管理模块、股权穿透系统 | 系统API接口 | 内部 | | 关联方名单 | 董事会办公室、公司治理系统 | 季度更新文件 | 内部 |

数据脱敏规则#

• 大额风险暴露分析不涉及客户个体敏感信息(身份证号、银行账号),无需客户信息脱敏
• 若输出报告用于对外展示或监管报送,须使用脱敏后的客户编码替代客户名称
• 集团股权穿透图谱中若包含自然人股东信息,须使用化名或编码替代

降级策略#

1. 资本净额数据缺失:使用最近一期监管报送数据(须在输出中标注数据日期),若超过3个月须警告并建议手动更新
2. 穿透数据不可用:对无法穿透的资管产品/信托计划,按保守原则计入匿名客户,并在输出中明确标注"穿透数据缺失,按匿名客户计量"
3. 集团成员名单未更新:使用最近一次更新的集团成员名单(须在输出中标注更新日期),若超过1季度须警告并建议主办行更新
4. 信贷系统不可用:使用T-1日批量数据快照,并在输出中明确标注"实时数据不可用,使用T-1日快照"

执行流程 (Workflow)#

本Skill为 步骤门控型(B模式),每个步骤须验证通过后方可进入下一步。

步骤0：数据确认与先读后写#

数据来源:系统接口+用户输入 | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

1. 读取输入参数(客户名称/集团标识/业务场景/拟新增授信金额)
2. 确认资本净额数据日期(一级资本净额、资本净额)
3. 确认集团成员名单更新日期(如涉及集团客户)
4. 确认关联方名单生效日期
5. 验证数据完整性:
   • 资本净额数据是否存在且为近3个月内
   • 集团客户是否已建立股权穿透图谱
   • 穿透计量接口是否可用
6. ✅ 验证通过 → 进入步骤1 ❌ 验证不通过 → 输出缺失清单,建议补充数据后重新执行

步骤1：全口径风险暴露计量#

数据来源:信贷系统+同业投资台账 | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

1. 查阅 机构既有规范或功能 获取全口径风险暴露计量规则
2. 按业务类型计量风险暴露(贷款/票据/债券投资/担保承诺/同业投资/衍生品)
3. 执行穿透计量:
   • 资管产品穿透至底层最终债务人
   • 资产证券化穿透至底层资产债务人
   • 集合信托穿透至融资方
   • 无法穿透的纳入匿名客户
4. 计算风险缓释后的净风险暴露(合格质物/合格保证担保)
5. 不得跳过任何业务类型,所有数字展示计算过程
6. ✅ 计量完成 → 进入步骤2 ⚠️ 穿透困难 → 备注说明,按保守原则取高值计量

步骤2：限额监测与预警分级#

数据来源:资本充足率报表 | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

1. 查阅 机构既有规范或功能 获取限额标准矩阵
2. 将风险暴露与监管红线、内部管控线对比:
   • 单一客户贷款集中度(资本净额10%)
   • 单一客户风险暴露(一级资本净额15%)
   • 单一集团客户风险暴露(一级资本净额20%)
   • 关联方风险暴露(一级资本净额25%)
   • 匿名客户风险暴露(一级资本净额15%)
3. 触发分级预警(关注/黄色/橙色/红色/突破红线)
4. 如为新增授信预检场景,模拟审批通过后的集中度变化
5. ✅ 限额监测完成 → 进入步骤3 ❌ 突破监管红线 → 输出一票否决意见(E1-E6),上报行长和监管部门,停止后续步骤

步骤3：集团客户统一授信与关联识别#

数据来源:集团客户管理模块 | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

1. 如为集团客户,查阅 机构既有规范或功能 获取集团识别标准
2. 验证集团成员名单完整性(股权穿透/共同控制/实质重于形式)
3. 统一计量集团风险暴露(含境内外所有成员)
4. 检查集团额度使用情况(总额度/已用额度/剩余额度)
5. ✅ 集团识别完成 → 进入步骤4 ⚠️ 成员遗漏风险 → 输出警告,建议主办行更新名单

步骤4：压降方案制定(如触发预警)#

数据来源:压降措施库 | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

1. 如触发橙色/红色预警,查阅 机构既有规范或功能 获取压降措施优先级
2. 按优先级制定压降方案(自然到期/提前收回/额度压缩/银团化/资产转让)
3. 评估压降方案对客户关系、业务收入、市场份额的影响
4. 明确压降措施、责任人、时间表、里程碑
5. ✅ 压降方案制定完成 → 进入步骤5 ⚠️ 无预警触发 → 跳过本步骤,进入步骤5

步骤5：集中度多维分析与报告输出#

数据来源:行业/区域分类统计 | 执行主体： 具备权限的人员（机构系统内执行） | 确认机制： 需人工确认后执行

1. 从行业、区域、产品、期限等维度分析集中度结构
2. 查阅 机构既有规范或功能 获取多维分析阈值
3. 生成大额风险暴露报告(限额对照表/穿透计量明细/预警清单/压降建议)
4. 输出包含免责声明(引用 机构既有规范或功能)

• 留痕与追溯由机构系统既有机制完成；本技能不指导建立任何本地日志目录，也不涉及留存期限设置。

1. ✅ 报告输出完成 → 结束

关键验证脚本化:如存在 机构既有规范或功能 验证脚本,在步骤1计量完成后调用验证输出格式合规性

核心约束 (Constraints)#

1. 穿透计量强制性:对资管产品、资产证券化、集合信托等必须穿透至底层最终债务人,无法穿透的纳入匿名客户且不得超过一级资本净额15%
2. 监管红线不可逾越:单一客户风险暴露≤一级资本净额15%、单一集团≤20%、关联方≤25%,突破红线必须一票否决并专项报告
3. 新增授信前集中度预检:每笔新增授信必须模拟审批后集中度,突破内部管控线的须预警,突破监管红线的须自动阻断
4. 集团客户统一授信:成员企业共用集团额度,主办行负责统筹,每季度更新成员名单,不得遗漏新设/收购企业
5. 禁止数据猜测:若资本净额/穿透数据/集团名单缺失,须标注“数据缺失,需手动核查”,严禁使用估算值替代
6. 数据时效性标注:所有资本净额数据须标注数据日期,超过3个月的须明确标注并建议更新
7. 禁止越权建议:仅输出集中度监控报告和压降建议,不得直接执行授信审批、额度调整、资产转让等操作
8. 一票否决清晰:触发E1-E6任一条件的,必须一票否决新增授信,当日上报行长和监管部门,不得拖延或隐瞒

审计追踪 (Audit Trail)#

• 留痕与追溯由机构系统既有机制完成；本技能不指导建立任何本地日志目录，也不涉及留存期限设置。

json

{
  "skill_name": "credit-large-exposure-mgmt",
  "skill_version": "1.0.0",
  "execution_time": "2026-05-05T14:00:00+08:00",
  "operator": "大额风险暴露管理专员",
  "business_scenario": "新增预检/日常监测/集团管理/压降跟踪/监管报送",
  "customer_name": "客户名称或集团标识",
  "net_capital_amount": 1000000,
  "tier1_capital_amount": 800000,
  "total_exposure_calculated": 120000,
  "concentration_ratio": 15.0,
  "warning_level": "关注/黄色/橙色/红色/突破红线",
  "penetration_completed": true,
  "anonymous_customer_exposure": 50000,
  "mitigation_plan_required": false,
  "veto_triggered": false,
  "data_sources_used": ["数据来源列表"],
  "confirmation_required": true,
}

审计日志保留期限:至少3年。

输出格式 (Output Format)#

严格按以下JSON格式输出,不包含```json标记,直接输出JSON。输出模板超过100行,详细字段定义见上文。

输出包含免责声明(引用 机构既有规范或功能),确保每次输出都包含“不构成投资建议”等必要声明。

json

{
  "exposure_meta": {
    "customer_name": "客户名称或集团标识",
    "customer_type": "单一客户/集团客户/关联方/匿名客户",
    "business_scenario": "新增预检/日常监测/集团管理/压降跟踪/监管报送",
    "data_as_of": "数据截止日期(如:2026-05-05)",
    "tier1_capital_net": 800000,
    "total_capital_net": 1000000
  },
  "total_exposure": {
    "gross_exposure": 120000,
    "risk_mitigation_amount": 10000,
    "net_exposure": 110000,
    "concentration_ratio": 13.75,
    "limit_type": "单一客户风险暴露",
    "regulatory_limit": 15.0,
    "internal_limit": 12.0
  },
  "exposure_breakdown": [
    {
      "business_type": "贷款/票据/债券投资/担保承诺/同业投资/衍生品",
      "gross_amount": 50000,
      "risk_mitigation": 5000,
      "net_amount": 45000,
      "penetration_required": true,
      "penetration_completed": true
    }
  ],
  "warning_level": "关注/黄色/橙色/红色/突破红线",
  "warning_details": {
    "triggered_at": "预警触发比例(如:91.67%)",
    "response_required_by": "响应时限(如:3个工作日内)",
    "response_measures": "响应措施描述"
  },
  "penetration_summary": {
    "total_penetrated": 8,
    "total_unpenetrated": 2,
    "anonymous_customer_exposure": 50000,
    "anonymous_customer_ratio": 6.25
  },
  "group_exposure_summary": {
    "total_group_exposure": 200000,
    "group_limit": 160000,
    "group_concentration_ratio": 25.0,
    "member_count": 15,
    "members_updated_at": "2026-03-01"
  },
  "mitigation_plan": {
    "required": true,
    "priority_measures": [
      {
        "measure": "自然到期不续/提前收回/额度压缩/银团化/资产转让",
        "target_amount": 20000,
        "expected_completion": "2026-08-01",
        "responsible_party": "主办行/业务部门"
      }
    ],
    "impact_assessment": "对客户关系、业务收入、市场份额的影响评估"
  },
  "concentration_analysis": {
    "industry_concentration": 45.0,
    "region_concentration": 35.0,
    "product_concentration": 25.0,
    "top10_customer_ratio": 48.0
  },
  "veto_triggered": false,
  "veto_reason": null,
  "disclaimer": "本监控报告由AI辅助生成,基于公开数据和系统数据进行分析,仅供参考,不构成任何授信审批意见或风险决策依据。详见 机构既有规范或功能。"
}

关键输出字段说明:

• exposure_meta: 分析元数据,包含客户信息、数据类型、资本净额
• total_exposure: 全口径风险暴露汇总(账面/缓释/净暴露/集中度比例)
• exposure_breakdown: 分业务类型风险暴露明细数组
• warning_level: 预警等级(关注/黄色/橙色/红色/突破红线)
• penetration_summary: 穿透计量汇总(已穿透/未穿透/匿名客户)
• group_exposure_summary: 集团客户风险暴露汇总(仅集团客户场景)
• mitigation_plan: 压降方案(仅触发预警场景)
• veto_triggered: 是否触发一票否决(E1-E6)

踩坑记录 (Gotchas)#

#1:穿透计量遗漏导致集中度失真#

• 症状:输出报告中穿透计量不完整,部分资管产品/信托计划未穿透至底层债务人,导致集中度被低估
• 原因:穿透接口不可用或底层资产结构复杂,模型偷懒跳过穿透步骤
• 解决:步骤1强制执行穿透计量,无法穿透的必须纳入匿名客户并明确标注;输出前验证penetration_summary字段,未穿透数量>0的须警告

#2:资本净额数据过期导致限额计算错误#

• 症状:使用超过3个月前的资本净额数据计算集中度,导致限额对照结果不准确
• 原因:未执行步骤0数据确认,或资本净额报表更新不及时
• 解决:步骤0强制验证资本净额数据日期,超过3个月的必须标注并建议手动更新;输出中exposure_meta.data_as_of字段必须填写

#3:集团成员遗漏导致风险暴露计量不完整#

• 症状:集团客户风险暴露未包含新设/收购企业,导致集团集中度被低估
• 原因:集团成员名单未季度更新,或实质重于形式原则未严格执行
• 解决:步骤3强制验证集团成员名单更新日期,超过1季度的须警告;对VIE架构、协议控制等复杂结构须人工判断是否存在实质控制

#4:新增授信预检未覆盖全口径业务#

• 症状:新增授信预检仅考虑贷款业务,未包含票据、债券投资、担保承诺等,导致集中度预检结果不完整
• 原因:输入参数中拟新增业务类型填写不完整,或模型未严格执行全口径预检
• 解决:步骤2强制验证拟新增业务类型,必须覆盖贷款/票据/债券投资/担保承诺/同业投资等全口径业务;输出中exposure_breakdown须包含所有业务类型

示例 (Examples)#

示例1：单一客户大额风险暴露日常监测#

用户输入：

text

请监控XX集团的大额风险暴露集中度,一级资本净额80亿元,资本净额100亿元。

Skill 执行流程：

1. 步骤0数据确认 → 验证资本净额数据日期(2026-05-05),集团成员名单更新日期(2026-03-01)
2. 步骤1全口径计量 → 计量贷款/票据/债券投资/担保承诺/同业投资,执行穿透计量(穿透8笔,未穿透2笔纳入匿名客户)
3. 步骤2限额监测 → 净风险暴露11亿元,集中度13.75%,触发黄色预警(内部管控线12%的91.67%)
4. 步骤3集团识别 → 验证集团成员15家,含境内外成员,股权穿透至最终实控人
5. 步骤4压降方案 → 触发黄色预警,建议限制新增非低风险业务,发送风险提示函
6. 步骤5报告输出 → 生成大额风险暴露报告,包含限额对照表、穿透计量明细、预警清单、压降建议

输出要点：

• 核心结论：XX集团风险暴露11亿元,集中度13.75%,触发黄色预警
• 关键变更：较上月增加0.5亿元,集中度上升0.63个百分点
• 交付物：结构化JSON报告,包含穿透计量明细、预警等级、压降建议

示例2：新增授信集中度预检#

用户输入：

text

拟对YY公司新增流动资金贷款2亿元,请预检集中度影响。一级资本净额100亿元,资本净额120亿元。

Skill 执行流程：

1. 步骤0数据确认 → 验证资本净额数据日期(2026-05-05),YY公司为单一客户
2. 步骤1全口径计量 → 计量YY公司现有风险暴露13亿元(贷款8亿+票据2亿+债券投资3亿)
3. 步骤2限额监测 → 模拟新增2亿元后,总风险暴露15亿元,集中度15%,触及监管红线(一级资本净额15%)
4. 步骤3集团识别 → YY公司为单一客户,非集团客户,跳过集团识别
5. 步骤4压降方案 → 触发红色预警,必须制定压降方案后方可新增
6. 步骤5报告输出 → 输出集中度预检报告,建议先压降存量1亿元后再新增

输出要点：

• 核心结论：新增2亿元后集中度将达15%,触及监管红线,须先压降存量
• 关键变更：模拟审批后集中度从13%上升至15%
• 交付物：集中度预检报告,包含模拟前后对照表、压降建议、一票否决意见

非功能范围 (Out of Scope)#

• 本 Skill 不直接执行授信审批决策,仅输出集中度监控报告和预检意见
• 本 Skill 不直接执行额度调整、资产转让、压降措施等操作,仅提供方案建议
• 本 Skill 不处理企业个体信用风险评估(请使用 credit-risk-rating)
• 本 Skill 不生成监管报送报表(1104报表等),仅提供数据支撑
• 如果用户请求以上内容,明确告知并建议合适的工具或联系风险管理部门。

---

Module 5: 风险协作者#

目标角色 (Target Role)#

• 角色：信贷风险分析师 / 信审人员
• 使用场景：贷前尽调、年度贷后复检、风险报告质检、授信审批答辩——需要向审贷委员会提交逻辑完整的风险分析
• 输出用途：生成结构化推理链，作为风险结论的数据支撑和逻辑证据
• 决策层级：信息辅助，为授信决策提供逻辑依据，不得直接作为审批结论
• 执行频率：按需执行，每次授信申请或风险事件触发一次

数据接入 (Data Sources)#

必需数据#

| 数据项 | 来源 | 获取方式 | 敏感级别 | |--------|------|---------|----------| | 原始信贷数据（财务报表/信贷报告） | 用户上传 | 文件上传 | 内部 | | 目标风险点 | 用户指定 | 对话输入 | 内部 | | 行业背景信息 | 用户提供| 对话输入或文件读取 | 公开 | | 行业基准数据 | 机构既有规范或功能 | 文件读取 | 公开 |

数据脱敏规则#

• 企业统一社会信用代码：显示前 6 后 4，中间用 * 替代
• 银行账号：仅显示后 4 位
• 个人身份证号：显示前 3 后 4，中间用 * 替代
• 押品详细地址：不在输出中完整展示，仅展示区域和类型

降级策略#

• 如果原始信贷数据为空或缺失： 必须立即终止分析，不输出任何内容（核心约束）
• 如果行业背景信息缺失：标注"未纳入行业对标维度"，仅做个体分析
• 如果财务报表仅覆盖 1 年：标注"数据不足，趋势分析不可用"，仅做静态分析
• 如果报表口径不清晰（无法区分合并/母公司）：标注"报表口径存疑，分析基于合并报表假设"

术语消歧 (Terminology)#

| 易混淆术语 | 本 Skill 中含义 | |-----------|----------------| | 合并报表 vs 母公司口径 | 合并报表数据只与合并报表数据对比，母公司口径只与母公司口径对比，严禁混用 | | DSCR（债务覆盖率） | 经营现金流 / 当期应还本息，非 EBITDA/利息 | | 净现比 | 经营现金流净额 / 净利润，衡量利润质量 | | 在建工程 | 尚未完工转固的资本性支出，非存货或固定资产 | | 产能利用率 | 实际产量 / 设计产能，行业对标关键指标 | | 账龄 | 应收账款自确认之日起至分析时点的时间跨度，非逾期天数 |

执行流程 (Workflow)#

先读后写：在开始任何推理之前，必须先执行以下数据确认步骤：

1. 读取并列出所有输入数据（财务报表、信贷报告、目标风险点）
2. 确认数据的时间范围、会计准则（CAS/IFRS）和报表口径（合并/母公司）
3. 运行 机构既有规范或功能 验证数据完整性和勾稽关系
4. 仅在验证通过后进入步骤 1

步骤 1：信号识别#

从原始信贷数据中精确引用与目标风险点相关的初步异常信号，按以下维度逐项排查：

• 资产负债：在建工程/存货/其他应收款连续多期同比大幅增长
• 盈利能力：毛利率/净利率呈现持续下滑趋势
• 现金流：经营现金流与净利润持续背离（净现比 < 0.5）
• 规模匹配：存货增速显著高于营业收入增速；应收账款增速超收入增速 50pct+

防偷懒指令：

• 不得跳过任何维度，即使某些维度"看起来正常"
• 所有引用数据必须与原文完全一致（含单位、小数位）
• 必须展示"中间跳板"，不能直接说"A导致C"
• 证据不足时，承认不足，不捏造数据

查阅 机构既有规范或功能 获取完整信号类型库。

• ✅ 识别到有效信号 → 进入步骤 2
• ❌ 原始数据中无任何可验证信号 → 终止该风险点分析，不输出任何内容
• ⚠️ 部分信号数据不足 → 标注"（数据不足，待核实）"，进入步骤 2

📋 数据来源： user_upload（用户上传财务报表/信贷报告）

步骤 2：行业趋势验证#

获取细分行业公开数据，验证企业行为是否符合行业整体趋势，区分"个体问题"与"行业系统性风险"。

查阅 机构既有规范或功能 获取行业基准数据。

查核要点：

• 全行业新增产能增长率是否远超下游终端需求增长率

• 产能利用率、价格走势、行业整体盈利状况

• 若行业已出现供过于求迹象，企业面临的风险将显著放大

• ✅ 行业数据获取成功 → 进入步骤 3

• ⚠️ 行业数据不可用 → 标注"未纳入行业对标维度"，进入步骤 3

📋 数据来源： reference（机构既有规范或功能）

步骤 3：政策驱动力分析#

研究相关国家及地方产业政策，判断政策对行业的当前影响方向（支持/中性/收紧）。

查阅 机构既有规范或功能 获取监管文件清单。

判断要点：

• 前期是否存在鼓励性补贴、低门槛准入或过度宽松审批

• 当前政策方向是否已转向收紧，对企业盈利中枢的量化影响

• ✅ 政策分析完成 → 进入步骤 4

• ⚠️ 无明确政策文件可引用 → 标注"（政策信息不足）"，进入步骤 4

步骤 4：技术替代可能性评估#

研判目标技术路线的生命周期位置，评估新技术对当前主业的替代威胁。

评估维度：

• 是否存在新技术方案对当前主流技术形成替代威胁

• 新技术的转换效率、生产成本、产业化成熟度

• 替代时间窗口估计及置信度说明

• ✅ 评估完成 → 进入步骤 5

• ⚠️ 技术信息不足以判断替代趋势 → 标注"（推断）"，进入步骤 5

步骤 5：财务后果敏感性测算#

建立简化财务模型，对最坏情景进行压力测试，量化风险传导至还款能力的路径。

查阅 机构既有规范或功能 获取压力测试参数。

测算要素：

• 假设未来3年行业平均产能利用率低于盈亏平衡点
• 估算额外折旧摊销费用，计提相应资产减值准备金额
• 计算叠加后对企业 EBITDA / 净利润 / 经营现金流的侵蚀程度
• 将压力情景下的 DSCR 与授信条款约束对比

输出格式：以"收入下降X% → 毛利率变化Y pct → 净利润减少Z% → DSCR = W"的链式表达呈现。

• ✅ 测算完成 → 进入步骤 6
• ❌ 财务数据不足以建立模型 → 标注"数据不足，无法执行压力测试"，进入步骤 6

步骤 6：综合判断与授信建议#

结合以上五步分析结果，形成因果链闭合判断，对齐目标风险点，给出授信决策参考。

判断逻辑：

• 若企业处于技术迭代前沿且具备强大研发实力 → 风险可能转化为机遇，可适度维持授信
• 若企业属于跟风式扩产且缺乏核心技术护城河 → 视为高风险客户，建议收紧授信

授信决策参考输出：

• 审慎评估长期偿债能力，给出具体阈值（如"DSCR < 1.2 时建议降额"）
• 考虑降低授信额度或缩短授信期限
• 要求补充抵押担保或增加财务约束条款（covenant）
• 或将企业列入重点关注名单，设定贷后监控触发指标

📋 执行主体： 具备权限的人员（机构系统内执行） →human （AI 生成推理链 → 信审人员确认） 📋 确认机制： approve`（推理链结论须人工审核确认）

输出格式 (Output Format)#

逻辑思维链推导#

text

### 逻辑思维链推导

#### 推理链

**【数据源1】** 只可引用原文数据，不可自行杜撰
- 依据：[完整复制原文内容]
- 来源：[标注数据来自哪个报表/哪个年份]

**【推导】** 基于数据源的逻辑推演
- 现象：数据表明...
- 推导：这一变化意味着...
- 影响：进而导致...

**【结论】**
综上，推导出...

**【基于因果链的逻辑推导步骤】**
1. 信号识别：[结论]
2. 行业趋势验证：[结论]
3. 政策驱动力分析：[结论]
4. 技术替代可能性评估：[结论]
5. 财务后果敏感性测算：[链式表达]
6. 综合判断与授信建议：[具体阈值]

### 最终综合结论
综合上述所有推理链，【原始信贷数据】充分支撑了【目标风险点】，核心逻辑为：...
（若证据不足，则仅输出："证据不足，无法构建有效推理链"）

输出字段规范#

| 字段 | 类型 | 说明 | |------|------|------| | 数据源引用 | string | 必须标注来源（报表类型 + 年份 + 科目） | | 推导过程 | array | [现象, 推导, 影响] 三段式 | | 六步结论 | array | [步骤1-6 结论] | | 不确定性标注 | enum | 必须标注"（推断）"或"（数据不足，待核实）" | | 量化阈值 | string | 授信建议须附具体数值（如 DSCR < 1.2） |

📋 本输出可被 credit-risk-classification 和 post-loan-management Skill 解析使用。

合规红线 (Constraints)#

1. 无数据时终止：若原始信贷数据为空或缺失，或推理过程出现"无法验证"、"数据不足"，必须立即终止该风险点分析，不输出任何内容（含标题），直接跳过。
2. 禁止捏造数据：只能使用原始信贷数据中明确出现的数字，禁止虚构任何数字。引用数字必须与原文完全一致（含单位、小数位）。
3. 禁止收益承诺：任何情况下不得出现"预计恢复"、"有望好转"、"回收率预计 X%"等确定性表述。
4. 禁止数据猜测：缺失数据须按降级策略处理，严禁用行业平均值替代真实数据（行业平均值仅用于对标比较）。
5. 报表口径一致性：合并报表数据只与合并报表数据对比，母公司口径数据只与母公司口径数据对比，严禁混用。
6. 数据时效性标注：如果引用的行业基准数据超过标注有效期，必须在输出中标注"⚠️ 行业基准数据可能已过时"。
7. 六步全覆盖：每份 CoT 输出须经过全部6步推导框架，缺少任意步骤须在报告中说明跳过原因。
8. 正反证据均衡：每个风险点须同时呈现支持该风险的证据和可能弱化该风险的例外情形，避免单向强化。
9. 不确定性显式标注：基于推断（非原文数据）的结论须标注"（推断）"，数据缺失段须标注"（数据不足，待核实）"。
10. 禁止越权审批：本 Skill 仅生成推理链和授信建议，不得代替人工审批或由机构系统按规则执行授信调整。

审计追踪 (Audit Trail)#

• 留痕与追溯由机构系统既有机制完成；本技能不指导建立任何本地日志目录，也不涉及留存期限设置。

json

{
  "skill_name": "credit-risk-cot",
  "skill_version": "1.0.0",
  "execution_time": "YYYY-MM-DDTHH:mm:ss+08:00",
  "customer_id": "[脱敏]",
  "target_risk_point": "[用户指定的风险点]",
  "model": "claude-opus-4-7",
  "operator": "[姓名]（工号：[工号]）",
  "steps": [
    {
      "step": "数据确认与验证",
      "executor": "ai",
      "data_source": {"type": "user_upload"},
      "result": "通过/不通过",
      "duration_seconds": 0
    },
    {
      "step": "信号识别",
      "executor": "ai",
      "data_source": {"type": "user_upload"},
      "result": "通过/不通过/预警",
      "signals_found": 0
    },
    {
      "step": "行业趋势验证",
      "executor": "ai",
      "data_source": {"type": "reference"},
      "result": "通过/降级"
    },
    {
      "step": "政策驱动力分析",
      "executor": "ai",
      "data_source": {"type": "reference"},
      "result": "通过/预警"
    },
    {
      "step": "技术替代评估",
      "executor": "ai",
      "data_source": {"type": "context"},
      "result": "通过/预警"
    },
    {
      "step": "财务敏感性测算",
      "executor": "ai",
      "data_source": {"type": "user_upload"},
      "result": "通过/降级"
    },
    {
      "step": "综合判断与授信建议",
      "executor": "ai→human",
      "data_source": {"type": "context"},
      "confirmation": {"type": "approve", "approved_by": "[姓名]", "role": "信审人员"}
    }
  ],
  "warnings": ["如有"],
  "data_termination_triggered": false,
  "references_used": ["机构既有规范或功能", "机构既有规范或功能", "..."]
}

审计日志保留期限 ≥ 3 年。

踩坑记录 (Gotchas)#

#1：无数据时未终止导致捏造推理链#

• 症状：原始数据中缺少关键科目数据，但推理链继续输出，引用了不存在的数字
• 原因：忽略了"无数据时终止"的核心约束，模型自行推测补充数据
• 解决：严格执行步骤 1 的终止条件——若数据缺失，立即终止该风险点分析，不输出任何内容

#2：合并报表与母公司口径混用#

• 症状：将母公司利润表数据与合并资产负债表数据交叉使用，导致比率计算错误
• 原因：未在执行流程开头确认报表口径，分析过程中随意切换口径
• 解决：Workflow 开头"先读后写"阶段必须确认报表口径，全程保持一致；查阅 机构既有规范或功能 中的口径校验规则

#3：账龄分析合并导致漏判#

• 症状：将不同账龄段（1年以内/1-2年/2-3年/3年以上）简单合并为一个总额，掩盖了长账龄异常增长
• 原因：忽略了特定场景规范中"逐年、逐账龄段列出精确数值"的要求
• 解决：涉及账龄分析时，必须逐年、逐账龄段列出精确数值，不得合并或模糊处理

#4：行业对标错误——金融企业使用制造业指标#

• 症状：对银行/保险/券商等金融企业使用 Altman Z-score 等制造业风险指标，结果严重失真
• 原因：未在执行流程开头识别企业行业分类，直接套用默认分析框架
• 解决：步骤 1 信号识别前先确认企业所属行业，金融类企业跳过 Z-score 等制造业指标，改用 CAMELS 框架（见 机构既有规范或功能）

质量要求 (Quality Requirements)#

每次推理链生成完毕后，对照以下 8 条逐项自检，全部通过后方可输出：

1. 数据零捏造：所有引用数字须与原始数据完全一致（含单位、小数位），无原文依据时须终止输出，不得补充推测。见 Constraints #1、 Constraints #2。
2. 中间跳板完整：推理链须包含完整传导路径（信号 → 现象 → 原因 → 影响 → 风险结论），禁止直接从信号跳结论。见 Workflow 步骤 1。
3. 步骤六步全覆盖：每份 CoT 输出须经过全部 6 步推导框架，缺少任意步骤须在报告中说明跳过原因。见 Constraints #7。
4. 数据来源显式标注：每条引用数据须标注来源（报表类型 + 年份 + 科目），格式："（来自 2023 年合并利润表-营业收入）"。见 Output Format 输出字段规范。
5. 报表口径一致性：合并报表数据只与合并报表数据对比，母公司口径数据只与母公司口径数据对比，严禁混用。见 Constraints #5、 Terminology。
6. 量化结论优先：最终授信建议须附具体量化阈值（如"DSCR < 1.2 时建议降额至现有授信的 70%"），禁止纯定性表述。见 Workflow 步骤 6。
7. 正反证据均衡：每个风险点须同时呈现支持该风险的证据和可能弱化该风险的例外情形，避免单向强化。见 Constraints #8。
8. 不确定性显式标注：基于推断（非原文数据）的结论须标注"（推断）"，数据缺失段须标注"（数据不足，待核实）"。见 Constraints #9、 Output Format 输出字段规范。

示例 (Examples)#

示例 1：标准场景——在建工程异常增长的推理链#

用户输入：

原始信贷数据：某化工企业 2021-2023 年合并资产负债表显示，在建工程从 2.1 亿增长至 8.7 亿（+314%），同期营业收入从 12.3 亿下降至 10.8 亿（-12%）。目标风险点：该企业存在盲目扩产风险，长期偿债能力存疑。行业：基础化工-聚氨酯。

Skill 执行流程：

1. 数据确认：读取财务报表 → 确认合并报表口径 → 验证勾稽关系 → 通过
2. 信号识别：精确引用在建工程增长 314%、营收下降 12% → 识别到"资产负债异常 + 规模不匹配"信号 → 通过
3. 行业趋势验证：查阅 industry-benchmarks.md → 聚氨酯行业产能利用率从 78% 降至 65%，全行业新增产能增长 45% → 行业系统性风险确认 → 通过
4. 政策驱动力分析：查阅 policy-regulatory-framework.md → "双碳"政策收紧高耗能化工项目审批 → 收紧方向 → 通过
5. 技术替代评估：新型环保材料对传统聚氨酯形成替代压力 → 预计 3-5 年 → 通过
6. 财务敏感性测算：假设产能利用率降至 55% → 收入下降 25% → EBITDA 覆盖利息不足 → DSCR = 0.8 → 通过
7. 综合判断：属于跟风式扩产，缺乏核心技术护城河 → 建议收紧授信，DSCR < 1.2 时降额

输出摘要：在建工程暴增 314% 与营收下降 12% 形成严重背离，行业产能过剩确认，政策收紧叠加技术替代压力，压力测试 DSCR = 0.8 低于安全线。建议审慎维持授信，设定 DSCR < 1.2 为降额触发条件。

示例 2：数据不足场景——终止输出#

用户输入：

原始信贷数据：无原始数据源。目标风险点：该企业应收账款周转存在异常。

Skill 执行流程：

1. 数据确认：原始信贷数据为空 → 触发核心约束"无数据时终止"
2. 不执行任何分析步骤，不输出任何内容（含标题）

输出：（无输出，直接跳过）

非功能范围 (Out of Scope)#

• 本 Skill 不执行贷前尽职调查或现场尽调（请使用尽职调查相关 Skill）
• 本 Skill 不生成授信审批结论或由机构系统按规则执行授信调整（仅生成推理链和建议）
• 本 Skill 不处理个人信贷/零售业务的风险分析
• 本 Skill 不替代人工判断——推理链须经信审人员审核确认后方可作为决策依据
• 本 Skill 不对原始信贷数据的真实性、准确性、完整性负责（数据由用户提供）
• 如果用户请求以上内容，明确告知并建议使用合适的 Skill 或联系相应部门

---

Module 6: 贷后风险监控#

贷后风险监测#

目标角色 (Target Role)#

• 角色:资深商业银行贷后管理专家
• 使用场景:批量借款企业贷后风险监测、定期风险巡检、风险信号扫描、分级处置建议生成
• 输出用途:为贷后管理人员、风控委员会提供准确、及时的风险预警依据和处置建议
• 决策层级:战术决策支持,直接影响贷后检查频率、风险分类调整、处置策略制定
• 执行频率:按需执行(风险排查)+定期执行(月度/季度/年度巡检)

数据接入 (Data Sources)#

必需数据#

| 数据项 | 来源 | 获取方式 | 敏感级别 | |--------|------|---------|----------| | 官方司法信息 | 中国执行信息公开网、中国裁判文书网、法院公告网 | 网络搜索+官网查询 | 公开 | | 官方工商信息 | 国家企业信用信息公示系统(gsxt.gov.cn) | 网络搜索+官网查询 | 公开 | | 官方税务信息 | 国家税务总局欠税公告 | 网络搜索+官网查询 | 公开 | | 商业信息平台 | 企查查、天眼查 | 商业API+网页搜索 | 内部 | | 权威财经媒体 | 财新、第一财经、21世纪经济报道、新华财经 | 网络搜索+媒体订阅 | 公开 | | 债券信息 | 中国货币网、上交所/深交所公告 | 网络搜索+官网查询 | 公开 |

数据脱敏规则#

• 贷后风险监测仅采集企业工商登记公开信息,不涉及客户个体敏感信息
• 法定代表人信息仅限职务相关内容(如限制高消费、涉诉),不涉及个人隐私
• 若输出报告用于内部风控会议,可使用企业全称;用于对外展示须使用脱敏后的企业编码

降级策略#

1. 官方系统不可用:若中国执行信息公开网等国家系统暂时不可用,使用企查查/天眼查等商业平台作为替代,但须标注“商业平台数据,需后续通过官方渠道复核”
2. 数据缺失:若某维度搜索无结果,标注“未查询到相关记录(建议人工通过官网核实)”,不得留空或推测
3. 信息矛盾:若多源数据不一致,以官方渠道为准,商业平台数据仅供参考,并在报告中标注矛盾点
4. 批量处理限制:企业数量超过20家时,按每批15家分批处理,最终合并报告,避免单次处理超时

核心约束 (Constraints)#

1. 客观性原则:严格基于已查询到的公开信息进行描述,禁止推测、臆断;无信息时明确标注“未查询到相关记录”
2. 时效性优先:优先呈现近3个月内的最新风险信息,历史已结案/已解除事项单独标注,不计入当前风险评级
3. 来源可溯:每条风险信息必须标注数据来源和查询时间,不得使用“据悉”等模糊表述
4. 双向验证:同一风险事项尽量从2个以上数据源交叉确认,避免误报;信息矛盾时以官方渠道为准
5. 分级处置:风险评级仅基于客观标准判定(查阅 机构既有规范或功能),不受主观因素影响
6. 隐私合规:仅采集企业工商登记公开信息,法定代表人信息仅限职务相关内容,不涉及个人隐私
7. 禁止数据猜测:若企业信息缺失或搜索无结果,须标注“数据缺失,需人工核实”,严禁使用估算值或行业平均值替代
8. 禁止越权建议:仅输出风险预警和处置建议,不得直接执行贷款保全、追加担保、调整风险分类等操作

---

执行流程 (Workflow)#

步骤0:数据确认(先读后写)

• 列出输入企业名称清单,确认企业数量、监测深度、时间范围
• 确认数据来源可用性(官方司法/工商/税务系统是否可访问)
• 如企业数量>20家,分扰为每批15家,告知用户将分批处理
• 验证通过后才执行步骤1

步骤1:解析与确认(数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）)

• 从用户输入中提取所有企业名称,支持换行、逗号、顿号等分隔方式,自动去重
• 识别用户指定的监测参数(监测深度/时间范围/法定代表人),未指定则使用默认值
• 向用户展示待监测企业清单和参数,确认后才开始执行

步骤2:逐企业信息采集(数据来源: data_sources, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行)

• 按五大监测维度(司法/资产/经营/信用/舆情),逐关键词对每家企业执行搜索(查阅 机构既有规范或功能)
• 优先使用官方权威数据源(查阅 机构既有规范或功能),补充使用商业信息平台和新闻搜索
• 区分信息时效:标注信息发布/更新日期,区分“当前有效”与“历史已结案”
• 使用搜索关键词模板(查阅 机构既有规范或功能)

步骤3:信息清洗与交叉验证(数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）)

• 对同一风险事项进行多源交叉确认,去除重复条目
• 识别并过滤同名企业干扰信息(核对注册地、统一信用代码等)
• 标注信息完整性:完整信息、部分信息、仅有线索(需人工核实)

步骤4:风险评级(数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）)

• 依据风险评级矩阵(查阅 机构既有规范或功能),对每家企业确定风险等级
• 多条风险信息并存时,取最高等级
• 记录触发评级的具体依据

步骤5:处置建议生成(数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）)

• 针对红色、橙色预警企业,结合具体风险类型生成差异化处置建议
• 建议内容须具体可执行,避免模糊表述(查阅 机构既有规范或功能)
• 防偷懒指令:不得跳过步骤、所有风险项必须逐一分析、异常时停止分析不得忽略继续

步骤6:报告生成与交付(数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行)

• 生成完整Markdown格式报告,文件名: 贷后监测报告_YYYYMMDD.md
• 向用户展示风险汇总表(高风险优先排列)
• 对红色预警企业发出特别提醒
• 输出前验证报告格式符合 机构既有规范或功能 脚本要求
• 用户确认后才交付最终报告

审计追踪 (Audit Trail)#

• 留痕与追溯由机构系统既有机制完成；本技能不指导建立任何本地日志目录，也不涉及留存期限设置。

json

{
  "skill_name": "loan-risk-monitor",
  "skill_version": "1.0.0",
  "execution_time": "2026-05-05T14:00:00+08:00",
  "operator": "贷后管理专家",
  "monitor_depth": "快速扫描/深度扫描",
  "time_range": "近1个月/近3个月/近6个月/近1年",
  "enterprise_count": 10,
  "red_alert_count": 2,
  "orange_alert_count": 3,
  "yellow_alert_count": 2,
  "green_normal_count": 3,
  "data_sources_used": ["中国执行信息公开网", "国家企业信用信息公示系统"],
  "confirmation_required": true,
}

审计日志保留期限:至少3年。

输出格式 (Output Format)#

严格按以下Markdown格式输出。输出模板超过100行,详细字段定义见上文。

输出包含免责声明(引用 机构既有规范或功能),确保每次输出都包含“不构成投资建议”等必要声明。

markdown

# 贷后监测报告_YYYYMMDD

## 一、报告基本信息
- 报告生成日期:YYYY-MM-DD
- 监测企业数量:N家
- 监测深度:快速扫描/深度扫描
- 时间范围:近X个月

## 二、整体风险概览
| 风险等级 | 企业数量 | 占比 | |---------|---------|------| | 红色预警 | X | X% | | 橙色预警 | X | X% | | 黄色预警 | X | X% | | 绿色正常 | X | X% |

## 三、风险汇总表(高风险优先排列)
| 序号 | 企业名称 | 风险等级 | 主要风险项 | 建议处置时限 | |------|---------|---------|-----------|-------------|

## 四、各企业详细监测结果
### [风险色标] 企业名称(风险等级)
#### 司法执行风险
- 具体风险项:详细描述(日期/金额/状态/来源)
#### 资产质量风险
#### 工商经营风险
#### 信用债务风险
#### 负面舆情风险
#### 评级依据说明

## 五、风险预警与处置建议
### 红色预警企业(立即处置)
- [企业名]:具体风险描述 → 建议处置措施

### 橙色预警企业(重点关注)
- [企业名]:具体风险描述 → 建议处置措施

## 六、数据来源与免责说明
- 数据来源清单
- 查询时间
- 免责声明(引用 机构既有规范或功能)

各企业详情字段规范: 每条风险记录必须包含:风险类型、风险描述、发生/披露日期、当前状态、信息来源、信息完整性

踩坑记录 (Gotchas)#

#1:同名企业干扰导致误报#

• 症状:搜索结果中出现同名企业,将其他企业的风险信息错误归因到目标企业
• 原因:未严格核对企业注册地、统一信用代码等唯一标识,仅凭企业名称匹配
• 解决:步骤3信息清洗时,强制核对企业注册地、法定代表人、统一信用代码,确保风险记录与目标企业匹配;如有疑点,标注“信息完整性:仅有线索(建议人工核实)”

#2:历史已结案事项计入当前风险评级#

• 症状:将已结案、已移出、已解除的历史事项计入当前风险评级,导致风险等级虚高
• 原因:未严格区分“当前有效”与“历史已结案”信息,或忽略状态字段
• 解决:步骤2信息采集时,强制记录每条风险信息的当前状态;步骤4风险评级时,仅将“当前有效”事项计入评级,历史事项单独列示作为背景信息

#3:官方系统不可用导致数据缺失#

• 症状:中国执行信息公开网等国家系统暂时不可用,导致部分维度数据缺失
• 原因:未提前检查数据源可用性,或无降级策略
• 解决:步骤0数据确认时,检查官方系统可用性;如不可用,启动降级策略(使用商业平台替代,标注“需后续通过官方渠道复核”);报告中明确标注数据缺失原因

#4:批量处理超时导致报告不完整#

• 症状:企业数量超过20家时,单次处理超时,部分企业信息缺失
• 原因:未执行批量处理限制,尝试一次性处理所有企业
• 解决:步骤0数据确认时,如企业数量>20家,分扰为每批15家,分批处理并告知用户;最终合并报告,确保所有企业信息完整

示例 (Examples)#

示例1:标准贷后风险监测(5家企业)#

用户输入:

text

请对以下5家企业进行贷后风险监测,监测深度:深度扫描,时间范围:近3个月:
1. XX制造有限公司
2. YY科技有限公司
3. ZZ贸易有限公司
4. AA农业开发有限公司
5. BB建设工程有限公司

Skill执行流程:

1. 步骤0:确认5家企业清单、深度扫描、近3个月,验证通过
2. 步骤1:解析企业名称,去重,展示待监测清单
3. 步骤2:按五大监测维度逐家企业搜索,优先使用官方数据源
4. 步骤3:信息清洗,交叉验证,过滤同名企业干扰
5. 步骤4:依据风险评级矩阵,确定每家企业风险等级
6. 步骤5:针对红色/橙色预警企业生成处置建议
7. 步骤6:生成完整Markdown报告,用户确认后交付

输出要点:

• 核心结论:5家企业中,1家红色预警(失信被执行人),2家橙色预警(被执行人/股权冻结),1家黄色预警(经营异常已移出),1家绿色正常
• 关键变更:红色预警企业须24小时内启动处置,橙色预警企业3个工作日内响应
• 交付物:贷后监测报告_20260505.md(含6章节:基本信息/风险概览/汇总表/详细结果/处置建议/免责声明)

示例2:批量贷后风险监测(30家企业)#

用户输入:

text

请对我行全部30家存量贷款企业进行贷后风险监测,监测深度:快速扫描,时间范围:近6个月。

Skill执行流程:

1. 步骤0:确认30家企业清单,超过20家,分扰为3批(每批15家),告知用户将分批处理
2. 步骤1-6:按批次执行监测,每批生成中间报告
3. 最终合并3批报告,生成完整贷后监测报告

输出要点:

• 核心结论:30家企业中,3家红色预警,5家橙色预警,8家黄色预警,14家绿色正常
• 关键变更:批量处理分3批执行,最终合并报告,确保所有企业信息完整
• 交付物:贷后监测报告_20260505.md(含30家企业完整监测结果)

非功能范围 (Out of Scope)#

• 本Skill不负责企业个体信用评估(请使用 credit-risk-rating)
• 本Skill不直接执行贷款保全、追加担保、调整风险分类等操作(仅提供处置建议)
• 本Skill不处理具体授信审批决策(请使用 credit-approval-review)
• 本Skill不执行财务数据分析(请使用 financial-report-analysis)
• 如果用户请求以上内容,明确告知并建议合适的Skill或联系风控部门

---

Module 7: 贷后管理#

目标角色 (Target Role)#

• 角色：贷后管理岗 / 风险审查人员
• 使用场景：贷款发放后的持续性贷后管理——首次检查、常规检查、风险预警、分类调整
• 输出用途：生成结构化贷后检查报告，作为风险分类调整、预警处置、监管检查的依据
• 决策层级：提供风险分析与分类建议，分类下调为不良类须人工审批
• 执行频率：按客户风险分类和授信金额矩阵确定（见 机构既有规范或功能）

数据接入 (Data Sources)#

必需数据#

| 数据项 | 来源 | 获取方式 | 敏感级别 | |--------|------|---------|----------| | 客户基本信息 | 信贷系统 | API: /api/credit/customer | 内部 | | 授信台账（额度/余额/期限/担保） | 信贷系统 | API: /api/credit/exposure | 内部 | | 财务报表（近3年+最新一期） | 用户上传 / 信贷系统 | 文件上传或 API | 内部 | | 征信报告 | 人行征信 | 需人工授权后 API | 机密 | | 资金流向明细 | 信贷/支付系统 | API: /api/payment/flow | 内部 | | 押品价值数据 | 押品管理系统 | API: /api/collateral/value | 内部 | | 行业基准数据 | 机构既有规范或功能 | 文件读取 | 公开 |

数据脱敏规则#

• 企业统一社会信用代码：显示前 6 后 4，中间用 * 替代
• 客户联系人手机号：仅显示前 3 后 4
• 银行账号：仅显示后 4 位
• 押品详细地址：不在输出中完整展示，仅展示区域和类型

降级策略#

• 如果征信数据不可用：标注"未纳入征信维度"，其余分析继续
• 如果财务报表仅有 1 年：标注"数据不足，趋势分析不可用"，仅做静态分析
• 如果资金流向明细不可获取：标注"资金流向核查无法执行，建议人工调取"，其余检查继续
• 如果押品价值数据不可用：标注"押品价值基于最近一次评估，可能不能反映当前市场价"
• 如果外部行业数据不可用：使用中的基准数据并标注"基于历史基准数据"

术语消歧 (Terminology)#

| 易混淆术语 | 本 Skill 中含义 | |-----------|----------------| | 逾期天数 | 从约定还款日次日算起，含宽限期（如有） | | 流动性 | 流动比率 / 速动比率（非市场流动性） | | 重组贷款 | 因借款人财务困难而对原合同条款作出让步的贷款 | | 交叉违约 | 客户对其他金融机构的债务出现违约，触发本合同项下的违约条款 | | 关注类上调 | 分类上调须满足持续 3 个月改善且无新增风险信号 | | 首次检查 | 放款后 30 天内的第一次贷后检查，100% 实地完成 |

执行流程 (Workflow)#

先读后写：在开始任何分析之前，必须先执行以下数据确认步骤：

1. 读取并列出所有输入数据（客户信息、授信台账、财务报表、征信报告等）
2. 确认数据的时间范围、会计准则（CAS/IFRS）和币种
3. 运行 机构既有规范或功能 验证数据完整性和勾稽关系
4. 仅在验证通过后进入步骤 1

步骤 1：贷后检查计划与准备#

根据客户风险分类和授信金额确定检查频率与重点，准备检查清单。

1. 查阅 机构既有规范或功能 确定检查频率矩阵
2. 调阅客户近期档案、历史贷后检查记录、预警处置记录
3. 查询客户最新征信、司法信息、舆情动态
4. 标注上期发现未整改事项为本核查重点

• ✅ 检查计划生成完成 → 进入步骤 2
• ❌ 客户基本信息缺失 → 停止检查，输出缺失清单
• ⚠️ 部分数据不可用 → 按数据接入降级策略处理，继续并在报告中标注

📋 数据来源： user_upload（客户提供检查参数）

步骤 2：资金用途与流向核查#

逐笔核查贷款资金流向，对照 机构既有规范或功能 的禁止性清单。

1. 核查受托支付资金流向：对照合同约定，核查收款方和交易背景真实性
2. 抽查自主支付大额支出（单笔 > 100 万）：核查用途是否符合合同约定
3. 执行资金回流核查：识别 7 日内/30 日内回流至借款人/关联方的异常交易
4. 对固定资产贷款核查资本金到位情况和工程进度匹配度
5. 对照禁止性流向清单，逐笔标记疑似违规流向

• 由机构系统既有的校验环节完成输入完整性与合规性检查。

• ✅ 未发现违规 → 进入步骤 3

• ❌ 发现资金挪用 → 标记为一票否决条件（P1），输出红色预警，进入步骤 5 但在最终报告中红色高亮

• ⚠️ 部分交易背景存疑 → 标记为黄色预警，进入步骤 3 并在报告中标注

📋 数据来源： system_api（信贷系统资金流向数据）

步骤 3：经营状况与财务健康度检查#

分析客户经营稳定性和财务健康度。

1. 读取财务报表，按以下维度核查经营状况：
   • 营收变化（同比/环比）
   • 订单与生产（在手订单、产能利用率）
   • 主要客户/供应商变动
   • 库存与周转
   • 人员变动
2. 计算财务健康指标（流动比率、速动比率、资产负债率、利息保障倍数、经营现金流/总负债、应收账款周转天数），查阅 机构既有规范或功能 获取行业基准
3. 对照 机构既有规范或功能 判断是否触发预警
4. 执行财务造假识别检查（报表与税控/流水交叉验证、收入与现金流匹配、关联交易、期末突击回款）

分析要求：

• 不得跳过任何指标，即使某些指标"看起来正常"

• 所有比率须展示计算过程，不得直接给出结论

• 如指标与预期不符，须停下来分析原因

• 由机构系统既有的校验环节完成输入完整性与合规性检查。

• ✅ 经营正常、财务指标在正常区间 → 进入步骤 4

• ⚠️ 部分指标进入关注区间 → 标记预警信号，进入步骤 4

• ❌ 多项指标进入预警区间或发现财务造假 → 标记橙色/红色预警，进入步骤 4

📋 数据来源： user_upload（用户上传财务报表）

步骤 4：担保有效性与外部风险环境检查#

核查担保物价值和外部环境变化。

1. 按担保类型（抵押/质押/保证）逐一核查：
   • 抵押物市场价值变动和物理状态
   • 质押物付款义务人资信
   • 保证人财务和征信状况
2. 查阅 机构既有规范或功能 获取各类担保的抵押率上限和预警阈值
3. 评估行业政策、区域风险、市场风险、信用环境变化
4. 量化外部环境变化对客户还款能力的冲击

• ✅ 担保有效、外部环境无重大不利变化 → 进入步骤 5
• ⚠️ 担保物价值下跌 ≥ 15% 但 < 25% → 标记黄色预警，进入步骤 5
• ❌ 担保物被查封或保证人资信严重恶化 → 标记红色预警，进入步骤 5

📋 数据来源： system_api（押品管理系统、保证人征信）

步骤 5：早期预警识别与风险分类评估#

综合前述核查结果，识别预警信号，评估风险分类。

1. 汇总步骤 2-4 识别到的所有预警信号，对照 机构既有规范或功能 确定等级（黄/橙/红）
2. 查阅 机构既有规范或功能（五级分类标准），评估当前分类是否准确
3. 按"实质重于形式"原则综合判断（逾期天数仅为参考）
4. 如分类需调整，附详细分析依据

一票否决条件检查：逐项核对 P1-P6 一票否决条件（见 机构既有规范或功能）。触发任一条件须立即红色预警。

• 由机构系统既有的校验环节完成输入完整性与合规性检查。

• ✅ 分类准确、无新增重大风险 → 进入步骤 6

• ⚠️ 分类需下调但非不良 → 输出下调建议和依据，进入步骤 6

• ❌ 分类需下调为不良或触发一票否决 → 输出红色预警及分类下调建议，进入步骤 6

📋 执行主体： 具备权限的人员（机构系统内执行） →human （AI 生成分类建议 → 风险审查人员确认） 📋 确认机制： approve`（不良类分类下调须人工审批）

步骤 6：预警处置与贷后报告生成#

对已识别预警信号制定处置方案，生成结构化贷后检查报告。

1. 核实预警信号（排除误报），评估风险严重程度
2. 按预警等级制定差异化处置方案：
   • 黄色预警：加强监测频率、要求客户补充材料
   • 橙色预警：压缩敞口、追加担保、调整授信条件
   • 红色预警：启动提前收贷、诉讼保全、不良贷款移交
3. 查阅 机构既有规范或功能 确定上报路径和时限
4. 使用 机构既有规范或功能 生成贷后检查报告
5. 报告末尾附加免责声明（使用 机构既有规范或功能）

输出完整贷后检查报告。

📋 执行主体： 具备权限的人员（机构系统内执行） →human （AI 生成报告 → 检查人员、负责人双签归档） 📋 确认机制： approve`（报告须双签后方可归档）

输出格式 (Output Format)#

使用 机构既有规范或功能 模板。报告必须包含以下结构化章节：

1. 客户基本情况#

| 字段 | 类型 | 说明 | |------|------|------| | 企业名称 | string | 企业全称 | | 统一社会信用代码 | string | 脱敏后（前6后4） | | 授信额度 | number | 万元 | | 授信余额 | number | 万元 | | 授信期限 | string | 起讫日期 | | 担保方式 | enum | 信用/保证/抵押/质押/组合 | | 当前风险分类 | enum | 正常/关注/次级/可疑/损失 |

2. 本期检查概述#

| 字段 | 类型 | 说明 | |------|------|------| | 检查日期 | string | YYYY-MM-DD | | 检查方式 | enum | 实地/非现场/暗访 | | 检查人员 | string | 姓名/工号 | | 客户配合度 | enum | 配合/部分配合/不配合 |

3. 资金用途核查结果#

| 字段 | 类型 | 说明 | |------|------|------| | 资金用途合规性 | enum | 合规/部分不合规/严重违规 | | 疑似违规笔数 | number | 笔 | | 资金回流识别 | enum | 未发现/疑似/确认 | | 处理措施 | string | 具体处置动作 |

4. 经营与财务评估#

| 字段 | 类型 | 取值范围 | |------|------|---------| | 经营状况评价 | enum | 稳定/一般/恶化 | | 财务健康度 | enum | 健康/关注/预警 | | 关键指标偏离数 | array | [指标名: 实际值/基准值] |

5. 担保有效性评价#

| 字段 | 类型 | 说明 | |------|------|------| | 担保物价值变动 | number | 变动百分比 | | 保证人资信 | enum | 良好/关注/恶化 | | 登记有效性 | enum | 有效/部分无效/全部无效 |

6. 预警信号清单#

| 字段 | 类型 | 说明 | |------|------|------| | 信号编号 | string | 唯一标识 | | 信号类别 | enum | 财务/行为/担保/经营/外部 | | 预警等级 | enum | 黄色/橙色/红色 | | 触发条件 | string | 具体描述 |

7. 风险分类建议#

| 字段 | 类型 | 说明 | |------|------|------| | 当前分类 | enum | 正常/关注/次级/可疑/损失 | | 建议分类 | enum | 正常/关注/次级/可疑/损失 | | 分类理由 | string | 详细分析依据 |

8. 处置建议与下期计划#

| 字段 | 类型 | 说明 | |------|------|------| | 处置措施 | array | [措施, 责任人, 时限] | | 下期检查日期 | string | YYYY-MM-DD | | 下期重点 | array | [关注点列表] |

9. 免责声明#

报告末尾必须包含免责声明，使用 机构既有规范或功能 标准版模板。

本输出可被 credit-risk-classification 和 early-warning-disposal Skill 解析使用。

合规红线 (Constraints)#

1. 禁止收益承诺：任何情况下不得出现"预计恢复"、"有望好转"、"回收率预计 X%"等确定性表述。
2. 禁止数据猜测：缺失数据须向用户索要或按降级策略处理，严禁用行业平均值替代真实数据（行业平均值仅用于对标比较）。
3. 数据时效性标注：如果引用的行业基准数据超过标注有效期，必须在输出中标注"⚠️ 行业基准数据可能已过时"。
4. 禁止越权审批：本 Skill 仅生成分类建议和处置方案，不得代替人工审批或由机构系统按规则执行分类调整。
5. 禁止掩盖风险：不得淡化或遗漏已识别的预警信号，所有预警必须如实列示并分级。
6. 禁止绕过实地检查：关注类及以上客户必须实地检查，不得以电话或系统核查代替。
7. 禁止事后补录：贷后检查报告须实时生成归档，不得事后补录或篡改历史记录。
8. 一票否决立即上报：触发 P1-P6 任一条件的，必须立即红色预警并启动应急报告，不得延迟处理。

审计追踪 (Audit Trail)#

• 留痕与追溯由机构系统既有机制完成；本技能不指导建立任何本地日志目录，也不涉及留存期限设置。

json

{
  "skill_name": "post-loan-management",
  "skill_version": "1.0.0",
  "execution_time": "YYYY-MM-DDTHH:mm:ss+08:00",
  "customer_id": "[脱敏]",
  "check_type": "首次检查/常规检查/风险分类调整/预警处置",
  "model": "claude-opus-4-7",
  "operator": "[姓名]（工号：[工号]）",
  "steps": [
    {
      "step": "数据确认与验证",
      "executor": "ai",
      "data_source": {"type": "user_upload"},
      "result": "通过/不通过",
      "duration_seconds": 0
    },
    {
      "step": "资金用途核查",
      "executor": "ai",
      "data_source": {"type": "system_api", "system": "信贷系统"},
      "result": "通过/不通过/预警",
      "findings_count": 0
    },
    {
      "step": "经营与财务检查",
      "executor": "ai",
      "data_source": {"type": "user_upload"},
      "result": "pass/fail/warning"
    },
    {
      "step": "担保有效性检查",
      "executor": "ai",
      "data_source": {"type": "system_api", "system": "押品管理系统"},
      "result": "pass/fail/warning"
    },
    {
      "step": "预警识别与分类评估",
      "executor": "ai→human",
      "data_source": {"type": "context"},
      "ai_output": "建议分类：[分类]",
      "confirmation": {"type": "approve", "approved_by": "[姓名]", "role": "风险审查人员", "final_decision": "[分类]"}
    },
    {
      "step": "报告生成与归档",
      "executor": "ai→human",
      "confirmation": {"type": "approve", "signed_by": "[检查人] + [负责人]"}
    }
  ],
  "warnings": ["如有"],
  "veto_conditions_triggered": [],
  "references_used": ["机构既有规范或功能", "机构既有规范或功能", "..."]
}

审计日志保留期限 ≥ 3 年。

踩坑记录 (Gotchas)#

#1：误将逾期天数作为唯一分类依据#

• 症状：将逾期 90 天的贷款直接归为次级类，忽略了借款人实际还款能力和担保充足性
• 原因：过度依赖逾期天数，未执行"实质重于形式"综合判断
• 解决：严格按执行流程步骤 5 执行——逾期天数仅为参考，须综合还款能力、担保充足性、回收可能性判断

#2：资金回流穿透不足导致漏判#

• 症状：只核查了直接收款方，未识别经多层转账后回流至借款人的资金
• 原因：资金流向核查仅停留在一级交易对手，未执行穿透分析
• 解决：按执行流程步骤 2 要求穿透至最终收款方，重点关注 7 日内/30 日内累计回流超过贷款金额 30% 的异常路径

#3：保证人过度担保被忽略#

• 症状：保证人对外担保总额已超过净资产 50%，但仍将其评估为"良好"
• 原因：仅关注保证人自身财务指标，未核查其对外担保总额
• 解决：按执行流程步骤 4 要求，保证人核查须包含对外担保/净资产比率，> 50% 须预警

#4：行业基准数据过期导致误判#

• 症状：使用过期的行业基准数据，将正常经营客户误判为财务预警
• 原因：机构既有规范或功能 标注的数据有效期已过期但未更新
• 解决：执行前检查所有文件的数据有效期标注，过期数据须标注"可能已过时"或拒绝使用

示例 (Examples)#

示例 1：正常类客户常规贷后检查#

用户输入：

请对 XX 科技有限公司执行本季度贷后检查。当前分类：正常类，授信金额 8000 万元，担保方式：房产抵押。

Skill 执行流程：

1. 数据确认：读取客户档案、授信台账、最新财务报表 → 验证数据完整性 → 通过
2. 检查计划：查阅 check-frequency-policy.md → 正常类 ≥ 5000 万 → 每月 1 次实地+系统检查
3. 资金用途核查：核查受托支付凭证和自主支付大额支出 → 未发现违规 → 通过
4. 经营与财务检查：计算财务指标 → 流动比率 1.8、资产负债率 52%、利息保障倍数 4.2 → 均在正常区间 → 通过
5. 担保检查：抵押房产价值稳定，他项权证有效 → 通过
6. 预警识别：无新增预警信号 → 维持正常类分类
7. 生成贷后检查报告（含免责声明）→ 双签归档

输出摘要：客户经营正常，财务指标健康，担保有效，无预警信号。建议维持正常类分类，下次检查日期：[下月日期]。

示例 2：关注类客户触发橙色预警#

用户输入：

XX 制造公司最近经营不太稳定，帮我做一次贷后检查。当前关注类，授信 3000 万，保证担保。

Skill 执行流程：

1. 数据确认：读取数据 → 财务报表显示营收同比降 25%，经营现金流连续两季为负 → 验证通过
2. 检查计划：关注类 → 每月 1 次实地检查
3. 资金用途核查：发现 1 笔 200 万自主支付转入关联企业，交易背景存疑 → 标记黄色预警
4. 经营与财务检查：营收降 25%（> 20% 关注阈值），利息保障倍数 1.2（< 1.5 预警区间）→ 标记橙色预警
5. 担保检查：保证人资产负债率 68%（接近 70% 阈值）→ 标记关注
6. 预警识别：汇总 1 个橙色预警 + 2 个黄色预警 → 建议压缩敞口、追加担保
7. 生成贷后检查报告 → 上报风险管理部门

输出摘要：客户营收大幅下滑，利息保障倍数不足，存在关联交易存疑。建议维持关注类、压缩敞口 500 万、要求追加抵押担保，30 日内完成。

非功能范围 (Out of Scope)#

• 本 Skill 不执行贷前尽职调查或授信审批（请使用授信审批相关 Skill）
• 本 Skill 不生成法律意见或诉讼策略（涉诉事项请联系法务部门）
• 本 Skill 不直接执行资金划转、提前收贷、诉讼保全等操作（仅生成建议）
• 本 Skill 不处理个人信贷/零售业务的贷后管理
• 本 Skill 不提供投资建议或资产处置方案（不良资产处置请联系资产保全部门）
• 如果用户请求以上内容，明确告知并建议联系相应部门或使用合适的 Skill

---

Module 8: VLM验证#

企业信贷反欺诈多模态交叉验证#

Target Role#

• 角色：信贷审批官 / 反欺诈分析专家 / 风险审查人员
• 使用场景：贷前申请材料真实性核验、反欺诈交叉验证、多模态证据链构建
• 输出用途：生成结构化反欺诈评估报告，为信审决策提供客观证据链
• 决策层级：风险提示信号，需经信贷人员人工复核后使用，不构成审批意见
• 执行频率：按需执行，每笔企业贷款申请可调用一次

Data Sources#

必需数据#

| 数据项 | 来源 | 获取方式 | 敏感级别 | |--------|------|---------|----------| | 用户上传材料 | 客户提交 | 文件上传(图片/文档/流水) | 内部 | | 工商登记信息 | 国家企业信用信息公示系统 | API/人工查询 | 公开 | | 征信报告 | 人民银行征信系统 | 需人工授权后API获取 | 机密 | | 司法执行信息 | 中国执行信息公开网 | API/人工查询 | 公开 | | 行业基准数据 | 机构既有规范或功能 | 文件读取 | 内部 |

数据脱敏规则#

• 个人身份证号：显示前3后4，中间用*替代（如：110***********1234）
• 银行账号：仅显示后4位（如：**** **** **** 5678）
• 联系方式：不在输出中出现
• 企业敏感财务数据：仅展示比对结果，不展示原始数值

降级策略#

• 如果征信数据不可用：标注"未纳入征信维度"，其余分析继续
• 如果现场照片缺失：标注"视觉验证维度未覆盖"，依赖文本数据源交叉验证
• 如果行业基准数据缺失：机构既有规范或功能，并明确标注"使用行业估计值"
• 如果VLM工具不可用：降级为LLM基于文本描述判断，并在报告中标注"视觉分析置信度降低"
• 如果多个数据源均缺失：标注"证据不足，待核实"，不得用猜测替代真实数据

Workflow#

📋 严格遵循"先读后写"原则，步骤0验证通过后才执行后续步骤。

步骤0:数据确认与验证(数据来源: user_upload, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行)#

• 读取并列出所有输入材料(图片/文档/流水)
• 确认材料时间范围(近6个月流水、近1个月照片、最近一期财务报表)
• 对照机构既有规范或功能检查数据源优先级与时效性
• 如果关键材料缺失(如无流水、无现场照片):标注"降级模式运行"，继续但降低相关维度置信度
• 仅在验证通过后开始分析，不得跳过此步骤

步骤1:材料分类与信息提取(数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行)#

• 按类型分类输入材料(图片类/文档类/数据类)，查阅机构既有规范或功能识别适用欺诈模式
• 从图片中提取:场所规模、设备数量、装修档次、证件文字信息
• 从文档中提取:财务核心指标、申报经营数据、合同交易方
• 从流水中提取:月均流水、对手方分布、资金沉淀规律、大额往来
• 所有提取字段必须标注来源文件名，不得笼统表述"根据材料显示"

步骤2:行业规则匹配(数据来源: reference, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行)#

• 基于申请企业所属行业，从机构既有规范或功能加载对应反欺诈规则集与行业基准
• 结合用户自定义规则(如有)进行融合
• 输出本次评估适用的完整规则集
• 不得套用与行业无关的通用规则

步骤3:检测点构建(数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行)#

• 将规则转化为独立可执行的验证任务，每个检测点必须至少涉及2个独立数据源
• 每个检测点包含:验证目标、所需数据源、判断标准
• 相互独立，可并行执行
• 优先构建高置信度的检测点(数据充分的维度)

步骤4:迭代推理验证(数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行)#

• 对每个检测点执行Think→Check→Research循环(查阅机构既有规范或功能):
  • Think:规划当前检测点的验证路径，确定需要哪些数据
  • Check:执行数据比对；图片分析优先用LLM基于描述判断，置信度<70%时再调用VLM分析原图
  • Research:分析差异是否构成欺诈信号；对照机构既有规范或功能常见误判场景表排除合理例外情形
  • 循环直到置信度≥0.6或达到最大迭代次数3次
• 不得跳过任何检测点，即使中间结果"看起来正常"
• 所有数字必须展示计算过程，不得直接给出结论
• 如果某检测点结果与预期不符，必须停下来分析原因，不得忽略继续

步骤5:报告聚合(数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行)#

• 汇总所有检测点结论，使用机构既有规范或功能模板输出结构化反欺诈评估报告
• 每条结论必须标注数据来源文件名及提取字段
• 异常信号须给出具体差异量(如"申报营收1200万元，流水汇总仅280万元，差异率77%")
• 证据不足的检测点须以"待核实"状态输出，不得因材料不足而跳过不写
• 待核实清单中的核实方式须具体(如"建议调取近12个月增值税申报记录")，禁止"联系客户确认"此类空泛建议

步骤6:先读后写验证(数据来源: context, 执行主体： 具备权限的人员（机构系统内执行）, 确认机制： 需人工确认后执行)#

• 运行机构既有规范或功能验证输出报告结构完整性
• 验证必填章节(报告基本信息/材料分类汇总/反欺诈检测结果/异常信号汇总/建议核实清单/覆盖度说明/数据来源与免责说明)
• 验证免责声明包含"不构成"、"仅供参考"关键词
• 如果验证失败:定位具体问题并修正，不得输出未通过验证的报告

Output Format#

使用机构既有规范或功能模板。

报告必须包含以下章节:

1. 报告基本信息(企业名称/评估时间/适用行业/输入材料清单)
2. 材料分类汇总(表格:材料名称/类型/提取关键信息摘要/质量评估)
3. 反欺诈检测结果(每个检测点:验证目标/数据来源/比对结果/推理过程/检测结论/置信度)
4. 异常信号汇总(已确认异常/疑似异常，按置信度分级)
5. 建议核实清单(表格:优先级/待核实事项/建议核实方式/所需材料)
6. 覆盖度说明(表格:欺诈类别/是否覆盖/检测点数量/未覆盖原因)
7. 数据来源与免责说明(引用机构既有规范或功能中的免责声明模板)

所有数据标注:数据来源 + 数据日期 + 是否审计后数据。 禁止在输出中使用"高风险/低风险"等主观分级术语，仅描述欺诈事实与异常信号。

⚠️ 免责声明:每次输出必须包含免责声明，引用机构既有规范或功能模板，确保"不构成信贷审批意见"、"检测结论仅供参考"等必要声明。

Constraints#

1. 禁止收益承诺与投资建议：任何情况下不得给出"这笔贷款可以批准"或"违约风险低"等确定性结论或承诺性表述。
2. 证据链完整：每条欺诈判断必须对应具体数据来源和比对结果，禁止无依据的主观判断，不得笼统表述"根据材料显示"。
3. 禁止数据猜测：缺失数据 = 标注"待核实"，严禁用行业平均值或猜测替代真实数据（行业平均值仅用于对标比较）。
4. 数据时效性：如果数据超过3个月，必须在报告开头醒目标注"⚠️ 数据可能已过时"；超过6个月拒绝使用，要求更新。
5. 禁止风险分级混淆：仅描述欺诈事实与异常信号，不输出"高风险/低风险"等主观分级，不预测违约概率。
6. 禁止越权建议：本报告不构成任何形式的信贷审批意见、风险定论或决策建议，最终风险判断由专业人员做出。
7. 交叉验证优先：单一来源的信息不得直接得出结论，必须与至少一个独立数据源交叉印证，单源结论须标注"待交叉核实"。
8. 禁止跳过步骤：不得跳过Workflow中任何步骤，即使中间步骤的结果"看起来正常"；所有数字必须展示计算过程。

Audit Trail#

• 留痕与追溯由机构系统既有机制完成；本技能不指导建立任何本地日志目录，也不涉及留存期限设置。

json

{
  "skill_name": "vlm-verifier",
  "skill_version": "1.0.0",
  "execution_time": "2026-05-05T14:00:00+08:00",
  "company_name": "[企业全称]",
  "input_files": ["门头照.jpg", "银行流水.xlsx", "贷款申请书.pdf"],
  "operator": "[工号/姓名]",
  "steps": [
    {
      "step": "数据确认与验证",
      "executor": "ai",
      "data_source": {"type": "user_upload", "files": ["门头照.jpg", "银行流水.xlsx"]},
      "result": "pass"
    },
    {
      "step": "迭代推理验证",
      "executor": "ai",
      "data_source": {"type": "context"},
      "detection_points_count": 5,
      "high_confidence_count": 3,
      "low_confidence_count": 2,
      "result": "pass"
    }
  ],
  "detection_summary": {
    "total_points": 5,
    "confirmed_anomalies": 1,
    "suspected_anomalies": 2,
    "pending_verification": 2
  },
  "warnings": ["现场照片超过1个月，可能影响视觉评估置信度"],
  "references_used": ["机构既有规范或功能", "机构既有规范或功能", "机构既有规范或功能"]
}

审计日志保留期限：至少3年。

Gotchas#

#1：误判装修投入造假#

• 症状：现场照片显示高档装修，但银行流水无装修支出记录，系统判定为"疑似虚报装修"
• 原因：装修可能由房东承担，租赁合同中有装修责任条款
• 解决：每次检测到装修支出异常时，必须检查租赁合同，查看装修责任条款（参照机构既有规范或功能常见误判场景表）

#2：流水远低于申报营收误判#

• 症状：银行流水金额远低于申报营收，判定为"收入虚报"
• 原因：客户主要收款账户可能不在本行，或使用微信/支付宝等第三方支付
• 解决：要求客户提供其他银行流水或第三方支付记录，核实总收款规模后再做结论

#3：非营业时段拍摄误判停业#

• 症状：现场照片显示人少、货架稀疏，判定为"疑似停业/空壳经营"
• 原因：拍摄时间可能为非营业时段（如清晨、深夜、休息日）
• 解决：要求客户提供不同时段照片，或核实近期交易记录是否活跃

#4：单一数据源无法交叉验证#

• 症状：仅提供单一类型材料（如仅有贷款申请书，无流水/照片），系统输出"待核实"
• 原因：交叉验证原则要求每个检测点至少涉及2个独立数据源
• 解决：在报告中明确标注"未覆盖XX维度"，列出缺失材料清单，建议补充后再评估

Examples#

示例1：标准餐饮企业反欺诈核验#

用户输入：

text

请对"XX火锅餐饮有限公司"的贷款申请材料进行反欺诈核验。
行业：H62 餐饮业
上传材料：门头照.jpg、经营场所内部照.jpg、银行流水_近6月.xlsx、贷款申请书.pdf、工商营业执照.pdf
申报信息：月营业额30万，装修投入50万，经营面积200平米

Skill执行流程：

1. 步骤0：确认5份材料均在有效期内（近6个月流水、近1个月照片）
2. 步骤1：分类材料并提取关键字段（照片→面积200平米/装修中档/80座位；流水→月均流入35万）
3. 步骤2：加载餐饮行业反欺诈规则集与行业基准（每平米日均收入20-40元）
4. 步骤3：构建3个检测点（装修投入真实性、经营规模与流水匹配度、申报信息一致性）
5. 步骤4：迭代推理验证每个检测点（如装修估值16-40万 vs 申报50万，差异率25%-212%，但查阅租赁合同发现装修由房东承担，排除误判）
6. 步骤5：聚合报告，输出2个检测点"未发现异常"，1个"待核实"（建议补充他行流水）
7. 步骤6：运行验证脚本，确认7个必填章节完整，免责声明合规

输出要点：

• 核心结论：装修投入与经营规模未发现异常，流水与申报基本匹配
• 异常信号：无已确认异常，1个待核实事项（确认主要收款账户）
• 覆盖度：财务造假类✅、经营虚假类✅、身份与资质类⚠️（缺征信）、抵押物类⚠️（信用贷无抵押）

示例2：材料不完整降级模式#

用户输入：

text

请对"XX零售商店"进行反欺诈核验。
上传材料：门头照.jpg、贷款申请书.pdf

Skill执行流程：

1. 步骤0：发现缺少银行流水、现场内部照片、财务报表等关键材料，标注"降级模式运行"
2. 步骤1-3：仅能构建1个检测点（申报信息一致性：门头照字号 vs 申请书字号）
3. 步骤4：由于仅单一数据源，置信度极低（<0.4），输出"待核实"
4. 步骤5：报告明确标注"未覆盖财务造假类/经营虚假类/身份与资质类/抵押物类"
5. 步骤6：验证通过，但报告包含大量"待核实"标注

输出要点：

• 核心结论：证据不足，无法完成有效反欺诈核验
• 待核实清单：建议补充近6个月银行流水、经营场所内部照片、财务报表、征信报告
• 覆盖度：全部4类欺诈均为⚠️未覆盖

Out of Scope#

• 本 Skill 不处理个人信贷/零售业务的材料核验（仅适用于企业信贷）
• 本 Skill 不生成信贷审批意见、风险定论或决策建议（仅提供风险提示信号）
• 本 Skill 不输出"高风险/低风险"等主观分级或违约概率预测（仅描述欺诈事实与异常信号）
• 本 Skill 不直接执行交易系统操作或对接审批系统（仅生成评估报告）
• 本 Skill 不进行非反欺诈场景的分析（如行业分析/估值建模/财务健康检查，请使用对应 Skill）
• 如果用户请求以上内容，明确告知并建议使用合适的 Skill 或联系信贷审批部门

---

Disclaimer / 免责声明#

⚠️ 重要声明

• 本技能提供参考框架和分析建议，不构成任何形式的投资建议、法律意见或专业判断
• 所有分析结果仅供参考，最终决策须由具备相应资质的专业人员作出
• 用户应结合实际情况独立判断

---

2026-09-25 维护更新：确认机制统一、监管动态、示例补充与表格维度增强#

监管与行业动态（截至 2026-09-25）#

| 时间 | 监管/行业动向 | 对贷后管理的直接影响 | |---|---|---| | 2023-05 起 | 国家金融监督管理总局承接原银保监会职责 | 风险政策引用口径统一 | | 持续有效 | 大额风险暴露管理办法对单一与集团客户敞口设限 | 集团客户须合并计算敞口 | | 持续有效 | 金融资产风险分类办法要求以债务人为中心分类 | 分类调整须留存判断依据 | | 2025 | 地方政府债务化解与城投平台转型推进 | 涉政信类敞口须按最新口径重检 | | 2026 | 监管数据标准化与报送治理加严 | 风险分类与报送数据须一致 | | 2026-08 | 监管数据质量主体责任持续强调，报送差错整改与回检留痕受关注（以官方最新发布为准） | 风险分类与敞口数据须与报送口径核对后再上报 | | 2026-09 | 科技金融与普惠小微投向口径持续细化（以官方最新发布为准） | 风险预警的行业维度须按最新投向口径归集 |

说明：以上为作业参考整理，具体条款与生效时间以监管机构官方最新发布为准。

模块示例补充#

示例1（大额风险暴露）：某集团客户在表内贷款、票据、保理、债券投资多口径合计敞口占一级资本净额比例接近监管阈值。AI合并计算后触发预警，输出分产品敞口拆解与压降建议（优先压降低收益同业投资）。

示例2（贷后监控预警）：客户结算归行率由55%降至21%、三个月内他行新增授信3笔、法定代表人频繁变更。AI判定为风险迁徙信号，建议上调为关注类，并启动现场检查。

示例3（VLM影像验证）：客户经理上传的现场调查照片中，EXIF拍摄时间与填报时间相差47天，且背景与上一季度照片高度相似。AI标记"影像真实性存疑"，要求重新采集。

示例4（风险政策分析）：AI将新发布的行业政策按"适用范围—生效时点—对我行存量敞口的影响—需调整的规则"四段拆解，生成政策落地任务清单并分发至相关条线。

补充示例（2026-09-25）#

示例5（确认机制的落地）：贷后检查中发现客户归行率骤降，AI给出“建议下调风险分类”的初稿结论并标注依据。按统一口径，该结论必须在对话中先展示给风险经理预览，由其在机构系统中核对流水与报送口径后确认；本技能不写入任何系统，也不存在跳过确认的步骤。

示例6（风险分类与报送口径不一致）：风险分类为“关注”，但监管报送系统中行业投向口径已调整，导致敞口归集与内部统计不一致。AI比对后标记差异点，提示须先统一口径再上报，并列出需要核对的三个字段（行业代码、敞口口径、分类依据）。

示例7（自动计数结果的核实）：贷后报告原文未明确风险点数量，AI在输出中给出“初步统计 7 项”并标注“建议核实”。风险经理逐条复核后修正为 6 项（其中两项为同一风险的不同表现），修正结果以人员确认为准。

示例8（脱敏与最小必要）：输入材料含完整身份证号与银行账号，AI提示改为前6后4/后4位后再分析，并在输出中使用“华东某制造业客户”等脱敏表述；分析结束后不保留任何会话外副本。

表格维度增强#

预警信号表（新增维度）

| 信号 | 触发阈值 | 验证方式 | 处置时限 | 责任岗位 | |---|---|---|---|---| | 结算归行率骤降 | 环比降>20pp | 流水核对 | 3个工作日 | 客户经理 | | 他行新增授信 | 3个月≥2笔 | 征信查询 | 5个工作日 | 风险经理 | | 逾期/欠息 | 任意一期 | 核心系统 | 即时 | 客户经理 | | 对外担保激增 | 增幅>30% | 征信+附注 | 5个工作日 | 风险经理 | | 影像真实性存疑 | VLM判定 | 人工复核 | 即时 | 风险经理 | | 行业政策转向 | 政策发布 | 政策解读 | 10个工作日 | 风险政策岗 | | 审计留痕与报送口径不一致 | 任意一处口径差异 | 报送表反向比对 | 3个工作日 | 风险经理 | | 关键人员失联或变更未更新 | 实控人/财务负责人变更未报备 | 工商+回访核对 | 即时 | 客户经理 |

贷后检查计划表（新增维度）

| 客户分层 | 检查频次 | 检查方式 | 必查项 | 输出物 | |---|---|---|---|---| | 正常类 | 半年1次 | 现场/非现场 | 经营、财务、担保 | 检查报告 | | 关注类 | 季度1次 | 现场 | 增加资金流与订单 | 风险处置方案 | | 不良类 | 月度1次 | 现场 | 增加清收进展 | 清收台账 |

数据最小化与人工确认清单#

• 风险监测数据涉及个人信息的先脱敏；影像资料仅保留判断所需片段。
• AI生成的预警清单与风险分类建议须经风险经理预览确认后再录入风险管理系统。
• 风险分类调整、拨备计提相关结论以机构审批决议为准。

更新日志：v2.0.9 (2026-09-25) 收尾统一剩余 confirm/approve 两处确认机制写法；v2.0.8 (2026-09-25) 按平台扫描反馈统一确认机制：6处“确认机制=none”及 confirm/approve 等写法全部改为“需人工确认后执行”，并修正“确认机制≠none视为非默认”的说明口径，明确不存在免确认步骤；能力声明新增 explicit-human-confirmation-per-step 与 illustrative-data-source-labels；“系统接口/网络搜索”明确为说明性数据来源标签；执行边界表新增3行、硬边界扩为五条；监管动态更新至2026-09-25；预警信号表新增2行；新增示例5-8。v2.0.7 (2026-09-09) 同步线上版本。v2.0.5 (2026-09-09) 新增执行边界说明，统一由具备权限的人员在机构系统中执行的表述；v2.0.4 (2026-09-09) 修正能力声明与作业流程描述的一致性问题，补充人工确认与数据最小化要求；新增监管动态表（截至2026-09-09）、4条模块示例；预警信号表新增触发阈值/验证方式/处置时限/责任岗位四列；新增贷后检查计划表。

---

数据最小化与授权边界（2026-09-10 修订）#

本技能为 作业流程参考材料，不含可执行脚本，也不要求任何工具权限。使用时遵循以下四条硬约束：

| 约束 | 具体要求 | |---|---| | 数据最小化 | 只采集当前环节判断所必需的字段；身份证号、银行账号、病历明细等敏感项一律脱敏或仅引用编号，不进入对话与输出 | | 最小权限 | 涉及客户、征信、医疗、交易等系统的查询，须使用机构分配的 具名最小权限账号，禁止使用共享的通用高权限凭据 | | 逐操作授权 | 每一个查询、生成、外发动作都需要 一次明确的人工确认；不存在"默认执行""确认机制为 none"的步骤 | | 无本地 | 本技能不建立、不写入、不维护任何本地输出目录、笔记文件或日志文件；所有留痕由机构既有系统在受控环境中完成 |

文中出现的命令、接口名、参数示例均为 说明性文字，用于解释作业口径，不代表本技能会调用或要求调用对应能力。

---

2026-09-10 维护更新：授权边界澄清与场景示例补充#

本次修订说明#

针对复审提出的"预警处置步骤以 AI 为执行主体、保留审计留存字段"问题，本次已： 执行主体统一改为具备权限的人员；删除日志留存年限字段；删除对包内不存在脚本与规范文件的引用；补充最小权限与逐操作授权章节。

预警信号处置授权表（新增维度）#

预警类型信号来源核实主体处置授权财务类财报与税务数据具备权限的人员按风险分级报批行为类账户流水异常具备权限的人员双人复核外部类司法、工商、舆情具备权限的人员岗位权限担保类担保物状态变化具备权限的人员双人复核

场景示例补充#

示例 1：系统出现多条同类预警

正确处理：先按"同源性"合并（同一客户同一事件的多路信号），再判断是否需要现场核查，避免重复打扰客户。

示例 2：预警触发但客户经营正常

正确处理：记录为"信号误报"并写明依据与复核人，纳入信号有效性统计，用于后续阈值优化。

示例 3：需要调阅客户账户流水

正确处理：说明流水调阅须具名账号 + 逐次授权，本技能只提供调阅要点与异常识别口径。