Engineering

——从 Journal 到真实环境验证：AI 降低的是实现门槛，而不是工程责任 上一篇文章中，我讨论了一个问题：工作经验在什么条件下，才能成为真正的资产？ 我以智能管路 PMI 标注为例，提出了一条转化路径：把任务提升为问题，把经验提炼为规则，把规则写入系统，再把系统沉淀为作品。 但那篇文章没有详细回答一个更具体的问题：当一个人并不具备软件开发经验时，他究竟怎样把自己脑海中的工程经验写入系统？ 因为在开始这项工作时，我对 NX Open 二次开发几乎一无所知。 我不熟悉 NX Open 的对象模型，不知道一个被鼠标选中的面，在程序中对应什么对象；不知道怎样通过代码读取组件名称、几何属性和中心线长度；也不知道应该调用哪些 API，才能在三维模型中创建带引线的 PMI 标注。 按照传统的学习路径，我似乎应该先学习 Python，再学习 NX Open，阅读开发文档，理解类、方法、Builder 和 Session，最后才有资格尝试开发插件。 但我最终走的并不是这条路径。 我没有先学会 NX Open，再开始解决问题。我先进入了一个真实问题，然后在不断解决问题的过程中，一点一点获得了完成下一步所需要的知识。 一、我不是从“学习开发”开始，而是从一个重复问题开始 我最初看到的，并不是一个软件开发项目。 我看到的是一组每天都可能重复发生的工程动作：在三维模型中找到一根管路，确认它对应的对象，查找名称，测量中心线长度，整理信息，再创建相应的标注。 完成其中一次操作并不困难。真正的问题在于，这些动作并不是只发生一次。车型变化、模型更新或者管路数量增加以后，同样的查找、测量、复制和核对还会再次发生。 于是，我开始问： 为什么每一根管路，都需要重新经历一遍近似的操作？ 如果工程师最终需要的结果具有相对固定的结构——名称、长度、对象信息和标注——那么这些信息是否可以直接从模型中读取？ 如果人工操作本身存在稳定步骤，那么这些步骤能否被软件重新执行？ 我当时还不知道具体应该怎样实现，但我已经知道自己想改变什么。 这一点后来变得非常重要。因为我虽然不懂 NX Open，却知道： 工程师实际会选择什么； 哪些对象是真正的管路； 哪些对象只是接头、管夹或附件； 哪些对象需要计算长度； 名称应该以什么形式显示； 什么结果对装配规范真正有用； 一个功能是否解决了现场问题。 换句话说，我缺少的是 Implementation Knowledge，也就是实现知识；但我并不缺少 Problem Knowledge，也就是问题知识。 AI 可以帮助我补充前者，但后者必须从真实工作中产生。 二、Journal 不是答案，而是让 AI 看见人的动作 NX 可以录制 Journal，把人在软件中完成的一系列操作，以程序代码的形式记录下来。1 于是，我产生了一个很直接的想法：既然我暂时不知道 NX Open 的正确写法，能不能先在 NX 中完成一次正确的人工操作，再把录制出来的 Journal 交给 AI 分析？ ...