企业官网建设流程全解析

开头先说个我观察很久的现象：CAD软件发展了三十多年，菜单栏布局、命令面板和我们“先画草图再拉伸切除”的操作习惯，几乎没变。直到text-to-cad这个概念进入视野，我才第一次感受到“设计工具换了个引擎”的可能性——你只需要说一句“一块100乘60的铝板，厚4毫米，四角各打一个直径6的孔，孔心距边缘10毫米”，它就能直接给你一个可以编辑、可以出工程图的三维模型。

我花了几个周末把当前能看到的主流方案都摸了一遍，也亲手跑通了一个轻量demo。如果你是个CAD二次开发工程师、想搞AI应用落地的开发者，或者纯粹好奇“文本生成模型到底靠不靠谱”的人，这篇文章应该能帮你少走不少弯路。我会把技术路线、底层数据链路、真实踩坑记录和一套我常用的评估体系全部摊开讲。

1. 先把概念掰清楚：text-to-cad到底改变了哪一环

1.1 传统CAD建模流程的“老规矩”

传统CAD的建模过程，本质上是“人脑先想清楚 → 告诉软件 → 软件计算”的循环。以最常见的参数化建模为例：你要先选基准面、画草图、标尺寸、加约束，然后拉伸、切除、倒角，每改一版尺寸，软件重新计算一遍特征树。整个过程最耗时的不是软件操作，而是“把设计意图翻译成一系列操作指令”的过程。

很多工程师能闭着眼完成上述操作，但这里有个隐性门槛：你必须先把模型在脑子里“建成”了，才谈得上在软件里表达。对专业用户这没问题，但对只见过实物、没受过制图训练的人来说，这种交互方式天然不友好。

text-to-cad的出现，正好卡在这个翻译环节上。它尝试让“自然语言输入”直接对应到“参数化特征序列”，而不是一行行画线、拉伸、切槽。

1.2 text-to-cad不是“自动出图”，而是“意图到特征的映射”

很多人第一次听说text-to-cad，会把它理解成“AI自动画图”。其实没那么简单。它的核心任务是把一句话或一段话里的信息，拆解成CAD引擎能识别的东西：尺寸、单位、特征类型、位置关系、约束条件。

举个例子：“底板上开两个对称的腰型孔。”这句话人类一听就懂，但CAD引擎要落地，需要知道：腰型孔的长宽、相对底板的中心位置、两个孔之间的间距、对称轴是X轴还是Y轴。text-to-cad系统要做的，就是从这句话里抽取出“腰型孔”“对称”“中心”这些语义，再组装成一组带参数的建模指令。

所以我的判断是：它改写的不是“画图”这个动作，而是“从设计意图到特征表达”这条最短路径。这个区别决定了你评估一个text-to-cad工具时该看什么——不是看它能不能生成一个好看的三维预览，而是看它生成的特征是不是可以被下游改造。

1.3 哪些场景是真需要它的

我梳理下来，最需要这个能力的是三类场景：

• 概念设计阶段。方案工程师要快速验证“这个零件大概多大、能不能塞进那个空间”，用自然语言生成基础模型比从头画快得多。
• 标准化零件库的建设。很多公司有大量非标准的钣金件、支架、盖板，描述文字本来就存在ERP里，如果text-to-cad能直接把这些文字变成可编辑模型，库的建设成本会大幅下降。
• 面向非专业用户的定制化工具。比如电商定制雕刻件、教学演示、创客社区，用户不懂CAD，但能描述清楚自己要什么。

2. 主流做法复盘：四类技术路线与我的选型判断

实际看了一圈之后，我发现text-to-cad的实现路径五花八门，但大体可以归成四类。每一类的理论基础和适用边界差别很大，选错路线会浪费大量时间。

2.1 路线A：脚本和程序化生成作为中间语言

这条路线最直观，也是我个人最推荐入门的。它让大语言模型去生成一段脚本化建模的代码，比如先用“DQCad”这类开源脚本内核的语言描述一个模型，然后由内核实际执行这段代码，产出可编辑的参数化模型。

为什么这条路便宜？因为大模型不需要去学习复杂的B-Rep几何学，它只需要学会“写对代码”。代码的语法对不对，由编译器检查；几何算得准不准，由内核兜底。模型只负责语义理解，把“底板80毫米长”映射成一句“长度设为80”，后面的事不归它管。

这个路线的缺点是，它极其依赖模型写代码的稳定性。模型一旦生成一个语法正确、但逻辑不通的脚本——比如孔打在了零件外面——内核不会报错，只会默默生成一个形状奇特的模型。所以需要我在第4章讲的“后置几何校验”，这一步不能省。

2.2 路线B：端到端输出边界表示序列

这是看起来最“原教旨AI”的路线。它直接把CAD模型的原生数据格式，也就是边界表示（B-Rep），拆成一系列token，让模型像写文章一样一个token一个token地预测出整个模型。

这条路的优点是输出没有中间损耗，模型理论上能直接生成带有圆角、倒角、复杂曲面的工业级模型。但代价也很明显：token序列极长，训练数据极难获取，而且模型非常容易在某个局部“画崩”——面与面之间出现微小裂缝、法线反向，这些在渲染图上根本看不出来，一导到加工软件就完蛋。

目前我看到的社区实验里，这条路能稳定生成的还停留在简单几何体级别，离生产环境有距离。适合高校和研究机构去啃，不适合急着落地的工程师。

2.3 路线C：CSG构造树生成

CSG，也就是构造实体几何，是把模型看作“基本几何体 + 布尔运算”组合出来的一棵树。比如一个带孔的板子，可以表达为“板子 减去 圆柱体”。这条路让模型去预测这棵树的节点和运算关系。

它的最大优势是结构天然紧凑、容易验证。一棵树是否合法，直接通过布尔运算结果就能判断。但缺点也很明显：CSG模型擅长表达规则几何体，一到自由曲面、复杂的倒角过渡就力不从心。

我个人的判断是，CSG路线在“规则机械零件”这个细分领域很有前途，因为它和传统机械设计的思维习惯高度一致——零件就是一堆拉伸体和孔槽的组合。

2.4 路线D：检索加变形

这条路不直接生成模型，而是先从模型库里检索出一个最相似的，再用文本差异信息驱动局部变形。比如你输入“把这个法兰的四个孔改成六个”，系统先找到那个四孔法兰，再通过语义对比把孔的阵列数改掉。

它的优点是结果极其稳定，因为底子来自真实可加工的模型；缺点是天花板低——库里面没有的东西，它再怎么变形也变不出来。我见过一些企业级应用用它做“老图新用”，把旧零件库改造成按文本检索的口令式操作，效果不错。但如果目标是“从无到有”，这条路线帮不了你。

2.5 四类路线怎么选

我把它们的核心差异整理成一张表，方便直接对照：

如果你是第一次接触text-to-cad，我强烈建议从路线A切入。理由只有一个：你可以在一个周末内跑通整个链路，亲眼看到“文本进、模型出”的完整过程，这个正反馈对理解其他路线非常重要。

3. 一条完整的text-to-cad数据链路：从自然语言到可编辑特征

工具选定之后，更重要的其实是理解一条text-to-cad数据链路上到底发生了什么。我习惯把它拆成四个环节，每个环节都有各自容易翻车的地方。

3.1 输入处理：实体抽取与单位归一化

自然语言进系统之后，第一步通常不是直接丢给大模型，而是先做一轮“实体抽取+归一化”。这里要处理的坑相当多。

先说单位。工程师的习惯用法五花八门：“30厘米见方”“大概4毫米厚”“半个拇指长”。如果不对单位做强制归一化，模型很容易把30厘米当成30毫米用。我的做法是：在提示词里明确要求输出结果统一使用毫米，同时在后处理代码里加一道校验，凡是数值或单位异常的直接拒绝，不让它进入几何内核。

再说表达歧义。“上面”“正面”“左侧”这些词，在自然语言里再正常不过，但在三维空间里取决于你默认的坐标系朝向。我在demo里约定：XY平面为俯视面，Z轴正方向为“向上”，“前面”指-Y方向。这些约定必须写进系统提示词，否则同一个词每次的解释都不一样，出来的模型就毫无一致性。

3.2 生成引擎：把语义变成参数化特征序列

处理完输入，就轮到核心生成环节。这一步大模型的角色是“语义理解机器”，不是“几何计算器”。

我用的是一个精心构造的输出格式：模型只输出一个JSON结构，里面包含特征类型、主尺寸、位置偏移、阵列信息和约束关系。比如一个四孔板，输出的特征序列是“一块板”加“一个孔特征，带阵列参数4个”。至于这个孔具体怎么切，交给脚本化建模内核去算。

这里有一个非常关键的设计决策：绝不指望模型输出精确的几何坐标流。模型在数值计算上天然不敏感，它擅长的是理解“对称”“四角”“中心距”这些概念，然后把它们整理成结构化参数。所有精确计算都发生在后端的几何内核里。定位好模型和内核的分工，整个系统的稳定性会上一个台阶。

3.3 约束重建与拓扑修正

模型生成的结构化参数，即便所有数值都正确，也还不算真正“能用”的CAD模型。因为一个可编辑的参数化模型，特征之间必须有关联约束。

依然用四孔板举例。如果模型输出的是四个孔各自独立的绝对坐标，那么当你把板宽从100毫米改成120毫米时，四个孔是不会跟着移动的，因为它们之间没有依赖关系。要解决这个问题，需要在后处理里做“约束重建”：把孔中心坐标改写为“距边缘10毫米”的表达式，而不是写死成“(20, 20)”。

这一步我的实现方式是：一个轻量的规则引擎，专门负责识别常见的几何关系，包括等距、对称、阵列、同轴，然后把它们转换成约束表达式。它不聪明，但极其可靠。我的经验是，宁可让这层规则引擎多管闲事，也不要让模型自己去处理约束——模型的“想当然”在这里会神不知鬼不觉埋下大坑。

3.4 导出与下游兼容

最后一步是把模型导出成标准格式。我一般导出两种：STEP格式用于制造交换，原生格式用于继续编辑。无论哪种格式，导出前都建议跑一遍几何检查，包括自交面检测、法线方向检查、未缝合边检测。很多text-to-cad工具生成的结果“渲染时好看、一加工就坏事”，就是跳过了这一步。

4. 实战：我从零跑通的一个轻量text-to-cad Demo

理论讲多了容易虚，我直接用一次完整的实操记录来说明这套链路到底怎么落地。这是我某个周末搭的模拟项目X，不涉及任何商业代码，参考价值在于流程完整、可以复现。

4.1 环境准备与依赖选型

我用了Python作为主语言，后端框架选了轻量的Flask（更重的框架在本地调试时反而碍事）。脚本化建模内核，我选的是之前提到的DQCad这一类开源脚本库，它可以直接通过代码创建板、孔、槽等特征，并导出STEP和中转网格。

大模型这部分，我强烈建议你先在本地跑一个量化的小模型，把整个流程调通，再考虑接更强的模型或者云端接口。原因很现实：CAD数据往往涉及公司图纸机密，外发调用接口在很多企业里过不了合规。本地部署虽然生成的复杂模型能力弱一些，但胜在数据安全，而且后续调试更快。

依赖清单就三样：Python环境、脚本建模内库、一个支持JSON输出的本地模型服务。别在这一步追求复杂框架，越轻越好。

4.2 后端：提示词与脚本化建模内核的联动

下面这段代码是demo的核心逻辑，我把它简化后贴出来。你可以看到，提示词部分其实是一个“角色约束”加“输出格式约束”的组合：

import json from flask import Flask, request, jsonify from dqcad import build_part_from_features from llm_client import local_llm_generate app = Flask(__name__) system_prompt = """ 你是一个CAD特征提取助手。你的任务是把用户对机械零件的描述， 转换为结构化的参数化特征JSON。 硬性规则： 1. 所有尺寸一律使用毫米，不允许使用cm/m。 2. 坐标系约定：XY平面为俯视基准面，Z轴正方向为向上。 3. 只输出合法JSON，不要输出任何解释性文字。 4. JSON结构必须是： {"features": [ {"type": "plate", "length": 100.0, "width": 60.0, "thickness": 4.0}, {"type": "hole", "diameter": 6.0, "center_x": 20.0, "center_y": 20.0} ]} 5. 如果描述中缺少某个参数，使用默认值并添加键"defaulted": true。 """ def text_to_cad(user_text): messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_text} ] raw = local_llm_generate(messages, temperature=0.1) try: feature_json = json.loads(raw) except json.JSONDecodeError: # 第一次解析失败，把错误信息回传给模型重试 messages.append({"role": "assistant", "content": raw}) messages.append({"role": "user", "content": "以上输出不是合法JSON，请只输出JSON。"}) raw = local_llm_generate(messages, temperature=0.1) feature_json = json.loads(raw) # 交给脚本化建模内核生成实体 result = build_part_from_features(feature_json["features"]) return result @app.route("/generate", methods=["POST"]) def generate(): data = request.get_json() user_text = data.get("text", "") result_path = text_to_cad(user_text) return jsonify({"model_path": result_path})

这段代码里有个容易被忽视的点：重试时把前一次的错误输出原样回传给模型，并附加一句“请只输出JSON”。这个小技巧比“直接再问一次”有效得多，模型的自我纠错能力是真实存在的，前提是你得把错误信息喂回给它的上下文。

4.3 前端：Web页面上的实时预览

后端有了生成接口，前端我用了最简单的方案：一个页面输入框，提交后调接口获取模型文件，再由一个通用WebGL渲染器加载网格数据，支持旋转和缩放。没有用重型三维CAD前端的必要，因为第一步只需要让用户看到“生成的东西长什么样”。

从STEP转成网格这步要放在后端完成，否则浏览器直接读STEP会很痛苦。转换完成后再把三角网格的顶点和索引送到前端渲染。整个过程在三秒内完成，体验上接近“输入文字、看到模型”的即时感。

4.4 第一次出模：一次完整的输入输出记录

我测试时输入的第一句是：“一块100mm乘60mm的铝板，厚度4毫米，四角各有一个直径6毫米的孔，孔心距边缘10毫米。”

模型返回的JSON大致是：板面长度100、宽度60、厚度4；四个孔的直径都是6，坐标分别是(10,10)、(90,10)、(10,50)、(90,50)（坐标原点在板中心的前提下，实际我把原点设在了板的一个角点）。几何内核接收后成功生成了板实体，网格渲染也正常。

但我紧接着发现一个问题：这四个孔的坐标是绝对坐标，而不是“距边缘10毫米”的约束表达式。这意味着我如果希望修改板宽为120毫米，孔的绝对坐标不会自动更新。这个问题在第3章预测过，现在真实撞上了。解决办法就是我在3.3节说的约束重建，把“孔中心坐标”改写成“边缘距离”表达式。处理好之后，四孔板才真正变成一个参数化模型。

5. 实测中的关键调优点：稳定输出一个“能用的模型”

demo跑通只是开始，真正让text-to-cad进入可用状态，靠的是下面这几轮调优。我踩过的坑不算特别新鲜，但对第一次接触这个方向的人来说，每一条都可能是拦住你去路的门槛。

5.1 输出不稳定的根因与对策

大模型输出不稳定的根因，说到底是它在数值表达上天生不可靠。同一个“6毫米”直径，它可能这次输出6，下次输出6.0，再下次输出0.006（因为偷偷用了米），甚至偶尔输出“六毫米”。

我的对策分三层。第一层，把温度参数压到0.1左右，让输出模式尽量确定；第二层，在提示词里强制规定数值类型和单位，并要求所有字段必须是浮点数；第三层，也是最重要的一层，在后端做数值范围校验，任何超出合理范围的数值直接拦截并触发重试。

你可以把这三层理解成：降低随机性、规范表达、强制校验。没有最后一层的强制校验，前面两层只是降低了出错的概率，并没有消除出错的可能。

5.2 单位、坐标系和命名混乱

单位问题我前面提过，但实际踩坑比想象中更频繁。有一次我的模型输出板厚“4.0”，我以为是4毫米，导出的STEP进了某款切片软件才发现尺寸小了十倍。一查才发现，模型内部其实是0.4厘米，STEP单位换算时出了问题。自那以后，我在导出接口前都会硬编码一次“全部转换为毫米”的检查，不吃任何“默认单位”的亏。

坐标系混乱的典型表现是模型“朝天长”。原因一般是模型没有理解“厚度方向”是哪个轴。解决方式是固定约定并反复写入系统提示词。命名混乱则是个长期维护问题——孔有时候叫“hole”，有时候叫“开孔”，有时候叫“圆洞”，导致后期特征树难以阅读。我现在的做法是，在内核层统一把命名规范成“特征类型_序号”的格式，不让模型自由发挥。

5.3 复杂描述的拆分与重试策略

当用户一句话里有多个零件时，一次生成出来的结果往往是灾难现场。比如“做一个盒子，上盖要卡扣”这句话，如果你让系统一次性输出整个盒子加卡扣，特征之间的配合关系很容易乱套。

我的解决方式是把任务拆成子任务：先生成盒体的几个面，再单独生成上盖，最后做装配关系。拆分的判断依据不复杂——一句话里出现了多个主语或独立功能描述，就按语义断点分开执行。这个逻辑在demo里我用一个很简单的规则实现：先让模型把输入拆成“零件清单”，再逐个零件调用text-to-cad。

重试策略我也总结出了一个固定套路“3+2”：第一次自由生成；失败后要求“只输出合法JSON”；再失败则把最后一次的错误堆栈或异常信息原样拼回上下文再试一次；仍然失败就放弃并向用户输出可理解的错误提示。这个“3+2”策略看起来朴素，但它几乎帮我处理了九成以上的偶发故障。

5.4 推理服务化：并发与超时

本地模型服务有个现实问题：推理慢、并发能力弱。我第一次直接把生成接口暴露给前端，结果两个人同时提交请求，显存直接被打满，整个服务卡死。

后来我做了三层限制：第一，模型推理和几何内核执行分成两个独立进程，免得几何计算拖垮模型服务；第二，引入一个简单的请求队列，限制同时只有两个推理任务在跑，其余的排队；第三，给每个请求设置二十秒超时，超时的直接返回重试提示。小规模场景下，用锁和队列比引入分布式任务框架好调试得多，别一上来就整复杂架构。

6. 怎么判断text-to-cad跑得好不好：一套我常用的评估体系

很多人跑通demo后，接下来都问同一个问题：这玩意儿生成的模型到底算不算合格？只靠人眼“看着像”是不行的，你得有一套可重复的评估方法。

6.1 客观指标：几何误差与特征完整度

我常用的客观指标有三个。第一组是尺寸偏差，也就是生成模型的包围盒长宽高与目标尺寸的误差比例，允许范围我一般卡在百分之二以内。第二组是网格间的重合度，也就是体素化之后交并比（IoU），这一项对整体形状把握能力很敏感。但要注意，IoU对细小特征特别不敏感，一个孔被完全漏掉，在体素化后只会让IoU掉一点点，肉眼根本看不出来，所以必须加上第三组：特征级指标。

特征级指标会去数生成模型里有没有出现目标数量的孔、槽、阵列，数量对不对，位置偏差在不在公差范围内。这一组指标才是真正贴近工程要求的，毕竟加工一个零件，少一个孔就是废品，形状再像也没有意义。

6.2 主观指标：可编辑性与建模意图

客观指标之外，还有一个往往被忽略但极其重要的主观指标——可编辑性。我判断一个text-to-cad系统好不好，会直接问几个问题：

• 生成的模型是进了特征树，还是一团三角网格？
• 修改“板厚为4”这个参数时，其他特征会跟着正确变化吗？
• 特征树的名称是否清晰可读？
• 隐藏某个特征、再显示回来，模型还稳定吗？
• 能直接出工程图而不需要重新画一遍吗？

这些问题的本质是区分“看起来像”和“真正是”。“看起来像”只需要一堆三角网格，“真正是”需要一个结构正确、约束完整的参数化模型。前者只能用来展示，后者才能进入生产链路。这也是我在整个实践中最看重的一条分界线。

6.3 我踩过的七个典型坑

最后把我在调试中反复遇到的七个问题整理成一个清单，方便你对照排查：

这些坑没有一个是“改个参数就能立刻解决”的，它们都指向同一个核心问题：文本到CAD的系统，不能只解决“生成”，必须解决“生成之后的参数化关系维护”。这是我在整个实践中最大的感悟。

我的一个收尾体会

如果让我给准备上手text-to-cad的人一句忠告，我会说：别急着用它去生成复杂的装配体，先把一个带孔的小板子做到尺寸精确、特征可编辑、改参数不崩，这比生成一百个“看起来很像”的漂亮模型有价值得多。我吃了不少亏之后才意识到，文本描述的本质不是“形状”，而是“设计意图”，而表达意图这件事，恰好是语言天然擅长、几何计算天然不擅长的。把这层关系在系统架构里摆正，后面的一切都会顺很多。