一点写软件的心得
本文摘要：（由ai生成）
团长作为CAE工程师，成功开发了基于ANSA的自动建模插件，简化车门刚度仿真计算。尽管实现了部分高级自动化功能，但面对车门结构变化时，插件出现问题。团长发现自动化建模适用范围有限，对变化敏感。他意识到，实用工具应解决实际工程问题，而非仅用于展示。团长从实践中认识到，灵活的小功能可能更实用。他的经验表明，在追求技术展示的同时，需关注工具的实际应用效果。
大家好，我是团长，一个爱写Code的CAEer。
团长日常的工作之一是做车门刚度仿真计算。2018年，为了能简化自己的工作（想多偷偷懒），特地花了3个月，加班加点，基于ANSA软件进行二次开发，做了个自动建模的插件。这个插件，其实就是把重复性的操作用代码来代替，然后整理好先后顺序，用一个个按钮来调用不同功能的代码，进而辅助建模，提高工作效率。写完后，意外发现还挺好用，推荐给其他几个做刚度计算的同事，都觉得挺好，然后我就屁颠屁颠地去申请了个软件著作权，觉得自己“车门刚度小王子”的称号实在是实至名归，一度飘飘然，甚至还骚情地吟了首诗发朋友圈。
到此，其实一切都刚刚好，直至后来，2020年，想要攀附“人工智能”高枝，欲实现“一键式自动化建模”。所想其实也非常简单，既然此前已经写了很多建模过程中的操作代码，那为何不把所有的操作都写出来，点一个启动键，所有的代码都运行一遍，剩下的就是等待整个模型搭建完毕呢？
想好就开始干，先整理好框架，写一个GUI界面，对整个建模过程进行分步，划分不同模块需要实现的不同的功能，剩下的就是一个一个功能代码写出来去填空，这一个一个的功能都变成了GUI界面上的一个个按钮、输入框、或者选择栏。最后综合起来，拿几个现成的例子测试代码，继而更新代码，不断迭代。
比如如何自动实现位移约束和力值加载？这涉及到自动定位，不能手动去点了，最简单的方法是通过提前设置的名称去识别，但这个太“不智能”了，我甚至想通过机器学习的方法来进行图像识别来找到位置，但实在是太复杂了，最后我折中选择了“直线逼近法”和“特殊筛选法”大致实现了自己的目的。
也比如如何能做多个选择？我希望这个代码能用来进行前门的建模，也能进行后门的建模，那自然有很多的不同在。所以在代码运行起来后，还得做选择题，那就是判断咯，你可能说，多写几个if语句不就行了？可是if语句判断的条件在哪儿呢？我还得在一键启动前就提示用户多做几个选择题，你这个是前门还是后门，你希望一键运行所有代码，还是有所选择性的运行哪几个？定位算法你想用“直线逼近法”还是“特殊筛选法”？等等。加班常有之，天昏地暗，头昏脑胀。那段时间，纯粹是自己的一点热情，想做点事情，虽然累，但看着一个个功能被自己写出来，总是有很多成就感在其中，竟然给坚持了下来，等经过两个案例的测试，竟然都成功了。
最近又开始搭建车门刚度模型了，2021年，等我再打开以前的小插件，竟发现不好用，因为竟然到处都是“八阿哥”，主要原因是门的结构和此前有非常大的不同，完全在我意料之外，导致软件中的很多算法都发生错误，这个时候，我竟然发现，第一版的辅助建模插件竟是无比好用。
自动化的条件实在是苛刻，任意一点的变动都可能导致一键式插件变成一键式垃圾，当然，这跟我这个插件的冗余性做得不好有关，所考虑的特殊性较少有关。我甚至发现，就算是在某些案例中能实现一键式自动化，但这个应用范围非常小，所以叫“车门刚度自动化建模软件”实在是太抬举它了，它应该叫“大众典型旋转车门常规线性刚度工况建模软件”，因为它处理不了斯柯达和奥迪的门，也处理不了滑动门、处理不了无框门、处理不了非常规的工况，更处理不了非线性模型。。。小小的一个门刚度，竟然还有这么多门道，你们大概想不到吧？
这么说来，此路实在是难走，“一键式”近乎破产。除了能拿来炫酷地展示下效果，于实际工程其实并无多大作用。反而是，某些非常“小”的功能，比较有实用性，因为人具有比较大的自由度，遇到问题能自主选择解决方案，这也就是为什么我反倒觉得第一版好用的原因。能解决实际工程问题的工具才是好工具，拿来展示的大都是“吹牛逼”。
