前言

这本书的起点是一份清单。

几年前，我开始把用 Qt 写的开源工业软件一个个收进仓库：FreeCAD、ParaView、QGIS、KiCad、3D Slicer、Gmsh，再加上一些不太出名但结构很有意思的项目。每收一个，附一张截图、一个网址、一句说明。清单解决的问题是“有没有”，用起来也方便，但它回答不了我真正想知道的事：为什么这些软件长成这个样子？为什么 FreeCAD 要把应用层和界面层拆成两个库？为什么 KiCad 坚持不用 Qt？为什么一个只有几万行的查看器也值得单独分析？

后来我意识到，答案不在功能列表里，而在约束里。几何内核的许可证、装配体的内存占用、现场机器的显卡驱动、团队对 C++ 标准的接受程度、客户内网能不能连外网，这些约束一层层叠加，最后才凝固成屏幕上那个窗口。功能是结果，约束才是原因。把约束讲清楚，比再列五十个项目有用。

三条主张

第一，工业软件的护城河在数据模型和内核，不在界面。 界面框架可以换，数据模型换一次要三年。书里会反复回到这条判断：读一个项目，先看它的文档对象怎么定义、依赖怎么传播、扩展点开在哪里，再看它的界面用了什么控件。这个顺序反了，学到的就只是皮毛。

第二，工程结构决定一个项目能走多远。 很多团队在功能还少的时候不觉得结构重要，等到插件多起来、新人多起来、构建时间从三分钟变成三十分钟，才发现目录和依赖已经理不清。第 5、6 章花了很多篇幅讲目录、模块边界、依赖方向和插件接口，因为这些决定不是“代码风格”，而是产品三年后还能不能改。

第三，AI 改变的是协作方式，不是工程判断。 2026 年的 Agent 已经能读仓库、改多文件、跑测试，能把很多重复劳动接过去。但它不会替你决定模块怎么切、许可证能不能用、性能瓶颈在哪。第 12 章讲怎么把 AI 放进 Qt 项目的日常流程，也讲哪些地方必须保留人工评审。

关于案例

书里的案例都来自公开仓库，章节中给出了地址。我对它们的描述基于公开的代码结构、文档和实际使用，不涉及任何未公开信息。项目在演进，截图会过时，接口会变，所以书里尽量谈结构和判断，少谈具体 API。

书中也用相当篇幅讨论我参与维护的几个开源库：SARibbon、QWT 分支、QIm、DAWidgets、QtPropertyBrowser、SAColorWidgets、qwindowkit，以及 data-workbench。写这些库时，我尽量把它们放回同类库里比较，讲它们补的是哪一块缺口、能力边界在哪里，而不是“我的库更好”。读者最终选谁，应该由约束决定，不由作者的偏好决定。

关于许可证

许可证信息来自仓库的 LICENSE 文件与公开页面的自动识别，可能有偏差。真正要做商业决策时，请以仓库中的许可证原文为准，必要时咨询法务。这本书不是法律意见，也不构成对任何项目的背书。

怎么用这本书

第一次读，建议按顺序。第一部建立坐标系，第二部搭工程基础，第三部处理架构、性能、稳定性和交付，第四、五部是查阅和前沿内容。已经做过大型项目的读者可以从第 5 章开始，遇到背景问题时再回头翻第 1、2 章。

代码示例大多是可编译的最小片段，少数长示例标注了“结构示意”。Mermaid 图用来解释机制，截图用来说明界面形态，两者都不能替代源码阅读。真正的验证入口，是每章给出的仓库和文档地址。

致谢

感谢这些项目的作者。他们中的大多数人在没有商业回报的情况下，把工业软件里最难的部分开放了出来。这本书能写的每一个判断，都建立在他们的工作之上。

也感谢 data-workbench 的用户和贡献者。书里关于工程结构、插件化、CI 和 AI Agent 的很多细节，是在维护这个项目的过程中被实际问题逼出来的，不是坐在书桌前想出来的。

---

尘中远 2026 年 11 月