版本演进说明 (v1.0 → v2.7)

iRAS 项目从 2026 年初首发以来, 经历了 18 次重大版本升级, 每次都基于公开文献或工业项目实测数据校准, 不是经验调整。 本手册整合 v1.1 (2026 年 4 月) 物理框架重构 + v1.2 (热平衡建模) + v1.3 (工程化模块) + v1.4 (投资财务评价) + v1.5 (可研报告生成器) + v1.6 (站级设备 + UI 重构) + v1.7 (氧锥拓扑 + 系统排水重构 + 审计修复) + v1.9 (碳酸盐平衡求解 + o2 物理校准 + finance 零利率修复) + v1.9.1 / v1.9.2 (液氧消耗口径 + 蒸发系数量纲 + 通风口径 + 机械除湿机) + v1.9.3 (基线对齐与验证自动化) + v2.0.0 (热平衡架构重构 + 气液接触器) + v2.0.1 / v2.1 (缺陷修复 + 车间显热能量守恒 + 守恒类断言) + v2.2 (工况覆盖补盲 + 登记表声明自校验 + UI 审计 + 字段范围单一事实源) + v2.3 (第七轮审计处置: head 结构修复 + 加载路径钳制 + 曝气尾气入室 + 全局热工单源 + chart.js SRI) , 以及 v2.3 内后续四批工作 —— 简易模式 (自然通风车间自由空气节点求解 + 太阳辐射子系统首次建模)、池内曝气拓扑修正 (曝气强度约束 + sp 白名单跨模块同源)、车间模式三档 + 车间通风机建模、CO₂ 脱除机制澄清 + 浅池告警, v2.5 六批 (字段流转工厂化 + aerationMode 硬告警 configWarns + 空气曝气密度分界 40→30 + 空气曝气设计工况点与加载路径哨兵盲区 + 手册第 15 章追平代码), 直至 v2.6 (开源基建 + 液氧采购口径补生物滤池水侧耗氧 —— 氧锥按「鱼 + MBBR」选而液氧按「只有鱼」买, 锚定工况年耗 471 → 790 t) 与 v2.7 (财务 OPEX 基数接线修复 + 生物滤池设计 TAN 按盐度取行业口径 + NH₃ 独立校验 + 投饵率校准第一批 + 输入/结果分区重整) —— 的全部内容, 是 RAS 工程设计的完整参考。

〔v2.2 注: 本段此前停在 v2.0.0 —— v2.1 与 v2.2 两批工作都只加了下方的版本演进章节, 而没有更新这段总览。同一事实 (手册覆盖到哪个版本) 散布于封面副标题、封面页脚、本章标题与本段共四处, 改一处不改其余。已加入 t21 三文档判据, 下次漏改会转红。〕
〔v2.3.3 文档批订正: 上句最后一条不成立。 实测 v2.3 → v2.3.3 期间四处全部漏改而自检 29/29 全绿 —— 当前 29 项里管版本的只有 meta_version_consistency, 且只查 index 页内 meta。根因不是判据写漏了, 而是页面内自检运行在 index.html 的 DOM 里, 根本读不到 manual.html 与 README.md, 这个判据在浏览器内原理上就做不成 —— "t21 三次扩展全部落空"由此得解。现改由工具侧门禁 tools/check_doc_version.js 承担(node 可同时读三个文件), 四处口径已随本批订正到 v2.3.3。⇒ 纪律 12: 注释里写"已被断言覆盖"不等于真被覆盖 —— 声称有防线时必须同时给出该防线失败时的可见信号。〕

v1.0 → v1.1: 物理框架重构 + 文献校准

A. 严格分离三个时间尺度

v1.0 在 calcStageLoad 中用 feedDesign = feedMax × peakFactor 算所有"日产污染物"。但 feedMax 已是日峰值, 再乘 1.2-1.5 在量纲上是"日总量再放大", 所有下游负荷被一刀切偏大约 17%。v1.1 严格分离三个时间尺度:

• 日尺度 (kg/d): feedMax = biomass × feedRate, 用于 OPEX/换水/化学品/沿程水质
• 小时峰值 (kg/h): xxxPeakHourly = xxxDaily/24 × peakFactor, 用于设备容量选型
• 全周期日均 (kg/d): feedAvg = yearGrowth × FCR / 365, 用于年化 OPEX

peakFactor 物理意义钉死: 代谢污染物 (TAN/O₂/CO₂) 小时峰值/全日均速率, 默认 1.5 (Timmons & Ebeling 2010 标准)。

B. 设备按动力学分类选型

C. 鱼生理耗氧按物种 + 温度自动算

v1.0 用 0.25 一刀切违背物种特性差异。v1.1 改为按物种 + 温度自动算:

D. CO₂ 脱气塔独立建模

v1.0 没有 CO₂ 脱气塔模型 (仅在增氧节点扣 70% 写死)。v1.1 作为独立设备建模, 默认参数与 Delta Cooling Towers 工业项目实测对齐: G:L=3, 风压 2.5 kPa, 风机效率 0.60, 单次脱气率 65%。

E. 大菱鲆密度修正

v1.0 大菱鲆 15/30/40 kg/m³ 偏低 (与莱州东方海洋等循环水项目实测 50-70 kg/m³ 不符)。v1.1 调整为 25/50/60 kg/m³。修正后大菱鲆综合成本从 81.5 元/kg → 48.1 元/kg, 与国家海水鱼产业体系 2019 调查数据 (46.32 元/kg) 偏差仅 +4%。

F. CAPEX 折旧 + 系统体积建模

v1.1 设备 8 年 + 土建 20 年分别折旧, 加到日运行成本。引入完整 V_total = V_tank + V_process 建模 (典型 V_process 占 V_tank 的 30-60%)。换水率口径改为 V_total (行业标准 Timmons 2010 / 国家海水鱼体系)。详见第 8 章。

v1.1 → v1.2: 全局气候 + 双节点稳态求解

G. 项目级常量管理

v1.1 把热平衡参数(气温/源水温/U 值/换气率) 放在每个阶段的 proc 字段里, 用户必须在每个阶段重复设置。 工程现实中这些是项目级常量。v1.2 把所有热平衡参数挪到顶部全局配置区 globalThermalConfig, 作为项目级常量影响所有阶段。新增地区预设(青岛/海南/挪威 Bergen/法罗群岛)、围护预设、4 工况对比(冬/夏/年均)。详见第 28 章。

H. 双节点稳态求解器

v1.1 用单点能量平衡, 忽略车间空气节点。v1.2 改为双节点 Picard 迭代同时求解空气热平衡 + 空气湿平衡, 输出 T_room、RH、蒸发率/凝结率、热泵装机。详见第 29 章。

I. 围护结构详细建模

v1.2 引入完整车间围护参数: U_wall / U_roof / U_floor / U_window / windowRatio / airChangeRate / ventHeatRecovery / poolCover。详见第 28 章。

v1.2 → v1.3: 多模块并联 + 工程化

J. 模块化与 N+1 备用

大型项目(>1000 t/yr)拆成多模块并联: 每模块独立循环, 模块间共用液氧站/应急电源/控制中心。每模块内部按容量上限自动配 N+1 备用 (主泵/风机/RDF/UV/热泵)。模块数完全由用户在阶段卡片"🔧 套数" subSystemCount 决定。详见第 26 章。

K. 鱼池配置反推

用户给"每套池数 + 池深", 工具按总水体反推单池直径 D = √(4V/πH)。自动检查工程合理性: D < 4m / D > 30m / D > 20m 配 H < 3m 给告警。SPECIES_DB 各鱼种各阶段加入推荐池深 recDepth_m。详见第 27 章。

L. P&ID 工艺图自动生成 (v1.3.x)

独立的 pid.html 查看器, 主页面"📐 输出 P&ID"一键打开, 自动渲染主流串联 + 3 条旁路 + 公用工程 + 仪表泡泡 + 联锁线 + 设备表。LOX 跟随阶段切换。详见第 30 章。

M. 设备清单导出 (v1.3.x)

独立的 equipment.html 页面, 一键导出当前方案完整设备规格表, 含 N+1 备用展开 + 单价 + 合计金额, 支持打印/导出 PDF。详见第 31 章。

N. 池深统一数据源 (v1.3.x)

v1.3 早期版本中池深有两个独立输入(阶段卡片头 + 热平衡区), 容易混淆。v1.3.x 统一为一个数据源: stage.poolDepth_m → recDepth_m → proc.poolDepth → 1.5。同时用于池径反推 + 热平衡。详见第 27.5 节。

O. 共用车间散热系数 (v1.3.x)

各阶段独立估算的散热相加 × thermalSharingFactor (默认 0.75) = 全场总散热, 反映多阶段共享车间的工程现实(共享外墙节省散热约 25%)。详见第 29.7 节。

P. 集水池建模 (v1.3.x)

V_process 加入集水池项 V_sump = clamp(Q/30, 20, 200) m³, P&ID 加入 S-101 标识。

v1.3 → v1.4: 投资财务评价

Q. 8 张标准财务表 + NPV/IRR + 敏感性分析

v1.3 输出停在工程概算 (CAPEX 万元 / OPEX 元/kg), 用户拿这个数据再去 Excel 手算财务评价 (NPV/IRR/回收期) 是当前主要的工作流痛点——一份可研报告里财务评价占 30% 篇幅, 设计院通常要花 1-2 周做完。 v1.4 加入独立的投资财务评价页面 (finance.html), 主页面"💰 投资财务评价"按钮一键打开, 按发改委可研编制规范输出 8 张标准财务表:

1. 投资估算表 (设备 / 土建 / 流动资金)
2. 资金来源运用 + 还款计划 (等额本息 / 等额本金)
3. 总成本费用估算表 (满产年, 含折旧+利息)
4. 销售收入和税金表 (按爬坡逐年)
5. 损益表 (逐年净利润)
6. 现金流量表 — 全投资 (项目本身 IRR)
7. 现金流量表 — 自有资金 (股东 IRR, 含贷款杠杆)
8. 敏感性分析 (5 因子 ±20% 对 IRR 影响)

用户在页面顶部填 17 个参数 (售价、项目年限、产能爬坡、自有资金比例、贷款利率、折现率、所得税等), 计算引擎用逐年现金流模型 + Newton-Raphson 求 IRR, 实时输出关键指标。 支持一键导出 Excel (用 SheetJS, 7 个工作表) 和打印为 PDF。详见第 33 章。

R. 关键指标定义对齐国内规范

v1.4 财务评价 6 个关键指标的定义全部按国内可研规范:

S. iRAS 整体架构演进

从 v1.0 到 v1.5 共 1 年多时间, iRAS 完成了从"单页工程概算"到"完整可研工作流"的演进:

v1.4 → v1.5: 可研报告生成器

T. 16 章扩展版可研报告自动生成

v1.4 之前的输出层级停在工程数据 (P&ID / 设备清单 / 财务表 Excel), 用户需要把这些数据手动整合到一份 Word 可研报告里。 一份政府版可研通常 80-150 页, 设计院做一份要花 1-2 个月。v1.5 加入可研报告生成器 (report.html), 按发改委编制规范输出 16 章扩展版可研, .docx 格式, 大幅压缩可研撰写时间。

v1.5 严格遵循以下技术决策:

1. 结构化内容输出, 不替设计院排版 — 生成的 docx 是"内容产品", 用户复制粘贴到自己院的 Word 模板即可
2. 纯模板 + 条件分支, 不用 LLM — 可研是法律文件, 模板生成有可追溯性, 不能赌幻觉
3. nunjucks 模板引擎 — Jinja2 JS 移植, 语法标准, 可后续移植到 Python 后端
4. docx.js 文档生成 — 浏览器侧生成, 无后端依赖, 单文件部署
5. 模板内嵌 script 标签 — 保持 iRAS"双击 HTML 即用"的传统

U. 16 章覆盖范围与自动化率

加权平均自动化率约 70%, 用户需要补充的主要是项目身份信息 (业主名/地址等 20 字段)、场址自然条件、土建详细设计、消防/环评/安评等专项内容(这些必须由有资质机构出具)。

V. 工艺流程图 + 财务图嵌入

v1.5 在 docx 中嵌入 3 张自动生成的图:

1. 图 5-1 工艺流程示意图 — 6 个主流程方框 + 主循环回流 + 旁路单元(蛋分/反硝化/AOP, 按是否启用动态显示)+ 关键工艺参数表
2. 图 13-1 累计现金流曲线 — 实线全投资 + 虚线自有资金, 含 0 轴线、网格、图例、节点标记
3. 图 13-2 敏感性 Tornado 图 — 5 个因子按 IRR 摆动从大到小排序的横向条形图

图表生成路径: 浏览器侧 SVG → Canvas → PNG → docx ImageRun。中文字体使用系统 SimHei/Microsoft YaHei, 高清 2× DPR 渲染。

v1.5 → v1.6: 站级设备 + UI 重构 + 工程逻辑精化

W. 液氧储罐站级化(核心改动)

v1.5 之前, 液氧储罐 (V-901) 作为阶段级设备计入 calcCapex, 每个阶段独立挂一笔储罐 CAPEX。 但 RAS 工程实际是全场单点供应: 多个阶段共用同一座液氧站, 计 4 次显然错误。 4 阶段千吨级项目可虚报约 30 万元 CAPEX。

v1.6 把液氧储罐从阶段 CAPEX 剔除, 挪到全场"③ 站级设备"区域, 增加 calcSiteCapex(stages, eqPrices, allResults) 函数计算站级 CAPEX 并加入工程总投资。用户可在 ③ 区调整规格 / 数量 / 单价, iRAS 按全场日耗自动推荐:

单价按规模指数公式 P = 100,000 × (size/3)^0.6 取值, 经标准档列表: 1 t ≈ 5 万 · 3 t = 10 万 · 5 t ≈ 14 万 · 10 t ≈ 22 万 · 20 t ≈ 35 万 · 30 t ≈ 47 万 · 50 t ≈ 65 万 (元/罐)。

P&ID 图 (V-901) / 设备清单 / 可研报告 全部同步显示规格 + "全场共用"标注。

X. UI 整体重构

v1.6 把 iRAS 主页面从"一长条信息流"重构为可扫描的工程师视角:

• 3 个顶部 section + 阶段卡片 + 鱼种区全部可折叠 — 用 <details open> 替代 <section>, 用户可按需折叠看不到的区
• 双行 sticky 工具栏 — 项目级按钮(P&ID/设备/财务/报告/手册)与阶段级按钮(导入/导出/重置)分两行, 滚动时常驻顶部
• 4 KPI 卡片 2×2 网格 — 综合成本 / OPEX / CAPEX / 用地, 配色统一冷色 (cyan/emerald/teal/sky)
• 配色克制化 — cyan 主操作, slate 次操作, rose 危险/v1.6 主色, 取代之前过多的彩色按钮
• 财务参数独立到顶部 — 售价/电价/年限/折旧/区域系数/规模指数 6 项与设备单价分离 (① 区)

Y. 工程逻辑精化

Z. v1.5 → v1.6 公式订正表

v1.5 代码已经修复但本手册之前未同步的几处公式:

v1.6 → v1.7: 氧锥拓扑 + K-101 + 系统排水重构 + 全面审计修复

A. 氧锥工艺拓扑 mainline / bypass 真实区别对待

v1.6 之前, iRAS 在 UI 上已经有"主流路径 / 旁路(节能)"两个选项, 但 calcPumpPowerBreakdown / aerationSpec / OPEX 完全没区分 — 是"UI 假承诺"。v1.7 通过全网调研 (Linde SOLVOX cone / Pentair AES Speece / PR Aqua PPC / Global Seafood Advocate 2019) 确认: 国际主流大型 RAS 项目"more often plumbed in side stream configuration"。原因是氧锥操作压力 10-21 psi (玻璃钢上限) 或 1-3 bar (SOLVOX), 让主流全部过氧锥意味着主泵要承担额外 3-5 m 压头, 而旁路只让 10% 流量过高压锥, 主泵不过锥, 能耗显著下降。

v1.7 新增 5 个工艺字段 (PROCESS_DEFAULTS + UI 输入框 + 工程范围钳制):

物理改动:

• 主泵实际扬程 = mainPumpHead + o2ConeHeadLoss (mainline) 或 = mainPumpHead (bypass, 主泵不过锥)
• 氧锥规格 towerFlowM3h 随拓扑变 (mainline = Q 全流量, bypass = Q × ratio 小流量)
• 旁路泵 P-602 加入设备清单 / CAPEX / OPEX / 热平衡, 1+1 备用模块化
• P&ID 自动重画 bypass 模式: A-601 旁路三件套 (取水点 + 高压锥 + M-601 混合点) + P-602 旁路泵

B. K-101 鱼池增氧鼓风机 (air 模式专属)

v1.7 之前, air 模式 (空气曝气) 只有 K-302 (BF 曝气风机), 缺鱼池主增氧风机。 这意味着温水鱼种 (罗非鱼 / 鳗鱼 / 对虾) 的大规模 RAS 设计无法用工具自动生成 — 而这是 80%+ 中国 RAS 项目的实际场景。

v1.7 加入 K-101 鱼池增氧鼓风机: 罗茨风机 + 微孔盘管曝气, 与 K-302 同口径 1+1 备 (鱼池主增氧故障即鱼窒息, 必须双机轮换)。P&ID / 设备清单 / 报告章节 / 财务测算 全链路同步, modulePerSpec 含完整规格 (风量 Nm³/min / 功率 kW / 风压 kPa / 效率 %)。

C. 系统排水重构 (RDF 反冲废水 → 系统排水)

旧版工艺面板"RDF 反冲(%) 2%"是反冲管瞬时分流比, 但 4870 m³/d ÷ V_total = 101%/d 物理荒谬 (远超合理换水率 1-5%/d)。真相: RDF 反冲水绝大部分经污泥沉淀池回循环 (Sharrer 2010 实测 95-98% 清液回流), 真实穿越系统边界的废液由换水率决定。

v1.7 全面清理:

• UI 删 "RDF 反冲(%)" + "反冲泵 H/η" 3 个输入框
• 反冲泵不再独立设备 (RDF 厂家整体出厂含反冲泵, 工程实际)
• 字段 rdfBackwash / rdfBackwashPumpHead_m / rdfBackwashPumpEta 从 PROCESS_DEFAULTS / readStageProcFromInputs 删除
• 新增"📤 系统排水"卡片 (取代"🗑️ RDF排污"卡片):
  • 流量按 V_total × exchangeDaily 算 (与"换水率"定义一致)
  • TAN / NO₃ 按 V_disch × C_tank (溶解态稳态)
  • TSS 按质量守恒 (含污泥进沉淀池, tooltip 明确说明此为沉淀池入口浓度, 不可直接对照 GB 8978 — 沉淀池后才是污水管口)
• report.html 第 9 章环评章节同步重构

D. 全面审计修复 (27 项 bug)

v1.7 发布前进行了一次彻底审计, 覆盖 Level 1 (静态扫描) + Level 2 (jsdom 三工况数值验证) + Level 3 (核心计算函数逐项审查), 共发现并修复 27 项 bug:

E. v1.7 验证状态

v1.7 工况成本基线 (1000 t 大西洋三文鱼)

📌 历史数据：本章记录的是 v1.7 当时的成本基线，用于说明氧锥 mainline / bypass 两种拓扑的差异。这些数字已被 v1.9 / v1.9.2 / v1.9.3 / v2.0.0 / v2.1 多次重算覆盖， 不代表当前版本。当前基线见「v2.1 → v2.2」章节与主页自检基线 （?selftest=1）。结论层面的 mainline vs bypass 对比仍然成立。

对比 mainline 与 bypass 两种氧锥拓扑在挪威 Bergen 气候下的全工况成本:

工程结论: 1000 t 三文鱼项目采用 bypass 拓扑相对 mainline: 泵综合节能近 30 kW (年电费节省 17 万) + CAPEX 工程总投资节省 1,346 万 + 综合成本省 1.29 元/kg + 全投资 IRR 提升 2.4 个百分点 + 静态回收期缩短 0.62 年。 这与国际主流大型三文鱼 RAS 多采用 side stream 拓扑的工程实际一致 (Linde SOLVOX / PR Aqua PPC / Global Seafood Advocate 2019)。

历史 4 工况成本基线 (v1.3 数据, 沿用)

iRAS 不计算人工 / 苗种 / 管理费等"软成本" (合计 15-20 元/kg), 综合成本通常比文献项目实际偏低。 对照 Nordic Aqua 宁波 (中国境内唯一商业化运营的 RAS 三文鱼项目, AKVA Group 技术) 2024 年 Q2 实测生产成本 41 元/kg (EUR 5.23/kg) — iRAS 36.70 + 软成本 ~5 元/kg = 41.7 元/kg, 与 Nordic Aqua 实测完全吻合 ✓

v2.1 → v2.2: 工况覆盖补盲 · 登记表声明自校验 v2.2

源于第三方第六轮审计。审计核心判断:「断言的质量已超过工况的覆盖面 —— 下一步的收益在加工况, 不在加断言」。本版照单全收: 自检 17 → 20 项, 13 条数值基线重算 (|Δ| ≤ 0.02 元/kg, 符号随工况方向翻转)。

A. 三条配置边界工况

此前 13 条数值工况全部「mainline 拓扑 + 脱气塔开启 + 纯氧增氧」。新增 edge_no_degasser / edge_bypass / edge_air_aeration 三条配置边界工况, 只跑不变量断言、不比数值。落地顺序刻意为先加工况 (转红) 再修缺陷 (转绿) —— 红→绿转换即工况有效性的负对照。

B. 蛋分风机 CAPEX 解嵌套 + ΔT/mdot 不动点迭代

CAPEX 嵌套: 蛋分风机条目原嵌在脱气塔 if 条件分支两层内, 脱气关闭时蛋分照常运行照常计费、投资却消失 —— F4 目标模式第四次出现, 且在修复它的同一次提交里。现与各独立设备并列。

ΔT/mdot 不自洽: 风机温升按冷密度算、焓流按热密度算, 丢失 (1−mdot/mdot₀) 份轴功 —— 默认工况 1.2%, 脱气关闭时 ΔT≈30 K、丢 10.1%。现做不动点迭代解联立至 mdot·c_p·ΔT ≡ P_shaft, 附录 B 的 dT_blower / mdot 自此严格同一状态点 (即「mdot 自洽」)。

C. 轴功 η 逐台加权

旧口径 ΣkW × 0.57 与各风机效率参数脱节 (用户调高效率, 模型反而认为进气流的热更少)。物理上 kW_i×η_i = Q·Δp 与 η 无关, η 只影响电机损失分成 —— η 逐台加权自动恢复该性质, η 与各功率公式严格同源 (co2 读 co2BlowerEfficiency, bf 取公式内常数 0.60, skimmer 读 skimmerBlowerEta, 鱼池增氧读 tankAirBlowerEfficiency)。

D. 第四台风机接入 + 断言 E2b

空气曝气模式的鱼池增氧鼓风机 K-101 此前登记表与气路都看不见 (计费有、CAPEX 有、热去向无、气路无) —— 与 Q_air_gain (v2.0)、蛋分气流 (v2.1)、风机轴功 (第五轮) 同族的第四次逃逸, 机制是关键功率藏在混合数值与格式化字符串的展示对象里。现全量接入 (airFlowM3h + airPath + 登记表 + 轴功加权)。新增断言 E2b 递归扫 *Spec 子对象封住该逃逸类; 治本方案 registerDevice 工厂化已立项 v2.3。

E. capexVia 精确名称数组 + capexMinKw

capexVia 由正则改精确名称数组: 旧正则假阴性 (删掉真目标仍绿) 与假阳性 (bypass 下 F4 四阶段误报) 双向皆错。五台支路泵显式声明共享「支路泵合计」聚合条目。精确化随即曝光被掩盖四版的存量不一致 —— BF/脱气塔风机 CAPEX 选型门槛 0.5 kW vs F4 的 0.05 kW, 现以 capexMinKw 显式声明进登记表, 与 CAPEX 侧选型门槛同源。

F. 断言 G: 登记表声明自校验

堵 v2.1 明示的最后盲区 (「billedVia 可以指向不存在的成本字段而断言不会发现」)。断言 G1 落地当天抓到 5 条活体: 声明写的是内部变量名 *CostDaily, cost 导出面是 *CostMax/*CostAvg —— 与第六轮审计连错两轮的 dehumCostDaily 同一个坑 (billedVia 声明必须真实存在于导出面, 设备活跃时非零)。G2 防同一 CAPEX 条目被重复认领。

G. 其他

skipClimate 删除: 全库零调用点的死参数 (restoreState 不经 loadStagesFromDB), 为不存在的调用方准备的开关只会在被忘传时静默伤人。渲染与计算解耦: 渲染抛错此前被计算 catch 吞掉伪装成「计算异常」并销毁结果, 现独立捕获、标注「渲染异常, 计算结果有效」—— 负对照双向实测 (修复前渲染故障使 13 条数值全灭为 0, 修复后零影响)。审计误报驳回: NH₃ 阈值与 Ω 告警两条「六轮未动」为第四轮已驳回误报的复发 (v1.9.3 起在位); 接触器进气节点不可选为记录在案的设计决策。

v2.2 第二批: UI 审计 · 字段范围单一事实源 v2.2

源于本版的首次 UI 专项审计。与第一批的登记表工作是同一个模式在 UI 侧的实例。自检 20 → 21 项, 13 条数值基线逐位不变 (纯重构)。

A. 填 0 → 界面回显默认值 → 输入被静默丢弃

用户填 0 → 模型收 0 → 重渲染后输入框显示默认值 (模板把 0 当 falsy) → 再改任何别的字段, 全量读回时假显示值覆盖 proc, 用户设置无声消失。陷阱在三层 (渲染 / 读取 / 消费), 只修一层反而更糟: 实测只修渲染侧会造成「界面诚实显示 0、模型仍用默认值」, 而原状态至少界面与模型口径一致。三层必须同批落地。

B. FIELD_SPEC —— 范围的单一事实源

取值约定此前散布四处 (默认值表 / 渲染模板 / 读取侧钳制 / 消费侧兜底), 实测已漂移四条: co2StripperEff 三处三值 (65/65/75)、co2StripperGtoL 事实源 v2.0 改 3→5 而副本停在 3、co2PackingHeight_m 1.5 vs 1.0、climateRegion 事实源与消费侧不同。这些副本平时是永不触发的死代码, 故漂移无人发现 —— 直到用户填 0 让它们复活。

FIELD_SPEC 只管范围 (min/max/step/clamp), 默认值仍归 PROCESS_DEFAULTS, 由断言 H 保证对齐。clamp 取 UI 范围与原钳制的并集 —— 机械规则, 不收紧现有能力, 无回归风险。同时消灭: UI 范围与代码钳制不一致 (7 字段)、22 字段无钳制、同字段多处渲染矛盾 (3 处)。

C2. 覆盖扩展与 clamp 规则修正

第一版 FIELD_SPEC 只收了原本带 min/max 属性的 34 个字段, 另有 22 个字段完全无钳制 —— 实测 mainPumpEta=0 使主泵报 1383.6 kW (成本 +6.6 元/kg)、VTR20=0 使成本 +12.0 元/kg, 全部有限无 NaN: 危害是「看起来正常的错误数字」, 会原样进可研报告, 比 NaN 难发现得多。现已全部接入 —— 依据取自各字段自己的 title 提示 (22 条无一缺失地写明了工程范围, 只是从未落到属性上)。本批 min/max 取 tooltip 的工程范围, clamp 取更宽的物理边界 (第一批那些字段的 UI 范围本身就是硬边界, 本批多为典型值区间, 当硬边界会挡掉合法探索)。

并集规则的缺陷: 第一批的 clamp = UI 范围 ∪ getNumClamped 漏了第三个来源 —— 消费处的 Math.max(x, 下限)。它与前两者性质不同: 前两者是允许区间 (并集 = 不收紧能力), 后者是物理硬保护 (必须遵守而非并入)。后果: co2BlowerEfficiency 的 clamp 是 [0,100] 而消费处写着 Math.max(η/100, 0.3) —— 用户填 0 时 proc 存 0、界面显示 0、模型实际用 30%, 而 t22 一直报「保真 ✅」(它检查的三个量全在 proc 层, 看不见消费处)。规则修正为 clamp_lo = max(消费处硬下限, 原下限), 并撤除全部 8 处隐式兜底。至此 66 个输入字段零裸奔。

删除死控件 sourceTemp: 双证据确认 —— 静态全库无消费点、动态填 -99 结果逐位不变。源水温自 v1.2 起归全局气候 (T_source_annual 等), 本字段是当时未清理的残留。给死控件加钳制等于承认它还活着, 故删而不修, 与第一批删 skipClimate 同一原则。

C3. 物质平衡实测 (本版仅验证, 未建断言)

发布前对四条基本物质平衡做了产品路径实测 (三文鱼 1000 t): 氮 (TAN) 残差 0.08%、硝酸盐 0.00、CO₂ 0.13% (即换水那份)、TSS −1.8% —— 前三条闭合, 说明稳态方程是自洽解出的。TSS 的 −1.8% 四阶段同号且随规模成比例, 但未确证为模型缺陷 (更可能是核算漏了排污股)。

⚠ 需要明确记录的是: 现有断言覆盖能量 (A1/A2/A3/B/C)、水量 (F1/F2/F3)、登记 (D/E/G)、资本 (F4), 没有一条物质平衡断言。即今天闭合是因为公式恰好写对, 不是因为有东西防止它写错。氧平衡、碱度平衡、碳酸盐体系 (carbonate.js 与主模型的交叉一致性) 三项连"今天是否闭合"都未测过。已列为下一版首要工作。

C. 断言 H 与判据盲区

新增自检项 field_spec_consistency (H1 渲染与表逐位一致 / H2 clamp ⊇ UI 范围 / H3 默认值存在且在范围内)。⚠ 记一条判据盲区: t22 检查的量全在 proc 层, 消费侧的 || 不影响 proc, 故 t22 结构上覆盖不了第三层 (负对照实测无反应), 另补静态判据 t23。一条判据绿了不等于该层被覆盖。

以下三章为 v2.2 发布【之后】的持续加固 —— 不改变 v2.2 的功能范围, 只增加护栏与修正: 第三方独立复核处置 → 物质平衡断言 M → 碳酸盐接口一致性 · a11y · CDN 加固。v2.2 本体的两批发布内容见上方「v2.1 → v2.2」与「v2.2 第二批」两章。

v2.2 第三方独立复核处置 2026-08-08

一份独立复核报告 (jsdom 走真实产品路径 + PyCO2SYS 1.8.3.4 / USGS·APHA 溶解氧表 / ASHRAE·IAPWS 湿空气数据 / 第一性原理手算) 提出三条模型误差, 全部落在本版自述的断言盲区 (氧侧 / 碳侧 / 水汽侧)。逐条实测核实: 一条采纳、一条部分采纳、一条驳回。

✅ 采纳: co2DailyAvg 漏硝化产 CO₂ (已删除)

co2DailyAvg = o2FishDailyAvg × 1.375 只算呼吸, 缺硝化项 tanDailyAvg × 6.286 × (1 − BF_CO2_STRIP), 实测少算 34.5%–43.4%。设计口径 co2Daily 是对的 —— v1.9 memo F2 修过同一个 bug, 设计口径已修而日均口径未跟上。全库 0 消费点, 属死字段, 故删除而非修正 (与删 sourceTemp 同一原则)。带错误公式的死字段比空字段危险: 谁把它接进年度碳核算会静默低估三四成且不触发任何断言。

◐ 部分采纳: 0°C 以下饱和水蒸气压 (只订正注释)

复核指出应使用冰面式, 数值属实 (−20°C 时水面式高 21.97%), 原注释的适用下界 −20°C 不成立。但本项目继续用水面式且自洽: RH 数据源为「WMO/Climate.gov 30 年均值」, 而 WMO 对 0°C 以下的 RH 以水面 (过冷水) 饱和压定义; humidityRatio 用同一相态还原分压, 前后一致。改冰面式而 RH 仍是水面口径, 反会使含湿量系统性偏低。相态必须与数据定义口径一致 —— 这是选水面式的理由, 不是疏忽。已订正注释区间为 [0, 60]°C 并写明依据。

✗ 驳回: 海水 DO 饱和度「单向偏高 3.3%」

复核建议「改用 Benson & Krause (1984)」—— 而代码用的就是该式本身: S ∈ {0,30} × T ∈ {10,15,20,25,28,30} 共 12 点, 与 B-K 标准式偏差全部 0.0000%。报告「参考值」反解出的盐度为 ≈35.5‰, 而对比的是 iRAS 在 S=30 的值 —— 拿 S=35 表值比 S=30 计算值, 差的 3.3% 正是盐度效应本身。报告自己写着工况盐度 28–30‰; 其 28°C 行「iRAS 6.410 / 参考 6.41」数值相同却标 +3.33%, 该 6.410 实为 T=30 的值, 表格行错位。

📌 此条与第六轮审计的 NH₃/Ω 误报同类: 基准取值与被测对象的工况参数不一致。复核方法本身正确, 出问题的是基准侧的参数对齐。

复核通过项 (记录备查)

化学计量 8 项对第一性原理手算全部吻合 (硝化耗氧 4.57 / 耗碱 7.14 / 反硝化回碱 3.57 / 硝化产 CO₂ 6.286 / 呼吸产 CO₂ 1.375 等); 碳酸盐体系对 PyCO2SYS 1.8.3.4 共 1400 工况, 淡水 pH 一致到机器精度 8.88e-16、海水最大偏差 1.78e-05、Ω_calcite 相对误差 0.0082%; 能量守恒 B 断言残差 0.000e+0、A 断言 1.57e-14%。这些正是本版断言已覆盖的区域 —— 与「三条缺陷全在盲区」互为印证。

物质平衡断言 M v2.2 后续

此前断言覆盖能量 (A1/A2/A3/B/C)、水量 (F1/F2/F3)、登记 (D/E/G)、资本 (F4), 唯独物质平衡一条没有 —— 而它是本工具的物理核心。第三方独立复核印证: 三条缺陷全部落在无断言区。实测确认今天全部闭合后立即固化 —— 闭合状态是免费拿到的验收基线。

断言清单

M1 氧-构成 总需氧 = 鱼呼吸 + 硝化 + 异养 · M2 氧-硝化 硝化耗氧 = TAN × 4.57 · M3 氧-供给 液氧耗量 = 鱼呼吸耗氧 / 吸收率 · M4 碱度链条 净额 = 消耗 − 回收, 投加 = max(0, 净额 − 补水带入), 药剂 = 投加 / 0.595 · M6 碳-构成 CO₂ = 呼吸 × 1.375 + TAN × 6.286 × (1 − BF 内脱气)。

负对照复现了历史上真实发生过的 bug

把过去修过的缺陷形态注回代码: M6 ← CO₂ 漏硝化项 (复核 BUG-2 形态) 报 −41.5%, 与报告实测同量级 —— 若 v1.9 之前就有这条断言, 那个 bug 根本写不出来; M3 ← 液氧用总需氧而非鱼呼吸 (v1.9.2 修过的口径混淆) 报 +104.7%, 与当年「高估 1.65 倍」同量级; M2 ← 4.57 改 4.60 报 +0.656%。

M4b 落地当场咬中 edge_yield_0 / edge_yield_tiny 八条: 零产量时补水带入碱度超过消耗, 净需求为负而 alkToAdd 钳到 0。核实后确认钳制正确 (不可能投负量药剂), 故改断言纳入下钳而非改代码。

建立过程的教训

外部核算这三条口径连续错了三次: 液氧误用设备选型口径 o2Demand (含容量系数, 报 −48% 假不闭合)、碱度消耗误用 tanDaily 而非被硝化的 TAN、碱度回收误用理论 3.57 而非代码里的工程系数 2.8。同族「猜口径」已达十次。这正是要把核算放进产品路径的理由 —— 断言从真实导出面取值, 不会像外部工具那样猜错口径。

碳酸盐接口一致性 · a11y · CDN 加固 v2.2 后续

A. 碳酸盐模块的【接口】验证

第三方复核验证的是 carbonate.js 模块本身。但主模型与它之间隔着一层单位换算 (TA = 碱度/50043/ρ、CO₂ = 浓度/44010/ρ), 那一层从未验证 —— 三个因子任一错, pH 与 Ω 都会偏而无人察觉。

I1 往返自洽: solveAlk(pH*) → solve(TA) 还原 pH*, 240 点网格最大 |ΔpH| = 0。I2 换算层: 手工复算与模型逐位相同 (Δ = 0)。I3 双副本: 独立文件与内联块 20 个函数、63 个平衡常数, 归一化 md5 完全相同。

📌 真正的风险不是「当前是否一致」(是), 而是将来会不会漂移 —— 同一份求解器存在两处, 没有任何东西阻止有人只改一处。I3 即为此而设。

B. a11y 与窄屏

163 个 label 零个有 for, 输入框全部无 id —— 点击标签无法聚焦输入框, 是所有人都损失的常规交互 (工艺参数标签仅 10px)。现按 f_{idx}_字段名 生成 id 并关联 65 处。31 个表格中 12 个未包 overflow-x-auto, 已全部包裹。新增自检: 输入框必须有 id、for 不得悬空、表格必须可横向滚动。

📌 实施教训: 正则改了三轮仍漏 1 处 —— Python re 在超长 title 属性上回溯超限后静默放弃匹配。改线性扫描后一次到位。这与 t21 三次扩展全部落空同形态, 两次都是断言先报出数目不对才发现的。

C. CDN 加固 〔v2.3 注: 本节「不填哈希」的状态已被 v2.3 关闭 —— SRI 已按 npm 包内真实发布件落地, 且原 URL 的 .min.js 实为 jsDelivr 动态压缩产物、包内不存在, 详见「v2.2 → v2.3」章 E 节〕

Tailwind Play CDN 动态生成响应体, SRI 哈希无法预先计算 —— 技术限制而非疏忽。chart.js 是固定文件, 可以且应该加 SRI, 但本版不填哈希: 当前拿不到真实值, 而编造哈希会让浏览器拒绝执行脚本、图表直接消失, 比没有 SRI 更糟。只加 crossorigin 并把取真值的命令写进注释。📌 与「判据先负对照证明会红」同源: 安全措施也不能靠猜值上线。

v2.2 → v2.3: 第七轮审计处置 · 结构断言 v2.3 · 2026-08-10

第七轮独立审计报出两条严重回归, 共性诊断准确: 都是一次正确的重构越过了自己的边界, 且检测缺口同构 —— 现有断言查的是内容 (值对不对、几处一不一致), 失效发生在结构 (元素在哪个父节点、钳制覆盖哪些入口)。v2.3 逐条实测核实后处置, 并把「结构」维度补进断言体系。自检 21 → 22 项, 工况 22 → 23 条 (新增 edge_hostile_json)。

A. P0 · <head> 提前闭合 (实测三处, 审计报一处)

v2.2 构建期补丁写入的三处 description (meta / og / twitter) 行尾各多一个 >; HTML5 解析器在第一处提前闭合 <head>, 20 个 meta + canonical 掉进 <body> —— 爬虫只解析 head, canonical / robots / og / twitter 全部失效, 而 description 断言用 querySelector, 对父节点不敏感, 照样全绿。修三字符; 新增 head 结构断言 (元素必须在 document.head 内), 先转红再修复转绿 —— jsdom 内部即 parse5, 负对照免费。

B. P1 · 方案 JSON 加载路径绕过钳制

v2.2 撤消费处 || 默认 时把 Math.max 取值域守卫一并删了 —— 前者是真相源问题、后者是校验边界问题, 写法相似但性质不同。clampByFieldSpec 只在 UI 读取路径调用, 载入越界方案 JSON 长驱直入 (实测 co2BlowerEfficiency=0 → NaN 遍布; co2StripperGtoL=1e6 → 成本 109 万元/kg)。修复: ensureStageProc 兑现自己注释宣称的不变式 —— 对 PROCESS_DEFAULTS 数值键逐一 clampByFieldSpec (非有限回落默认, 布尔/字符串原样)。它是 recomputeAll / rebuildStages 的公共入口, 「UI 有守卫而加载没有」自此在结构上写不出来。edge_hostile_json 修复前咬出 Infinity/NaN 于能量 A2/B/C、登记 E1、物质 M4a; 修复后转绿, 13 条数值基线逐位不变 (钳制对合法参数是纯守卫的实证)。

C. P2 · 鱼池曝气尾气入车间 (进气维持室外, 设计决策)

鱼池是车间内的敞开水面, 气泡在池面破裂 —— 尾气必然入室且已被水温饱和; OUTDOOR→OUTDOOR 只对有排风管的脱气塔成立。aerationSpec.airPath.sink 改 INDOOR, 车间湿平衡产湿侧新增 ṁ_air × (W_sat(T_w) − W_room)。实测罗非养成 (28°C/65%): 1,384 m³/h → 336.1 kg/d, 为池面蒸发 +29% (审计估 335 / 手算 337 / 实测 336, 三方吻合)。显热恰为零 (A3: T_room = T_w); 与接触器 netWater 无重复 (一记水体失水、一记车间得湿)。成本仅动 air 模式除湿设计选型 CAPEX (罗非 +0.007 元/kg), 年均电耗不变; 13 条数值基线全 o2 模式, 逐位不变。进气侧维持室外取气 (设计决策: 进气经风管自室外), 接触器进气继续用室外温湿度。开放项: air 模式气泡吹脱的 CO₂ 同样入室, 新风需求目前只计脱气塔份额。

D. P3 · 全局热工配置单源化 (含审计误报更正)

默认值同时写在 GLOBAL_THERMAL_DEFAULTS 与读取函数的字面量 fallback 里, degasserExhaustIndoorFrac 已实际漂移 (表 0 / fallback 0.2; 0 正是 v2.1 为气路 A5 改的值)。实测更正: 缺失键为 4 个非审计所报 6 个 (三个 U 值在表内, 审计漏了 fcDesignDT_K); 另抓到审计未报的第三处副本 —— 消费点一处 : 0.2 死 fallback。处置: 补 4 键入表 → 32 处 fallback 一律引表 → 死 fallback 改引表 (保留 [0,1] 取值域守卫)。断言两条: 键集锁定 + 运行时 toString 扫源码禁字面量 fallback (首版正则漏 3 处对齐多空格行, 由脚本残留自查抓到 —— 故把这层也固化为断言), 双向负对照精确。

E. chart.js SRI 落地 (对 v2.2 注释的事实更正)

v2.2 注释预想「联网后 curl 原 URL 取哈希」—— 实测原 URL 的 chart.umd.min.js 在 npm 包内不存在, 是 jsDelivr 对缺失 .min.js 的动态压缩产物; 给动态生成物钉 SRI 与给 Tailwind Play 钉 SRI 是同类错误的温和版。处置: URL 改指包内真实发布件 chart.umd.js, 哈希链条 = registry 声明 sha512 → 本地 tarball 复算逐位一致 (供应链验证) → 发布件 sha384; integrity 与 crossorigin 成对上线。断言: jsdelivr 脚本必须成对、Tailwind Play 必须皆无 (防 v2.2 样式崩掉事故复发)。

F2. 第二批: 曝气风量物理选型 (2026-08-10)

海南低密度(石斑 20 kg/m³)鼓风曝气 + 关脱气塔是主流案例, 暴露两层缺口: ① 旧风量公式 SOTE 硬编码 0.18 为清水标准态值, 无水深/α β θ/驱动力修正, 实际 OTE 仅其 1/3–1/2; ② CO₂ 侧风量需求缺席, 关塔只有不联动的 fallback 旋钮(实测鱼池 CO₂ 55–179 mg/L 超阈 2.5–8 倍而选型无反应)。实装: tankAerationDesign 为选型与稳态的共同单源 —— O₂ 侧 OTE = SOTE(%/m)×水深×αβ×θ^(T−20)×(C*−DO_design)/C*; CO₂ 侧按 Henry 平衡载量(复用碳酸盐 K0_W74/ρ, 零副本), 风量取两侧 max 并标注控制侧; 关塔稳态 η = A·k·逼近/Q 反算。断言 M8(air+关塔 ⇒ 稳态 CO₂ ≤ 选型目标)红→绿: 旧 144–179 → 新 20.5 mg/L。DO 饱和与 CO₂ 阈值内联逻辑抽共享函数(逐字符不变), o2 基线逐位未动; 新工况 edge_air_no_stripper。新参数(JSON 可调, 经全路径钳制): sotePerMeter 6.5 %/m · aerationAlphaBeta 0.75 · co2StripApproach 0.5 · co2TargetMgL null=阈值。事故记录: K0_W74 入参为 Kelvin(Weiss 式 T/100), 首版传 °C 得 1e111 —— 第六次「猜接口」。海南石斑 200 t 案例落点: 风量 O₂/CO₂ 两侧收敛(1,095 vs 1,270 m³/h), CO₂ 控制选型, 全场风机 ~78 kW, 综合 60.4 元/kg · 21.5 kWh/kg(对照: 带塔 68.1/25.5, 旧旋钮虚算 57.5/18.8)。

F. 交付方式变更: 补丁链封存

v2.2 的 patches/ 与 tools/ 不可得, 自 v2.3 起直接在交付产物上编辑, 「从 v2.1 全量重建」的可复现性封存; 验证工具按 HANDOFF §4 规格重建并显式标注。编辑纪律不变: replace_once 强制唯一命中、断言先负对照转红、基线变动先预测符号量级。

[v2.3 第四批] 简易模式 · 自然通风与太阳辐射 2026-08-12

国内多数循环水项目是简易棚: 无暖通无除湿, 车间温湿度由太阳、设备废热、池面与尾气换热、自然通风共同决定。此前该场景无表达路径 —— hvacEnabled=false 只是不收电费, A3 前提仍强制室温=水温。本批新增全局键 roomMode 三档: conditioned(恒温车间, 既有路径逐字保留)/ ventilated(简易棚·自然通风)。⚠ 本批原含第三档 open(露天), 因中国工厂化循环水无此实际场景, 后续批次已撤销(白名单/UI/派发分支/R4 枚举一并移除; 旧 JSON 写 open 者与非法值同路回落 conditioned)。13 条数值基线在恒温档下逐位不变(全精度导出比对); 自检 23 → 24 条(新增 edge_room_ventilated)。

A. 决定性考古: v1.x 的失败根因

车间温度自由求解正是 v1.2–v1.9.3 的做法, 热带鱼种曾算出车间 9–14°C / RH 99%, 与实测(摩洛哥温室 16°C / 大连简易棚 22–23°C / ASHRAE 水温+1~2K)方向反 15–20 K, v2.0 因此撤退到「暖通维持」。复盘结论: 方程没错, 热源清单漏了三类 —— ① 太阳辐射(全库无建模)② 设备废热(未进空气节点)③ 接触器尾气显热(被 A3 温差恰为零掩盖)。空气节点唯一热源只剩池水对流小项, 解被围护+通风大项拽向室外温度。三类补齐后重启求解。凡 A3 成立时「恰好为零/恰好抵消」的项, 求解器一上全部复活 —— 这是 A3 的隐藏依赖清单, 开工前逐条重审过。

B. 太阳辐射子系统与 solveRoomAir

九气候区各补 GHI 冬/夏/年(Global Solar Atlas / NASA POWER; 三亚 4.2/5.8/5.2, 多哈夏 7.2, 特罗姆瑟冬 0.0 极夜); 四档围护配窗 SHGC / 屋面 SHGC / 不透明面吸收率(ASHRAE Fundamentals Ch.15; 温室档透光屋面 SHGC 0.55 且不透明项置零, 近被动房 0.35/0.5)。不透明面按 sol-air 折算 U·A·α·GHI/h_o(h_o=22.7 W/m²K, 墙面另乘 0.5 朝向因子)。求解器对显热与湿平衡两线性式经结露潜热耦合做阻尼(0.5)不动点迭代, ≤50 轮; 不收敛回落 T_room=室外并置 converged:false(断言 R1 + 界面 danger 双通道)。池面显热系数由既有 evapCoeff 经 Lewis 类比反推(β 的钳制同步作用于显热 —— 蒸发与显热同一张换热面, 不另取 5 或 15 的常数); 通风显热直接吃 0.34 系数的 UA 项, 与报告口径同源(否则 ρ 口径差在大体积×高 ACH 下产生数百 kWh/d 虚假残差, 空气节点闭合断言会咬到工具误差而非真错)。超饱和钳到饱和线、结露潜热回注显热式、凝水量 kg/d 出腐蚀风险告警。

C. 「零」的语义与成本方向

简易档下暖通显热与除湿电耗严格为 0, 由断言 R3 锁死 —— 该零是「设备不存在」而非「算了不计」。池面显热带符号接入水侧热平衡: 三亚设计夏车间解至 36.7°C(室外 35 + 太阳/内热推高、27°C 池水拉低), 池面转为得热, 水侧冷负荷 3,894 → 4,520 kWh/d。同基准三方对照(石斑/三亚/密度20/air/关塔/annual): 恒温 hvac-off 63.9 元/kg(仍计除湿 711 kWh/d 电 —— 那台机在该档真实存在)→ 简易棚 62.6 元/kg。热泵冷负荷确实上升(6,157 → 6,298 kWh/d, 与 A.4 预测机理一致), 总成本却略降 —— 除湿整机移除的省电压过池面得热代价, 这是把「假简易」(关电费开关)换成「真简易」(机器不存在)的正当结果; v1.x 失败特征(车间坍缩到室外之下、池面白捡散热)经标定确认未重演。

D. 断言 R1–R5 · 分层负对照 · 标定哲学

R1 收敛性 · R2 物理界(下界对规格原文做了推广: min(室外,水温,地温)−0.1 —— 冷水鱼种池面是合法低于室外的热汇)· R3 模式互斥 · R4 取值合法性与向后兼容(未设 roomMode 的旧 JSON 必落恒温档; 白名单守卫在 UI 读取与消费点两侧同口径)· R5 空气节点显热闭合(围护+通风流出 = 太阳+内热+池面+尾气+结露, 容差 max(2, 0.5%), 守恒断言 B 的自由节点版)。五组破坏性负对照逐一验证闸门: 强制不收敛→R1、撤暖通守卫→R3、求解器丢尾气项→R5、太阳归零→标定钩子、池面归零→标定钩子。标定探针(tools/probe_room_calib.js)固化三组实测锚点; 首版判据「命中实测点 ±2K」全数失败但逐项热流物理自洽 —— 偏差来自锚点场景重建不确定度(iRAS 建筑几何是成本驱动的紧凑型, 内热密度 200+ W/m², 与实测场几何不可比), 判据遂改为方向 + 有界偏移 + 三类热源在场且量级合理, 点值降级为诊断输出。追着实测点调工况旋钮 = 曲线拟合表演, 教训保留在探针头注。

E. 遗留修复与使用要点

关塔空气曝气的 CO₂ 新风份额(v2.3 遗留): 气泡把池水 CO₂ 吹入车间, 新风需求此前只按脱气塔份额计; 现关塔且曝气入室时份额取 1(零新常数)。对 air+关塔的恒温档工况有真实影响(三亚案例约 +0.3 元/kg); 13 条 o2 基线逐位不受影响。开塔时曝气残余份额未细分, 维持开放项。使用: 全局热工面板顶行「🏠 车间模式」三档; 简易棚建议 ACH 15–30(上限已放宽); 结露告警优先加大通风; 车间比水温低 >2 K 提示寒潮核对鱼种耐受下限。ventHR(通风热回收)在自然通风棚语义上应为 0, 模型不强制 —— 用户若留非零值等于假设有被动回收构造, 参数哲学是用户定参数、模型只管算。

[v2.3 第五批] 池内曝气拓扑 · 曝气强度约束 2026-08-13

本版全部起于一句产业侧提问: 空气曝气是直接加在池子里的, 曝气的时候鱼也在消耗, 所以空气用量要远大于 95% 饱和度。顺着这句话查下去, 发现模型对同一台鼓风机 K-101 用了两套互相矛盾的拓扑, 并连带挖出一处潜伏的跨模块不同源缺陷。13 条数值基线逐位不变, 自检 24 条工况不变, 新增断言 M9/M10/M11。

A. 两套物理: 选型侧对、水质侧错

选型侧 tankAerationDesign 按池内曝气算, 完全正确: 池水维持 DO_design = max(DOmin_abs, 0.7×DO_sat) ≈ 5 mg/L, 推动力只剩 (C_sat−C)/C_sat ≈ 26%, OTE = SOTE/m × 水深 × αβ × 1.024^(T−20) × 推动力 折算后仅 2.2–4.5%, 风量据此反推 —— 这正是提问者说的"远大于饱和所需"。水质侧 simulateWaterQualityProcess 却写着 satTarget = 0.95(air 模式写死)、tankDO = DO_sat×0.95 − ΔDO_per_cycle, 这是氧锥/增氧塔在主管路上把水打到位再送进池子的拓扑。可 air 模式的设备是 鱼池增氧鼓风机 K-101, 气直接打进池子, 根本没有"进池浓度"这个概念 —— 增氧与耗氧在同一个控制体内同时发生。后果是鱼被"呼吸了两次": 选型侧已按维持 5 mg/L 配好风机, 水质侧又假设进池 95% 再扣一整个循环的耗氧量。

B. 修正: 传质 = 耗氧的稳态

air 分支改为池内质量平衡: OTR(C) = A × 1.2 × 0.23 × OTE_base × (C_sat − C)/C_sat = OCR ⇒ C = C_sat − OCR × C_sat / (A × 1.2 × 0.23 × OTE_base)。与循环流量无关 —— 循环流量只管 TAN/CO₂/TSS 的移除, 不管 O₂。零新常数(1.2 与 0.23 与选型侧同源); OTE_base 是推动力折算之前的基础效率, 为保 13 条基线逐位不变, 原 OTE 表达式逐字符不动、此处独立重算一份。o2 分支逐字保留(氧锥确在主管路上, 原口径本就正确)。

修正前后对比(石斑/三亚/200t):

修正后 DO 不再随密度崩塌, 且高出 DO_design 的那一点正是选型安全系数 safetyAerator=1.10 的效果。解析验算: 开塔(O₂ 控制)工况 deficit = (6.73−5.00)/1.10 = 1.573 ⇒ DO = 5.158, 模型三个阶段输出全为 5.158, 与手算逐位吻合。⚠ 修正前那个 0.00 是拓扑用错产生的伪值, 不是"会死鱼"的物理结论 —— 本手册特此记录, 防止后人把它当作历史结论引用。

C. 潜伏缺陷: sp 白名单漏 recDepth_m(同模式第三次复发)

诊断中发现探针复算与模型内部风量对不上(苗种期 222 vs 132 m³/h), 而成鱼期完全一致 —— 差异只出现在 O₂ 控制的阶段。根因: recDepth_m 是鱼种库的逐阶段字段, 而 tankAerationDesign 被两条路径各调一次:

OTE ∝ 水深、风量 ∝ 1/OTE, 苗种期两侧差 1.68× —— CAPEX 买的机器与水质链假设的机器不是同一台。该白名单上方就挂着 v1.1.2 的注释「sp 必须包含 DOmin_satRatio 和 DOmin_abs, 否则鱼种内置 DO 阈值失效」: 同一个白名单、同一种漏字段、第三次复发。负对照(撤掉修复)证明24 条自检依然全绿 —— 因为两条路径各自内部自洽, 只是彼此不同源, 这正是它能潜伏至今的原因。故封在断言层(M11 跨模块风量同源), 不是注释层。

D. 曝气强度: DO 与 CO₂ 都达标后先撞线的那一项

总风量由鱼的耗氧决定, 几乎不随密度变(密度 20→60 时 222→332 m³/h, 因鱼的总量由产量定); 而水体 V = 生物量/密度 ⇒ 强度 ∝ 密度, 密度 3 倍则强度 4.5 倍。新增派生量 sim.aerIntensity: 体积强度 m³/(m³·h)、池底布气 m³/(m²·h)、两口径各自反算的该阶段 air 模式可行密度上限(因 V 与密度严格反比, 反解精确而非外推; 唯一一阶近似是风量本身随密度的微弱变化, 偏差 <10%)。

阈值的出处与局限都写在 WATER_LIMITS 注释里, 使用者必须知道它们不是福利阈值的直接规定: ① 体积 2.0 —— 源自 33.3 m³ 池微孔曝气 CFD+实测, 30 m³/h 相对 60 m³/h 标准曝气效率高 32.1%(即 0.90 相对 1.80), 0.90 是能效拐点, 2.0 是在其上留工程余量的告警线; ② 池底 3.0 —— 由"纳米盘(孔径 80–100 μm)每 m² 池底 1 个 × 单盘常规工作气量 1.5–3 m³/h"反推的工程惯例, 非规范条文。定性佐证只入注释不入判据: 池底/穿孔管曝气的气泡上升对水体产生扰动与噪音、不利养殖生物生长, 且紊流会把残饵粪便搅碎成细颗粒使水质恶化(气提式无扰动曝气装置的研究动机); 三文鱼计算机视觉实验显示曝气开启时通气频率升高, 且与 DO/水温无关, 属对紊流与气泡流的行为响应 —— 即DO 达标不等于鱼没有代价。

石斑/三亚实算:

成鱼期可行上限 35 kg/m³ 与国际经验线接近 —— Global Seafood Alliance 的 RAS 综述指出密度高于 40 kg/m³ 时鱼与细菌的耗氧速率通常已超出常规曝气设备溶入大气氧的能力, 必须改用气态纯氧。差别在于 35 这个数是从曝气强度推导出来的, 不再是拍脑袋的门槛。苗种期上限只有 12–15, 但这更说明"把同一密度套在三个阶段上"本身不合理 —— 曝气强度约束的是"密度 × 阶段"的组合, 不是全场密度。

E. 断言与负对照

M9 气曝-DO 闭环(air 模式稳态 DO ≥ DO_design − 0.05; 与 M8 气曝-CO₂ 闭环成对, 一个锁 O₂ 侧、一个锁 CO₂ 侧) · M10a 体积/池底口径几何自洽 · M10b/c 可行密度反算自洽 · M11 设备侧/水质侧风量同源。四组负对照逐一验证闸门会咬人: 撤 DO 修正 → M9 红(三条 air 工况全咬, 罗非默认密度即报 2.08 vs 4.70) · 池底面积错水深 → M10a 红(7.240 ≠ 10.860) · 反算写成加法 → M10b 红(2.393 ≠ 2.000) · 池底口径误用体积阈值 → M10c 红(2.000 ≠ 3.000) · 撤 recDepth_m 白名单 → 修 M11 前无人咬住(24/24 全绿), 修后转红。另补车间高温告警, 与简易模式批次的寒潮告警对称: 比水温高 >5 K 管热泵冷负荷(池面转得热), 绝对 >38°C 管作业条件与风机/变频器降容。

F. 海南简易棚实证与使用要点

本版的产业来源。石斑/三亚/200t/简易棚(ventilated, ACH 15)/关脱气塔/关臭氧与 AOP/放大系数 1.8: 密度 20 → 70.29 元/kg(35.1 元/斤), 密度 31.2 → 58.77, 密度 40 → 54.23(27.1 元/斤)。密度 40 下 DO 5.31–5.38 达标; CO₂ 20.45 mg/L 在阈值 22.5 内 —— air 模式的曝气本身即脱气, 不需另配脱气塔(反之 o2 模式关塔会让 CO₂ 冲到 257.91 mg/L、pH 掉到 5.67, 纯氧模式脱气塔是必需品); 全年凝水为零(海南冬季室外 18–20°C, 围护内表面始终高于露点, 简易模式批次的结露告警在此气候区空转, 要到青岛大连才有意义)。唯独曝气强度全线超限。真正的限制是夏季车间温度(设计夏 36–41°C, 池面转得热直接进热泵冷负荷; 加大 ACH 可降温但推高 RH, 热带自然通风无法同时降温除湿)与曝气强度 —— 不是 DO、不是 CO₂、不是湿负荷。

[v2.3 第六批] 车间模式三档 · 车间通风机 2026-08-13

车间模式重新划分为三档: conditioned 恒温恒湿车间 / natural 自然通风车间 / mechanical 机械通风车间。分档判据只有一条: 能否自动调节温湿度 —— 不是"简易还是正式", 也不是"自然还是机械"。同时补上一台此前两档共同缺失的设备: 车间通风机 KV-1003。13 条数值基线因此全部重算。

A. 关键判断: 恒温恒湿车间本身就是机械通风的

本版起于产业侧一句反问: "恒温恒湿车间也有机械通风"。确实如此 —— 恒温档的 ACH 新风量一直参与计算(UA_vent_sens 进暖通负荷), 但从来没人给它配风机: 全场四台风机(脱气塔 / BF / 蛋分 / 池内增氧)没有一台是车间通风机。所以通风方式不是某一档的子类型, 而是横跨两档的独立事实。三档扁平命名后, "恒温恒湿 + 自然通风"这个物理上不成立的组合被天然排除 —— 你不可能一边花钱把室温压到 27°C, 一边让室外热风自由穿堂。

⚠ 键名变更: 简易模式批次的 ventilated 改名 natural; open(露天)已于池内曝气批次撤销。二者均不留别名 —— 留一条永远没人走的路径只会扩大审计面。旧方案 JSON 写这两个值的, 与任何非法值同路回落 conditioned(断言 R4b 覆盖)。

B. 通风机 KV-1003: 两个易错点都封在断言里

功率 = 风量(m³/s) × 全压 ÷ 效率, 与既有四台风机同一套公式。

易错点一 — 风量口径。 必须取 V_vent_eff_m3h = max(ACH×V_room, CO₂ 稀释需求), 不是 ACH×V_room。air 模式关脱气塔时 CO₂ 才是控制项; 负对照实测挂错口径低估 58–66%, 且只在 CO₂ 控制的工况暴露 —— 只测 o2 模式永远不会显形。由 M12a 锁住。

易错点二 — 全压。 独立键 ventFanPressure_Pa 默认 250 Pa, 绝不复用池内曝气盘的 70 kPa: 后者要克服水柱静压, 前者只克服风管与百叶阻力, 差两个数量级。实测 173,123 m³/h 下 250 Pa 给 21.9 kW, 误用 70 kPa 给 6,121 kW —— 与 HANDOFF 记录的 K0_W74 传摄氏度事故(airCO₂ 冲到 1e10)同族, 故独立成键并在两处留警示注释。

热去向为登记表新增的 exhaust 类别: 直驱轴流排风机电机在排风气流中, 空气离开车间后才经过电机 ⇒ 废热随排风带走, 既不进车间也不进水。与 external(臭氧发生器独立机组冷却介质带走)的区别在成因, 结果同为界外。⚠ 已知边界: 恒温恒湿车间若用送风式 AHU, 送风机废热确实进车间并需再制冷; 本版按单风机排风统一处理, 该情形下偏低。UI 提示: 送排平衡式请把全压按两台之和折算。

C. 13 条基线重算: 预测先行, 逐条吻合

补一台真实存在的设备必然改变基线, 故按纪律先出预测表再改代码。预测: 全部 13 条上升、幅度 +0.01~+0.08 元/kg(≤0.1%)、最大为 turbot_500(水体大, 通风量 5 万 m³/h)。

方向 13/13 为正、量级 13/13 吻合, 最大偏差 0.006 元/kg(bass_300, 差在预测未计 CAPEX 折旧那一份)。幅度远小于口头估算的 +0.8 元/kg, 原因是基线默认 ACH 为 1 而非简易棚的 15 —— 同一台风机放到海南工况(ACH 15)是 21.9 kW(密度 20)/ 10.9 kW(密度 40), 密度高反而小, 因为车间体积减半, 这是高密度此前没算出来的一项红利。

D. 空气曝气 × 车间模式: 三样东西的去向与三条告警

恒温恒湿档下用空气曝气, 气泡带进车间的 CO₂ / 湿 / 热各有归宿(石斑/三亚/200t/密度20/年均实测):

CO₂ 经 fracIndoorCO2 → V_vent_fish_m3h 与 ACH 口径取大值, 关塔时把新风顶高 38%, 这部分新风的冷热负荷全压给暖通。湿按 ṁ_air × (W_sat(T_w) − W_room) 计入车间产湿, 除湿量较 o2 档 +29%。热的尾气显热恰好为零 —— 这不是漏算: A3 下 T_room = T_w, 而尾气离开水面时温度就是 T_w, 显热项数学上严格为零; 该零只在恒温档成立, 到通风档 T_room 是解出来的, 这一项立刻复活(海南夏季 −93 kWh/d, 冷尾气反过来给车间降温)。v1.x 当年正是被这个"恰好为零"骗过, 重写车间求解时漏掉了它。另有一段热记在别处: 进气自室外取, 被加热并饱和加湿到 T_w, 这段由水侧的气液接触器换热承担, 不进车间账本 —— 两本账各记一次, 不重不漏。

据此三条告警: ① 恒温恒湿 + 空气曝气(新风与除湿双重加价, 成鱼养成建议改纯氧)· ② 新风被 CO₂ 顶高(同一股 CO₂ 在通风车间只需付风机的钱, 为省一台脱气塔而关塔请核对这笔账)· ③ air 模式开塔冗余(曝气本身即脱气, 关塔后 CO₂ 20.5 仍在阈值 22.5 内)。

第 ③ 条有一个例外值得记住: 脱气塔在 air 模式下虽非 CO₂ 达标所需, 却是调节曝气强度的杠杆 —— 密度 40 成鱼期关塔时 CO₂ 侧需 1,270 m³/h 反超 O₂ 侧 1,095, 成为风量控制项, 把池底布气顶到 3.43(超 3.0); 开塔卸掉 CO₂ 负担后风量回落 1,095, 强度 2.96 合规。告警文案按阶段判断 sizedBy 分别措辞, 风量由 O₂ 控制时明说"开塔不会减少风量, 纯属多花钱"。

⚠ 三条告警都写明什么时候可以忽略它: 育苗 / 亲鱼车间本就是恒温恒湿 + 空气曝气的常态配置(密度天然低、水温与光周期要求精确、鱼苗对纯氧过饱和敏感 —— 模型里苗种期 TGP 阈值本就更严的 110%), 而 roomMode 是全局键、aerationMode 是逐阶段键, 该组合会自然出现, 不是误操作。若每次打开都见红字, 久了就没人看告警了。

H. 成文标准 DB46/T 424—2017 与石斑成鱼期池深修正(2026-08-13)

此前几轮关于"空气曝气能撑多少密度"的推算, 全部依赖设备商配置反算与媒体报道。取得海南省地方标准 DB46/T 424—2017《豹纹鳃棘鲈工厂化养殖技术规程》正文后, 这条链才有了成文依据。

标准表 1 · 分规格养殖密度(直接给 kg/m³, 无需折算):

标准明写密度的约束条件: 「养殖密度与养殖设施、换水量、溶氧量密切相关, 换水量越大、溶氧量越高的养殖水体, 可适当增加养殖密度」—— 正是本模型一直在建的逻辑链。4.4 增氧设施「采用鼓风机+纳米管或纯氧统一供氧」, 二者并列为合规方案、未规定密度分界; 结合密度表, 20 kg/m³ 量级下鼓风机+纳米管是标准认可配置, 印证空气曝气承载量 20–25 的落点。6.2 水质指标 DO≥5 mg/L 与模型 DO_design = max(DOmin_abs 5, 0.7×DO_sat) 逐字相符; 修正后的池内曝气稳态 DO 5.16–5.41 正在标准线之上。

⚠ 换水率口径不可混用: 标准 6.1「流水养殖模式下日换水量一般控制在 200%～800%」是流水模式(日 2–8 倍水体), 循环水模式低两个数量级, 与模型 exchangeDaily 不是一个口径。

石斑成鱼期 recDepth_m 由 3.0 m 改为 1.5 m, 依据标准 4.2「养殖池面积 10–20 m²、池深 1.0 m–1.5 m」; 万宁在建工厂化项目实测池型 Ø8 m / 90 m³ ⇒ 水深 1.79 m, 亦远浅于原值 3.0。

⚠ 该字段是统一池深数据源: poolArea = V_tank / poolDepth → A_building = 1.6 × poolArea → V_room = A_building × H。改它会连锁改池面积、建筑面积、蒸发面与通风量, 故基线随之重算。按纪律先出预测再改: 池面积翻倍 ⇒ 蒸发↑、除湿↑、围护散热与通风量↑ ⇒ 仅 grouper_500 上升且幅度显著(远大于此前几次的 +0.01 量级), 其余 12 条逐位不变。

预测完全命中, 其余 12 条 diff = 0。热泵涨幅最大(+8.7%)正是蒸发面翻倍导致的潜热负荷。副效果: 成鱼期池底布气强度由 1.71 降至 1.48, 从超限转为合规; 可行密度上限 19.8 → 23.0 kg/m³, 与标准表 1「30–40 cm 段 ≥20」及产业口径 20–25 一致。

控光: 已知未建模维度。标准把控光列为要求项 —— 4.2「配备通风、控光、控温设施」(与通风、控温并列)、6.2「光照 2000 Lux～5000 Lux」(与 DO/pH/温度/盐度同级的受控参数)。产业侧佐证: 东星斑养殖场用蓝光、红光模拟 20–30 m 深的海底光照环境, 因为体色直接决定售价。iRAS 目前只有 UV 消毒(水处理), 没有养殖照明, 缺口有三: ① 灯具电耗未进 POWER_REGISTRY, 比电耗系统性低估; ② 灯具废热未进车间空气节点(与补 UV/泵废热同族的漏项); ③ 体色分级溢价未进财务侧 —— 这是唯一一条收入侧缺口, 其余全部遗留都在成本侧。不在本批建模: 需灯具选型口径(W/m² 或 Lux→W 换算)、光谱配比、光周期, 且体色-售价的量化关系无公开数据, 硬做即编造。

G. 曝气强度限值下调并按养殖对象分档(2026-08-13)

原限值 2.0 m³/(m³·h) 与 3.0 m³/(m²·h) 的依据是搅拌式反应器能效拐点与对虾育苗盘密度反推, 用在鱼身上偏松 2–3 倍。经产业配置反算后下调至鱼类档 1.0 / 1.7, 原值保留为甲壳类档 —— 工厂化对虾的正常工况就是"水面气泡成沸腾状", 絮团模式还需曝气维持颗粒悬浮, 二者不可共用一个限值。

标定口径写死为全压 20 kPa · 风机效率 0.60 —— 产业确认 1 m 深的池子 20 kPa 够用(罗茨风机压力经验 9.8 kPa/m 水深)。⚠ 刻意不写"20–30 kPa"这类区间: 全压取 20 与 50 kPa 结果相差 2.5 倍, 含糊比精确更危险, 复核时务必按此单一口径。

⚠ 二次修订: 两个判据曾自相矛盾, 这是本批最该记住的一条。一次修订把池底 1.7(来自养殖池真实配置反算)与体积 1.0(来自搅拌式生物反应器的能效拐点 0.9)并列当判据用 —— 两个数来源不同质。结果在 0.8 m 浅池上直接打架: 同一套真实运行的系统, 按池底判据合格(0.97 / 1.65 < 1.7), 按体积判据却超限(1.22 / 2.06 > 1.0)。因 池底 = 体积 × 水深, 池底 1.7 在 0.8 m 水深下隐含的体积上限本应是 2.1, 而当时设了 1.0。

现改为主/次判据结构: 池底为主判据(有真实工程配置支撑), 体积为次判据且阈值取在全部实测之上, 只拦极端情况。告警文案亦按主/次分别措辞。

注意甲壳类那档: 一次修订误设的 3.0 / 2.0 低于对虾的真实配置(3.89 / 3.24)—— 等于把一个正常运行的工况判成超限。这是"拿 A 场景的数字当 B 场景阈值"的第二个实例(第一个是拿反应器能效拐点当养殖池福利阈值)。

布气密度口径交叉印证: 纳米盘按每 m² 池底 1 个布置(孔径 80–100 μm, 曝气压力 0.02–0.03 MPa); 对虾池 5.5×5.5 m 配纳米管总长 28 m ≈ 每 m² 池底 0.93 m 管 —— 两者量级一致。

承载量交叉校验: 取鱼类 1.7 时, 石斑成鱼期反算可行密度 19.8 kg/m³。这与设备商系统参数吻合 —— 同一套海水工厂化循环水系统, 最大生物承载量为「半滑舌鳎 10 kg/m²(液氧 15)、大菱鲆等 20 kg/m²(液氧 40)」, 即空气曝气的承载量约为纯氧的一半; 亦与 GSA「密度 >40 kg/m³ 时耗氧速率超出常规曝气设备溶入大气氧的能力, 必须改纯氧」一致。三个独立来源收敛于空气曝气鱼类承载量 20–25 kg/m³, 产业侧确认 30–40 配空气曝气偏高。

⚠ 仍未解决的不确定度: 上述反算全部依赖假设的全压(20–30 kPa)与风机效率(0.6), 全压取 20 与 50 kPa 结果差 2.5 倍; 且多数来源未给出对应的养殖密度, 严格说不可直接互比。若能取得近两年新建海水鱼工厂化项目的完整设计参数(密度 + 增氧方式 + 风机配置三者齐备), 应据此重校。常量注释已完整记录出处与局限。

新增断言 M13 与工况 edge_shrimp_air(自检 24 → 25 条)。立此断言的直接原因值得记录: 新增鱼种字段 isCrustacean 后, 负对照证明把它从 recomputeAll 的 sp 白名单里撤掉, 24 条自检依然全绿 —— 与 recDepth_m 完全同一模式的第四次复发(前三次: v1.1.2 的 DOmin_*、本轮的 recDepth_m)。注释提醒挡不住, 只有断言能。凡"鱼种库有字段 → 白名单转发 → 消费点使用"这条链, 都应有一条断言校验消费点拿到的确实是鱼种的值。

⚠ 更值得记的是第二层: 断言写好后负对照仍然全绿。查明原因是没有工况能触发它 —— aerIntensity 仅在 air 模式下计算, 而 shrimp_100 基线走 o2 模式。补 edge_shrimp_air 工况后负对照才精确转红(实得 1/1.7, 应为 2/3)。新断言必须确认存在能走到它的工况, 否则等于没写 —— 这条教训与"断言先负对照转红"的纪律是一体两面。

F. 补丁: CO₂ 脱除的机制澄清与浅池告警(2026-08-13, 无数值变动)

交付后的一个提问("空气曝气对 CO₂ 的去除如何建模")牵出一处被误判为缺陷、实际是正确设计的地方, 特此记录以防后人"修正"它。

模型的 CO₂ 脱除走三步: ① 亨利平衡载量 kLoad = (1/44010/ρ/K0)×44.01/Vm(K0 用碳酸盐模块的 Weiss 1974 溶解度常数, 与 pH/Ω 求解同一套参数, 无第二份副本); ② 反推所需风量 airCO2 = CO₂日产量×安全系数 /(kLoad×目标浓度×逼近度)/24, 再与 O₂ 侧取大值并标注 sizedBy; ③ 稳态去除率由选定风量反算 η = 风量×kLoad×逼近度/循环流量, 而非独立旋钮 —— 这是 v2.3 二批修复的核心(旧版 fallback 旋钮与风量互不知晓, 海南石斑关塔实测池水 CO₂ 冲到 55–179 mg/L 而选型侧毫无反应), 断言 M8 锁住该闭环。

看似的不一致: O₂ 侧 OTE ∝ 水深, CO₂ 侧与水深无关。查证后确认这是两种传质机制的正确区分: O₂ 溶入是【速率控制】(推动力大, 气泡全程远未饱和, 接触时间越长溶入越多); CO₂ 脱除是【气相载量控制】(气泡在离开液面前已被 CO₂ 饱和, 再深也装不下更多)。生物反应器放大实测: O₂ 的 kLa 斜率随液深线性增长, 而 CO₂ 的 kLa 仅在液深 < 约 1000 mm 且最弱搅拌下线性, 更深/更强搅拌时出现明显饱和效应(气体停留时间足够长, 气泡出液前已被充分饱和); CFD 研究同样确认大型反应器中 CO₂ 吹脱时气泡在离开培养液前即饱和, 且放大过程中 O₂ 与 CO₂ 的 kLa 演化路径不同。若照"给 CO₂ 补上水深依赖"去改, 反而会把一个正确的模型改坏。

真正的问题在浅池: 饱和的前提是停留时间够。鱼种库里大菱鲆全程 0.8–1.0 m、石斑苗种期 1.5 m, 都在转折点附近或以下, 这些工况的 CO₂ 去除被系统性高估 —— 而大菱鲆是冷水鱼、CO₂ 阈值更严(20 而非 30 mg/L), 又常用平面浅池, 三重叠加。故新增浅池告警(水深 < 1.5 m 且 air 模式关塔时触发)。实测触发精确: 大菱鲆三阶段全触发, 石斑 1.5 m 及以上不触发, 开塔与 o2 模式均不触发。

⚠ 只告警不折减, 这是有意选择: 那个 ~1000 mm 转折点出自搅拌式生物反应器, 气泡尺寸、上升速度、湍流强度与养殖池微孔盘曝气都不同, 转折点位置未必能直接搬。拿一个来源不同的数字当阈值就是曲线拟合表演(与 probe_room_calib.js 头注记录的标定哲学同款教训)。宁可显式承认不确定, 也不假装知道折减多少。

⚠ 另记一条待查: 级联塔实测(淡水 0‰ vs 盐水 35‰, 15°C, 进水 10–60 mg/L)显示两者传质系数相近, 但盐水的 CO₂ 吹脱效率显著低于淡水, 归因于出水重建平衡时无机碳各形态电离分数的差异, 并直接指出海水循环水系统的 CO₂ 去除比淡水更困难。模型 kLoad 里的 ρ 与 K0 已含盐度, 但那是溶解度的盐度效应, 不是电离分数造成的额外损失。而现有 marineCO2Factor: 0.75 挂在 CO₂ 限值上, 其注释自承"代码中无出处标注、教科书亦未按盐度区分 CO₂ 限值、该系数应单独查证"—— 该系数可能挂错了位置: 海水该被区别对待的或许是去除效率而非限值。本版不动, 记入遗留。

E. 断言 M12 与三组负对照

M12a 通风机风量与热工侧真实通风量同源 · M12b 档位一致性(自然通风档必须无风机, 恒温恒湿 / 机械通风必须有 —— 后者正是"恒温恒湿本身即机械通风"这一判断的运行时证据)。负对照: 风量挂错口径 → M12a 红(429.5 ≠ 1023.3, −58%; 1944 ≠ 5762, −66%)· 恒温档不装风机 → M12b 红(FAIL 3/24)· 误用 70 kPa 全压 → 13 条基线红(FAIL 11/24)。

实施中另有一次真实被咬值得记录: CAPEX 选型门槛(if(_vf > 0.3))与登记表 capexMinKw 不同源时, 断言 F4 当场报出"ventFanKw 有电功率但 CAPEX 明细中无对应条目"—— 这正是 v2.2 为 BF 风机建立该机制时预期的用途。

v2.3 → v2.3.3: 字段流转工厂化 + 空气曝气路线补完 v2.3.3 · 2026-08-13/14 · 六批

〔本章含 v2.3.3 全部六批: A–F 一批(字段流转工厂化) · G 二批(aerationMode 硬告警) · H 三批(密度分界 40→30) · I 四/五批(设计工况点 + 哨兵盲区) · J 文档批(手册第 15 章追平代码)。 章标题此前只写一批主题, 与章内实际内容不符, J 批一并订正。〕

版本主题只有一件事: 治「权威源 → 转发 → 多消费点, 某个消费点没接上; 各自内部自洽故断言全绿」这一缺陷模式。它在本库已复发五次(v1.1.2 DOmin_* / recDepth_m / isCrustacean / 通风机风量口径 / 曝气侧池深不同源), 每次补断言只封住当次字段, 模式换个字段就复发——上一版交接文档已把"工厂化"列为遗留清单第 0 位。本版为纯结构重构, 13 条数值基线对【v2.3 新基线值】逐位不变(重构版的最强验收条件), 自检 26 → 27 条。

A. 声明表 SPECIES_FIELD_FLOW + 工厂 buildWaterSp

五次复发的案发现场是 recomputeAll 里的手写白名单: 每漏一个鱼种字段, 就多一处静默兜底。现每个字段在 SPECIES_FIELD_FLOW 声明 {scope, toSp, resolve?}——scope 标记权威源层级(阶段字段 / 鱼种级字段 / 派生), toSp 声明是否转发进水质侧, resolve 为解析函数(省略即原样转发)。buildWaterSp(stage) 按表生成 sp, 手写字面量退役。池深解析(用户设定 > 鱼种推荐 > proc 兜底 > 1.5, 下钳 0.3 m)收敛为 resolvePoolDepth 全库唯一副本——此前三副本且兜底不一致(3 vs 1.5)正是"池深修一半"事故的温床。

B. 断言 M15a–d: 静态源码扫描

选静态扫描而非运行时校验, 是对既往两次教训(M13 / M14: 断言写好后负对照仍全绿, 因为没有工况能走到那条路径)的机制性回应: 对水质链四个消费函数做 .toString() 源码扫描, 不依赖工况, 每次自检对全部代码路径无条件全覆盖。M15a 消费面每个 sp.X 必须声明且转发; M15b 每个转发字段必须有消费点(抓死转发); M15c recomputeAll 的 sp 必须来自工厂; M15d 设备侧 tankAerationDesign 调用必须经同一工厂。落地顺序刻意为先加断言(转红)再处置(转绿), 且上断言前先以预飞探针(tools/probe_fieldflow.js)在真实页面环境跑同一套扫描、确认红名单恰为预期。

C. 断言落地当天的收获: 第六例 thermalClass + 死转发 protein

M15a 上线即红: isWarmWaterStage 支持鱼种显式声明温冷水类别 thermalClass(注释明写"优先用鱼种显式声明"), 但该字段从未进过白名单——同模式第六例, 与 recDepth_m 完全同型, 只因尚无鱼种声明它而未被踩响。已补声明转发(阶段显式 > 鱼种级; 现状无声明 ⇒ 数值逐位不变), 声明能力自此真正生效。M15b 同批咬出 protein 死转发: 白名单转发了它, 消费面(水质链四函数)零处读取——真实消费者是 calcStageLoad, 走 stage.protein 直连不经 sp。已撤转发, 条目以 toSp:false 存档("该字段存在, 有意不进 sp"是一条信息, 删掉条目就丢了)。

D. 设备侧接入同一工厂

此前设备侧传完整 stage、水质侧传白名单 sp——两侧传参形状不同, M11 只能事后比对两侧风量。现设备侧改为 tankAerationDesign(buildWaterSp(stage), …), 两侧吃同一工厂产物, "两侧不同源"在结构上写不出来; 两侧解析规则的微分歧(设备侧原缺 0.3 m 下钳与 proc 兜底——被 UI 输入范围掩盖着的潜在分叉)一并消失。M11/M14 保留为纵深防御, 不撤。

E. 验证记录

红→绿全程: 批① 忠实等价替换(protein 照转、thermalClass 照漏), 自检 26/26 + 基线逐位不变 → 批② M15 入列, FAIL 26/27, 红项恰为预飞命中的两条 → 批③ 处置, PASS 27/27 + 基线仍逐位不变。四条人工负对照(临时副本上做)全部精确转红: 表删 DOmin_abs → M15a · 塞假字段 ghostField_xyz → M15b · 手写白名单复活 → M15c 两条且级联咬中 M11/M14 数值断言(23.5 条自检中 6 项转红——结构层与数值层的双重防御得到实证) · 设备侧退回 raw stage → M15d。

F. 局限(如实记录)

M15 只覆盖「鱼种/阶段 → sp」这条链——五次复发的案发地。派生中间量的流转不在射程(V_vent_eff 一类, 第四次复发所在), 仍由 M12a 数值断言压着; 那是另一个量级的依赖图, 有意不在本版摊开。消费点内残余的 || sp.recDepth_m || 1.5 兜底对工厂产物是死代码, 仅为诊断脚本手造 sp 时保留防御——已在声明表头注如实标注, 不假称"解析规则彻底单副本"。

G. 二批(同日): aerationMode 硬告警 —— configWarns 结构化导出

遗留清单第 5 位。侦察修正了问题定义: 渲染层其实已有曝气强度告警与 CO₂ 超标告警——真实缺口是: ① 两条告警困在渲染层(A.6 家族: 无导出面、无断言、渲染改坏无人知, 报告照出成本不带任何"该方案不可行"标记); ② o2 关塔这一物理上必然积累 CO₂ 的配置(仅剩增氧锥附带解吸 ~5%)与"塔效率不足"共用一句"建议启用"的文案, 严重性被淡化; ③ 参数表 aerationMode 处无联动。

落地形态: sim 新增结构化导出 configWarns = [{code, level, …data, rootCause?}], 两个 code: AIR_INTENSITY_OVER(复用 aerIntensity 全部字段)与 CO2_OVER(rootCause 三分 stripperOff / airUnderperf / stripperUnderperf)。判据是结果级而非配置级——CO₂ 稳态实测超阈值才响, 而非"o2+关塔一律响": 高换水/低密度下 o2 关塔确实可达标, 配置级会天天误报, 而"天天见红字就没人看告警"是前一批刚写进文档的原则。判据只复用 sim 已算出的量(aerIntensity / 鱼池 CO₂ / CO2_threshold), 零新阈值(纪律: 不拿来源不同的数字当阈值)。渲染层两块改为消费该数组单源, o2 关塔文案升格为「物理上必然积累, o2 模式必须启用脱气塔」; 参数表联动: aerationMode 选择器随每次计算着色并在 title 给出可行密度上限, 只提示不自动切换(不替用户改配置——改配置是工程决策)。这也是遗留 2(A.6 十一类告警进导出面)未来迁移的目标形态: 新告警按结构化建, 旧的逐步迁。

H. 二批断言 W0–W3 与验证记录

预飞定锚(教训: 断言必须先确认存在能走到它的工况): 探针 tools/probe_warnmatrix.js 对六类工况出触发矩阵——W1 锚 edge_air_aeration(罗非三阶段池底布气 4.84–7.24 vs 限 1.7, 必超)、W2 锚 edge_no_degasser(鲑四阶段 CO₂ 124–148 vs 阈 15/20, 必超); 13 条基线两标志全假; edge_shrimp_air 天然提供 W1 的"合规不响"侧(甲壳类档 0.79–1.77 vs 4.0)。

断言设计: W0 导出存在性(数组) · W1/W2 标志与底层状态双向 ⇔(该响必响 + 不该响必不响, 防告警恒真化)· 两处工况锚定——锚定与 ⇔ 刻意不同源: ⇔ 查标志与数据的一致性(同函数内, 防重构漂移), 锚定查物理预期(预飞矩阵给出的独立事实)。W3 为静态 .toString() 扫描(与 M15 同机制, 免疫工况可达性问题): 渲染层必须消费 configWarns 且引用两个 code 字面量——若渲染悄悄退回旧读法(直接判 aerIntensity / tank.CO2), 就回到"数据层↔渲染层双源各自自洽", 正是复发六次那个模式的翻版。W0–W2 入逐工况不变量循环(自检行数不变), W3 为新自检行 config_warns_render(27 → 28 条)。

红→绿全程: 断言先行上线即 FAIL 3/27(W0 遍布全库——红仪式全量咬中)→ 数据层落地转绿(含零产量早退分支的空数组骨架: 导出面结构必须完整)→ 渲染单源化 + W3 入列, 28/28。负对照 3/3 精确转红: 撤数据层 AIR 标志 → W1⇔ + W1锚咬(FAIL 24/28)· 渲染退回旧读法 → W3 咬中 CO2_OVER 引用缺失 · CO₂ 判据改错(阈值×10)→ W2⇔ + 锚咬(FAIL 26/28)。13 条基线三次比对全程逐位不变。

📌 负对照 NC3 顺带核实一个边界事实: edge_yield_tiny 工况的鱼池 CO₂ 实际为 21.5–23.7 mg/L、略超阈值 20——真实构建里该工况 CO2_OVER 标志为真且 W2 一致性通过, 行为正确; 它说明 CO2_OVER 在既有工况集中并非只有 edge_no_degasser 一个触发点, ⇔ 断言对所有工况统一生效。

G. 二批: aerationMode 硬告警(2026-08-13, 同版追加)

处置遗留第 5 位。侦察修正了问题定义: 渲染层已有曝气强度与 CO₂ 超标告警, 真实缺口是告警困在渲染层(无导出面、无断言——A.6 家族), 且 o2 关塔这一"物理上必然积累"的配置与"塔效率不足"共用一句轻文案。落地四件: ① sim.configWarns 结构化导出(AIR_INTENSITY_OVER + CO2_OVER 带 rootCause 三分; 结果级判据, 零新阈值, 全部复用水质链已算出的量); ② 断言 W0–W2 锁数据层(双向 ⇔ + 双工况锚定, 预飞探针 probe_warnmatrix.js 事先实测触发矩阵: edge_air_aeration 池底布气 4.84–7.24 vs 限 1.7, edge_no_degasser CO₂ 124–148 vs 阈 15/20) + W3 静态锁渲染挂钩(防数据层↔渲染层双源复活, 与 M15 同机制); ③ 渲染改吃单源, o2 关塔文案升格为"o2 模式必须启用脱气塔"; ④ 参数表联动(aerationMode 选择器着色 + 可行密度上限 title; 有意不做自动切换——不替用户改配置)。红→绿全程: 断言先行 FAIL 3/27 → 数据层落地 28/28; 负对照 3/3 精确转红。13 条基线逐位不变。顺带发现 edge_yield_tiny 的 CO₂ 处于 21.5–23.7、略超阈值 20 的边界超标状态——结构化导出上线第一天就多看见一件此前无人知道的事。

H. 三批: 空气曝气密度分界 40 → 30(2026-08-13, 纯文案/注释)

产业侧质疑 UI 的 40 kg/m³ 偏高。查证不仅确认判断, 还更正了本库自己的一处引用错误: 注释记「GSA >40 必须纯氧」, 原文实为区间 + 硬上限两句(仅靠曝气典型限于 30–40; >40 则耗氧超出曝气能力)。旧注释把硬上限抄成分界线, UI 据此写成"<40 都可用空气"——把区间上沿当成了推荐值。新分界 30 取自 SRAC-453(美南水产中心 RAS 设计实践综述: 密度 <30 kg/m³ 时气提可提供全部需氧, 满密度 60 时仅约一半)——⚠ 该装置为开放池气提(效率约 0.80), 与本模型池内微孔盘不完全同源, 已标明。另有 TheFishSite「>50 才常规上纯氧」更宽松, 但答的是经济性问题而非工程能力问题, 不并列取值。口径分层(项目方定): 30 进 UI 与参数表(物理上限)· 20–25 进选择器 title 与注释(国标 + 设备商 + 模型反算三源收敛, 国内浅池实配)· 任一阶段准确上限始终以 aerIntensity 反算为准(随水深/温度/鱼种变)。教训: 根因不是数字取错, 而是抄数字时丢了口径(范围/硬上限/推荐值)——失去口径的数在传递中会变成另一种含义("超 40 肯定不行"传成"低于 40 都行")。已立为纪律: 凡引用外部数字, 须连同原文口径一并记录。

I. 四/五批: 空气曝气设计工况点 + 加载路径哨兵盲区(2026-08-13)

由产业侧追问"关塔时是不是该让用户输 CO₂ 浓度"牵出的一串处置。(1) 加载路径防线判据错位: ensureStageProc 以「默认值是不是数字」决定钳不钳, 而哨兵字段(默认 null)的 typeof 是 object, 整类漏在防线外——注入 co2TargetMgL=0.0001 使关塔风量 4,239 → 12.7 亿 m³/h, 与第七轮 P1 的 co2StripperGtoL=1e6 同族同路径。判据改为「FIELD_SPEC 表内有无条目」, 空值仍保持 null(未设定≠设定为下限)。断言 S1/S2 构造注入复验。(2) 两侧都拿安全红线当设计目标: CO₂ 取阈值(上限)、DO 取 DOmin(下限), 同一毛病两面, 系统贴红线跑无裕量。补成对称一对: 设计 DO + 设计 CO₂, 留空回落鱼种值(基线逐位不变)。实测控制侧可翻转: 留空时 CO₂ 侧 4239 险胜 O₂ 侧 4228, 设计 DO 提到 6.0 立翻 O₂ 控制(7243), 提到 7.0 达 15993(近四倍)——该决策此前藏在鱼种库"最低允许值"里替用户做了。(3) 池内曝气与循环流量无关(产业侧指出的拓扑差别, 已实测): turnover 1→4 时 air 模式 DO 恒为 4.9813, 而 o2 模式由 0 → 8.39; 两参数算式均不含流量。⚠ 如实记录一处二阶耦合: 关塔 CO₂ 稳态随流量小幅变(23.7→27.3), 系经风量的间接效应(流量低→TSS 高→耗氧高→风量大→多吹脱)。(4) air ⇒ 塔默认关: 罗非1000t 模型实算开塔 31.25 元/kg 关塔 26.20(省 16%, 比电耗近腰斩), 水质守得住; 代价是 CO₂ 转入车间, ACH 1.0→6.05(恒温恒湿车间需掂量)。联动只在 UI 事件层——计算层猜意图会静默改用户显式配置并动基线, 断言 S3 静态锁; 用户手动过开关后不再被覆盖。(5) 教训: 批B 给 co2TargetMgL 加了输入框, 随即发现 readStageProcFromInputs 根本没读它——UI 加了但白加; 断言 S4 因此同时查"留空须回落"与"填了须生效"。另补反向灰显 data-aeration-air: 新字段在纯氧模式下填了不起作用, 常显是误导。

J. 文档批: 手册第 15 章与参数速查表追平代码(2026-08-14)

前五批把空气曝气路线的代码补完了, 文档没跟上——最直接的后果是界面写 30、手册第 15 章写 40, 用户按哪个都不对。本批只改文档与文档级注释, 不动任何计算: 自检 29/29, 13 条基线逐位不变(三次比对)。

(1) 15.2 对比表重修: 密度分界 40 → 30, 并把口径分层写进正文(30 = SRAC-453/GSA 物理上限 · 20–25 = DB46/T 424—2017 + 设备商参数 + 模型反算三源收敛 · 任一阶段准确上限以 aerIntensity 反算为准)。 另修两处同源矛盾: air 行的"~95% 饱和度"是 v2.3 前旧拓扑的说法; 新增"池水 DO 是否随循环流量变"与"CO₂ 去向"两行。 (2) 「微孔盘 SOTE 18%」退役: 它是清水标准态(20 °C / 零盐度 / 洁净水 / 初始 DO=0)下的值, 养殖池四个条件一个都不满足; 手册把它列作"吸收效率", 正是二批修掉的那个硬编码 0.18 的文档孪生体。换成完整 OTE 公式并逐因子标注, 附实算链: 清水标称 9.75% → 加 αβ 7.31% → 加 θ 8.63%(OTE_base) → 加推动力 2.22%, 差 4.4 倍; 并点明 OTE(选型用)与 OTE_base(水质侧解稳态用)是两个量。 (3) 15.3 标注适用范围 + 新增 15.3b / 15.3c: 15.3 的 DO 公式只适用纯氧拓扑(前提是"存在进池浓度"), 此前无任何标注——而 v2.3 那次"选型侧说 5.00、水质侧说 0.00"的事故根因正是它被误用到 air 模式。 新增 15.3b(池内稳态方程 / 两侧取大 / 设计工况点 / 完整例题 / 守卫与局限)与 15.3c(硬规则与设计选择之分 / 结果级判据 / 实算对照 / 已知缺陷)。正文数字全部为本版模型实算, 取数探针 probe_manual_ch15.js 与 probe_manual_ch15b.js 随交付。 (4) 两条写进手册的实算结论: 安全系数的去向可解析——实算DO = C* − (C*−设计DO)/safetyAerator、 实算CO₂ = 设计CO₂/safetyAerator; 塔的价值随密度反向变化——关塔时池内 CO₂ 与密度无关 (石斑成鱼期恒 11.86, 因 CO₂ 产量与曝气风量都正比于生物量), 开塔时正比于密度(2.14 → 6.43, 因塔的去除能力 正比于循环流量而流量随水体缩小)。两条曲线走向相反 ⇒ 低密度段塔的优势最大, 而空气曝气恰只用在低密度段。 (5) 参数速查表 D 组补登五参数: designDO_mgL · co2TargetMgL · sotePerMeter · aerationAlphaBeta · co2StripApproach; 后三者标明无 UI 入口仅 JSON 可调, co2StripApproach 另标无成文出处、属待校准项。

(6) 一条失效的"已被断言覆盖"承诺(本批最值得记的一件): 手册封面口径散布四处(副标题 / 页脚 / 版本演进章标题 / 首段), v2.2 曾在本章上方留注称「已加入 t21 三文档判据, 下次漏改会转红」。 本批实测: 四处全部停在 v2.3, 而自检 29/29 全绿。查明当前 29 项里只有 meta_version_consistency 管版本, 且只查 index 页内 meta——页面内自检运行在 index.html 的 DOM 里, 读不到 manual.html 与 README.md, 这个判据在浏览器内原理上就做不成, "三次扩展全部落空"的根因在此, 不是写漏了。 现改由工具侧门禁 tools/check_doc_version.js 承担(node 能同时读三个文件), 四处口径一并订正。 ⇒ 纪律 12: 注释里写"已被断言覆盖"不等于真被覆盖。声称某处有防线时, 必须同时给出该防线失败时的可见信号; 给不出, 就说明防线不在你以为的那一层。

K. 收尾批: 默认值口径清账 + 入室 CO₂ 守恒修复(2026-08-14)

清两条遗留。(1) 脱气塔默认值三处文档与代码不符: v2.0 对标 Timmons Ch.10 把 co2StripperGtoL 3→5、co2StripperLoadingRate 40→80、 co2PackingHeight_m 1.0→1.5, 而参数速查表、阶段卡片 title、手册 15.4.1 三处都没跟。 这是数值口径错不是排版问题: 用户照文档填 3, 模型按 5 跑, 风机功率差 1.67 倍 (手册例题写 35 kW, 实算 58.8 kW)。另修两处死 fallback(: 3 / : 1.0), 与第七轮审计咬中的 : 0.2 同型。 新增门禁 tools/check_defaults_sync.js, 判据对准 PROCESS_DEFAULTS 这张表 (D1 死 fallback / D2 title「默认: X」/ D3 参数速查表默认列), 上线当天咬出清单上没有的第四处: denitriFlowPct 文档写 10、实际 2。负对照 4/4。 ⚠ D1 另报 33 处同值副本, 有意不判红 —— 一次性改造属独立重构批次, 混进来会淹没 "数值口径错"这件事; 该计数应逐批下降而非上升。

(2) air + 开塔 入室 CO₂ 少算(遗留 §6-1)已修。缺陷本体见手册 15.3c.4。 要点: 曝气吹脱的 CO₂ 水侧不记移除、室侧不记入室, 两头都不记 = 孤儿项 —— 与 v2.0 Q_air_gain、v2.1 蛋分气流、v2.2 K-101 轴功同族, 第五次。 最能说明问题的对照: 修复前 air+开塔 与 o2+开塔 的池内 CO₂ 完全相同(罗非苗种期均 10.55), 尽管前者有 476 m³/h 空气打进池子。修法是取消特判而非补第三档: 入室份额由质量守恒导出, o2 与 air+关塔 两档退化为原值逐位不变。方向标反的代价: 修复前该工况 CO₂ 新风需求恒为 0, 罗非 1000t 成鱼期新风 6,499 → 11,460 m³/h, 通风机原来选小 1.76 倍; 而综合成本只涨 0.09 元/kg —— 靠成本异常根本发现不了, 只能靠守恒。 补断言 X0–X3 + 锚定工况 edge_air_stripper_on, 自检 29 → 31, 负对照 6/6, 13 条基线逐位不变。

(3) 一个被负对照咬出的断言漏洞(本批最值得记的一件): X0 最初写成 X1 的守卫 if (sim.co2Removal) {…}, 于是"撤掉该导出"这一负对照竟然全绿 —— 导出没了, 整块断言直接被跳过。改为独立判定后当场转红, 并顺带咬出空场骨架漏导出 (与二批 W0 是同一课)。⇒ 纪律 14: 守卫会吞掉失败。导出面本身必须是受检对象, 不能是判定的前提 —— 凡写 if (X) { 判定 X 的性质 }, X 缺失时你得到的是绿, 不是红。

L. 下游审计批①: 告警链从 sim 打通到可研报告(2026-08-14)

二批把告警做成结构化 configWarns 时, 交接文档记的是「报告侧消费未做」。 审计实测发现比这严重一档: 数据根本没过桥 —— configWarns / aeration / aerIntensity / 入室 CO₂ 四组量全不在 payload 里, 下游想消费也没得消费。于是"报告照出成本、不带任何不可行标记"这句话是字面成立的。

(1) 先造审计器: index 与四个下游页之间此前没有任何契约 —— 下游多读一个字段 拿到 undefined 而不是报错, 上游删一个字段也没人知道。这是「转发断链」模式 在页面之间的翻版, 只是跨了 localStorage。audit_downstream_contract.js 把 payload 包成递归记录 Proxy 记下每页实际读了什么; 不用静态扫描, 因为下游大量 d[k] 动态取键。 (2) 过桥: 产出面 831 → 874 条, 纯搬运不加工; 断言 Y0–Y3 判逐位相等而非容差 —— 过桥中间任何差异都说明有人加工了, 而加工正是双源漂移的起点。 (3) 呈现: report 新增 15.5「设计边界与模型告警」节 + 第 5 章就地标注 + 第 16 章结论改条件式(原来无论如何都印「工艺技术上完全可行」, 现在检出 danger 级时降级并要求决策文件留痕)。取向是显式披露而非硬阻断: 不拒绝生成报告 —— "我知道超标就是要出个初稿"是正常用法, 挡住只会让人绕过工具, 但白纸黑字。 (4) 顺带修 report.html 的 sproc.peakFactor || 1.5: peakFactor 是阶段级字段不在 proc 下, 该行永远回落字面量 —— 读错层级 + 字面量兜底 = 静默错值, 与 recDepth_m 那六次同族。

(5) 本批最值得记的: 审计器自己被跑瘸了三次。 ① jsdom 不加载外部脚本, finance/report 被跑成"只访问 9/14 条路径"的假空场, 差点得出「下游几乎不消费」的错误结论(注入本地依赖后 933/937 条); ② Y 断言首版写在逐工况循环外, 只看最后一个工况的 lastResults 而它恰好 没告警 ⇒ 负对照「截断 configWarns」全绿 —— M13/M14 陷阱第三次复发, 本批自己踩的; ③ 门禁用裸 nunjucks 渲染而 report 自注册了 wan 过滤器 ⇒ 报假红。 ⇒ 纪律 17: 审计器把被审对象跑瘸了, 得到的"干净"是假的; 把自己跑瘸了, 得到的"红" 也是假的。出现"全绿"或"全红"这类整齐结果时, 先怀疑审计器, 再怀疑代码。

(6) 一个撤回的误报: stages[].subSystemCount 初报 56 次 orphan, 实测设成 3 就正常导出 3 —— 只是默认未设定的可选字段, 下游 || 1 兜得住。 审计器的判据不能区分"该有而没有"与"本来就可以没有", 其 ORPHAN 表须逐条复核, 不可直接当缺陷清单。

M. 下游审计批②: 设备清单少四台、总价却对得平(2026-08-14)

(1) pid 内嵌示例冻结四个版本: 点"载入内嵌示例"得到的是 irasVersion 1.1.0 / pidSchema 1.0 的数据(G:L 3 / 塔风压 5 kPa / pumpHeatRatio 0.85, perStage 仅 8 键), 而 SUPPORTED_SCHEMA_MAJOR 只比大版本 ⇒ 照常载入、不报一句警。 根因不是"忘了更新", 是"有机制、无工具" —— 源码里本来就留了注入哨兵, 说明设计上 就该有注入工具, 但它从没被写出来, 注入成了一次性手工操作, 做完即失传。 现补 inject_pid_sample.js + 门禁 C6。⇒ 留了钩子不等于钩子会被拉。

(2) 设备清单少四台设备, 而总价对得平: equipment.html 的行是硬编码的, 冻结在写它那天的设备集合, 缺 K-501 蛋分供气风机 · DH-1001 除湿机 · AHU-1002 暖通机组 · KV-1003 车间通风机。⚠ 金额层面没有错 —— finance/report 用聚合值 capex.total, 这四台的钱一直在里面。错的是"清单少四台、总价却对得平": 对账对得平, 所以谁也发现不了, 只有拿这份清单去询价/招标时才会发现少买了设备。这类不一致比数值错更难查。 修法不是手工补四行, 而是 index 导出 capex.items、equipment 改为自 CAPEX 清单 反向补全 —— 以后新增任何设备都会自己出现。门禁 C7 锁位号集合包含关系。

(3) 让设备自己说清"为什么是这个规格": K-101 行补选型控制侧(O₂ 传质 / CO₂ 吹脱, 两侧风量并列)、设计 DO 及其来源、实际 OTE、池底布气强度与超限告警(含可行密度上限); KV-1003 行补控制项(CO₂ 稀释需求 / 换气次数)、车间稳态与限值, 由 CO₂ 顶大时明写 "改增氧方式或脱气塔配置后必须重选"。pid/finance 有意不消费 —— "未消费"是决定, 不是遗漏。

(4) 死负载 371 → 365 → 22 → 10, 前两个数都是量具错: 先拿运行时 CONSUMED 表反推(371), 但 Proxy 把 JSON.stringify/深拷贝这类深度枚举也记成"读取", 两个方向都虚高; 改静态文本判据后叶子名被 depth-6 截成 label…, 判据全军覆没, 365 里 308 条全是这一个 bug。 真实值 22, 消费落地后 10。现判据保守: 出现 ≠ 一定在用, 但不出现 = 一定没用。 加 C8 棘轮逼迫"过桥"与"消费"同批完成。

(5) 一条被推翻的旧结论: 批① 曾宣布"ventFan 单价下游同步已验证通过", 错的 —— 它在 finance.html 里一次都没出现。正确结论是分层的: 金额层面 ✓, 清单层面 ✗。 ⇒ 运行时"读过"不等于"在用"。

(6) 纪律 17 在两轮内被验证 7 次, 批② 又踩四次: 门禁只写 localStorage 而被审页读 sessionStorage; equipment.html 读完即 removeItem 而 jsdom 同源实例共享 storage, 门禁第二次打开就空手(⇒ 假定被审页面有副作用, 每实例独立 origin); 写门禁时掉了一层转义致正则退化, 而这次是被自己写的 catch(e){ return '[]' } 挡住的 —— 纪律 14 刚写完就又犯一次; 死负载三次报错全是量具问题。 ⇒ 补充: "零脚本错误"不等于"渲染出了东西", 空页也零错。

N. 版本口径批: 下游页版本号跟随主页面(2026-08-14)

项目方决定: 下游页版本号不再各自演进, 一律跟随主页面。四页此前是 equipment v1.3 · pid v2.0(图签另写 v2.1)· report v1.7 (templateVersion 又是 v1.5-alpha-1)· finance 根本没有版本号 —— 四页四个口径, 现全部对齐 2.3.3, 各立 IRAS_PAGE_VERSION 作单一事实源。

(1) 判据必须分层 —— 有两类版本号不跟随。一刀切会改坏两样东西: ① 数据契约版本(pidSchema / pidSchemaMinSupported / SUPPORTED_SCHEMA_MAJOR)表达的是"能读哪些格式", 与产品版本无关, 跟着改会直接破坏向后兼容; ② 史料标注(注释里的 // v1.7: ...)是 "这行代码是哪版加的", 改掉就抹掉了来历。三类在 docver 登记表里显式区分。

(2) 图签版本取方案自身而非页面。pid 图签的"版本"格优先取所载入方案的 irasVersion, 无数据时才回落页面版本 —— 图纸上的版本应当是"这张图是哪版 算出来的", 不是"看图的工具是哪版"。

(3) 补上此前四页都没有的一件事: 「方案版本」与「页面版本」不一致时显式提示。 二者是两回事; 旧方案在新页面上打开会走各处兼容回退, 结果看起来正常但口径是混的, 而此前没有任何信号。现 pid 走 toast, equipment 写进元信息行。

(4) 门禁: docver 登记表 10 → 19 项, 负对照 4/4。其中"主页面升版而下游七处 不动"这个发版全场景, 纳管前只咬中 8 处, 现咬中 17 处。⚠ 读取下游页时缺文件即判 工具异常退出, 不静默跳过 —— "文件不在就当它没问题"正是本轮反复咬出的那类假绿。

⭐ 最新 v2.4 → v2.5: 沿程口径归位 v2.5 · 2026-08-23 · 第八轮审计

版本主题只有一件事: 把几个算在了错误位置的量放回它该在的节点。 起因是一份外部审计(第八轮), 七条 B 类问题, 复核后确认六条、升级一条、降级一条、新增两条。 13 条数值基线全程逐位不变, 自检 35 → 40。

A. 沿程碳酸盐逐节点重算 (B1)

沿程节点用 s = {...s, ...} 逐节点展开, 只覆写各自改变的 CO₂/TAN/TSS/NO₃/DO, 于是 pH / fNH3 / NH3_N / Ω / β 五个字段原封不动从鱼池复制到全部七个节点。 后果: 脱气塔节点 CO₂ 降 65%, 真实 pH 升 0.33、Ω 由 0.75 升到 1.52(跨过饱和线), 而界面上七个节点全标"欠饱和"; 生物滤池节点 TAN 降了 70% 而 NH₃-N 是绝对值没跟着变, 偏高 3.4 倍。

重算需要该节点的 (TA, CO₂) 两个量: TA 沿程不守恒, 生物滤池每硝化 1 mg/L TAN 消耗 ALK_PER_TANN = 7.14 mg/L CaCO₃(该系数同时提升为模块级单源常数, 此前 calcAlkalinity 里是个字面量)。鱼池节点用同一组 (TA, CO₂) 重算, solve() 确定性 ⇒ 逐位复现原值, 故设计判据与导出面不受影响。 哨兵 IRAS_V25_CHAIN_PH。

B. CO₂ 按产生位置链式重导 (B8) —— 本批唯一改数的一处

呼吸产 CO₂ 在鱼池, 硝化产 CO₂ 在生物滤池, 而生物滤池位于鱼池下游、脱气塔上游。 链式质量平衡给出 C_塔前 = Δ_总/(η + η_换水)(恰好等于原集总式的值)与 C_鱼池 = C_塔前 − δ_n。空气曝气模式下两类汇点位置也不同, 需按 A = 1 − η_池内、B = 1 − η_下游 联立, 纯氧模式是 A = 1 的特例。

实测鱼池 CO₂ 降 15–28%(纯氧)/ 23–39%(空气曝气), pH 升 0.07–0.22, Ω 升约 30%。 CO2_OVER 告警无一翻转, 海水鱼种 Ω 仍多数 < 1。按 D1-c 双报落地: 鱼类福利判据取鱼池值, 同时导出 co2StripperInlet_mgL 作为设备选型口径 —— 原实现把两个工程量混在一个数里, 用鱼的限值去卡一个鱼接触不到的浓度。 哨兵 IRAS_V25_CHAIN_CO2。

C. NH₃ 峰值位置判据 (B5)

模型把 pH/NH₃ 报在鱼池出水。该点对 CO₂ 与 Ω 最保守, 但对 NH₃ 不保守 —— 同一点 TAN 最高而 fNH₃ 最低, 两个偏差方向相反。缓冲区内 fNH₃ ∝ 1/[H⁺] ∝ 1/CO₂, 故:

忽略 δ_n 时退化为简洁判据 η_bio > η_co2; 计入后阈值由 63.4% 松到 54.8%。 判据在推荐输入范围内即可翻转(生物滤池推荐值与脱气塔可达效率区间重叠), 极端组合下塔后 NH₃ 达池值 4.9 倍。告警不引入新阈值, 直接取沿程实算最大值比对 —— B1 修好之前这段做不了, 那时七个节点的 NH₃ 是同一个复制值。哨兵 IRAS_V25_NH3_PEAK。

D. 换水稀释补回 CO₂ 稳态式 (B4)

原注释称"V_replace ≪ Q×24×η, 偏差 < 1%, 可忽略"—— 该论证只在高 η 下成立, 而 η = 5% 正是纯氧关塔时 co2FallbackEff 的默认值。实测偏差 0.13%(η=65%)/ 1.63%(η=5%)。连带必须同批: 补回换水项后"产量 ≡ 塔移除 + 曝气移除"不再成立, 而 fracIndoorCO2 的第二项默认"剩下的全是塔的", 会把随排水离场的那部分 乘 degasFrac 送进车间。改为三份额分解 + 断言 X1b(三份额之和恒为 1)。 哨兵 IRAS_V25_CO2_DILUTION。

E. MBBR 尾气去向可选 (B9)

bfBlowerSpec.airPath.sink 原写死 OUTDOOR。澄清: MBBR 与鱼池同厅与否, 只决定风机电机废热去哪个房间, 不决定气去哪儿 —— 同厅照样可以加盖外排, 两个决策相互独立。 故开放为工艺选项 mbbrCovered(默认 true = 加盖外排 = 既有行为, 基线逐位不变)。 敞口时 0.50 t/d 水汽进厅 ≈ 342 kWh/d 潜热, 是池面蒸发项的 1.35 倍, 全库热泵电费最大变动 12.3%。 断言 V4 借此由"只认 K-101"推广为逐股白名单(比原判据更强)。哨兵 IRAS_V25_MBBR_COVER。

F. pH 与硝化的不一致 · 求解器边界 · 亚硝酸盐边界 (B2 / B7 / B3)

B2: biofilterTAN 是常数效率, 与 pH 无关, 而硝化速率对 pH 高度敏感 —— 模型会同时输出"pH 6.9"与"硝化效率 70%", 两者物理上不相容且偏差方向乐观。 本版只告警不折减(硬套一条来源不同的 f(pH) 曲线比明确宽带更糟)。 ⚠ f(pH) 在实现上不成环: pH 只依赖 (alkTarget, co2_tank), 而 co2Daily 用的是 产生的 TAN 不是被硝化的 TAN, 故是单次前推 —— 留给下一版。

B7: 碳酸盐求解器在 pH 2–12 上二分, 真解在区间外会静默返回端点值。 加括号符号检查并随返回值带出 boundaryHit(不抛异常 —— 调用方是静默降级的, 抛出会把"可疑的数"换成"没有数")。⚠ 当前输入域够不到(alkTarget 钳在 [20,400], CO₂ 恰为 0 时 alk=400 也只到 pH_sws 11.53), 属防御性; 故不写自检工况而用单元级断言 N1, 其中 N1a' 专查"够不到"这个前提本身 —— 前提失效时它会转红。 哨兵 IRAS_V25_PH_BRACKET。

B3: 新增 §4.5.3b 说明氮链为何不含 NO₂⁻ —— 这是稳态口径的固有边界, 不是待补功能。详见该节。

G. 文案实算值锚定 (扫尾)

B8 把全库鱼池 CO₂ 动了 23–39%、Ω 动了约 30%, 而发布说明里 "实测海水鱼种 Ω 0.37–1.29 全部欠饱和"这句话一个字没跟着变, 而且定性结论已经反了 (对虾苗种期实测 1.63, 为过饱和)。当时 40 条自检全绿、25 项 docver 全绿 —— 因为没有任何门禁在看文案里的实算值, 是靠人眼发现的。

H. logo 改版: 孤立 R → iR(独立于水质线)

原 logo 是一个孤立的 R —— 读不出品牌名。改为 iR,几何定稿 R 0.98 · i 冻结(笔 53 / 点 r30)· 字距 34 · 整体右移 14, 逐档栅格化到 16/24/32/48/64/128 目视比选而定, 非拍脑袋。

为什么右移 14: 外框居中时留白 80/84 看似对称, 但墨迹重心在 x=241.9、偏左 14px —— 右下那条腿是细斜杠, 左上却是实心 i 竖笔加 R 的厚字碗。右移后重心 255.9 ≈ 画布中心 256。 i 有意比 R 主干细约 1/3: i 是前缀, 主体是 RAS, 等粗会读成两个并列字母而不是一个词。 全尺寸统一, 不设简化版 —— 16px 下 i 的点会与竖笔并成一根竖线, 这是有意接受的代价。

单一事实源为 logo-master.svg, 几何参数与取舍理由写在文件头部。派生出 favicon 的 data URI、三处可见内联 SVG(页头 / 「关于」面板 / 手册导航条)、 以及 favicon.ico(手工封装 PNG-in-ICO, 16/32/48/64/128 逐尺寸单独栅格化 —— PIL 的 ICO 保存只会把一张图重采样到各尺寸)与两个 PNG。

顺带修掉两个既有缺陷: ① apple-touch-icon 指向 favicon-180.png(带连字符), 而库内实际文件名无连字符 —— 线上必然 404, iOS 加主屏取不到图标; 已改指真实文件名, 并由门禁第③组断言「引用的图标文件必须真的在」锁死。这同时解释了 v2.4 MD5SUMS 里那个缺失文件。 ② 手册导航条 logo 原为纯色方块内写 "iR" 文字, 背景 #00b4d8 与品牌渐变 #0C9ED5 → #1A5CD7 本就不一致, 已换成真标记。

⚠ 门禁证明不了的事: 三个栅格派生物无法逐字符比对, 只能校验存在与尺寸 —— 它们是否由最新母版生成, 本工具证明不了(与 MD5SUMS 头部第③条同理)。 改 logo 后必须重跑栅格派生, 这一条只能靠流程。 另: og-cover.png(社交分享卡片图)在服务器上不在库里, 仍是旧 R, 需服务器侧替换。

I. 物质平衡断言 · MBBR 曝气重构 · EBCT 分子修正

I-1 物质平衡断言(氧 O1–O3 / 碱度 A1–A3)。 本库此前没有一条物质平衡断言 —— "今天闭合是因为公式恰好写对, 不是因为有东西防止它写错"。立断言的关键是 被比的两边必须来自不同的计算链: 既有的那条碱度断言把上一行的赋值原样验一遍, 永远绿, 与 bioVolume × VTR ≡ tanDaily × sBio(注释自己判过"校核没有意义")同类。

I-2 MBBR 曝气重构 —— 本版改动最深的一批。 原模型三处错: ① 风机按需氧选型而 SOTE 写死 8%, 但 SOTE 的标准定义是清水 20 °C、溶解氧为零(驱动力最大点), 实算冷水纯氧工况实际 SOTE 仅 0.35–0.5%; ② 沿程 BF 节点把全部需氧从水里扣掉(等于假设密闭罐无曝气), 而同一份已拿去选风机 —— 同一股氧算两遍; ③ Math.max(bfDOout, 2.0) 是 ② 的创可贴, 地板生效时凭空造氧。

新口径把因果倒过来: 风量由流化决定, DO 由质量平衡解出 DO_out = (Q·DO_in − R + M·k·β·Cs_水深)/(Q + M·k) —— 解是两端点的加权平均(风量 0 → ∞), 数学上跑不出窗口, 不需要钳制或地板。 反方向(输入目标 DO 反算风量)有 1/(Cs−DO) 渐近线, 且 DO=4 在 24 个工况里 18 个物理不可达, 故不采用。

四个新输入: bfAirFlux 10(2–20)· bfDepth 3 · bfDOMin 4 · bfAlpha 0.85(⚠ 无 RAS 出处, 待标定)。 DO 低于下限只告警、不自动加风, 告警给出"需把通量提到 X、届时功率 Y", 让用户做有标价的选择。风机压力改由水深导出, 替掉硬编码 50 kPa(≈5 m, 与 3 m 默认自相矛盾)。

基线变动 52/52, 最大 4.62%, 且方向分裂 —— 这正是改动的意义: 冷水鱼种电耗 +1.9~2.4%(池大、流化风量大), 暖水鱼种 −3.4~−4.6% (原来按清水 DO=0 的驱动力选型, 虚高三倍多)。

I-3 EBCT 判据分子用错(用户实测报出)。 "去除率与接触时间不自洽"告警用填料净体积当分子, 而 EBCT = Empty Bed Contact Time, 分子必须是空床即反应器容积 (V_BF = bioVolume / 填充率)。50% 填充率下 EBCT 低估整整一倍, 该告警系统性误报。 实例: 填料 791 m³ / 空床 1583 m³ / 流量 77,615 m³/h ⇒ EBCT 0.61 → 1.22 min, 告警消失。 单源取 eq.bfTankVolume, 不在告警层第三次重算填充率。 ⚠ 只修分子, 阈值一个没动 —— 带界 1/2/5 min 是经验/文献口径, 用的就是标准定义。 修正后仍有 6 条告警(罗非、对虾), 那些是真的。

J. 补捕手: 曝气口径断言 + 台账门禁

J-1 N3a/b/c —— 把 negA/negB 那两条抓不到的补上。 上一批的负对照里有 2 条没能转红: 把风机选型退回供氧驱动、或撤掉传氧的水深/α/温度三项。 根因是 O1/O2 锁的是各模块之间自洽, 而它们改的是全模型共同采用的物理口径 —— 两边同步退回, 自洽性依然成立。

N3 换一个抓法: 锁住"用户填的输入必须真的进入计算"。 N3a 风量 ≡ bfAirFlux × 池底面积; N3b 风压 ≡ bfDepth×9810+15000; N3c 从导出量反解传氧系数, 须等于 0.012×水深×α×θ^(T−20)/9.09。 负对照 3/3 各自精确转红, 一一对应。

J-2 check_ledger.js 台账门禁。 本轮交接台账 §6「下次开工核对用」的门禁基线过期 3 次(anchors 计数 ×2、defsync ×1), 外加遗留表挂着已完成项。三次都是加完东西忘了同步, 而没有任何门禁在看台账 —— check_doc_version 查的是版本号一致性不是新鲜度; check_anchors 不查 HANDOFF 里抄的那个数。

新工具做五件事: L1 实测重数 anchors · L2 selftest 总数交叉 README 徽章 · L3 台账 §6 ⇄ MD5SUMS 头部 · L4 台账引用的文件必须存在 · L5 遗留表已完成项必须划掉。 一上来抓到 2 条真的: defsync 台账 171 而 MD5SUMS 头部仍是 167; 以及本工具自己的计数正则 与 check_anchors 不同导致的误报(已对齐)。

K. MBBR 曝气对 CO₂ 的吹脱(原 B10)

为什么此前写死 0, 以及那个 0 不算错。 v1.9 定 BF_CO2_STRIP = 0, 注释写"保守, 脱气塔选型偏安全"—— 该判断成立: 承认吹脱后塔前浓度实测由 9.53 降到 8.47, 塔确实可以选小一档。旧值是留了余量, 不是算错。

逼近系数单开 bfCo2Approach = 0.23, 不复用脱气塔的 0.5。 塔是填料逆流, MBBR 是池内粗孔鼓泡; 本手册自记"粗孔盘仅达理论平衡约 23%、细孔盘 93%", 23% 正是为粗孔盘记的。复用塔的值等于宣称两者传质逼近程度相同, 属"拿来源不同的数字当系数"。

链式位置在 MBBR 节点 δ_n 加入之后、脱气塔之前 ⇒ 只需把稳态式的 B 换成 Bf·B, 形状不变。 实测 η_BF: 三文鱼成鱼期 7.5%(鱼池 CO₂ 7.39→7.02、塔前 9.53→8.47)、 大菱鲆成鱼期 9.9%(9.82→9.17、13.0→11.08)。基线 0/52 变动 —— 鱼池 CO₂ 不进成本链, 而脱气塔按 G:L 与水力负荷选型、不看进水浓度。

X1b 那条"假绿"同批修了: 四条移除路径此前只登记三条(塔/池内曝气/换水), fracBF 现已进分解; 并接上 B9 —— 敞口 MBBR 时吹掉的 CO₂ 计入车间新风。 B8 归位 / B9 尾气去向 / B10 吹脱 至此在一个式子里闭合。

L. 接触水气流 ⇄ CO₂ 分解登记表(N4)

同一个洞出现了四次: v2.0 Q_air_gain 孤儿项 · v2.1 蛋分气流未登记 · v2.5 MBBR 吹脱从未计入 · 蛋白分离器的 CO₂。每次都是"某台设备的某股气流, 一半算了一半没算": 风机选了型、电耗算了、气路登记了 contactsWater, 唯独 CO₂ 那份没人管。

蛋白分离器的登记结论(全网检索后): 文献确证蛋分对 CO₂ 脱除有正向贡献 (Barrut 2012; Orellana & Wecker 2013), 但未检索到可用的单程去除率 —— 能查到的是能效(0.023 kg CO₂/kWh)或标准传质速率, 几何依赖强, 不能直接折成去除率。 按 MBBR 同口径粗估约 2.6%, 属二阶项; 略去方向保守(脱气塔进水浓度偏高 ⇒ 塔选型偏大)。

M. 碳酸盐缓冲修正: 表观 vs 真实脱碳量

问题: 按气相载量算出的 CO₂ 去除率(MBBR 曝气吹脱、空气曝气模式的池内曝气) η = 风量 × kLoad × 逼近系数 / 水量 给出的是从总无机碳 DIC 里转移走的质量; 模型此前把它当作自由 CO₂ 的降幅使用 —— 等价于假设缓冲因子 = 1.0。

实际上 CO₂ 被吹走后碳酸盐平衡右移(HCO₃⁻ + H⁺ → CO₂ + H₂O), 重碳酸盐转回补上, 自由 CO₂ 的降幅小于被吹走的质量, 这两个去除率因此被系统性高估。

依据: Colt 等 2012 —— 基于总碳酸盐变化的真实脱碳量大于表观值, 海水高碱度下尤甚; 同时指出淡水条件下 CO₂ 吹脱不受酸碱平衡影响(碱度 ≤ 200 mg/L CaCO₃)。实测完全对上: 淡水缓冲因子 1.02(几乎不变), 海水 1.15–1.26。

新增两个碳酸盐函数: co2FromDIC(由总碱度与总无机碳反解自由 CO₂, 几何二分 —— 无闭式反函数, 因 DIC 是 CO₂ 与 [H⁺] 的耦合式)与 co2BufferFactor。 后者就是海洋化学 Revelle 因子的绝对量写法: 缓冲因子 = DIC/([CO₂] × Revelle)。 实测本工况 Revelle ≈ 13.9(pH 7.22 海水), 落在海洋典型 8–15 内 —— 独立口径的旁证。

实测影响: 三文鱼成鱼期 MBBR 吹脱率 7.5% → 5.94%, 鱼池 CO₂ 7.02 → 7.10; 大菱鲆 9.9% → 8.56%, 9.17 → 9.25; 罗非(淡水)几乎不变。基线逐位不变(不动成本链)。

N. 淡水方解石饱和度: 钙输入 + 活度修正(B6)

原缺陷: 钙由海水恒定比例反推 ⇒ 淡水盐度为 0 时钙恒为 0, 方解石饱和度 Ω 直接算不出。 罗非、加州鲈、鳜、鳗四个淡水鱼种全场 n/a, 占鱼种库一半 —— 而本手册自己写着淡水 RAS 的碳酸钙溶蚀(溶蚀混凝土池体、池壁起砂)是真实工程问题, 恰恰算不了。

新增两个输入: 钙口径(自动/手动)与钙硬度(默认 90 mg/L as CaCO₃)。 出处: USGS 硬度分级(0–60 软 / 61–120 中等 / 121–180 硬 / >180 极硬); 水产目标区间 SRAC 464(游离钙 40–100 即钙硬度 100–250, 其中 100 mg/L 游离钙恰与鱼血钙浓度相当); Boyd(鱼 >50、甲壳类 >80)。取 90(中等硬度地下水)—— RAS 补水多为井水。 海水档一个数没动: 海水反推给 412 mg/L Ca²⁺, 与文献典型海水约 400 直接吻合。

⚠ 残余不确定度(已写进代码与 UI 提示): K1/K2 在盐度 0 处的标度约定未经独立核对; 若它们也是活度标度, 则由其解出的碳酸根已含活度, 本修正会略微过头。 LSI 交叉验证表明总方向与量级正确, 但淡水 Ω 仍应视为 ±30% 量级的估计。 离子强度亦为估算(由碱度与钙硬度加电荷平衡推出, 未计镁与硫酸根)。

O. 生物滤池异养呼吸的 CO₂(整项缺失)

缺陷: 设计口径 CO₂ 产量式为「池内耗氧 × 1.375 + TAN × 6.286」。代码注释写着 「池内耗氧含池内异养耗氧, 故本式的 CO₂ 也自动含池内异养呼吸产的 CO₂」—— 关键词是「池内」。而生物滤池内的异养耗氧是单独一项, 参与生物滤池风机选型, 但它的 CO₂ 一分都没进产量式。 ⇒ 氧账本里有、碳账本里没有 —— 又一个「一半算了一半没算」。

实测锚定 —— 本版少数几条有实测支撑而非推导的修正。Summerfelt 等 2004 《Design implication of carbon dioxide production within biofilters contained in recirculating salmonid culture systems》(Aquacultural Engineering), Freshwater Institute 商业规模鲑鱼 RAS 实测: 滤池产 CO₂ 4.1 ± 0.2 mg/L, 同时去除 0.51 mg/L TAN 与 3.8 mg/L 溶解氧。 拆解为硝化项 3.0 mg/L(60%)与异养项 2.0 mg/L(40%)。 论文标题直指: 循环水系统中很大一部分 CO₂ 由生物滤池产生。

补项前后(生物滤池节点的 CO₂ 增量): 三文鱼成鱼期 2.14 → 3.41、 大菱鲆 3.12 → 4.68、罗非 1.67 → 3.11 mg/L —— 补项后落入实测区间 4.1 附近; 只算硝化则偏低 33–46%。系数 1.38 g CO₂/g O₂ 出处同上, 不是新的待标定项。

结果: 设计口径 CO₂ 产量上升 19.8%; 鱼池 CO₂ 7.10 → 7.71、脱气塔进水 8.69 → 10.44 (三文鱼成鱼期); 海水方解石饱和度包线 0.60–1.63 → 0.55–1.53。 数值基线 0/52 变动 —— 鱼池 CO₂ 不进成本链, 脱气塔按气水比选型不看进水浓度, 且 CO₂ 超标告警在所有基线工况下未被顶破。

P. 生物滤池对溶解性 COD 的去除(整项缺失)

缺陷: 原去除路径注释原文「溶解有机物: 蛋分(旁路) + 高级氧化(旁路) + 换水」——没有生物滤池。 异养菌吃掉的底物本该从水里消失(变二氧化碳 + 菌体污泥, 污泥经微滤机与换水排出); 模型算了异养耗氧、也补了异养产 CO₂ —— 唯独没扣底物, 产生与消耗各记各的。

落地结果(关蛋分 = 淡水实际工况): 罗非 277 → 37.2、加州鲈 → 35.1、 三文鱼 → 32.7、鳗 → 46.2 mg/L, 与文献 35.6 同量级。

⚠ 本值是等效值 = 可降解占比 × 可降解部分去除率, 两件事挤在一起。 正确做法是拆成可降解/难降解两层并与产率系数闭合, 已排入生物滤池模型重构大批次。 ⚠ 字段名沿用历史称谓; 该量以 mg O₂/L 计即溶解性 COD, 将与降解性拆分同批重命名 —— 不单独改名, 以免白付导出面变更的代价。

v2.3.3 → v2.4: 四个量的口径单一事实源 v2.4 · 2026-08-18 · 五批

〔⚠ id 说明: 本节 id 是 rel_2_3_3_2_4 而非 rel_2_4 —— 后者已被占用, 指的是 2026-08-12 的内部特性批次「简易模式 · 自然通风与太阳辐射」。 本库两套编号并存: 发布版本号(v2.4)与内部特性批次号(v2.4/v2.5/v2.6, 均未独立发版)。 代码里 IRAS_V24_* 是后者, 本次发布批的新哨兵一律 IRAS_R24_*。 详见 index.html 顶部的编号说明块。〕

版本主题只有一件事: 给四个从来没有声明过口径的量建立单一事实源。 起因是一份热平衡专项审计, 它指出气液接触器的质量流量取错了状态点(用了风机加热后的密度); 复核后发现根因更深 —— airFlowM3h 从来没有声明过参考状态, 三个产气者各按一套隐含口径, 相加后再乘一个密度, 本就无解。

A. 室外 CO₂ 本底: 同一物理量的两份口径

合并前热工侧写死 const co2Out_ppm = 450(无 UI、无默认表条目、无 FIELD_SPEC), 而 PROCESS_DEFAULTS.co2IntakeCO2_ppm = 350 是同一物理量的另一份 —— 值还不一样。后者更麻烦: 它有读取路径 getNumClamped('co2IntakeCO2_ppm', …, 300, 5000), 但 data-proc-field 命中 0 ⇒ 那句钳制从未执行过, 该字段只能改方案 JSON。

现统一为 GLOBAL_THERMAL_DEFAULTS.co2Outdoor_ppm = 450, UI 可调, 范围 300–5000, 两个消费点(车间新风稀释基准 dC = 限值 − 本底 · 脱气塔 auto 模式进风本底) 一律经 resolveCO2Outdoor()。钳制放 resolver 而非读取函数 —— 方案 JSON 经 restoreState 直写全局配置, 绕过 UI 约束(v2.3 P1 教训)。

唯一数值变化: 塔进风本底 350 → 450, 仅影响 co2StripperEffMode='auto' 的用户 (默认 manual), 塔效率降 0.74–1.33 个百分点。

⚠ 撤字段时把原注携带的 Fig 10.17 论证 (本底 1000 ppm 去除率降 10%、5000 ppm 降 70%)迁存到脱气塔 airPath 处 —— 那是「尾气必须排室外、不得回车间」的量化依据, 字段可撤, 依据不可撤。

B. 工艺风量的参考状态: 声明为标准状态 Nm³/h

裁决(项目方): airFlowM3h 全库一律为标准状态体积流量 (0 °C · 101.325 kPa), 因为对外向风机厂家提规格时给的就是 Nm³/h + 压力, 机器由厂家按此选型、质量由该单位本身锁定。

为什么必须显式声明: 参考态在选型式与接触器之间会抵消 —— mass = airFlowM3h × ρ_ref = o2Peak·s / (f_O2 × OTE), 故对「由 O₂ 质量反算风量」的气流 (K-101 鱼池曝气 / BF 风机)取多少都不影响物理; 但对「体积比」气流 (脱气塔 flowM3h × G:L / 蛋分 skimmerFlow × skimGtoL)没有任何参考态可抵消。 不声明, 接触器的质量流量就无解。

v2.2 的六次不动点迭代整段删除。 它当年确实让 ΔT 与质量流取了同一密度, 但统一到了「风机加热后的密度」这一侧 —— 而风机不改变质量流量。 现质量流是常数, mdot·cp·ΔT ≡ P_shaft 恒成立, 断言 A3 逐位不变。

⚠ 审计建议的断言 mdot×3600/air ≡ ρ(T_air) 不采纳 —— 它锁的是"实际进气体积"口径, 与标准态裁决相反。锁错口径比不锁更糟。

⚠ 全库 1.2 共 9 处, 只改 3 处: Lewis 类比的车间空气密度(×2)· 除湿/暖通选型裕度(×4)· UA_vent 的建筑物理常数 0.34 (= 1.2×1006/3600)均不得改动, 由断言 A4d 反向保护。 0.23 同理: 它与鱼种耗氧系数 o2FishFactor(鲑 0.20–0.23)数值相近而物理无关。 禁止全局替换(本库有 v2.0.0 版本号全局替换污染历史叙述的先例)。

C. 风机送进车间的那股空气: 它就是新风

K-101 鱼池增氧鼓风的气路是 OUTDOOR → INDOOR —— 它吸室外空气、穿过池水、 从池面进车间(它没有风管)。进气侧为室外(项目方裁决: 所有风机进气都自室外)。 ⇒ 这股空气就是新风, 而 v2.3.3 之前一分未计, 两笔账同时错:

• CO₂ 稀释侧 —— 它是 450 ppm 室外空气, 车间 CO₂ 质量平衡看不出它与通风口进气有任何区别, 通风系统该补的只是差额;
• 显热侧 —— 它已在接触器被水加热到水温饱和, 那笔热水侧付过了; Q_vent_sens 再按 T_air→T_room 收一遍 = 同一份热收两次。

⚠ 与 v2.3.3 收尾批② 是同一股气流的两个方向: 当年补上了 CO₂ 的去向(fracIndoorCO2 由质量守恒导出), 但没回头问 承载 CO₂ 的空气本身该怎么记。
⚠ 不新增「超额排风热损」项: solveRoomAir 已把该气流作为独立股入解 (denomT 含 mEx·cp, 湿平衡含 mEx), 恒温档由 m_indoorExhaust 承载。 再加一项即把它的焓算第二遍 —— 那是收尾批② 的镜像(当年"两头都不记 = 孤儿项", 这次会变成"两头都记 = 双计"), 且守恒断言抓不到。

D. 自然通风: 从"需要多少给多少"改为钳在用户填的 ACH 上

v2.3.3 之前自然通风档同样走 max(ACH×V_room, CO₂需求), 三个后果:

• 用户填 ACH 1 / 2 / 5, 结果完全相同(室温 8.4 °C · 车间 1500 ppm · 25.03 元/kg) —— CO₂ 需求 39,304 m³/h(相当于 ACH 6.05)顶着, 用户的输入被架空;
• 那 35,414 m³/h 由谁提供? 该档没有通风机(断言 M12b 禁止), 零电耗、零 CAPEX —— 模型把"需要多少"当成了"有多少";
• 于是自然通风档成本永远优于机械通风档(25.03 vs 25.07–25.15), 成了"选自然通风就能免掉通风机"的套利口子。

物理上站不住: 自然通风由风压/热压驱动, 不会因为室内 CO₂ 高就自己变大。 而且它随开口面积与天气跨近两个数量级 —— 温室夏季敞开设计取 45–60 ACH、冬季关口除湿约 3; 同一房间把固定窗玻璃拆掉可从 9 变 66。拿这样一个量去保证 CO₂ 限值(人员暴露口径)本身就不成立。

⇒ 现钳在用户填的 ACH 上, 缺口由 V_vent_shortfall_m3h 导出并告警:

用户填的 ACH 终于有意义了。

⚠ 断言 X2(车间稳态 ≤ 限值)随之按车间档分派: 原措辞是 "新风量未按入室 CO₂ 校核(通风机选小)"——那是模型缺陷的判定, 而钳制后自然通风档超标是 用户配置的结果。但没有给该档发豁免(豁免会让 X2 在该档变成恒真), 改为替换义务: 超标时必须导出缺口(X2b), 不超标时不得报缺口(X2c)。 判据强度不降, 只是换了被判对象。

E. 三条车间通风告警

⚠ ROOM_ACH_TOO_LOW 取 warn 而非 danger: 该组合有合法工况(冬季关闭通风口运行的简易棚), 按纪律 10 有合法工况就不判 danger, 措辞里必须写明"什么时候可以忽略我"。
⚠ VENT_CTRL_BY_CO2 的措辞里明确写着不要为了缩小通风机而开脱气塔 —— 实测在空气曝气下开塔使全场能耗上升 27–93%(罗非恒温 8.855 → 13.676 kWh/kg)。 脱气塔的作用是压低池水 CO₂(通常配液氧拓扑), 不是省车间通风。 这一条拦住的正是"只看通风机风量降了 71%、没看总账"这个推理。

⚠ 原遗留清单里的候选项「车间 CO₂ 超限告警」判据恒假, 已改写: V_vent_fish 是"恰好把浓度压到限值的风量"的反解, 故 CO₂ 一旦成为控制项, co2Room_ppm 恒等于限值(实测四组 air 工况全部精确 1500)。 照原样写会得到一条永远为假的判据、负对照全绿。真正要告警的不是浓度, 是为了不超标所要求的通风量。

F. 一个被撤销的批次: air 模式默认关塔

立项时据 PROCESS_DEFAULTS.co2StripperEnabled: true 判断"air 模式默认开塔", 并据此算出默认配置使成本高 9.5–22.3%。核实后撤销: 该联动 v2.3.3 四批已在 UI 事件层实现 (切到 air 时脱气塔自动置 false, 带 auto-value 样式与提示语, 并以 dataset.userSet 尊重用户的显式选择), 且由断言 S3 静态锁住不得下沉到计算层 —— 计算层若按 aerationMode 猜用户意图, 用户显式选的"air+开塔"会被静默改掉。

⚠ 该行代码已就地留痕, 写明"勿据本行断言 air 模式默认开塔"以防第三次重开。 错因: 从一个位置的值推断了系统行为, 没查 UI 事件层。

G. 门禁: 防线扩到全局配置层, 并补 U1 的反方向

check_defaults_sync 的三条判据 D1/D2/D3 全部对准 PROCESS_DEFAULTS 这一张表, 于是 GLOBAL_THERMAL_DEFAULTS 这一层从来没有门禁。本轮新增 G0–G4, 判据数 136 → 167。 上线即咬出两条(均 WARN 级, 结构性隐患非数值错, 与 D1 的"30+ 处同值副本"同一处置):

• G1b co2IndoorLimit_ppm: UI 的 min="800"(HTML 属性)与消费点 Math.max(…, 600)(代码字面量)分居两处, 无单一事实源;
• G4 GLOBAL_THERMAL_DEFAULTS 的围护五项逐值等于 ENVELOPE_PRESETS.industrial_standard —— 第二副本, 改预设表不会自动改默认值。

U2 关掉了 U1 的结构性盲区: U1 是从"有框"一侧起判的三件套(UI 有框 ⇔ 读取路径认它 ⇔ 消费点真的用它), 对「无框 + 有读取路径 + 有消费点」这一类结构上判不到 —— 撤销的 co2IntakeCO2_ppm 正是此类。U2 要求: 凡出现在读取路径里的字段, 要么有框, 要么显式登记为 JSON-only 并写明理由。现 87 个读取字段中 4 个走登记表, 且登记表双向校验(表里有而读取路径无 ⇒ 该清理了)。

H. 基线变动与正确性旁证

五批中只有 B(标准态口径)改基线, 52/52 项变动:

成本变化符号随工况方向翻转 —— 与 v2.1/v2.2 守恒修复时一致。 单向偏移才说明修错方向, 这里没有。

I. 本轮的方法论教训

本轮在六个不同位置犯了同一形态的错: 为判据或探针挑对象时用了记忆里的名字, 而不是先查。

危险性分两档: 报错型当场红, 损失只是时间; 恒真型静默全绿, 会跟着交付, 且再也不会有人发现。 前两条若不跑负对照就会随本轮一起交付。⇒ 固化为三条纪律:

• 纪律 18: 静态/结构断言必须(a)显式声明宿主函数并核实存在, (b)判据尽量取被判对象自身的结构而非旁证字段, (c)找不到目标一律判红(防恒真)。
• 纪律 19: 探针读数出现「一半对一半空」时, 先怀疑量具。
• 纪律 20: 引用变动幅度时必须看绝对值。

⚠ 另有一条判据本身写错的教训: G1 第一版写成"UI 范围必须等于 clamp", 于是把合规的 800/600 判成红。但 FIELD_SPEC 的既有设计就是 {min,max}(UI 引导)与 clamp[](消费点接受)分开存, 断言 H2 要的是 clamp ⊇ [min,max] —— 二者本就允许不等。差一点逼出一个错误的"修复"。 判据错比代码错更贵: 它会让人去改对的东西。

v2.6 → v2.7: 财务基数接线 · 生物滤池设计 TAN 口径 · 投饵率校准

本轮的性质与前几轮不同。 逐项手算复核了 11 项物理关系 —— TAN 产率 0.092×蛋白、硝化耗氧 4.57 / 耗碱 7.14 / NaHCO₃ 0.595、CO₂ 呼吸 1.375 与硝化 6.29、鱼池 TAN/TSS/CO₂/NO₃ 沿程质量平衡、热平衡、 Benson-Krause 溶氧饱和、泵功 ρgQH/η、MBBR 曝气传氧质量平衡、面速率口径 —— 全部闭合，没有一处公式错误。 缺陷全部在别处：字段没接上、默认值与判据不自洽、诊断方法本身有问题。

A. 财务 OPEX 基数：声明了七个版本，从未被读过

主页面自 v1.9.2 起导出 annualOpexForFinance = annualOpex − 维护费 + 苗种费，手册与 finance.html 表 4 脚注都写着「基数已剔除维护费，此处不重复计算」。但 finance-core.js 读的是 annualOpex —— 没有任何一行代码读那个字段。手册那句「老版本不导出时回退」，实际是唯一在跑的路径。

后果两个方向：维护费（4.5%/yr）进了基数后又按 repairRate 再算一遍；苗种费一分没进财务。 实测（1000 t，默认财务参数，全投资 IRR）：

⚠ 此前为高苗种占比鱼种（鳗鲡、石斑）生成的可研报告，财务结论偏乐观近一倍，应重新生成。

门禁没抓到的原因：契约判据只查字段「在产出面」，不查「被消费」。新增 C10 为运行时判据 —— 同一载荷删掉该字段后结果必须改变。负对照已验红。

B. 生物滤池设计 TAN：淡水默认被原样套到海水

出厂默认诊断（不改任何输入）发现两个海水鱼种 6/6 阶段各带 2 条危险级，且高度雷同： 臭氧蛋分（海水中臭氧氧化 Br⁻ 生成溴酸盐）+ 设计 TAN 0.5 mg/L 不可达。后者的机理是海水硝化有 0.70× 盐度修正，沿用淡水的 0.5 需要 104–126% 的单程去除率，物理上不存在。

处置方案转了三次，每次都由证据推翻上一次，留痕如下：

1. 抬 bfDesignTAN 0.5→1.0 —— 被该字段自己的说明驳回：「不要填告警阈值」。
2. 由 NH₃ 上限（0.02 mg/L）反算 Sn —— 反算出 1.1–3.7 mg/L，恰好落回告警线上，滤池掉到 1/3–1/5。 根因：0.02 是急性/运行上限，拿它当稳态设计目标等于零裕度。
3. 定案：行业实际直接给 TAN 设计限值 —— Nofima NCRA 研究型 RAS 设计条件为最大投饲负荷下 CO₂ < 10、TAN < 0.7–1、NO₂-N < 0.1 mg/L（Aquacultural Engineering, 2012）； 滤池成熟判据为 TAN 稳定在 0.7 mg/L 以下（Rojas & Pedersen, 2016）。 ⇒ 淡水 0.5（原值，保守端常规值）、海水 0.7。

NH₃ 不再用于反算，改作独立校验：由 pH 控制目标 + 水温 + 盐度算出设计 TAN 对应的非离子氨， 超过 0.0125 mg/L（Colt & Armstrong 1981；Meade 1985）报危险级。选型用行业惯例，安全用物理判据， 两者互不替代。实测九个鱼种落在 1.1–7.1 µg/L，最紧为罗非鱼 28 °C、pH 7.4（占限值 57%）。

同时把两条互相独立的约束分开报告，因为处方完全不同：

副产物：淡水鱼种（加州鲈、鳗鲡、鳜鱼）几乎全是水力侧受限，海水鱼种多为面积侧 —— 这是此前 「η 显示 100%」说不清的事。⇒ 海水鱼种危险级 15 → 2。

⚠ 本次推翻了 2026-08-29 的一条裁决（保持 0.5 全局默认）。推翻依据是外部文献而非内部方便， 代价已量化：海水鱼种滤池面积 ×(0.5/0.7)^0.7 = 0.79×。两条裁决同时保留在断言 N7 的注释里。

C. 投饵率校准（第一批）

新增的「隐含峰均比」派生量（峰值投饵率 ÷ 由 FCR/增重/损耗反推的年均，正常 1.1–1.5）一眼指出八处偏离， 分两类、处方相反：峰均比 > 2 者峰值虚高，< 1 者物理不可能（峰值不能低于年均）。

偏离有两个可能来源（feedRate 错，或 FCR/体重区间/时长错），故先核对生长周期： 大菱鲆 16 °C 幼鱼 SGR 实测 0.92–1.4 %/d，库内 4 个月周期无问题；大西洋鲑 0+ 烟化路线 7–8 个月、 1+ 路线 16 个月，库内 6 个月落在 0+ 下沿，偏快但可行。⇒ 四处 > 2 判为 feedRate 偏高。

峰均比告警阈值 8 → 3.0。原值从未响过（2.75、2.49 全漏）；3.0 不是新拍的数，而是这条告警 自己的文案就写着「工程设计建议峰均比 1.1–3.0（成鱼期可接近 1.1，苗种期通常 2–3）」—— 判据与自己的说明书对齐。取 2.0 反而会让它自带误报。

⚠ 本批暴露的隐含耦合。 投饵率下调后耗氧减半，而 o2SatTarget 仍是配合旧投饵率的 145/165%，池内 DO 冲到 13.8/14.2 mg/L（饱和度 128%/137%），生物滤池进水 DO 高过曝气平衡 DO， 稳态闭式解算出负的空气传氧，被自检 O2b 咬出。修法是按池内目标 DO 9 mg/L 反推饱和度。 这是收口做法 —— 硬编码的饱和度与投饵率之间仍无守卫，正解是由 designDO_mgL 反推，单独立批。 在那之前，改任一鱼种的投饵率都必须回来核对增氧饱和度。

未做的四处（罗非 S2/S3、石斑 S3、对虾 S3，峰均比 < 1）：试改后负荷推上去，危险级从 1 涨到 4。 这些温水鱼种的默认配置本来就靠一个偏低的投饵率撑着，修对就必须同时动循环倍数或密度 —— 而循环倍数已由用户裁决不得再增。单独立批。

D. 遗留：总溶解气体压力（TGP）全库贴近急性阈值

本轮调查（多来源一致）：慢性型约 103%（维持即致生长下降；浅池中已与敏感鱼应激相关； BC 省水质导则对孵化场取 103%）；急性型 110–115% 以上（一般水体导则取 110%）。 挪威 2026 年实验（n = 1440）显示大西洋鲑 parr 在 115–120% 出现急性病变，1–6 h 内鳃气栓与皮下气肿。

对照现状：salmon S3/S4 为 114/113%，turbot S3 为 113%，各鱼种末期普遍 113–114% —— 贴着急性阈值。

⚠ 并发现一处方向性错误：v1.9.2 的注释称「鱼苗对 TGP 最敏感、成鱼可到 <115%」，据此给苗种期 −20、成鱼期 −5。而文献显示相反 —— 急性病变出现在 parr（中大鱼），卵黄囊仔鱼与鱼苗反而耐受到 120%。 现行分档把最高过饱和度给了最敏感的阶段。

三条待处置：① O2_REC_BY_SPECIES 基线 165%（≈TGP 114%）整体过高；② TGP 告警分级 （>103 提示 / >110 警告 / >115 危险，现只有一条 110 线）；③ 把水深纳入 TGP（poolDepth_m 已存在， 每米抵消约 10 个百分点，不计水深会系统性高估风险）。三条合起来是一次增氧口径重定，单独立项。

E. 方法学教训：不要自造诊断工况

本轮自写的诊断脚本三次得出错误结论，每次都让判断跑偏一到两轮，而门禁全绿：

1. 诊断某工况时先改了投饵率再打印告警 —— 得到「MBBR 溶氧 0.62 mg/L、5 条危险级」，据此怀疑曝气模型有缺陷， 查了一整轮才发现模型没错，是我造出来的工况。
2. 取工况期望值时用 DOM id 设置气候，而自检走的是 globalThermalConfig 覆盖 —— 六个不同气候的工况跑成了同一个默认气候，还据此报告「模型变化」。
3. 同一脚本漏了苗价同步（代码注释明写「对虾按鲑鱼卵算，苗种成本高 50 倍」）—— 造出全成本假涨 2.4×， 并据此错误归因。

⇒ 纪律：自检已有的路径就用自检的路径，不要另写一份；任何为诊断而做的输入改动必须单列声明， 不得混进「现状」报告。并据此补了工具：run_selftest --print-actual 直接输出实测值 （数据本就在自检结果里，无需重跑）、check_md5 反向扫描（一跑抓出 5 个未登记文件， 含 C8 棘轮自己的比对基准）、package.json/version 登记进版本口径判据 （此前未登记，版本停在 2.5.0 两个版本而门禁全绿）。

F. 基线与判据

两次口径改动，基线各重录一次：生物滤池设计 TAN（36/52 项，最大绝对差 2.870， turbot_500 全成本 65.30→64.27）、投饵率校准（28/52 项，最大绝对差 1.032）。 判据：上下游契约 41 → 43（C10 两条）、默认值同步 193 → 194（U1：每个鱼种阶段字段必须有输入框）、 版本口径 25 → 26（package.json）。页面内自检维持 43/43。

逐版升级说明归档 (v1.1 – v2.5) v2.7

🚀 v2.5 · 沿程口径归位:算出来的那个数，未必是它标签上那个点（2026-08-23 · 第八轮审计）

本版主题只有一件事:把几个算在了错误位置的量放回它该在的节点。 外部审计七条 + 复核追加三条, 共十四个批次。自检 35 → 42, 13 条数值基线两次有意变更、 其余批次逐位不变。

本版最重要的一句话:集总口径下算出来的那个数, 未必是它标签上写的那个点的值。 与 v2.4 那族「取值来源型断言」治的是同一个病 —— 这次是取值位置。 守恒断言依然全绿, 因为账本两边同步变化; 标签错了, 守恒式看不见。

① 沿程七个节点的 pH / Ω / NH₃ 是从鱼池复制的

逐节点展开时只覆写各自改变的 CO₂/TAN/TSS/NO₃/DO, 五个碳酸盐字段原封不动复制。 后果: 脱气塔节点 CO₂ 降 65%, 真实 pH 升 0.33、Ω 由 0.75 升到 1.52(跨过饱和线), 而界面上七个节点全标"欠饱和"; 生物滤池节点 TAN 降了 70% 而 NH₃-N 是绝对值没跟着变, 偏高 3.4 倍。 重算需要该节点的 (碱度, CO₂) 两个量 —— 碱度沿程不守恒, 生物滤池每硝化 1 mg/L 氨氮耗 7.14 mg/L 碱度。

② CO₂ 稳态式算出来的不是鱼池, 是脱气塔进水

呼吸产 CO₂ 在鱼池、硝化产 CO₂ 在生物滤池, 而生物滤池位于鱼池下游、脱气塔上游。 链式重导给出 C_塔前 = Δ_总/(η + η_换水) —— 恰好等于原集总式的值 —— 与 C_鱼池 = C_塔前 − δ_n。即原式算的那个量, 标签贴错了地方。 鱼池 CO₂ 实测降 15–28%(纯氧)/ 23–39%(空气曝气)。 按双报落地: 鱼类福利判据取鱼池值, 同时导出脱气塔进水浓度作设备选型口径 —— 原实现把两个工程量混在一个数里, 用鱼的限值去卡一个鱼接触不到的浓度。

③ MBBR 曝气: 风机按 DO=0 选型, 而实际驱动力几乎为零

标准氧转移效率的定义条件是清水 20°C 溶解氧为零, 即驱动力最大点; 而实际 MBBR 内溶解氧 5–12 mg/L, 实算实际效率仅 0.35–0.5%, 按 8% 选出的风量与它能传的氧无关。 新口径把因果倒过来: 风量由载体流化决定(Norsk Vann 导则: 供气量不应低于 10–15 m³/h·m² 池底), 溶解氧由质量平衡算出来 —— 解是两端点的加权平均, 数学上跑不出窗口, 不需要任何钳制或地板。冷水鱼种电耗 +1.9~2.4%, 暖水鱼种 −3.4~−4.6%(原按清水口径虚高三倍多)。

④ 五处"某个量算了一半"

本版十四批里有五批是同一个模式 —— 一个量在这个账本里有、在那个账本里没有:

• 碱度收支缺排水出口项: 补水按 100 mg/L 进、系统水按 150 出, 换水实际是碱度净汇而模型记成净源 ⇒ 碳酸氢钠投加量低估 5–35%
• MBBR 曝气吹脱 CO₂: 风机选了型、电耗算了、气路登记了接触水, 唯独 CO₂ 那份没人管
• 生物滤池异养呼吸产的 CO₂: 注释写着"含池内异养", 而生物滤池内那份整项缺失 —— 实测占滤池产 CO₂ 的四成
• 生物滤池对溶解性 COD 的去除: 算了异养耗氧、也算了异养产 CO₂, 唯独没扣底物
• 气相载量型效率未计碳酸盐缓冲: 算出的是从总无机碳里转移走的质量, 却当作自由 CO₂ 的降幅用

⇒ 反复到第五次时才立了白名单断言: 凡接触水的气流, 要么在 CO₂ 分解里有份额, 要么显式登记为「有意不计 + 理由」。它不判"不计是否正确", 只判"有没有做过这个决定" —— 判据的力量在于把沉默的遗漏变成显式的取舍。

⑤ 淡水方解石饱和度: 四个鱼种从"算不出"到"方向还反了"

钙按海水恒定比例反推 ⇒ 淡水钙恒为 0, Ω 直接算不出, 四个淡水鱼种全场 n/a(占鱼种库一半)。 开放钙硬度输入后, 未加活度修正的实现给出 Ω = 1.22–1.76(过饱和, 会结垢), 而 Langelier 饱和指数独立算出 0.40–0.70(欠饱和, 会溶蚀)—— 方向相反。 而"溶蚀混凝土池体、池壁起砂"正是本模型该提示的工程问题, 不修正等于把它藏起来还反着说。 加 Davies 活度修正后落到 0.58–1.06, 与该指数同侧同量级。

⑥ 外部口径交叉验证: 内部自洽挡不住"一致地偏离物理"

本版新增两条拿库外通行量来对的断言 —— 缓冲因子换算成海洋化学的 Revelle 因子须落在典型区间 8–15(实测 13.9); 淡水 Ω 须与 Langelier 饱和指数同侧且在一个数量级内。 库内多数断言查的是内部自洽, 而内部自洽挡不住整套实现一致地偏离物理 —— 淡水 Ω 那一版方向反了的实现, 若只跑内部断言会全绿通过。

⑦ 两条流程门禁: 台账与 logo 也需要有人看着

交接台账的门禁基线本版过期六次(锚点计数、断言总数、字段计数), 每次都是加完东西忘了同步, 而没有任何门禁在看台账 —— 版本一致性检查查的是一致性不是新鲜度。 新增台账门禁后, 其中三次是被工具抓的。同期发现 logo 有四份拷贝(favicon 内联 + 三处可见 SVG), 而首版门禁只锁了其中一份 —— 若照那样收工, 换 logo 后页头两处仍是旧图而全绿。

本版遗留: 生物滤池模型重构已立范围书(硝化面速率动力学 + 溶解性 COD 按降解性拆分 + 字段改名 + 淡水蛋分默认值, 四件事必须同批, 共用同一套化学计量); 三个待标定系数中 bfAlpha 是唯一进成本链的, 最该先标定。详见交接文档。

🚀 v2.4 · 四个量的口径单一事实源（2026-08-18 · 五批）

起因是一份热平衡专项审计: 它指出气液接触器的质量流量取错了状态点(用了风机加热后的密度)。复核后发现根因更深 —— airFlowM3h 从来没有声明过参考状态, 三个产气者各按一套隐含口径, 相加后再乘一个密度, 本就无解。本版把四个这样的量全部建立单一事实源。

本轮最重要的一句话(引自审计原文): 守恒断言保证账本自洽, 但保证不了记进账本的那个数是对的。 无论取哪个密度、扣不扣哪股风, 守恒式两边都会同步变化、残差恒为零 —— 这类缺陷守恒断言天然抓不到。本版因此新增一整族「取值来源」型断言, 它们不问账本平不平, 只问这个数是从哪儿来的。自检 32 → 35, 门禁判据 136 → 167。

① 室外 CO₂ 本底 — 同一物理量的两份口径

热工侧写死 const co2Out_ppm = 450(无 UI、无默认表条目、无范围登记), 而 PROCESS_DEFAULTS.co2IntakeCO2_ppm = 350 是同一物理量的另一份 —— 值还不一样。后者更麻烦: 它有读取路径且带 300-5000 钳制, 但根本没有输入框, 那句钳制从未执行过。现统一为 co2Outdoor_ppm(默认 450, UI 可调 300-5000), 两个消费点一律经同一 resolver。⚠ 撤字段时把原注携带的 Fig 10.17 论证(本底 1000 ppm 去除率降 10%)迁存到脱气塔气路处 —— 那是「尾气必须排室外」的量化依据, 字段可撤, 依据不可撤。

② 工艺风量 — 声明为标准状态 Nm³/h

全库风量一律为 0 °C · 101.325 kPa 下的体积流量(1.293 kg/m³ × 0.232 = 0.300 kg O₂/Nm³, 国内曝气设计手册经典常数)。理由: 对外向风机厂家提规格时给的就是 Nm³/h + 压力, 质量由该单位本身锁定, 故风量/压力/功率全部同口径、不做进气温度修正。
接触器质量流因此成为常数, v2.2 那段六次不动点迭代整段删除 —— 它当年确实统一了两侧密度, 但统一到了"风机加热后的密度"这一侧, 而风机不改变质量流量。

⚠ 全库 1.2 共 9 处只改 3 处: Lewis 类比的车间空气密度、除湿/暖通选型裕度、通风显热的 0.34(=1.2×1006/3600)均不得改动。0.23 同理 —— 它与鱼种耗氧系数(鲑 0.20–0.23)数值相近而物理无关。禁止全局替换, 由断言 A4d 反向保护(不该改的必须仍在原位)。

③ 风机送进车间的那股空气 — 它就是新风

K-101 鱼池增氧鼓风机没有排气风管: 吸室外空气、气泡穿过池水、从池面进车间。⇒ 它就是新风, 而此前一分未计, 两笔账同时错 —— CO₂ 稀释侧让通风系统重复提供了这部分; 显热侧这股空气已被池水加热到水温饱和(水侧付过了), 通风显热又收了一遍。实测在恒温车间占通风需求 36.9%–44.5%。现按净额抵扣, 并把「机械换气」与「总换气」拆成两个报告口径。纯氧拓扑下抵扣量恒为 0 ⇒ 13 条数值基线逐位不变。

④ 自然通风 — 从"需要多少给多少"改为钳在设定 ACH 上

此前自然通风档同样走 max(ACH×V_room, CO₂需求), 于是用户填 ACH 1 / 2 / 5 结果完全相同(室温 8.4 °C · 车间 1500 ppm · 25.03 元/kg)——CO₂ 需求一直顶着, 用户的输入被架空; 而那 35,414 m³/h 没有风机、零电耗、零 CAPEX, 等于"选自然通风就能免掉通风机"。物理上站不住: 自然通风由风压/热压驱动, 不会因为室内 CO₂ 高就自己变大, 且随开口面积与天气跨近两个数量级(温室夏季敞开 45–60、冬季关口约 3)。

现钳在用户填的 ACH 上, 不足则让车间 CO₂ 真的算超标并给出缺口与两条出路(加大开口 / 改机械通风)。实测 ACH 1 → 4422 ppm、2 → 2894、5 → 1584、15 → 857、30 → 658 —— 用户填的 ACH 终于有意义了。

⑤ 三条车间通风告警 + 一条被否决的候选

ROOM_ACH_TOO_LOW(warn, 阈值 15 取自该档自己的定义注释「简易棚取 15–30」, 零新常数)· NAT_VENT_SHORTFALL(warn, 给出缺口与出路)· VENT_CTRL_BY_CO2(info, 沿用已有标志, 零新阈值)。
⚠ 原遗留清单里的候选项「车间 CO₂ 超限告警」判据恒假, 已改写: 通风量本就是"恰好把浓度压到限值"的反解, 故 CO₂ 一旦成为控制项, 车间浓度恒等于限值(实测四组工况精确 1500)。照原样写会得到一条永远为假的判据。真正要告警的不是浓度, 是为了不超标所要求的通风量。

⚠ VENT_CTRL_BY_CO2 的措辞里明确写着不要为了缩小通风机而开脱气塔 —— 实测在空气曝气下开塔使全场能耗上升 27–93%。脱气塔的作用是压低池水 CO₂(通常配液氧拓扑), 不是省车间通风。这一条拦住的正是"只看通风机风量降了 71%、没看总账"这个推理。

⑥ 门禁: 防线扩到全局配置层, 并补 U1 的反方向

默认值同步门禁的三条判据此前全部对准阶段工艺参数表, 于是全局热工配置层从来没有门禁。本版新增 G0–G4, 上线即咬出两条(均 WARN 级, 结构性隐患非数值错): co2IndoorLimit_ppm 的 UI min=800 与代码下钳 600 分居 HTML 属性与代码字面量; 全局默认里的围护五项逐值等于「一般工业车间」预设(改预设表不会自动改默认值)。
断言 U2 关掉了 U1 的结构性盲区: U1 是从"有框"一侧起判的三件套, 对「无框 + 有读取路径 + 有消费点」这一类结构上判不到。U2 要求凡出现在读取路径里的字段, 要么有框, 要么显式登记为 JSON-only 并写明理由。

⑦ 基线变动: 只有 ② 改数, 且符号随工况方向翻转

五批中只有标准态口径改基线, 52/52 项变动, costPerKg −0.10 ~ +0.36 元/kg: 制热工况下降(青岛冬 −0.102 · 鲈 −0.089 · Bergen −0.013), 制冷工况上升(海南夏 +0.358 · 三亚 +0.255 · 对虾 +0.175)。与 v2.1/v2.2 守恒修复时一致 —— 单向偏移才说明修错方向。
⚠ 不要引用"最大相对差 13.68%": 那一项绝对值仅 +0.024 元/kg, 是小分母造成的假象。引用变动幅度时必须看绝对值。

⑧ 一个被撤销的批次, 与六次同类错

计划中的第四批「air 模式默认关塔」核实后撤销 —— 该联动 v2.3.3 已在 UI 事件层实现(切到空气曝气时脱气塔自动关闭, 并尊重用户的显式选择), 且由断言 S3 锁住不得下沉计算层。立项时据一处默认值的字面量推断了系统行为, 没查 UI 事件层。该行代码已就地留痕防重开。

本轮在六个不同位置犯了同一形态的错: 为判据或探针挑对象时用了记忆里的名字而不是先查。其中两次是恒真型(断言宿主函数填错 ⇒ 写了、跑了、全绿, 但从未判过任何东西), 若不跑负对照就会随本版一起交付。⇒ 固化三条纪律: 静态断言必须核实宿主并在找不到目标时判红 · 探针读数"一半对一半空"时先怀疑量具 · 引用变动幅度必须看绝对值。

⚠ 另有一条判据本身写错的教训: 新门禁 G1 第一版写成"UI 范围必须等于消费点钳制", 于是把合规的 800/600 判成红 —— 而既有设计本就是「UI 引导范围」与「模型接受范围」分开存, 二者允许不等。差一点逼出一个错误的"修复"。判据错比代码错更贵: 它会让人去改对的东西。

⑨ 版本号命名空间: 两套编号并存

代码里的 IRAS_V24_* / IRAS_V25_* / IRAS_V26_* 是内部开发批次号, 与发布版本号不是同一序列 —— 那三批成果都随 v2.3.x 发布, 从未独立发版。故本次发布批的新哨兵一律 IRAS_R24_*。旧哨兵一律不改名(它们是史料; 本库有过全局替换污染历史叙述的先例)。详见源码顶部的编号说明块。

🚀 v2.3.3 版本口径批 · 下游页版本号跟随主页面（2026-08-14）

项目方决定: 下游页版本号不再各自演进, 一律跟随主页面。四页此前是 equipment v1.3 · pid v2.0(图签另写 v2.1)· report v1.7(templateVersion 又是 v1.5-alpha-1)· finance 根本没有版本号 —— 四页四个口径, 全部对齐 2.3.3。

① 判据要分层: 有两类版本号【不】跟随

一刀切"全文版本号都改成 2.3.3"会改坏两样东西: (1) 数据契约版本——pidSchema / pidSchemaMinSupported / SUPPORTED_SCHEMA_MAJOR 表达的是"能读哪些格式", 与产品版本无关, 跟着改会直接破坏向后兼容; (2) 史料标注——注释里的 // v1.7: 鱼池增氧鼓风机 K-101 是"这行代码是哪版加的", 改掉就抹掉了来历。⇒ 只有"页面版本"跟随, 契约与史料原样保留, 这三类在 docver 登记表里被显式区分。

② 每页立一个单一事实源

四页各加 const IRAS_PAGE_VERSION = '2.3.3', 标题字面量与它对齐, docver 同时登记两者 —— 二者不一致即转红。pid 图签的"版本"格优先取【所载入方案自身的 irasVersion】, 无数据时才回落到页面版本: 图纸上的版本应当是"这张图是哪版算出来的", 不是"看图的工具是哪版"。

③ 补上一件此前四页都没有的事

「方案的 irasVersion」与「页面版本」不一致时显式提示。二者是两回事: 前者是"这份数据是哪版算的", 后者是"你在用哪版工具"。旧方案在新页面上打开会走各处兼容回退 —— 结果看起来正常, 但口径是混的, 而此前没有任何信号。现 pid 走 toast, equipment 写进元信息行(方案 v? / 本页 v2.3.3)。

④ docver 登记表 10 → 19 项

负对照 4/4 精确转红。其中"主页面升版而下游七处不动"这个发版全场景, 纳管前只咬中 8 处, 现在咬中 17 处。⚠ 读取下游四页时缺文件即判工具异常退出, 不静默跳过——"文件不在就当它没问题"正是本轮反复咬出的那类假绿。

🚀 v2.3.3 下游审计批② · 设备清单少四台、总价却对得平（2026-08-14）

第二轮清掉 🔴「下游三页深审计」最后四条。三件实事 + 七次量具翻车——后者才是本批真正的收获。

① pid.html 内嵌示例冻结了四个版本

点"载入内嵌示例"得到的是 irasVersion 1.1.0 / pidSchema 1.0 / savedAt 2026-04-30 的一份数据, 带 v1.1 口径(G:L 3 / 塔风压 5 kPa / pumpHeatRatio 0.85 / denitriFlowPct 10), perStage 只有 8 个键(现 17)。而 SUPPORTED_SCHEMA_MAJOR 只比大版本、它确实还是 1 ⇒ 照常载入、不报一句警。根因不是"忘了更新", 是"有机制、无工具": 源码里本来就留了注入哨兵 %%---SAMPLE-PAYLOAD-INJECT-HERE-<hex>---%%, 说明设计上就该有注入工具, 但工具从没被写出来 ⇒ 注入成了一次性手工操作, 做完即失传。现补 inject_pid_sample.js(savedAt 归一化以保证可重复生成)+ 门禁 C6, 载入标签也改为从示例自身读版本号。⇒ 留了钩子不等于钩子会被拉。

② 设备清单少四台设备, 而总价对得平

equipment.html 的行是硬编码的, 冻结在写它那天的设备集合, 缺 K-501 蛋分供气风机 · DH-1001 除湿机 · AHU-1002 暖通机组 · KV-1003 车间通风机——全是 v2.x 后加的。⚠ 金额层面没有错: finance/report 用聚合值 capex.total, 这四台的钱一直在里面。错的是"清单少四台、总价却对得平"——对账对得平, 所以谁也发现不了; 只有拿这份清单去询价/招标时才会发现少买了设备。这类不一致比数值错更难查。修法不是手工补四行(那只解决今天): index 导出 capex.items(逐项 + ISA 位号), equipment.html 改为自 CAPEX 清单反向补全——以后 index 新增任何设备都会自己出现, "两份清单各自维护"从根上消掉。门禁 C7 锁死位号集合包含关系。

③ 让设备自己说清"为什么是这个规格"

过桥的 aeration / aerIntensity / indoorCO2 原本无人消费。现落在采购方真正需要它的地方: K-101 行写明选型控制侧(O₂ 传质 / CO₂ 吹脱, 两侧风量并列)、设计 DO 及其来源、实际 OTE 与清水基础、池底布气强度与超限告警(含该阶段可行密度上限); KV-1003 行写明控制项(CO₂ 稀释需求 / 换气次数, 两侧并列)、车间稳态与限值, 由 CO₂ 顶大时明写"改增氧方式或脱气塔配置后必须重选, 不可沿用"。采购方原来只看到"0.4 kW · 2863 m³/h", 看不出这台风机是被 CO₂ 顶大的。pid/finance 有意不消费(前者画水路, 后者用聚合值), "未消费"是决定, 不是遗漏。

④ 死负载: 371 → 365 → 22 → 10, 前两个数都是量具错

先拿运行时 CONSUMED 表反推得 371——但 Proxy 会把 JSON.stringify/深拷贝这类深度枚举也记成"读取", CONSUMED 与 ORPHAN 两个方向都虚高。改静态文本判据后得 365——而叶子路径被 depth-6 上限截成 label…, 文本判据全军覆没, 365 里有 308 条全是这一个 bug。depth 提到 9 后真实值 22, 其中 17 条正是刚过桥尚无人消费的字段; 消费落地后 10。现判据是保守的: 出现 ≠ 一定在用, 但不出现 = 一定没用。加 C8 棘轮(只许降不许升), 目的是逼迫"过桥"与"消费"同批完成。

⑤ 一条被推翻的旧结论

批① 曾据 CONSUMED 表宣布"ventFan 单价下游同步已验证通过, 该条销号"。错的——ventFan 在 finance.html 里一次都没出现。正确结论是分层的: 金额层面 ✓(用聚合值, 财务数字没错)· 清单层面 ✗(少四台设备)。⇒ 运行时"读过"不等于"在用"。

⑥ 纪律 17 在两轮内被验证 7 次

批② 又踩四次: (4) 门禁只写 localStorage 而 equipment.html 读 sessionStorage ⇒ 空页、C7 满屏假红; (5) equipment.html 读完即 removeItem(一次性消费), 而 jsdom 同源实例共享 storage ⇒ 门禁第二次打开就空手(修法: 每实例独立 origin, 假定被审页面有副作用); (6) 用 Python 写门禁时掉了一层转义, 模板字符串里 \\s 变成 s, 正则退化成 /^s*(...)s*$/——而这次是被我自己写的 catch(e){ return '[]' } 挡住的, 纪律 14 刚写完就又犯一次; (7) 死负载三次报错的数全是量具问题。⇒ 补充一条: "零脚本错误"不等于"渲染出了东西"——空页也零错, C5 已加最低渲染量判据并按各页形态分档(pid 画 SVG 无表格行)。

🚀 v2.3.3 下游审计批① · 告警链从 sim 打通到可研报告（2026-08-14）

二批把告警做成结构化 configWarns 时, 交接文档记的是「报告侧消费未做」。审计实测发现比这严重一档: 数据根本没过桥——configWarns / aeration / aerIntensity / 入室 CO₂ 四组量全都不在 payload 里, 下游想消费也没得消费。于是"报告照出成本、不带任何不可行标记"这句话是字面成立的。本批打通三段。自检 31/31, 13 条基线逐位不变。

① 先造审计器: Proxy 记录下游实际读了什么

index 与四个下游页之间此前没有任何契约: 下游多读一个字段拿到的是 undefined 而不是报错, 上游删一个字段也没人知道——这是本库复发六次的「转发断链」模式在页面之间的翻版, 只是跨了 localStorage。audit_downstream_contract.js 把 payload 包成递归记录 Proxy, 记下每页实际访问的每条路径。不用静态扫描: 下游大量 d[k] 动态取键, 静态扫必漏。

② 过桥: 纯搬运, 判据取逐位相等

产出面 831 → 874 条。结构与 sim 内部值逐字段一致, 不二次加工、不改判据、不新增阈值——呈现方式留给下游各页决定, 但数据必须先在。空值语义分两档: 无告警 → [](与 W0 同口径, 空场也要有骨架), o2 模式无曝气 → null(语义是"该拓扑下不存在这个量", 与"有但为零"不同)。断言 Y0–Y3 判逐位相等而非容差: 过桥是纯搬运, 任何差异都说明中间有人加工了, 而加工正是双源漂移的起点。

③ 呈现: 显式披露, 不硬阻断

report 新增 warnings 命名空间与 15.5 设计边界与模型告警节(有则逐条列: 阶段/级别/实测与判据/建议处置; 无则明写"未检出配置级告警"), 含 15.5.1 车间 CO₂ 与新风量的设计边界; 第 5 章开头就地标注"本章参数是在哪些告警存在的前提下算出的"; 第 16 章结论改条件式——原来无论如何都印「工艺技术上完全可行」, 现在检出 danger 级时降级并要求决策文件留痕。取向是显式披露而非硬阻断: 不拒绝生成报告("我知道超标就是要出个初稿"是正常用法, 挡住只会让人绕过工具), 但白纸黑字。

④ 顺带修掉一处读错层级

report.html:3078 写的是 sproc.peakFactor || 1.5, 而 peakFactor 是阶段级字段、不在 proc 下 ⇒ 该行永远回落到字面量 1.5: 用户把峰值系数改成 2.0, 报告照印 1.5。与 recDepth_m 那六次同一形态: 读错层级 + 字面量兜底 = 静默错值, 没有任何信号。

⑤ 本批最值得记的: 审计器自己被跑瘸了三次

(1) jsdom 不加载外部脚本, finance-core.js 与 nunjucks 都没进去 ⇒ finance/report 被跑成"只访问 9/14 条路径"的假空场, 差点得出「下游几乎不消费」的错误结论; 注入本地依赖后是 933/937 条。(2) Y 断言首版写在逐工况循环外, 只看最后一个工况留下的 lastResults, 而它恰好没告警 ⇒ 负对照「把 configWarns 截断成 []」全绿——这是 M13/M14 陷阱的第三次复发, 且是本批自己踩的; 移进循环后七个工况转红。(3) 门禁用裸 nunjucks.renderString 渲染, 而 report 自己注册了 wan 等过滤器 ⇒ 第 16 章报 filter not found, 判据报出假红; 必须走页面自己的 renderChapter。⇒ 纪律 17: 审计器把被审对象跑瘸了, 得到的"干净"是假的; 把自己跑瘸了, 得到的"红"也是假的。出现"全绿"或"全红"这类整齐结果时, 先怀疑审计器, 再怀疑代码。

⑥ 一个要撤回的误报

stages[].subSystemCount 一开始报了 56 次 orphan(report 占 52), 看着最严重。实测设成 3 就正常导出 3——它只是默认未设定的可选字段, 下游 || 1 兜得住。不是缺陷, 是审计器的判据不能区分"该有而没有"与"本来就可以没有"。已在交接文档标注: 读该工具的 ORPHAN 表须逐条复核, 不可直接当缺陷清单。

🚀 v2.3.3 收尾批 · 默认值口径清账 + 入室 CO₂ 守恒修复（2026-08-14）

清两条遗留。一条是文档写的默认值和代码跑的不是一个数, 一条是一股气流在模型里凭空消失。前者纯文档, 后者动计算——13 条基线仍逐位不变(全 o2 拓扑, 走退化档), 自检 29 → 31。

① 脱气塔默认值: 三处文档停在 v2.0 之前

v2.0 对标 Timmons Ch.10 把 co2StripperGtoL 3→5、co2StripperLoadingRate 40→80、co2PackingHeight_m 1.0→1.5, 但参数速查表、阶段卡片 title、手册 15.4.1 三处都没跟。这不是排版问题而是数值口径错: 用户照文档填 3, 模型按 5 跑, 风机功率差 1.67 倍(手册例题 35 kW 实际是 58.8 kW)。另有两个 死 fallback(: 3 / : 1.0)——与第七轮审计咬中的 : 0.2 同型, 已改读 PROCESS_DEFAULTS。

② 新门禁 check_defaults_sync, 上线即多咬一条

判据对准 PROCESS_DEFAULTS 这张表(纪律 10c), 三条: D1 阶段卡片不得用字面量 fallback · D2 title 里的「默认: X」⇔ 实际 · D3 参数速查表「默认」列 ⇔ 实际。上线当天咬出清单上没有的第四处: denitriFlowPct 文档写默认 10、范围 5-20, 实际默认 2。负对照 4/4 精确转红(含"改默认值而文档不动"的真实发生场景)。⚠ D1 另报告 33 处同值副本(今天不错、改默认值时必漏), 有意不判红——一次性改造属独立重构批次, 混进来会淹没"数值口径错"这件事; 该计数应逐批下降。

③ air + 开塔: 一股气流在模型里凭空消失

开塔时入室 CO₂ 比例取脱气塔的 degasFrac(默认 0), 但曝气气流依然 sink=indoor 且接触水体。更彻底的一层是: 曝气吹脱在水侧的 η 里也没算——水侧不记移除、室侧不记入室, 两头都不记 = 孤儿项, 与 v2.0 的 Q_air_gain、v2.1 的蛋分气流、v2.2 的 K-101 轴功完全同族, 是第五次。最能说明问题的一个对照: 修复前 air+开塔 与 o2+开塔 算出的池内 CO₂ 完全相同(罗非苗种期均 10.55 mg/L)——尽管前者正有 476 m³/h 空气打进池子。

④ 修法: 不是补第三档特判, 是取消特判

原写法是三分特判(o2→degasFrac / air+关塔→1 / air+开塔→degasFrac), 第三档错了, 而且错得"看起来已经考虑过了"——原注释还自称保守方向。现由质量守恒导出 入室份额 = fracAer×sAer + (1−fracAer)×degasFrac, 三档全部成为特例, 不再需要 if: o2 档 fracAer=0 退化为 degasFrac, air+关塔 档 fracAer=1 退化为 1, 两档逐位不变, 只有 air+开塔 得到修正。fracAer 取自水侧 sim.co2Removal 单源, 零新常数。方向标反的代价: 修复前该工况 CO₂ 新风需求恒为 0, 罗非 1000t 成鱼期新风 6,499 → 11,460 m³/h, 通风机原来选小 1.76 倍; 综合成本只涨 0.09 元/kg——靠成本异常根本发现不了, 只能靠守恒。

⑤ 断言 X0–X3 与一个被负对照咬出的断言漏洞

该链此前零导出量、零断言, 所以缺陷是手算发现的。现补 X0 导出面必须存在 · X1 入室份额 ⇔ 水侧移除分解(单源) · X2 车间稳态 ≤ 设计限值(守恒闭环) · X3 静态锁特判不得复活; 并补锚定工况 edge_air_stripper_on(air+开塔+机械通风车间)——全库既有 air 工况原本全部关塔, 不补工况 X 锚写了也走不到(M13/M14 同款教训)。⚠ X0 自身曾有漏洞: 它最初写成 X1 的守卫 if (sim.co2Removal) {…}, 于是"撤掉导出"这一负对照全绿——导出没了, 整块断言被跳过。改为独立判定后当场转红, 并顺带咬出空场骨架漏导出(与二批 W0 同一课)。⇒ 纪律 14: 守卫会吞掉失败——导出面本身必须是受检对象, 不能是判定的前提。负对照 6/6。

🚀 v2.3.3 文档批 · 手册第 15 章与参数速查表追平代码（2026-08-14）

前五批把空气曝气路线的代码补完了, 文档没跟上——手册第 15 章还停在 v1.7 口径, 于是界面写 30、手册写 40, 用户按哪个都不对。本批只改文档与文档级注释, 不动任何计算: 自检 29/29, 13 条基线逐位不变(改前/改后/交付副本三次比对)。

① 手册 15.2: 密度分界 40 → 30, 并把口径分层写进正文

三批已在代码与 UI 改到 30, 手册对比表仍写 40——同一事实两处不同源, 而用户看到的多半是手册。现补齐并把三层口径一并写明: 30(SRAC-453 / GSA 物理上限)进 UI 与参数表 · 20–25(DB46/T 424—2017 + 设备商参数 + 模型反算三源收敛)进选择器提示 · 任一阶段准确上限以 aerIntensity 反算为准。连同"抄外部数字时丢了口径"这条根因一并留档, 免得下一个人再把硬上限当分界线抄一遍。

② 「微孔盘 SOTE 18%」清水常数退役

SOTE 是清水标准态(20 °C、零盐度、洁净水、初始 DO=0)测出来的值, 养殖池四个条件一个都不满足。手册把它当"吸收效率"列在对比表里, 正是二批修掉的那个硬编码 0.18 的文档孪生体。现换成完整 OTE 公式并逐因子标注, 附实算链: 清水标称 9.75% → 加 αβ 7.31% → 加 θ 8.63%(OTE_base) → 加推动力 2.22%, 差 4.4 倍。同时点明 OTE 与 OTE_base 是两个量: 选型反推风量用前者, 水质侧解池内 DO 稳态用后者(后者要把对浓度 C 的依赖显式解出来)。

③ 15.3 标注适用范围 + 新增 15.3b / 15.3c 两节

15.3 的 DO 公式只适用纯氧拓扑(前提是"存在进池浓度"), 此前无任何标注, 而 v2.3 那次"选型侧说 5.00、水质侧说 0.00"的事故根因正是它被误用到 air 模式。新增 15.3b 空气曝气风量选型与设计工况点(池内稳态方程 / O₂ 与 CO₂ 两侧取大 / 设计工况点 / 完整例题 / 守卫与局限)与 15.3c 空气曝气要不要上脱气塔(硬规则与设计选择之分 / 结果级判据 / 实算对照 / 已知缺陷)。正文每个数字都是本版模型实算, 为此建了取数探针 probe_manual_ch15.js 与 probe_manual_ch15b.js 随交付。

④ 两条写进手册的实算结论

安全系数的去向可解析: 实算DO = C* − (C*−设计DO)/safetyAerator, 实算CO₂ = 设计CO₂/safetyAerator(CO₂ 控制时)——裕量看得见, 不是黑箱。塔的价值随密度反向变化: 关塔时池内 CO₂ 与密度无关(石斑成鱼期恒 11.86, 因 CO₂ 产量与曝气风量都正比于生物量), 开塔时正比于密度(2.14 → 6.43, 因塔的去除能力正比于循环流量而流量随水体缩小)。两条曲线走向相反 ⇒ 低密度段塔的优势最大, 而空气曝气恰只用在低密度段——这正是"要不要上塔"值得算一算的原因。

⑤ 参数速查表 D 组补登五个曝气参数

designDO_mgL · co2TargetMgL(哨兵字段, 标明留空回落语义与生效条件)· sotePerMeter · aerationAlphaBeta · co2StripApproach。后三者标明无 UI 入口、仅 JSON 可调但钳制全路径生效; co2StripApproach 另标无成文出处、属待校准项——参数表是用户查"这个数能不能信"的地方, 出处不明必须写在表里而不是只写在注释里。

⑥ 一条失效的"已被断言覆盖"承诺

手册封面口径散布四处(副标题 / 页脚 / 版本演进章标题 / 首段), v2.2 曾在原地留注称「已加入 t21 三文档判据, 下次漏改会转红」。本批实测: 四处全部停在 v2.3, 而自检 29/29 全绿——查明当前 29 项里只有 meta_version_consistency 管版本, 且只查 index 页内 meta。页面内自检读不到 manual.html 与 README.md, 这个判据在浏览器里原理上就做不成, 三次扩展落空的根因在此。现改由工具侧门禁 tools/check_doc_version.js 承担(node 能读三个文件), 并就地订正那条失效的注。⇒ 纪律: 注释里写"已被断言覆盖"不等于真被覆盖; 声称有防线时, 必须给出该防线失败时的可见信号。

🚀 v2.3.3 · 字段流转工厂化（2026-08-13）

「权威源 → 转发 → 多消费点, 某个消费点没接上; 各自内部自洽, 所以断言全绿」—— 这一 bug 模式在本库已复发五次(DOmin_* / recDepth_m / isCrustacean / 通风机风量口径 / 曝气侧池深不同源)。每次补断言都只封住当次的字段, 模式本身换个字段就复发。本版治本: 把「鱼种/阶段 → 水质侧 sp」这条链工厂化, 让"漏进白名单"成为写不出来的代码。纯结构重构, 13 条基线对【v2.3 新基线值】逐位不变, 自检 26 → 27 条。

① 声明表 + 工厂: 白名单不再手写

新增 SPECIES_FIELD_FLOW 声明表(每字段声明 scope 权威源层级 / toSp 是否转发 / resolve 解析函数), recomputeAll 的 sp 改由 buildWaterSp(stage) 工厂按表生成, 五次复发的案发现场——那个手写白名单——退役。池深解析(兜底链 + 0.3 m 下钳)收敛为 resolvePoolDepth 唯一副本(曾有三副本且兜底不一致 3 vs 1.5 的前科)。历史教训注释(v1.1.2 DOmin、recDepth_m 1.68×、池深修一半)全部随迁到表处存档。

② 断言 M15a–d: 静态源码扫描, 免疫"工况走不到"

M13/M14 两次踩过同一个坑: 断言写好后负对照仍全绿, 因为没有工况能走到那条路径。本版的 M15 从机制上免疫它——对水质链四个消费函数(simulateWaterQualityProcess / isWarmWaterStage / co2ThresholdFor / tankAerationDesign)做 .toString() 静态源码扫描, 不依赖任何工况, 每次自检对全部代码路径无条件全覆盖。四条子断言: M15a 消费面每个 sp.X 读取必须在表中声明且转发(抓"消费了但没转发", 五次复发的标准形态); M15b 每个转发字段必须有消费点(抓死转发); M15c recomputeAll 的 sp 必须来自工厂、手写字面量不得复活; M15d 设备侧 tankAerationDesign 调用必须经同一工厂。

③ 断言落地当天咬出第六例: thermalClass

M15a 上线即红: isWarmWaterStage 的消费代码支持鱼种显式声明温冷水类别 thermalClass, 但该字段从未进过白名单——与 recDepth_m 完全同型的第六例, 只因尚无鱼种声明它、还没被踩响: 哪天有人给某鱼种加上 thermalClass: 'cool', 水质侧会静默无视、继续按 tempOpt 推断。已补声明转发(阶段显式 > 鱼种级), 声明能力自此真正生效; 现状无鱼种声明 ⇒ 数值逐位不变。同批 M15b 咬出 protein 死转发(消费面零读取, 真实消费者走 stage 直连), 已撤转发并以 toSp:false 存档。

④ 设备侧接入同一工厂: M11 从"事后比对"升级为"结构单源"

此前设备侧传完整 stage、水质侧传白名单 sp, 两侧传参形状不同, M11 只能事后比对两侧风量是否相等。现设备侧改为 tankAerationDesign(buildWaterSp(stage), …)——两侧吃同一工厂产物, "两侧不同源"在结构上写不出来; 两侧解析规则的微分歧(设备侧原缺 0.3 m 下钳与 proc 兜底)一并消失。M11/M14 保留为纵深防御。

⑤ 验证: 红→绿仪式 + 四条负对照 + 级联实证

按纪律先红后绿: 批①忠实等价替换(基线逐位不变) → 批② M15 入列预期转红(红项恰为 thermalClass + protein, 预飞探针 tools/probe_fieldflow.js 事先命中) → 批③处置转绿 27/27。四条人工负对照全部精确转红: 表删 DOmin_abs → M15a · 塞假字段 → M15b · 手写白名单复活 → M15c 两条且级联咬中 M11/M14 数值断言(结构层与数值层双重防御实证) · 设备侧退回 raw stage → M15d。

⑥ 二批(同日): aerationMode 硬告警 —— configWarns 结构化导出

遗留清单第 5 位落地。侦察修正了问题定义: 渲染层其实已有曝气强度告警与 CO₂ 超标告警, 真实缺口是三样——告警困在渲染层(A.6 家族: 无导出面、无断言、渲染改坏无人知, 报告照出成本不带"该方案不可行"标记); o2 关塔这一物理上必然积累 CO₂ 的配置与"塔效率不足"共用一句轻描淡写的文案; 参数表 aerationMode 处无联动。现 sim 新增结构化导出 configWarns: AIR_INTENSITY_OVER(复用 aerIntensity 全部字段)与 CO2_OVER(结果级判据 CO₂稳态>阈值 + rootCause 三分 stripperOff/airUnderperf/stripperUnderperf——不选"o2 关塔一律响"的配置级判据, 因为高换水/低密度下确实可达标, 天天误报就没人看告警了)。判据只复用已算出的量, 零新阈值。渲染两块改为消费该数组单源, o2 关塔文案升格为「物理上必然积累, o2 模式必须启用脱气塔」; 参数表联动落地(选择器随每次计算着色 + title 给可行密度上限, 只提示不自动切换——不替用户改配置)。这也是 A.6 十一类告警未来迁移的目标形态。

⑦ 二批断言 W0–W3 与验证

预飞探针 tools/probe_warnmatrix.js 先出触发矩阵定锚: W1 锚 edge_air_aeration(池底布气 4.84–7.24 vs 限 1.7)、W2 锚 edge_no_degasser(CO₂ 124–148 vs 阈 15/20), 13 条基线两标志全假, edge_shrimp_air 提供"合规不响"侧(甲壳类档 0.79–1.77 vs 4.0)。断言四条: W0 导出必须存在(红仪式之红: 断言先行上线即 FAIL 3/27, W0 遍布全库)· W1/W2 标志与底层状态双向一致(该响必响 + 不该响必不响, 防告警恒真化)+ 两处锚定(锚定与 ⇔ 不同源: ⇔ 查一致性, 锚定查物理预期)· W3 静态 toString 锁渲染层必须消费 configWarns 与两个 code 字面量——防"数据层↔渲染层双源各自自洽"这一复发六次模式的翻版(自检 27 → 28 条)。负对照 3/3 精确转红: 撤数据层标志 → W1⇔+锚咬(FAIL 24/28)· 渲染退回旧读法 → W3 咬· 判据改错阈值×10 → W2⇔+锚咬。13 条基线全程逐位不变。

📌 局限如实记录: M15 只覆盖「鱼种/阶段 → sp」这条链(五次复发的案发地)。派生中间量的流转(V_vent_eff 一类, 第四次复发所在)不在本表射程, 仍由 M12a 数值断言压着——那是另一个量级的依赖图, 有意不在本版摊开。消费点内残余的 || sp.recDepth_m || 1.5 兜底对工厂产物是死代码, 仅为诊断脚本手造 sp 保留防御。

🚀 v2.3.3 四/五批 · 空气曝气设计工况点 + 加载路径哨兵盲区（2026-08-13）

由产业侧一句追问("关塔时是不是该让用户输 CO₂ 浓度")牵出的一串: 先是发现参数早已存在却无入口, 再顺藤查出加载路径防线的判据错位, 最后补成对称的一对设计输入。自检 29 项, 13 条基线全程逐位不变。

① 加载路径防线的判据错位(P1 同族残留)

ensureStageProc 的钳制以「默认值是不是数字」为判据, 而哨兵字段(默认 null = 未设定)的 typeof 是 object, 整类字段漏在防线之外——表里登记了 clamp 也不生效。实测注入 co2TargetMgL=0.0001 原样通过, 关塔风量 4,239 → 1,271,584,656 m³/h(放大 30 万倍), 与第七轮审计 P1 的 co2StripperGtoL=1e6 同族同路径。修法是把判据改为「FIELD_SPEC 表里有没有条目」, 与默认值类型无关; 空值仍保持 null——"未设定"不能被钳成"设定为下限", 那是另一种静默错配。断言 S1/S2 直接构造注入复验, 不依赖工况。

② 两侧都在拿"安全红线"当设计目标

查证发现这是同一个毛病的两面: CO₂ 侧拿鱼种阈值(安全上限)当选型目标, DO 侧拿 DOmin(安全下限)当设计 DO。两边都贴着红线设计, 没有裕量应对投饵高峰/水温波动/设备衰减。故补成对称的一对: 设计 DO 与 设计 CO₂, 留空则回落鱼种值(现状, 基线因此逐位不变)。二者共同决定风量并可看到控制侧翻转——实测罗非成鱼期留空时 CO₂ 侧 4239 险胜 O₂ 侧 4228, 设计 DO 提到 6.0 立刻翻成 O₂ 控制(7243); 设计 DO 7.0 时风量 15993, 是留空的近四倍。这个决策以前藏在鱼种库的"最低允许值"里替用户做了。

③ 池内曝气拓扑: 两参数与循环流量无关

产业侧指出这与液氧拓扑的关键差别, 已实测确认: turnover 1→4(流量 4×)时 air 模式池内 DO 恒为 4.9813 纹丝不动, 而 o2 模式同一扫描 DO 由 0 → 8.39。两个设计参数的算式中都不含流量(O₂ 侧 ∝ 1/驱动力, CO₂ 侧 ∝ 1/(亨利载量×目标))。⚠ 如实记录一处间接耦合: air+关塔时 CO₂ 稳态会随流量小幅变化(23.7→27.3), 但那是经由风量的二阶效应(流量低→池内 TSS 高→耗氧高→O₂ 侧风量大→顺带多吹脱), 非直接依赖。

④ air ⇒ 脱气塔默认关(只改默认, 不禁改回)

产业实际: 空气曝气用于低密度(苗种/小鱼期最常见), 该场景基本不另配脱气塔——曝气本来就在跑, CO₂ 顺带被吹脱, 一台设备干两件事。模型实测支持: 罗非1000t air 开塔 31.25 元/kg·14.23 kWh/kg, 关塔 26.20·8.35(省 16%, 比电耗近腰斩), 最高 CO₂ 27.3 < 阈值 30 守得住。⚠ 代价不是消失而是转移: 关塔后曝气吹脱的 CO₂ 全部入室, 车间通风 ACH 1.0 → 6.05——敞开式车间无妨, 恒温恒湿要掂量。故联动只做在 UI 切换事件层、不下沉计算层(计算层猜意图会静默改掉用户显式配置, 且会动基线), 且用户亲手动过塔开关后不再被覆盖。断言 S3 静态扫描计算层源码防止后人挪下去。

⑤ 一次"UI 加了但白加"的教训

批B 给 co2TargetMgL 加输入框后随即发现 readStageProcFromInputs 根本没读这个字段——UI 加了也不生效。同型风险已写进断言 S4: 不仅查"留空必须回落鱼种值", 也查"填了必须真的生效"。另修一处误导: 新增字段最初无条件常显, 而它们在纯氧模式下填了完全不起作用(o2 模式根本不调 tankAerationDesign), 已补反向灰显标记 data-aeration-air, CO₂ 目标另加"仅关塔"二级条件。

🚀 v2.3.3 三批 · 空气曝气密度分界 40 → 30（2026-08-13）

产业侧质疑"UI 里 40 kg/m³ 太高"。查证结果不止确认了这个判断, 还更正了我们自己的一处引用错误: 代码注释记的是「GSA >40 kg/m³ 必须纯氧」, 而原文给的是区间 + 硬上限两句话——仅靠曝气的密度典型限于 30–40, 超过 40 则确定不足。旧注释把硬上限抄成了分界线, UI 又据此写成"<40 都可用空气", 等于把区间上沿当成了推荐值。纯文案与注释改动, 13 条基线逐位不变, 自检 28/28。

① 30 的出处: SRAC-453

美南水产中心《RAS 设计实践综述》给出最明确的一条: 密度 <30 kg/m³ 时气提(airlift)可提供全部需氧, 而满密度 60 kg/m³ 时仅能满足约一半。这是"空气路线物理上限"的独立出处, 非经验感觉。⚠ 其装置为开放池气提(效率约 0.80), 与本模型池内微孔盘不完全同源, 已在注释标明。另有 TheFishSite 的「>50 kg/m³ 才常规上纯氧」明显更宽松, 但它答的是经济性问题(何时不得不上纯氧), SRAC 答的是工程能力问题(空气供不供得上)——两问不同, 故不并列取值。

② 口径分层: 固定数字给量级, 活数据给准数

三个数各有各的位置, 不混用: 30(物理上限, SRAC/GSA)进 UI 选项与参数表; 20–25(DB46/T 424—2017 + 设备商大菱鲆系统参数 + 本模型按池底布气 1.7 反算, 三源收敛的国内浅池实配)进选择器 title 与代码注释; 而任一阶段的准确上限始终以 aerIntensity 反算为准——它随水深/温度/鱼种变(石斑成鱼期 23.0, 甲壳类另档), 二批已把它接进选择器提示。三批后 title 在合规工况下也显示口径谱系, 不再只在超限时出现。

③ 教训: 引用外部数字必须连口径一起记

这次的根因不是数字取错, 而是抄数字时丢了它的口径(范围 / 硬上限 / 推荐值)。一个失去口径的数在传递中会自动变成另一种含义: GSA 的"超过 40 肯定不行"传成了"低于 40 都行"。已写入注释作为纪律: 凡引用外部数字, 须连同原文口径一并记录。这与"不拿来源不同的数字当阈值"是同一条纪律的两面——前者管来源, 后者管语义。

🚀 v2.3.3 二批 · aerationMode 硬告警（2026-08-13）

处置遗留清单第 5 位: 两条物理不可行/不合理配置(air 超密度、o2 关塔)此前"静默算出成本"。侦察发现真实缺口比清单文字更窄——渲染层其实已有曝气强度与 CO₂ 超标告警, 真正的问题是它们困在渲染层(A.6 家族: 无导出面、无断言、渲染改坏无人知, 报告照出成本不带任何标记), 且 o2 关塔与"塔效率不足"共用一句轻描淡写的文案。本批把两条判定提升为 sim 级结构化导出 configWarns + 断言 W0–W3 锁定。纯新增字段, 13 条基线逐位不变, 自检 27 → 28 条。

① configWarns: 结构化导出, A.6 迁移的目标形态

AIR_INTENSITY_OVER(复用 aerIntensity 全部字段与可行密度反算)与 CO2_OVER(结果级判据 CO₂稳态>阈值, 附 rootCause 三分: stripperOff / airUnderperf / stripperUnderperf)。选结果级而非"o2 关塔一律响"的配置级: 高换水/低密度下 o2 关塔确实可达标, 配置级会天天误报——"天天见红字就没人看告警"。判据只复用水质链已算出的量, 零新阈值(纪律: 不拿来源不同的数字当阈值)。渲染层改为消费本数组(单源), CO₂ 文案按根因三分——o2 关塔从"建议启用"升格为"物理上必然积累, o2 模式必须启用脱气塔"。这也是 A.6 十一类告警未来迁移的目标形态: 新告警按此建, 旧的逐步搬。

② 断言 W0–W3 与工况锚定

W0 导出必须存在(红仪式的红即由此: 断言先行上线, FAIL 3/27 全库咬中)· W1/W2 标志与底层状态双向 ⇔(该响必响、不该响必不响, 防告警恒真化)· 锚定: edge_air_aeration 必须有 W1 标志(预飞实测池底布气 4.84–7.24 vs 限 1.7)、edge_no_degasser 必须有 W2 标志(CO₂ 124–148 vs 阈 15/20)——锚定与 ⇔ 不同源: ⇔ 查一致性, 锚定查物理预期, 且是对"存在能走到断言的工况"的显式保证(M13/M14 教训, 本批以预飞探针 tools/probe_warnmatrix.js 事先确定触发矩阵)。W3 静态锁渲染挂钩(.toString() 扫描, 与 M15 同机制): 渲染层若退回"直接判 aerIntensity / tank.CO2"的旧读法, 就是复发六次那个模式在数据层↔渲染层之间的翻版, W3 当场咬。

③ 参数表联动: 只提示, 不自动切换

aerationMode 选择器随每次计算结果着色, title 给出本阶段池底布气实测值与 air 模式可行密度上限(活数据, 经 renderStageWarnings 每次 recompute 刷新, 无陈旧问题)。有意不做自动切换: 不替用户改配置, 增氧方式是工程决策——模型的职责是把不可行性摆到明处, 不是代替拍板。

④ 验证与顺带发现

负对照 3/3 精确转红: 撤数据层标志 → W1⇔+锚咬(FAIL 24/28)· 渲染退回旧读法 → W3 咬 · 判据改错(阈值×10)→ W2⇔+锚咬。顺带发现: edge_yield_tiny 的鱼池 CO₂ 实际在 21.5–23.7 mg/L、略超阈值 20——该工况的 CO2_OVER 标志为真且 W2 一致性通过, 行为正确; 此前无人知道这个边界工况处于超标状态, 结构化导出的第一天就多看见了一件事。⚠ v2.5 补注: 链式重导 (审计 B8) 后该工况鱼池 CO₂ 已降到阈值内, 当前只有 edge_no_degasser 触发 CO2_OVER。本段保留为当时的记录, 结论不再描述现状。

🚀 车间模式三档 + 车间通风机（2026-08-13）

车间模式重新划分为三档, 分档判据只有一条: 能否自动调节温湿度 —— 不是"简易还是正式", 也不是"自然还是机械"。conditioned 恒温恒湿车间 / natural 自然通风车间 / mechanical 机械通风车间。同时补上一台此前两档共同缺失的设备: 车间通风机 KV-1003。13 条数值基线因此全部重算(方向与量级逐条对预测表)。

① 恒温恒湿车间本身就是机械通风的

这是本版的关键判断, 来自产业侧一句反问: "恒温恒湿车间也有机械通风"。确实如此 —— 恒温档的 ACH 新风量一直在参与计算(UA_vent_sens 进暖通负荷), 但从来没人给它配风机。全场四台风机(脱气塔/BF/蛋分/池内增氧)里没有一台是车间通风机。所以通风方式不是 ventilated 的子类型, 而是横跨两档的独立事实; 撤销三档并列后, "恒温恒湿 + 自然通风"这个物理上不成立的组合也被天然排除(一边花钱控温, 一边让室外热风穿堂)。

② 通风机 KV-1003: 风量口径是关键

功率 = 风量(m³/s) × 全压 ÷ 效率, 与既有四台风机同一套公式。两个易错点都封在断言里: 其一, 风量必须取 V_vent_eff_m3h(= max(ACH×V_room, CO₂ 稀释需求))而非 ACH×V_room —— air+关塔 时 CO₂ 才是控制项, 挂错口径实测低估 58–66%, 且只在 CO₂ 控制的工况暴露, 只测 o2 模式永远不显形。其二, 全压走独立键 250 Pa, 绝不复用池内曝气盘的 70 kPa —— 后者要克服水柱静压, 差两个数量级(173,123 m³/h 下: 250 Pa 给 21.9 kW, 70 kPa 给 6,121 kW), 与 K0_W74 传摄氏度那次事故同族。热去向为新增的 exhaust 类别: 直驱轴流排风机电机在排风气流中, 空气离开车间后才经过电机, 废热随排风带走。⚠ 已知边界: 恒温恒湿若用送风式 AHU, 送风机废热确实进车间并需再制冷, 本版按单风机排风统一处理, 该情形偏低。

③ 13 条基线重算: 预测先行, 逐条吻合

补一台真实存在的设备必然改变基线, 故按纪律先出预测表再改代码: 预测全部 13 条上升、幅度 +0.01~+0.08 元/kg(≤0.1%)、最大为 turbot_500(水体大、通风量 5 万 m³/h)。实测方向 13/13 为正、量级 13/13 吻合, 最大偏差 0.006 元/kg(bass_300 预测 +0.02 实测 +0.026, 差在预测未计 CAPEX 折旧那一份)。幅度之所以远小于口头估算的 +0.8 元/kg, 是因为基线默认 ACH 为 1 而非简易棚的 15; 同一台风机放到海南简易棚工况(ACH 15)是 21.9 kW(密度 20)/ 10.9 kW(密度 40) —— 密度高反而小, 因为车间体积减半。

④ 空气曝气 × 车间模式的三条耦合告警

实测(石斑/三亚/200t/密度20/年均, 恒温恒湿档) air+关塔 相对 o2: 新风 7,116 → 9,835 m³/h(+38%, CO₂ 成为控制项)、除湿量 1,378.6 → 1,776.9 kg/d(+29%)、除湿电 551 → 711 kWh/d; 尾气显热恰为零(A3 下 T_room=T_w, 数学上严格为零, 到通风档立刻复活)。据此三条告警: 恒温恒湿+空气曝气(新风与除湿双重加价)· 新风被 CO₂ 顶高(同一股 CO₂ 在通风车间只需付风机的钱)· air 模式开塔冗余(曝气本身即脱气, 唯一合理用途是当风量被 CO₂ 侧控制时降低曝气强度 —— 实测 d40 成鱼期开塔可把池底布气从 3.43 降到 2.96 而合规)。每条都写明什么时候可以忽略它: 育苗/亲鱼车间本就是恒温恒湿+空气曝气的常态配置(低密度、精确控温、鱼苗对纯氧过饱和敏感), 否则天天见红字就没人看告警了。

⑨ 全批次审计: 三项发现（2026-08-13）

对本批全部改动做了一次系统审计, 查出三项, 其中一项是真 bug。

① 池深不同源(真 bug, 且是我上一批"只修了一半"留下的)。poolDepth_m 是阶段卡片上用户可编辑的字段(0.5–8 m), 注释明写它是「统一池深数据源」。但曝气侧三处全都绕过它、直接读鱼种推荐值 recDepth_m: tankAerationDesign 的 OTE、aerIntensity 的池底面积、浅池 CO₂ 告警; 而且兜底值也不一致(统一源 1.5 / 曝气侧 3)。实测: 用户把池深由 1.5 改到 5 m, 热工侧池面积 1348 → 404 m² 响应了, 曝气侧仍按 1348 算, 池底布气强度纹丝不动。上一批修 recDepth_m 白名单时只让它读到了推荐值, 没接到权威源 —— 修一半比不修更隐蔽。现三处统一改读 poolDepth_m || recDepth_m || proc.poolDepth || 1.5, 与热工侧同口径。13 条基线逐位不变(基线均未设 poolDepth_m, 走同一分支)。

新增断言 M14(池深单源): 曝气侧池面积必须等于热工侧池面积。⚠ M10a 抓不到它 —— M10a 校验「体积×水深=池底」, 两边用同一个 _depth, 自洽但不同源。这是本会话第五次同模式(DOmin_* / recDepth_m / isCrustacean / 风量口径 / 本项)。凡"权威源 → 转发 → 多消费点"的链, 断言必须跨消费点比对, 不能只查单侧自洽。

⚠ M14 写好后负对照仍全绿 —— 基线工况都没设 poolDepth_m, 两个源恰好相等, 没有工况能触发它。这正是 M13 那次教训的第二次复发, 根因是自检工况只能施加 proc 与 climate、无法施加阶段级字段。故补齐 c.stage 施加机制并新增工况 edge_pool_depth_override(自检 25 → 26 条), 负对照方精确转红(44.737 ≠ 13.421, 偏差 233%)。断言的表达能力受限于工况的表达能力 —— 这次是从工况层解决, 不是再写一条注释。

② heatVia 取值文档缺 'exhaust'(文档缺口)。登记表新增了该热去向类别但注释里的取值清单没同步, E1 断言只查是否声明、不查枚举, 故功能无碍但会误导后人。已补。③ 发布章小节编号乱序: 每次追加都插在前一节之前, 导致显示为 ①②③④⑧⑦⑥⑤。已重排。

审计中复核无误的部分: 通风机 CAPEX 实际入清单(14.3 kW → 28,595 元 @2000 元/kW, 苗种期 0.13 kW 低于 0.3 门槛未单列, 与 capexMinKw 一致); 风机风量在 CO₂ 控制工况下亦与热工侧同源(此前担心 pass-1 粗算 thermal 与最终值分叉, 实测多趟迭代已收敛); 档位白名单回落正常(open/非法值均落 conditioned, 与 conditioned 输出逐位一致); 自然通风档无风机、零产量边界不崩。

⑤ 找到成文标准: DB46/T 424—2017 与石斑成鱼期池深修正（2026-08-13）

此前几轮关于"空气曝气能撑多少密度"的推算, 全部依赖设备商配置反算与媒体报道, 直到取得海南省地方标准 DB46/T 424—2017《豹纹鳃棘鲈工厂化养殖技术规程》正文 —— 这是本轮最硬的一份依据, 因为它是成文标准而非推算。

标准表 1 分规格养殖密度: 体长 10–15 cm → 150–250 尾/m³、1–5 kg/m³; 15–20 cm → 100–150 尾、5–15; 20–30 cm → 70–100 尾、15–20; 30–40 cm → ≤70 尾、≥20 kg/m³。标准同时明写密度的约束条件: 「养殖密度与养殖设施、换水量、溶氧量密切相关, 换水量越大、溶氧量越高的养殖水体, 可适当增加养殖密度」—— 正是本模型一直在建的那条逻辑链。增氧设施 (4.4) 规定「采用鼓风机+纳米管或纯氧统一供氧」, 二者并列为合规方案, 未规定密度分界 —— 结合密度表看, 20 kg/m³ 量级下鼓风机+纳米管是标准认可配置, 再次印证空气曝气承载量 20–25 的落点。另: 水质指标 DO≥5 mg/L 与模型 DO_design = max(DOmin_abs 5, 0.7×DO_sat) 逐字相符, 修正后的池内曝气稳态 DO 5.16–5.41 正在标准线之上。

石斑成鱼期 recDepth_m 由 3.0 m 改为 1.5 m, 依据标准 4.2「养殖池面积 10–20 m²、池深 1.0 m–1.5 m」; 万宁在建工厂化项目实测池型 Ø8 m / 90 m³ ⇒ 水深 1.79 m, 亦远浅于原值。⚠ 该字段是统一池深数据源(poolArea = V_tank/poolDepth → A_building = 1.6×poolArea → V_room), 改它会连锁改池面积、建筑面积、蒸发面与通风量, 故基线随之重算。按纪律先出预测: 池面积翻倍 ⇒ 蒸发↑、除湿↑、围护与通风↑ ⇒ 仅 grouper_500 上升且幅度显著, 其余 12 条逐位不变。实测完全命中: grouper_500 工艺成本 44.6291 → 44.8341(+0.2050)、企业全成本 +0.2176、比电耗 +0.2217 kWh/kg、热泵成本 +0.1400(+8.7%, 蒸发面翻倍导致的潜热负荷, 涨幅最大); 其余 12 条 diff = 0。副效果: 成鱼期池底布气强度由 1.71 降至 1.48, 从超限转为合规, 可行密度上限 19.8 → 23.0 kg/m³, 与标准表 1「30–40 cm 段 ≥20」及产业口径 20–25 一致。

控光作为已知未建模维度记入代码注释: 标准把控光列为要求项(4.2「配备通风、控光、控温设施」; 6.2「光照 2000–5000 Lux」, 与 DO/pH/温度/盐度同级)。产业侧佐证: 东星斑养殖场用蓝光红光模拟 20–30 m 深海光照, 因体色直接决定售价。iRAS 缺口有三: 灯具电耗未进 POWER_REGISTRY(比电耗系统性低估)、灯具废热未进车间空气节点(与补 UV/泵废热同族的漏项)、体色分级溢价未进财务侧 —— 这是唯一一条收入侧缺口, 其余遗留全在成本侧。不在本批建模: 需灯具选型口径、光谱配比、光周期, 且体色-售价的量化关系无公开数据。

⑥ 曝气强度限值下调并按养殖对象分档（2026-08-13）

原限值 2.0 / 3.0 m³/(m³·h) / m³/(m²·h) 的依据是搅拌式反应器能效拐点与对虾育苗盘密度反推, 用在鱼身上偏松 2–3 倍。经产业配置反算后下调至鱼类档 1.0 / 1.7, 并将原值保留为甲壳类档(工厂化对虾的正常工况就是"水面气泡成沸腾状", 絮团还需曝气维持颗粒悬浮)。

标定口径写死为全压 20 kPa · 效率 0.60(产业确认: 1 m 深的池子 20 kPa 够用; 罗茨风机压力经验 9.8 kPa/m 水深)。⚠ 不写"20–30 kPa"这类区间 —— 全压取 20 与 50 kPa 结果差 2.5 倍, 含糊比精确更危险。同口径反算: 山东海水工厂化空气悬浮 18 kW/2000 m²(深 0.8)→ 池底 0.97·体积 1.22; 老式罗茨 22 kW/1440 m²(深 0.8)→ 池底 1.65·体积 2.06; 工厂化对虾 15 kW×2/1000 m³(深 1.2)→ 池底 3.89·体积 3.24(该工况正常状态即水面沸腾, 鱼类不适用)。布气密度交叉印证: 纳米盘每 m² 池底 1 个; 对虾池 5.5×5.5 m 配纳米管 28 m ≈ 每 m² 0.93 m 管。承载量交叉校验: 鱼类取池底 1.7 时石斑成鱼期反算可行密度约 20 kg/m³ —— 与设备商系统参数(同一系统: 罗茨风机 20 kg/m²、液氧 40 kg/m², 大菱鲆)及 GSA「>40 kg/m³ 必须纯氧」一致, 三个独立来源收敛于空气曝气鱼类承载量 20–25 kg/m³; 产业侧确认 30–40 配空气曝气偏高。

⚠ 二次修订: 两个判据曾自相矛盾。一次修订把池底 1.7(来自养殖池实配反算)与体积 1.0(来自搅拌式生物反应器能效拐点 0.9)并列当判据用, 结果在 0.8 m 浅池上打架 —— 同一套真实运行的系统按池底判据合格(0.97/1.65 < 1.7)、按体积判据却超限(1.22/2.06 > 1.0)。因 池底 = 体积 × 水深, 池底 1.7 在 0.8 m 下隐含的体积上限本应是 2.1。现改为: 池底为主判据(有真实配置支撑), 体积为次判据且阈值取在实测之上只拦极端 —— 鱼类 池底 1.7 / 体积 2.5, 甲壳类 池底 4.0 / 体积 3.5(一次修订误设的 3.0/2.0 实际低于对虾真实配置 3.89/3.24)。告警文案按主/次判据分别措辞。⚠ 仍依赖假设的风机效率 0.60, 且多数来源未给对应密度, 属待校准项。

新增断言 M13 + 工况 edge_shrimp_air(自检 24 → 25 条)。立此断言的直接原因: 新增鱼种字段 isCrustacean 后, 负对照证明把它从 sp 白名单撤掉24 条自检依然全绿 —— 与 recDepth_m 完全同一模式的第四次复发, 注释提醒挡不住, 只有断言能。更值得记的是: 断言写好后负对照仍全绿, 查明是没有工况能触发它(aerIntensity 仅在 air 模式下计算, 而 shrimp 基线走 o2) —— 新断言必须确认存在能走到它的工况, 否则等于没写。补工况后负对照精确转红(实得 1/1.7, 应为 2/3)。

⑦ 补丁: CO₂ 脱除的机制澄清与浅池告警（2026-08-13, 无数值变动）

交付后有人问"空气曝气对 CO₂ 的去除如何建模", 顺带发现一处我误判为缺陷、实际是正确设计的地方, 特此记录以防后人"修正"它。模型对 O₂ 用 OTE ∝ 水深、对 CO₂ 用与水深无关的亨利平衡载量 kLoad —— 这看似不一致, 查证后确认是两种传质机制的正确区分: O₂ 溶入是【速率控制】(推动力大, 气泡全程远未饱和, 接触越久溶入越多); CO₂ 脱除是【气相载量控制】(气泡在离开液面前已被 CO₂ 饱和, 再深也装不下)。生物反应器放大实测显示 O₂ 的 kLa 随液深线性增长, 而 CO₂ 的 kLa 仅在液深 < 约 1 m 且最弱搅拌下线性, 更深时出现明显饱和效应; CFD 研究同样确认大型反应器中气泡在离开培养液前即被 CO₂ 饱和。若照"补上水深依赖"去改, 反而会把一个正确的模型改坏。

但饱和的前提是停留时间够, 浅池不成立。鱼种库里大菱鲆全程 0.8–1.0 m、石斑苗种期 1.5 m 均在转折点附近或以下 —— 这些工况的 CO₂ 去除被系统性高估, 而大菱鲆是冷水鱼、CO₂ 阈值更严(20 而非 30 mg/L), 三重叠加。本补丁新增浅池告警(水深 < 1.5 m 且 air 模式关塔时触发; 实测大菱鲆三阶段全触发、石斑 1.5 m 及以上不触发、开塔与 o2 模式均不触发)。只告警不折减: 那个 ~1 m 转折点出自搅拌式生物反应器, 气泡尺寸/上升速度/湍流强度与养殖池微孔盘曝气都不同, 硬套来源不同的数字比宽带更糟(与标定探针头注同款教训)。另记一条待查: 级联塔实测显示海水的 CO₂ 吹脱效率显著低于淡水(归因于无机碳电离分数差异), 而模型现有的 marineCO2Factor 挂在 CO₂ 限值上且注释自承"无出处、应单独查证"—— 该系数可能挂错了位置: 海水该被区别对待的或许是去除效率而非限值。

⑧ 断言 M12 与三组负对照

M12a 通风机风量与热工侧真实通风量同源 · M12b 档位一致性(自然通风档必须无风机, 恒温恒湿/机械通风必须有 —— 后者是"恒温恒湿本身即机械通风"的运行时证据)。负对照: 风量挂错口径 → M12a 红(429.5 ≠ 1023.3, −58%)· 恒温档不装风机 → M12b 红(FAIL 3/24)· 误用 70 kPa → 13 条基线红(FAIL 11/24)。实施中另有一次真实被咬: CAPEX 门槛 0.3 kW 与登记表 capexMinKw 不同源时, 断言 F4 当场报出"有电功率但 CAPEX 明细中无对应条目"。

🚀 池内曝气拓扑修正 + 曝气强度约束（2026-08-13）

本版起于一个产业侧提问: 空气曝气是直接打进鱼池的, 鱼在同时消耗氧, 所以风量必然远大于"把水打到 95% 饱和"所需。顺着这句话查下去, 发现模型对同一台鼓风机 K-101 用了两套互相矛盾的拓扑, 并连带挖出一个潜伏的跨模块不同源缺陷。13 条数值基线逐位不变, 自检 24 条工况不变, 新增断言 M9/M10/M11。

① 同一台设备, 两套物理

选型侧 tankAerationDesign 按池内曝气算, 是对的: 池水维持 DO_design(≈5 mg/L), 推动力只剩 (C_sat−C)/C_sat ≈ 26%, OTE 折算后仅 2.2–4.5%, 风量据此反推 —— 确实远大于饱和所需。水质侧却按主流增氧算: DO = DO_sat×0.95 − 单循环降幅, 假设水"进池时"已 95% 饱和。可 air 模式的气是直接打进池子的, 根本不存在"进池浓度"。后果: 同一台按 5.00 mg/L 选型的风机, 水质侧在密度 40 时算出 DO = 0.00, 密度 20 苗种期算出 2.70, 而成本照出、无人报错。本批改为池内质量平衡 C = C_sat − OCR·C_sat/(A·ρ·w_O₂·OTE_base), 与循环流量无关(循环流量只管 TAN/CO₂/TSS)。修正后密度 20/31/40 全部稳在 5.31–5.41, 且开塔工况解析验算 (6.73−1.73/1.10 = 5.158) 与模型三阶段输出逐位吻合。零新常数。

② 潜伏缺陷: sp 白名单漏 recDepth_m（同模式第三次复发）

诊断中发现两条路径的风量对不上。根因: recDepth_m 是鱼种库逐阶段字段, 设备选型侧传完整 stage(有), 水质侧传 recomputeAll 构造的白名单 sp(没有) → 静默兜底 3 m。OTE ∝ 水深, 苗种期两侧风量差 1.68×(222 vs 132 m³/h) —— CAPEX 买的机器与水质链假设的机器不是同一台。该白名单上方就挂着 v1.1.2 的注释「sp 必须包含 DOmin_satRatio 和 DOmin_abs, 否则鱼种内置 DO 阈值失效」: 同一个白名单、同一种漏字段、第三次。负对照证明撤掉修复后24 条自检依然全绿(两条路径各自内部自洽, 只是彼此不同源), 故封在断言层 M11 而非注释层。

③ 曝气强度: DO 与 CO₂ 都达标后先撞线的约束

总风量由鱼的耗氧定, 几乎不随密度变(密度 20→60, 222→332 m³/h); 而水体 ∝ 1/密度 ⇒ 强度 ∝ 密度。新增派生量 aerIntensity(体积强度 m³/(m³·h) 与池底布气 m³/(m²·h)), 超限告警并反算该阶段 air 模式可行密度上限(因 V=生物量/密度, 反解精确而非外推)。阈值 2.0 / 3.0 的出处与局限均写在常量注释里: 前者源自 33.3 m³ 池 CFD+实测的能效拐点(30 vs 60 m³/h 效率差 32.1%, 即 0.90 vs 1.80), 是能效拐点而非福利阈值; 后者由纳米盘每 m² 1 个 × 单盘 1.5–3 m³/h 反推的工程惯例, 非规范条文。定性佐证(气泡扰动噪音不利生长、紊流碎化残饵、三文鱼通气频率随曝气升高且与 DO 无关)只入注释不入判据。实算: 石斑成鱼期可行上限 35 kg/m³ —— 与 40 kg/m³ 的国际经验线接近, 但这次是推导出来的。

④ 断言 M9 / M10 / M11 与四组负对照

M9 气曝-DO 闭环(与 M8 气曝-CO₂ 闭环成对: 一个锁 O₂ 侧、一个锁 CO₂ 侧) · M10a/b/c 曝气强度几何自洽与可行密度反算自洽 · M11 设备侧/水质侧风量同源。负对照逐一验证: 撤 DO 修正 → M9 红(三条 air 工况全咬, 罗非默认密度即 2.08 vs 4.70) · 池底面积错水深 → M10a 红 · 反算写成加法 → M10b 红 · 池底口径误用体积阈值 → M10c 红 · 撤 recDepth_m 白名单 → 修 M11 前无人咬住, 修后转红。另补车间高温告警(与简易模式批次的寒潮告警对称: 比水温高 >5 K 管热泵负荷、绝对 >38°C 管作业与设备降容)。

⑤ 车间模式撤销「露天」档

简易模式批次的车间模式做了三档, 其中 open（露天, 车间热工整体旁路）在中国工厂化循环水里没有实际工程场景 —— 该领域以简易棚为主。保留一个永不被选中的分支只会扩大维护面与审计面, 故本版连同白名单、UI 选项、派发分支、R4 断言枚举一并撤销。向后兼容按既有路径处理: 若方案 JSON 写着 roomMode='open', 白名单不认 ⇒ 与任何非法值同样回落 conditioned（断言 R4b 覆盖, 实测确认）。因该档从未随任何发布出厂, 实际不存在此类文件。

⑥ 海南简易棚实证(本版工作的产业来源)

石斑/三亚/200t/简易棚/关塔/关臭氧与 AOP/放大系数 1.8: 密度 20 → 70.29 元/kg, 密度 40 → 54.23 元/kg。密度 40 下 DO 5.31–5.38 达标、CO₂ 20.45 mg/L 在阈值 22.5 内(曝气本身即脱气, 无需另配脱气塔)、全年凝水为零(海南冬季室外 18–20°C, 围护内表面始终高于露点) —— 唯独曝气强度全线超限。真正的限制是夏季车间温度(设计夏 36–41°C, 池面转得热进热泵)与曝气强度, 不是 DO、不是 CO₂、不是湿负荷。

🚀 简易模式: 自然通风（2026-08-12）

国内多数循环水项目是简易棚: 无暖通无除湿, 车间温湿度由太阳、设备废热与自然通风共同决定。此前该场景无表达路径 —— 关掉暖通开关只是不收电费, 模型仍强制室温=水温。本版新增全局「车间模式」: conditioned（恒温车间, 既有路径逐字保留）/ ventilated（简易棚·自然通风, 新求解器）。（本批原含第三档 open 露天, 后续批次已撤销, 见下。）13 条数值基线在恒温档下逐位不变（全精度导出比对, 非仅容差级）, 自检 23 → 24 条。

① 一次决定性考古: v1.x 做过同款自由求解, 失败了

车间温度自由求解正是 v1.2–v1.9.3 的做法, 当年热带鱼种算出车间 9–14°C / RH 99%, 与摩洛哥温室实测 16°C、大连简易棚实测 22–23°C 方向反了 15–20 K, v2.0 因此撤退到「暖通维持」。本轮复盘确认: 方程没错, 是热源清单漏了三类 —— 太阳辐射（全库无建模）、设备废热（未进空气节点）、接触器尾气显热（被 A3 的温差恰为零掩盖）。空气节点唯一热源只剩池水对流小项, 围护+通风大项把解拽向室外温度。三类全部补齐后重启求解。

② 太阳辐射子系统（全库首次）与自由空气节点求解器

九个气候区各补 GHI 冬/夏/年（Global Solar Atlas / NASA POWER, 三亚年均 5.2 kWh/m²·d）; 四档围护各配窗 SHGC / 屋面 SHGC / 不透明面吸收率（ASHRAE Fundamentals Ch.15, 温室档透光屋面 0.55, 近被动房 0.35）; 不透明面按 sol-air 折算（h_o = 22.7 W/m²K, 墙面 ×0.5 朝向因子）。求解器 solveRoomAir 对显热与湿平衡两线性式经结露潜热耦合做阻尼不动点迭代; 池面显热系数不另取 5 或 15 的常数, 由既有蒸发系数经 Lewis 类比反推（蒸发与显热永远同一张换热面）; 通风显热直接复用 0.34 系数的 UA 项, 与报告口径同源。超饱和时钳到饱和线、结露潜热回注、凝水量作腐蚀风险告警。

③ 简易档的"零"是设备不存在, 不是省略

ventilated/open 档下暖通显热与除湿电耗严格为 0 并由断言 R3 锁死 —— 防「算了不计」复发。池面显热带符号接入水侧热平衡: 三亚设计夏车间解至 36.7°C（高于 27°C 水温）, 池面转为得热, 水侧冷负荷 3,894 → 4,520 kWh/d。同基准三方对照（石斑/三亚/密度20/air/关塔/annual）: 恒温车间 hvac-off 63.9 元/kg（仍计除湿 711 kWh/d 电, 那台机在该档真实存在）→ 简易棚 62.6 元/kg（除湿整机移除省电 > 池面得热代价, 而热泵冷负荷确实上升 6,157 → 6,298 kWh/d）。v1.x 失败特征（车间坍缩到室外之下、池面白捡散热）经三组实测锚点标定确认未重演。

④ 断言 R1–R5 与分层负对照

R1 收敛性（不收敛即红, 界面同步 danger 告警）· R2 物理界（T_room ∈ [min(室外,水温,地温)−0.1, max(室外,水温)+30] —— 对规格原文下界做了推广: 冷水鱼种的池面是合法低于室外的热汇）· R3 模式互斥 · R4 取值合法性与向后兼容（未设 roomMode 的旧方案 JSON 必落恒温档）· R5 空气节点显热闭合（围护+通风流出 = 太阳+内热+池面+尾气+结露, 守恒断言 B 的自由节点版）。五组破坏性负对照逐一验证每道闸门真会咬人: 强制不收敛→R1 红、撤暖通守卫→R3 红、求解器丢尾气项→R5 红、太阳归零→标定钩子红、池面归零→标定钩子红。新增标定探针固化三组实测锚点（摩洛哥温室鳟场 / 大连河豚棚 / ASHRAE 自然通风泳池馆）, 判据为方向+有界偏移+三类热源在场, 点值降级为诊断输出 —— 追着实测点调工况旋钮是曲线拟合表演, 探针头注保留了这条教训。

⑤ 顺带修复: 关塔空气曝气的 CO₂ 新风份额（v2.3 遗留）

air 模式气泡把池水 CO₂ 吹入车间, 新风需求此前只按脱气塔份额计。现关塔且曝气入室时份额取 1（全部 CO₂ 产量入室, 零新常数）。该修复对 air+关塔的恒温档工况有真实影响（新风↑ → 除湿/暖通构成变化, 三亚案例约 +0.3 元/kg）; 13 条数值基线全 o2 模式, 逐位不受影响。开塔时曝气残余吹脱份额仍未细分, 维持开放项。

⑥ 使用要点

全局热工面板顶行新增「🏠 车间模式」。选简易棚后建议把 ACH 调到 15–30（输入上限已放宽到 30）; 简易档下若出现结露告警（围护内表面凝水 kg/d）, 优先加大通风或对围护做防凝露处理; 车间比水温低超过 2 K 时提示寒潮核对鱼种耐受下限。恒温车间档行为与 v2.3 完全一致。

🚀 v2.3 · 第七轮审计处置（2026-08-10）

第七轮独立审计报出两条严重回归, 共性诊断准确: 都是一次正确的重构越过了自己的边界, 且检测缺口同构 —— 断言查的是内容, 失效发生在结构。本版逐条实测核实后处置 (两条属实且比报告更重、一条属实、一条含误报更正、一条按设计决策收窄), 并把「结构」维度补进断言体系。自检 21 → 22 项, 工况 22 → 23 条。

① P0 · <head> 被多余字符提前闭合（实测三处, 审计报一处）

v2.2 构建期补丁写入的三处 description（meta / og / twitter）行尾各多一个 >。HTML5 解析器在第一处把 <head> 提前闭合, 20 个 meta + canonical 全部掉进 <body> —— 爬虫只解析 head, canonical / robots / og / twitter 全部失效; 而 v2.2 的 description 断言用 document.querySelector, 元素在哪个父节点它不关心, 照样全绿。修复三字符, 并新增 head 结构断言（元素必须真的在 document.head 内）, 按「先转红再修复转绿」落地 —— jsdom 内部即 parse5, 负对照免费。

② P1 · 方案 JSON 加载路径绕过全部钳制

v2.2 撤消费处 || 默认 时把 Math.max 取值域守卫一并删了 —— 前者是真相源问题、后者是校验边界问题, 写法相似位置相邻但性质不同。而 clampByFieldSpec 只在 UI 读取路径调用, 载入越界方案 JSON 长驱直入（实测 co2BlowerEfficiency=0 → NaN 遍布, co2StripperGtoL=1e6 → 成本 109 万元/kg）。修复: ensureStageProc 兑现自己注释里宣称的不变式（对 PROCESS_DEFAULTS 数值键逐一钳制）—— 它是 recomputeAll / rebuildStages 的公共入口, 钳制放这里后「UI 有守卫而加载没有」在结构上写不出来。新增工况 edge_hostile_json（六个越界值）, 修复前咬出 Infinity/NaN 于能量 A2/B/C、登记 E1、物质 M4a, 修复后转绿且 13 条数值基线逐位不变。

③ P2 · 鱼池曝气尾气进车间（进气维持室外取, 设计决策）

鱼池是车间内的敞开水面, 气泡上升后在池面破裂 —— 尾气必然进入车间且已被水温饱和; OUTDOOR→OUTDOOR 只对有排风管的脱气塔成立。sink 改 INDOOR, 车间湿平衡产湿侧新增 ṁ_air × (W_sat(T_w) − W_room)。实测罗非养成（28°C/65%）: 1,384 m³/h → 336.1 kg/d, 为池面蒸发的 +29%（审计估 335, 手算 337, 三方吻合）。显热恰为零（A3: T_room = T_w）; 水侧补水股无重复（接触器 netWater 记水体失水、本项记车间得湿, 两本账各一次）。成本影响: 仅 air 模式的除湿机设计选型 CAPEX（罗非 +0.007 元/kg）, 年均电耗不变; 13 条数值基线全部 o2 模式, 逐位不变。进气侧维持室外取气（2026-08-10 设计决策: 进气经风管自室外）, 接触器进气温湿度继续用室外值。开放项: air 模式气泡吹脱的 CO₂ 同样入室, 新风需求目前只计脱气塔份额, 二阶项未建模。

④ P3 · 全局热工配置的分散声明（含审计误报更正）

默认值同时写在 GLOBAL_THERMAL_DEFAULTS 与 readGlobalThermalConfig 的字面量 fallback 里, degasserExhaustIndoorFrac 已实际漂移（表 0 / fallback 0.2 —— 0 正是 v2.1 为气路 A5 改的值, 副本停在旧值, 输入框缺失即复活旧矛盾）。实测更正: 缺失键为 4 个非审计所报 6 个（三个 U 值在表内, 审计漏了 fcDesignDT_K）; 另抓到审计未报的第三处副本 —— 消费点一处 : 0.2 死 fallback（合并链路保证键必在, 永不触发, 但停在旧值待复活）。处置: 补 4 键入表 → 32 处 fallback 一律引表 → 死 fallback 改引表（保留 [0,1] 取值域守卫）→ 两条断言: 键集锁定（配置出现表外键即红）+ 运行时 toString 扫函数源码禁字面量 fallback（首版正则曾漏 3 处对齐多空格行, 是脚本残留自查抓到的 —— 故把这层也固化为断言）。双向负对照精确。

⑤ chart.js SRI 落地（含一处对 v2.2 注释的事实更正）

v2.2 注释预想「联网后 curl 原 URL 取哈希」—— 实测该 URL 的 chart.umd.min.js 在 npm 包内不存在, 是 jsDelivr 对缺失 .min.js 的动态压缩产物, 给它钉 SRI 与给 Tailwind Play 钉 SRI 是同类错误的温和版。处置: URL 改指包内真实发布件 chart.umd.js, 哈希链条 = registry 声明 sha512 → 本地 tarball 复算逐位一致（供应链验证）→ 发布件 sha384。integrity 与 crossorigin 成对上线（v2.2 教训）。新增断言: jsdelivr 脚本必须两者成对、Tailwind Play 必须两者皆无（防 v2.2 样式崩掉事故复发）, 双向负对照精确。

⑥ 第二批 · 曝气风量物理选型(海南低密度主案例驱动)

旧 air 模式风量 = O₂峰值 ÷ (1.2×0.23×SOTE 0.18) —— 0.18 是清水标准态值(20°C、DO=0), 无水深/α β θ/驱动力修正, 实际 OTE 只有它的 1/3–1/2, 风量系统性低估 2–4×; CO₂ 侧风量需求完全缺席, 关塔时只有一个与风量不联动的 fallback 旋钮(海南石斑 20 kg/m³ 关塔实测: 鱼池 CO₂ 55–179 mg/L 超海水阈值 2.5–8 倍, 选型侧毫无反应)。本批实装物理选型: OTE = SOTE(%/m)×水深×αβ×θ^(T−20)×驱动力, CO₂ 侧按 Henry 平衡载量(复用碳酸盐模块 K0_W74 与 ρ 口径, 零副本), 风量取 max(O₂侧, CO₂侧) 并标注控制侧; 关塔稳态 η 由风量反算(η = A·k·逼近/Q), 选型与稳态自此共源。新断言 M8(air+关塔 ⇒ 稳态 CO₂ ≤ 选型目标)按红→绿落地: 旧模型下 144–179 mg/L 转红, 实装后 20.5 mg/L 转绿; DO 饱和(Benson 1984)与 CO₂ 阈值两段内联逻辑抽为共享函数(表达式逐字符不变), 13 条 o2 数值基线逐位未动。新工况 edge_air_no_stripper(石斑/air/关塔), 自检 23 条工况。实施事故记录: 调 K0_W74 时未读函数体先传了 °C(其 Weiss 式入参为 Kelvin), airCO₂ 爆至 1e10 m³/h —— 本会话第六次「猜接口」, 已在调用处留 Kelvin 警示注释。

⑦ 交付方式变更: 补丁链封存

v2.2 的 patches/ 与 tools/ 目录不可得（无法从原环境下载）。自 v2.3 起直接在 v2.2 交付产物上编辑, 「从 v2.1 全量重建」的可复现性就此封存; 验证工具按 HANDOFF §4 规格重建并显式标注（run_selftest / probe / _edit 编辑纪律库, replace_once 强制唯一命中保留）。编辑纪律不变: 每处替换恰好命中一次、断言先负对照转红、基线变动先预测符号量级。

⚙️ v2.2 发布后持续加固

以下三节发生在 v2.2 发布之后, 不改变 v2.2 的功能范围, 只增加护栏与修正 —— 依次为: 碳酸盐接口一致性与 a11y/CDN、物质平衡断言 M、第三方独立复核处置。v2.2 本体的两批发布内容见下方「v2.2 第二批」与「v2.2 升级说明」。

🔗 碳酸盐接口一致性 · a11y · CDN 加固

A. 碳酸盐模块的【接口】验证（此前只验过模块本身）

第三方复核已用 PyCO2SYS 1400 工况验证 carbonate.js 模块本身（淡水 pH 一致到 8.88e-16）。但主模型与它之间隔着一层单位换算，那一层从未验证：TA = 碱度/50043/ρ、CO₂ = 浓度/44010/ρ（mg/L ↔ mol/kg-SW），三个因子任一错，pH 与 Ω 都会偏而无人察觉。

• I1 往返自洽 — solveAlk(pH*) → solve(TA) 应还原 pH*。240 点网格（S∈{0,15,30,35} × T∈{10…30} × pH*∈{6.5…8} × CO₂∈{3,10,25}），最大 |ΔpH| = 0，零抛错
• I2 换算层 — 手工按 50043 / 44010 / ρ 复算，pH 与 Ω 与模型逐位相同（Δ = 0）
• I3 双副本 — work/carbonate.js 与 index 内联块，20 个函数、63 个平衡常数，归一化后md5 完全相同

📌 真正的风险不是「当前是否一致」（是），而是将来会不会漂移 —— 同一份求解器存在两处，没有任何东西阻止有人只改一处。I3 即为此而设。

B. a11y：65 处 label↔input 关联 + 12 个表格横向滚动

UI 审计发现 163 个 <label> 中零个有 for，输入框也全部无 id。后果不止屏幕阅读器：点击标签无法聚焦输入框 —— 这是所有人都损失的常规交互，而工艺参数标签只有 10px，点击目标本就很小。现按 f_${idx}_字段名 生成 id 并关联。另 31 个表格中 12 个未包 overflow-x-auto，窄屏撑破布局，已全部包裹（已验证表格无嵌套，配对包裹安全）。

新增自检三条：工艺参数输入框必须有 id、for 不得悬空、表格必须可横向滚动。

📌 实施过程的教训：正则版本改了三轮仍漏 1 处 —— 查明是 Python re 在超长 title 属性上回溯超限后【静默放弃匹配】（不报错，只是不匹配）。改为线性扫描后一次到位。这类「工具自己悄悄少做了事」与 t21 三次扩展全部落空是同一形态，而两次都是断言先报出数目不对才发现的。

C. CDN 加固：能做的做，不能做的说清楚

两个 CDN 资源性质不同：Tailwind Play CDN 按页面内容动态生成响应体，SRI 哈希无法预先计算 —— 加了必然阻断加载，这是技术限制而非疏忽（要 SRI 须改为构建期产出静态 CSS）。chart.js 是固定版本文件，可以且应该加 SRI。

但本版不填 chart.js 的哈希：当前环境拿不到真实值，而编造哈希会让浏览器拒绝执行脚本、图表直接消失，比没有 SRI 更糟。故只做两件确定的事 —— 两个 script 都加 crossorigin（SRI 前置条件，且让跨域错误可见），并把取真值的一行命令写进代码注释供联网环境补上。

📌 与本项目「判据先负对照证明会红」同源：安全措施也不能靠猜值上线。

🧪 物质平衡断言 M (补上最后一块无护栏区域)

此前断言覆盖能量 (A1/A2/A3/B/C)、水量 (F1/F2/F3)、登记 (D/E/G)、资本 (F4) —— 唯独物质平衡一条没有，而它是本工具的物理核心。第三方独立复核给了这个判断一次印证：三条缺陷全部落在无断言区，断言覆盖区一条问题都没有。

实测确认今天全部闭合后立即固化 —— 此刻成本最低：闭合状态是免费拿到的验收基线；等日后有人改了硝化公式再来查，就得先分辨「是新改的破坏了平衡，还是本来就不平衡」。

断言清单

• M1 氧-构成 总需氧 = 鱼呼吸 + 硝化 + 异养
• M2 氧-硝化 硝化耗氧 = TAN × 4.57
• M3 氧-供给 液氧耗量 = 鱼呼吸耗氧 / 吸收率（纯氧模式）
• M4 碱度链条 净额 = 消耗 − 回收；投加 = max(0, 净额 − 补水带入)；药剂 = 投加 / 0.595
• M6 碳-构成 CO₂ = 呼吸 × 1.375 + TAN × 6.286 × (1 − BF 内脱气)
• M5 氮-稳态 TAN = 单程增量 / (1 − R_tan)，R_tan = (1−η_bio)(1−换水稀释)
• M7 TSS-稳态 TSS = 单程增量 / (1 − R_tss)，R_tss = 四路径 (1−η_rdf)(1−η_skim)(1−η_bioTSS)(1−稀释)

M5/M7 适用域: 水体 ≥ 1 m³。实测产量 1000 t 时四阶段偏差 0.01–0.03%（方程完全成立），产量 0.001 t 时散乱在 −9.7% ~ +11.2% 且方向不一 —— 散乱而非单向偏置，说明是极小规模下的数值行为（水体仅 2 升级、源水本底与各种钳制浮现），不是方程实现有误。极小产量工况的价值在于测崩溃，不在测稳态精度。

TSS 结案：模型正确，是核算漏项

v2.2 首测曾报「TSS 残差 −1.8%，四阶段同号且随规模成比例，未确证为缺陷」。查证结果：模型正确。TSS 单程残留是四条路径，而首测只算了微滤、蛋分、换水三条，漏了 η_bioTSS = 0.2 的生物滤池截留 —— 它是 PROCESS_FIXED 常数而非 proc 字段，按字段名扫描根本看不见。补齐第四路后残差降到 0.02–0.04%。质量侧另有独立证据：代码 6766 行 disch_TSS_kg_d = load.tssDaily，注释「守恒 — 生成 ≈ 排出（不溶不降解，全部最终出系统）」。

📌 这次漏项的形态与前十次不同：前十次错在取值的键名或单位，这次错在漏了一整条物理路径。教训相应更新 —— 核对稳态方程时应以方程本身为准逐项对齐，而不是从导出字段反推路径。建立 M5/M7 过程中另有两次同族错误：exchangeDaily 取值位置错（它是 stage 级字段，不在 proc 里，正是 t23 白名单三项之一）、以及首版适用域用比值而非物理条件。

三条负对照复现了历史上真实发生过的 bug

把过去修过的缺陷形态人为注回代码，断言逐条咬住：

• M6 ← 注入「CO₂ 漏硝化项」(第三方复核 BUG-2 的形态)：报 −41.5%，与报告实测的 34.5–43.4% 同量级。若 v1.9 之前就有这条断言，那个 bug 根本写不出来
• M3 ← 注入「液氧用总需氧而非鱼呼吸」(v1.9.2 修过的口径混淆)：报 +104.7%，与当年记录的「高估 1.65 倍」同量级
• M2 ← 化学计量 4.57 改 4.60：报 +0.656%

另有 M4b 落地当场咬中 edge_yield_0 / edge_yield_tiny 八条 —— 零产量时补水带入的碱度超过消耗，净需求为负而 alkToAdd 被钳到 0。经核实钳制是正确行为（不可能投负量药剂），故改断言纳入下钳而非改代码。

建立过程本身的教训

外部核算这三条口径连续错了三次：液氧误用设备选型口径 o2Demand（含 peakFactor 1.5 与 sAerator 1.10 两个容量系数，报出 −48% 的假不闭合）、碱度消耗误用 tanDaily 而非被硝化的 TAN、碱度回收误用理论值 3.57 而非代码里的工程系数 2.8（注释写明「理论 3.57，工程实测 2.5–3.0 取中位」）。加上此前物质平衡首测的三连错，同族「猜口径」已达十次。

📌 这正是要把核算放进产品路径的理由：断言从 load / sim / eq 的真实导出面取值，不会像外部工具那样猜错口径。「人工核对过所以没问题」不可信 —— 十次实证。

🔍 v2.2 第三方独立复核处置 (2026-08-08)

一份独立复核报告 (jsdom 走真实产品路径 + PyCO2SYS 1.8.3.4 / USGS·APHA 溶解氧表 / ASHRAE·IAPWS 湿空气数据 / 第一性原理手算) 提出三条模型误差。三条全部落在本版自述的断言盲区 (氧侧 / 碳侧 / 水汽侧) —— 该判断准确, 也正是 F 节所说「今天闭合是因为公式恰好写对, 不是因为有东西防止它写错」的直接印证。逐条实测核实后: 一条采纳、一条部分采纳、一条驳回。

✅ 采纳 · co2DailyAvg 漏硝化产 CO₂ (已删除)

co2DailyAvg = o2FishDailyAvg × 1.375 只算呼吸, 缺硝化项, 实测少算 34.5%–43.4%。而同文件的设计口径 co2Daily 是对的 —— v1.9 memo F2 修过同一个 bug「v1.7 之前只算呼吸, 漏算硝化产 CO₂, 导致脱气塔规格偏小 30-50%」, 设计口径已修而日均口径未跟上。这是「同一公式两处实现」的又一实例, 与本版反复处理的「分散重复声明」同族。

全库 0 消费点, 属死字段 ⇒ 删除而非修正。复核报告引用本版删 sourceTemp 时确立的原则「给死控件加钳制等于承认它还活着」来主张删除, 该引用恰当。其风险论证也成立: 带错误公式的死字段比空字段更危险 —— 谁把它接进年度碳核算, 会静默低估三四成且不触发任何现有断言。

◐ 部分采纳 · 0°C 以下饱和水蒸气压 (只订正注释)

复核指出 0°C 以下应使用冰面式, 数值全部属实 (−3.5°C 高 3.50% / −10°C 高 10.44% / −20°C 高 21.97%), 原注释「±0.4% in [−20,60]°C」的下界确实不成立。

但结论需改: 本项目继续用水面式, 且这是自洽的。本项目 RH 数据源标注为「WMO/Climate.gov 30 年均值」, 而 WMO 对 0°C 以下的相对湿度以水面 (过冷水) 饱和压定义, 是气象观测通行口径。humidityRatio(T, RH) 用同一相态把 RH 还原为分压, 前后一致 ⇒ 含湿量正确。改用冰面式而 RH 仍是水面口径, 反会使含湿量系统性偏低 —— 相态必须与数据定义口径一致。故只订正注释适用区间为 [0, 60]°C, 并在函数头写明相态选择依据, 避免下一位读者重复得出「用错相」的结论。

✗ 驳回 · 海水 DO 饱和度「单向偏高 3.3%」

复核建议「改用 Benson & Krause (1984)」—— 而代码用的就是该式本身。逐点比对: S ∈ {0, 30} × T ∈ {10,15,20,25,28,30} 共 12 点, iRAS 与 B-K 标准式偏差全部为 0.0000% (盐度项写法 +S·(−a+b/T−c/T²) 与 −S·(a−b/T+c/T²) 代数等价)。

报告「参考值」反解出的盐度为 ≈35.5‰ (15°C 参考 8.11 → 35.5‰; 20°C 参考 7.38 → 35.4‰; 25°C 参考 6.75 → 35.6‰), 而它对比的是 iRAS 在 S=30 的计算值。拿 S=35 的表值比 S=30 的计算值, 差的 3.3% 正是盐度效应本身, 不是公式误差 —— 报告自己也写着「工况盐度 28-30‰」。「四个测点全部同号」确为系统性偏置, 但偏的是盐度输入。另有一处内部佐证: 报告 28°C 行「iRAS 6.410 / 参考 6.41」数值相同却标 +3.33%, 那个 6.410 实为 T=30 的值, 表格行错位。

📌 此条与第六轮审计的 NH₃/Ω 误报属同一类: 基准取值与被测对象的工况参数不一致。复核方法本身 (jsdom 走真实路径 + 外部权威基准) 是正确的, 出问题的是基准侧的参数对齐 —— 这与本版自己七次「猜接口」错误同源: 从外部取值时必须先确认口径。

附带处置

towerFlowM3h 零值噪声: 复核实测加载时触发 8 次告警, 已自查为误报 (全部来自 edge_yield_0 / edge_yield_tiny, flowM3h = 0)。已加零值短路 —— 噪声会淹没这条告警要抓的真回归, 消除噪声本身就是在保护告警。自检项数陈述: 第一批章节的「17 → 20 项」是当时的准确记录, 第二批新增 field_spec_consistency 后总数为 21, 已加衔接说明。

复核报告的「复核通过项」值得一并记录: 化学计量 8 项对第一性原理手算全部吻合; 碳酸盐体系对 PyCO2SYS 1400 工况, 淡水 pH 一致到机器精度 8.88e-16、海水最大偏差 1.78e-05; 能量守恒 B 断言残差 0.000e+0。这些是本版断言已覆盖的区域, 复核未发现问题 —— 与「三条缺陷全在盲区」互为印证。

📦 v2.2 发布内容

v2.2 分两批发布 (同版分批, 沿用 v2.1 先例)。

📌 v2.2 第二批 (2026-08-07) — UI 审计 · 字段范围单一事实源

源于本版的首次 UI 专项审计。与第一批的登记表工作是同一个模式在 UI 侧的实例: 分散的重复声明必然漂移。自检 20 → 21 项, 13 条数值基线逐位不变 (纯重构)。

A. 🔴 填 0 → 界面回显默认值 → 用户输入被静默丢弃

完整危害链 (已在真实事件路径复现): 用户填 0 → 模型收 0 → 任何触发重渲染的动作后输入框显示默认值 (模板 ${p.X || 默认} 把 0 当 falsy) → 再改任何别的字段, readStageProcFromInputs 全量读回时那个假显示值覆盖 proc, 用户的设置无声消失。这与 v1.9.2「对外发布数字与产品路径脱节」同族, 只是发生在 UI 层。

⚠ 关键教训: 陷阱在三层 (渲染 31 处 / 读取 / 消费 71 处), 只修一层反而更糟 —— 实测只修渲染侧会造成「界面诚实显示 0、模型仍用默认值」, 比原状态危害更大 (原状态至少界面与模型口径一致)。三层必须同批落地, 本批即如此。

B. 🟠 FIELD_SPEC —— 字段范围的单一事实源

同一字段的取值约定此前散布在四处: 默认值表、渲染模板的 min/max/step 与 || 默认值、读取侧的 getNumClamped、消费侧的 || 默认值。实测已漂移四条 —— co2StripperEff 在三处是三个不同的值 (65 / 65 / 75); co2StripperGtoL 的事实源在 v2.0 由 3 改为 5, 另两份副本停在 3; co2PackingHeight_m 同理 (1.5 vs 1.0); climateRegion 事实源 china_qingdao 而消费侧 custom。这些副本平时是永不触发的死代码 (默认表已填好值), 所以漂移了也无人发现 —— 直到用户填 0 让它们复活。

FIELD_SPEC 只管范围 (min/max/step/clamp), 默认值仍归 PROCESS_DEFAULTS, 由断言 H 保证两表对齐 —— 而不是再复制一份 (那会制造第五处声明)。三个消费方 (渲染 / 读取 / 断言) 从同一张表取值。clamp 取UI 范围与原代码钳制的并集: 这条规则是机械的, 不含逐字段工程判断, 且不收紧任何现有能力 ⇒ 无回归风险。

C. 🟠 一并消灭的三条存量问题

• UI 范围 ≠ 代码钳制 (7 字段) — 如吸收率 UI 写 [70,99] 而代码钳 [0,100]: UI 上那些有文献依据的工程范围只是装饰 (type=number 的 min/max 不阻止键盘输入)
• 22 字段完全无钳制 — 各安全系数 / COP / HRT / G:L 等, 手打任意值直接进模型。现统一由 FIELD_SPEC.clamp 执行
• 同字段多处渲染范围矛盾 (3 处) — co2BlowerEfficiency 一处 max=90 一处 85 等, 用户在 A 面板能填的值到 B 面板填不进去。三处渲染同一张表后自动消失

D. 断言 H 与两条判据

新增自检项 field_spec_consistency: H1 每个带范围的输入框 (含全部渲染实例) 的 min/max/step 必须与表逐位相等; H2 clamp ⊇ [min,max] (UI 能填的模型必须接受); H3 表内字段必须在 PROCESS_DEFAULTS 有默认值且落在 clamp 内。落地时精确抓出三处渲染矛盾, 负对照 (改回硬编码) 转红。

E. 🟠 覆盖扩展与 clamp 规则修正 (讨论后落地)

第一版 FIELD_SPEC 只收了原本带 min/max 属性的 34 个字段, 另有 22 个字段完全无钳制 —— 实测 mainPumpEta=0 使主泵报 1383.6 kW (成本 +6.6 元/kg)、VTR20=0 使成本 +12.0 元/kg, 全部有限无 NaN: 危害是「看起来正常的错误数字」, 会原样进可研报告。现已全部接入 —— 依据取自各字段自己的 title 提示 (22 条无一缺失地写明了工程范围, 只是从未落到属性上)。

本批 min/max 取 tooltip 的工程范围 (spinner 边界与用户指引), clamp 取更宽的物理边界 —— 与第一批规则不同, 因两批字段性质不同: 第一批多是效率/比例类硬边界, 本批多是「典型值区间」, 若当硬边界会挡掉合法探索 (大型轴流泵 η 可达 90 而 tooltip 写 60-85)。

并集规则的缺陷与修正: 第一批的 clamp = UI 范围 ∪ getNumClamped 漏了第三个来源 —— 消费处的 Math.max(x, 下限) 隐式约束。它与前两者性质不同: 前两者是允许区间 (取并集=不收紧能力), 后者是物理硬保护 (必须遵守而非并入)。后果: co2BlowerEfficiency 的 clamp 是 [0,100] 而消费处写着 Math.max(η/100, 0.3) —— 用户填 0 时 proc 存 0、界面显示 0、模型实际用 30%。现规则修正为 clamp_lo = max(消费处硬下限, 原下限), 并撤除全部 8 处隐式兜底。

⚠ 该缺陷是判据扩展后才发现的: t22 检查的三个量全在 proc 层, 看不见消费处, 故它一直报「保真 ✅」—— 这是第二次实证「一条判据绿了不等于该层被覆盖」。t23 现已扩展为同时禁止 || 默认 与已登记字段的 Math.max(x, 下限) 两种同族写法。

另删除死控件 sourceTemp: 双证据确认 —— 静态全库无消费点、动态填 -99 结果逐位不变。源水温自 v1.2 起归全局气候 (T_source_annual 等)。给死控件加钳制等于承认它还活着, 故删而不修, 与第一批删 skipClimate 同一原则。

F. 物质平衡实测 (本版仅验证, 未建断言)

发布前对四条基本物质平衡做了产品路径实测 (三文鱼 1000 t): 氮 (TAN) 残差 0.08% · 硝酸盐 0.00 · CO₂ 0.13% (即换水那份) · TSS −1.8%。前三条闭合, 说明稳态方程是自洽解出的; TSS 的 −1.8% 四阶段同号且随规模成比例, 但未确证为模型缺陷 (更可能是核算漏了排污股)。

⚠ 需明确记录: 现有断言覆盖能量 (A1/A2/A3/B/C)、水量 (F1/F2/F3)、登记 (D/E/G)、资本 (F4), 没有一条物质平衡断言 —— 今天闭合是因为公式恰好写对, 不是因为有东西防止它写错。氧平衡、碱度平衡、碳酸盐体系 (carbonate.js 与主模型的交叉一致性) 三项连「今天是否闭合」都未测过, 已列为下一版首要工作。

📌 该实测过程本身产出一条教训: 外部核算连续三次出错 (co2Eff 单位误除 100 倍、猜错反硝化字段名、NO₃ 以 N 计却做了 62/14 换算), 每次都差点报出巨额假不闭合。「人工核对过所以没问题」不可信, 只有跑在产品路径上的内建断言可信 —— 这正是应当把这四条平衡固化为断言的理由。

⚠ 判据盲区实录: t22 (显示保真) 检查的三个量全在 proc 层, 而消费侧的 || 不影响 proc —— t22 结构上覆盖不了第三层, 负对照实测它对恢复消费侧兜底毫无反应。故另补静态判据 t23 禁止 proc.X || 默认 复发。一条判据绿了不等于该层被覆盖。

📌 v2.2 升级说明 (2026-08-07) — 工况覆盖补盲 · 登记表声明自校验

本版源于第三方第六轮审计。审计的核心判断本版照单全收: 断言的质量已超过工况的覆盖面 —— 本轮两条真缺陷现有断言本可抓到, 只是 13 条数值工况全部「mainline + 脱气开 + 纯氧」, 断言从没机会跑到那条路径。自检 17 → 20 项 (新增三条配置边界工况), 13 条数值基线重算 (|Δ| ≤ 0.02 元/kg)。〔第二批另加 field_spec_consistency, 本版最终为 21 项〕

※ v2.1 变更日志曾写「本批并入 v2.1, 不另开 v2.2」—— 指的是当时那批补丁不单独成版, 与本版无冲突。

A. 🟠 三条配置边界工况 (edge_no_degasser / edge_bypass / edge_air_aeration)

只跑不变量断言、不比数值。落地顺序刻意为先加工况 (转红) 再修缺陷 (转绿) —— 红→绿转换本身就是工况有效性的负对照。实测 edge_no_degasser 一个开关同时触发 F4 与 A3 两条断言 (审计称其为「目前最有信息量的未覆盖工况」), edge_bypass 精确复现 capexVia 假阳性 (92.2 kW 与审计逐位一致)。

B. 🔴 蛋分风机 CAPEX 嵌套 (P1) + ΔT/mdot 不动点 (P1)

CAPEX 嵌套: 蛋分风机条目嵌在脱气塔 if 两层内 —— 两套互不相干的设备, 脱气关闭时蛋分照常运行照常计费, 投资却随脱气塔消失。这是 F4 目标模式的第四次出现, 且出现在修复它的同一次提交里。现提出与各独立设备并列。

ΔT/mdot 密度不闭合: 风机温升 ΔT 按冷密度算、焓流按热密度算, 注入热 = 轴功 × (mdot/mdot₀), 丢失的那份默认工况仅 1.2% (藏在 A3 的 0.15 K 容差内), 脱气关闭时风量骤小、ΔT≈30 K, 丢 10.1%。现解联立方程做不动点迭代至 mdot·c_p·ΔT ≡ P_shaft (6 次内收敛到 10⁻⁴ K)。

C. 🟠 轴功 η 逐台加权 (P2)

旧口径 ΣkW × 0.57 与各风机自身效率参数脱节 —— 用户把 co2BlowerEfficiency 从 30 调到 90, 电耗 174→95 kW, 模型轴功却恒按 0.57 折, 方向反直觉 (效率越高, 模型认为进气流的热越少)。物理上 kW_i×η_i = Q·Δp (气侧有用功), 与 η 无关, η 只该影响电机损失分成 —— 逐台加权自动恢复该性质, η 与各功率公式严格同源。

D. 🟠 第四台风机: 鱼池增氧鼓风机 K-101 全量接入 (P2)

空气曝气模式的鱼池增氧鼓风机此前「计费有、CAPEX 有、热去向无、气路登记无」—— 与 v2.0 的 Q_air_gain、v2.1 的蛋分气流、第五轮的风机轴功完全同族, 这是第四次。它鼓的气直接打进鱼池水体, 比脱气塔更无疑问地接触水。现补 airFlowM3h + airPath (OUTDOOR→OUTDOOR, 与 A5 一致)、进登记表、并入轴功加权。逃逸机制值得单独记一笔: 32.3 kW 藏在混合数值与格式化字符串的展示对象里, 所有「数值字段 + 命名规则」的扫描器集体失明。

E. 🟠 断言 E2b: 递归扫 *Spec 子对象

封住 D 项那一类逃逸路径: 对每个 /Spec$/ 普通对象再扫一层, 数值且形如功率的字段, 其点路径必须出现在某登记项的 path 或 aliasPaths (同一设备的已知副本路径, 如 skimmerBlowerSpec.power = 顶层标量的同值副本 —— 声明而非豁免)。⚠ 这是治标; 治本是 registerDevice 工厂化 (登记成为设备定义入口而非事后清点, 「漏登记」变成写不出来的代码), 已立项 v2.3。

F. 🟠 capexVia 由正则改精确名称数组 + capexMinKw

旧正则两个方向都错: /曝气|风机|鼓风/ 命中 4 条, 删掉真目标断言仍绿 (假阴性); bypass 下旁路泵计入「支路泵合计」无独立条目, 零命中导致 F4 四阶段误报。CAPEX 条目名全是字符串字面量, 正则无必要 —— 改精确名称数组, 五台支路泵显式声明共享聚合条目 (capexShared)。精确化随即曝光一条被误命中掩盖了四个版本的存量不一致: BF/脱气塔风机的 CAPEX 选型门槛是 0.5 kW (小于此并入 MBBR 曝气配件价), F4 却统一按 0.05 —— 鳗/虾苗种期 0.4 kW 恰落中间。门槛现显式化为登记表的 capexMinKw, 与 CAPEX 侧同源。

G. 🔴 断言 G: 登记表声明自校验 (堵 v2.1 明示的最后盲区)

v2.1 HANDOFF 原话:「billedVia 可以指向一个不存在的成本字段而断言不会发现」。断言 G1 (billedVia 必须真实存在于 cost 导出、设备活跃时非零) 落地当天抓到 5 条活体 —— 声明写的全是内部变量名 (*CostDaily), cost 导出面是 *CostMax/*CostAvg。认识论上与第六轮审计连错两轮的 dehumCostDaily 是同一个坑: 靠字段名猜接口, 而不是以导出面为准。G2 校验非共享 capexVia 名称不被两条登记项重复认领 (防双计)。三条负对照 (拼错字段 / 指向零值 / 重复认领) 全部精确转红。

H. 🟡 skipClimate 死参数删除 · 渲染与计算解耦

skipClimate: 全库零调用点 (restoreState 直接恢复 stagesState、不经 loadStagesFromDB) —— 为不存在的调用方准备的开关只会在将来被忘传时静默伤人, 已删。渲染解耦: 渲染函数抛错此前被计算 catch 吞掉, 报「阶段 N 计算异常」且销毁本已算好的结果 —— 渲染故障伪装成计算故障。现独立捕获, 计算结果保留, 错误明确标注「渲染异常, 计算结果有效」。负对照双向实测: 修复前人为渲染故障使 13 条数值全灭为 0, 修复后零影响。

I. 基线重算与审计误报驳回

13 条基线 |Δ| ≤ 0.02 元/kg, 符号随工况方向翻转 (制热 ↓ 青岛冬 −0.02 / Bergen −0.02, 制冷 ↑ 海南·三亚 +0.01) —— 与 v2.1 两轮同款的正确性旁证。另驳回审计三条: NH₃ 阈值「六轮未动」与 Ω 告警「六轮未动」均为第四轮已驳回误报的复发 (v1.9.3 起分别按鱼种三档着色、两级徽章告警, 本版实测在位); 「接触器进气节点不可选」为记录在案的设计决策而非漏项。

📌 v2.1 升级说明 (2026-08-01) — 能量守恒修复 · 守恒断言落地

本版源于第三方第四轮审计。核心是修复 v2.0 架构重构时留下的能量守恒破口, 并补齐审计建议了三轮、唯一没落地的守恒类断言。13 条数值基线全部重算, 自检 17 → 17 项(新增三条守恒断言并入既有不变量)。

A. 🔴 车间显热能量守恒破口 (P0)

v1.x 的能量分配是自洽的: 泵/UV 电功率拆两份, 一份进水 (Q_pumps), 一份进车间空气 (Q_air_gain_kW), 相加恰为电功率。进空气那份在旧模型里进入空气节点能量方程。

v2.0 删除空气节点时, 挂在该节点上的产热项没有被重新安置。Q_air_gain_kW 仍在计算、仍在返回, 但不再进入任何一侧平衡 —— 既不在水侧, 也不在暖通侧。这部分能量从模型里凭空消失。

同因还有第二处 (本轮自查发现, 审计未列): dehumHeatDest === 'indoor' 时的除湿机冷凝热。第 5461 行注释写着「排入车间的部分已在 T_room 迭代中计入」—— 而那个迭代在 v2.0 已被删除, 注释与 UI 提示都停留在旧模型。

实测规模 (三文鱼 1000 t 青岛设计冬): 丢失 1,617 kWh/d, 达 HVAC 显热负荷 3,864 的 41.8%。模型一边说要给车间供暖, 一边把电机与灯管废热倒进同一个车间却不入账。

修法: Q_hvac_sens = Q_envelope + Q_vent_sens − Q_room_internal, 其中室内产热 = 设备废热 + 除湿冷凝热(入室时)。符号由 Q_hvac_sens 自身携带, 不需分支。

✅ 修复后成本变化的符号随工况方向翻转, 这是正确性的旁证: 制热工况下降 (青岛冬 −0.22, Bergen −0.15 元/kg, 废热减轻供暖), 制冷工况上升 (海南冬 +0.11, 青岛年均 +0.06, 废热加重制冷)。若为单向偏移, 反而说明修错了方向。

B. 🟠 守恒类不变量断言落地 (建议三轮未落地)

A 项那类缺陷现有三类断言全都抓不到: golden-master 抓不到 (基线跟着一起变)、有限性断言抓不到 (数值完全正常)、口径一致断言也抓不到 (不涉及同一量的两处换算)。只有守恒断言能抓。而同一版里出现两处同样成因的孤儿项, 说明这不是偶发失误, 是架构改动时缺少守恒护栏的系统性风险。

现已并入 ?selftest=1 的逐阶段不变量 (亦有外部脚本 t20_energy_closure.js 同源可挂 CI), 三条:

• A 设备产热分配完整性 — Q_pumps + Q_uv + Q_air_gain×24 = 泵电功率 + UV电功率。电功率 100% 终归变成热, 只有进水/进空气两个去处, 不得有第三个
• B 车间显热闭合 — hvacSensible = Q_envelope + Q_vent_sens − Q_room_internal
• C 水侧净热闭合 — 含代谢/设备/补水/蒸发/除湿/接触器六项

修复前实测: 断言 A、C 通过, 断言 B 在 56 个「工况×阶段」组合中 48 项失配, 残差与 Q_air_gain×24 逐位相等 —— 诊断被精确坐实。⚠ 新增任何进/出车间或水侧的热流时, 必须同步这三条式子, 那正是目的。

C. 🟠 自然冷却可见性回归 (P0)

v2.0 新增 fcUnavailReason 时的单行编辑失误, 把同行的 freeCoolingSinkT: _fcSink, 并进了行尾注释 —— 该字段自 v2.0 起不再导出, UI 第四档分支因而永不触发。v1.9.3 加这一档的动机是「用户拨动开关看不到任何回应, 无法区分『因不可用而无效』和『坏了』」, 修好一版之后又回归了。而本该替代它的 fcUnavailReason 做好了却全代码库无消费点。

本轮另发现第三层: 整个状态段包在 pumpDirection === 'cool' 里, 而 v2.0 最常见的原因恰是 not_cool (接触器把热排光, 水侧转制热) —— 即便前两层都修好, 最该解释的情形仍然不说话。

现改为读 fcUnavailReason 枚举 (四档 + 显式 default), 并把 not_cool 提到方向判断之外。缺字段会落到显式分支而非静默跳过 —— 这类「注释吞代码」用眼睛复查很难发现, 改成枚举后才有护栏。

D. 🟡 口径与参数四处

• totalMax 补 hvacCostDaily —— 此前只有 totalAvg 含它, 而 totalMax 是面向用户的「小计·工艺运行成本」并导出下游。同为暖通电耗, 除湿计入而显热不计, 无理由 (青岛冬 1,166 元/d, 约 0.97%)
• dehumEnabled 开关对成本完全无效却仍 gate 显示 —— v2.0 把除湿改为无条件的暖通职责后, 用户设「不配置」照付 2,989 kWh/d (海南夏) 却看不到卡片。实测开/关成本一字不差。现改为按是否真有除湿负荷显示
• degasserExhaustIndoorFrac 默认 0.2 → 0 —— 与气路拓扑 A5「工艺气路全程不碰车间」对齐。同一股尾气此前算热时 0%、算 CO₂ 时 20% 进车间; v2.0 把暖通显热计入能耗后该矛盾首次影响成本
• co2StripperGtoL 引擎侧钳到 [1, 30] —— 旧式只有下界。UI 有 min/max 但可被载入方案 JSON 绕过, 填 1e6 得接触器排热 4.1×10⁹ kWh/d (有限但荒谬)

E. 🟡 鱼种默认气候联动

v2.0 修正了自检基线的鱼种-气候配对, 但 UI 默认仍是青岛且切鱼种不联动 —— 用户点「罗非鱼」拿到的就是被修掉的那个组合 (28°C 的鱼在 −7°C 过冬)。测试修好了, 产品还在发同一个陷阱。

新增 DEFAULT_CLIMATE_BY_SPECIES (与 SEED_PRICE_BY_SPECIES 同样板), 切鱼种时联动。实测比电耗: 罗非 16.21 → 13.48, 对虾 36.85 → 18.84, 鳜鱼 28.56 → 22.95。仅改默认起点, 用户仍可自由切换。

⚠ 剩余差距来自产品默认工况是设计冬而基线用年均 —— 定容工况与运行工况的正当区别, 不是配对问题。

F. 关于审计的两处不同判断

审计报「HVAC 潜热算出来但未计费, 海南夏 +0.42 元/kg」—— 经复算不成立。v2.0 已把 m_dehum_kgs 改为无条件计算的暖通除湿职责, dehumCostDaily 已进 totalMax/totalAvg; 海南夏模型实算潜热 5,117 kWh/d → 除湿电 2,989 kWh/d, 按 SMER 2.5 折算已计费。真正的问题是反向的 (见 D 项第二条: 开关无效却 gate 显示)。

G. 🟡 补齐三处漏项 (第二批)

在审计「仍然开放」表逐条实测复核后补上, 均为纯增项。

• 车间暖通机组 CAPEX (AHU-1002) —— v2.0 引入车间显热能耗、v2.1 又修准了口径, 却一直没有对应设备与投资 (实测: CAPEX 17 条里有热泵、有除湿机, 暖通 0 条)。与 v1.9.2 给除湿机补 CAPEX 前的状态同构。按设计冬/夏显热峰值选型, 合计 85.5 kW / 24.4 W/m²。⚠ 与热泵不重复: 热泵调水温, 本机组维持室温
• 制冷↔制热切换余量 regimeMarginPct —— 审计指出默认工况正坐在制度切换边界上 (单项 +0.24~0.36 而合计 +2.49, 严重非线性)。而 v2.1 的守恒修复恰好移动了这个边界 (青岛冬 hvacSens 3,355 → 769), 边界挪了提示更该有。实测 G:L=3 时余量仅 3.9%, 默认阶段 1 仅 0.5%。余量 < 15% 时在阶段卡片提示
• 蛋分供气风机 (K-501) —— 此前只有支路泵没有风机, 而泡沫分离的效率由气量决定 (没有气就没有泡沫)。新增气水比/风压/效率三参数, 成鱼期 6.41 kW / 508 m³/h

H. 🔴 登记完整性断言 —— 守恒断言抓不到的那一类

加蛋分风机时连犯三个同类错误, 现有断言一个都没抓到:

• 风机并进 totalPumpKw (废热错误地按 pumpHeatRatio 进水) —— 守恒断言 A 等式两边同步放大, 残差为零
• 漏加 elecCostAvgDaily —— 比电耗单向低估, 该口径是手工枚举、无断言
• 气流未登记 airPath —— 508 m³/h 的接触水气流不进接触器热湿交换; 风量平衡断言只校验已登记项之间是否自洽

第三条与 v2.0 的 Q_air_gain 孤儿项完全同类。结论:

守恒/平衡断言只能约束已进入体系的量, 无法发现压根没进体系的量。要抓后者, 必须从设备侧反向枚举。

新增 POWER_REGISTRY 登记表与两条断言 (并入逐阶段不变量):

• D 气流登记完整性 —— 凡带 airFlowM3h > 0 的 spec, 必须 (a) airPath 三字段齐全 (b) 出现在 collectAirStreams() 输出中 (c) spec.power 与同名标量一致
• E 电功率登记完整性 —— 凡 /Kw$|Power$/ 且 > 0 的字段必须在 POWER_REGISTRY 声明计费去向; 且 totalPumpKw 必须等于其声明成员之和

四条负对照全部精确转红 (用上面三个真实犯过的错 + 缺 airPath 构造)。其中「风机并进 totalPumpKw」正是 t20 守恒断言抓不到而登记断言 E 抓住的那条。⚠ 新增任何风机/泵/用电设备时必须同步 POWER_REGISTRY —— 那正是目的。

⚠ 本断言仍有一层盲区: 登记表本身可以声明错 (如 billedVia 指向不存在的成本字段)。堵它需校验该字段真实存在且非零 —— 未做。

J. 🟠 接触器净水汽计入水量平衡

v2.0 把接触器的热计入了水侧平衡, 但水的质量一直没进 V_makeup。本版补上, 并顺带修掉一处已存在但从未显形的盐度错误。

发现的两个问题

• 符号不对称 —— 凝结水减少补水 (已建模), 但蒸发不增加补水。补水与排污都等于 V_total × exchangeDaily, 注释写着「质量守恒」而蒸发不在其中。与 v2.0.1 修的 totalKw_field 同族: 同一物理量的两个方向只守一边
• 纯水扣错了股 —— 凝结水与除湿水是纯水, 却去扣减含盐的换水股。后果: 海水进得少、纯水补进来, 盐度会漂低 —— 一个已经存在但从未显形的错误 (盐度不是状态变量, 无处报警)

采用的简化: 拆两股水流

蒸发走掉的是纯水, 就补等量淡水, 独立成股, 不动换水份额:

体积平衡与盐平衡各自闭合, 盐度因此恒等守恒 —— 不需要盐度状态变量, 不需要「补水盐度」参数, 不需要补盐 OPEX。工程上这也是实际做法: 海水 RAS 的蒸发补水本就走独立的淡水补给管路。实测换水股与排水量逐阶段完全相等。

实测规模 —— 订正 HANDOFF v2.0.0 的记载

⚠ HANDOFF v2.0.0 记的「584.6 kg/h, 占补水 6.0%, 单向系统性偏差」三点都不准确: 实测范围 −10.8% ~ +10.7%, 双向。湿热气候下净结露, 模型反而高估补水需求。字段因此命名 netWater 而非 evap —— 「热带养冷水鱼」正是 v2.0 新增的能力, 净结露是常态而非边角情形。

净结露时没有「补负淡水」这回事: 纯水先抵扣蒸发股, 抵到零仍有余量的转为排水, 并按现有假设推出稳态盐度 S × V_exch / (V_exch + V_surplus)。这不是新建模, 是把模型现有假设的推论说出来。

断言 F (三条)

• F1 水量闭合 —— 总补水 = 换水股 + 淡水股, 两股均 ≥ 0。拆股后这是恒等式, 转红即说明两股水流的分离被破坏
• F2 盐平衡 —— 无净结露时盐度不得漂移; 有净结露时稳态盐度须等于稀释式
• F3 热质同源 —— 由导出的 mdot / W_in / W_out 独立重推净水汽量并比对。若有人把它改成独立的经验蒸发系数, 立刻转红 —— 这是本方案的核心护栏

⚠ F3 初版写成「潜热占比须在 [50%, 105%]」, 用 Karimi 2020 的 91% 做区间 —— 判据错了。那 91% 是近等温工况(出口气温与进水温差 0.77°C) 的实测值; 青岛冬进气 −7°C、水温 12°C 时显热 19.1 kJ/kg、潜热 18.0, 占比 48.5% 是物理正确的, 却被区间判红。用文献单点值当断言区间, 必须先确认该值的适用工况。

K. 🔴 第五轮审计 — 风机热与登记表升级

K1. 🔴 三台风机的热此前没有任何去处 (P0)

模型对泵与 UV 做了完整的电-热分配 (进水 Q_pumps + 进空气 Q_air_gain = 电功率), 但三台风机 (脱气 53.6 + BF 42.4 + 蛋分 11.7 = 107.7 kW) 的电功率既不在这个分配里, 也不在任何其它热流里。代码注释写了「不走 pumpHeatRatio 进水」—— 这是对的, 但它也没走别的任何地方。

后果: 风机轴功全部变成气流温升, 而这三台吹的正是接触水的那三股气流, 接触器却用原始室外温度。方向与 v2.0 的 Q_air_gain 完全一致 —— 模型付电费让风机运转, 却让这些电产生的热凭空消失, 然后再付一次热泵的钱把水加热回来。

修法: 轴功 (η=0.57) 抬高接触器进气温度 (青岛设计冬 −7 → −3.5°C, 升温 3.3–3.5 K), 电机损失并入 Q_room_internal。⚠ 加热是等湿过程, 绝对含湿量不变, 只有温度抬高。

✅ 成本变化符号随工况方向翻转 —— 制冷工况上升 (海南夏 +0.42 / 三亚 +0.41), 制热工况下降 (Bergen −0.23 / 鳜鱼 −0.36)。与 v2.1 守恒修复时一致, 单向偏移反而说明修错方向。

K2. 登记表升级为唯一真相源

审计指出同一缺陷已在三个抽象层各出现一次: Q_air_gain (v2.0) → 蛋分气流漏登记 (v2.1 自查) → 风机热无去处 (本轮)。成因是计费去向、热去向、资本去向分散在三处不同机制里, 每处覆盖边界都是手工划的。

POWER_REGISTRY 每条现声明四项: path (支持嵌套) / billedVia / heatVia / capexVia。断言改为从登记表反向枚举 —— 旧断言 E 用 Object.keys(eq) 正向扫描 + 命名规则, 实测漏掉 co2StripperSpec.blowerKw (53.6 kW) 与 bfBlowerSpec.power (42.4 kW)。审计原话:

「为『漏了蛋分风机』而建的断言, 覆盖了蛋分风机, 却覆盖不了另外两台大 4–5 倍的风机。」

新增断言: A2 (全量电-热分配, 由登记表枚举 heatVia) 与 F4 (登记设备必须有 CAPEX 条目)。F4 落地后立刻抓到蛋分风机「有电费无投资」 —— 这是同一模式的第三次 (v1.9.3 加药计量泵 / v2.1 车间暖通机组 / 本项), 前两次只写了注释总结、没变成断言。

⚠ 实现过程中 A2 连报两次「已接入 0.00 kW」, 两次都是真错 (哨兵串被后续补丁注释污染导致静默跳过; const 块作用域导致变量在 return 处不可见)。若没有 A2, 第二个错会完全静默 —— 数值正常、无 NaN、守恒 B/C 照常通过, 风机热又一次凭空消失。

K3. 气候联动只覆盖点击路径

审计报「温水鱼种 × 青岛未修」—— 结论不成立 (字段真名是 DEFAULT_CLIMATE_BY_SPECIES, 点击鱼种实测罗非 13.83 / 对虾 19.27), 但他们给的数字恰好是没有联动时的值。查因: 联动只挂在鱼种按钮的 click 处理器里, loadStagesFromDB() 不调用 —— 载入方案 / 下游导入 / 测试脚手架全部绕过。审计撞到了真洞, 只是归因错了。

已移入 loadStagesFromDB()（所有切鱼种路径的必经之处），并加 skipClimate 开关 —— 载入用户保存的方案时不覆盖用户当初的显式选择。〔v2.2 订正: 该开关全库零调用点 —— restoreState 直接恢复 stagesState、不经 loadStagesFromDB, 开关从未被使用, 已于 v2.2 删除 (第六轮审计 P3)〕

📌 意外收获: 对虾基线 −3.58 元/kg (热泵费 2.77 → 1.90)。原因是基线只覆盖年均字段, 而设备选型用设计冬/夏 —— 三亚年均运行的对虾场一直按青岛设计冬选热泵。属选型工况与运行工况长期不一致的修正, 不是回归。

K4. 与审计的两处不同判断

「HVAC 潜热未计费」不成立 (第二次报同一条)。实测海南夏潜热 4,473 → 除湿电 2,613 kWh/d / 1,829 元/d。hvacLatentKWhPerDay 与 dehumKWhPerDay 是同一个 m_dehum 的两种表达, 再计一次就是重复。

「买了 92 万除湿机一天不开」表述有误。CAPEX 按设计夏峰值选型是正常工程做法 (夏季峰值选型、冬季不运行), 默认视图是设计冬所以显示 0 电费。经产品方确认, 除湿按独立机组处理: 潜热由独立除湿机承担、AHU 只管显热, 二者不重复。

K5. 收尾两项

• 蛋分风机 1+1 备用 —— 补 modulePerSpec 规格后, 三台风机的备用政策终于一致 (co2Blower / bfBlower / skimmerBlower 均 1+1)。与 v1.9.3 给脱气塔风机补规格时完全同一处境, 当时的原注释即适用:「此前没有模块化规格, 因而设备清单不显示备用、CAPEX 也不计备用。」
• v1.9.2 章节 G / I 两表加历史横幅 —— 数字 (37.53 / 比电耗 9.5) 是当时实测, 原样保留为历史记录; 但同章节末尾「请以本节为当前基线」这句在 v1.9.2 时是对的、现在已指错, 会让读者把 37.53 当成当前值, 已加订正批注。当前基线由 <meta description> 自基线自动生成。

⚠ 补丁顺序教训: 「meta 自基线生成」是构建期动作, 正确位置是链尾。第一次修复给了编号 48, 结果新增基线补丁 51 又排到它后面, 同一问题立刻重现 —— 现改为 99, 让「链尾」由编号本身保证, 而不是每次靠人记得。

I. 版本号与位号

• 版本号统一为 v2.1 (此前 v2.1.0)。本批并入 v2.1, 不另开 v2.2。v2.0.0 / v2.0.1 的历史叙述保持三段式原样
• 蛋分供气风机补位号 K-501 —— 蛋分区已有 C-501 (塔) 与 P-501 (支路泵), 同类的 K-101 (池增氧) / K-302 (BF 风机) 都有位号, 唯独新加的风机没有。P&ID 注册表内带 isBlower 标志, 供下游区分泵与风机符号

审计报「三处对外基线未跟上重算」—— 仅一处成立。<meta description> 确是当前对外事实, 已更新; 另两处 (行 1544「G. v1.9.2 成本基线」/ 行 1576「I. mainline vs bypass」) 都在 help-changelog-v192 章节内, 是 v1.9.2 变更日志的历史记录, 改它们等同于污染版本演进记录 —— 正是 v2.0.0 版本号全局替换踩过的坑。「常年需要制冷」那句按同一原则处理: 加 v2.0 订正批注, 不改原句。

水的热平衡 (kWh/d, 正=向水加热):
  Q_net_water = + Q_metab            (鱼代谢, 沿用 v1.1)
              + Q_pumps + Q_uv      (设备产热, 沿用 v1.1)
              + Q_makeup_signed     (补水温差, 扣板换 + 凝结回收)
              − Q_pool_loss         (池水→车间空气, U·A·ΔT)
              − Q_envelope          (墙+顶+地板+窗, 多 U 多 ΔT)
              − Q_vent_sens         (通风显热, 含热回收)
              − Q_evap_latent       (蒸发潜热, 凝结时反号 +)

车间空气节点 (内生, 闭式解):
  T_room = (UA_pool·T_w + UA_to_outdoor·T_air + UA_floor·T_ground)
         / (UA_pool + UA_to_outdoor + UA_floor)
  W_room = (β·ρ·cover·A·W_w_sat + m_air·W_air)
         / (β·ρ·cover·A + m_air)        [饱和约束 RH ≤ 99%]

蒸发率 m_evap [kg/s] = β · ρ_air · cover · A_pool · (W_w_sat − W_room)
  正值 = 蒸发  (水散热);  负值 = 凝结 (水吸热)

热泵 COP 修正:
  COP_real = COP_nom × (1 − k × |T_source − T_ref|)
  ASHP heat: T_ref=7,  k=0.030;  cool: T_ref=35, k=0.025
  WSHP/GSHP/海水开式: 见 correctedCOP() 函数