AI编程的玩具级可运行与企业级落地之间的鸿沟

寂静回声

这个非程序员工程师用 AI 做出 CATIA 插件的案例，恰恰是「玩具级可运行」和「企业级可落地」之间，存在不可逾越鸿沟的典型样本。
这位工程师能做出「点击按钮跑通流程」的插件，本质是 AI 帮他完成了单次场景的代码片段拼接，而非工业级的二次开发。CATIA 的二次开发（无论是基于 CAA 还是 V5 Automation），从来不是「能跑通」就合格，核心门槛恰恰是 AI 生成 + 非专业开发完全无法覆盖的部分。
AI 生成的代码只能适配理想状态下的标准数模，一旦遇到特征缺失、几何异常、大装配体权限冲突、版本兼容问题，没有任何异常处理机制，轻则直接崩掉 CATIA 进程，重则直接损坏核心数模。
非程序员看不懂代码，根本无法识别 AI 生成代码中的内存泄漏、无效 API 调用、冗余循环、License 资源占用等问题。单次单模型跑通毫无意义，一旦批量处理、长时间运行、对接大装配体，大概率会出现 CATIA 卡顿崩溃、占用浮动 License 导致全部门无法使用等问题。
CATIA 版本升级、企业 PDM/PLM 系统接口变更、MR 评审规则迭代、企业安全策略调整，都会导致插件直接失效。而开发者本人连代码都看不懂，既无法定位 bug，也无法完成迭代升级，这个插件本质是「一次性工具」，甚至是一颗随时会炸的「定时炸弹」。


合规性的一票否决，是制造业研发体系的绝对红线。
这一点比代码问题更致命，也是个人玩具工具和企业级应用最核心的分水岭。在高端装备、汽车、航空航天等强合规行业，MR 制造要求评审是和产品质量、体系认证强绑定的核心流程，私自开发的黑盒插件，从根上就触碰了 4 条不可逾越的合规红线。

CATIA 的二次开发有严格的达索官方授权规范，未经 IT 和厂商确认的私自开发，本身就违反了软件最终用户许可协议，企业会面临厂商的追责；同时 AI 生成代码存在严重的开源协议污染风险，若代码中包含 GPL 等传染性开源协议的片段，一旦用于企业正式流程，会面临巨额的知识产权诉讼。
汽车行业 IATF16949、航空航天 AS9100 等体系认证，明确要求研发评审全流程可追溯、可审计、可复现。黑盒插件的评审逻辑没有经过 IT 验证、质量部门评审、版本管控和操作留痕，一旦用该插件评审的数模出现批量生产质量问题，不仅无法追溯根因，企业的体系认证会直接亮红灯，甚至面临终端客户的巨额索赔。
3D 数模是制造企业的核心商业机密，未经 IT 安全审核的插件，是否存在数据上传后门、是否会窃取核心设计参数、是否存在恶意代码，完全不可控。绝大多数制造企业对研发环境有严格的隔离管控，连外接 U 盘都严格禁止，私自安装未经审核的插件，本身就违反了企业数据安全的红线规定。
个人私自开发的工具，一旦用于正式生产流程，出现问题后的责任主体完全模糊。走正规 IT 立项开发的工具，有明确的需求评审、测试验收、运维责任主体；而个人黑盒开发的插件，出了生产事故，开发者本人、部门、企业都要承担连带责任，这是任何正规企业都不可能接受的。

如果只是工程师做一个纯个人提效的工具，只给自己用、不碰核心数模、不输出正式评审结果、不传播给他人，只是替代自己的重复手动操作，就算崩了也只影响个人工作，那这确实是 AI coding 的价值，把过去需要 IT 排期立项的事，实现了快速的个人提效。
但只要这个插件涉及正式评审流程、输出正式生产结论、多人共用、接入企业研发体系，哪怕只是部门内推广，这个玩法从根儿上就不成立。
工业软件的二次开发，核心从来不是「实现功能」，而是「不出错、可追溯、可维护、全合规」。这恰恰是 AI 生成 + 非专业开发，永远无法靠「一键生成」跨越的门槛。目前国内绝大多数头部整车厂、航空航天院所，已经明确出台规定：严禁员工私自用 AI 生成代码开发接入研发体系的工具，AI 只能作为专业开发人员的辅助工具，所有二次开发必须走完完整的立项、审核、测试、合规扫描、发布管控全流程。