我完全不会 NX Open，却用 AI 做出了第一个功能性插件

——从 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，把人在软件中完成的一系列操作，以程序代码的形式记录下来。¹

于是，我产生了一个很直接的想法：既然我暂时不知道 NX Open 的正确写法，能不能先在 NX 中完成一次正确的人工操作，再把录制出来的 Journal 交给 AI 分析？

这个想法后来成为整个项目的起点。

我先录制一个很小的动作，例如选择某个对象、执行一次测量，或者创建一种 PMI。然后把 Journal 交给 AI，告诉它：

• 我刚才在 NX 中做了什么；
• 最终想实现什么；
• 哪些代码可能只是录制过程产生的冗余；
• 哪些步骤需要被提取成可以重复调用的逻辑；
• 下一步还缺少什么信息。

AI 分析完代码以后，会告诉我：为了继续完成某项功能，还需要知道对象选择是怎样发生的，中心线是怎样生成的，属性从哪里读取，或者 PMI 是通过什么方式创建的。

于是，我再回到 NX，再录制一段，再交给 AI，再运行新代码，再观察它究竟做了什么。

整个过程不是“一句话生成一个插件”，而是一个不断往返的循环：

现场问题 → 人工操作 → Journal 记录 → AI 分析和生成 → NX 真实运行 → 错误与结果反馈 → 继续补充 Journal → 系统迭代

有时，AI 会错误理解 NX 中的对象关系。有时，录制出来的代码包含大量与当前模型、文件路径和临时对象绑定的信息。有时，代码能够运行，却读取了错误的名称。有时，某条技术路径在理论上成立，放进具体版本的 NX 后却无法使用。

这时，我需要重新回到现场，观察问题究竟发生在哪里，再决定应该补充什么操作、日志或对象信息。

因此，真正推动插件向前发展的，并不是某一次特别聪明的 Prompt。

而是人的动作和问题意识持续进入这个闭环。

三、我没有逐行写代码，但我实际上一直在写 Specification

这段经历让我重新理解了 Coding。

过去，我们通常把 Coding 理解为：掌握一门编程语言，按照语法逐行编写源代码。

在 Lex Fridman 与 Jensen Huang 的访谈中，Jensen 将 Coding 描述为对软件意图、规格乃至架构的说明，并明确说过：“Writing a specification is coding.”²

回头看这次开发过程，我虽然没有独立写出每一个 NX Open 类和方法，却一直在提供不同形式的 Specification。

1. 问题规格

我首先需要说明，这个插件究竟要解决什么问题。

它不是笼统地“自动标注管路”，而是：工程师选择一个管路对象后，系统需要判断对象类型，找到正确的数据来源，读取名称，决定是否计算中心线长度，再按照统一形式生成相应的 PMI。

如果问题本身没有被拆清楚，AI 就只能根据一句模糊的要求猜测。

2. 行为规格

Journal 记录的，是一个正确操作在 NX 中怎样发生。

我用自己的动作告诉 AI：

• 什么对象需要被选择；
• 什么命令能够得到目标结果；
• 软件内部会创建哪些中间对象；
• 一个正确的 PMI 是怎样生成的。

Journal 因而不只是“参考代码”，更像是一份 Behavioral Demonstration。它把过去难以用语言完整描述的操作经验，转化为 AI 可以分析的行为证据。

3. 错误规格

当生成的代码无法运行、识别错误或者导致软件异常时，这些失败同样提供了信息。

每一次错误都在说明：

• 某个对象类型判断不成立；
• 某个 API 与当前版本不兼容；
• 某项信息不能从原先设想的位置读取；
• 某种几何提取方法存在边界；
• 某个异常情况此前没有被考虑。

错误不是开发过程之外的意外。错误本身也是系统规格的一部分。

4. 验收规格

最终，只有理解现场的人才能判断：

• 选择这张面以后，程序是否找到了正确的管路；
• 这个名称是否符合业务使用习惯；
• 得到的长度是否可信；
• 接头和管夹是否被错误地当成管路；
• 标注是否便于阅读；
• 模型变化以后，原有信息应当怎样更新。

代码能够运行，只说明语法和部分逻辑成立。它有没有解决问题，则需要领域判断。

因此，我并不是把开发完全交给 AI。

更准确地说，我负责定义问题、提供行为、反馈错误和验收结果；AI 负责解释代码、寻找接口、生成实现并协助修正；NX 的真实环境负责告诉我们，前面的假设究竟是否成立。

这是一个 Human–AI–Environment Loop：人决定方向，AI 扩大实现能力，环境提供真实反馈，再由人决定下一步。

四、AI 改变了学习的顺序

传统的学习模式通常是：

学完基础知识 → 掌握工具 → 完成练习 → 最后尝试解决真实问题

这条路径仍然有价值，尤其适合建立完整的知识体系。但它也有一个明显问题：学习者可能投入很长时间，仍然没有完成第一个真实结果。

我这一次采用的路径则是：

先找到真实问题 → 完成最小操作 → 暴露知识缺口 → 学习完成下一步所必需的内容 → 立即回到真实环境验证

这是一种 Just-in-Time Learning。

我不需要在开始之前理解整个 NX Open 对象模型，但我必须理解当前失败与哪一个对象有关。我不需要先记住所有 API，但我必须知道眼前这段代码为什么读取了错误的信息。我不需要在项目开始时设计出完整架构，但随着不同类型的管路、组件和非管路对象出现，我必须逐渐建立更稳定的分类规则。

学习没有消失。

它只是从“获得行动资格之前必须完成的准备”，转变成了“在解决真实问题时持续发生的过程”。

更准确地说：过去是先学习，再行动；现在也可以先行动，让真实问题决定下一步需要学习什么。

五、为什么 AI 对初学者的帮助可能尤其明显？

Erik Brynjolfsson、Danielle Li 和 Lindsey Raymond 在发表于 The Quarterly Journal of Economics 的研究中，分析了 5,172 名客服人员使用生成式 AI 助手后的工作表现。研究发现，AI 使每小时成功解决的问题数量平均提高约 15%，但收益分布并不平均：经验较少、技能水平较低的员工改善更明显。任职两个月且使用 AI 的客服人员，表现达到或超过任职超过六个月但未使用 AI 的人员。研究者提出的解释之一是，AI 有可能把高绩效员工原本分散、甚至没有被明确写下来的做法，传播给其他员工。³

客服工作当然不等于 NX 二次开发。这项研究也不能直接证明所有初学者都能够依靠 AI 快速成为软件工程师。

但它为我的经历提供了一个很有价值的解释视角：AI 最先压缩的，可能不是专家之间的差距，而是初学者获得已有经验的时间。

以前，我遇到一个 NX Open 问题，可能需要先找到熟悉该接口的人，再让对方理解我的业务场景，或者花费大量时间搜索零散资料。现在，Journal、日志、自然语言要求和运行结果，可以被放进同一个对话中。

AI 未必一次给出正确答案，但它能够帮助我：

• 解释看不懂的代码；
• 找出可能有用的对象和接口；
• 判断还缺少哪些上下文；
• 把一次人工操作抽象成函数；
• 根据错误日志提出新的排查路径；
• 在不同实现方案之间建立比较。

这并没有让我瞬间拥有资深 NX Open 开发者的知识。但它明显缩短了从“完全不知道下一步做什么”，到“知道下一项应该验证什么”的距离。

而对于一个初学者而言，最大的障碍往往并不是不知道最终答案，而是不知道下一步应该做什么。

六、Job、Task 和 Tool 并不是同一件事

Jensen Huang 在那次访谈中做了一个非常重要的区分：一份工作的目的、组成这份工作的任务，以及完成任务所使用的工具，彼此相关，但并不是同一件事。²

他以软件工程师为例指出，软件工程师存在的目的不是生产尽可能多的代码行。真正的工作包括解决问题、诊断问题、协作、评价结果、发现新的问题以及进行创新。手工 Coding 只是其中一项 Task；当工具变化时，工作的目的未必随之消失。

这个区分也可以放到我的工作中。我的 Job 从来不是“用鼠标测量管路长度”。真正的工作是：确保工程设计和装配所需要的信息准确、清楚、可追溯，并能够在模型发生变化后得到正确维护。

在这个 Job 下面，曾经存在很多 Task：

• 找到对应管路；
• 查找名称；
• 测量长度；
• 复制信息；
• 创建标注；
• 调整显示位置；
• 重新核对更新后的模型。

NX、Journal、NX Open、Python 和 AI 都是 Tool。

当工具能够承担查找、测量、整理和生成标注的一部分任务时，它并不意味着工程责任也被自动交给了工具。

相反，人的工作开始向更高一层移动：

• 什么才算需要标注的业务对象？
• 不同管路形式应该怎样统一分类？
• 什么对象具有“可测量长度”的能力？
• 数据源发生冲突时应该相信什么？
• 哪些情况必须阻止自动生成？
• 如何确保结果可以被更新和维护？

原来，我更多是在流程中执行动作。后来，我开始尝试设计这个流程。

这就是从 Task Executor 向 System Designer 的移动。

七、“Go use AI”不是对失业焦虑的完整回答

在访谈中，Jensen 给出了一个非常直接的建议：“Go use AI.”² 但这句话不能被理解为：只要一个人使用 AI，就不需要再担心自己的工作。

Lex Fridman 在对话中专门停下来谈到了另一面：每一次具有变革性的技术到来，都可能给具体的人和家庭带来真实痛苦。岗位消失、收入中断和职业路径被打乱，并不能被一句技术乐观主义轻易带过。² 这一点必须被保留。

个人积极使用 AI，是一种行动策略；但它不是解决结构性失业、收入分配和社会保障问题的完整政策答案。

并不是所有人都拥有相同的学习时间、工作自主权和试错空间。也不是所有岗位都一定会因为 AI 变得更有趣、更高薪或者产生更多需求。

所以，我不会从自己的经历推出一个简单结论：我能够借助 AI 做出插件，因此所有人只要足够努力，就不会被 AI 影响。

更加诚实的结论是：在仍然拥有行动空间的情况下，主动学习怎样与 AI 协作，通常比等待工作边界被别人重新定义更有利。

“Go use AI”的意义，不是保证结果，而是要求我们不要只站在工具外面想象它将怎样改变自己。进入真实问题，使用它，观察它擅长什么、会在哪里失败，再逐渐建立自己的判断。

八、Jason Fried：很多软件并不是从技术理想开始，而是从真实痛点开始

Jason Fried 在讲述 Basecamp 的起源时，并没有把它描述成一次凭空出现的伟大产品构想。37signals 当时还是一家设计公司。随着同时进行的项目增多，团队原有的协作方式开始失效。他们并不是缺少设计能力，而是缺少一种适合自身工作的方法和工具，于是先为自己搭建了项目管理系统。后来，客户看到这个内部工具，发现自己也面临相似问题，Basecamp 才逐渐从内部解决方案变成独立产品。⁴

我的 PMI 插件与 Basecamp 当然不在同一个规模，也不能简单地把企业内部工具包装成个人产品。具体模型、代码、数据和业务信息仍然受到明确的知识产权与保密边界约束。

但 Jason Fried 的经历提醒了我一个重要事实：有价值的软件，未必从“我要做一个软件”开始。它往往从“我每天都在承受这个问题”开始。

领域工作者拥有一种软件开发者未必天然拥有的资源：他长期处在问题内部。他知道哪些操作只是偶尔麻烦，哪些问题每天都在重复；知道什么功能看起来先进却没有实际价值，也知道哪一个微小改变能够真正改善工作。

过去，这种领域经验与软件实现能力之间存在一条很宽的鸿沟。一个工程师即使知道问题在哪里，也未必有能力把它做成工具；而专业开发团队即使会写代码，也需要付出很高成本才能理解复杂现场。

AI 正在缩短这段距离。它让领域工作者有机会先做出一个最小的功能性原型，用真实结果证明问题是否值得继续解决。这可能是 AI 对普通 Worker 最重要的意义之一：它让那些长期生活在问题内部的人，第一次更容易参与解决方案的构建。

九、功能性插件并不等于成熟工程软件

当第一个版本能够在 NX 中运行，并完成基本识别、信息读取、长度计算和 PMI 生成时，我确实感到非常兴奋，因为这证明了一件事：这条技术路线可以被拉通。

但我也越来越清楚，Functional 不等于 Production-ready。一个功能性原型回答的是：这件事能不能做到？

成熟的工程工具还需要继续回答：

• 它能否稳定重复运行？
• 不同模型和对象形式是否兼容？
• 异常输入是否会导致软件崩溃？
• 错误信息能否被记录和定位？
• 几何更新以后，标注如何刷新？
• 代码结构是否便于后续维护？
• 新增对象类别时，是否需要重写大量判断？
• 如何测试结果的正确性？
• 如何部署、管理版本和控制权限？
• 哪些数据可以进入 AI，哪些数据必须留在安全边界内？

AI 可以大幅降低做出第一个版本的成本，却不会替人承担这些工程责任。

甚至因为代码生成变得更容易，我们更容易产生一种错觉：能运行，就等于已经理解；能生成，就等于已经完成。

实际上，代码数量增加得越快，验证、测试、架构和维护的重要性就越高。

因此，我不愿意把这次经历写成一个“完全不懂编程，也能轻松开发专业软件”的故事。

它更准确的意义是：一个懂现场问题、但缺少开发经验的人，可以借助 AI 更快地跨过原型门槛；但要把原型变成可靠系统，他仍然需要不断学习，并对最终结果负责。

十、AI 没有取消学习，而是让学习开始围绕真实结果组织

在整个过程中，我确实依靠 AI 写出了大量自己原本无法独立完成的代码。但与此同时，我对 NX 对象、几何关系、组件结构、虚拟中心线、PMI 关联以及异常处理的理解，也在不断增加。

原因很简单：每当 AI 给出的代码失败，我都必须理解它为什么失败；每当两个技术方案都可能成立，我都必须判断哪一个更符合实际模型；每当系统错误识别一个对象，我都必须重新思考自己的分类规则。

因此，AI 并没有让我绕过所有知识。它让我不再需要先掌握全部知识，才有资格开始；但它也迫使我围绕真实问题，逐步建立真正需要的知识。

这里存在一个重要区别。我把两种使用方式暂作区分：

Cognitive Offloading：把查找语法、生成重复代码、整理结构等工作交给 AI，让自己把注意力放在问题与判断上。

Cognitive Outsourcing：不理解问题，不检查结果，也不承担判断，只希望 AI 替自己完成整个思考过程。

前者会放大人的能力。后者可能制造一种脆弱的熟练感：只要 AI 和当前环境都正常，系统似乎可以运转；一旦出现新的错误，人便不知道从哪里开始处理。

我希望自己采用的是第一种方式：不是让 AI 替我拥有问题，而是借助 AI，逐渐扩大自己能够拥有的问题范围。

十一、这次实践真正留下来的资产是什么？

上一篇文章中，我已经区分了企业成果和个人资产。具体插件、内部模型、产品数据和源代码，并不会因为我参与了开发，就自动成为我的个人财产。

但这次工作仍然留下了很多可以合法迁移的东西。我知道了如何：

• 从重复劳动中识别值得系统化的问题；
• 把一个模糊需求拆成可以逐步验证的功能；
• 用 Journal 把隐性操作转化为行为证据；
• 让 AI 反向指出上下文缺口；
• 把错误日志变成下一轮开发输入；
• 在真实软件环境中验证 AI 的假设；
• 区分对象分类、几何计算和 PMI 输出；
• 区分一个功能性原型与成熟工程系统；
• 把一次开发过程沉淀成技术文档和方法论。

这些能力不只适用于管路 PMI。它们还可以迁移到其他 NX 自动化、BOM 处理、PLM 信息提取、工程图生成、设计校核，以及更多专业软件工作流中。

所以，最终属于我的资产并不是某一段代码，而是一种新的行动能力：即使面对一个自己尚未掌握的技术领域，我也知道怎样从真实问题出发，收集行为证据，借助 AI 生成方案，再通过环境反馈逐步把它拉通。

插件可能属于某一个版本，API 可能变化，模型和项目也会结束。但这套方法会改变我下一次面对陌生问题时的起点。

结语：普通 Worker 用 AI 加速劳动，Worker Investor 用 AI 积累资本

回头看，我并没有在某一天突然学会 NX Open。我只是持续完成了很多很小的动作：录制一段 Journal，提出一个问题，运行一次代码，发现一个错误，补充一份信息，再验证一个假设。正是这些连续动作，把一个最初只有想法的问题，逐渐拉通成了一个具备基本功能的插件。

这让我看见，AI 时代真正发生的变化，可能并不只是“机器会写代码了”。更加重要的变化是：过去只有少数开发者能够把想法写入软件；现在，越来越多生活在真实问题内部的人，也开始获得构建系统的能力。

但这种能力不会自动发生。AI 可以生成代码，却不会替我长期观察现场；AI 可以推荐 API，却不知道什么结果对装配真正有用；AI 可以帮助排查错误，却不会自动承担软件崩溃、标注错误和工程决策所带来的后果。

真正稀缺的，仍然是：

• 对真实问题的长期接触；
• 把隐性经验表达出来的能力；
• 持续进入环境验证的行动；
• 判断结果好坏的专业标准；
• 对问题负责到底的 Problem Ownership。

因此，AI 并没有让人的工作变得不重要。它让一个新的差别变得更加明显：普通 Worker 用 AI 加速劳动；Worker Investor 用 AI 把劳动中形成的经验，转化为可以继续复用的系统与资本。

第一个插件不是终点。它只是一份 Proof of Work。它证明了：当人的问题意识、现场动作、AI 的生成能力和真实环境的反馈持续形成闭环时，一个原本不具备专业开发经验的人，也可以逐步跨过技术边界，把自己对工作的理解变成一个能够运行的系统。

而当一段经验能够被写入系统、被反复验证，并继续改变下一轮行动的起点时，它便不再只是发生过的工作。它开始进入未来。

参考资料