做流程模拟时，我们经常遇到一种很小、却反复消耗时间的麻烦：明明知道自己要找哪个参数，却不知道它藏在哪一页。
想检查所有加热器的出口温度，要逐个打开设备；想比较几股物流的压力，要在画布和结果表之间来回切换；准备写一段自动化脚本，又得重新寻找这些量在接口中的名字。
当流程变大，寻找参数本身就成了一项工作。更棘手的是，找到一个数以后，还要判断：它是指定值还是计算结果？属于哪次输入？现在能不能修改？
最近规划 RadishFlow 的变量浏览器时，我越来越觉得，这个看似普通的面板，能够把模型、工程操作与自动化连接起来。关键在于，它能否让每个变量的含义和使用方式都清楚可见。
本文介绍 RadishFlow 的变量与对象浏览器设计。项目已有只读浏览、搜索、对象定位及统一单变量写入基础；双视图工作区、稳定路径、关注列表和批量编辑等仍属规划。配图为 AI 生成的概念示意，数值与布局不代表实机运行。
找到变量，是理解模型的第一步。
这次讨论从 OLGA 和 Aspen Plus 的使用体验开始。
OLGA 的 Model Browser 给我的启发，是把查找与工程对象的上下文联系起来。2016.1 官方发布说明中，搜索结果支持单击查看对象属性，双击让流程图居中到对应对象。找到一项内容后，用户可以直接回到它所在的工程位置。
Aspen Plus 的变量树则提示了另一层价值：软件内部的数据结构，可以成为用户能够探索的模型地图。其 10.1 版原厂指南区分了面向表单操作的 Data Browser，以及展示底层变量、节点路径和属性的 Variable Explorer；后者在该版本中不能直接修改变量值，路径可供 Automation 使用。
这些历史资料帮助我们理解设计机制，并不代表最新版的完整行为。RadishFlow 希望结合两种思路：让工程师按熟悉的对象找参数，也让程序通过明确的身份访问同一个变量。
一个工作区，容纳两种寻找方式。
多数时候，工程师想的是“检查一下加热器”，并不会先想到一串路径。因此，我希望默认的工程视图按单元、流股及后续接入的物性、设计基础等类别组织内容。
搜索“出口温度”，就能集中看到相关对象，分清输入与结果；筛选“未指定”，就能找到需要补充条件的位置。选中一行后，可以定位到流程图和具体字段，也可以从设备面板反向打开对应变量。
需要写脚本或深入检查时，再切换到变量树，沿对象、输入或结果、具体字段逐层展开，查看说明、约束与访问方式。两种视图共享同一份选择，用户不必重新寻找刚才的对象。
浏览器还应覆盖画布以外的工程内容。组分、物性方法、公共设计条件未必适合画成设备，却同样影响计算。它们应随各自领域能力接入，并跳转到合适的页面。
当对象扩展到组成、塔板数据或时空结果时，浏览方式也要保留相应的维度。组分名称、相态、时间和位置不能在一张长表中丢失。未来可以按需展开或读取切片，让用户知道自己正在查看哪个范围，避免打开目录就加载全部数据。
我希望这个工作区可以常驻，和画布、检查器一起使用。这样，检查一组参数就能成为连贯的操作，而不必反复打开、关闭窗口。
图一：搜索、输入与结果区分、字段定位和关注入口协同呈现。界面及示例数值均为设计示意。
名字可以修改，变量的身份应当稳定。
假设一台设备最初叫 H-101，后来改名为“原料预热器”。工程师会认为它还是原来那台设备，之前加入的关注项、报告引用和脚本关联也应该继续有效。
如果引用只保存显示名称，重命名就可能破坏关联；两个对象恰好同名，还可能让程序找错目标。因此，RadishFlow 已有的变量身份由文档、对象、输入或结果分区及字段共同确定，显示名称不参与身份。
在这个基础上，未来的路径负责帮助人和程序找到变量。人可以阅读“主流程／单元／原料预热器／输入／出口温度”，持久引用则绑定稳定身份。具体公开路径语法仍需设计，不能直接拿界面文字当协议。
同名时明确指出歧义，对象删除后明确提示引用失效，也很重要。尤其不能在删除后新建了同名设备，就把旧引用悄悄接过去：名字相同，研究对象未必相同。
另一个维度是读取上下文。未来，同一设备在夏季和冬季工况中可能有不同的出口状态。变量身份回答“哪个量”，工况与运行记录回答“在哪组条件下得到的值”。脚本应明确指定这些条件，避免结果取决于用户恰好打开哪个页签。
图二：显示名称、稳定身份与读取上下文分别表达不同含义；路径协议和多工况访问仍属规划。
一个数值，需要带着来源一起出现。
在表格中看到“90 ℃”，还不足以判断怎样使用它。这可能是工程师指定的出口温度，也可能来自上一次求解；输入已经变化时，后者甚至不再适用于当前模型。
因此，变量浏览器需要同时表达值、单位、来源与状态。尚未指定、没有结果、结果过期和数值为零，要有清楚的区别。用零补齐空表格，虽然整齐，却可能把“没有答案”伪装成一个有效答案。
关注列表也应该遵循这个原则。用户收藏的是变量引用及显示偏好，每次查看时再读取相应状态。如果收藏时复制一份数值，列表就容易变成另一份需要人工维护的数据。
未来衔接工程基础与工况后，浏览器还应说明一个条件来自公共基础，还是某个工况的显式覆盖。准备修改时，用户能看清自己改的是哪一层、哪些研究可能受到影响。
这样，工程师整理报告、比较方案或排查异常时，就更容易从一个数字回到产生它的条件。这也是我希望变量浏览器与消息系统、结果页面共同建立的体验。
集中编辑，需要完整的工程规则。
把参数集中成表格，很容易让人联想到 Excel。但模拟模型里的字段经常存在关联：某个量允许输入，不代表当前计算模式允许把它作为独立规格；组成、压力和热负荷，也各有相应约束。
所以，规划中的表格编辑会复用正式修改入口，执行单位转换、版本检查、草稿保护与领域校验。检查器和浏览器里修改同一个参数，应该得到一致的结果或拒绝原因。
仅改变显示单位，也要与修改物理条件区分。例如 90 ℃ 显示成 363.15 K，实际温度没有改变，无需因此让求解结果过期；把它改为 95 ℃，才是一项新的工程输入。
批量编辑则需要更明确的行为。假设同时调整多台加热器，其中一项不符合约束，用户需要知道整个请求如何处理。我们的规划是先检查完整修改集合，成功后一次提交、一次撤销；任一项失败，全部不落地。
这也意味着，批量编辑不能简单地循环调用若干次单值修改。相关字段可能必须一起校验，失败时不能留下用户没有预料到的半套参数。
图三：规划中的批量编辑先明确拟修改值，再整体校验与提交。该能力尚未实现，示例不代表实际计算。
让手工探索，能够自然延伸到自动化。
对于写程序做模拟的人，变量树最有吸引力的地方，是能把手工查找的结果交给脚本继续使用。
工程师在界面中找到目标，查看量类型、单位、约束和可写条件，再复制引用。程序通过同一套描述发现能力，通过正式命令修改输入，通过明确的结果身份读取输出。界面与脚本就有了可以共同核对的对象。
未来 Agent 也可以建立在这层基础上。例如用户提出：“找出未指定出口温度的加热器，整理需要我补充的条件。”系统可以先查询变量和状态，再组织解释，而不用仅凭界面文字猜测缺项。
若进一步要求调整参数，Agent 仍需明确目标、依据和影响，并在授权范围内调用正式入口。已有草稿、输入版本冲突或领域约束，不应因为操作来自 Agent 就被绕过。返回的数值仍然来自计算模型，语言模型负责协助组织与理解。
这里值得期待的价值，是手工探索与自动化研究使用一致的工程含义。一次交互中弄清楚的参数关系，能够继续用于重复计算、工具集成和研究流程复用。
统一入口也需要明确范围：公开工程变量由所属模型提供说明和访问规则，浏览器负责组织与呈现。模型内部的临时计算量，不会因为技术上能读到，就自动成为允许修改的公共参数。
从一个可靠的小闭环开始。
变量浏览器的功能可以列很长，我更愿意先用一条完整路径判断它是否好用：搜索出口温度，分清输入与结果，定位一台设备，修改并撤销，重新运行，再查看关注变量；保存重开后，关联仍然正确。
RadishFlow 已有的浏览与统一写入为这条路径提供了基础，但当前浏览窗口仍然只读。接下来需要逐步补齐工作区、稳定路径、关注与受控编辑，再随领域能力扩展工况和多维结果。
对我来说，这项设计想争取的优势，是让用户在找到变量之后，可以顺着它理解模型、检查依据、完成修改，并把工作继续交给程序。每一步都能回到同一个工程对象，软件才更容易成为持续研究的工具。