做 RadishFlow 的过程中，我越来越在意一个问题：流程模拟软件的下一次进步，应该给工程师带来什么？
模型更丰富、计算更可靠，当然是长期要做的功课。但在实际工作中，我们还会花大量精力寻找参数、排查规格冲突、整理不同工况，或者解释一份结果为什么值得采用。这些工作连接着计算与决策，也决定了一款软件究竟有多好用。
我希望 RadishFlow 成为一个更智能、更容易上手，也能承接深入研究的流程模拟平台。它的特色，应当体现在工程师提出问题之后，软件如何帮助他把问题定义清楚、算明白，并形成能够复核和继续研究的结论。
围绕这个目标，我们明确了几项会影响项目长期形态的设计选择。这里想和大家分享的，就是这些选择背后的思考。
本文介绍 RadishFlow 的产品方向与规划。配图为 AI 生成的未来概念界面，图中数据、状态和布局仅供示意，不代表已交付功能。
第一项选择：让智能化从理解模型开始。
我期待的智能化，首先是一种很具体的体验：搭建模型时，软件知道还缺什么；发生冲突时，能够解释原因；计算失败后，可以帮助用户找到下一步。
例如，在进料和压力等条件确定、且没有额外可调变量的某种加热器计算模式下，热负荷和出口温度通常不能再作为两个任意独立的指定值。软件需要依据当前模式识别规格关系，指出冲突位置，并帮助用户选择保留哪项要求。
这比让用户反复修改输入、等待一次次失败，更接近专业工具应有的主动性。因此，RadishFlow 确定先建设基于模型和规则的建模辅助，再逐步引入 AI Agent。
其中一个重要的专业细节，是把输入就绪、规格完整性、结构自由度和数值诊断分开。必填项齐全，只说明输入层面的条件满足；变量与方程数量匹配，也不能单独证明模型可解。常见的自由度计数有明确范围，例如 IDAES 的相应工具按参与活动等式的未固定变量与等式数量计算，并不包含不等式约束。
RadishFlow 希望进一步把这些分析转化为用户能采取的动作：定位欠指定的对象、解释互斥规格、提供合法修改路径；进入数值层面后，再检查初始化、缩放、残差与奇异性等问题。
这种设计的优势，是让专业知识直接参与操作过程。新手可以少走试错弯路，熟练用户也能更快缩小排查范围。软件给出的每项建议，都应当说明依据、适用条件和准备修改的内容。
第二项选择：围绕工程任务重新组织界面。
功能越来越多时，界面很容易变成越来越长的菜单。RadishFlow 已经确定重新评估功能分区，让工作区跟随工程任务展开。
用户可以从分析物性、计算一台设备、搭建流程或比较工况开始。独立设备任务应有合适的工作空间，流程图则服务于需要观察连接与系统关系的工作。它们通过共同的工程对象和数据关联起来。
以“现有冷却系统能否适应夏季工况”为例，工作区应该先明确研究目标、固定设备、允许调整的操作量，以及需要覆盖的条件，再组织输入、计算和比较。用户始终知道自己在研究什么，也知道哪一步尚未完成。
这里的低门槛来自信息组织。初学者先看到必要输入、缺项和建议动作；有经验的工程师继续展开假设、模型方法与诊断细节。两种阅读深度使用同一个模型，专业能力随着任务需要逐步呈现。
未来界面的吸引力，就在于它既能让简单问题更快完成，也能为复杂问题留下充分的分析空间。
第三项选择：把工况、设备与设计依据连成一个整体。
设备工程已经成为 RadishFlow 的独立规划主线，可以随着稳态模型成熟逐步推进。我们关心的重点，是设备计算如何与整个工程研究保持连续。
设计新设备时，几何可以是待确定的结果；评价已有设备时，则应固定已选几何，观察它在不同条件下的表现。设备可以独立研究，也可以引用流程中的工况，两种路径复用相应的物理定义与计算能力。
设想我们考察一台换热器：夏季冷却水条件可能限制出口温度，某个高流量工况可能限制压降，结垢条件又会改变传热表现。软件应帮助工程师看清每项约束由哪个工况控制，候选方案之间分别有什么权衡。
对于分离器，气相处理能力与液体缓冲要求也可能由不同工况控制。因此，不能简单把所有输入的最大值拼成一个“最坏工况”，更不能让每个工况分别选出一台设备，就认为某一台设备满足全部要求。
RadishFlow 规划中的工况矩阵，将围绕同一研究对象保留完整条件组合，汇总各项约束及控制工况。压力边界和公用工程条件也进入研究，使设备性能能够放回系统中审视。
这条路线还包括目标反算：在给定设备与约束下，为达到目标出口条件，需要怎样的操作参数？软件应明确目标、可调变量、范围与求解记录，并区分可行解、经过相应验证的最优解，以及尚未找到解的情况。
这些能力的组合价值，是把“算一次设备”发展成“研究一个工程方案”，让设计、校核、调整和比较能够相互衔接。
第四项选择：让结论自带依据，让变更显露影响。
模型算出一个数值之后，工程师还要回答：采用了什么条件？数据来自哪里？哪些是假设？条件改变以后，这个结果是否仍然适用？
RadishFlow 将工程设计基础、输入来源和结果追溯放进同一条规划主线。公共冷却水条件由项目统一定义，相关设备引用它；某个工况需要特殊条件时，显式记录覆盖值与理由。
当公共条件发生变化，软件应识别受影响的设备和计算记录。工程师可以直接审阅影响范围，减少逐个文件排查与人工同步的负担；历史记录则保留当时的条件，方便解释方案演变。
结果页面也应当能够回到有效输入、模型与物性数据版本、关键假设和运行设置。供应商数据、文献参数、关联式估算与用户假设，应保持各自的来源身份。
这会改变交付物的价值。一份计算表能够带着假设、来源、适用范围和未解决问题一起交接，下一位工程师便有条件复核和继续研究。
工程检查也要有足够的分辨率：数值收敛、物料与能量收支、模型适用性、设备约束分别呈现。收敛容差不能替代数据不确定度，增加小数位也不会让估算参数变得更可靠。
我希望这种可追溯性成为日常体验，让用户在关键决策前，更容易发现一个尚未确认的前提，或者一个已经失效的结果。
第五项选择：让人、脚本和 Agent 使用同一套工程能力。
对于经常写程序做流程模拟的朋友，这可能是 RadishFlow 最值得期待的方向之一。
我们的长期选择，是以统一的变量与动作入口表达软件能力。程序需要能够发现对象、识别可调整变量、查询前置条件、提交操作，并读取有明确来源的结果。图形界面、自动化脚本和未来 Agent 都基于这些能力工作。
这样的结构，有机会缩短手工探索与自动化研究之间的距离。工程师先完成一次研究，再把其中有明确工程含义的操作录制下来，整理成可编辑、可参数化的流程，用于重复工况或后续项目。
录制内容应保留“修改哪个参数、建立哪条连接、运行哪个工况”的含义，使研究流程能够被阅读和检查。自动化遇到不兼容对象或失败步骤时，也应留下明确的执行记录。
未来 Agent 可以在这套基础上理解意图、组织计划和解释结果。例如用户提出：“比较三个冷却水工况，保持已选设备不变，列出不能满足要求的情况及原因。”Agent 应能先呈现工况与操作范围，再调用正式计算能力，最后把解释关联到具体记录。
候选建议与已采纳方案有明确区别，影响工程假设的修改能够被审阅，常规重复任务则可以在授权范围内自动执行。工程数值来自计算模型，语言模型负责协助组织和理解。
这样的智能化更容易融入专业工作，也为批量研究、外部工具联动和经验复用留下空间。
第六项选择：让模型随着研究深度持续扩展。
RadishFlow 的长期定位是可扩展流程模拟平台，覆盖方向包括稳态、动态、瞬态以及间歇与半间歇过程。我们希望已有工程数据能够在不同研究中继续发挥作用。
例如，设备几何可以支撑后续动态建模，但动态任务仍需明确积存、初始状态、压力与流量关系、控制和事件等条件。设备容积也不能直接替代操作持液量。这些补充要求应由软件清楚表达，帮助用户理解研究范围发生了什么变化。
在求解组织上，规划保留递归分块、序贯模块、联立模块与联立方程等方向，依据模型的表达能力和耦合关系逐步选择、验证。物性、设备模型与工程任务明确各自职责，也为专用模型和插件扩展提供基础。
可扩展性的价值，最终要落到用户身上：新增模型能够进入已有的工况、诊断、自动化和结果体系，一次研究形成的数据与经验，可以成为下一次研究的起点。
这些选择共同构成了 RadishFlow 想争取的差异化：更主动的建模辅助、更连贯的工程研究，以及更容易复核和复用的自动化。
行业中已经有很好的探索，例如 Aspen Multi-Case 的多场景分析，以及 DWSIM 通过自然语言和工具调用操作模型的 AI 助手。RadishFlow 的创新取向，是从平台设计阶段把上述关系贯穿起来，形成一致的使用体验；这也是我们未来需要通过实际产品证明的优势。
我期待它帮助工程师把更多时间用于理解过程、比较方案和作出判断，让软件承担更多重复操作、关系检查和记录整理。
也欢迎大家在评论区留下建议：你最希望流程模拟软件增加什么功能？哪些工作仍需要频繁切换 Excel、脚本和模拟器？哪一种报错或重复操作最耽误时间？
最好带上一个具体场景，说明现在怎么做、困难在哪里，以及你希望软件怎样帮助你。一个清楚的工程问题，往往比一句“加入 AI”更能推动产品进步。
有价值的建议会进入 RadishFlow 的需求评估。如果你的建议被采纳，并对功能设计或实现产生实质帮助，未来有机会受邀加入项目贡献者名单，经你同意后署名致谢。
希望 RadishFlow 的未来，也能留下大家参与设计的痕迹。