当AI遇上汽车设计审查，一场生产力革命正在悄然发生。赛力斯通过整合Catia插件库与AI能力，打造了一套能自动完成数模审查、生成标准报告的智能系统，将工程师从重复劳动中解放。但这场变革并非简单的技术替代——文章深度剖析了工业场景下AI落地的真实边界，揭示了车企智能化转型中最关键的工程化积累与场景适配问题。

你盯着屏幕，进度条走了二十分钟，还剩三分之一。

这是一个Catia数模文件的加载画面。作为车企设计审查工程师，这样的等待是日常。文件打开之后，还有上百张照片要按标准逐一拍摄，还有审查报告要整理归档，还有不达标的地方要反馈给供应商，等对方修改后再来一遍。

一个车型下来，审查项目多达上万条。

这件事有没有可能让AI来做？

我们在赛力斯做了一次尝试。结果是：可以，但没有你想象的那么简单。

一、这件事有多痛

如果你没在车企待过，可能很难想象设计审查这个环节有多重复、多消耗人。

我们梳理了一下，大概有三层痛：

第一层是时间消耗在等待上。数模文件动辄几个G，光是打开就要半小时起，工程师坐在那里什么都干不了，只能等。

第二层是拍照这件事本身。一个零部件的审查，可能需要上百张照片，每一张都要按照规定的角度、规定的标准来拍。这件事高度重复，但又不能出错，做多了会麻木，麻木了就会出错。

第三层是标准一致性。人工操作难免有个体差异，同一条审查项，不同工程师截图的角度、判断的尺度可能不一样，输出的报告格式也很难统一，给后续的归档和追溯带来麻烦。

这三层痛加在一起，本质上是：大量高度重复、有明确标准、却又全靠人盯着干的工作。这恰好是AI最适合介入的场景。

二、为什么这个问题一直没被解决

你可能会问：这个问题存在这么久，为什么之前没人用自动化解决？

原因在于Catia本身的生态。Catia是达索系统的工业软件，在汽车、航空领域是事实上的标准，但它的二次开发接口——也就是CAA——门槛相当高，学习曲线陡，文档体系复杂，能熟练做CAA开发的工程师在市场上本来就稀缺。大多数车企要么没有这个技术积累，要么有但规模很小。

我们能做这件事，前提是公司内部已经有一个专门做CAA二开的团队，沉淀了大约一千个审查插件。这个积累本身花了很长时间，不是一个新项目能从零复制的。

换句话说，AI在这里是”最后一公里”的解法，但”前九十九公里”的基础设施得先有。

三、我们怎么做的

我们的方案分两层，缺一不可。

第一层是打造一个本地客户端。这个客户端部署在工程师自己的台式机上，能够自动读取指定目录下的数模文件，按照审查标准自行完成拍照、核对、生成报告的全流程。工程师不需要手动点开文件、逐项操作，客户端跑完直接出报告，格式统一，标准一致。

但这里有一个现实问题没办法绕开：数模文件打开需要半小时，AI也省不了这个时间。文件的加载是Catia软件本身的性能瓶颈，不是AI能解决的。

这就引出了第二层：打通飞书。

我们通过飞书应用机器人把客户端连接起来，工程师可以用自然语言，在手机上远程操控台式机里的客户端。出差在外、下班回家，睡前给机器人发一条消息：”帮我跑一下XX零件的审查”，客户端自动启动，文件在加载，AI在等——等文件开完，立刻开始干活。

AI不用睡觉。这是它唯一但足够重要的优势。

等你第二天早上醒来，报告已经在系统里了。

简单系统架构如图：

四、最难的问题：AI幻觉怎么解

讲到这里，做AI产品的人可能会问一个问题：审查结果准不准？AI会不会看错？

这是整个方案里最核心的设计决策，也是我们花时间最多的地方。

如果让AI直接”看”数模图片来判断是否合规，幻觉问题几乎无解——3D模型的细节太复杂，视觉识别的误差在工业场景里是不可接受的。

我们的解法是：不让AI去”看”，而是让AI去”操作”。

具体来说，Catia提供了付费的二次开发接口，可以在软件内部开发定制化插件。我们公司有一个团队专门做这件事，目前已经积累了大约一千个审查插件，每个插件对应一类具体的检查项——干涉检查、包络检查、特征检查等等。这些插件的输出结果是结构化的：合格或不合格，有明确的判断依据，不存在模糊地带。

AI做的事情，是调用这些插件，按顺序执行检查，收集结果，生成报告。它不需要自己判断，它只需要正确地调用接口、正确地记录结果。这样幻觉问题就被大幅规避掉了。

当然，这个方案有一个边界：AI能审查的项目数量，取决于已有插件的覆盖范围。一个完整车型下来有上万条审查项，目前插件能覆盖的大概是其中一半左右，剩下的那一半还需要人工介入。

但这个边界本身，也在被持续推进。

五、AI能取代CAA工程师吗？

这个问题在我们内部讨论过。

领导层一度有个设想：既然AI能调用插件做审查，那能不能也用AI来写插件？把CAA二次开发这件事也交给AI，岂不是两头都省人了？

我们认真拆解了一下CAA工程师的实际工作时间分布，结论是：没那么简单。

一个CAA开发工程师，大概60%的时间在编码，20%在调试验证，20%在需求和概要方案阶段。看起来编码占大头，AI应该能帮上忙——但问题出在编码之前。

在动手写代码之前，工程师要先读懂审查标准，把它转化成可执行的逻辑步骤，再整理成AI能理解的概要方案。这个”翻译”过程，目前AI做不了，因为审查标准本身往往是工程语言，充满了行业隐性知识，没有足够的上下文，AI拿到这些标准根本不知道从哪里下手。

所以实际上，AI辅助CAA编码的边界是这样的：工程师负责需求理解和逻辑拆解，AI负责在清晰的逻辑框架下生成代码、调用API。我们评估下来，在逻辑层编码和API调用编码这两块，AI介入后分别有望提升5-10%和10%左右的效率。

不是取代，是分工。工程师的价值，往前移了。

我们现在在做的，是把Catia官方文档和内部业务代码库整合成知识库，同时定制专用的技能模块，让AI在有约束的环境里输出更稳定的代码质量。这件事还在探索中，结论还没出来。

六、这套方案能复制吗？

理论上可以，但有一个绕不开的前提：你得先有足够规模的CAA插件库。

插件库是这个方案的地基。AI调用的每一个检查项，背后都是工程师一行一行写出来的插件代码。我们评估下来，一个完整车型的上万条审查项里，大约一半可以被标准化成插件，另一半因为场景复杂、判断依赖经验，目前只能靠人工。而这”能插件化的一半”，本身也需要持续投入CAA工程师来开发和维护——AI在这里能提升编码效率，但替代不了工程师对需求的理解和逻辑拆解。

所以这套方案的可迁移性是有门槛的。门槛不在AI，在二开积累。

这也是为什么我们认为，车企AI落地的核心竞争力，不是谁用了更好的模型，而是谁在垂直场景里有更深的工程化积累。

七、回头看这件事

我们做对了一件事：没有试图用AI解决所有问题。

数模加载慢，我们没有去攻克这个性能瓶颈，而是绕开它——让AI在等待的时间里干活，让工程师从等待中解放出来。AI识别不准，我们没有去硬上视觉模型，而是用结构化接口约束AI的行为边界，把”判断”这件事交给已经验证过的插件。AI写不了业务代码，我们没有强行让它全包，而是让工程师往前移，专注在AI真正做不了的那部分。

这是车企AI落地最难的地方，也是最容易被忽视的地方：不是模型不够强，而是场景太复杂、约束太多、容错空间太小。在这种环境下，把AI用对，比把AI用满更重要。

我们这个项目还在推进中，很多结论还没有最终数据支撑。但有一点是确定的：当工程师早上来公司，发现昨晚AI已经跑完了三个零件的审查报告，格式整齐地躺在系统里——这件事本身，已经说明了一些问题。