Credit Industry Rule Gen

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

目标角色 (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或联系风控团队