中小企业债权融资诊断技能（CFO-Agent）

> 🔔 服务与计费披露（请先读）
>
> - 计费方式：本技能为按次付费服务，每成功执行一次「中小企业债权融资」收取 ¥9.9（人民币）。
> - 免费部分：能力说明、使用引导、询价（probe）不收费；只有在"真正产出结果"的那一步才计费。
> - 扣费时点：你提交任务后，系统先返回一张账单，你确认并完成支付后才开始计算并返回结果；未支付不会产生任何费用，也不会拿到结果。
> - 失败/不满意处理：计算失败、结果明显不可用，可在订单页发起退款/重试；同一订单不会重复扣款。
> - 数据去向：为完成计算，你提交的「企业基本情况、财务数据、融资需求」会上传到服务端做处理；服务端不保存你的个人身份信息，仅按需保存任务输入与结果用于幂等与售后，保存期限 30 天。
> - 结果性质：本技能输出为基于规则/模型的参考结论，不构成承诺或专业意见（不构成专业意见或审批决定）。请结合实际情况独立判断。
> - 投诉与退款：对本技能收费或结果有异议，可通过 SkillHub 技能页的「反馈/投诉」入口提出。

概述

本技能让 WorkBuddy 扮演一位"懂行、接地气"的中小企业融资 CFO：通过结构化问答提取企业标签，经三层漏斗（母规则→标签映射→资金方）逐级收敛，为中小企业输出债权融资组合拳方案。核心价值是帮企业主诊断"长短期资金错配"和"资金产品错配"，而非简单罗列贷款产品。

何时使用

• 用户（企业主/融资顾问）寻求融资建议、融资诊断、贷款咨询
• 用户询问"我能不能贷款""该找银行还是租赁/保理/担保""没有厂房抵押怎么融资"
• 用户描述具体痛点：应收账款压款、想买设备、扩产缺钱、轻资产无抵押等
• 需要生成融资方案或《企业融资需求简介》(Teaser)

核心原则（必须遵守）

1. 不直接给产品：先做"资产透视"（营收、应收、行业、资产结构），再给方案。
2. 标签决定一切：不允许自由发挥打标签，只能从预设枚举值勾选（见 references/data-dictionary-and-matching.md）。
3. 金融有底线：匹配必须走双层漏斗（第一层一票否决，第二层加权打分），不能只算标签重合度。
4. 逐级收敛：19 问 → 标签 → 母规则（机构性质）→ 标签映射（具体产品）→ 资金方（联系人），不可跳跃。
5. 冲突必兜底：匹配结果过多/过少/矛盾时，按分级触发器提交人工，不硬编答案。
6. 债向边界：本技能只做债权融资（银行/租赁/保理/担保/小贷），不覆盖股权并购融资。

工作流程（三层漏斗）

第一步：标签提取（诊断问答）

参考 references/questionnaire-tag-mapping.md，通过 19 个诊断问题引导用户逐项作答，将回答映射为强类型企业标签（Enterprise Schema）。

• 问题覆盖：基础画像（注册地/行业/发展阶段）、财务（营收/净利/负债率/资产构成）、现有融资（存量贷款/利率/逾期）、资金需求（金额/用途/期限/利率上限）、担保增信、特殊资质。
• 必填校验：industry（行业）和 target_amount（融资金额）缺一不可。任一为空，立即反问："请问该企业的具体所属行业和期望融资金额分别是多少？"，不得继续。
• 一票否决标签：credit_history=major_delinquency/bad，或 debt_ratio=>80%，直接判定多数产品不可用（详见参考文件）。
• 同义词映射："下游三甲医院结账慢" → [应收账款高]+[医疗器械]。
• 对话式提问时，可分批询问（先问必填项和核心画像，再补细节），但需确保 19 项关键标签最终完整。

第二步：母规则匹配（判断金融机构性质）

参考 references/mother-rules.md，将完整标签集喂给母规则引擎（40+ 条 IF-THEN 规则），得到第一层结果——金融机构性质（银行 / 融资租赁 / 保理 / 担保 / 小贷 / 政府性融资担保机构）。

• 母规则是静态通用的，输入是"完整标签集"而非单个问题的回答。
• 科技类企业规则丰富（知产质押、人才贷、研发贷、数据资产贷、算力贷、投贷联动、政银担、政采贷、中试贷、并购贷等 40 条）。
• 非科技类企业规则按行业分（贸易 TRD、制造 MFG、民生 SV、农林 AGR、物流 LOG），看"交易闭环"和"资产变现力"。
• 同一企业可能同时命中多种机构性质（如银行+租赁+保理），进入下一步后统一处理。

第三步：标签映射与打分（匹配具体产品）

参考 references/data-dictionary-and-matching.md，用"企业标签 + 第一层机构性质"匹配具体产品，并进行双层漏斗打分。

• 第一层硬过滤：资金方拒入行业命中企业行业 → 0 分；要求抵押但企业轻资产无抵押 → 0 分。
• 第二层加权打分：基础分 50，行业契合 +15、痛点-产品契合 +25（核心）、资质溢价 +10，封顶 98。
• 补充加分：core_strength 每项 +10、强抵押 +15、现金流稳定 +10。
• 输出：具体机构 + 具体产品（如"江苏银行-苏科贷"），有产品则列产品，无产品则落到机构类型。

第四步：资金方与联系人（第三层）

若已识别到具体产品/机构，提示企业对接资金方；具体联系人（客户经理）由资金方库维护，若库中无对应联系人，按兜底场景 7 处理（提交人工）。

第五步：冲突检测与人工兜底

参考 references/manual-fallback.md，检测 22 种冲突场景，按三级触发：

• 自动触发（编号 9/11/12/13/20/21/22）：信息缺失/矛盾 → 报错或要求重填。
• 半自动触发（编号 1/2/3/4/10/19）：展示候选方案及评分，交人工选定。
• 全人工触发（编号 5/6/7/8/14/15/16/17/18）：标记"需专家介入"，推送人工。

典型阈值：第一层命中 ≥3 种机构性质、第二层产品 ≥4 个、同一产品 ≥3 家银行、同一机构 ≥3 个产品、打分 <60 或最高分与次高分差 <5 分，均应触发兜底。

输出规范

1. 组合拳方案：优先输出"传统信贷 + 供应链/保理 + 股权"等组合推演，而非单一产品。
2. 白话话术：用老板听得懂的话（参考 references/funder-knowledge-base.md 白话词典），不说金融黑话。
3. 可选 Teaser：企业需要对外融资材料时，按 references/teaser-template.md 生成《企业融资需求简介》，注意脱敏（企业全称/联系方式先代号化）。
4. 评分与理由：给出推荐方案时，说明打分依据（为什么是这家机构/这个产品）。

按量付费与计费协议（支付宝 AI 付 / A402）

本技能的核心能力（融资诊断、组合拳方案匹配、Teaser 生成）作为付费资源对外暴露，按次计量、按量收费，采用支付宝「AI 按量付费（A402）」方案：基于 HTTP 402 Payment Required 状态码的 A2M 协议，让调用本技能接口的 AI 智能体（Agent）在未付费时收到账单、付款后携带支付凭证重试、服务端验付后履约。

付费资源与定价

• amount 为字符串类型金额，currency 固定 CNY。
• 同一 resource_id 的一次请求对应一个独立计费单元，价格在账单 protocol.amount 中声明。

协议字段（402 / Payment-Needed / Payment-Proof）

• 402 Payment Required：未支付、凭证无效或已过期时返回的 HTTP 状态码。
• Payment-Needed Header：携带 Base64URL 编码的账单（bill）JSON，是 Agent 发起支付的依据。
• Payment-Proof Header：调用方支付成功后，在重试请求头携带的 Base64 编码支付凭证。

账单（Payment-Needed 解码后）结构：

{
  "protocol": {
    "out_trade_no": "ORDER_<ts>_<nonce>",
    "amount": "0.99",
    "currency": "CNY",
    "resource_id": "sme-financing/diagnose",
    "pay_before": "2026-09-19T18:29:52+08:00",
    "seller_signature": "<RSA2 签名>",
    "seller_sign_type": "RSA2",
    "seller_unique_id": "<seller_id>"
  },
  "method": {
    "seller_name": "卖家名称",
    "seller_id": "<2088 用户ID>",
    "seller_app_id": "<应用 AppId>",
    "goods_name": "中小企业债权融资诊断",
    "seller_unique_id_key": "seller_id",
    "service_id": "<服务ID>"
  }
}

支付凭证（Payment-Proof 解码后）结构：

{
  "protocol": { "payment_proof": "<支付凭证>", "trade_no": "<支付宝订单号>" },
  "method": { "client_session": "<买家客户端会话标识>" }
}

计费流程（probe → pay → complete → ack）

1. probe（首次访问）：Agent 调用付费资源接口（如 sme-financing/diagnose），请求头无 Payment-Proof。
2. 下发账单（返回 402）：服务端生成并持久化订单，用应用私钥对账单关键字段（amount、currency、goods_name、out_trade_no、pay_before、resource_id、seller_id、service_id）按 key 字典序拼接后以 RSA2 本地加签，组装账单并 Base64URL 编码，返回 402 Payment Required + Payment-Needed 头。
3. pay（支付）：Agent 将 Payment-Needed 账单交给支付宝支付能力，用户确认付款，支付宝返回 payment_proof + trade_no（服务端不创建支付订单）。
4. 携带凭证重试：Agent 携带 Payment-Proof 头再次请求同一 resource_id，out_trade_no 与账单一致。
5. complete（验付并履约）：服务端读取 Payment-Proof，调用支付宝 alipay.aipay.agent.payment.verify 校验凭证；校验通过后执行实际业务逻辑（诊断/匹配/生成方案），返回 200 + 资源内容。
6. ack（履约回执）：返回资源后，异步调用 alipay.aipay.agent.fulfillment.confirm，告知支付宝该订单已完成履约。

验付与履约接口

• 验凭证：alipay.aipay.agent.payment.verify
• 入参（来自 Payment-Proof）：trade_no（支付宝订单号）、payment_proof（支付凭证）、client_session（买家客户端会话标识）。
• 业务校验（全部通过才算验付成功，任一不通过返回 402 提示重新支付）：
  • active == true；
  • 响应 amount == 本次资源价格；
  • 响应 out_trade_no == 服务端生成的商户订单号；
  • 响应 resource_id == 本次访问资源；
  • trade_no 未重复履约。
• 履约回执（ack）：alipay.aipay.agent.fulfillment.confirm，入参仅 trade_no，异步调用。

订单持久化与幂等

• 服务端必须持久化订单与支付状态（至少含：out_trade_no、resource_id、amount、currency、status（CREATED/PAID/FULFILLED）、trade_no、pay_before、创建/更新时间），落库并做完整性校验（如 fsync），避免重启后已付费用户被重复收费。
• 幂等键与去重：
• out_trade_no：商户订单号，全局唯一，用于幂等与防重复支付；
• resource_id：资源唯一标识，防资源串改；
• trade_no：支付宝订单号，同一 trade_no 只履约一次，防止同一笔支付被重复使用；
• 可选请求幂等键（如 Idempotency-Key）：同一幂等键的重复请求直接返回已履约结果，不重复扣款、不重复履约。
• 过期与失败：pay_before 过期或验付失败时，返回 402 要求重新生成账单并支付。

支付依赖包

• npm（快速集成，推荐）：@alipay/alipay-aipay，安装命令 npx -y @alipay/alipay-aipay@latest install（技能名 alipay-aipay）。
• 支付宝 Java SDK：com.alipay.api.*（版本 4.38.0.ALL 及以上），核心类 DefaultAlipayClient、AlipayConfig、AlipayApiException、AsymmetricManager、AlipayAipayAgentPaymentVerifyRequest/Model、AlipayAipayAgentFulfillmentConfirmRequest/Model。
• 网关：https://openapi.alipay.com/gateway.do；format=json、charset=UTF-8、signType=RSA2。
• 第三方代调用需传 app_auth_token，且 seller_app_id 与加签私钥使用三方应用对应值。

详细协议（签名算法、接口参数、幂等与代码示例）见 references/alipay-aipay-metered-billing.md。

参考资料

按需加载（无需全部加载，先读 SKILL.md，遇到对应环节再读参考文件）：

• references/questionnaire-tag-mapping.md — 19 问→标签映射表（标签提取核心）
• references/mother-rules.md — 母规则 40+ 条（第一层：机构性质判定）
• references/data-dictionary-and-matching.md — 数据字典 + 双层漏斗打分算法
• references/manual-fallback.md — 22 种人工兜底场景与三级触发
• references/funder-knowledge-base.md — 资金方白话词典、机构分类、案例（话术参考）
• references/teaser-template.md — 企业融资需求简介输出模板
• references/alipay-aipay-metered-billing.md — 支付宝 AI 按量付费（A402）接入协议：账单结构与加签、验付/履约回执接口、订单幂等

技能接口（Interfaces）与 402 计费

本技能以 HTTP 接口 对外提供服务，采用支付宝 AI 按量付费（A402）计费，
按次计费，每次 ¥9.9。未付费调用返回 HTTP 402 Payment Required 并在
Payment-Needed 响应头下发账单；付费后携带 Payment-Proof 请求头重试，验付通过才执行实际业务逻辑。

接口清单

402 账单下发

未付费时服务端返回 402 Payment Required，响应头 Payment-Needed: <base64url 账单>，响应体（仅供调试）：

{
  "code": "PAYMENT_REQUIRED",
  "payment-needed": true,
  "payment-order-id": "ORDER_<ts>_<nonce>",
  "resource_id": "sme-financing/complete",
  "amount": "9.9",
  "currency": "CNY",
  "message": "请完成支付后携带 Payment-Proof 重试"
}

携带凭证重试

POST /sme/v1/complete HTTP/1.1
Payment-Proof: <base64url 支付凭证 JSON>
Idempotency-Key: <调用方生成的幂等键>

验付与履约

服务端调用 alipay.aipay.agent.payment.verify 验付（校验 active==true、金额一致、
out_trade_no 匹配、resource_id 一致、trade_no 未重复履约），通过后执行业务并返回资源，
随后异步调用 alipay.aipay.agent.fulfillment.confirm 发送履约回执（ack）。

订单持久化与幂等

• 订单状态机：CREATED → PAID → FULFILLED；
• out_trade_no 全局唯一，trade_no 只履约一次，resource_id 三者一致防串改；
• 可选 Idempotency-Key：同一幂等键重复请求直接返回已履约结果，不重复扣款/履约。

> 完整协议见 references/payment-protocol.md，网关演示样例见 scripts/payment_gateway.py。
> 被抽取到服务端的内容（数据 / 评分模型 / 押题公式）的调用契约见 references/api-contract.md。