AI能取代CAA工程师吗？

寂静回声

车企设计审查工程师打开车型文件之后，还有上百张照片要按标准逐一拍摄，还有审查报告要整理归档，还有不达标的地方要反馈给供应商，等对方修改后再来一遍。一个车型下来，审查项目多达上万条。

这个问题存在这么久，为什么之前没人用自动化解决？
原因在于Catia本身的生态，Catia是达索系统的工业软件，在汽车、航空领域是事实上的标准，但它的二次开发接口——也就是CAA——门槛相当高，学习曲线陡，文档体系复杂，能熟练做CAA开发的工程师在市场上本来就稀缺。大多数车企要么没有这个技术积累，要么有但规模很小。
能做这件事的前提是公司内部已经有一个专门做CAA二开的团队，沉淀了大约一千个审查插件。这个积累本身花了很长时间，不是一个新项目能从零复制的。
换句话说，AI在这里是”最后一公里”的解法，但”前九十九公里”的基础设施得先有。

方案分两层，缺一不可。
第一层是打造一个本地客户端，这个客户端部署在工程师自己的台式机上，能够自动读取指定目录下的数模文件，按照审查标准自行完成拍照、核对、生成报告的全流程。工程师不需要手动点开文件、逐项操作，客户端跑完直接出报告，格式统一，标准一致。
但这里有一个现实问题没办法绕开：数模文件打开需要半小时，AI也省不了这个时间。文件的加载是Catia软件本身的性能瓶颈，不是AI能解决的。

这就引出了第二层：打通飞书。
通过飞书应用机器人把客户端连接起来，工程师可以用自然语言，在手机上远程操控台式机里的客户端。出差在外、下班回家，睡前给机器人发一条消息：”帮我跑一下XX零件的审查”，客户端自动启动，文件在加载，AI在等——等文件开完，立刻开始干活。
AI不用睡觉，这是它唯一但足够重要的优势。

如果让AI直接”看”数模图片来判断是否合规，幻觉问题几乎无解。3D模型的细节太复杂，视觉识别的误差在工业场景里是不可接受的。
AI做的事情，是调用审查插件。前面说过，Catia提供了付费的二次开发接口，可以在软件内部开发定制化插件。
这家公司有一个团队专门做这件事，目前已经积累了大约一千个审查插件，每个插件对应一类具体的检查项——干涉检查、包络检查、特征检查等等。这些插件的输出结果是结构化的：合格或不合格，有明确的判断依据，不存在模糊地带。
不需要AI自己判断，它只需要正确地调用接口、正确地记录结果，这样幻觉问题就被大幅规避掉了。
当然，这个方案有一个边界：AI能审查的项目数量，取决于已有插件的覆盖范围。
一个完整车型下来有上万条审查项，目前插件能覆盖的大概是其中一半左右，剩下的那一半还需要人工介入。

领导层一度有个设想：既然AI能调用插件做审查，那能不能也用AI来写插件？把CAA二次开发这件事也交给AI，岂不是两头都省人了？
然而一个CAA开发工程师，大概60%的时间在编码，20%在调试验证，20%在需求和概要方案阶段。
在动手写代码之前，工程师要先读懂审查标准，把它转化成可执行的逻辑步骤，再整理成AI能理解的概要方案。这个”翻译”过程，目前AI做不了，因为审查标准本身往往是工程语言，充满了行业隐性知识，没有足够的上下文，AI拿到这些标准根本不知道从哪里下手。
所以实际上，AI辅助CAA编码的边界是这样的：
工程师负责需求理解和逻辑拆解，AI负责在清晰的逻辑框架下生成代码、调用API。在逻辑层编码和API调用编码这两块，AI介入后有望提升大部分效率。

插件库是这个方案的地基，AI调用的每一个检查项，背后都是工程师一行一行写出来的插件代码。一个完整车型的上万条审查项里，大约一半可以被标准化成插件，另一半因为场景复杂、判断依赖经验，目前只能靠人工。而这”能插件化的一半”，本身也需要持续投入CAA工程师来开发和维护——AI在这里能提升编码效率，但替代不了工程师对需求的理解和逻辑拆解。
车企AI落地的核心竞争力，不是谁用了更好的模型，而是谁在垂直场景里有更深的工程化积累。
不要试图用AI解决所有问题，不仅是模型不够强，而且还有场合太复杂、约束太多、容错空间太小。在这种环境下，把AI用对，比把AI用满更重要。