SolidWorks用户试过用Claude Code接DeepSeek操作SolidWorks，结论是“只能做简单零件，而且多次试错，实用性不强”，AI在CAD里到底是“能力还不够”还是“交互范式从一开始就配错了”？

CONTENTS目录

OVERVIEW一、导语：一个被误读的失败案例

先把案例本身说清楚。这位用户的搭建方式是：Claude Code作为前端代理，负责理解自然语言指令并组织工具调用；DeepSeek作为后端推理模型，负责生成操作步骤；两者通过某种桥接方式去驱动SolidWorks。结果是简单零件（如带孔法兰、阶梯轴）能勉强做出来，稍复杂的特征组合就频繁失败，需要反复试错，最终判定"实用性不强"。

这个结论在工程上是成立的，但它的归因值得推敲。把失败归为"AI能力还不够"，隐含的假设是：只要模型再强一点、上下文再长一点、推理再准一点，问题就会自然解决。本文认为这个假设站不住脚。真正的问题在于，这条链路把CAD建模当成了一次性的文本生成任务，而CAD建模本质上是一个带约束的几何状态演化过程。两者对"正确性"的定义完全不同：文本生成的正确性是语义层面的，几何建模的正确性是拓扑与尺寸层面的，后者可以被精确验证，前者不能。

本文的分析主线可以一句话概括：AI与CAD之间缺的不是智能，而是一个可验证、可回滚、可增量更新的语义锚点。特征树（Feature Tree）恰好具备这三个性质，因此它应当成为交互范式的核心，而不是被绕过的中间产物。围绕这条主线，下文依次处理：问题从哪来、机制上为什么必然失败、应该怎么改、改完怎么落地、落地后怎么评估、以及还有哪些边界。

BACKGROUND二、背景与问题定义：AI进CAD的三次浪潮与当前断点

2.1 三次浪潮的划分依据

把AI进入CAD的历程按"AI承担的角色"来划分，比按年份划分更有解释力。笔者认为可以分成三段：

这三波的共同趋势是：AI对几何的介入程度越来越深，但对几何状态的掌控能力并没有同步提升。第一波AI不碰几何所以不会错；第二波AI碰了几何但错了才发现；第三波AI想边做边纠，却缺少可靠的中间表示来支撑纠错。当前断点就在第三波。

2.2 问题定义的精确化

要让讨论可检验，必须把"AI操作CAD"这个模糊说法拆成可度量的子问题。笔者认为至少应拆成四层：

这四层的失败率不是均匀分布的。根据公开的CAD脚本生成评测与笔者的工程观察，意图层和规划层是主要瓶颈，执行层反而是相对成熟的部分——SolidWorks的API文档完整、社区示例丰富，一个明确的API调用很少写错；真正难的是"该调用哪个API、按什么顺序调"。这个判断直接决定了后文的技术路线选择。

MECHANISM三、机制剖析：为什么"自然语言→CAD"这条链路天生不稳

3.1 两种正确性的错位

大语言模型的输出是token序列，其训练目标是下一个token的条件概率最大化。这意味着它优化的是"像不像人写的"，而不是"对不对"。在文本任务里，这两个目标高度相关；在几何任务里，它们几乎正交。一段语法完美、逻辑通顺的建模脚本，完全可能因为一个基准面选错而整体失败。

更麻烦的是误差的传播方式。文本生成里，一个词错了，后面可以靠上下文补救；几何建模里，一个特征错了，后续所有依赖它的特征都会连锁失效。用形式化的话说，CAD建模的状态转移是强耦合的，而LLM的生成过程是弱耦合的。弱耦合的过程去驱动强耦合的系统，误差必然被放大。

3.2 上下文窗口解决不了状态管理

有一种常见误解：只要上下文足够长，把整个建模历史塞进去，模型就能"记住"当前状态。这个想法混淆了"信息可见"和"状态可控"。即便模型能看到全部历史，它仍然需要自己推断"当前几何到底长什么样"，而这个推断没有任何机制保证正确。CAD软件内部维护的是精确的B-rep表示，模型看到的是文本描述，两者之间存在不可逆的信息损失。

笔者认为，正确的做法不是让模型去"记住"几何，而是让模型始终向CAD查询几何。模型不该是状态的持有者，而应是状态的查询者与修改者。这个角色转换是范式迁移的关键一步，后文的技术路线正是建立在这个判断上。

3.3 试错成本的结构性差异

案例里提到"多次试错"，这值得单独分析。试错本身不是问题，问题在于试错的成本结构。在软件开发中，试错成本低（编译快、可回滚、有单元测试）；在CAD中，试错成本高得多：一次失败的建模可能留下脏状态，回滚需要重建，验证需要人工看模型。如果AI的试错频率高于人类工程师，那它就没有实用价值，哪怕单次成功率不低。

这张表说明，要让AI在CAD里可用，必须把试错成本压到接近软件工程的水平。具体手段包括：事务化执行（失败即回滚）、几何断言（每步后自动检查关键约束）、增量重建（只重建受影响的特征）。这些都不是模型能力问题，而是工程基础设施问题。

ARCHITECTURE四、技术路线：以特征树为语义锚点的分层架构

4.1 架构总览

基于第三章的分析，本文提出一个四层架构。它的核心思想是：把LLM从"脚本生成器"降级为"特征树编辑器"，把CAD从"被驱动的黑盒"升级为"可查询的状态机"。架构如下：

与案例中的做法相比，关键差异在L2和L4。案例里L2直接产出脚本，L4基本缺失（靠人眼看结果）；本架构里L2产出的是特征树操作，L4是自动化的几何检查。这两个改动把"盲生成"变成了"可验证的增量演化"。

4.2 特征树作为中间表示的理由

为什么选特征树而不是别的表示？笔者认为可以从三个性质来论证：

• 可读性：特征树本身就是工程师熟悉的抽象，节点名、参数、依赖关系都是人类可读的。LLM在预训练中见过大量CAD教程与特征描述，对"拉伸凸台""旋转切除"这类术语有先验知识，迁移成本低。
• 可执行性：SolidWorks的特征树与API有一一对应关系。一个"拉伸凸台"特征对应FeatureExtrusion3调用，参数映射明确，不存在歧义。
• 可验证性：每个特征节点执行后，几何引擎会更新B-rep表示。可以针对每个节点定义断言（如"该特征产生的实体数量""该特征后的体积变化范围"），验证成本低。

4.3 增量操作而非全量生成

案例失败的另一个技术原因是"全量生成"：每次让模型从头生成完整脚本。这有两个问题：一是每次都要重新理解全部上下文，token消耗大且容易漂移；二是任何一处错误都会导致整体重来，试错成本极高。

增量操作的做法是：模型每次只输出对特征树的最小修改，比如"在第3个特征后插入一个孔特征""把第5个特征的深度从10改成15"。这样每次修改的影响范围可控，验证只需检查受影响的部分，回滚只需撤销单个操作。工程上这对应SolidWorks API的IModelDoc2.EditRebuild3配合特征级的事务管理。

IMPLEMENTATION五、工程落地：从零搭建一条可用的AI-CAD流水线

5.1 环境与依赖

下面给出一条最小可行路径。环境要求：SolidWorks 2022及以上（API较稳定）、Python 3.10+、pywin32（COM桥接）、一个支持结构化输出的LLM接口。核心思路是用COM接口把SolidWorks暴露成可编程对象，再用LLM生成对特征树的操作。

# 最小示例：连接SolidWorks并读取特征树（示意，非完整实现）
import win32com.client

sw = win32com.client.Dispatch("SldWorks.Application")
sw.Visible = True
model = sw.ActiveDoc
if model is None:
    raise RuntimeError("请先打开一个零件")

# 遍历特征树，导出为结构化表示
feat = model.FirstFeature()
tree = []
while feat is not None:
    tree.append({
        "name": feat.Name,
        "type": feat.GetTypeName2(),
        "next": feat.GetNextFeature() is not None
    })
    feat = feat.GetNextFeature()
print(tree)

这段代码只做一件事：把特征树读出来。它是整个流水线的起点，因为只有模型能"看到"当前特征树，才谈得上增量修改。案例里的做法跳过了这一步，直接让模型凭空生成脚本，这是失败的结构性原因之一。

5.2 五步落地流程

这五步里，第2步和第4步是案例缺失的关键。第2步把"自由文本"变成"受约束的结构"，大幅降低了执行层的失败率；第4步把"人眼验证"变成"程序验证"，把试错成本压了下来。笔者认为，这两步的工程投入产出比远高于换一个更强的模型。

5.3 事务化与回滚的实现要点

SolidWorks API本身没有数据库式的事务，但可以通过"特征级快照"模拟：在执行一组操作前，记录当前特征树的序列化状态与模型文件路径；执行失败时，关闭当前文档、重新打开快照文件。这种做法简单但有效，代价是重建时间。对于大型装配体，重建可能较慢，此时可以退化为"只回滚受影响的特征"——通过特征依赖图确定影响范围。

5.4 提示词与约束设计

在结构化输出的前提下，提示词的重点从"教模型怎么建模"转向"约束模型的输出空间"。一个可用的提示词骨架如下：

你是CAD特征树编辑器。当前特征树JSON如下：
{feature_tree}

用户需求：{user_intent}

请只输出一个JSON对象，表示对特征树的最小修改：
- op: insert | modify | delete
- target: 目标特征名（insert时为插入位置的前一个特征）
- feature: 特征定义（type, params, references）

约束：
1. 不得修改与需求无关的特征
2. 所有尺寸必须带单位
3. 引用基准面/边时必须使用特征树中已存在的名称
4. 若需求无法用单步完成，返回 {"op":"plan","steps":[...]}

这个骨架的关键是最后一条约束：它允许模型在必要时输出多步计划，但计划本身也是结构化的，可以被逐步验证。这比让模型一次性生成完整脚本要稳健得多。

DATA六、关键数据与案例：能力边界到底在哪里

6.1 公开评测透露的信号

关于LLM生成CAD脚本的能力，公开评测不多，但有几个方向可以参考。CADCodeVerify等工作提出了对LLM生成的CAD代码进行自动验证的框架，其核心发现是：直接生成的CAD脚本在复杂零件上的首次通过率显著低于简单零件，且错误类型集中在基准选择与特征顺序上（来源：CADCodeVerify相关论文，2024）。这与案例的观察一致。

另一条线索来自Text2CAD方向的研究。这类工作尝试从文本直接生成参数化CAD序列，评测指标通常包括序列合法性、几何相似度、约束满足率。公开结果显示，简单零件（如单特征或双特征零件）的序列合法率较高，但随特征数增加快速下降（来源：Text2CAD相关论文，2024）。需要说明的是，不同工作的评测集与指标不统一，跨论文比较需谨慎。

6.2 一个模拟的复杂度-成功率关系

由于缺乏统一的公开基准，下面给出一组模拟数据，用于说明趋势而非精确数值。设定：特征数从2到10，分别测试"全量脚本生成"与"增量特征树编辑"两种范式，每种配置模拟100次，统计首次成功率与平均修正轮数。数据为整合模拟，非真实实验。

这组模拟数据的趋势很清楚：两种范式的成功率都随复杂度下降，但增量编辑的下降斜率明显更缓，且在修正轮数上优势更大。这支持了本文的核心论点——范式改进能带来实质收益，而且收益随复杂度增加而扩大。需要强调，这是模拟数据，真实数值会因模型、提示词、零件类型而不同，读者应关注趋势而非绝对值。

6.3 案例复盘：失败点定位

回到开头的案例，用本文的框架复盘，可以定位到三个具体失败点：

• 缺少状态查询：模型不知道当前模型长什么样，每次生成都是"盲写"。对应第三章的"上下文窗口解决不了状态管理"。
• 全量生成导致高试错成本：一次失败就要整体重来，修正轮数多。对应第三章的"试错成本结构性差异"。
• 缺少几何验证：错误要到人眼看模型时才发现，反馈链路长。对应第四章的L4缺失。

这三个失败点都不是"模型不够聪明"，而是架构缺失。换句话说，即便换成更强的模型，只要架构不变，失败模式不会变，只是失败得晚一点。这个判断是本文与"能力不足论"的核心分歧。

COMPARISON七、对比与局限：三条主流路线的横向评估

7.1 三条路线的定位

当前AI进CAD主要有三条路线，各有适用边界：

案例中的做法介于"脚本生成"与"界面Agent"之间，但两头不靠：它想用脚本的自动化，又想用Agent的灵活性，结果既没有脚本的可验证性，也没有Agent的通用性。笔者认为，对于工程级应用，API+特征树是唯一能同时满足可验证与可回滚的路线；界面Agent适合演示与轻量场景，不适合严肃建模。

7.2 局限与未解问题

本文提出的架构也有明确局限，必须诚实列出：

• API覆盖度：SolidWorks API并非所有功能都开放，某些高级特征（如复杂曲面、钣金展开）的API支持有限，这些场景下架构会退化。
• 几何断言的完备性：能自动验证的约束是有限的，工程约束（如可制造性、装配公差）很难完全形式化，仍需人工把关。
• 特征树的语义鸿沟：特征树是"建模历史"而非"设计意图"，模型可能做出几何正确但设计意图错误的修改（如用切除代替拉伸），后续修改会变困难。
• 评测基准缺失：目前没有公认的交互式CAD建模基准，本文的模拟数据只能说明趋势，无法作为性能承诺。

CONCLUSION八、结论与展望：范式迁移比模型升级更紧迫

回到标题的问题：AI在CAD里到底是"能力还不够"还是"交互范式配错了"？本文的答案是：两者都有，但后者是主要矛盾，且后者不解决，前者的收益会被大量浪费。模型能力确实在提升，但提升的是意图理解与代码生成，这两项在本文的四层拆解里只覆盖了L1和部分L3；真正卡住实用性的L2规划与L4验证，靠模型升级解决不了，必须靠架构改造。

具体到操作层面，本文给出的路径是：以特征树为语义锚点，把LLM从"脚本生成器"改造为"特征树编辑器"；用结构化输出约束操作空间；用事务化执行与几何断言压低试错成本；用增量修改替代全量重来。这条路径有明确的工程步骤（第五章五步流程），也有可检验的评估指标（首次成功率、平均修正轮数、回滚时延）。

展望未来，笔者认为有三个方向值得投入：一是建立交互式CAD建模的公开基准，让不同方案可比较；二是研究特征树的语义补全，让模型理解"设计意图"而不只是"建模历史"；三是把几何验证前移，在生成阶段就用轻量几何检查过滤明显错误，减少无效试错。这三点都不依赖更强的基座模型，属于工程与算法结合的中层创新，投入产出比更高。

REFERENCES九、参考文献与拓展资源

9.1 主要参考文献（8篇）

9.2 数据集与预处理说明

本文引用的公开评测涉及CAD数据集（如DeepCAD数据集、Fusion 360 Gallery数据集）。这些数据集通常包含大量CAD模型的命令序列与B-rep表示。预处理一般包括：过滤无效模型、统一单位、提取特征序列、对齐坐标系。本文未直接使用这些数据集做实验，相关描述仅用于说明领域现状。第六章的表格为模拟数据，生成方式为：设定特征数与两种范式的成功率衰减曲线，按100次/配置抽样统计，非真实实验，不可作为性能依据。

9.3 拓展资源

• SolidWorks官方帮助中心：API文档与示例的权威来源。
• GitHub上的CAD自动化项目：可搜索"solidworks api python"等关键词，参考社区实现。
• arXiv：检索"Text2CAD""CAD generation"等关键词获取最新预印本。
• 视频教程：搜索"SolidWorks API macro tutorial"可找到宏录制与API入门的实操视频。