工业计算工具让我换了一种写软件的方式

我大多数项目都是 Web 系统，但有一次 WPF 工业计算工具让我换了一种写软件的方式。

这个工具要解决的是汇流排切割计算。输入是定位点间距，输出是切割后的汇流排长度和安装位置。规则看起来很具体：长度要在 6 到 12 米之间，终端头和最近定位点要保持指定距离，首尾还有固定约束。目标也很明确：要么让汇流排数量尽量少，要么让某类长度尽量复用。

这类项目的难点不在页面复杂，而在规则必须算得清楚、结果必须能解释。

先把业务规则翻成约束

写后台系统时，我经常把业务拆成对象和流程；写这个工具时，第一步变成把业务规则翻成数学约束。

定位点、间距、可切长度、首尾位置、可行安装点，这些都不能只靠 if else 堆出来。它们之间互相限制：某一段长度变了，后面的安装位置也会变；某个切割点不合规，整套方案就不可用。

所以我把可选长度做成约束域，把可能的切割点范围也做成约束域，再用求解器去枚举可行解。这样代码表达的不是某个固定算法技巧，而是业务规则本身。

这个工具没有数据库，也没有复杂账号体系，但它并不简单。

使用者的真实工作流是 Excel。定位点数据从 Excel 导入，计算结果也要导出成 Excel。对这种工具来说，Excel 不是临时格式，而是业务现场已经习惯的协作方式。

我在实现时要处理模板导出、数据导入、计算后结果列表和再导出。软件的价值不是替代所有流程，而是把最容易出错的计算段接住，再把结果还给原来的工作流。

Web 系统经常强调权限、协作和长期维护。桌面计算工具更关心另一件事：使用时不要打扰人。

导入按钮、计算按钮、导出按钮、结果表格，这些交互要直接。计算开始时禁用按钮，结束后刷新结果，没找到可行方案就明确提示。它不需要复杂界面，但每一步都要让使用者知道软件在做什么。

这类工具的体验不靠视觉效果，而靠确定性。

工业工具最怕的是给出一个看似正确但没人敢用的结果。

所以结果里不仅要有切后长度，还要有安装位置；不仅要能在界面看，还要能导出。使用者需要把这些数据带回自己的图纸、表格或工艺流程里继续使用。

我也因此更重视“可解释的输出”。在业务系统里，可解释性可能体现在日志、状态和权限；在计算工具里，可解释性体现在每个结果字段是否能对应回现场规则。

这个项目给我的影响，是让我看到系统思维不只存在于 Web 平台。

一个小型桌面工具，同样要理解业务输入、约束关系、计算目标、用户工作流和交付方式。只是它的系统边界不在服务器、接口和数据库，而在规则、算法、表格和使用现场。

我现在看这类需求，会先问业务规则能不能被清楚表达，输入输出是否贴近真实流程，结果是否能被解释。只要这些问题回答清楚，小工具也能产生很实际的价值。