流程图连好了，参数填完了，点击运行，屏幕上出现一句“计算失败”。
接下来怎么办？检查进料，换一组初值，调整容差，再运行一次？如果涉及循环物流、嵌套求解或复杂物性，工程师很容易陷入反复试算：看见了失败，却不清楚问题在哪一层，更不知道下一次修改是否有依据。
开发 RadishFlow 时，我越来越觉得，消息系统会直接影响一款过程模拟软件的专业程度。这里的“消息”，指的是输入检查、运行事件、数值诊断和工程提示。它们连接着模型内部的计算过程，以及工程师接下来要作出的判断。
消息系统需要回答：缺什么，算到哪里，出了什么问题，哪些结果可用，下一步怎么办？这些回答既关系到工程排错，也关系到算法、模块和物性方法的开发与验证。
本文围绕 RadishFlow 已确认的消息系统规划展开。项目已有基础诊断与定位能力，文中讨论的统一工作台、执行追踪、条件暂停及开发者诊断仍属于未来设计。配图均为 AI 生成的概念界面，数据与状态仅作示意。
从一句“失败”，到一个可以处理的工程问题。
假设 E-101 在当前计算模式下缺少出口温度，导致后续分离器无法获得有效进料。用户可能同时看到设备标红、流程运行失败、下游没有结果。
这些表现背后，可能只有一个直接的阻断问题。若各处独立报错，一件事就变成了一串需要人工核对的消息。
RadishFlow 规划采用同一份问题记录，关联全局摘要、画布对象、模块面板和问题列表。同一问题可以在多处被看见，但只计一次；点击消息能够定位到具体字段、端口或连接，并说明它影响了哪些后续计算。
对于有明确依赖证据的连锁阻断，系统应突出需要优先处理的问题，将受影响对象放在它下面。只有“时间上接近”或“文字相似”的消息，则不能直接被认定为同一根因。
用户先了解对象、原因与影响，再按需要展开技术细节，从发现问题走到具体操作。
概念界面一：一个输入问题关联多个展示位置，定位与影响范围同时可见。
把“现在有什么问题”和“刚才发生过什么”分开。
消息系统里有两类信息很容易混淆：一类描述当前仍然存在的问题，另一类记录本次计算发生过的事件。
例如局部求解尝试失败，执行器调整初值后成功恢复。失败记录应保留，但当前是否仍有问题，需要依据实际恢复结果判断。不能始终用历史最高严重程度代表当前状态。
反过来，关闭消息、标记已读或清空可见列表，也不能让一个真实问题自动解决。修改相关参数之后，问题应进入待重检状态；只有新的检查给出明确依据，才能宣布它已经解决。
RadishFlow 希望把问题的活动、待重检、已解决、已恢复与历史状态表达清楚。每条记录都关联相应工程、输入版本和运行范围，避免上一轮失败继续干扰新工况，也避免旧消息跳转到后来新建的同名设备。
工程师由此既能处理当前任务，也能回头理解问题如何发生、如何解决。
“运行完成”需要拆开来看。
程序走完步骤、数值满足收敛准则、结果对应当前输入，以及设备满足工程要求，是不同层面的结论。
流程可能已收敛，但设备压降超出研究限值；热工计算可能已完成，但设备校核尚未进行。单一的绿色或红色不足以表达这些区别。
RadishFlow 规划分别呈现运行状态、数值结论、结果可用性和当前问题。用户可以看到“计算完成，当前结果可查询，仍有两项警告”，也可以看到“数值收敛，设备约束校核未通过”。
“没有活动错误”也需要说明检查范围。尚未检查、不支持检查和检查通过，不能都显示为空白；导出文件失败，也不能被算成设备求解失败。
对于暂停或失败过程中的观察值，还要标明它属于哪次运行、哪一步、是否只是试算值。局部数据有助于诊断，但不能据此宣称全流程成功，更不能悄悄进入正式结果表。
这种细分让用户准确理解软件已经证明了什么，也理解哪些判断仍需自己完成。
让计算过程真正可观察。
一个流程图上的设备顺序，并不总等于实际求解顺序。循环物流可能使同一单元被多次调用，外层循环之内还可能嵌套物性计算；不同求解方式暴露的执行粒度也不一样。
因此，RadishFlow 规划中的执行视图将由真实运行过程形成：从运行、执行组到循环、迭代与具体求解步骤。失败步骤应保留发生位置和已知上下文，尚未执行的步骤则明确标注，不能只留下成功节点。
收敛曲线也需要上下文。一条向下的曲线，只有说明对应哪个循环、采用什么残差、如何缩放、判定阈值是多少，才具有诊断意义。不同物理量的原始残差不宜直接按数值大小比较，内层求解收敛也不能代替外层循环的收敛结论。
用户应能从某次迭代回到相关变量与事件，辨认试算值与接受值。停滞或振荡应有判据支持，曲线外观只提供线索。
这里需要兼顾记录成本。COMSOL 的公开文档就区分了求解日志详细程度，并说明日志采样间隔会影响开销。
RadishFlow 同样规划区分采集范围与显示详细程度：普通高频事件可以按策略采样，错误、停止命中和终止等关键证据需要可靠保留；记录被截断或缺失时明确提示。没有采集的数据，事后展开面板也不能凭空补回来。
概念界面二：区分内外层计算，结合残差定义、阈值和运行身份审阅失败过程；曲线不代表真实求解结果。
消息系统也应当帮助开发者研究模型本身。
过程模拟软件的使用者中，还有一类人会修改算法、编写设备模块，或调整物性参数。对他们而言，“在哪个设备失败”只是排查的起点。
算法开发者需要知道哪层迭代没有满足准则，步长为何被拒绝，缩放和初始化是否合适；模块开发者需要核对输入输出、规格关系和守恒残差；物性开发者则需要追溯组分、相态、计算条件、方法和参数版本。
RadishFlow 已将这些需求纳入开发者诊断规划。同一次失败可以先展示工程影响，再展开模型上下文、数值证据和实现详情。普通用户获得清楚的解释，开发者沿同一条记录深入调查，双方讨论的是同一次计算。
阅读深度也不能决定问题是否严重。若模块返回非有限值或违反接口要求，即使用户关闭开发详情，工程视图仍需显示相应影响。隐藏技术细节不会让无效结果变得可用。
一个典型场景是调整物性的二元交互参数。新参数可能降低拟合数据上的误差，却让独立验证数据表现变差，甚至使原本可收敛的案例失败。此时，只显示“参数调整成功”远远不够。
我们希望把新旧参数作为独立版本，在可比的输入、相定义与参考态下运行，分别展示拟合表现、验证表现和收敛覆盖。失败案例保留在比较中，让工程师看清改善与退化各自发生在哪里。
独立物性或模块实验也应能直接进入这套诊断路径。残差序列、参数差异和方程关系分别用曲线、表格与结构视图呈现；导数检查等额外试算作为明确的实验运行，避免暗中影响正式计算。
进一步，还可以按范围导出包含输入、版本、设置与已采集证据的诊断包。缺少外部物性包或专有数据时说明复现限制，让问题报告更容易交接，也为模型维护和第三方扩展提供基础。
概念界面三：拟合改善、独立验证与收敛退化分别呈现；全部案例和评价为虚拟示意。
在关键条件出现时，能够停下来检查。
如果工程师怀疑某个步骤之后的状态异常，未来更有价值的交互是设置观察条件，让运行在支持的边界停下，查看现场，再决定后续处理。
例如：“E-101 完成计算后，如果出口温度超过我设定的研究阈值，首次满足时请求暂停。”这条规则需要明确观察对象、变量、检查时机、触发方式和动作。
监视条件只负责观察与请求控制。它不能为了避免报错，自动把温度截断到某个值，也不能暗中替换模型输入。修改物理条件应作为明确的工程操作，由用户或已授权流程决定。
暂停本身也有技术边界。对于内部不可中断的求解或第三方调用，发出暂停请求之后，可能仍需等待执行器到达支持的停止位置。因此，界面必须区分“正在暂停”和“已暂停”；单步也要说明是模块步、循环步还是动态时间步。
这些模拟调试能力需要后台运行与控制协议支撑。观察值不自动构成可恢复检查点，改变物理输入后也不能默认继续原来的计算。
概念界面四：条件命中后请求暂停，等待执行器确认；示例阈值不构成实际工艺限值。
为自动化提供可理解的事实，也为人保留安静的工作区。
消息系统的另一项长期价值，是让脚本和未来 AI Agent 了解工程状态。
如果接口只返回一段“计算出错”的文本，自动化程序很难稳定判断对象、原因和允许采取的动作。结构化的问题身份、目标、运行范围、证据与建议动作，则能让不同消费者使用同一份事实。
未来 Agent 可以据此定位缺项、解释警告、组织修复计划，再经正式操作入口执行；执行前重新检查目标与输入版本，避免旧建议作用于已经变化的工程。解释中的数值和结论，也应能回到相应计算记录。
与此同时，人不应该被越来越密集的消息淹没。查看历史时，新事件不应不断把页面拉回底部；编辑参数时，普通消息不抢焦点、不清除草稿；筛选可以减少视图中的内容，但不会改变真实问题总量，更不能影响监视条件是否触发。
重要信息找得到，普通过程看得懂，用户才能持续完成手上的工作。
成熟模拟软件早已有消息和诊断工具，例如 CHEMCAD 用户指南区分错误警告、运行通知与备注。RadishFlow 想争取的特色，是将问题生命周期、执行证据、定位修复、模型验证和自动化贯穿起来，让工程使用与模型开发相互衔接。
我希望将来用户遇到失败时，能够更快提出有依据的下一步；看到成功时，也能理解这个结论的范围。消息系统做得越扎实，软件就越有条件帮助工程师把时间用在分析与判断上。
欢迎大家在评论区聊聊：你遇到过最难理解的模拟报错是什么？最希望软件补充哪一段计算过程？如果你开发过设备模块或调整过物性参数，又最缺少哪一种诊断工具？