一家汽车零部件供应商拿到整车厂5亿元应付账款、90天账期，是该去质押应收账款，还是让核心企业做反向保理，或者把订单融资+仓单融资组合用上？供应链金融5种主流方案各有适用场景，但客户经理面对具体客户时往往凭经验选一个。下面这套引擎的做法是：输入四要素，输出方案对比+推荐组合+办理流程，全程零外部依赖。
一、5种方案的边界在哪里
供应链金融（Supply Chain Finance, SCF）的主流方案分为5种，每一种都对应一个特定的"现金流痛点阶段"：
| 方案 | 解决的痛点 | 依赖核心企业 | 额度上限 | 利率下限 |
|------|-----------|------------|---------|---------|
| 应收账款质押融资 | 已开票未到账 | 仅需确认函 | 中 | 中 |
| 订单融资 | 已下单未交付 | 需采购订单 | 中低 | 中高 |
| 核心企业反向保理 | 全链条降本 | 主功臣 | 高 | 低 |
| 供应链票据 | 多级信用穿透 | 票据开立人 | 高 | 低 |
| 仓单融资 | 已备货未开票 | 不依赖 | 低 | 高 |
可以看到，5种方案从"应收账款质押"到"反向保理"再到"仓单融资"，覆盖了供应链从下单→发货→开票→到期付款的完整生命周期。但客户经理拿到一个具体客户时，最常遇到的问题是：这家核心企业应付账款5个亿，到底推哪个方案？
financial-ai-skills仓库的supply_chain_finance模块给出的答案不是一个推荐，而是一组规则化对比+一个智能推荐引擎。
二、规模系数scale：一个0.6到1.5的数字如何撬动5种方案
这套引擎最精巧的设计是一个叫scale_factor的函数。它做的事情很简单：根据应付账款规模（万元），返回一个0.6~1.5之间的系数。
def _scale_factor(self, ap: float) -> float:
"""根据应付账款规模确定规模系数"""
if ap >= 100000: # 10亿+
return 1.5
elif ap >= 10000: # 1亿+
return 1.2
elif ap >= 1000: # 1000万+
return 1.0
elif ap >= 100: # 100万+
return 0.8
else:
return 0.6
这个系数看似简单，但它同时影响5种方案的两个关键维度：
**第一维：额度放大**。每一种方案的额度公式都乘以scale。以反向保理为例：
quota_range=f"{min(ap * 0.8, 150000) * scale:.0f}～{min(ap * 1.0, 200000) * scale:.0f} 万元"
应付账款5亿（50000万元）、scale=1.2时，反向保理额度=48000~60000万元。同样是反向保理，应付账款5000万、scale=0.8时，额度只有3200~4000万元。额度直接放大15倍，比单纯按应付账款比例计算更激进——这正是核心企业规模优势的体现。
**第二维：利率微调**。利率公式是3.2 + (8 - scale) * 0.2（反向保理）：
| scale | 应付规模 | 反向保理利率下限 | 反向保理利率上限 |
|-------|---------|----------------|----------------|
| 1.5 | 10亿+ | 4.50% | 6.10% |
| 1.2 | 1亿~10亿 | 4.56% | 6.16% |
| 1.0 | 1000万~1亿 | 4.60% | 6.20% |
| 0.8 | 100万~1000万 | 4.64% | 6.24% |
| 0.6 | <100万 | 4.68% | 6.28% |
注意一个细节：利率差异只有10~20个BP（基点），但额度差异是数量级的。这不是设计缺陷，而是复刻真实银行授信逻辑：核心不在于"大企业利率低到哪去"，而在于"大企业能放大授信额度"。利率断崖式跳变会触发合规审查，scale通过细微利率调整+大幅额度放大的组合，既保留了差异化定价，又规避了利率歧视风险。
5种方案的(8 - scale) * X系数也各有不同：
| 方案 | 利率系数 | scale=1.5→0.6的利率跨度 |
|------|---------|------------------------|
| 反向保理 | 0.2 | 4.50%~6.10% / 4.68%~6.28% |
| 供应链票据 | 0.2 | 与反向保理同档 |
| 应收账款质押 | 0.3 | 利率随规模波动更敏感 |
| 订单融资 | 0.3 | 同上 |
| 仓单融资 | 0.3 | 同上 |
反向保理和供应链票据的0.2系数表明：核心企业深度参与的方案，利率对规模更不敏感——因为核心企业信用本身就是定价锚，规模只是放大器。而仓单融资这种不依赖核心企业信用的方案，系数是0.3，利率随规模波动更大，反映了"无核心信用背书时需要更精细的风险定价"。
三、推荐规则：5亿是个分水岭
_build_summary函数的推荐逻辑只有3行，但恰到好处：
if ap >= 50000: # 5亿以上
recommended = ["反向保理", "供应链票据"]
elif ap >= 10000: # 1亿以上
recommended = ["反向保理", "应收账款质押融资", "供应链票据"]
else:
recommended = ["应收账款质押融资", "订单融资", "仓单融资"]
3档分水岭背后的产品逻辑：
**5亿+**：应付账款体量足够大，核心企业一定有动力做确权（否则资金成本太高），反向保理+供应链票据这对组合覆盖了"信用穿透+标准化结算"两个场景，不需要推应收账款质押——因为质押要多方确认函，操作成本高，5亿+客户用得起反向保理就没必要退而求其次。
**1亿~5亿**：开始出现"核心企业配合度不确定"的情况。三方案并列：反向保理是首选，应收账款质押是"核心不愿主动确权时"的退路，供应链票据是"已经开过商票想流转"的延续选项。
**<1亿**：核心企业可能根本不愿意做反向保理的IT投入，直接退回应收账款质押+订单融资+仓单融资三件套，让供应商自己挑。
这套规则最大的价值不在于推荐本身，而在于显式表达"为什么不推荐某方案"。客户经理面对5亿应付账款客户推反向保理，被问"为什么不推应收账款质押"，可以引用规则回答："5亿+档不上应收账款质押，原因是确权成本与方案收益不匹配"。把经验变成可解释的规则，是供应链金融产品数字化的关键一步。
四、parse_input：5套正则搞定自然语言输入
引擎的入口是一个parse_input函数，把自然语言转成SCFProfile结构体。没用任何NLP模型，纯靠5套正则+几条启发式规则，毫秒级响应。
def parse_input(text: str) -> SCFProfile:
# 1. 应付账款规模（支持亿/万/元三单位换算）
ap_match = re.search(r'应付账款\s*([\d.]+)\s*(亿|万|元)', text)
# 2. 账期（默认90天）
term_match = re.search(r'账期\s*(\d+)\s*天', text)
# 3. 供应商类型
supplier_match = re.search(r'供应商类型?\s*[:：]?\s*(\S+)', text)
# 4. 核心企业（显式标注优先）
core_match = re.search(r'核心企业\s*[:：]?\s*(\S+)', text)
# 5. 兜底：行业关键词触发
if '汽车' in text:
enterprise = "汽车整车厂"
elif '电子' in text:
enterprise = "电子核心企业"
为什么不用LLM？三个原因：
**第一，可解释性**。客户经理输入"应付账款5亿"被解析成50000万元，过程完全可追溯。用LLM解析就有"为什么是5亿不是50亿"的黑盒争议。
**第二，响应速度**。正则解析毫秒级，LLM至少500ms以上。客户经理查询高频，每秒延迟都影响体验。
**第三，部署成本**。正则零依赖，pip install都不需要。LLM要部署模型或买API。供应链金融场景输入结构高度规整（核心企业+供应商类型+应付账款+账期），不值得为这种结构化输入上LLM。
行业识别则用一个8行业关键词词典做兜底：
self._industry_keywords = {
"汽车": ["汽车", "整车", "车企", "车厂", "汽配", "零部件"],
"电子": ["电子", "半导体", "芯片", "面板", "消费电子", "手机"],
"医药": ["医药", "制药", "医疗", "器械", "药店", "医院"],
"家电": ["家电", "电器", "空调", "冰箱", "洗衣机", "彩电"],
"食品": ["食品", "饮料", "乳业", "酒类", "餐饮", "调味品"],
"纺织": ["纺织", "服装", "面料", "印染", "制衣"],
"建材": ["建材", "水泥", "钢材", "木材", "家居"],
"能源": ["能源", "电力", "光伏", "风电", "电池", "储能"],
}
字典不大，但覆盖了供应链金融主力行业的80%以上场景。匹配失败时退回"通用制造"，让后续方案依然能跑——容错性比覆盖度更重要。
五、5亿新能源汽车案例完整跑通
输入一句话：
供应链金融 某新能源汽车整车厂 应付账款5亿 账期90天
parse_input解析出的SCFProfile：
核心企业：某新能源汽车整车厂
应付账款：50000.0万元
账期：90天
_detect_industry扫描关键词命中"汽车"（"整车厂"中包含"车"字）。行业推断为汽车。
_scale_factor(50000)：50000 ≥ 10000 且 < 100000，返回1.2。
_build_summary：50000 ≥ 50000，命中第一档，推荐反向保理 + 供应链票据。
反向保理实际额度算式：
下限：min(50000 * 0.8, 150000) * 1.2 = 40000 * 1.2 = 48000万元
上限：min(50000 * 1.0, 200000) * 1.2 = 50000 * 1.2 = 60000万元
利率下限：3.2 + (8 - 1.2) * 0.2 = 4.56%
利率上限：4.8 + (8 - 1.2) * 0.2 = 6.16%
供应商拿到的是一份包含5方案对比、办理流程7步、推荐组合+行动建议的完整报告。整条链路从输入到输出，毫秒级响应，零API调用，零外部依赖。
如果换成应付账款5000万（5000万元，scale=0.8）：
| 维度 | 5亿案例 | 5000万案例 | 差异倍数 |
|------|---------|-----------|---------|
| 反向保理额度下限 | 48000万 | 3200万 | 15x |
| 反向保理额度上限 | 60000万 | 4000万 | 15x |
| 反向保理利率下限 | 4.56% | 4.64% | -8BP |
| 反向保理利率上限 | 6.16% | 6.24% | -8BP |
| 推荐方案 | 反向保理+供应链票据 | 应收质押+订单+仓单 | 完全不同 |
注意最后一行：5000万应付账款的推荐方案完全切换到了另一组——因为小于1亿档不上反向保理。这就是规则化引擎的价值：同一套逻辑在不同规模下自适应切换，客户经理不需要记5种方案什么时候用，规则自动决定。
六、设计启示
**scale是个杠杆，不是个开关**。0.6~1.5之间连续可变的系数，比"大/中/小"三档离散分类更精准。金融产品定价最忌讳档位跳变，scale用连续函数平滑过渡，规避了合规审查中的利率歧视问题。
**推荐规则要显式表达"为什么不推荐"**。客户经理需要的不是"推荐反向保理"，而是"为什么不推荐应收账款质押"——这种排除式逻辑才是产品规则的真正价值。3档推荐规则背后隐藏着5种方案的两两排除关系，规则化引擎把这种隐性经验变成了显式代码。
**正则解析+词典兜底足够覆盖80%场景**。供应链金融的输入结构规整，不值得上LLM。把LLM留给真正非结构化的场景（如客户自然语言咨询），让规则处理规则能处理的事，是工程效能最大化的关键。
快速上手
git clone github.com/yuzhaopeng-up/financial-ai-skills.git
cd financial-ai-skills/skills-phase2/supply_chain_finance
python scf_engine.py generate "供应链金融 某新能源汽车整车厂 应付账款5亿 账期90天"
from scf_engine import SCFEngine, parse_input
profile = parse_input("供应链金融 某新能源汽车整车厂 应付账款5亿 账期90天")
engine = SCFEngine()
result = engine.generate(profile)
# 三种输出形态：Markdown报告 / JSON / 企微卡片
print(engine.format_markdown(result)) # 给客户经理看
print(engine.format_json(result)) # 给系统对接
print(engine.format_wecom_card(result)) # 给企微群推送
完整源码不到500行，零外部依赖，copy到任何Python项目都能直接跑。
---
如果你在做供应链金融产品，或者想把5种SCF方案的选型逻辑规则化，这500行源码是个直接的起点。比起从零写一个推荐引擎，复用经过实战验证的规则集，能让你的产品早上线两周。
更多金融AI技能见 financial-ai-skills 仓库(github.com/yuzhaopeng-up/financial-ai-skills)。
