水果店盘点：让编码代理做一个鲜度分层库存估值工具——库存不是数出来的，是估出来的

给我做一个单文件 HTML 的库存估值工具，给水果店盘点专员每晚收摊后用，
手机上开。先说清这个工具的灵魂：水果盘库存，数是数不清的——半箱果、
三个瓜、一堆散橙，数出来也没用；有用的是「这些货明天还值多少钱」。
估值 = 数量 × 进价 × 鲜度折价系数，这个工具就是把三步做快。

每日录入（每个在售品一行，大概数就行）：
- 品名、剩余数量（约几斤 / 几个 / 几箱，估的数就写估的）
- 进价（进货单口径；查不到的品标「待补」，不阻塞录入）
- 鲜度等级三选一：
  A（硬挺，明后天照原价卖）
  B（走样，明早要动：折价或转果切）
  C（临界，明天出不掉就报损）
- 特殊标记：整箱未拆（估整箱，不开箱）

计算逻辑（口径写死在代码里，页面上各用一句话解释）：
- A 级估值 = 数量 × 进价 × 1（不减值）
- B 级 = 数量 × 进价 × B 系数（设置里填，首周自己校）
- C 级 = 数量 × 进价 × C 系数（更低，接近清仓口径）
- 整库存值 = 三级加总；B、C 两级的估值和占比单独显示——占比就是
  明天的行动清单

输出区（一屏）：
- 今日库存总估值，和昨日比的变化：变增说明今天卖得好买得准，
  变减说明鲜度在走下坡——连续三天变减要标红提示
- 「明早必动」清单：B、C 两级的品按估值从大到小排，每行给建议去向
  （B 折价 / B 转果切 / C 清仓）——去向是建议，人定，工具不替人定
- 「复制今日估值」按钮：纯文本，总估值、B/C 占比、必动清单，
  粘给老板或记账用

硬性要求：
- 单文件、无构建、不引任何 CDN，手机浏览器直接打开
- 数据只存 localStorage，不出本机，不做账号不做云同步
- 录入一屏做完：品名 + 数量 + 等级三下点完一个品——一个品超过
  十秒，这个工具就会被放弃，宁可功能少也要快
- 鲜度系数全部放设置，代码里不写死任何数字——各店品类结构差太多，
  工具只提供算式，参数归门店

为什么这样写

「数是数不清的」是这份工具的立论：常规盘点工具的范式是「录一个精确 数量」，对水果既做不到（半箱、散果、估重）也没意义——精确的数量配 不扣鲜度的单价，算出来的还是假值。把范式换成「估数量 × 分级折价」， 承认两个模糊（数量模糊、等级模糊），换回一个有用的粗值：今天店里 的货大约值多少钱。这恰恰是老板和会计真正要问的数。

三级折价的真正产出不是总估值，是 B、C 级占比。总估值是财务视角的 结果，占比是运营视角的信号：占比高说明「明早有一批货必须在变报损 之前动掉」——必动清单直接给到品和去向建议，盘点就从「算账」变成了 「排兵」。连续三天估值下滑标红，是在提醒一个更冷的事实：可能不是 卖得差，是最近拿的货鲜度本身在走下坡，该回头查进货了。

录入速度被提到「硬性要求」里、和单文件同级别，是盘点类工具的生死线： 每晚收摊九点半，理货员又累又饿，一个品超过十秒的记录工具活不过一周。 所有设计妥协（等级三选一而不是五级、去向是建议不是流程、数量允许 「约」）都服务于同一件事——让每晚这一分钟成为习惯。

系数不写死、放设置，还有一个不显眼的原因：系数是各店自己的经营史 压缩出来的（这家店的香蕉走样后还值七成，那家只值五成），首周按默认 跑，第二周对着自己的折价单校一次——工具用得越久，参数越像这家店 自己的性格，这才是「估值准」的真实含义。

变量