烘焙采购：按供应商拆单的订货工具——一份需求清单拆成三家能直接发的单（让编码代理做）

给我做一个单文件 HTML 的拆单订货工具，给烘焙店采购在发单前
用。双击打开就能用，不依赖网络，数据不出本机。

输入一，需求清单（每行一个原料，支持从表格软件直接粘贴，列序
固定）：原料名、需求量、单位。

输入二，供应商目录（在页面设置区维护，支持 JSON 导入导出）：
每个原料一行——主供应商、包装规格（如 25kg/袋）、整包起订
件数、是否支持拆零。

工具要做的事：
- 按主供应商给需求清单分组，一家供应商一组
- 按包装规格凑整：需求 60kg 面粉、规格 25kg/袋 时，每行给
  两种口径——「向上凑整」3 袋（多订 15kg），或「整包＋拆零」
  2 袋加散称 10kg（仅当目录标了支持拆零）；每行一个下拉
  切换，默认向上凑整
- 凑整后的量与需求量的差额逐行显示：多订了多少、拆零了
  多少；不许只在汇总里给一个总差额
- 起订件数不满足的行高亮标「未达起订」，显示还差几件
- 目录里查不到供应商的原料行标「未分配」，单独一张表列出；
  不许静默塞进任何一家，也不许从结果里消失
- 每家供应商生成一张纯文本订货单：品名 / 规格 / 件数 / 折合
  量 / 备注，一键复制，格式能直接粘进微信发出

硬性要求：
- 单文件、无构建步骤、不引任何外部 CDN、字体、库，不发起
  任何网络请求
- 粘贴的数据列数不对或列序错位时，在界面上报错并指明第几
  行，不能静默算错
- 不做账号、不做云端保存、不做本地存储，刷新即清空——这是
  刻意设计：供应商目录靠 JSON 导出导入在两次使用之间搬移，
  需求清单用完即弃。不要自作主张加 localStorage，昨天的旧
  需求混进今天的新单，比没有这个工具更糟

为什么这样写

订什么、订多少是判断；拆单、凑整、抄单是搬运——这个工具只搬后者。人的注意力应该留给凑整差额露出来的真问题：多订的 15kg 面粉下周周转得掉吗，库存放得下吗，贵价原料多订一件压不压资金。差额必须逐行亮出来，就是逼着每个凑整决定都被看见，不许被汇总里的一个总数糊过去。

两种凑整口径并存、由每行下拉切换，是因为哪个划算取决于单价和周转速度，而这两样工具不知道。大宗粉类多一袋下周就用掉，向上凑整几乎无代价；贵价原料多订一件就是压一笔资金，供应商支持拆零就该用拆零。所以默认值照顾大宗原料，改动权留给贵价行——工具算对数，口径归人。

「未分配」单独成表、不许静默归置，是防工具好心办坏事。需求清单里总有几个目录没登记的原料（新品、临时采购），最省事又看起来没问题的做法是塞进「看起来相关」的那家——发错单比不发明更麻烦，供应商收到不认识的品名还要来回确认。单独一张表逼采购当场补目录，目录也因此越用越全。

刷新即清空和 JSON 导入导出是一对刻意搭配。供应商目录值得留，但不许页面自己记；需求清单天天变，必须用完即弃。把「留」交给一个采购自己保管的 JSON 文件，把「弃」交给刷新，两条纪律各管一段。这些「不许加」必须明说——跟编码代理打交道，你说「做个工具」，它大概率附赠带 localStorage 的「完整方案」；不写死「这是刻意设计」，它还会好心帮你加回来。

变量

本条提示词无待填变量；供应商目录在工具的设置区内由使用方维护，经 JSON 导出保存、下次导入复用。