企业官网建设流程全解析

上周同事扔给我一张手绘草图，说“就这个法兰，四个安装孔的位置稍微挪一下”。我改到第三版的时候忽然意识到，如果有一条流水线能把“描述需求”直接变成“可编辑的数模”，这种来回返工至少能省掉一半。我正在折腾的方向，就是这两年设计圈讨论度很高的 text-to-cad：用自然语言描述零件或结构，让大模型理解设计意图，再通过代码生成的方式输出真正可编辑、可装配、可出图的CAD模型。它适合每天做非标件、频繁改结构的设计师，也适合想让三维建模门槛降下来的3D打印玩家。下面这些内容是我实际搭建和跑通这条链路后的经验记录，希望能让后来的人少踩几个坑。

1. 技术路径拆解：为什么“代码生成”才是text-to-cad的主赛道

1.1 三条路线的真实对比

我最早接触text-to-cad时，第一反应是“让大模型直接输出一个.obj或者.step文件不就行了吗”。真去试了才发现，这条路在工程上非常难走。三维模型本质上是一堆点、面、拓扑关系，纯文本输出格式就算勉强写出来，也基本没法保证“水密”、自交、法向一致这些几何基本要求。

目前市面上能看到的主流方案可以粗略分成三条路线。

路线A是“LLM直接生成模型文件”，比如让模型输出一段OBJ格式的顶点和面索引，或者生成STEP的文本片段。优点是省事，缺点是几乎不可用。三维格式的token效率极低，一个简单的立方体要输出几十行坐标，稍微复杂一点的特征就把上下文窗口撑爆了。更麻烦的是，模型不懂几何拓扑约束，输出的面经常是反的，顶点顺序一错，模型直接报废。

路线B是“LLM生成参数化建模脚本”，把自然语言转成CadQuery、OpenSCAD、FreeCAD的Python脚本或CSG声明式语言。这条路线是我现在的主力方案。它的核心逻辑是把几何问题转化成代码问题，代码可以用解释器执行、渲染、报错，模型在报错的引导下反复修正自己，直到出图成功。

路线C是使用扩散模型或隐式场做端到端生成，输入文本输出体素或神经隐式曲面。这条路线论文里效果很好看，但从实际落地来看，精度低、可编辑性差，生成的是“一张图片式”的网格，根本没法进入工程流程。

三条路线的对比结论其实很明确：当前工程可用度最高的是路线B。它把“不可验证的几何生成”变成“可验证的代码生成”，每一步都有中间表示可以检查，这正好命中了大模型能力的天花板和短板。

1.2 可编辑性才是真正的前提条件

很多没做过设计的人会问：能出一个模型不就行了，为什么非要可编辑？因为在真实工作流里，设计是“改”出来的，不是“生成”出来的。

你拿自然语言让模型生成了一个支架，看起来结构对，但孔位要往后挪3毫米，筋板要加厚到8毫米，这些需求在后续装配中随时会发生。如果模型输出的是一块不可拆分的网格，那这模型就是一次性道具，设计人员还得重建一遍；如果输出的是参数化脚本，那改一个数字就完成一轮迭代。

这里面的本质区别在于：CAD模型的本质是“特征树+约束”，而脚本本身就是特征树的文本表示。CadQuery里每一条box、cut、hole，都对应着设计意图的修改操作，这个过程是可追溯的、可回滚的。OpenSCAD里的difference、hull，本质上就是布尔运算和特征叠加。让大模型写脚本，等于让它在设计特征的空间里工作，而不是在离散三角形的空间里硬拼。

我自己的体会是，可编辑性这个门槛决定了text-to-cad到底是一场技术表演，还是一个能融入现有设计流程的生产工具。凡是把“生成”作为终点的方案，基本都停留在玩具阶段；凡是把“生成脚本+参数回传”作为闭环的方案，才真正有落地的希望。

2. 工具链与选型参考：从开源脚本到在线服务

2.1 脚本侧主力：CadQuery、OpenSCAD、FreeCAD

要搭text-to-cad工作流，第一步是选一个能被大模型“写好”并且能稳定执行的建模脚本语言。我试过的工具里，最值得推荐的是CadQuery、OpenSCAD，以及正在快速成熟的build123d。

CadQuery是基于Python的参量化建模库，它的写法非常接近人类的建模步骤：先在平面上建立工作平面，再来拉伸、切孔、倒角。大模型对这种“步骤化”的API理解得很快，因为它和人们描述建模过程的方式高度一致。OpenSCAD则更适合纯逻辑驱动的造型，它的语法是函数式CSG，特别适合那些能用“差集、交集、平移、循环”表达的结构，比如齿轮、多孔板、格栅。

FreeCAD的Python API也可以走这条路，但它的API相对厚重，大模型驾驭不好，所以我在快速原型阶段几乎不碰它。以下是我对这些工具的简单对比。

如果只想选一个起步工具，我建议直接选CadQuery。它生态最完整，导出STEP、STL都很成熟，而且大模型的训练语料里相关的代码示例足够多，生成质量相对稳定。OpenSCAD可以作为第二工具补充使用，用来生成那类“用循环描述几何”的零件。

2.2 端侧模型与在线服务

除了自己写代码，市面上也出现了不少号称text-to-cad的在线服务和研究项目。有些是公司做的编辑器插件，输入一句话自动生成基础模型；有些是学术机构放出来的实验模型，能读文本并输出CAD脚本或网格。它们的出现说明这个方向正在被更多人看见，但说实话，实验室工具离生产还有很长距离。

我试用过几类工具后总结下来的经验是：在线服务通常擅长“听起来很酷的单体造型”，比如一只椅子、一个花瓶、一个抽象雕塑，但一旦涉及工程上常见的长宽高尺寸、公差、配合关系，它们就立刻露馅。原因很简单，工程需求的约束是硬性的，差1毫米装配就过不去，而生成式模型天生擅长模糊匹配，不擅长硬约束。

所以我的建议是：在线服务可以拿来找灵感、做概念阶段的视觉参考，但真正的设计交付物，还是靠自己搭的“大模型+脚本”链路来保证。别把自己的交付能力绑在一个不透明的在线接口上，很多时候你连它是怎么生成、能不能复现都不知道。

3. 从零搭一个text-to-cad工作流demo

3.1 环境准备：Python + CadQuery + 大模型API

我这里直接给一个能跑通的最简配置。假设你的机器上已经有Python 3.10以上版本，那么只需要用pip安装CadQuery，再准备好一个云端大模型API的调用密钥即可。

pip install cadquery

安装完成后，可以用下面这段代码验证CadQuery是否能正常工作。

import cadquery as cq part = ( cq.Workplane("XY") .box(60, 40, 10) .faces(">Z") .workplane() .rect(6, 6) .cutBlind(-10) ) cq.exporters.export(part, "test_box.step")

这段代码创建了一个60乘40乘10毫米的长方体，然后在顶面挖了一个6乘6毫米的方孔。如果程序能跑通并生成test_box.step文件，说明环境已经就绪。大模型API这里就不指定具体厂商了，当前主流的云服务都能胜任，关键是要在请求中明确要求“只输出CadQuery代码，不输出解释”。

3.2 Prompt模板与几何描述词汇表

环境解决之后，真正决定生成质量的是提示词设计。很多人用text-to-cad失败，不是因为模型不行，而是因为prompt里写的是散文，不是工程需求。模型擅长理解“四个角上有孔”这种自然语言，但如果你希望孔的位置精确，就必须给它明确尺寸和数据。

我这里有一个反复验证过的模板，基本可用。

你是一位参数化CAD工程师，熟悉CadQuery。 当前零件单位全部使用毫米(mm)，坐标系Z轴向上。 请根据以下需求生成CadQuery代码： 任务：设计一个矩形法兰底座。 尺寸：长60mm，宽40mm，厚10mm。 中心有一个6mm x 6mm的通孔。 四个角各有一个直径6mm的安装孔，孔中心距较近边缘的距离为10mm。 要求： - 只输出Python代码，不要输出解释。 - 使用cadquery库，导出STEP文件。 - 不要使用不存在的API，不要使用未定义的变量。 - 先写代码，再以注释形式标注每个特征的尺寸。

注意“先写代码，再以注释形式标注每个特征的尺寸”这句话很重要。它能让模型在输出代码时回到可解释的设计特征思路，而不是生成一串难以理解的数字堆积。你还可以在系统提示词里维护一份“几何描述词汇表”，比如“通孔=完全贯穿”“盲孔=只挖到一定深度”“沉头孔=锥形底部”，这能显著减少歧义。

3.3 闭环校验：编译、渲染、反馈、修正

拿到模型生成的代码并不等于拿到模型，必须经过执行和校验。我会把大模型输出的代码保存成一个临时文件，用CadQuery执行并导出STEP，再用可视化工具或免费查看器快速检查轮廓。如果代码报错，就把错误信息连同原代码一起回传给大模型，让它修正。

这里给出一个自动循环的框架，可以直接抄走。

import cadquery as cq import subprocess def run_cq_code(code: str): try: exec(code, {"cq": cq, "export": cq.exporters.export}) return None except Exception as e: return str(e) user_prompt = "设计一个矩形法兰底座，长60宽40厚10..." last_error = None for attempt in range(4): if last_error: prompt = user_prompt + "\n\n上一次生成的代码报错了，报错信息：\n" + last_error + "\n请重新生成完整可运行的代码。" else: prompt = user_prompt code = llm_generate(prompt) error = run_cq_code(code) if error is None: print("生成成功") break last_error = error

我实际跑下来的经验是，大部分第一次生成的代码会卡在“API记忆混乱”上，比如CadQuery版本之间的函数名差异、忽略面选择的写法不对，但只要把报错回传，模型自己改对的比例非常高。三到四轮之内基本能产出可用的STEP文件。

4. 实测踩坑记录：LLM写CAD最容易翻车的五个场景

4.1 单位与坐标系的混乱

这是最常见、也最隐蔽的问题。大模型在训练语料中见过大量混合单位制的内容，它可能上一秒在用毫米，下一秒就切到英寸。装配场景下尤其危险，一个零件是60毫米，另一个零件是6厘米，看起来数值不同，实际相等，但如果是英寸与毫米混在一起，装配体直接乱套。

我的对策是在每一次请求里都显式声明“单位全部使用毫米，坐标系Z轴向上”，并把这句话放在prompt的最前面，而不是垫在最后。更重要的是，生成完成后要抽查代码里的关键尺寸是否和需求一致，不要默认模型执行了你的单位约定。

4.2 拓扑错误与布尔运算失败

模型生成的代码执行不报错，不代表几何正确。最容易踩的一个坑是布尔运算导致的面缺失或自相交。比如在CadQuery里用cut操作切孔，如果草图没有闭合，有时不会报错，但生成的重心或体积计算会异常；在某些情况下，导出的STEP文件进入CATIA或SolidWorks时会被提示几何有问题。

对策是坚持“先构建闭合截面，再拉伸或切除”的思路。我在prompt里会明确写：所有草图必须闭合，所有拉伸必须指定长度，禁止依赖默认值。这个习惯帮我避开了大量后续问题。如果需要做严苛的仿真前处理，生成后还要专门做一步几何修复，比如导入到FreeCAD里用Shape Validator检查精度容差。

4.3 命名冲突与装配配合问题

当模型生成一个包含多个特征的零件时，它经常给每个草图或特征取一个通用名字，比如rect、hole、cut，重复命名会直接导致代码失败。有时候循环体内创建的边或面没有显式命名，后续引用时根本找不到对象。

我解决这个问题的方式有点土但很有效：让模型在生成代码时“每个特征使用带语义的变量名”，比如flange_base、center_hole、mounting_hole_front_left。大模型对这种要求适应得很好，一旦命名清晰了，后续的代码修正、参数改动都变得顺很多。对于大型装配体，我会要求模型使用显式的workplane和tag标记，而不是依赖默认选择，这样装配时不会选到错误的表面。

4.4 模型幻觉：一本正经地写不存在的API

这个现象在大模型写代码时太常见了。模型可能写出一个看起来很有道理、但CadQuery库里压根不存在的函数，比如extrude_from_face，或者一个不存在的参数名。代码执行时立刻报错，报错信息投喂回去后，模型往往又会在下一轮编一个新的API出来。

要制住这个毛病，就得在prompt里限制“只能使用以下API”，并附上一小段可用的API示例代码，让模型照葫芦画瓢。你可以把自己验证过的示例代码贴进去，比如上面的法兰底座代码，模型会模仿这段代码的写法，大幅减少幻觉。实测下来，给一段示例代码比在prompt里写十句“不要编造”都管用。

4.5 上下文丢失与多轮修改歧义

在多轮修改中，用户经常说“把孔往左挪一点”，但“左”到底朝哪个方向、挪多少，模型完全没概念。更常见的是，模型在第三轮修改时已经忘了第一轮生成的零件长什么样，直接在新结构上重复挖孔，结果整个模型多出几十个孔。

我现在的做法是：每一轮修改时都把“完整的需求文档+上一轮成功代码”一起发给模型，而不是只发送“请把XX改一下”这一句话。同时要求模型在代码里保留所有原有特征的参数定义，只改动目标参数。任何“改一下”的描述都必须补充具体尺寸或百分比，否则退回去确认需求后再动手。

5. 应用场景与落地边界：text-to-cad到底适合做什么

5.1 能做的事：快速概念样件、标准件、参数化模板生成

text-to-cad目前最适合的场景，首先是非标零件的概念设计。比如客户说“我需要一个能装在40毫米方管上的L形支架，带两个腰形孔”，传统做法是找模型库、量尺寸、从草图开始拉，现在可以直接用自然语言描述，出一版能看能改的三维模型，快速沟通结构方案。

第二个我经常用的场景是扩充标准件库。很多企业的标准件库其实缺一堆“非典型”型号，尺寸只差几个毫米，却找不到现成模型。用text-to-cad的脚本生成思路，把尺寸参数从自然语言里解出来，批量生成同族不同尺寸的模型，能把一上午的建模时间压缩到几分钟。

第三个场景是产品教学。让初学者先描述自己想做的东西，再看到代码和特征树的对应关系，对理解“参数化建模”非常有帮助。工具生成得越差，反而越能暴露设计意图描述的模糊之处，这一点在带新人时意外地好用。

5.2 暂不能做的事：复杂装配、精密公差、仿真级模型

我见过不少人对text-to-cad的信心过高，拿它去生成复杂减速箱、完整管道系统，结果当然很惨。这些场景的难点不在“画得出形状”，而在“约束合理”。装配关系、配合公差、表面粗糙度、材料属性，这些信息目前靠自然语言很难完整表达，大模型也没有可靠手段去验证它们。

更关键的是，仿真级模型对几何质量要求极高。有限元分析前处理需要干净的中面抽取、无干涉装配、合理的圆角简化，这些都是模型当前根本做不到的。生成一个看起来像样的箱体容易，但生成一个能做模态分析的箱体，完全是另一回事。

所以要谨慎区分“视觉概念模型”和“工程可用模型”。前者是text-to-cad的主场，后者还需要工程师在生成结果上做大量修整和验证。任何宣传“输入一句话直接上产线”的说法，你都不妨先打一个问号。工程模型的可用性，最终还是得用工程工具去检验。

5.3 对CAD工作流的影响

即便有上述边界，text-to-cad对工作流的影响仍然值得重视。它真正改变的，是设计师的工作内容。以前设计师大量时间花在“用手画模型”上，现在这部分正在被自动化替代，工作重心逐步转向“定义约束”和“审查生成结果”。

这有点像程序员经历了从手写汇编到使用高级语言编译器的过程。写代码的人依然需要理解底层原理，但日常效率完全不在一个量级。审图能力、约束定义能力、几何知识这些核心素养会变得更值钱，而那些只会机械重复“建块、拉伸、倒角”的操作型岗位，压力会越来越大。对于设计部门来说，更现实的改变是“需求评审的颗粒度”要变细：既然模型能快速生成，需求必须表达得更精确，否则错误的模型会生成得更快，返工也更隐蔽。

6. 工具选型建议与进一步探索

6.1 选型建议速查表

最后给一张我个人的选型建议表。如果你要快速搭自己的text-to-cad，建议按下面这个组合来：

以上所有组合我都跑过一遍，最稳定的还是第一行。CadQuery的报错信息相对清晰，大模型通过几轮反馈基本能自己修正过来，这是它适合作为底层引擎的很大优势。

6.2 后续扩展方向：多模态、RAG与自动验证

text-to-cad接下来值得探索的方向，我目前关注三个。第一个是多模态输入，把“一张手绘图+一段文字描述”同时喂给模型，让视觉信息和语言约束互相补充。手绘图能提供空间位置的直觉，文字提供尺寸和标准化需求，两者结合后，输出质量会有明显提升。

第二个是检索增强生成RAG。把公司历史设计过的模型脚本、特征模板、标准规范存到向量库里，让大模型在生成前先检索相似的零件结构作为参考，能显著降低幻觉概率，也让生成结果更符合企业内部的设计风格。

第三个是自动验证闭环。生成模型后可继续配合轻量级仿真工具，自动做静强度校核或干涉检查，把不合格的模型直接打回重生成。这能把当前“人看完再修改”的流程进一步自动化，也是我认为text-to-cad从玩具走向生产工具最重要的一个入口。

6.3 我的实践体会

回头看我自己的实践，最能提升整体成功率的其实不是某个炫酷的模型或强大的后端，而是把“需求描述”这层基本功打扎实。大模型对几何的理解能力已经超过大多数人的预期，真正限制它的，是人的表达足够不够工程化。尺寸、单位、基准面、约束逻辑，这些在往常图纸上看似枯燥的内容，在text-to-cad里变成了模型能听懂的唯一语言。

另外建议你别追求一条prompt搞定所有零件。我目前的习惯是针对不同零件类型维护各自的结构化描述模板——板类、轴类、壳体类、支架类分开写，配合各自的示例代码，生成稳定性远高于一套通用模板打天下。text-to-cad和其他工具一样，用得越精细，回报越高。