供应链诊断器

把分散在四张表里的信息（BOM、库存、供应商、产能/订单）合成一次诊断，输出三份固定格式的报告。
所有数字由脚本算出，公式在报告里显式写出，可逐条复算。

核心能力：BOM 校验 → 物料需求展开（MRP）→ 缺料分级 → 供应商风险评分 → 工序负荷与瓶颈定位 → 双方案排程。

工作流程

第一步：确认数据来源（四张表，缺一张就少一份报告）

先确认这四类数据在哪、是什么格式：

有 Excel 先另存为 CSV (UTF-8)。字段结构见 references/input-contract.md。

示例数据已随技能提供，跑一遍就知道报告长什么样：

python scripts/sc_diagnose.py --as-of 2026-09-28 --outdir out

第二步：确认判定口径（这一步不能省）

跑之前先和用户对齐四项，否则报告出来后口径不一致会返工：

第三步：运行诊断

# 标准跑法
python scripts/sc_diagnose.py --as-of 2026-09-28 --data-dir data --outdir out

# 换成自己的数据
python scripts/sc_diagnose.py --as-of 2026-11-01 --data-dir 我的数据 --outdir 报告

# 调整外协成本参数（影响方案 A 的增量成本）
python scripts/sc_diagnose.py --as-of 2026-09-28 --outsource-price 18 --insource-cost 6.5

# 调整方案 B 的延期天数（默认 15 天）
# 直接改脚本里的 shift_days，或先跑默认值再手工换算

Windows 下若 python 不在 PATH，用完整路径或 py 代替。

脚本会打印一段控制台摘要（问题数、风险分布、瓶颈负荷率、交期达成率），并写出四份 Markdown。

第四步：资质部分不要重写，直接调已有技能

供应商资质有效期的追踪已经有专门技能 supplier-qualification-tracker。
本技能只负责在风险评分里用它的结论（资质剩余天数），不重复实现：

python "<skills>/supplier-qualification-tracker/scripts/check_qualifications.py" \
    data/supplier_qualifications.csv --as-of 2026-09-28 --md out/02b_供应商资质台账.md

注意：不加 --json。用户明确要求不输出 JSON，只出 Markdown。

第五步：解读与行动（不要只丢报告）

三份报告出来后按这个顺序讲：

1. BOM 校验：先说"重复行"和"层级错位"——这两类会让 MRP 算错数，是根因；物料主数据缺失是台账问题，单独说。
2. 缺料预警：先看高危（会断线），再看中危。高危项按"净需求 × 提前期"排序讲，不按数量排序——数量小但提前期长的更致命。
3. 供应商风险：讲清总分是怎么来的。特别注意"资质过期导致等级跳档"的情况——这是资质与缺料两套独立信号叠加的结果，是最容易被忽略的。
4. 排程：先给瓶颈和硬缺口，再给双方案，最后一定要说清为什么方案 B 的达成率可能不提升——产能硬缺口不投钱就只能延，不要美化。
5. 每条建议落到「谁、做什么、什么时候」。

第六步：输出报告

供应商合规信息属敏感信息，报告含证书编号、发证机构等可识别信息，提醒用户不要外发到公开渠道。

判定规则（脚本内实现，报告里显式写出）

BOM 校验七项

物料展开（MRP）

本级数量 = 上级数量 × 单位用量 × (1 + 损耗率)

• 从顶层成品逐层往下推，损耗逐层累乘。
• 同替代组内 alt_rank ≥ 2 为备选，不计入毛需求，只在主选断料时启用。
• 浮点累加后向上取整；报告同时给出"原始需求"和"去重修正需求"两列，方便一眼看出重复行的影响。

缺料分级

净需求     = 毛需求（去重后向上取整） − 现有库存 − 在途
建议采购量 = 净需求 ÷ MOQ 向上取整 × MOQ
可用日期   = 基准日期 + 采购提前期

两个容易做错的地方：

1. MOQ 必须向上取整——算出"买 3 个"实际得买 100 个，不取整的采购量是废的。
2. 安全库存不计入可用量，只作为二级预警信号。动用安全库存本身就是风险，不该被当成"有货"。

供应商风险评分

风险总分 = 准交率扣分 + 资质扣分 + 单一来源扣分 + 缺料影响扣分

准交率       ≥95% → 0 ｜ 90-94.9% → 1 ｜ 85-89.9% → 2 ｜ <85% → 3
资质有效期   >180天 → 0 ｜ 91-180天 → 1 ｜ 31-90天 → 2 ｜ ≤30天或已过期 → 3
单一来源     所供物料含关键件且仅此一家 → +2
缺料影响     该供应商所供物料的最高缺料等级：高 +3 ｜ 中 +2 ｜ 低 +0

风险等级     总分 ≥6 → 高 ｜ 3-5 → 中 ｜ 0-2 → 低

设计要点：资质和缺料是两套独立信号，叠加才升等级。 一个交付一直很准的供应商，可能因为一张证书过期直接从"中"跳到"高"——这个跳档要主动跟用户点出来。

排程与瓶颈

某工序需求工时 = 累计订单量 × 单件工时 ÷ 良率
某工序可用工时 = 设备数 × 每日可用工时 × 计划天数
负荷率         = 需求工时 ÷ 可用工时 × 100%
瓶颈工序       = 负荷率最高的工序；若 > 100% 即产能硬缺口
交期达成率     = 按原交期可完整交付的订单数 ÷ 总订单数

• 累计口径按交期顺序逐单叠加，越靠后的订单承担越大累计负荷。
• 计划天数按自然日计（每日可用工时已含班次，不做周末扣减）。
• 算"还能交多少台"必须用 int() 向下取整，用 ceil 会算出超过可用工时的台数。

字段说明

见 references/input-contract.md。核心是四组：

• BOM：parent_code / child_code / qty / unit / level / loss_rate / is_key / alt_group / alt_rank / make_or_buy
• 库存：item_code / make_or_buy / on_hand / in_transit / safety_stock / moq / lead_time_days / unit_price
• 供应商：item_code / supplier_id / supplier_name / promised_days / otif_rate / cert_name / cert_expiry
• 产能 / 订单：op_code / machine_count / cycle_min / hours_per_day / yield_rate ｜ order_no / item_code / qty / due_date / priority

make_or_buy：M = 自制件（不参与采购缺料，交由排程消化），B = 采购件。

注意事项

1. --as-of 必须显式传。 脚本里带的是示例日期 2026-09-28，不传就会按这个历史基准算，结论全错。
2. 不要编造数据。 字段不清楚就留空并在 SKILL 输出里标注「待补录」。台账里的假数据比缺失数据更危险。
3. 报告是管理辅助信息，不构成法律意见或财务承诺。 准入判定以公司制度与合同约定为准。
4. 本技能自带示例数据是虚构的（智能温控器 TR-200、示例认证机构），只能用来演示格式，不可作为真实业务数据引用。
5. 换真实数据时注意：报告 02 里的「必须立刻动手的事」与「评级要点」两段，是脚本按示例物料名与示例供应商名生成的具体建议。换成自己的数据后，这两段需要按实际物料重写，不能直接沿用。
6. 供应商合规信息属敏感信息，报告不要外发到公开渠道。

相关文件

• scripts/sc_diagnose.py —— 诊断引擎（仅标准库，Python 3）
• data/ —— 示例数据（同时可作为字段模板）
• out/ —— 报告输出目录（已含示例输出）
• references/input-contract.md —— 四张输入表的字段契约与常见坑

关联技能

• supplier-qualification-tracker —— 供应商资质有效期追踪与准入缺口检测（本技能第四步调用它，不要重复实现）

💳 付费能力（Pay Skill）

本 Skill 的基础能力永久免费：BOM校验与库存预警（本地）。

仅「供应链基准增强包」为按次付费（0.5 元/次）——付费购买的是服务端下发的方法论资产（行业周转率基准表、MRP参数库、排程规则库），不是算力。

> 重要：本 Skill 不自建、不部署任何大模型。付费项所需的算力由用户自带（BYOK）或本机提供；用户自带算力同样支付 0.5 元——因为买的是方法论，不是算力。

计费范围

支付依赖（支付宝 AI 按量付费官方能力）

买家侧依赖安装（运行环境尚无时执行一次）：

npx -y @alipay/agent-payment@latest install

> 本 Skill 不自行实现付款流程、不做任何签名与密钥处理。付款、收银与签名全部交给支付宝官方能力完成。

支付流程（Agent 自动执行）

服务端为已通过线上验证的支付宝 AI 按量付费（A2M 402）服务 https://chayuntang-skills.app.workbuddy.host/api/resource（单价以服务端下发的 402 账单为准）。

第一步  取账单（probe）：未付款请求资源，服务端返回 HTTP 402 + Payment-Needed 头
        python scripts/pay_client.py --info
        → 解析出账单 { out_trade_no, amount, currency, goods_name, service_id }

第二步  收银（pay）：向用户明示金额并取得同意后，由官方买家能力收银
        alipay-bot 402-buyer-pay \
          --resource-url "https://chayuntang-skills.app.workbuddy.host/api/resource?skill=supply-chain-diagnostician&feature=default" \
          --intent-summary "诊断供应链与库存问题"
        → 用户完成支付后取得 Payment-Proof 凭证
        ⚠️ 必须先向用户明示金额、取得同意后再继续
        ⚠️ 意图摘要必须写清原始业务目的，保留用户最初想做的事

第三步  取回资源（complete）：携带凭证重试，服务端验付并下发内容、发送履约回执
        python scripts/pay_client.py --payment-proof "<Payment-Proof>"
        → 服务端验付通过后返回付费内容，HTTP 2xx 即履约 ack（履约确认完成）

Agent 注意事项：

1. 三步复用同一个原始请求（URL、feature、必要请求头保持一致），付款后不重新下单；
2. 需要支付时以退出码 2 退出，并在 stdout 输出账单 JSON（含 bill、next_action）；
3. 支付状态不明时先查单（官方 alipay-bot 402-query-payment-status），不重复付款、不追加独立回执；
4. 履约回执失败时服务端重试同一订单并保持幂等，不因回执失败要求用户重新付款；
5. 验付失败（凭证无效或过期）时服务端不交付资源，本 Skill 自动降级为免费基础能力继续工作，不让用户走死路。

付费改造自查（对齐 SkillHub 支付宝付费改造规范）

协议与字段细节见 references/payskill/A2M-402-支付协议说明.md，官方支付能力用法见 references/payskill/官方支付能力说明.md。