有工程师在开云App里发现，半年前保存的某个混凝土方案，碳排放数字比当时记录的低了将近一成，第一反应是怀疑系统出了错。实际上这类变化大多数时候是数据更新导致的正常结果——材料碳数据从来不是一次性测定就永远不变的标签，而是随供应链条件变化持续重新计算的结果。

碳数据是计算结果，不是出厂时贴好的标签

建筑材料的碳排放数字背后，是原材料构成、生产能耗、能源结构、运输方式这几层数据共同计算出来的结果。这些底层数据里，任何一项发生变化，最终碳排放数字都会跟着变化。开云App的立场是：与其让用户长期看着一个可能已经过时的数字，不如把更新机制做透明，让用户清楚知道每一次数字变化背后发生了什么，而不是把数字变化当成需要藏起来的系统瑕疵。这类更新尤其常见于长周期项目——一个从方案设计到竣工可能跨越两三年的项目，期间材料供应商大概率会经历至少一次EPD换版。

四类会触发数据更新的信号

系统里主要有四类信号会触发碳数据重新计算。第一类是供应商EPD换版——EPD报告通常有效期为3到5年，到期后供应商重新核证发布新版本，新版本往往会反映最新的生产工艺改进。第二类是区域电网结构变化，比如某地区可再生能源装机比例上升，电网平均碳强度随之下降，依赖电力密集型工艺（电解铝、电弧炉炼钢）的材料碳排放会相应调整。第三类是运输路径变化，比如某供应商更换了更近的原料产地或改用铁路运输替代公路运输。第四类是再生成分比例变化，尤其是再生钢、再生铝，供应商申报的废钢废铝比例调整会直接影响碳排放核算结果。以电网结构变化为例，若某地区可再生能源装机比例三年内从28%提升到45%，电网平均碳强度可能从0.72千克CO₂e每千瓦时下降到0.58千克CO₂e每千瓦时，依赖该电网的电解铝或电弧炉钢材产品，碳排放数字会相应下降15%到20%左右，这类变化不需要供应商做任何生产工艺调整，仅仅是区域电网结构演变就足以改变材料的碳排放核算结果。

系统怎么知道一份新EPD和旧版本对应同一种材料？供应商提交新版EPD后，系统首先要做的是身份匹配——判断这份新文件对应的是数据库里已有的哪一条材料记录，而不是简单把所有新上传的EPD当成全新材料录入。匹配依据包括供应商注册编号、产品型号、材料类别以及申报的功能单位，四项信息高度吻合时系统才会判定为"同一材料的版本更新"，而不是新建一条记录。如果匹配置信度不够高，系统会把新数据标记为"待人工确认"，由开云研究组人工核实两份EPD是否确实对应同一产品，避免把生产工艺发生实质性变化的产品错误地当成简单版本更新处理，掩盖了真正的工艺差异。

更新频率不是越快越好，过期数据也不会被动等待

EPD报告的有效期通常是3到5年，系统会记录每一份EPD的发布日期，临近到期前90天自动向供应商发送更新提醒；如果超过有效期供应商仍未提交新版本，系统不会直接删除旧数据，而是在材料详情页加上"数据已过期，供应商尚未更新"的标注，并把这类材料在碳工作台的默认排序里适度降权，避免用户在不知情的情况下继续使用可能已经过时的数据做重要方案比选。这种主动标注比被动等待供应商配合更新更符合工程决策对数据时效性的要求。

数据更新也不是频率越高越好。如果碳排放数字每周都在小幅波动，反而会让用户难以基于稳定数据做长周期的方案决策。开云App的做法是设定更新阈值——只有当底层数据变化幅度超过5%，或者供应商正式提交新版EPD时才触发用户可见的更新，日常范围内的小幅波动会被记录在后台但不会频繁推送提醒，在数据真实性和决策稳定性之间找一个平衡点。

一个模拟场景：废钢比例从35%提升到55%之后

以下为模拟场景，不对应真实供应商数据。设定某钢材供应商最初申报的产品废钢比例为35%，对应碳排放约1750千克CO₂e每吨；一年后该供应商完成产线改造，废钢比例提升到55%，重新申报EPD后，碳排放数字下降到约1320千克CO₂e每吨，降幅约24.6%。开云App在检测到供应商提交新版EPD后，会自动比对新旧数据的差异幅度，如果单项数据变化超过10%，系统会在材料详情页标注"数据已更新"并附上变化前后的对比，而不是悄悄替换旧数字，让之前基于旧数字做出的方案对比失去可追溯性。

更新不是覆盖，而是保留版本记录

数据更新如果处理不当，容易造成一个隐患：工程师半年前基于某个碳排放数字做的方案比选，如果系统直接覆盖旧数字，之前的比选结论就变得无法复现。开云App对每一次材料碳数据更新都做版本化处理，旧版本数据不会被删除，而是标记为"历史版本"保留在项目记录里，同时新建的方案默认调用最新数据。这样既保证了新方案用到的是最新信息，也保证了历史决策可以追溯当时的计算依据，这一点对涉及审计或者需要长期留痕的绿色建筑认证项目尤其重要。版本记录还有一个现实用途：如果项目最终申请绿色建筑认证，评审机构可能要求提供材料碳排放数据的原始依据和计算时点，历史版本记录可以直接导出对应时间点使用的EPD数据和假设条件，而不需要用户自己去翻找几个月前的截图或者邮件附件。

更新影响到已保存方案时，系统还会额外通知用户：如果某个材料在被某个项目空间的已保存方案引用后，其碳排放数据发生超过10%的更新，系统会额外触发一条项目级别的提醒，列出所有引用了该材料、且可能受影响的历史方案，而不只是在材料详情页悄悄挂一个"已更新"标签等用户自己发现。这条提醒会说明具体变化幅度和变化原因，用户可以选择保留原方案的旧数据继续使用，也可以一键更新到最新数据重新计算，两种选择都会被记录在项目的版本历史里，方便后续追溯这份方案最终采用的是哪个版本的材料数据。

数据更新之所以能让用户信任，前提是每一次更新都附带原因说明，而不是一个孤立的新数字。这和材料决策必须看到假设条件是同一套设计思路——运输距离变了、电网结构变了、再生比例变了，这些变化本身要摆在明面上，用户才能判断新数字有没有道理，而不是被动接受一个看不出原因的更新结果。

数据更新和数据导入是两个相关但不同的环节

数据更新处理的是系统内已有材料的再计算，而用户自己上传新材料数据、遇到格式或单位问题时，则是另一套流程，具体可以参考材料数据导入失败的排查方法。两者共用同一套单位换算和口径校验逻辑，这也是为什么开云App要求所有材料数据——无论是系统内置更新还是用户手动导入——都必须经过同一套功能单位对齐的处理流程，才能进入碳工作台参与比较。

数字会变，恰恰说明系统在诚实地反映供应链现实

一个碳排放数字如果永远不变，反而更值得怀疑——这意味着系统要么没有跟踪真实的供应链变化，要么在用一个陈旧的行业平均值敷衍所有用户。开云App选择让数据随供应商、能源结构、运输条件的真实变化而波动，并且把每一次波动的原因摆在用户面前，这比维持一个表面稳定、实际上早已脱离现实的数字更接近材料碳核算该有的样子。