零食标准 · Standard Logic
零食标准背后的逻辑
餐饮服务立足 便利性、高效性、健康、安全 四大原则。
正餐提供饱腹感与核心营养，零食则在健康基础上为员工提供
解渴、适度解馋、提振状态 的轻量补给。
通过投入一个 等值零食篮 (Equivalent Snack Basket)，
在不同购买力的市场间拉齐预算投入水平，同时用必选核心品类保证员工体验一致。
1
四大指导原则
所有零食采购、配置、运营决策都围绕这四条原则展开。
便利性
员工随取随用，无需等待与审批，最大化可及性。
高效性
配置与运营模式低管理成本、易规模化。
健康
以膳食指南为锚，控制放纵品比例，优先健康选项。
安全
食品安全是底线，供应商资质与储存条件严格审核。
正餐 · Main Meals
提供饱腹与核心营养
解决员工在职场的基本能量与营养摄入需求，是餐饮服务的主体。
零食 · Snacks
健康基础上的轻量补给
在健康优先的前提下，适度满足员工对解渴、解馋和能量提振的需求，作为正餐之间的补充。
2
标准零食篮
一份标准零食餐由 5 个品类按固定克重/毫升组成（每人每天）。
🥜
坚果
20 g / 人 / 天
🍎
水果
300 g（2 件）
🥤
饮料
2 × 330 ml
🥔
薯片
20 g
🍫
零食棒
20 g
为什么是"等值"而不是"等同"？
由于各国购买力与价格水平差异巨大，直接用同一套 SKU 既不现实、也不一定合理。
等值篮子的做法是：固定 品类构成 + 克重/毫升比例，让每个市场都投入在"营养价值与体验相当"的组合上；
具体 SKU、品牌和配送方式可以灵活本地化。
3
三大需求维度
每一个品类都对应一个明确的员工需求维度，不是随意拼凑。
健康基础
参考 WHO 及欧盟主要国家膳食与营养建议，零食篮中纳入适量的健康品类：
WHO 膳食建议
欧盟主要国家指南
· 坚果 20 g / 人 / 天（一小把）
· 水果 300 g / 人 / 天（两件）
· 水果 300 g / 人 / 天（两件）
解渴与提振
基于既往运营中观察到的实际消费模式，员工对 日常解渴 与 适度咖啡因/糖分提振 有稳定需求。
· 2 × 330 ml 饮料 / 人 / 天
不限定具体形态（水、气泡饮料、茶、咖啡等），便于本地化选配。
适度解馋
承认员工也有"想吃点小零嘴"的诉求，同时 严格限定克重，把放纵品的比例控制在健康可接受范围。
· 薯片 20 g + 零食棒 20 g / 人 / 天
合计放纵品 40 g，远低于健康品类（坚果+水果）的克重占比。
4
必选 vs 可灵活本地化
全球一致的员工体验，不需要通过"全球一致的 SKU"来实现。
必选核心
所有办公地必须覆盖
保证全球员工都能获得一致的零食基线体验。
- 饮料 + 零食：免费提供，且尽可能提高健康选项比例
- 综合坚果 (Mixed Nuts)
- 基础水果：苹果、香蕉、柑橘类
可灵活
因地制宜，尊重本地特点
不对交付模式做刚性标准化，允许适度调整以提升员工满意度与感知价值。
- 具体品牌与 SKU：根据当地偏好与可及性选配
- 配送与运营模式：适应当地市场实践与管理成本
- 额外丰富度：在核心品类外加入本地特色
5
等值篮子公式
用统一口径把上面的设计翻译成各国零食餐标数字。
零食标准(国家) = Σ品类
篮子克重(品类) ×
单位价(国家, 品类)
展开到 5 个品类就是：
20 g × P(坚果) + 300 g × P(水果) +
2 × 330 ml × P(饮料) + 20 g × P(薯片) + 20 g × P(零食棒)
2 × 330 ml × P(饮料) + 20 g × P(薯片) + 20 g × P(零食棒)
其中 P
为该国代表 SKU 的单位价（来自"食材价格库"，归一到 per-100g / per-330ml）。最终数字会与各地实际花费交叉校验（见下方迭代记录）。
6
2025 年 2 月 · 非中区零食预算标准迭代
把原本只有 2 个品类的篮子扩展到 5 个品类，并与各地实际花费交叉校验。
旧版
2 × 可乐
+ 3 × 零食棒
+ 3 × 零食棒
采样面窄，只覆盖"解渴 + 解馋"两个维度。
2025 年 2 月
新版
2 × 饮料 + 2 × 水果
+ 20 g 坚果
+ 20 g 薯片 + 20 g 零食棒
+ 20 g 坚果
+ 20 g 薯片 + 20 g 零食棒
覆盖健康基础 + 解渴提振 + 适度解馋 三大维度。
① 丰富采样品类 — 从 2 个品类扩展到 5 个品类，让预算数字更全面地反映员工实际消费结构，而不只是"饮料+零食棒"这一窄视角。
结论：
预算公式本身立足健康，兼顾解馋解渴与提振状态，也让我们在全球各职场的零食投入在口径上真正可比。
7
技术逻辑
从零售商网页 → 清洗后的价格库 → 最终零食餐标，整条数据流水线是怎么跑起来的。
Step 1
爬虫
按"每国 × 每品类"去当地头部大型连锁商超/大型电商 C 端页面采集原始 HTML。
对强反爬的站点使用 ZenRows 无头浏览器渲染（模拟真实用户），对其他站点走 r.jina.ai 代理。
ZenRowsr.jina.aiSerper
Step 2
取数
优先抓 结构化状态（Next.js
__NEXT_DATA__ / JSON-LD ld+json / Apollo / Redux preloaded state），
拿不到再让 Ark 大模型 按 schema 解析 HTML 切片，输出 {name, price, weight, url, thumbnail}。
__NEXT_DATA__ld+jsonArk AI · schema
Step 3
清洗
多语种正则抽克重 / 毫升（g / kg / ml / L / oz / lb），再按类目中位数做兜底估算。
剔除面包屑页、404、广告位、SPA 骨架，留下真正的 SKU。价格统一归一到 单位口径（per-100g / per-330ml）。
weight regexSPA skeleton guardper-100g / per-330ml
Step 4
计算
每个品牌取最新一条价格 → 算术平均 → 乘以标准篮克重 → 累加 6 大食材得到当日零食篮预算。
所有中间结果存进 Supabase 做版本追溯，每周定时刷新一次。
Supabaseweekly refreshaudit trail
搜索代表物 · Search for Representative SKUs
对每个（国家 × 类目），用
对每个（国家 × 类目），用
site:retailer.com 关键词
调 Serper API 先定位候选页，再用 ZenRows/r.jina.ai 抓渲染后的 HTML。
零售商优先级：大型连锁线下超市 ≻ 主流电商 C 端 ≻ 备选。
结构化状态优先 · Structured-State First
先从页面里提取
先从页面里提取
__NEXT_DATA__、ld+json、Apollo/Redux preloaded state；
取不到再丢给 Ark 大模型按 JSON schema 解析切片。这一步把无结构的 HTML 变成干净的字段。
Schema 约束让模型只能输出被允许的键，避免乱造数据。
分级清洗 · Layered Cleaning
L1 多语种克重正则（中文"克 / 公斤 / 毫升"、英文 g/kg/ml/l、欧语 "gr / grammes" 等）； L2 根据 SKU 标题判断"按重量计价 vs 按件计价"； L3 类目中位数估算兜底，并打
L1 多语种克重正则（中文"克 / 公斤 / 毫升"、英文 g/kg/ml/l、欧语 "gr / grammes" 等）； L2 根据 SKU 标题判断"按重量计价 vs 按件计价"； L3 类目中位数估算兜底，并打
~估算 徽章让后续人工可审。
置信度低的 SKU 会进入"Fix missing weights"批处理任务由人工复核。
价格库沉淀 · Price Library in Supabase
每条记录按
每条记录按
(国家, 类目, 品牌) 去重，保留最新一条，旧记录做版本追溯。
"标准生成"页把价格库里每个品牌的 (raw_price / weight) × item.grams 做算术平均，再累加成零食篮总预算。
所有 Run 都有 sourceRunId，点进去能看到最原始的零售商页面 URL。
定时刷新 · Weekly Refresh
服务端每周自动触发一次全量扫描，失败的任务进
服务端每周自动触发一次全量扫描，失败的任务进
Retry failed 队列。
当数据超过 60 天未刷新 UI 会黄色提醒，超过 180 天红色阻断生成。
价格采样口径说明
受限于数据可得性，本网页上的价格均为当地大型连锁商超数据 / 大型电商 C 端数据。 由于 C 端零售价格和 B 端采购价格可能存在差异，我们会在每次 RFI 阶段向供应商收集食材报价， 并且沉淀出一套各个国家的 B 端 / C 端价格转化系数，让最终的餐标计算越来越接近供应商"真实的花费"。
餐标(真实) = 餐标(C 端采样) × k国家
其中 k国家 = 历次 RFI 供应商报价 ÷ 同时点 C 端零售价 · 滚动均值
其中 k国家 = 历次 RFI 供应商报价 ÷ 同时点 C 端零售价 · 滚动均值