Credit Risk Manager Digital Employee

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

⚠️ 能力声明 / Capability Notice

• Type: Knowledge reference framework for financial professionals
• Purpose: Provides analytical templates, reference data, and workflow guidance
• No persistent storage, network calls, background execution, or credential collection
• All outputs are for reference only and require human review before real-world application
• This skill does NOT provide financial, legal, or insurance advice
• Users must exercise their own judgment and consult qualified professionals

⚠️ 使用声明

• 本技能提供金融行业专业知识参考框架，辅助专业人员进行分析和决策
• 所有输出仅供专业参考，不构成投资建议、法律意见或合规保证
• 实际业务操作中需结合具体监管要求和机构内部制度执行
• 最终报告和数据须经相关责任人审核确认后方可提交或使用
• 不替代专业培训师、合规官或审核人员的专业判断## 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)

必需数据

数据脱敏规则

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

降级策略

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

执行流程 (Workflow)

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

步骤0：数据确认（先读后写）（数据来源:user_upload, 执行主体:ai, 确认机制:none）

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

步骤1：信息提取与风险点计数（数据来源:user_upload, 执行主体:ai, 确认机制:none）

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

步骤2：行业分类精准定位（数据来源:context + references/tag-system.md, 执行主体:ai, 确认机制:none）

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

步骤3：企业标签画像填充（数据来源:user_upload + references/tag-system.md, 执行主体:ai, 确认机制:none）

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

步骤4：风险点结构化转化（数据来源:user_upload + references/scenario-rules.md, 执行主体:ai, 确认机制:none）

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

步骤5：完整性自查（数据来源:context, 执行主体:ai, 确认机制:none）

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

步骤6：格式整合输出（数据来源:context + assets/risk-extraction-report-template.md, 执行主体:ai, 确认机制:none）

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

输出格式 (Output Format)

输出为完整Markdown风险结构化提取报告，模板引用 assets/risk-extraction-report-template.md。

【企业标签画像】

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

【风险结构化分析】

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

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

报告结构：

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)

每次执行后生成审计日志：

{
  "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
  },
  "audit_log_retention": "3年"
}

踩坑记录 (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中显式引用 references/tag-system.md。

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

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

示例 (Examples)

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

用户输入：

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

企业基本情况：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：集团企业多风险点提取

用户输入：

请对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)

必需数据

数据脱敏规则

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

降级策略

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

执行流程 (Workflow)

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

📋 数据来源: user_input | 执行主体: ai | 确认机制: none

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

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

📋 数据来源: context | 执行主体: ai | 确认机制: none

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

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

📋 数据来源: context | 执行主体: ai | 确认机制: none

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

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

📋 数据来源: context | 执行主体: ai | 确认机制: none

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

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

📋 数据来源: context | 执行主体: ai | 确认机制: none

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

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

📋 数据来源: context | 执行主体: ai | 确认机制: confirm

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

步骤 6: 格式标准化输出

📋 数据来源: context | 执行主体: ai | 确认机制: none

• 严格按JSON格式输出,不包含```json标记,直接输出JSON
• 输出包含免责声明(引用 assets/disclaimer-template.md)
• 验证输出格式符合 scripts/validate_rule_output.py 脚本要求

核心约束 (Constraints)

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

审计追踪 (Audit Trail)

每次规则生成执行后,生成审计日志记录以下信息:

{
  "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,
  "audit_log_retention": "3年"
}

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

输出格式 (Output Format)

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

输出包含免责声明(引用 assets/disclaimer-template.md),确保每次输出都包含"不构成投资建议"等必要声明。

{
  "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条含具体数值阈值;查阅references/industry-benchmarks.md获取行业基准

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

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

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

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

示例 (Examples)

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

用户输入:

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

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:存量行业规则补充

用户输入:

行业名称:水产养殖
已有规则:[{"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)

必需数据

数据脱敏规则

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

降级策略

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

执行流程 (Workflow)

执行模态说明:仅标注非默认值(非默认值:数据来源≠context、执行主体≠ai、确认机制≠none)。

步骤0:数据确认与验证 [数据来源=external_search, 确认机制=none]

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

步骤1:趋势研判与驱动因素分析 [确认机制=none]

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

步骤2:信贷传导路径分析 [确认机制=none]

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

步骤3:风险信号识别 [确认机制=none]

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

步骤4:政策组合效应分析 [确认机制=none]

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

步骤5:生成结构化报告 [确认机制=none]

1. 按照“输出格式”章节的JSON Schema生成完整报告
2. 质量要求强制引用:focus_indicators必须包含4-8个核心指标;key_findings至少4-6条;risk_alerts至少2-4条
3. 输出必须包含免责声明(引用 assets/disclaimer-template.md)
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)

每次分析执行后,生成审计日志记录以下信息:

{
  "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,
  "audit_log_retention": "3年"
}

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

输出格式 (Output Format)

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

输出包含免责声明(引用 assets/disclaimer-template.md),确保每次输出都包含“不构成投资建议”等必要声明。

{
  "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": "引用 assets/disclaimer-template.md 的免责声明内容"
}

质量要求:

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个,每个节点须为可验证的中间变量;查阅references/policy-indicators.md中的传导路径模板

#3:风险预警级别混淆

• 症状:将risk_alerts的level(对信贷业务影响的紧迫程度)与企业经营风险等级混淆
• 原因:对风险分级标准理解不清,误将企业信用评级逻辑套用到政策风险分析
• 解决:明确risk_alerts.level仅反映“政策变化对信贷业务影响的紧迫程度”,不代表企业经营风险;查阅references/risk-alert-rules.md中的风险分级标准

#4:模糊描述未具体化

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

示例 (Examples)

示例1:货币政策分析

用户输入:

分析维度:货币政策
分析目标:制造业
时间范围: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:监管政策分析

用户输入:

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

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)

必需数据

数据脱敏规则

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

降级策略

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

执行流程 (Workflow)

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

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

数据来源:系统接口+用户输入 | 执行主体:ai | 确认机制:approve

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

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

数据来源:信贷系统+同业投资台账 | 执行主体:ai | 确认机制:none

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

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

数据来源:资本充足率报表 | 执行主体:ai | 确认机制:confirm

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

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

数据来源:集团客户管理模块 | 执行主体:ai | 确认机制:none

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

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

数据来源:压降措施库 | 执行主体:ai | 确认机制:approve

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

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

数据来源:行业/区域分类统计 | 执行主体:ai | 确认机制:none

1. 从行业、区域、产品、期限等维度分析集中度结构
2. 查阅 references/concentration-analysis-guide.md 获取多维分析阈值
3. 生成大额风险暴露报告(限额对照表/穿透计量明细/预警清单/压降建议)
4. 输出包含免责声明(引用 assets/disclaimer-template.md)
5. 生成审计日志(记录操作人、数据源、预警等级、压降方案)
6. ✅ 报告输出完成 → 结束

关键验证脚本化:如存在 scripts/validate_exposure.py 验证脚本,在步骤1计量完成后调用验证输出格式合规性

核心约束 (Constraints)

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

审计追踪 (Audit Trail)

每次大额风险暴露监控执行后,生成审计日志记录以下信息:

{
  "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,
  "audit_log_retention": "3年"
}

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

输出格式 (Output Format)

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

输出包含免责声明(引用 assets/disclaimer-template.md),确保每次输出都包含“不构成投资建议”等必要声明。

{
  "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辅助生成,基于公开数据和系统数据进行分析,仅供参考,不构成任何授信审批意见或风险决策依据。详见 `assets/disclaimer-template.md`。"
}

关键输出字段说明:

• 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：单一客户大额风险暴露日常监测

用户输入：

请监控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：新增授信集中度预检

用户输入：

拟对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)

执行流程 (Workflow)

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

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

步骤 1：信号识别

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

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

防偷懒指令：

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

查阅 references/cot-signal-library.md 获取完整信号类型库。

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

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

步骤 2：行业趋势验证

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

查阅 references/industry-benchmarks.md 获取行业基准数据。

查核要点：

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

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

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

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

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

📋 数据来源：reference（references/industry-benchmarks.md）

步骤 3：政策驱动力分析

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

查阅 references/policy-regulatory-framework.md 获取监管文件清单。

判断要点：

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

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

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

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

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

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

评估维度：

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

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

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

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

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

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

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

查阅 references/financial-stress-test-params.md 获取压力测试参数。

测算要素：

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

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

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

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

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

判断逻辑：

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

授信决策参考输出：

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

📋 执行主体：ai→human（AI 生成推理链 → 信审人员确认） 📋 确认机制：approve（推理链结论须人工审核确认）

输出格式 (Output Format)

逻辑思维链推导

### 逻辑思维链推导

#### 推理链

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

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

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

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

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

输出字段规范

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

合规红线 (Constraints)

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