设备界面的调整常常很小：一个参数标签换了位置，一个告警条增加了说明，或者把确认按钮移到更容易找到的地方。单看设计稿，这些修改很容易讨论；放回正在运行的界面，才会遇到输入、数据和状态一起变化的问题。Peter Schneider在Qt官方文章里介绍了QML实时预览工具，也说明了热重载的边界。兰亭妙微这次借这个话题，分享一套围绕设备参数页展开的评审思路。下文画面均为独立AI概念示意，讨论的是怎样观察界面，不是工具操作实录。
假设要调整一台设备的转速设置页，评审的起点可以是一条具体任务：操作人员读取当前值，输入目标值，核对单位，提交并确认结果。把任务写清楚，大家看预览时就不会只围着按钮颜色讨论。名称、输入区、范围说明、单位和提交入口之间的关系，也有了共同的判断依据。
AI概念示意：设备参数页中的单位、调整范围与未保存状态；不是Qt官方界面截图。
不妨先保留修改前的页面，记录设备名称、选中栏目、已有输入和窗口尺寸，再打开修改后的同一状态。这样比较时，变化集中在本次要解决的问题上。若两个版本展示了不同设备、不同数值和不同选中项，很容易把内容差异当成设计改进，甚至误判哪些信息被删掉了。
评审记录也可以小而具体。例如记下“范围说明被移到输入框下方，较长单位是否仍可读”，而不是只写“信息更清晰”。前者能指向一个画面和一个复查动作；后者往往需要下一次会议重新解释。对于经常交接给不同工程师维护的设备软件，这种记录方式尤其方便。
设备在线、数据正常时，界面里的很多关系并不显眼。可以再准备几个讨论用状态：连接暂时中断、数值尚未返回、输入超过允许范围，以及提交后仍在等待处理。每一种状态都问同一件事：使用者现在看到了什么，还能做什么，下一步应该等还是继续操作。
AI概念示意：离线设备、最后更新时间和恢复入口共同构成一个可讨论的异常画面。
例如离线以后保留上一次读数，本身不是完整说明。读数旁边需要表达它属于哪个时间点，当前是否还在刷新，以及哪些操作暂时不可用。这里讨论的是信息呈现，不是替系统决定设备控制策略。具体允许操作的范围仍应由产品、工程和业务负责人共同确认，再把决定落实到界面。
也要看看提示出现以后，原有任务是否仍有位置可找。顶部告警若把整张表格向下推，选中行可能离开视线；弹层如果遮住待核对的参数，用户就需要在多个画面之间记忆。预览的价值，在于把这些同时发生的变化放在一起观察，而不是孤立查看一张错误提示。
设备屏幕的可用空间可能与设计电脑不同。即使分辨率一致，系统缩放、触控键盘、外接面板和较长的设备名称也会改变实际阅读空间。与其只把窗口缩小看一眼，可以在紧凑尺寸里重新完成一次参数读取与提交，观察哪些关系在变化后仍然成立。
AI概念示意：同一任务表在紧凑和宽屏布局中的排布比较，不代表真实QML运行结果。
重点看最容易被挤掉的信息：单位是否与数值分开，按钮是否只剩图标，表头和表格内容还能否对应，以及详情面板打开后当前记录是否仍然可辨认。文字可以换行，但不要让任务名称被省略到无法区分。某些补充字段可以放到详情里，前提是读者知道入口在哪里。
这样的比较也能帮助设计与开发讨论取舍。有时不是把所有内容等比例缩小，而是调整优先顺序：保留识别设备和判断状态所需的字段，把次要说明移到有明确标签的区域。决定调整以后，再回到常用尺寸确认一遍，避免紧凑布局修好了，宽屏页面却出现另一套规则。
Qt原文说明该工具面向Qt 6.12及更新版本；多数QML修改可以在预览中观察，但C++、构建配置等变化仍可能需要重新构建或启动。这个边界值得记住：看到一扇预览窗口，不等于所有改动都已经在相同条件下验证，更不等于设备上的最终行为已经通过验收。
AI概念示意：预览重启后检查输入、选择项与操作结果；不是工具自动保留状态的承诺。
可以把评审证据整理成简短的一组：修改前后截图、当时的窗口尺寸、使用的示例数据、操作顺序，以及仍未覆盖的状态。若中途重启了预览，就重新检查输入是否保留、筛选是否仍有效、弹层是否回到正确位置。记录这些，是为了让下一位同事能够接着看，而不是只相信一句“我这里没问题”。
如果设计、开发和测试在不同时间查看结果，截图旁边还可以写上版本与修改范围。一个已经修正的旧问题，不应混在新截图里继续讨论；一个尚未复现的现象，也不要急着标为解决。把观察和结论分开记录，能让下一轮讨论直接从仍然存在的问题继续，而不是重新确认大家看到的是不是同一版界面。
一次小改动是否值得保留，最后仍要落到使用者的任务上。实时预览让观察更及时，但清楚的比较条件和状态记录，才让设计讨论可以继续向前。我们更愿意把它当成设计与开发共同检查界面的窗口，在其中看清变化、表达问题，再把确认过的结果带到实际设备验证。
