一、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之间的系数。
``python 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。以反向保理为例：
`python 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行，但恰到好处：
`python 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套正则+几条启发式规则，毫秒级响应。
`python 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行业关键词词典做兜底：
`python self._industry_keywords = { "汽车": ["汽车", "整车", "车企", "车厂", "汽配", "零部件"], "电子": ["电子", "半导体", "芯片", "面板", "消费电子", "手机"], "医药": ["医药", "制药", "医疗", "器械", "药店", "医院"], "家电": ["家电", "电器", "空调", "冰箱", "洗衣机", "彩电"], "食品": ["食品", "饮料", "乳业", "酒类", "餐饮", "调味品"], "纺织": ["纺织", "服装", "面料", "印染", "制衣"], "建材": ["建材", "水泥", "钢材", "木材", "家居"], "能源": ["能源", "电力", "光伏", "风电", "电池", "储能"], } `
字典不大，但覆盖了供应链金融主力行业的80%以上场景。匹配失败时退回"通用制造"，让后续方案依然能跑------容错性比覆盖度更重要。
五、企微卡片：从Markdown报告到一行回复指令
整套引擎还有个容易被忽视但很关键的设计：format_wecom_card输出的是企微markdown卡片，而不是完整报告。
`python def format_wecom_card(self, result: dict) -> dict: return { "msgtype": "markdown", "markdown": { "content": ( f"### 🏦 供应链金融方案报告\n\n" f"核心企业 ：{p['core_enterprise']}\n" f"应付账款 ：{p['accounts_payable_yi']:.1f}亿 | 账期 ：{p['payment_term_days']}天\n" f"行业 ：{p['detected_industry']} | 供应商 ：{p['supplier_type']}\n\n" f"### ✅ 推荐方案\n\n" + "\n".join(f"- {r}" for r in summ['recommended_names']) + f"\n\n" f"> 💡 回复【详细】获取完整方案对比及办理流程" ) } } `
卡片信息密度有限：核心企业+应付账款+账期+行业+推荐方案，最多5个字段。详细方案对比表不直接发，需要客户经理回复"详细"才推送完整Markdown报告。
这个设计源于企微的实际使用场景：客户经理在群里推送方案时，老板第一眼只想看到"推荐了哪几个方案、规模多大"，多了一屏刷不完。回复"详细"才触发的二级分发，既保留了完整信息可达性，又控制了消息噪音。如果是直接用format_markdown推完整报告到群里，5种方案的对比表+办理流程表加起来几十行，老板大概率会直接跳过。
这种"卡片摘要+指令触发完整内容"的双形态分发，是金融场景里企微消息设计的标配。比起一股脑塞所有信息，让用户主动索取反而转化率更高。
六、5亿新能源汽车案例完整跑通
输入一句话：
`供应链金融 某新能源汽车整车厂 应付账款5亿 账期90天`
parse_input解析出的SCFProfile：
`python SCFProfile( core_enterprise="某新能源汽车整车厂", supplier_type="某新能源汽车整车厂", # 兜底逻辑会自动修正 accounts_payable=50000.0, # 万元 payment_term_days=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万 | 15× | | 反向保理额度上限 | 60000万 | 4000万 | 15× | | 反向保理利率下限 | 4.56% | 4.64% | -8BP | | 反向保理利率上限 | 6.16% | 6.24% | -8BP | | 推荐方案 | 反向保理+供应链票据 | 应收质押+订单+仓单 | 完全不同 |
注意最后一行：5000万应付账款的推荐方案完全切换 到了另一组------因为小于1亿档不上反向保理。这就是规则化引擎的价值：同一套逻辑在不同规模下自适应切换，client manager不需要记5种方案什么时候用，规则自动决定。
七、设计启示
scale是个杠杆，不是个开关。0.6~1.5之间连续可变的系数，比"大/中/小"三档离散分类更精准。金融产品定价最忌讳档位跳变，scale用连续函数平滑过渡，规避了合规审查中的利率歧视问题。
推荐规则要显式表达"为什么不推荐"。客户经理需要的不是"推荐反向保理"，而是"为什么不推荐应收账款质押"------这种排除式逻辑才是产品规则的真正价值。3档推荐规则背后隐藏着5种方案的两两排除关系，规则化引擎把这种隐性经验变成了显式代码。
双形态输出比单一报告更实战。企微卡片做摘要触发，完整Markdown做详细查询。在消息渠道碎片化的金融场景里，"卡片+指令"的双层分发是消息设计的基本功。
正则解析+词典兜底足够覆盖80%场景。供应链金融的输入结构规整，不值得上LLM。把LLM留给真正非结构化的场景（如客户自然语言咨询），让规则处理规则能处理的事，是工程效能最大化的关键。
快速上手
`bash git clone https://github.com/yuzhaopeng-up/financial-ai-skills.git cd financial-ai-skills/skills-phase2/supply_chain_finance python scf_engine.py generate "供应链金融 某新能源汽车整车厂 应付账款5亿 账期90天" `
`python 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项目都能直接跑。
Agent Skills开源生态
| 仓库 | 定位 | GitHub | |------|------|--------| | teleagent-skills | 5个通用业务Skill：4-Phase编排+规则参数化 | https://github.com/yuzhaopeng-up/teleagent-skills | | agent-cluster-comm | 多Agent集群5层通信架构 | https://github.com/yuzhaopeng-up/agent-cluster-comm | | skill-framework | Skill治理框架：L0-L4分类+YAML模板 | https://github.com/yuzhaopeng-up/skill-framework | | fintech-h5-demos | 57个零依赖金融H5演示 | https://github.com/yuzhaopeng-up/fintech-h5-demos | | soe-compliant-office | 17个央国企合规办公Skill | https://github.com/yuzhaopeng-up/soe-compliant-office | | regulated-rag | 零依赖RAG工具包：BM25+TF-IDF+RRF | https://github.com/yuzhaopeng-up/regulated-rag | | agent-ops-toolkit | 企业级Agent运维基础设施：降级+告警+工作流 | https://github.com/yuzhaopeng-up/agent-ops-toolkit | | financial-ai-skills | 金融AI技能库：104个场景纯Python实现（含本文SCF引擎） | https://github.com/yuzhaopeng-up/financial-ai-skills |
如果你在做供应链金融产品，或者想把5种SCF方案的选型逻辑规则化，这500行源码是个直接的起点。比起从零写一个推荐引擎，复用经过实战验证的规则集，能让你的产品早上线两周。 ---
> 觉得有用？给个 Star 支持一下！你的 Star 是我们持续开源的最大动力。
> 更多开源 Agent Skills：financial-ai-skills · teleagent-skills · regulated-rag · fintech-h5-demos ------ 全部在 github.com/yuzhaopeng-up，欢迎 Star/Fork/PR！