流量计算机组态,AI 能配吗?

最近有朋友问我，做了这么多年计量，为什么开始折腾 AI？

说实话，动机不纯。

一是怕错过。不是怕某个工具，是怕那种感觉——等你回过神来，行业已经走了一段，而你还在问"这东西有什么用"。二是真的有惊喜。AI 进到我工作里快两年，改方案、查标准、整理文献、起草澄清问答——有些地方它做得比我预期好太多，有时候给出的角度是我自己不会想到的。

但有一点越来越清楚：这不是"升级一次就行"的事。

计量这行本来就没有"学完"的那一天。API MPMS 年年在修，AGA 报告在迭代，现场还有那些书上没写的细节。AI 只是把"终身学习"这四个字说得更重了一点。

所以我选择在用的同时，认真想：它到底能做什么，做不到什么？边界在哪？

最近把这个问题落到了一个具体场景：流量计算机组态，AI 能配吗？

组态里有两层：AI 看得见的，和看不见的

很多人觉得流量计算机组态是个"填表"工作——给定设备参数、选择计算标准、输入 K-factor 和参考条件，按格填完就行了。这个直觉不完全错。

AI 能做的那一层，确实接近填表。

让 AI 查哪台表用哪个 AGA 标准、算 CTL/CPL 修正系数、列出审计追踪的配置清单——它查得比你快，也查得全，这层没问题。

但流量计算机组态里还有另一层，不在任何手册里。

参考温度该用 20°C 还是 15°C？——不是查 AGA，是看合同。压缩因子用 AGA-8 Detail Method 还是 GERG-2008？——不是查表，是判断：这个工况的 CO₂ 含量是多少，AGA-8 在这里精度够不够。这台表的 K-factor 为什么比厂家证书低了 0.05%？——那是上次 FAT 现场发现的问题，记录在一封邮件里，不在设备手册里。

AI 看不见那一层，不是因为它不够聪明，而是因为那一层根本不在它能读到的地方。

更危险的是：组态错误不崩溃。

某国内天然气计量站的案例：贸易合同约定参考温度 20°C（中国 GB/T 标准惯例）。供应商调试工程师按欧洲默认值，将流量计算机组态设置为 0°C。FAT 验收通过了——双方代表核查了流量精度，核查了审计追踪功能，没有系统性验证组态参数本身。

系统运行了 8 个月。没有任何报警，数字每天正常更新，报表每月正常生成。买方年度审计时发现，月报数据持续存在约 0.7% 的系统性偏差，方向固定。往回查：参考温度错了，通过压缩因子计算传递到标准体积。

8 个月，买方多付了约 0.7% 的气量费用。

如果当初是 AI 生成这份组态，它大概率也会选 0°C——那是 AGA 标准里常见的参考值，欧洲项目的惯例。AI 不知道这个项目的合同约定了 20°C。

加了"脚手架"，能走多远

"那给 AI 更多上下文不就行了？"

这个思路对，也有上限。

AI 圈有个概念叫Harness——AI 运行的约束性脚手架：系统提示、工具访问、知识库注入、核查工作流。MiniMax Agent 首席架构师有个比喻：同一辆 F1 赛车，普通人开能顺利跑完就不错了，专业车手开才能刷世界纪录——差距不是车，是整套调校让性能发挥出来。AI 也是这样，要发挥最大能力，需要为它打造对应场景的 Harness。

Harness 越完整，AI 能覆盖的工作越多：

Harness 程度	能做到什么	覆盖不了什么
裸 AI	查标准、生成模板、回答单点问题	无项目上下文，不知道合同约定
注入标准文件 + datasheet	生成参数清单、标记缺失项、计算核查	不知道历史判断，无法验证隐性参数
+ 合同 + FAT 记录 + 核查工作流	覆盖大部分标准化配置工作，自动标记高风险参数	Harness 本身须由领域专家设计

但这里有个循环。

能设计出"注入合同条款、FAT 历史、项目特殊约定"这套 Harness 的人，恰恰是那个知道哪些参数高风险、哪些细节容易出问题、哪次 FAT 曾经出过事的工程师。

能设计好 Harness 的人，本身就是那个可以配好流量计算机的人。

用 4D 框架想清楚：每一步，你在哪里

Anthropic 在 AI 素养课程里提出一个4D 框架，把人与 AI 的协作分成四个维度：委托（Delegate）、描述（Describe）、辨别（Discern）、勤勉（Diligence）。

把流量计算机组态的每一步放进去，分界清晰很多。

委托——哪些步骤可以完全交给 AI？

查适用标准，这步可以交。计算 CTL/CPL 系数、做 AGA-8 算例核验——都可以委托。FAT 前整理一份组态核查清单，让 AI 根据 datasheet 和 API MPMS Ch.21.1 自动生成，比手工快 10 倍，而且不会漏项。这一层，AI 是你的效率杠杆，用起来。

描述——如何告诉 AI 要配什么？

这里有个悖论，很少被说破。

向 AI 精确描述一套流量计算机的组态需求，你得说清楚：这台表是什么类型，流体是什么，操作工况什么范围，引用哪套标准，合同约定的参考条件是什么，客户 DCS 的通信协议是什么，有没有特殊的 FAT 核查要求……

能把这些说清楚的人，也就是本来就能配这台流量计算机的人。

越不懂流量计算机，越无法向 AI 提出正确问题，AI 越帮不了你。帮助最需要的人，恰恰最难被 AI 帮到。

辨别——如何判断 AI 的输出是否正确？

这是最难的一步。AI 的组态输出通常看起来完整、专业、无明显破绽。发现它在哪里错了，需要比使用它更深的知识——知道这个工况的 CO₂ 含量已超过 10%、AGA-8 精度在此不足，应该切换到 GERG-2008，知道这个项目合同约定了 20°C 而非 15°C，知道上次 FAT 在 K-factor 上改过值。

Anthropic 2025 年对内部 132 名工程师的研究发现：仅0-20% 的工作可以"完全委托"给 Claude，高风险任务仍需人工验证。他们的委托原则很实在：优先委派"能比较容易地 sniff-check 正确性"的任务。

流量计算机组态，sniff-check 很难。

勤勉——最后一道门，也是最不能绕过的。

API MPMS Ch.21.1 §5.4.1 要求，Configuration Log 必须作为审计包的一部分存档，记录所有常量参数和计算方法。Ch.21.2 §12.3.2 进一步规定：每次更改影响计量结果的参数，都必须记录旧值、新值、日期和时间。

这份记录里，写的是工程师的名字和工号，不是 AI 的。

贸易交接计量争议发生时，审计追踪是唯一客观依据。签字的责任链，从来没有 AI 的位置。

该交给 AI 的那层，真的值得交——省出来的时间，用在辨别和核查上。

但辨别那份输出是否真的正确，勤勉地在签字前逐项核查——这两步，必须留在你自己手里。

配置单上签的是你的名字，不是 AI 的。

参考：API MPMS Ch.21.1-2013 §5.4.1；Ch.21.2-2016 §12.3.2；Anthropic AI Fluency 4D 框架（anthropic.skilljar.com/ai-fluency-for-educators）；Anthropic 内部工程师 AI 使用研究（2025.08，n=132）；MiniMax Agent 首席架构师阿岛（量子位圆桌，2026.04）