企业官网建设流程全解析

去年我在一个机械设计社群里看到有人贴了一张图：输入一句“一个带矩形底座的U型支架，底座上有四个M6通孔，间距50mm”，系统直接吐出了可编辑的STEP文件和渲染图，全过程不到90秒。底下评论区炸了，有人说“CAD要完了”，有人说“这玩意儿能过审图吗”。我当时没急着站队，而是花了两个周末把它彻底跑了一遍，包括公开Demo、开源Pipeline和本地推理。想法的确改变了不少，但也发现大家对这个东西的预期和实际能力之间存在巨大落差。

今天这篇就是完全不掺水的实操复盘。我会把它拆到原理层面，讲清楚text-to-cad为什么选“代码生成模型”这条路，主流的几个方案差在哪，自己动手跑通一条mini pipeline要过哪些坎，以及最容易被忽略但决定成败的细节。不管你是机械工程师、CAD二次开发老手，还是刚接触生成式设计的玩家，这篇文章都能给你一个完整的坐标系。

1. 核心思路拆解：为什么"直接生成模型"是条死路

1.1 先问一句：凭什么text-to-cad能敢这么干？

很多人以为text-to-cad就是把一段文字丢进AI，然后AI“凭空捏”出一个三维模型。这个理解不能说错，但会严重误导你对技术路线的判断。我在刚开始研究时就犯了这个错——我以为背后是某种端到端的神经网络，直接把自然语言映射成体素或点云，像文生图模型画图那样“画”出个模型来。

但如果你真去用几款主流产品就会发现，它们生成的并不是“图像”，而是一段程序化建模的代码。也就是说，系统先把你的自然语言转换成一段OpenSCAD脚本、CadQuery Python脚本或者Fusion 360的API调用序列，然后由代码解释器执行这些脚本，最终生成模型。这个过程是“文本 → 程序化代码 → 几何内核 → 模型文件”。

这条路线的选择其实是必然的。早期确实有很多研究尝试用扩散模型或以GAN为代表的对抗网络直接从点云或体素空间生成模型，效果怎么样呢？说实话，演示视频都很惊艳，一到实际工程就露馅。直接生成点云或网格的问题在于：生成的几何没有设计历史，没有参数化关系，更谈不上可编辑性和装配约束。车间师傅拿到一个网格文件，想改个孔位、孔径、板厚，根本无从下手——不如重新画一个来得快。而程序化建模恰恰相反，它把模型变成代码，代码里的变量就是参数，改孔径就是改一个数字，改阵列间距就是改一个变量，这才是工程师需要的“可编辑性”。

1.2 从模型生成到代码生成的范式转移

我理解text-to-cad本质上是把问题从“几何生成”变成了“代码生成”。这看似是换了个赛道，实际上是聪明得多的一条路。

为什么这么说？因为自然语言模型（也就是大语言模型）最擅长的恰恰就是代码生成。经过海量代码语料训练的模型，在写OpenSCAD脚本、PythonOCC调用、CadQuery链式操作方面有着天然优势。它不需要“理解”三维空间，它只需要理解“如何用代码描述三维空间”就够了。而代码的执行结果是确定性的——同样的脚本在几何内核里跑出来永远是一样的模型，这比从隐式场采样出点云再重建表面要稳定得多。

另外，代码生成天然解决了“多样性”与“可控性”的平衡问题。你给同一段提示词，模型可能生成若干个不同代码版本，每个版本对应一个略有差异的模型。如果其中某一个不满足需求，你可以直接在代码层面修，而不是重新让模型生成。这种交互方式更贴近工程师的调试习惯——先跑通，再调参，不行就改，而不是“一个prompt定生死”。

说白了，代码生成路线把“结果黑盒”变成了“逻辑白盒”。这是它能被工业界接受的根本原因，也是我在实际使用中最认可的一点。

1.3 边界条件：能做什么，不能做什么

我在深入测试后总结了一下text-to-cad目前的能力边界，方便各位有个正确预期。它擅长的是规则化的机械零件，比如支架、法兰、箱体、外壳、管路接头，这些东西的特征都很清晰——拉伸、切除、阵列、倒角、螺纹孔、通孔。但一碰到自由曲面造型（比如汽车A柱内饰、人体工学鼠标外壳）就抓瞎了，不是生成不了，是生成的网格质量和曲面连续性完全达不到正向设计要求。

对于装配体场景，它能做的也比较有限，现在最多生成几个零件的组合体，但零件之间的配合关系、运动副约束、干涉检查这些，基本上还是空白。另外，如果需求里涉及标准件库调用（比如GB/T、ISO标准的螺栓螺母），目前主流工具也没法自动匹配型号。这些都是我在实测中踩过的真实边界，不代表未来不能突破，但如果你想用现阶段的text-to-cad去做整机设计，我只能说“还差得远”。

2. 完整技术解析：text-to-cad的流水线到底怎么跑

2.1 阶段一：几何语义理解

整个管线的最前端是自然语言理解。这看起来跟通用的大模型对话没区别，但实际上有很强的领域特殊性。你输入“一个带四个M6通孔的安装板”，通用模型会理解成“有一个板子，上面有四个孔”；但text-to-cad模型需要理解的是更精确的信息：M6代表孔径6.5mm左右的通孔（因为螺纹孔的底径和贯穿孔不同），四个孔是呈矩形阵列还是圆形分布，孔的间距是多少，板厚是否与孔位产生干涉。这些都是几何语义层面的理解，远比“字面意思”复杂。

我在测试中发现，当前优秀模型对这类结构化描述的理解已经相当准了。给它“直径50mm的圆形法兰，厚度8mm，均布6个M8通孔”这样的输入，它能正确推断出分度圆、均布角度，甚至会自动加上沉孔或倒角。但它对模糊语言的处理能力还比较弱。比如你说“一个不大不小的支架”，它通常会默认出一个200x200x10的方板——这其实是模型基于训练数据分布做的猜测，而不是真正理解“不大不小”在你的场景里意味着什么。

这个环节的关键技术是“指令跟随”（instruction following）和“几何常识推理”（geometric commonsense reasoning）。前者决定模型能不能严格按照你的约束条件执行，后者决定模型能不能在缺少参数时做出合理的默认假设。我个人的使用心得是：尽量把约束写死，不要给模型“自由发挥”的空间。

2.2 阶段二：程序化建模代码生成

这是整个系统最核心的环节。模型将解析后的几何语义翻译成可执行的程序化建模代码。目前主流的选择有三类，各有取舍。

第一类是用OpenSCAD。它的脚本语法是类C风格的CSG（构造实体几何）语言，减材、加材、交集、平移、旋转都极其直观，代码量也小。例如做支架，就是union + difference的组合，一眼就能看懂。OpenSCAD的缺点是从业者并不太用它做高复杂度建模，因为它的GPU渲染和交互预览能力比较弱。

第二类是CadQuery。这是一个Python库，它继承了OpenSCAD的“代码建模”思想，但加入了更高级的B-Rep（边界表示）操作，比如倒角、抽壳、放样、扫掠。CadQuery生成的模型可以直接导出STEP，这个格式对工程师来说要比OpenSCAD的STL友好得多。我在测试中的感受是，CadQuery代码更长，但生成能力的上界明显更高。

第三类是直接调用Fusion 360或SolidWorks这类商业CAD软件的API，对应到主流商用产品（如AutoCAD AI）就是这条路线。它不像前两种方案那样“从零建模”，而是通过API复用了成熟的内核能力，特征树里每一步都清晰可见。但它的限制在于API本身的设计和产品生态强绑定，离了软件就跑不动。

模型在生成代码时，往往不是一步到位的。它先起草一个大的结构轮廓，然后逐步补充细节特征。比如生成法兰时，先有基础旋转体，再挖中心孔，再打螺栓孔阵列，再做倒角，每一步都在代码里以函数调用或特征的形态出现。这种渐进式的构建方式跟人类工程师建模的思维是完全一致的——先粗后细、先主后次。

2.3 阶段三：渲染验证与迭代

代码生成了，并不代表万事大吉。与纯文本生成不同，代码生成的模型必须经过“执行验证”。系统会在解释器里运行这段脚本，如果语法错误或者参数越界，就要回退重试。跑通之后还要在内存中渲染出一个三维预览，让用户第一时间看到产物是否符合描述。

这里的核心逻辑是自我纠错循环。好的text-to-cad工具不仅仅是一次性生成，而是会模拟工程师的调试过程：先假设一个方案，渲染出来看效果，发现不对就修改代码参数重新执行，最多可以迭代几十轮。这在大模型的工程化产品中非常重要，因为模型生成代码的“一次成功率”并没有想象中那么高，这和我实际测试的数据是吻合的：简单零件一次成功率约80%，复杂零件迭代十几次才能稳定。

渲染验证环节对算力也有一定要求。如果系统在云端跑，批量渲染时需要用GPU加速；如果本地跑，即使是CPU用OpenSCAD的CGAL内核渲染中等复杂度的模型，也可能需要几秒到几十秒不等。所以在实际使用中，我建议大家不要频繁调整无关参数触发重新渲染，集中把描述改到位了再让系统执行，能省不少时间。

2.4 阶段四：导出与后处理

最终，系统会把验证通过的模型导出为常见格式。STL是默认选项，因为几乎所有几何内核都能输出STL；STEP格式则在工业交换中更重要，因为保留B-Rep信息，能被CAD/CAE/CAM各类软件正确处理。早期的text-to-cad工具大多只输出STL，现在主流产品基本都支持STEP了——这一步升级对于工程落地来说意义重大，因为STEP文件才能真正导入NX、Pro/E做后续工艺设计。

我在实操中建议做三个后处理动作。第一，检查单位。不同的建模库默认单位不同（有的是mm，有的是inch），单位错了就是整个零件放大25.4倍的灾难。第二，清理几何偏差。代码自动生成的模型里，平面不共面、孔轴线倾斜这类微瑕疵并不少见，最好导入专业的CAD软件里跑一次几何检查。第三，补特征属性。比如材料、表面粗糙度、公差这些代码不一定带得上，工程交付时手工加上。

注意：在文本生成阶段就要注意使用规范表述，避免“大约”“左右”“差不多”这类模糊语言。模型没听懂你真实的精度要求时，默认值往往会让你惊喜（或者说惊吓）。

3. 主流方案与工具选型对比

3.1 公开Demo级方案：值得玩，不值得依赖

现在网络上有很多text-to-cad的公开Demo，比如基于大模型微调的Web演示。这些产品在交互上做得非常讨巧：一个文本框、一个生成按钮、一个三维预览窗口，30秒出结果。我在尝试了若干款之后，把它们统一归类为“Demo级方案”。

它们有一个共同特点：生成结果的视觉冲击力很强，但文件质量和可复用性堪忧。同样一句话“做一个传动轴支架”，渲染图上看起来像模像样，导入到SolidWorks一看——是一堆离散三角面片组成的网格体，甚至还有自交面。这类工具适合你给客户展示“AI能做什么”，或者给设计评审做前期概念参考，但指望直接投入生产流程，目前仍然是风险极高的。

如果你只是个人学习或做概念验证，我很推荐先从这类方案玩起。不需要配置任何环境，打开网页就能体验完整的文本建模思路。但你要关心的是“这个模型对不对”，而不是“这个渲染图好不好看”。后者会严重高估工具的可用性。

3.2 开源Pipeline方案：可控性强但门槛不低

接下来一类是开源或半开源的本地部署方案，典型的技术栈是：用微调后的CodeLLM生成CadQuery代码，在本地用Python环境执行，再用OpenCASCADE内核渲染。这类方案的最大优势是可控性和可扩展性都很强，你可以自由调整模型参数、切换基座模型、甚至更换建模后端。

我搭过一个mini版，大致的架构是这样的：模型用7B参数的代码生成模型做底座，微调数据集来自公开的CAD程序库。推理时，用户输入自然语言，模型输出CadQuery Python代码；然后我在脚本里用exec()执行，并捕获异常；成功后用pyOCC或者CadQuery内置的三维视图渲染预览。整个过程复杂度不算高，真正难的是前期的数据清洗和模型微调。

如果你的目标不是研究算法而是作为工具使用，我的建议是直接选一个维护活跃的商用开源库，不要自己从头建档。个人开发者做微调，数据量一般都不够，效果还不如直接用通用代码模型，对OpenSCAD和CadQuery的指令理解基本及格。与其纠结模型，不如把精力花在工程脚本和后处理管线上，把从代码到STEP、从STEP到批注检查的过程跑顺了，这套工具才具备实际产出价值。

3.3 工业级方案：CAD软件的官方AI能力

第三类是大型CAD厂商自己做的AI集成，目前来看是最接近“能用”的状态。为什么？因为这类工具直接生在CAD内核里，生成的每一步都对应到原生的特征操作，比如Extrude、Hole、Fillet，特征树是完整可编辑的。你可以在生成过后直接改草图尺寸、改拉伸距离、增删特征，完全不像前两类方案那样“生成完就定型”。

这类方案我也实测过，优点很突出，缺点也很突出。一是目前支持的特征类型和几何操作仍然有限，复杂扫掠、多实体布尔、曲面裁剪这些操作，AI经常生成失败；二是它深度绑定自家生态，生成的模型能被自家软件完美识别，但导到别的平台可能会丢特征树，退化为网格体；三是license成本不低，对个人玩家不太友好。

做选型判断时，我总结了一个非常简单粗暴的标准：如果你只是做概念验证和展示，选公开Demo；如果你在做一个内网工具，希望提高设计效率而不在意可编辑性，选开源Pipeline自己做二次开发；如果你是设计工程师，希望在CAD软件内真正产出可迭代的零部件模型，那大概率只有原生方案能满足。

我把关键使用场景和现状列成一张速查表，方便你直接对号入座：

3.4 选型之外：数据与训练是真正的护城河

很多人选型时只盯着“产品功能列表”，但我建议用一个额外的视角去看：数据从哪来，怎么清洗的。text-to-cad场景里，模型的真实边界由训练数据决定。如果训练数据里大多是规则机械零件，那你很难指望它生成优秀的外观曲面；如果训练数据里没有某个行业的特殊标准（比如管道设计的BOM规范、钣金折弯扣除系数），那它对这领域的“理解”就只是泛泛而谈。

所以我的建议是，选型之前先看它支持的案例库和模型覆盖领域。你可以故意找几个冷门需求去测试模型（比如“带梯形槽的同步带轮”“非标的三角形法兰盘”），看它的处理能力。这比看官方宣传页面要靠谱得多。

4. 实操经验：从零搭一个mini text-to-cad管线

4.1 选型与准备阶段

我决定自己动手搭一套入门级text-to-cad管线时，第一件事不是写代码，而是把Python环境整好。这里强烈建议用conda建独立虚拟环境，因为这一套技术栈对依赖包版本非常敏感——我因为没有隔离环境，搞崩过不止一次系统Python。

依赖包准备主要分三层：模型层（负责文本到代码），代码解析层（负责执行生成的脚本），几何内核层（负责把脚本变成模型）。

针对模型层，可以先从Hugging Face上找一个擅长Python代码生成的模型，比如CodeLlama、DeepSeek-Coder、Qwen-Coder。这些模型的底座能力已经够强，不强求微调。实测下来，7B参数级别在简单零件场景下完全够用，13B/34B在复杂场景下稳定性更好，但显存占用也会显著增加。

代码解析层用Python原生即可。几何内核层主流选择是CadQuery，因为它比OpenSCAD更适合后续的STEP导出和参数化操作。CadQuery底层依赖OpenCASCADE，这两者配合，基本能覆盖机械零件90%的常规特征操作。安装时注意要选跟你Python版本匹配的wheel包，否则编译会让你怀疑人生。

4.2 核心代码实现：文本到STEP的完整闭环

我的实现思路是这样的：构造一个收窄了的专家提示词，把用户的自然语言描述“翻译”成CadQuery代码，再执行代码并导出STEP文件。整体代码如下，你可以直接运行试试。

import cadquery as cq import openai import os import re # 第一步：把自然语言描述翻译为CadQuery代码 def nl_to_cadquery_code(description: str, model="deepseek-coder-7b") -> str: prompt = f""" 你是一名机械设计工程师，熟悉CadQuery库。 请把下面这段自然语言描述转换为CadQuery代码。 要求： - 只用CadQuery库，不引入其他复杂依赖 - 所有尺寸以毫米为单位 - 代码中必须包含最终对象变量名为 final_part - 只输出纯代码，不要任何解释文字 自然语言描述： {description} """ response = openai.ChatCompletion.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=0.7, ) raw_code = response["choices"][0]["message"]["content"] # 清洗markdown代码块标记 code = re.sub(r"```python|```", "", raw_code).strip() return code # 第二步：执行CadQuery代码并捕获异常 def execute_cadquery_code(code_str: str) -> cq.Workplane: local_namespace = {"cq": cq} exec(code_str, local_namespace) result = local_namespace.get("final_part") if result is None: raise ValueError("模型未生成final_part变量") return result # 第三步：导出STEP文件 def export_to_step(part, output_path: str): cq.exporters.export(part, output_path, cq.exporters.ExportTypes.STEP) print(f"已导出STEP文件到: {output_path}") if __name__ == "__main__": user_input = "长100mm宽50mm厚5mm的矩形板，四角打四个直径6mm通孔" code = nl_to_cadquery_code(user_input) print("生成的CadQuery代码:\n", code) try: part = execute_cadquery_code(code) export_to_step(part, "output.step") except Exception as e: print(f"执行失败，需要返回模型重试: {e}")

这段代码看起来很简单，但它是整个管线的核心骨架。实际跑的时候你会遇到各种奇奇怪怪的问题，比如模型输出了unit = "mm"这种赋值语句但没执行单位设置，或者代码里引用了cq.Workplane("XY")拼错的情况。异常捕获和回重试机制是必须的。

根据我的测试，7B模型处理“长100mm宽50mm厚5mm的矩形板，四角打四个直径6mm通孔”这类描述，一次生成正确代码的概率极高，因为这是训练语料中常见的标准操作组合。但如果你让它生成“R角半径8mm、表面喷砂处理、边缘去毛刺”这种带工艺信息的描述，模型往往不知道如何把它转成几何操作——它可能会导入一个不存在的图层属性，或者直接忽略。这是当前模型对“制造语义”理解的局限，不是简单的调参能解决的。

4.3 从代码到模型的细节处理：单位、坐标系与容差

如果说生成代码只占了30%的工程量，那剩下的70%都在处理“工程化细节”。“单位问题”是首当其冲的——CadQuery默认单位是mm，但模型生成的代码有时会用到inch换算或者干脆不管，输出模型可能在毫米和英寸之间摇摆。我的处理方案是在代码执行后加一个强制校验：检查关键尺寸是否落在合理区间（比如长宽在1mm到1000mm之间），如果不合理就标记异常并重新生成。别嫌这个办法笨，在实际使用中它比让模型“理解”单位制可靠得多。

坐标系问题同样隐蔽。CadQuery默认以XOY平面作为建模基准面，厚度的拉伸方向是Z轴正向。但如果模型生成的代码里用了Workplane("YZ")或者Workplane("front")，零件可能就躺倒了。我在最初的测试里就遇到过一个“立着的板子”——Z轴方向上长100mm，厚度反而只有5mm，这种错误极其容易漏过渲染审查。

还有一个容易被忽略的点是容差设置。CadQuery的Workplane对象里的clean操作会在布尔运算时自动清理小特征，但清理的阈值受模型精度影响。如果容差设得太大，Thread（螺纹）这一类细碎特征会被抹掉；设得太小，布尔运算可能会失败。我个人的经验是对于小尺寸零件设为1e-6比较保险，标准零件保持在默认值即可。

# 强制设定容差，避免小特征被清理 cq.Workplane("XY").box(100, 50, 5).edges().fillet(2).val()

4.4 生产级工程用的正向设计要补哪些东西？

如果你的目标是把mini管线变成生产环境工具，至少还要补两块内容。第一块是“模型能直接出图纸”。设计交付的最终产物不只是三维模型，还包括二维工程图——尺寸标注、公差、表面粗糙度、技术要求。CadQuery可以直接生成SVG或DWG格式的二维视图，但标注位置和样式往往需要人工调整。想全自动出图，目前来看还是遥不可及，我建议半自动：AI出主体，人工补标注。

第二块是“和现有PDM/PLM系统对接”。设计数据要进入企业管理系统，必须带上物料编码、版本号、审批流程状态。这不在text-to-cad的能力范畴内，但你一旦要规模化落地，这部分才是真正的成本大头。我对工程师朋友的建议是：先在一个零件类型上跑通全流程，验证ROI，再逐步铺开，不要一开始贪多求全。

4.5 提示词策略：给AI建模，关键是“有尺寸，有顺序，有优先级”

我在大量测试中发现，提示词质量对生成结果的影响比想象中大得多，很多时候甚至超过模型本身的能力差异。在text-to-cad场景里，一段合格的提示词至少有三层结构。

第一层是几何主体描述，用数量和尺寸说话。与其说“做一个带孔的法兰”，不如说“外径120mm、内径70mm、厚度15mm的法兰盘”。这里的常量要具体到数值，哪怕你不确定，也要给模型一个锚点，让它建立基本比例感。

第二层是特征顺序描述，你要按照“主轮廓 → 切除特征 → 阵列特征 → 修饰特征”的顺序组织语言。因为CadQuery的代码也是按这个顺序链式操作的，顺序对了，模型生成代码时就更不容易乱。比如“先做一个80x60的椭圆底座，再沿长轴方向拉伸30mm厚度，然后切除中央直径20mm的中心孔，最后四角加R5圆角”。

第三层是约束优先级说明。什么是绝对不能改的，什么是可以妥协的。我在测试时发现，如果你写“M8螺纹孔”但没写孔的数量和位置，模型经常自创一个“围绕法兰均布8个孔”的方案，这是完全不可控的。你需要在提示词末尾明确“所有特征参数，均需严格按照以上数值生成，不得额外增加特征”。这句话看着普通，但对模型的“小心思”有很强的压制力。

我用这个三层结构去测过多个模型，生成成功率比“平铺直叙一口气描述完”高出30%以上，而且输出代码的规范程度也明显更好。这算是我这篇实操心得里最值钱的经验之一了。

5. 常见问题与避坑排查实录

5.1 代码生成常见的“伪正确”

表面现象是：text-to-cad过程非常顺利，没有报错，渲染也很漂亮，但你把模型拿到专业CAD软件里一检查，发现完全没法用。这个问题是生成失败里最隐蔽、也最浪费时间的。

典型的例子是孔的生成。CadQuery的hole()和csk()在语义上是有区别的——前者是通孔，后者是埋头孔。如果模型生成的代码里把“沉头孔”写成了普通通孔，程序不会报错，渲染图看起来也是个孔。你也不会第一时间发现错，直到装配时螺栓头怎么都沉不进去，才开始排查。我后来总结的经验是，涉及孔特征时，在代码执行前强制加上检查规则，用正则去扫描代码，看关键字是否和需求匹配。

还有一类“伪正确”是阵列特征的中心距问题。rArray和polarArray生成了正确的阵列数量，但间距值却凭空多除或者少除了一个数。渲染图能看，实际尺寸是错的。人工检查代码时一定要逐行核对输入参数是否一一对应，别指望“看起来差不多就行”。

5.2 解析器和几何内核的“隐性冲突”

有一次我生成一个带倒角特征的壳体，代码在CadQuery的默认环境下执行时报错，提示CQ object is not callable。我排查了很久才发现问题根源：模型生成代码时调用了cq.Workplane(...).faces()，而我在自定义的解析器里优先注册的cq命名空间与CadQuery版本冲突，导致方法解析混乱。这个问题的坑在于，报错信息只会告诉你哪个对象调不起来，不会告诉你为什么调不起来。

解决办法有两个，一是把cq的引用方式改成显式import cadquery，减少别名冲突；二是把解释器的执行环境和主程序环境隔离，在单独的进程或容器里跑解释器，避免依赖冲突。我自己的做法是直接用subprocess开一个子进程来执行生成的代码，父进程只负责传参和收结果，一点环境上的冲突都没有。作为自动化工具，这个架构在某些方面也更干净——生成的代码如果有恶意的系统调用，也不会影响到宿主机。

5.3 API的权限、配额与计费坑

如果你想基于模型服务商的API接口（比如OpenAI、Anthropic或云厂商的模型）来搭建服务，那要面对的问题就是“每生成一次都花钱”。但最坑的还不是花钱，而是API的配额限制。我在压测时遇到过次数限制拦路的情况，导致整个流程突然中断。解决方案是加一个本地的大模型底座备用方案，API主备切换，一次请求失败就用本地的模型顶上。注意，两个模型的生成质量会有差异，这不影响流程跑通，但会影响对效果的一致性预期。

一个小技巧：请在调用时把temperature参数调到0.1或0.2，输出代码的稳定性会显著提高。温度太高，模型容易“灵光一现”写出花活代码，虽然有时候确实妙笔生花，但产生奥妙不可复现的问题时，排查成本远远大于收益。

5.4 模型输出的“幻觉特征”问题

有一次我输入“做一个简单的电机安装支架”，模型生成的代码里凭空多出了两个M4螺纹孔。我反复确认了提示词，里面没提到任何孔。这就是典型的“幻觉特征”——训练数据里“电机安装支架”和“螺纹孔”共现得太多，模型就自己“脑补”上了。

这问题在工业场景下相当危险。如果不对抗它，轻则交付时尺寸审核不通过，重则导致干涉、装配失败。我的应对策略有两个：一是在提示词末尾加上强约束语句，明确“不得在未指定的情况下添加任何孔、倒角或额外特征”；二是在代码执行之前和之后各做一次特征语义的“差集检查”——忽略掉所有非用户指定的特征，让模型重新生成。这个“两遍生成”的方法诚然增加了成本，但对特高风险零件（比如配合面、受力件）来说非常值得。

5.5 部署与调优：性能数据与逃不掉的显存门槛

关于本地部署，我把一些实测数据列出来供你参考。使用CadQuery作为后端时，生成一个中等复杂度零件（约含50个特征操作）的代码推理耗时约为5~10秒（取决于模型大小和推理框架），代码执行建模耗时约1~3秒，STEP导出不到1秒。瓶颈永远在模型推理阶段，而不是几何内核执行阶段。

如果你没有本地GPU，纯粹想在CPU上跑，那也不是不行，但你要愿意等。我用纯CPU跑一个7B模型生成代码，用了约3分钟。这个速度只适合离线批量，不适合实时交互。显存方面，7B模型INT8量化后约需8GB显存，13B约需14GB，34B至少24GB。这个门槛直接把个人玩家挡在了大模型门外，也解释了为什么大部分人更愿意用API。

5.6 错误消息与速查表

如果你在实操中也遇到问题，可以把下面这张排查表存起来，这完全是我根据自己的踩坑记录整理出来的。

6. 写在最后：我的一些私房体会

整体玩下来，text-to-cad给我最深的感受是：它不是“一键出图”的魔法，而是一种“语义驱动的参数化建模范式”。它把设计师从“怎么一步步画出来”的繁琐操作中解放出来，让你更多去思考“我想要一个什么样的零件”。这套工作流对规则化的机械零件特别顺手，对创意曲面造型则力不从心。如果你明确把它定位在“早期概念生成+重复性标准件自动化”这两个场景，那它绝对是当下效率提升最猛的工具；如果你指望它替代专业建模软件的全部功能，那大概率会失望。

我踩过最大的一坑是“盲目信任渲染图”。记住一个原则：一切以导出的STEP文件在专业软件里的检查结果为准，而不是以AI工具自己渲染出来的预览图为准。这两个结果之间可能有微妙差距——渲染图是轻量化的网格快照，STEP文件是真实边界表示的数学模型——工程交付要的是后者。

如果你准备自己动手搭管线，我给三个小建议。第一，环境隔离要做好，conda + 子进程执行是避坑利器。第二，先在小数据集上验证提示词模板，让模型输出风格稳定下来，再考虑换更大模型。第三，保留好每一轮生成失败的代码和日志，text-to-cad这个领域迭代极快，失败样本是改进提示词和判断模型进步的最宝贵素材。希望这篇分享能帮你少走弯路，快速建立起自己的text-to-cad工作流。