夜雨聆风从事工业软件这些年，我越来越觉得一件事：工业软件研发的难，不是"能不能做"，是"能不能用"。
这两个的差距，用一个词就能概括：非确定性。
什么是"非确定性"
工业软件跑在真实工程里。真实的工程数据是什么样的？
一条线，用户画歪了0.001度。一个圆，半径被算成了1e-9而不是0。一个装配体，有10万个零件，其中一个被轻微改动。求解器迭代了1000次还没收敛。
这些不是bug，这是"真实世界"。
对于技术人员，天然喜欢"确定性"——输入A，输出B，中间可复现。但工业场景里，确定性只是特例，非确定性才是常态。
这件事，决定了工业软件研发的四个方面。这四个方面，不是四件事，是同一件事的四个角度。理解了这个，其他都是方法论。
第一个方面：你永远不知道用户会给你什么输入
这件事，说起来简单，做起来要命。
正常输入，谁都能处理。让人头疼的是"非标准输入"。
比如"画圆"这个功能。你做demo的时候，输入是标准的：圆心(x,y)，半径r。但实际工程里，用户可能输入了"圆心在无穷远""半径为负""圆退化为点""两圆刚好相切导致后续计算遇到奇异点"……
这些输入，不是用户"故意刁难"，是真实工程里就是会出现的。
真正把工业软件做起来的团队，有效测试集都是上万条起步，而且每个版本都在加。这件事没有捷径，就是"测出来的"。
不重视这件事的公司，做不好工业软件。这句话听起来绝对，但我越来越相信。
测试集的厚度，就是对"输入非确定性"理解厚度的直接体现。每加一条测试，就是多理解了一种"非标准输入"的形态。
第二个方面：数值计算本身，就是非确定的
这件事，做求解器的人最有体会。
求解器迭代求解时，偶尔会碰到一种尴尬情况：迭代忽然"飞了"，怎么也收不敛。
一个典型场景是：两条曲线刚好相切，雅可比矩阵秩亏，条件数急剧变大，数值上等同于"接近奇异"。这种情况，叫奇异点。
但"飞了"不全是奇异点导致的。步长太大、初始值太差、浮点误差累积……都可能让迭代发散。奇异点之所以难搞，是因为它让雅可比"几乎不可逆"，哪怕算法没问题，数值上也可能翻车。
处理奇异点没有银弹。有的团队靠"重置初始值"，有的靠"步长控制"，有的靠"切空间投影"。每种方法都有适用场景，都有坑。
有的求解器，处理奇异点的策略有二十多种。但即使这样，在某些"罕见但真实"的输入下，还是会崩。
为什么？因为奇异点的"形态"是无限的，你无法枚举完。
这件事的本质，是工业软件的"非确定性"在数值层面的体现——你永远不知道下一次迭代会不会飞。
目前国际上主流的几何内核，不是因为他们代码写得漂亮，是因为他们对"数值非确定性"的理解，比大部分团队都深得多。这种理解，不在论文里，在几十年的工程实践里。
第三个方面：规模变大时，非确定性是指数放大的
这件事，最容易被人忽略。
一个功能，处理10个零件没问题，处理1000个可能还行，处理10万个可能就崩了。但崩的原因，往往不是"性能不够"，而是"非确定性累积"。
具体来说：
一个微小的数值漂移，在10个零件时可以忽略。在1000个零件时，可能被放大成"装配约束冲突"。在10万个零件时，可能变成"求解器不收敛"。
这件事最可怕的地方在于：它在小规模测试时完全发现不了。
我观察到的现象：很多团队把"性能优化"和"稳定性"分开做。但实际上，规模带来的问题，一半是性能，一半是非确定性累积。只做性能优化，不做"数值稳定性控制"，规模上去了还是会崩。
第四个方面：长时间运行后，"不崩但错"最可怕
这件事，叫**"Silent Error"**——静默错误。
用户不害怕"崩"。"崩"至少知道有问题。用户最害怕的，是"不崩但错"。
举个例子：
一个奇异点，可能导致一次微小的数值漂移。一次数值漂移，可能被后面的计算放大。放大到一定程度，系统进入"虽然没崩但已经错"的状态。用户不知道，但错误已经在那里了。
稳定性测试要抓的，不只是"崩不崩"，还有"错不错"。后者比前者难十倍，因为它需要对"非确定性"的系统化理解，而不只是"多跑几个小时"。
长时间压力测试、长周期内存监控、极端输入下的行为——这些事情，本质上都是在跟"时间的不可靠"作战。
四个方面是叠加的
简单总结一下。
输入的不可预知，带来数值的不稳定。数值的不稳定，在规模放大时变成累积性问题。规模的累积性，在长时间运行后变成时间的不可靠。
这件事，国外工业软件比我们做得好，不是因为他们"功能多"，是因为他们对这四个方面的理解，比我们深太多。
这种理解，不在论文里，在"客户案例库"里。每遇到一个奇异点，每处理一次过约束，每修复一个静默错误——这些都是"对非确定性的理解"在增厚。
我们能做什么
我觉得核心是一件事：让"对非确定性的理解"，变成团队的资产，而不是个人的直觉。
具体来说：
测试集的厚度，就是对"输入的不可预知"理解厚度的直接体现。
奇异点处理策略的丰富度，就是对"数值的不稳定"理解深度的直接体现。
大规模场景下的数值稳定性，就是对"规模的累积性"控制能力的直接体现。
长时间压力测试的覆盖度，就是对"时间的不可靠"对抗能力的直接体现。
这四件事，说到底，都是在把"对非确定性的理解"，从"个人直觉"变成"团队资产"。
工业软件的差距，从来不是"功能数量"的差距，而是"对非确定性理解深度"的差距。
这个深度，是靠时间堆出来的，没有捷径。
我们能做的，是接受这个事实，然后在每一个版本里，让这个深度，尽可能厚一点。
