AI能接管CAD吗？40位从业者的内部讨论与分歧实录 | AI4ELAB

大家好，我是秦明。让AI调用CAD这件事，最近开始从小圈子讨论变成了显性需求——甲方问CAD厂商能不能开放接口，CAD厂商问谁在做Agent，做Agent的人问设计师到底想要什么。

5月21日晚上，一批来自建筑、制造、化工、仿真等不同垂直领域的从业者——涵盖CAD平台方、设计院工程师、AI创业团队、大厂内部研发、行业顾问——就「AI如何介入CAD工作流」展开了一场内部讨论。话题覆盖技术路线选择、图纸理解的真实难点、产品形态演变方向，以及行业落地的现实障碍。

以下是这场讨论的观点精华整理，观点来自不同背景从业者的发言，代表讨论时的个人判断，不代表任何机构或企业的官方立场。部分表述经过整理和提炼，原始发言者未对本文进行审核确认。

接口之争：MCP、CLI、Python，没有标准答案

1、MCP被过度神化了。有实践者明确表示不看好MCP作为CAD Agent的主接口——它对网络通信和认证场景有价值，但在本地工作流中，CLI与文件系统的结合更自然，且大模型训练数据里Linux命令覆盖量级远高于MCP规范，调用质量更稳定。

2、CLI的真正优势在于可组合性。单条命令只覆盖一个原子操作，但多条命令可以像管道一样串联，绝大部分图形操作的80%可以通过grep、awk、文件路由等通用Linux工具完成，只需自己写剩下的20%。这是MCP封装方案难以复制的灵活性。

3、Python SDK在灵活性上优于CLI，但在AI集成上弱于CLI。有团队做过对比：Python脚本支持更复杂的逻辑组合，有一定二次开发经验的设计师可以直接编辑代码文件；但CLI风格的接口让大模型「更熟悉」，调用成功率更高。两者可能需要混合使用。

4、C++ SDK和传统二次开发接口对大多数Agent场景已经足够。有厂商提出，是否需要专门为AI设计新接口？实践者的反馈是：只要Python接口足够丰富（参考Ansys近几年的推进路径），加上良好的文档和GitHub开源示例，大模型就能用得好。问题不是「能不能调」，而是「能不能调得好」。

5、不同任务应该匹配不同接口形态。复杂的、需要多步推理的任务封装成MCP反而高效；简单、频繁、对稳定性要求高的任务用CAD原生CAPI或Python更可靠。没有哪种接口在所有场景都最优，这是目前行业共识。

6、评测体系严重缺失。当前多数团队靠「自己日常带着软件做任务」来判断哪种方案好用，自动化Benchmark成本高且与真实场景存在偏差（比如真实任务中Agent可以联网搜索，自动化测试不行）。这个领域缺一套公认的评测框架。

读懂图纸，比想象中难得多

7、DWG转JSON是当前最主流的技术路径，但它只解决了「数据可读」，没有解决「语义可理解」。多个团队独立实现了类似方案：将DWG解析为包含坐标、颜色、图层、块属性的结构化JSON，再喂给大模型。这一步的技术门槛已经不高，三方库基本可以覆盖。

8、图层是最不可信的信息源。有设计院背景的参与者直接说：图层命名在实际工作中「非常随意」——同一图层可能混有不同对象，同一对象可能分布在不同图层，不同设计院、不同专业、不同个人的命名体系完全不统一。一个团队做过统计：对数万张图纸做质量评审，86%的图层信息存在问题。依赖图层做语义识别的方案，泛化性极差。

9、视觉模型路径（CV）准确率上不去，但放弃它又走不通。纯数据解析缺乏视觉上下文，纯CV缺乏行业语义，最终有效的方案几乎都走向了「CV+JSON语义标注融合」的多模态路线。代价是标注工作量极大——1000张图纸的标注实测需要6个月人力，且早期完全无法通过AI自动化完成。

10、一个矩形，到底是梁还是柱？这是最核心的歧义问题。同样的几何形状在不同图纸、不同专业中语义完全不同。解决路径是引入「知识图谱」思维——不是单独识别一个图元，而是识别它与周边图元的关系网络，再结合行业规范做推断。这个方向工作量大，但目前看是最稳健的技术路线。

11、平法标注是混凝土图纸AI算量的硬门槛。平法（平面整体表示方法）是中国建筑行业特有的标注体系，信息密度极高、解读依赖大量行业背景知识。当前主流AI算量产品大多绕开了混凝土图纸，聚焦在标注信息相对清晰的钢结构领域，也是出于这一原因。

12、不是「识别出来」就算成功，定位同样关键。有团队做了一个验证：不只找出图纸里有哪些静载实验表，还要直接在CAD画面内定位并放大显示。这两件事的技术难度不在同一量级，前者是检索问题，后者是坐标系对齐加视图控制问题。很多演示只做到前者。

行业语义，才是真正的壁垒

13、识别一条线不难，难的是理解这条线「为什么存在」。有从业者给出了清晰的分层判断：当前开源模型识别简单图元（门、窗、线）已经不是大问题，预计半年内这一能力会进一步普及；但「这扇门放在这里是否合理」「这根梁和柱子的关系是否满足规范」才是下一阶段的核心竞争力。能力分层决定壁垒高度。

14、老法师的经验比规范文本更难复制。建筑工程中大量问题的处理方式不在任何规范里写着，它存在于有20年经验的工程师的直觉判断中。这类隐性知识的提炼和编码，是当前RAG或Skill设计所面临的真实挑战。某种程度上，谁能把这部分经验结构化，谁就拥有了竞争对手最难复制的数据资产。

15、规范知识库不等于行业理解。有团队将1.2万本国家及地方规范全部录入知识库，规范检索准确率达到85%-95%，但始终无法达到100%。问题不在数量，在于规范条文之间的关联逻辑——哪条规范在什么条件下优先、不同规范之间如何冲突、施工方案如何在规范边界内做取舍，这些都不在文本里。

16、行业知识的组织方式比训练数据量更重要。单靠语料堆叠不够，需要对业务流程和行业规则有足够深的理解，才能在语料之间建立正确的关联关系。这一判断来自早期尝试过垂直大模型底座的团队，他们认为」语料之间的串联能力」才是垂直大模型相对通用大模型的真正差异点。

产品形态：从「会画图的AI」到「人管AI画图」

17、当前建筑设计行业的劳动力存量过剩，「画图更快」不是刚需。行业下行背景下，设计院并不缺人手，一个能大幅提升出图速度的AICAD插件，反而会加剧行业人力资源问题，买单意愿存疑。这个判断挑战了很多AICAD产品的基本假设。

18、真正有价值的产品形态是：人定方向，AI执行。类比是工厂里的中控系统——操作者设定参数和目标，机器自动运行。对应到CAD场景，设计师负责「设计意图」的输入和审核，AI负责将意图翻译为符合规范的图纸输出。这需要的不是更快的绘图工具，而是更好的「意图捕捉接口」。

19、六七十分的生成质量，在实际工作中约等于零。有大厂内部研发团队做了诚实的披露：他们的AI生成建筑方案可以打到六七十分，但在推广中发现，设计师拿到这个结果之后几乎要「重新画一遍」，并不能节省实质性工作量。产品可用的门槛远比技术演示的门槛高。

20、三种产品形态都被验证过，都有问题。第一种是将图纸上传到大模型网页端做解读，流程割裂；第二种是在CAD里嵌入Agent插件，与设计师的操作习惯不符；第三种是通过命令行调用大模型能力，与传统CAD操作方式最接近，被认为是目前摩擦力最小的接入方式。但三种都没有解决「如何流畅表达设计意图」的根本问题。

21、从「人画CAD」到」人管CAD」，可能同时重塑BIM的推广逻辑。当前建筑行业的数据流是：设计院出CAD→构件加工厂重新翻格式→施工方再建一个BIM模型。每个环节格式不通、语义丢失，BIM难以普及的根源在于整个生产要素流通链条缺乏统一标准。AI介入CAD如果能在源头就让图纸携带语义信息，可能是重构这个链条的真正机会。

22、在画图阶段就让图元携带信息，可能是读图难题的终极解法。有观点认为，与其在事后用AI解析图纸语义，不如学习酷家乐的路径——在用户画图时，工具本身就强制要求对象携带类型、规格、材质等结构化信息，从源头避免语义缺失。这对ToB产品意味着需要介入用户的上游工作流，是更高的产品壁垒，也是更大的推广难度。

谁的机会？垂直专业先行，跨专业融合还早

23、跨专业融合是陷阱，单专业突破是正道。建筑项目涉及建筑、结构、给排水、暖通、电气等多个专业，各专业之间的图纸协同目前无法被AI完整接管。当前已有商业化案例的产品（如某电力设计AI出图产品）都是在单一专业内闭环——系统图、变电所图，图元类型有限，规则相对清晰，准确率可以做高。

24、钢结构是当前AI算量准确率最高的细分场景。相比混凝土图纸，钢结构图纸标注信息更规范，构件类型更清晰，AI可以做到较高精度的重量统计和构件检索。已有团队验证了从「找出所有GL一梁」到「计算它们的总重量」的完整链路。

25、制造业零件图的自动生成，比建筑图更接近可商业化。齿轮、连接块等标准机械零件有明确的几何逻辑，特征（孔、腔、倒角）可枚举，投图规则相对固定。已有团队在这个方向实现了：输入3D数模→自动识别零件类型和加工特征→生成带标注的2D图纸，且流程基本不依赖人工干预。难点在于从标准件向个性化零件的泛化。

26、定制化制造场景，文生CAD的效率问题尚未解决。有企业尝试通过AI生成SolidWorks零件再组装成装配体，简单场景可行，但面对定制化程度高、变量多的产品线时，全AI生成效率远低于有经验工程师手工建模。这个问题的本质是：当前大模型对复杂三维几何关系的理解能力，仍远弱于人类工程师。

27、化工领域的P&ID识图到三维建模，是一个被低估的机会。化工工厂的CAD图纸以管道流程图（P&ID）为主，与建筑图纸相比图元类型更少、规则更清晰，但目前专门针对这一场景的AI工具极少。从P&ID读图到三维管道模型的自动生成，存在明显的技术空白。

28、仿真（CAE）的AIAgent可能比CAD本身更快落地。Ansys等仿真软件已经提供了非常丰富的PythonAPI（远比多数CAD软件开放），且仿真工作流相对标准化——建模、划网格、设参数、求解、出报告。有团队已经在汽车、半导体芯片等行业的仿真场景跑通了完整Agent流程，并在接商业项目。相比CAD，CAE的接口生态更成熟，是更容易先验证商业价值的方向。

人与AI的协作界面，还没有找到正确的打开方式

29、设计师无法用自然语言准确表达设计意图，这是结构性难题。经过多年专业训练，工程师在大脑中形成了强烈的空间感和约束直觉，但这些认知很难翻译成线性文字描述。「帮我建一个体育馆」的级别的指令远未到来，但「把第三排第二跨的斜撑改成180×10的角钢」这类精确指令，又要求用户具备和原来手工操作一样的专业准确度——只是换了个输入方式。

30、当模型复杂到一定程度，连用户自己都说不清楚要改哪里。这是AnyCAD团队在实践中遇到的真实问题：一个包含数百个零件的装配体，用户想修改某个局部，但用自然语言描述这个局部的位置关系，比直接用鼠标点选更费力。AI接口的设计，不能脱离GUI单独存在。

31、「修改辅助」可能比「生成」更有实际价值。AI一次生成出完整正确的图纸，在复杂工程场景几乎不可能实现。但「设计师画一步，AI帮优化一步」的协作模式，摩擦力更低，容错性更高，也更符合设计师的实际工作习惯——设计本来就是一个边画边改的迭代过程，而不是脑中有完整方案再线性输出。

32、把设计师的个人经验蒸馏成Skill，是细分领域落地的可行第一步。与其让设计师学会用AI，不如先把资深设计师的判断体系结构化。某种程度上，这是在创造「数字员工」——不依赖用户实时输入意图，而是预先编码了专业决策逻辑。代价是Skill的泛化能力弱，更换场景需要重新构建。

33、设计协作系统的「人性化」是一个被忽视的需求。有20年数字化协作系统建设经验的从业者提出：AI介入CAD的价值，不只是提升绘图速度，还包括让协作方式回归「人与人之间的紧密沟通」——现有协作系统大多是冷冰冰的流程管控，AI有可能让专业间的沟通更接近于自然语言交流，而不是流程审批。这个方向目前几乎没有产品在做。

欢迎加入我们的付费社群，获取更多一线交流思考，包括AI4ELAB闭门交流后的每次讨论内容实录