碳方法学与商业设计 气雾咖啡

欧盟及主要买家的产品碳足迹要求，指向的是同一条工程约束：优先使用特定现场的一次数据（site-specific primary data），并披露二次数据占比。ISO 14067 与 PAS 2050 都不禁止估算，但要求把估算和实测分开记账、分开披露。绝大多数农产品的碳标签之所以无法通过深度核证，不是因为算错了，而是因为分母（产量）和分子（能耗）都来自事后汇总的表格，既没有时间戳，也无法证明没有被修改过。这是构造成本问题，不是态度问题：没有计量装置，一次数据在结构上就拿不到。

我们的机队恰好在两个最重的分项上有计量级来源。power-meter-PuEr-01 每 60 s 报 power_kw / kwh_total / tariff，是带累计寄存器的真实电能增量，而不是"功率 × 时长"的推算；fog-ctrl-A3 报 ec / ph / do / water_temp 与 fog_duty，配合加肥泵的配方记录，可以把氮投入量从"按采购单摊"变成"按实际配液批次累加"。这两项合起来占本页算例中一次数据占比 65.5%（0.1273 / 0.1943）。剩下 34.5% 是包装、外运、硬件摊销这类上游二次数据，行业里通常靠供应商因子表，属于可替换项，不构成结构性缺陷。

时间戳是第二层。碳排放的时间分辨率决定了因子该用哪一个：同一度电在 00–06 时段（0.31 kgCO2e/kWh）与 17–21 时段（0.58）之间差 87%。用年度平均因子算出来的数，会让"把补光与雾化移到夜间低谷"这类真实减排动作完全消失在账上——既奖励不了正确的行为，也识别不出错误的配置。本页的引擎按六段小时边际因子对每个计量区间逐段加权（见 §3），所以灯谱、轮作、峰谷电价策略的改动会直接反映到标签数字上。

第三层是哈希链。每个批次的碳账本在封账时对"区间清单 + 计量摘要 + 配方记录 + 产量"做规范化 JSON 的 SHA-256，并把上一批次的哈希写进本批次（prev_hash），形成只可追加、不可回改的批次链。核证方拿到的不是一份 PDF，而是可以独立重算的输入集：他能自己把 134.4 kWh 乘上因子表，得到 57.232，再看我们的 57.232 是否一致。能被别人重算，才叫可审计；其余的所谓"碳管理平台"，本质是把不可验证的估算换成不可验证的仪表盘。

所以"现在"不是指市场窗口，而是指数据条件刚刚成立：同一套遥测已经同时喂给闭环控制与碳账本，边际成本接近于零。如果先做标签再补计量，就要重建数据链路；而按现在的顺序——控制层 → 遥测 → 批次账本 → 标签与积分——每一层都复用下一层的输入。这也是本页唯一一个真正的差异化论点，其余部分（因子、标签、积分）都是可被同行复制的工程细节。

2.1 功能单位与参考流 functional unit

FU 2 之所以暂不给数：成株阶段的计量基线尚未建立（无电表、无土壤/基质投入记录）。在缺乏一次数据的阶段直接给数，等于把本文档最核心的论点自己推翻。接口与字段先留，数值等基线。

2.2 纳入 / 排除清单 scope inventory

截断规则：单项 < 总量 1% 且累计 < 5% 的排放源可排除（PAS 2050 惯例）。本页排除项累计约 1.5%，其中 Scope 1 未量化为数据缺口而非截断判断，须在核证前补维保台账。

2.3 边界图 inputs → aeroponic floor → outputs & emissions

图中比例与 §3.2 算例逐项对应。注意边界的方向：气雾栽培排除基质，是"我们的分子里没有基质"；常规土壤育苗的基线里有基质（多为泥炭），这一项在基线侧计入，见 §6 关于基线自声明的风险。

3.1 公式链 engine formula chain

取整方向是刻意的：向上取整使声明值永远不低于计算值，代价是 0.0057 kgCO2e/株（2.9%）的保守偏差。审计上"偏保守"可接受，"偏乐观"不可接受。

3.2 单批算例：480 株 / 45 天 CJV-B-2026-0417

校验：57.232 + 3.888 + 5.760 + 9.600 + 16.800 = 93.280；93.280 / 480 = 0.194333；ceil(0.194333, 0.01) = 0.20；0.20 × 480 = 96.00。 电耗因子 0.4258 为六段曲线的时间加权均值 10.22 / 24 = 0.425833，前提是负荷在 24 h 内均衡（见 §3.3 灵敏度）。

3.3 电网小时边际因子曲线 Yunnan-like hydro-heavy grid · kgCO2e/kWh

因子为设计假设（水电为主的省级电网量级），不是官方发布值 待核证。切换区域时只换这张表，公式与标签结构不变；但标签必须记录所用因子版本，否则跨期不可比。

3.4 不确定度：什么是 ± 什么 uncertainty statement

合成算式：u = √(0.0179² + 0.0016² + 0.0030² + 0.0060² + 0.0140²) = √0.0005636 = 0.02374；相对声明值 0.0237 / 0.200 = ±11.9%。 五项相互独立的前提并不严格（电耗与氮肥投入同受配方影响），故该值偏乐观，工程上应按 ±15% 取用。

4.1 必需字段 required fields

4.2 标签样张 printed mock · 实物尺寸 80 × 100 mm 比例

4.3 标签记录（JSON） signed label record

{
  "label_id": "CJV-CN-YN-2026-000417",
  "version": 1,
  "batch_id": "CJV-B-2026-0417",
  "declared_unit": "plantlet",
  "quantity": 480,
  "kgco2e_per_unit": 0.200,
  "kgco2e_total": 96.00,
  "breakdown": {
    "electricity": 0.11923,
    "nutrient_n": 0.00810,
    "substrate": 0.00000,
    "packaging": 0.01200,
    "transport_outbound": 0.02000,
    "hardware_amortised": 0.03500,
    "rounding_reserve": 0.00567
  },
  "computed_per_unit": 0.19433,
  "boundary": "cradle-to-gate",
  "gwp_version": "IPCC AR6 · GWP100",
  "method": ["ISO 14067", "PAS 2050"],
  "data_quality_grade": "A",
  "primary_data_share": 0.655,
  "activity": { "kwh": 134.4, "n_kg": 0.288, "units": 480, "days": 45 },
  "factors": { "mef_bands": [0.31,0.38,0.44,0.47,0.58,0.41], "mef_applied": 0.425833,
                 "ef_n": 13.5, "ef_pack": 0.012, "ef_trans": 0.020, "ef_hw": 0.035 },
  "verification": { "status": "pending", "body": null, "date": null },
  "inputs_digest": {
    "power_intervals": "sha256:1c07…e9a2",
    "nutrient_lots": "sha256:44b1…7d03",
    "transport_docs": "sha256:9f52…0c6b"
  },
  "prev_hash": "sha256:5c71a0e3d8b46f92a1c07e5b3d84f9026e1a7c4d0b93f8e25a6d1c0b7f4e2938",
  "hash": "sha256:9d2f4c1b7e0a5f836c2b0d94ae17f5c30b8e6d2a4f9c1e7b5a3d8f06c29e4b71",
  "issued_at": "2026-11-03T09:12:44+08:00",
  "valid_until": "2028-11-02T23:59:59+08:00"
}

hash 的覆盖范围：除 hash 字段自身外全部字段（含 verification、factors、inputs_digest），按 JSON.stringify 的键序规范化（字典序、无空白、数字不补零）后取 SHA-256。规范化算法必须公开，否则同一份数据会算出不同哈希。

4.4 验证流程：从 ID + 哈希到重算 public verification

4.5 工程接口 planned endpoints · 与实现对齐

与现有平台的关系：复用 /api/telemetry 的同一份环缓冲与 /api/overview 的设备注册表；设备名、遥测键（power_kw / kwh_total / tariff）沿用冻结契约，不得为碳模块新增设备名或改名。四个端点均为只读；封账与签发走内部任务，不暴露写接口。

5.1 三方账本 three-way ledger

5.2 一年、24 万株：逐项算术 worked annual example

所有"算术"行的输入都写在同一行的算式里，可逐格复算；标"假设"的六个数（年产 24 万株、溢价区间、BOM 与加价率、SaaS 单价、核证费与分成、30 t 出货情景）是本页唯一需要外部验证的输入。其中 30 t 绿果出货量与 24 万株之间的对应关系未建立，见 §5.4 说明。

5.3 积分机制的参数 points mechanics

5.4 溢价通道的口径问题 premium caveat

溢价按绿果重量计价（¥0.3–1.0/kg），而我们的功能单位是苗（株）。两者之间缺一个成株阶段的产出系数（每株成株年产绿果 kg），该系数本页没有计量基线，因此 30 t 只作为情景参数出现，不得解读为 24 万株的必然产出。 正确的做法是：等后期阶段（FU 2）建立计量基线后，用同一套账本把"苗 → 绿果"的产出系数也变成可审计量，届时溢价才能与株数直接换算。在那之前，溢价只能按吨报价、按批结算。

另一个口径问题：溢价由谁支付、在哪个环节实现。若买方只认"整批绿果"而不认苗，则苗阶段的减排实际上是通过下游成株批次的碳标签变现的，中间的分配规则（按质量、按经济价值、还是按阶段独立核算）必须写进合同，否则出现 §6.7 的分配争议。本页立场：两阶段各自独立核算、独立签发标签，苗阶段不向成株阶段转移排放或权益。

6.1 发布前置条件 gate to publish

结论只有一句：这套设计的价值在于"可以被人重算"，风险全部集中在"我们是否真的让人来算"。只要把原始区间、因子版本、基线区间和哈希链都交出去，它就是方法学；只要其中任何一项留在我们手里，它就是营销。