你的钢铁 BOM 会替你藏起的那个「不可能的用电数」

焦化工序那一行写着：全厂烧掉了 6,649,140 万 kWh 的混合电网电力。而整个厂——12 道工序，年产 2,093,927 t 粗钢与钢坯——的总用电是 95,503 万 kWh（约 9.55 亿 kWh，吨钢综合电耗约 456 kWh/t，量级合理）。可一个子工序，报出了整个厂区 70 倍的电量：那不是一道高耗能工序，而是一件根本不可能的事。没有人是想用这个数字骗谁。在录入的某个环节，一个数掉进了错的单位字段、错的量级上。它就躺在 BOM 里，看上去和数据没两样。

这类错误，你的表格查不出来，你快速过一遍也看不出来，而你的审核员会查出来——在最糟的时间点：你已经在它之上把整个产品系统搭好了。

能挺过每一轮复核的那个错

这样一个量级错，对人们真正会跑的那几道检查是隐形的。它能过格式检查：是个数字，在对的列，旁边跟着对的单位字符串。它真正过不去的只有一项测试——质量与能量平衡。而这项测试足够繁琐，在一份 12 工序、85 种外购物料的 BOM 上，几乎没人愿意用手算它。这个错之所以一路放行，并不是因为它看上去合理——一个子工序耗掉全厂 70 倍的电，对任何肯停下来把它加一遍的人都不合理。真正的原因是：没人停下来加这一遍。

于是这个数字一路向前。它被匹配到一个电网电力排放因子。它被乘了进去。于是这家粗钢生产商的焦化阶段，报出的电力负荷大幅超过全厂其余部分之和。下游每一个结果——吨产品足迹、贡献分析、你自家碳模型里的前驱体投入量——都继承了这个错位。

要还原真实值，唯一诚实的办法是从全厂电力平衡反推：总用电减去其余工序能解释的那部分。在这里这样算，焦化落在 9,838 万 kWh 附近。对照之下，填进去的 6,649,140 高出约 676 倍——比平衡能容纳的上限还高出两个数量级。具体是怎样录错的，远不如这一点要紧：平衡把它冲了出来。这是一个量级错，肉眼和格式检查本来都注定逮不住。

Cortex Cowork 在哪里读出它

Cortex Cowork 原地打开了这家生产商的 Excel BOM——不重新录入，不套导入模板，不另建一个数据库去填。12 道工序：6 道主冶炼，6 道辅助。它在 14 个数据库间匹配外购物料——HiQLCD、Ecoinvent、EF、CarbonMinds 等——并把匹配率如实报出：85 种物料匹配上 71 种，83.5%。

然后它跑了复核者通常没时间跑的那个平衡。焦化的电力数与全厂总量对不上，于是 Cortex 把它标了出来：这个值超过了全厂用电总量，这是全厂平衡，这是反推得到的 9,838 万 kWh，对照全厂其余部分，这是一个量级错。它没有改写那个单元格。它把这个异常连同推理一起，写回项目决策记录，把改正留给你。

Cortex 标出这个数，把决策交回来。它不会悄悄在单元格里写下 9,838 然后继续往下走。

这个区别是全部要点所在。一个把值「悄悄修好」的工具，已经替你做了一个没有记录的建模选择——而核查者恰恰会要你为这种选择辩护，你却答不上来，因为你从没看见它发生过。Cortex 在自动化会破坏审计的地方暂停。决策回到从业者手里；这个决策被记进推理链。

缺口比错位更响

这个量级错只是 Cortex 在这份 BOM 里翻出的 45 处数据质量问题之一。比任何一个填错的数字更该让你担心的，是那两处数字根本缺席的地方。

大气排放——SOx、NOx、颗粒物——在全部 12 道工序里都是空的。对一个粗钢系统来说，这些不是可填可不填的字段；它们决定了这个模型描述的是一座钢厂，还是一座理想化的炉子。外部运输距离也是空的，每一道工序都空着。没有距离，你无法表征上游运输；你也不能悄悄假设一个出来，那等于凭空造数据。

一个写得很确定的数字之所以危险，是因为它看上去已经完成了。一个空字段至少会自己声明。麻烦在于：一份 100 行的 BOM 里空格够多，重要的那些就藏进了无害的那些里——而人眼是按「填了什么」来分诊的，不是按「缺了什么」。Cortex 把这个反了过来：它把完整性作为五个 DQI 维度之一来打分——时间性、地理性、技术性、完整性、可靠性，沿用 LCA 从业者早已熟悉的 Pedigree 矩阵谱系——并以与一个填错单元格相同的权重报出那一列空着的 SOx，因为对最终结果而言，它们的代价一样。

为什么是推理链，不是一份改好的文件

你可以设想一个工具：它拿走 BOM，清洗一遍，递回一份齐整的版本，焦化数修好了，排放插值补上了，运输距离按厂址估了出来。那个工具会更快。它对核查者也毫无用处，因为这些修补里的每一处，都是一次没有作者的判断。

Cortex 的产出走另一条路：原始单元格原样不动，外加一份记录——它质疑了什么，为什么。焦化那条标记带着它的算术：全厂总量、其余工序用电、残差、它无法对上的那段量级落差。空排放那条标记点名受影响的工序，以及它据此扣分的 DQI 维度。当你的审核员问「焦化那处异常你是怎么处理的」，你打开决策记录，把推理念回去，包括其中那一步——选定改正值的是你，不是软件。

同样的纪律也跑在模型上游：Cortex 准备并筛查数据，把过不了平衡的那些翻出来，再把建模决策连同其来源一起交回给你。这一切都不是审计认证。它是 ISO 14044 要求、CBAM 核查员也会期待的那套数据质量纪律——一条你能逐步走过的推理链，而不是一个你只能选择信任的黑箱。（一点边界说明：这个错位会顺着你自己的 LCA 与产品碳足迹一路传下去。CBAM 申报报的是基于装置实测数据的前驱体排放，而不是一次背景因子匹配——但让两者都经得起追问的，是同一套数据纪律。）

等模型本身要跑起来时，Cortex 连接并驱动你本就在用的引擎——openLCA、brightway、积木LCA。它不替代引擎；它驱动引擎。

今晚，在你自己的 BOM 上查什么

找出你最耗能的那道子工序，把每道工序的电力加起来。如果某一行能跟总量比肩、甚至超过它，那你有的是一个单位错，不是一道高耗能工序。然后扫一遍要紧的空格——燃烧密集工序上的大气排放、任何外购物的运输距离——再问一句：某个缺失的字段，是不是已经在下游某处被悄悄填上了。

或者，把 BOM 在 Cortex Cowork 里打开，让它把平衡跑一遍。2,093,927 吨粗钢，骑在了一个从来没人加过一遍的数字上。逮住它的那点算术并不难。它只是从来没被跑过——直到有样东西每次都把它跑一遍，并写下它查到了什么。

向 Cortex 问一行 BOM → cortex.hiq.earth/chat