项目说明

Carbon Compliance OS

面向出口欧盟的中国企业的碳合规系统：每个碳足迹数字，都能追溯到条文、数据和证据。

看两分钟演示

1. 法规状态是数据，不是文案。 适用日期由法案状态和日期算出，法定日期与有效日期分开，依赖推断的地方逐项标出。
2. 数字可以复核。 计算结果冻结成带哈希的快照，声明数值只取自冻结运行，国内参考包在类型层就进不了声明。
3. 规则可以替换。 同一批数据，在草案规则和将来的正式规则下各算一次，两次结果都留档。

两分钟演示

问题

欧盟电池法规 (EU) 2023/1542 第 7 条，要求电动车电池、容量大于 2 kWh 的可充电工业电池和轻型交通工具电池，逐步提供碳足迹声明、性能等级和最大阈值。但截至 2026-09-29，这三项要求所依赖的授权法案和实施法案都还是草案，没有一项能确定适用日期。2025 年 7 月，委员会答复欧洲议会时也只说仍在研究电动车方法学的推进方式。

对中国电池企业，这是一个具体的难题：投放市场的义务人通常是欧盟境内的进口商，但碳足迹需要的物料清单、能耗和供应商数据，只有制造商拿得出来。数据现在就要开始整理，规则却还会变。

做了什么

碳合规系统围绕“会变的规则”来设计。演示使用一家虚构中国企业的单个 EV 电池型号及单个工厂的合成数据。

条文 → 要求 → 数据请求 → 数据点与证据 → 冻结的计算运行 → 报告变量。

五个设计决定

1. 状态是数据，不是文案。 法案是否生效、要求何时适用，都写成记录（24 条触发记录、28 条法定期限），由评估日期算出结果。每个要求同时显示法定日期和叠加依赖后的有效日期，靠推断或条文读法待专业确认的地方逐项标出。可以假设某个法案在某天生效，系统在内存里重算，页面写"假设，非事实"，不写入事实记录。

   

   

2. 方法学是可替换的数据。 功能单位、阶段映射、电力核算规则和因子集都在方法学包里，引擎没有方法学分支。欧盟草案依据包可以进入声明；国内参考包只作对照，声明构建器在类型层就拒绝它。草案里容易算错的规则也被编码了：购电协议和绿证不能抵扣，只有厂内直连发电可以，且受年度上限约束（按草案）。

   

3. 冻结即快照，声明只取自冻结运行。 冻结时记下方法学版本、输入版本、因子版本和证据哈希，生成一个哈希（RFC 8785 规范化加 SHA-256）。声明页没有输入框，只显示最近一条通过完整性校验的冻结运行。之后输入变了，三个相互独立的标记指出后果：物料清单或能源结构变了需要重算（附件 II 第 5 点），其他输入或规则更新了建议重算，排放量上升超过 10% 可能需要新型号版本（草案规则，字面读法，待核对）。

   

4. AI 不产生数字。 数字由引擎产生。what-if 的新数值全部由用户输入，系统不给建议，情景也不能冻结或绑定到报告。顾问页只展示各部分占总量的比例，并提供一个由用户自己输入数值的 what-if 面板。这条边界是产品原则：合规里的数字必须能解释、能复现。
5. 每个数字都能追溯。 从声明里的一个阶段数值，可以一路点回过程行、排放因子（含版本和数据集层级）、输入版本、数据来源、证据哈希、对应的要求与条文、方法学包。哪一环缺失就写"无"，不隐藏。

   

怎么核实的

代码由 AI 编程代理按书面规格逐个检查点写出。每个检查点再在另一个 AI 对话里独立复核，不采信代理自己的汇报。复核时重做了这些事：

• 用 Python 和第三方库重新计算冻结运行的哈希，与保存值一致；
• 对 10 份法规与草案来源重算 SHA-256，与登记表一致；
• 用自己的测试矩阵重跑适用性引擎，覆盖多个法案、依赖链、假设情景和月末算法；
• 从 PDF 文本里自动抽出法规日期，与种子数据逐项比对；
• 我自己对照官方公报原文和草案，核对了 8 项关键条款，记录见核对记录。

复核和盘点中发现并修正过的问题：

• 蒸汽用量以 GJ 记、因子以 MJ 计，直接相乘少算了 1000 倍。现在每个数量都带单位，乘法只有一个入口，量纲不符就报错。
• 一个名义日期（工业电池最大阈值的适用日）从研究稿一路转写下来是 2029-08-18，对照官方公报原文应为 2029-02-18。
• 声明页最初显示的是实时计算结果，不是冻结运行，屏幕上的数字可能对应不到任何带哈希的记录。现在只读冻结运行。
• 旧演示的物料清单合计每 kWh 30 公斤，量级不合理；重设后还要把因子同比例重标定，否则各阶段占比会翻转。

报告工作台

限度

• 概念原型，不是可用于申报的产品。
• 全部企业数据和排放因子是合成示例。
• 欧盟方法学规则取自未通过的授权法案草案，可能变化。不构成法律意见；几处条文读法（例如两个法案同时适用时的"取较晚者"，第 77(10) 条没有独立日期）标着待专业确认。
• 没有确认的公告机构通报范围，所以符合性声明编号一律显示"待核查渠道"，系统不虚构任何核查结果。
• 没有权限与多租户。冻结运行和输入版本存在浏览器的 localStorage 里，哈希只能发现意外改动。

技术

React 19、TypeScript、Vite、Tailwind、shadcn/ui，没有后端。535 个自动化测试。中英双语界面。数据模型 40 个实体：27 个已实现，4 个部分实现，9 个仅设计。

分工

我做的： 提出问题并划定范围，只做欧盟电池法规第 7 条这一个切片；取得并整理法规原文与草案；组织并审阅法规研究；审定每个阶段的验收标准并逐个放行；对照原文亲自核对了关键条款，共 8 项，见核对记录；做取舍并记录在 decisions.md，例如演示参数、哪些规则只标"待核对"、国内参考包不得进入声明。

AI 工具做的： 研究法规并起草要求卡片，起草数据模型和规格，写代码和测试。

复核方式： 构建与复核分开。代码由编程代理写，每个检查点交给另一个 AI 对话独立重做一遍，再由我决定是否放行。

愿景与路线

这个原型只是一个切片。我想验证的是一个更大的想法：行业专家把知识封装成参数化的规则，企业通过标准化工作流调用它，不同法规共用同一个碳数据模型。路线分三步，每一步有可检验的完成标准：

1. 把数据模型整理成标准。 独立于实现的机器可读 schema，版本与扩展策略，交换格式，一致性测试。完成标准：另一个实现只靠这份 schema，就能读写冻结运行。
2. 加第二个法规包，例如 CBAM 或国内标准，不改核心结构。完成标准：新法规只通过新增记录和方法学包进入，现有测试不变。
3. 做方法学包的专家创作界面，让规则的编辑不依赖写代码。完成标准：专家能改一个参数，并看到版本、差异和对结果的影响。

目前的数据模型是 v0.1.1：40 个实体，27 个已实现。它是这条路线的起点，不是终点。