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