1. text-to-cad到底是什么——先把这个概念嚼碎了

第一次看到“text-to-cad”这个说法，大多数人第一反应是：用文字生成三维模型？听起来像是把“给我画一个杯子”丢给电脑，然后它就真的给你一个杯子。这个直觉方向是对的，但理解得还不够深。如果只是生成一个像杯子的网格体，那这件事五年前就有技术方案了，也不至于到最近才被反复拿出来讨论。

text-to-cad真正有价值的地方，不是“识别自然语言并输出一个模型文件”，而是让大语言模型直接操作一套参数化建模指令，生成一个带有完整特征树、可以继续编辑、可以改参数、能够落到实际工程流程里的CAD模型。换句话说，它生成的不只是“一个形状”，而是一整套“建模过程”。这才是它和传统文本生成图片、文本生成三维网格之间本质的区别。

从实际应用的角度看，这件事解决的是两类人的痛点。一类是机械设计、工业设计领域的工程师，每天要处理大量标准件、相似结构件，手动建模虽然不难但极其枯燥。另一类是非专业用户，比如采购、销售、产品经理，他们需要用三维模型做沟通和验证，但不会用建模软件。text-to-cad给了这两类人一条更短的路径：用自然语言描述需求，让模型去完成重复劳动。

这篇文章我用自己实际折腾过的经验，把text-to-cad的技术结构、可行方案、实操流程和踩坑经历都梳理一遍。适合三类人阅读：想搭建自己的text-to-cad原型的开发者、正在评估这项技术能不能进工作流的工程师、以及单纯想搞清楚“这东西到底是不是噱头”的产品和技术管理者。

1.1 它解决的不是“画图”问题，而是“表达”问题

人类工程师设计一个零件，脑子里想的从来不是“这个形状的点的坐标是多少”，而是“这是一个底座，厚度5毫米，四个角各有一个直径4毫米的安装孔，孔中心距边缘10毫米，底部开一个倒角”。这句话本质上就是一段文字描述，而传统CAD软件要求你把它翻译成草绘、拉伸、打孔、倒角等一系列离散操作。这个翻译过程对新手来说是有学习成本的，对老手来说是需要重复执行的低效劳动。

text-to-cad把“翻译”这一层交给大模型来做。模型负责理解“一个带四个安装孔的底座”这句话里隐含的几何信息和特征关系，然后输出对应的参数化建模指令序列。指令本身是结构化的，比如“在基准平面上画一个120x80的矩形，拉伸5毫米，在四个角生成直径4毫米的通孔”。执行这些指令的，仍然是你用的CAD内核或者建模软件，不是大模型直接生成顶点和面。

这里就引出一个关键认知：大模型是指挥官，不是施工队。它不参与几何计算的细节，只负责把人类的模糊意图转译成工程系统能够理解的动作。这种方式的好处非常明显——输出的结果天然就是参数化模型，你拿到手之后可以继续改尺寸、改位置、重新编辑特征，而不是面对一堆无法修改的三角网格。

我自己在做原型验证的时候，最大的感受是：把问题定义为“翻译”之后，技术实现的路径就清晰了很多。你不需要去解决“如何生成一个高质量曲面”这种工程难题，你需要解决的是“如何让模型输出的指令足够规范、足够可执行”。这是完全不同的技术栈。

1.2 核心思路是程序化建模，不是生成网格

很多人刚接触这个方向时，会拿它和“文本生成三维模型”的AI工具做对比。那些工具的典型做法是输入一段文字，输出一个OBJ或者GLB文件，模型是三角网格的，适合渲染、展示，但不适合加工、不适合装配、不适合做工程分析。CAD行业对模型的诉求完全不同：一个零件模型必须包含精确的尺寸、约束关系、特征历史，才能支撑后续的仿真、加工和装配验证。

text-to-cad走的是另一条路：程序化建模。所谓程序化建模，就是用一段可执行的代码或者指令序列来描述模型的构造过程。模型不是“画”出来的，是“算”出来的。比如一个法兰盘，程序化描述就是“旋转一个轮廓生成主体，再开六个均布孔，再做一圈倒角”。这段描述可以被同一个CAD内核反复执行，修改任意参数都能重新生成，这就是参数化能力的来源。

把这两条路线放在一起对比就很清楚了：

所以如果你想做一个真正能用的text-to-cad工具，从一开始就应该明确：你的目标不是让模型“画得像”，而是让模型“按正确的过程建出来”。像不像由视觉判断，正确性由建模流程保证。这个过程对了，结果就一定是好的。

1.3 现阶段最适合落地的地方在哪里

从成熟度来看，text-to-cad目前还做不到“你随便说一句，它就能给你一个工业级模型”的程度。但有几个场景已经比较实用了。

第一个是标准件和通用件的自动建模。法兰、支架、轴套、齿轮坯这类零件，结构相对规整，特征套路固定，大模型很容易学会。你给它一句话“直径80的法兰盘，六个均布孔，孔中心圆直径60”，它能生成一个基本可用的模型。这类工作占了设计环节里很大一部分重复劳动，自动化价值非常高。

第二个是概念设计阶段的快速验证。工程师脑子里有个想法，想快速看个三维效果，验证装配关系，这时候不需要精雕细琢，只需要一个结构合理的粗略模型。text-to-cad可以把想法快速变成可查看、可分享、可讨论的三维形态，大大降低沟通成本。

第三个是设计和制造的衔接。程序化生成的模型天然带特征信息，可以直接对接CAM、3D打印切片、有限元分析等下游工具。相比从网格模型反推几何，这条路要干净得多。

我做原型测试时的判断是：这技术现在还撑不起“替代设计师”这种宏大叙事，但已经能在“辅助设计”“批量建模”“设计自动化”这些方向上产生真实价值。

2. 技术路线拆解：一整套text-to-cad系统由哪几块拼起来

如果只是用大模型的API，把一句话和一个模型文件对应起来，那是demo级别的玩具。真正要做一套能用的text-to-cad系统，至少需要四个部分协同工作：负责语义理解的大模型、负责中间表达的指令语言、负责执行指令的建模引擎、以及负责检查结果的质量反馈模块。这四个部分缺一不可，任何一个环节出问题，整个链路都跑不通。

2.1 大语言模型负责翻译，不负责画图

这个观点我在前文提过，但值得展开。大语言模型在这个系统里的职责边界是：接收自然语言描述，输出结构化的建模指令序列。它不需要理解几何内核的底层实现，不需要知道B-rep数据结构的细节，只需要把“用户想要什么”转译成“建模系统支持哪些操作”的表达方式。

在实际落地时，这意味着你要对大模型做两件事。第一件事是给它一套建模指令的词汇表，告诉它系统支持哪些操作、每个操作的参数长什么样、有哪些约束必须满足。第二件事是给它足够的示例，让它学会将不同的自然语言表达映射到正确的指令组合上。这本质上是一个可控生成问题，你越能把输出空间约束得足够清晰，模型的准确率就越高。

我用过的几种实现方式里，最简单的是让模型直接输出一段DSL代码，再由程序解析执行。稍微复杂一点的是让模型通过函数调用机制去调用建模API，每次调用对应一个操作。两种方式都可行，区别在于你对中间格式的控制粒度。直接输出DSL的好处是实现简单、便于调试；函数调用的好处是模型和建模引擎的交互更自然、更容易实现多轮控制。

有些项目也会尝试微调一个小模型来专门做这个任务。微调适合输出格式固定、操作类型有限的场景，能够显著降低推理成本和延迟。但通用性会差一些，擅长处理模板化的建模任务，遇到没有见过的表述方式容易出问题。

2.2 中间表示层决定生成质量的上限

这是整个text-to-cad系统里最容易被忽视、但最值得钻研的部分。中间表示层，通俗说就是“模型输出什么格式，才能让建模引擎稳定执行”。你直接让大模型生成STEP文件是不现实的，那是一种复杂的文本交换格式，逐行逐句生成容易出错。你让大模型直接生成几何代码也希望渺茫，它不具备空间计算的精确能力。所以中间表示层必须是一种“刻意设计”的东西。

目前比较常见的做法是设计一套轻量级的程序化建模DSL。这套DSL的指令集合需要和建模引擎的能力保持对齐，引擎支持什么操作，DSL里就定义什么指令。比如一套面向机械零件的DSL，通常包含：

• 草绘指令：矩形、圆、多边形、样条线等
• 特征指令：拉伸、旋转、扫掠、放样、倒角、圆角等
• 阵列指令：线性阵列、圆周阵列
• 布尔指令：合并、相减、相交
• 辅助元素：基准面、基准轴、坐标系定义

DSL的设计有几个原则值得留意。一是参数必须显式命名，不要依赖模型去推断“默认值在哪”；二是约束关系要支持声明式表达，比如“这两个圆同心”“这条边和那条边共线”；三是指令序列要有严格的层次结构，草绘在前、特征在后、阵列和布尔在最后。这样设计的目的，是让大模型输出的内容足够结构化，降低执行阶段的解析难度。

如果说大模型决定了这个系统的“理解上限”，那中间表示层就决定了它的“工程下限”。一个好的DSL能把模型的幻觉限制在可纠正的范围内，一个糟糕的DSL会让模型输出一大堆看似合理但根本执行不了的指令。我见过太多原型项目死在“模型输出不合法”这个问题上，最后排查发现是DSL设计得太自由，给了模型太多发挥空间。

2.3 参数化建模API为什么是工程落地的关键

有了中间表示层之后，你还需要一个真正能把这些指令变成几何实体的执行器。这一步的选择基本决定了整个系统的工程边界。

市面上常见的参数化建模内核大致分三类：商业闭源内核、开源内核、以及可以通过脚本驱动的商业建模软件。选择哪一类，取决于你的应用场景是嵌入式自动化、离线批处理，还是交互式辅助设计。

如果你的目标是构建一个自动化批量建模服务，开源内核或者商业建模软件的脚本接口都值得考虑。脚本接口的优势在于它有完整的参数化建模能力、有原生窗口去查看结果、导出格式齐全，缺点是启动一个软件实例占用资源比较大，不适合高并发场景。开源内核的优势是轻量、可控、可以嵌入到自己的服务里去，缺点是你可能需要自己包一层几何操作封装，工程工作量会多一些。

我在原型阶段使用的是开源内核的方案，核心原因是它的许可证和部署方式更灵活。不过这里有个容易被忽略的点：几何内核只是执行引擎，你还需要一个好用的错误反馈机制。当模型生成的指令执行失败时，你要能拿到准确的失败原因，比如“草绘约束不足”“拉伸方向与草图平面冲突”“自相交导致布尔运算失败”。否则整条链路一旦出错，排查成本会非常高。

3. 实操流程：从一个想法到一个能用的参数化模型

理论部分说得再多，不如动手跑一遍。这一章我把一整套text-to-cad的实操流程拆开，从环境搭建到Prompt设计再到闭环修正，每个环节都写清楚。你可以把它当作一条可以直接照做的路径。

3.1 环境准备：先跑通一个最简链路

搭建text-to-cad系统不需要一开始就搞很复杂的架构。先跑通一条最简链路：大模型API + 指令解析器 + 几何内核。这条链路建立起来之后，再逐步往里面加校验、反馈、重试等模块。

具体到工具选型上，我的建议是：大模型部分用支持函数调用或者结构化输出的主流商用模型，因为它们的指令遵循能力更强；指令解析器自己写一个，用Python或者其他你熟悉的语言，把DSL文本解析成内部操作序列；几何内核这一层，可以根据你的技术栈选一个支持脚本控制的建模环境。

对我个人来说，最快能验证想法的方式是让大模型输出JSON格式的操作指令，然后写一个Python脚本去逐条执行。JSON的好处是解析简单、结构清晰、出错容易定位。比如一个“开四个安装孔的底座”的请求，大模型输出：

{ "operations": [ { "type": "sketch", "plane": "XY", "entities": [ { "kind": "rectangle", "name": "base", "width": 120, "height": 80, "center": [0, 0] } ]}, { "type": "extrude", "sketch": "base", "height": 5, "operation": "new" }, { "type": "hole", "on_face": "base_top", "diameter": 4, "positions": [ [45, 30], [-45, 30], [45, -30], [-45, -30] ]} ] }

这种格式非常直白，不需要训练也能看懂。而且它的优点在于，一旦执行失败，你可以很清楚地看到是哪一条指令出了问题。调试起来远比让模型直接生成一段代码要轻松。

在跑通这条链路之前，我建议你不要急着做复杂的Prompt。先用一组固定句式测试，比如“一个长多少宽多少高多少的方块”，把基座流程跑通。流程通了之后再逐渐增加自然语言的复杂度。这一步最大的价值是帮你建立信心，让你看到整条链路是可行的。

3.2 Prompt设计：把模糊需求拆成可执行的建模指令

Prompt设计是text-to-cad系统里投入产出比最高的环节。同样是“帮我做个法兰盘”这样一句话，不同Prompt写法得到的模型质量可能天差地别。核心原因在于，大模型对模糊词的默认解读不一定是你想要的。

我在实践中总结了一套比较有效的设计方法，核心思路是把“用户需求”和“建模约束”分成两层传递给模型。用户需求可以很口语化，比如“底座，四个角打孔”；但建模约束必须明确，包括单位、尺寸、坐标系、特征优先级。

一个比较完整的system prompt结构大致是这样的：

• 角色定义：你是一名参数化建模工程师，根据自然语言描述生成CAD操作指令
• 输出格式：只输出JSON，不要解释过程
• 单位约定：所有长度单位为毫米
• 坐标系约定：默认使用XY平面作为草绘平面，Z轴正方向为拉伸方向
• 几何原则：优先使用参数化特征，禁止生成网格或直接用B-rep布尔
• 命名规范：每个特征都要有名字，方便后续编辑
• 自检要求：生成的模型必须满足尺寸合理、特征之间无干涉、可加工性合理

这一套约束写下来，模型的输出稳定性会有明显提升。比较有意思的是“自检要求”这一项，它会让模型在生成指令时主动检查一下自己有没有犯低级错误，比如把直径80的零件开直径60的孔，显然不合理。这个机制不能保证模型完全正确，但能拦截掉相当一部分明显不合理的输出。

用户消息部分也需要引导，让用户描述尽量包含关键尺寸和功能要求。最简单的方法是在Prompt里给一个模板，要求用户按“零件类型+关键尺寸+附加特征”的结构去描述。但现实情况是用户不会配合你，所以更好的做法是你做一个自然语言预处理，把口语描述里的关键参数抽取出来再交给大模型。

我在实际项目里就是用“抽取-重组-生成”三步走：先用一轮轻量级模型抽取尺寸和特征描述，再重组为规范的结构化描述，最后交给text-to-cad主模型生成指令。这样做能明显提升对口语化输入的容忍度，代价是多一次模型调用。

3.3 生成、校验、反馈修正：完整闭环怎么转起来

如果只做一次“输入一句话，输出一个模型”，那成功率很难达到实用水平。真正稳定可用的系统，一定要有循环修正机制。用一句话来说就是：先生成，再检查，错了就让模型重新改。

校验环节可以做两个层面。第一层是格式校验，检查模型输出的JSON是否符合预定义的schema，必填字段是否存在，枚举值是否合法。这层校验很快，基本不消耗额外算力。第二层是几何校验，真正把指令丢进建模引擎去执行，看能不能成功生成实体、有没有自相交、尺寸是否合理。

第二层校验是整个闭环的关键。执行失败时，建模引擎会返回错误信息，你把这部分信息作为反馈，拼到原始Prompt里，让大模型重新生成一版。比如“拉伸操作失败，原因是草绘未闭合”，大模型看到这个反馈后，大概率会主动修复草绘轮廓，或者换一种更稳妥的建模方式。

我在跑这个闭环时，有一个习惯：把每一轮的输入、输出、错误信息都记录下来。这样不只是调试方便，你还可以复盘哪些错误是高频错误。如果你的系统里总是出现“孔位置越界”这类问题，说明Prompt的约束还不够细，或者DSL设计有歧义。根据高频错误去优化系统，效率远高于随机调整Prompt。

循环次数也要限制。我一般设置最多三次重试，三次之后仍然失败，就放弃自动生成，转人工处理。原因很简单，有些需求本身描述得就不清楚，模型重新生成再多轮也只是在猜。设置上限可以避免资源浪费。

4. 常见问题与排查技巧：我在text-to-cad里踩过的那些坑

text-to-cad这个方向看着门槛不高，真正用起来之后各种毛病都会冒出来。这一章整理几个我实际踩过的高频问题，每一条都附上排查思路和解法，希望能帮你少走点弯路。

4.1 模型输出合法但是几何上“没用”

这是最让人头疼的一类问题。大模型生成的指令格式完全正确，schema校验也通过了，建模引擎也能顺利执行，生成的模型看起来也有模有样，但放到工程场景里根本不能用。典型表现是：该倒角的地方没有倒角，该有的公差配合没有体现，孔的位置分布不合理，或者拉伸方向选错了。

根源在于，语法正确不等于设计合理。模型学到了“法兰盘由主体+孔+倒角组成”这个模式，但它不理解“六个孔应该均布才满足使用需求”的物理逻辑。解决这个问题，单靠Prompt改进效果有限，更有效的做法是在DSL里增加约束检查规则，把“孔必须均布”“孔径与主体尺寸比例必须合理”这类规则固化成代码，在几何校验阶段就用程序拦截。

另一个比较实用的技巧是在Prompt示例里加入“反面案例”。给模型看几个“设计不合理”的例子，并明确指出不合理在哪里。这样做比单纯说“请生成合理的模型”管用得多，因为大模型学习示例的能力远强于服从抽象规则的能力。

4.2 单位、坐标系和草绘基准面的混乱

text-to-cad系统对单位的敏感度远高于普通文本生成任务。同样一句“厚度3”，如果英制单位和公制单位混在一起，生成出来的模型尺寸会差25.4倍，直接导致整个设计报废。模型内部可能对单位并不敏感，它只是按概率把数字填进去，不会去思考这个数字在哪个单位体系下是合理的。

坐标系问题也是重灾区。同一个“底座”描述，模型有时候把拉伸方向设为Z+，有时候设为Z-，有时候放在XY平面上，有时候放在YZ平面上。这种不一致性在生成单个零件时不容易发现，但在后续做装配体对齐时就会让人崩溃。

我的处理方式是在Prompt里极其显眼地声明单位、坐标系、基准面，并且在DSL里强制要求每个草绘指令都带上plane字段。解析器在收到没有plane字段的指令时直接拒绝执行，而不是默认填充一个值。用“宁可报错也不猜测”的策略，能过滤掉大量潜在错误。

4.3 上下文丢失导致模型整体漂移

多轮交互是text-to-cad的前沿应用方向之一，比如先创建一个底座，然后说“底座加高一些”“在侧面开个槽”“把孔改成腰型孔”。理想情况下模型应该记住底座是什么样，然后精准地执行增量修改。但现实是，对话越来越长之后，模型常常把最早的模型结构信息忘掉，或者越改越偏。

这个问题在多轮设计中尤其致命。原因是大模型的注意力机制天然对近期内容更敏感，早期的模型特征描述在长上下文里容易被稀释。解决思路有两种：一种是把状态压缩，每一轮对话结束后把当前模型的结构摘要提取出来，下一轮交互时把摘要重新注入Prompt，而不是依赖对话历史；另一种是提供“回到上一步”的回退机制，每轮生成结果都保存快照，发现漂移了就回退到上一个稳定版本。

两种方式我都在实际项目里试过。状态压缩更适合长流程自动化，虽然实现上要维护一个“模型状态摘要”的数据结构，但稳定性好得多。快照回退方式简单直接，不过当对话轮数很多时，用户可能自己也分不清该回退到哪一步了。

4.4 性能瓶颈和超时处理

模型生成指令通常需要几秒钟，几何内核执行也需要时间，如果校验失败还要再跑一轮重试，一个复杂零件的完整生成链路可能要消耗几十秒。这个数字对批量生成场景来说是个严峻的考验。

我在优化性能时做了三件事。第一件是分层生成：先让大模型生成一个粗粒度的“建模方案”，只包含特征类型和大致顺序，不包含精确参数；方案确认没问题之后，再生成具体的参数化指令。这样可以把错误尽早暴露，避免在错误方案上浪费时间。第二件是并行验证：多个候选方案并行送到建模引擎去执行，谁先通过校验就用谁。第三件是把高频使用的建模操作提前封装成模板，大模型只需要做“选模板+填参数”这个动作，而不是每次都从零生成指令。

另外，无论怎么优化都要做好超时处理。我在系统里给每个零件设置了一个总体时间预算，超时后自动进入人工处理队列。没有兜底方案的自动化系统，上线之后一定会被真实用户骂到怀疑人生。

5. 再往深处走：从单零件生成到更复杂的设计场景

能把一个零件从文字变成模型，只能说明链路跑通了。要从“能跑”走到“能用”，还有几个方向值得深入探索。这一章聊聊我看到的三个进阶方向，每个方向都有一定的技术挑战，但也都有实际的应用价值。

5.1 装配体、约束与零件间关系的表达

从单零件到装配体，是一个质的跨越，也是text-to-cad真正走向工程设计核心的必经之路。单零件生成只涉及“自身几何形状”，装配体生成还要求模型理解零件之间的空间关系：哪个零件放在哪个位置，哪个面和哪个面贴合，运动副怎么定义。

我尝试过的方案是扩展DSL，在指令集里加入装配约束描述。比如“将零件A的底面与零件B的顶面重合，孔中心对齐”。这个描述不是几何建模指令，而是一种装配语义。模型需要输出的不再只是“如何创建这个零件”，还包括“这个零件和其他零件之间的相对关系”。

这个方向目前的技术成熟度还不高，主要难点在于模型的几何空间推理能力有限，很难想象出多个零件在三维空间里的相对位置和装配顺序。不过在一些受限场景里已经可以做得很好了，比如标准件库、管路连接件、螺栓螺母垫圈这类组合，模式非常固定，模型很容易掌握。

5.2 批量生成不再是梦——参数扫描和设计变体

单件生成只是起步，批量生成才是text-to-cad最吸引人的价值点之一。想象一下这个场景：一个产品要做多个型号，每种型号只是尺寸不同，目前工程师需要手工修改模型参数再逐个出图。用text-to-cad系统，你只需要定义清楚变化规则：“内径从20到50，每隔5一个规格，孔数按直径大小适配”，剩下的事情全部由系统自动完成。

这种批量化能力背后的技术支撑，恰恰就是我前面强调的程序化建模路线。因为模型是参数化的，变更尺寸参数就能重新生成新模型；因为特征是完整的，批量导出图纸、批量做仿真都可以无缝衔接。在项目管理、产品选型这类需要多型号数据支撑的场景里，这套能力能节省的时间非常可观。

还有人把这类应用玩得更高级，他们在批量生成的基础上叠加了“设计约束检查”，比如“壁厚不得小于2毫米”“所有倒角半径不小于0.5毫米”。系统生成一个变体就检查一次，不满足的自动打回，满足的进入下一环节。这种“自动建模+自动审核”的组合，正好卡在制造业数字化的需求点上。

5.3 接入现有设计和制造流程的三种方式

最后说说落地接入的问题。一套text-to-cad系统做出来之后，不能只在实验环境里自己玩，要接到设计团队、制造流程、产品数据管理平台里才有真实价值。我整理出三种接入方式，你根据自己团队的情况选择。

第一种是“辅助式”接入。把text-to-cad作为插件或者脚本工具，嵌入到工程师常用的CAD软件里。工程师在对话框里用文字描述需求，系统自动生成初始模型，工程师自己再手动完善。这种方式适合设计团队，因为它的侵入性最小，工程师依然保有最终控制权。

第二种是“自动化”接入。系统接收结构化输入，比如ERP系统里的物料参数表，自动生成对应的三维模型，存到统一的模型库里。这种方式适合标准化程度高、批量大的业务场景，比如标准件、通用件、打包方案。实现难度较大，但收益也最大。

第三种是“协作式”接入。text-to-cad作为设计评审的辅助工具，把产品经理、销售人员的口头描述快速转成模型，放到协同评审平台里讨论。这种方式不追求模型精度，更强调“把想法变成看得见摸得着的东西”的效率。对非设计岗位的价值最直接。

这三种方式不是互斥的，很多团队会结合使用。我在实际规划里比较推荐先做辅助式接入，因为它能最快收集到真实需求，而且工程师的反馈可以直接用来迭代你的Prompt和DSL。等系统成熟度上来了，再逐渐往自动化方向推进。

我个人在实际操作中的体会是，text-to-cad不是一个“一句Prompt解决所有建模问题”的黑魔法，它更像是一条流水线，需要你精心设计每个环节。最花时间的部分往往不是模型调用，而是DSL设计、错误反馈、校验规则这些不起眼的工程细节。把这些细节打磨好，整个系统的体验就会有质的提升。最后再分享一个小技巧：每次跑通一个新类型的零件，都把它沉淀成一个模板，放到你的模板库里。时间长了之后，你会发现自己不是在“生成模型”，而是在“组装模板”，速度会快到一个很夸张的程度。这个方向后续还可以和你团队的知识库、设计规范、历史模型数据打通，让系统越用越聪明。