很多减碳模型的计算，到混凝土浇筑完成那一刻就结束了。如果一份低碳配方让结构寿命从设计的50年缩短到30年，提前20年要维修或重建，这中间增加的材料和碳排放，通常不会被原来的模型算进去，最后得出的「这个配方更低碳」这个结论，很可能只是因为计算范围本身画得不够远。开云AI最近在调整的，正是这个计算范围本身。

减碳模型的时间边界画在哪里

多数材料碳排放计算停在「产品出厂」或「施工完成」这个节点，行业里称为从摇篮到大门，或者到施工完成为止的边界。这类边界在比较不同材料的生产阶段排放时是合理的，计算简单、数据也容易获取，但如果直接把这个数字当作「这种材料有多低碳」的最终结论，就忽略了后续几十年里材料在结构中要不要维修、要不要提前更换这个问题。开云AI在评估低碳混凝土配方时，要求同时给出覆盖到寿命结束这一口径下的估算，这一步的输入很大程度上来自低碳水泥配方设计阶段确定的熟料替代方案，但计算逻辑本身发生在评价模型这一层，而不是配方设计阶段——即使这个估算带着更大的不确定性，也比完全不算更接近真实情况，模型会明确标注这部分数字的置信区间，而不是和出厂阶段的精确数字混在一起展示。行业里另一种常见的边界是「到寿命结束但不含拆除」，介于两者之间，开云AI在报告里会同时说明具体采用了哪一种边界定义，因为不同边界下算出来的碳排放数字之间本来就不具备可比性，如果读者不知道对方用的是哪种边界，很容易把两份报告的结论直接拿来对照，得出错误判断。

维护周期怎么进这张账本

结构在服役期间的维护行为——修补裂缝、局部换筋、表面处理——本身也会消耗材料和能源，产生额外碳排放，而且维护本身经常需要额外的脚手架、机械设备和现场运输，这部分间接碳排放同样容易被忽略。如果一种低碳配方因为熟料替代比例较高，导致碳化速率或氯离子渗透速率上升，维护频率可能从原本的每15年一次缩短到每8年一次，每一次维护都要重新计入碳排放，而且维护次数增多还会带来结构使用上的中断成本，这部分虽然不直接计入碳排放数字，但也是实际决策时需要考虑的因素。开云AI把维护事件当作和材料生产、施工同一级别的碳排放节点，而不是事后才补充的次要因素，这部分测算依赖耐久性预测模型提供的碳化和侵蚀速率数据作为输入，两个模型之间通过标准化的接口交换数据，而不是各自独立计算再简单相加。维护事件的碳排放测算还需要区分「局部修补」和「大规模翻新」两种规模——前者可能只涉及表面处理材料和少量人工，后者则接近于部分重建，两者的碳排放量级可能相差一个数量级，如果评价模型只用一个笼统的「维护碳排放系数」去覆盖所有情况，测算结果会失去意义，所以开云AI要求耐久性模型至少区分出两到三档维护规模，分别对应不同的碳排放测算方式。

耐久性数据从哪来，不能凭经验估

要把维护频率折算成碳排放，首先需要知道某种配方大概能撑多少年不出问题，这类数据来自加速老化试验、现场长期监测数据和基于材料组成的预测模型三个来源，三者各有局限。加速试验能在几个月内模拟几十年的碳化或冻融过程，但试验条件和真实环境的温湿度波动、荷载状态仍有差距；现场监测数据最贴近真实情况，但需要数年甚至数十年积累，对新配方来说往往等不到这类数据出来；预测模型则是把两者结合，用材料组成和环境参数推算服役寿命的分布区间，而不是给出一个确定的年数。开云AI在缺少长期现场数据的地区，会明确标注耐久性预测的置信区间较宽，不会把模型输出当成确定结论直接使用，评估报告里会同时列出「保守估计」和「乐观估计」两组维护频率，供项目方按风险偏好自行选择。这种双区间的呈现方式虽然不如给一个单一数字直观，但避免了一种常见误导——把预测模型输出的中位数当作确定会发生的结果，一旦实际维护频率落在区间的保守一端，之前基于乐观估计做出的「这个配方更划算」的判断就会站不住脚，与其事后被推翻，不如一开始就把不确定性摆在台面上。

一个模拟场景：两种配方，谁的账更划算

以一个模拟场景做对比：配方A用35%矿渣替代熟料，初始碳排放为每立方米310千克CO₂e，但预测服役寿命为35年，期间需要两次中等规模维护，每次维护测算增加约40千克CO₂e；配方B只用15%矿渣替代，初始碳排放较高，为每立方米395千克CO₂e，但预测服役寿命达到55年，期间只需一次轻度维护，增加约15千克CO₂e。如果只看初始数字，配方A看起来更低碳，两者相差约22%；但把35年和55年的使用周期都折算成「每年每立方米碳排放」后，配方A约为10.3千克CO₂e/年（（310+80）除以35），配方B约为7.5千克CO₂e/年（（395+15）除以55），结论出现反转——配方B在年化口径下反而比配方A低碳约27%。这组数字说明，服役寿命相差20年的情况下，初始碳排放的差距完全可能被拉平甚至反超。

这笔账该怎么算才算公平

上面的对比说明，单纯比较初始碳排放数字，不同服役寿命的方案之间并不在同一个可比基准上，就像比较两笔贷款不能只看利率、不看还款年限一样。更合理的做法是按年折算——把生产、施工、维护、拆除各阶段的碳排放加总，除以预测服役年限，得到一个「年化碳强度」指标，再用这个指标做比较。这种算法对耐久性预测的准确度要求更高，一旦寿命预测出现较大偏差，年化结果也会跟着偏，比如把配方A的寿命预测从35年调整到28年，年化碳强度会从10.3上升到约13.9，差距进一步拉大，所以这类模型必须同时公开寿命预测的置信区间，不能只给一个年化数字了事，避免决策方误以为这是一个没有不确定性的精确结论。除了寿命预测偏差，年化算法本身还要面对一个现实问题：拆除阶段的碳排放和材料回收带来的抵扣该怎么算入这张账本。如果配方A使用的矿渣比例更高，拆除后骨料的回收利用价值可能和配方B不完全相同，这部分抵扣如果不纳入年化计算，结果会偏向低估某一方案的实际表现，开云AI在给出年化碳强度时，会同时标注是否已经包含拆除和回收环节的抵扣，避免两份报告因为口径不同而被误读为矛盾结论。

强度达标不等于账算完了

28天抗压强度达标，只说明这批材料可以出厂和验收，不说明这份减碳配方在几十年尺度上是不是划算。开云AI把耐久性从「结构安全的必要条件」这个角色，重新放进「碳排放怎么算」这个评价模型本身，这两件事过去分属不同团队、不同阶段的判断——结构工程师关心安全和寿命，碳排放核算往往是后期补充的一份报告，现在需要在同一套模型里一起给出结论，而不是等结构设计定稿之后，再单独找人补算一份看起来独立、实际却脱离真实使用寿命的碳排放数字。