龙虎斗App AI碳足迹与绿色工厂助手

龙虎斗App显示一个产品PCF上涨以后，为什么页面首先应该告诉用户到底是Material、Factory还是Transport发生了变化？

手机上弹出一条通知：SKU-A的PCF从11.9升到了12.8 kgCO2e。如果点开以后看到的只是这个新数字、一个红色向上的箭头和一张饼图，用户得到的只有焦虑：哪里出了问题？该找谁？是不是工厂的事？龙虎斗App的Product PCF页面把这些问题的答案放在第一屏，数字本身放在第二位。数字为功能示意。

第一屏显示的是变化归因：本次上涨0.9 kgCO2e，其中0.7来自Factory Energy，0.2来自一条物料的供应商数据更新；Material（除该物料外）与Transport无变化。Factory Energy的0.7再往下一层：2号线8月报废率从6%升到11%，单位好品能耗上升，制造段分摊到每件的碳随之上升。这段话回答了“哪里变了”和“为什么变”，用户不需要从饼图里猜。

为什么归因要放在数字前面？因为工程师看PCF不是为了知道它是多少，而是为了知道该做什么。一个从11.9到12.8的变化，如果来自工厂报废率，行动在生产和质量部门；如果来自供应商数据更新，行动在采购，而且可能根本不需要行动，因为那只是数据从行业平均值换成了实测；如果来自因子更新，那和这家企业的任何部门都无关。三种情况的数字变化可能一样，行动完全不同。页面结构决定了用户是先看到行动方向，还是先看到一个需要自己去解读的数。

归因之下是Contribution Tree：Materials、Manufacturing、Transport、Packaging各占多少，每个节点标注数据置信度（Supplier Verified、Supplier Data、Database Factor、Estimated）。用户可以点进Materials看到铝壳体、PCB、铜材各自的贡献和数据来源；点进Manufacturing看到电力、天然气、压缩空气各自的分摊和实测比例。再往下是版本对比：当前版本与上一版本在六个维度上的差异，变化的维度高亮。

归因本身也要标置信度。“0.7来自Factory Energy”是基于两个版本之间只有工厂数据期间不同这一事实推出的，置信度高；如果两个版本之间同时变了三个维度，归因就需要把交互影响拆开，置信度会下降，页面上要如实显示“归因为估算，三个维度同时变化”。用户应该知道归因本身有多可靠。

当变化来自因子更新时，页面要特别明确。电网因子从2023版更新到2024版，所有产品的制造段同时变化，这不是任何工厂的功劳或过失。龙虎斗App在这种情况下的首屏文案是：“本次变化由因子库更新导致，与产品设计、供应链和工厂运行无关。”并在趋势图上用不同的标记显示这个版本，避免它被当成真实的上升或下降。

版本比较的选择也在这一屏：默认与上一版本比较，用户可以切换到与同一产品的任何历史版本比较，或与同类产品的当前版本比较。跨边界的版本不允许比较，页面会提示“边界不同，不可直接比较”。

这种“先归因、后数字”的结构，来自龙虎斗官网反复强调的一个观点：PCF变化可能来自真实减排，也可能只是数据质量、方法或版本变化；一个数字如果不能说清楚为什么变了，它就不能被用来做任何决定。龙虎斗App把这个观点变成了页面的默认布局。用户打开一个PCF，第一眼看到的不是“它是多少”，而是“它为什么是这么多、上次以来哪里变了、你该去找谁”。

移动端还有一个特殊约束：屏幕小，用户往往只看第一屏。所以龙虎斗App把归因压缩成三行以内，每一行对应一个可以点进去的维度，点进去才展开Contribution Tree和数据来源。第一屏不出现饼图，因为饼图在手机上只能传递“谁大谁小”，传递不了“谁变了”。通知本身也遵循同样的规则：推送文案直接写“SKU-A PCF +0.9，主要来自2号线报废率上升”，用户不打开App也知道该找生产部门。当归因的置信度不够时，推送文案改为“SKU-A PCF +0.9，三个维度同时变化，请打开查看拆解”，不给出一个可能误导的单一原因。这些细节决定了一条PCF通知是被当成待办，还是被当成噪音。

龙虎斗App发现某供应商Carbon Data已经超过一年没有更新以后，为什么这应该成为Data Quality问题而不是直接把旧数字删掉？

龙虎斗App的Supplier Carbon页面上，一条铝壳体供应商的PCF旁边出现了一个标记：参考年份2024，已超过一年未更新。用户的第一反应可能是：旧数据不可靠，删掉，换成行业平均值。龙虎斗App不这样处理。它把这条数据标为“陈旧”，放进Data Quality待办列表，数值保留，置信度降一级，并生成一封向供应商索取更新的邮件草稿。数字为功能示意。

不删除的第一个理由是：旧的一手数据通常仍然比新的行业平均值更接近这家供应商的实际情况。供应商2024年的PCF反映的是它的工厂、它的工艺、它的电网；行业平均值反映的是一个大类的平均。除非有理由相信这家供应商在一年内发生了重大变化（换厂、换工艺、换电力来源），否则旧的一手数据仍然是更好的估计。删除它，等于用一个更粗的数替换一个更细的数。

第二个理由是：删除会让这条物料在Confidence Ladder上从Supplier Data退回Industry Average甚至Missing，总PCF的Primary Data占比下降，置信度下降。这条物料贡献了33%的PCF，它的置信度下降会明显拖低整个结果的可信度。而“陈旧的Supplier Data”比“新的Industry Average”在阶梯上仍然更高。

第三个理由是：陈旧标记本身是一条有用的信息。它告诉采购：这家供应商需要被追问了。它告诉碳核算人员：这条数据在下次重算时可能会变。它告诉验证方：这个数字的参考年份是2024，请据此判断。删掉以后，这些信息全部消失，只剩下一个看起来“干净”但实际上更不可靠的行业平均值。

所以龙虎斗App的处理是：数值保留，附年份标签和“建议更新”状态，置信度降一级，进入Data Quality待办，生成追问草稿。待办列表按物料贡献排序：贡献33%的铝壳体排在最前面，贡献0.1%的标签排在最后面。陈旧阈值也按贡献区别设置：对高贡献物料，一年就该提醒；对低贡献物料，两三年才提醒。这样用户的注意力花在真正影响结果的地方。

当供应商回复并上传了2025年的数据以后，页面不是简单地覆盖旧值，而是把新旧两版都保留在这条物料的版本记录里。用户可以看到这家供应商的PCF从2024到2025的变化，这本身是一条供应商信息：它是在改善还是在恶化，变化来自它的电网还是它的工艺。如果新值与旧值相差很大，页面会提示核对：是供应商的实际变化，还是它换了计算方法或边界。

页面上还有一个“供应商响应”视图：向多少家供应商发出了更新请求，多少家回复了，平均响应时间多长，哪些供应商连续两次没有回复。这些信息对采购评估供应商的配合度有用，也是Supplier Data Agent工作效果的直接反映。

龙虎斗App对陈旧数据的处理原则可以概括为：数据的年龄是它的属性，不是删除它的理由；处理陈旧的方法是索取更新，而不是退回估算；用户的注意力应该按贡献分配，而不是按陈旧程度平均分配。一个把所有超过一年的数据都自动删除的系统，看起来很严格，实际上是在系统性地降低自己的数据质量。

页面上还处理一种更细的情况：供应商的数据没有陈旧，但它引用的因子陈旧了。供应商2025年的PCF里用的是2022年的电网因子，这在供应商那边是一个方法问题，在采购方这边则表现为一条“看起来很新、实际上部分过时”的数据。龙虎斗App在读取供应商PCF的元数据时，会检查它声明的因子年份，并在与参考年份差距过大时给出提示，建议采购在下次索取更新时一并提出。这类提示不改变数据的置信度等级，只作为追问清单的一项。数据质量不是一个开关，而是一组可以逐项改善的属性；龙虎斗App的Supplier Carbon页面把这些属性一条一条摆出来，让采购知道每家供应商还差什么，而不是只知道谁的数字“旧了”。

龙虎斗App显示工厂实时用电突然增加以后，为什么页面应该同时显示Production Output而不是只发一个红色Energy Warning？

下午两点，龙虎斗App推送了一条通知：2号线用电比基线高18%。如果通知只有这一句话和一个红色图标，值班工程师会放下手里的事去查设备。到了现场他会发现：2号线正在赶一批订单，产出比基线高21%，好品高19%，单位好品用电几乎持平。这不是异常，是正常的高负荷生产。他白跑了一趟，下次再看到红色通知时会犹豫。数字为功能示意。

龙虎斗App的Green Factory页面不这样推送。用电上升18%这条信息在推送之前，先和同一时间窗口的MES产出对齐，算出单位好品能耗与基线的偏差。如果偏差在阈值内，通知的措辞是：“2号线用电+18%，产出+21%，单位好品能耗持平，不构成Energy Anomaly。”甚至不推送，只在页面上记录。如果偏差超过阈值，通知才是红色的，而且措辞是：“2号线用电+18%，产出+2%，单位好品能耗+16%，请检查。”

页面上，用电和产出画在同一张图上：两条曲线，一条是功率，一条是产出，同一个时间轴。用户一眼能看到两条线是否同步上升。同步上升是正常生产，一条上升一条不动才是问题。顶部直接给出判断：kWh每好品与基线的偏差，以及“是否构成异常”的结论。这个判断是龙虎斗能耗管理归一化逻辑在移动端的直接体现：总能耗上升不等于效率下降，必须先看产量。

什么情况下应该真正报警？龙虎斗App的规则有三条。第一，产出没变而用电上升：同样的产品、同样的产量，能耗突然高了，这是设备或工艺的信号。第二，单位好品能耗偏离基线超过阈值：无论总量怎样，每件好品用的电明显变多了。第三，非生产时段出现不该有的负载：夜班没有工单，某台设备的功率却在生产水平，这可能是设备没关、也可能是有人在做系统里没记录的事。这三条都经过了产量归一化，不会被正常的高负荷生产触发。

即使真正报警，页面也不只给一个“异常”。它附带上下文：当前工单和产品型号（是不是切换到了一个能耗更高的产品），Product Mix（今天的重型型号占比是不是变了），环境温度（冷却负荷是不是因为天气上升了），最近的维护记录（这台设备是不是刚修过或者该修了），以及这台设备在同类产品上的历史单耗曲线。有了这些，工程师在到现场之前就能排除一半的可能原因。异常能耗不等于设备坏了，原因可能是产品结构、操作员、温度、维护、负载或工艺参数，页面把这些可能性和支持或排除它们的数据一起列出来。

压缩空气有一个专门的视图：夜间基载模型、当晚的实际负载、压力衰减速度与历史比较、可疑区域。如果夜间基载偏高，页面给出的是“建议本周巡检某区域”，而不是“泄漏警报”。这个措辞的差异是刻意的：前者是可以执行的动作，后者是一个需要人去解读的标签。

报警的最终去向也在页面上：这条异常被谁认领了、现场检查的结果是什么、是设备问题还是产品原因、有没有产生变更申请。这些记录回流到基线模型，让下一次的判断更准。一个被误报多次的报警系统会被工程师忽略；一个每次报警都附带产量、上下文和可能原因的系统，才会被信任。龙虎斗App的Green Factory页面设计目标不是让用户看到更多红色，而是让每一个红色都值得跑一趟。

这一页与产品碳足迹的连接也是直接的。当2号线的单位好品能耗确实上升并持续了一个统计期间，SKU-A的制造段碳排会在下一次重算时上升，Product PCF页面的归因会指向“2号线报废率”。用户从能源警报可以跳到受影响的产品列表，从产品的PCF变化也可以跳回到当时的能源曲线和工单记录。两个页面共用同一套归一化数据和同一个时间轴，所以它们对同一件事的解释是一致的：工厂不会说“效率提高了”而产品页面说“碳排上升了”。龙虎斗官网反复强调两条主线必须连通，龙虎斗App把这种连通做成了页面之间的跳转，而不是两套看板各说各话。

龙虎斗App运行一个“更换低碳供应商”的Scenario以后，为什么结果必须明确标成模拟值而不是新的正式PCF？

用户在龙虎斗App的Scenario页面选择：把铝壳体供应商从A换成B。系统调用Calculation Engine，用B提供的PCF、估算的新运输路线和当前的工厂数据重算，得到PCF预计从12.8降到11.6 kgCO2e。这个11.6是什么？它是一个Scenario：一个基于假设的预测值。它不是新的正式PCF，龙虎斗App用醒目的橙色“Scenario / Estimated”标签、独立的Scenario列表和禁止导出为正式报告的限制，把它与正式版本严格分开。数字为功能示意。

为什么11.6不是正式PCF？因为它依赖的三个输入都还不是事实。B的PCF尚未验证，可能还缺边界或年份字段，它在Confidence Ladder上的位置未定。新的运输路线是按B的地址估算的，实际的运输方式、承运商和装载条件要等第一批货发出以后才知道。采购决策本身尚未做出，工程认证尚未通过，合同尚未签订。三个假设中任何一个改变，11.6都会变。一个建立在三个未发生的假设上的数字，不能成为产品的正式属性。

Scenario Treated as Actual是这类系统最常见也最有害的错误。它的实际后果是：一个从未执行的方案“减排”了从未发生的碳，进入了月报、客户回复或对外声明。当客户后来索取证据时，发现供应商还是A，运输还是原来的路线，所谓的减排只存在于一次模拟里。这不只是数据错误，是信誉问题。龙虎斗App在数据结构上把Scenario和Actual分开存储，Scenario不能被选为“当前版本”，不能导出为正式报告，不能进入版本账本的正式序列。这是技术限制，不是提示文案。

Scenario应该保存什么？假设本身：换成哪家供应商，用了它哪一版数据，运输路线怎样估算，工厂数据用的是哪个期间。结果：预计的PCF、与当前版本的差异、差异在Contribution Tree上的分布。置信度：B的数据是什么等级，运输估算的不确定性多大。这些一起保存，用户几个月后回来看这个Scenario，仍然知道它当时基于什么、预计什么、有多可靠。

Scenario怎样与后来的实际对比？如果采购真的切换到了B，第一批货到了，B的数据经过验证进入系统，实际运输记录回流，新的正式版本产生。龙虎斗App把这个正式版本与当初的Scenario并排显示：预计11.6，实际11.9；差异0.3，其中0.2来自实际运输方式与估算不同，0.1来自B验证后的数据与初始数据的差异。这个对比是Scenario引擎改进最直接的输入，也是用户判断“AI的预测有多准”的依据。

Scenario转正的路径也要清楚。它不是把Scenario的标签改成Actual，而是：假设变成事实以后，用事实数据走一遍正式的Calculation Engine，产生一个带版本号的正式结果，在版本账本里记录“本版本对应Scenario S-0421的实际落地”。Scenario本身保留，作为历史记录。追溯链从正式版本可以回到Scenario，从Scenario可以回到当时的假设。

页面上，Scenario列表与正式版本列表是两个不同的入口，颜色不同，图标不同。在Scenario页面里的所有数字都带橙色标签，分享功能只能生成“模拟结果”格式的截图，截图上有水印。这些设计有些用户会觉得多余，龙虎斗App坚持这样做，因为一个Scenario被当成Actual的代价，远高于多看几个标签的不便。

龙虎斗官网反复说的一句话在这里落实成了产品：Scenario与Actual必须分开。AI可以模拟任何方案，方案的结果在被执行和测量之前，永远只是估算。龙虎斗App的工作是让这个区别在每一个页面上都无法被忽略。

Scenario页面还支持多个方案并排比较：换供应商B、壳体减重、改用高回收料牌号、提高Yield，四个方案各自的预计PCF、差异分布、置信度和已知的Cost与Difficulty放在同一张表里。表上没有“推荐”列，因为选择哪个方案取决于企业当下的权重，而权重不在数据里。用户可以把其中一个或几个方案标记为“待评估”，生成给采购、工程或生产部门的评估请求，请求里附带方案的全部假设和数据来源。评估结果回填以后，方案的Cost和Difficulty从“待评估”变成具体的判断，Impact仍然是Scenario。只有当某个方案真正被执行、Measure Result完成以后，它才从Scenario列表移到已落地列表，并链接到对应的正式版本。整个过程在页面上留下完整的记录：什么时候模拟的、谁评估的、什么时候批准的、实际结果与预测差多少。