Octopus Polarstar
工程项目的答案会变。Polarstar 保留它变化的理由。
每个数字都带着自己的边界、作者与证据。当其中之一发生变化，平台会明确告诉你什么不再成立——并阻止旧答案继续被当成当前答案引用。
问题
项目很少因为算错而失败。它们失败于：算对了，三周后某个输入变了，而所有人还在引用旧的那个。
真实项目的状态散落在 Word 文档、聊天记录、供应商 PDF、表格和仿真输出里。评审人通常能找到答案是什么，但找不到：它为什么从 A 变成了 B、是谁提供了新证据、哪个假设被推翻，以及当前结论究竟建立在哪一版供应商数据和哪一次仿真之上。
这个问题应该是点一下就能回答，而不是一次考古。
四条规则
数值必须带着它的边界
「45%」不是事实。「以 LHV 为基准的氢化学能输入，到含系统辅机的净电输出，45%」才是。拿两个测量边界不同的效率互相比较，是系统级数字出错最常见的方式——所以边界始终跟着数值走。
四类数字，绝不共用一列
需求、供应商声明、仿真结果、实测值是四种不同的东西。它们都是关于同一个参数的数字，把它们塞进一个叫 value 的字段，正是一个项目最终按照一个宣传数字来做设计的方式。
任何事实都不被覆盖
新数值取代旧数值，但不替换它。旧记录保留自己的作者、日期与证据——因为只有旧答案还在，「它为什么变了」才回答得出来。
派生量必须是推导出来的
储氢质量由可用电能与燃料电池效率算出，从不存储。一旦存下来，就等于把某一个假设冻进了模型，也就失去了「这个假设变了会牵动什么」的能力。
如何运作
一个离开一周的评审人真正需要的三件事。
一个参数的页面，就是它的历史
关于同一个量的每一条断言，按时间排列，标明是谁在什么边界上说的。供应商的数值与干系人基线并排存在，而不是替换掉它。
- 50 %假定2026-07-28
- ↓ 被取代于
- 45 %干系人输入2026-08-15 · Sherry
- ↓ 对照于
- 46.8 %供应商声明datasheet p.17
- ↓ 验证于
- —实测尚未测试
候选与需求的对照
把供应商声明与系统要求逐项对照。缺口是从数据算出来的，不是从对话里总结出来的。
| 参数 | A | B | 要求 |
|---|---|---|---|
| System η | 46 % ✓ | 49 % ✓ | ≥ 45 % |
| Start temp | 0 °C ✗ | −10 °C ✗ | ≤ −20 °C |
| Outdoor | no ✗ | yes ✓ | yes |
⚠ 没有任何候选能满足的需求是一条发现，而且是算术，不是观点。
我们现在为什么相信这一点？
从一个决策一路回溯到发现、到仿真运行、到部件版本、到断言，最后落到一份带页码的文档。
- Decision
- ↳ 支撑自Finding
- ↳ 产出自Simulation run
- ↳ 使用了Component version
- ↳ 记录于Datasheet — p.17
而一旦有东西变了，它会说清楚弄坏了什么
取代一个数值会触发全图遍历，把依赖它的一切标记出来。不删除、也不阻塞——旧的运行仍是有效历史。过期的是「拿它来做决策」，而值得渲染的只有这个区别。
三层
Lab
需求 · 供应商 · 证据 · 实验 · 发现 · 决策人在这里工作，这里也是事实源。每个对象都带版本、带来源、可审计。
Engine
架构 · 布局 · CAD · 热 · 氢 · 有限元 · 优化AI 系统工程闭环。需求进、架构与分析出——消费 Lab 冻结的快照，再把运行结果写回。
Workers
FreeCAD · Gmsh · CalculiX · Code_AsterEngine 驱动的 CAE 进程，容器化、无头运行。
参考项目
一套集装式氢能系统，是 Polarstar 上运行的第一个工程项目。
电解槽、固态储氢、燃料电池、储能电池与热管理，覆盖 5 kW 与 10 kW 两个平台等级。它的需求集、未决矛盾与供应商评估全部存放在 Lab 中。
本页刻意不写的内容：哪一家供应商不满足哪一条需求。那是属于该项目的供应商评估；一个主张「证据应被审慎对待」的平台，不能一开场就先花掉别人的证据。
平台中没有任何氢能专属的东西。储能、医疗器械、传感器、机器人是同一个问题换了单位——某人在某个边界上断言了一个数值，而其他工作已经开始依赖它。
如果你项目当前的答案说不出它的作者是谁，那它还不算一个答案。
Polarstar 正伴随一个真实工程项目持续开发中。Lab 现已可用。
进入 Lab