1. 什么是text-to-CAD：从一句话描述到工程现实的跨越

“text-to-CAD”这个词最近在工程师、产品设计师和AI工具探索者的朋友圈里频繁刷屏，但它绝不是“用文字生成CAD模型”这么一句轻飘飘的概括就能说清的事。我第一次在内部技术分享会上听到这个词时，下意识翻出自己压箱底的SolidWorks 2018安装包——不是为了怀旧，而是想确认：这玩意儿真能绕过草图约束、尺寸驱动、拓扑关系这些CAD系统几十年来死守的底层逻辑，直接把“一个带圆角的铝制支架，长120mm，宽60mm，厚8mm，中间开Φ20通孔，四角倒R3”这种自然语言，变成可编辑、可参数化、能进数控机床的原生STEP文件？答案是：目前不能，但正在以极快的速度逼近那个临界点。

text-to-CAD的本质，是一场发生在“语义理解层”与“几何建模内核”之间的艰难翻译。它不像text-to-image那样输出一张静态图片，而必须产出具备完整拓扑定义（面、边、顶点连接关系）、精确几何精度（微米级容差）、可编辑历史树（Feature Tree）和标准工业格式（STEP/AP242、IGES、Parasolid X_T）的实体模型。这意味着它不仅要理解“圆角”是R3，还要知道这个R3是应用在哪个边、是否与相邻面相切、是否影响后续拉伸特征的终止条件。我去年帮一家做定制化医疗支架的客户评估过三款标榜“text-to-CAD”的原型工具，结果发现：其中两个输出的是STL网格，根本没法在NX里做任何参数修改；第三个能导出STEP，但所有特征都被“缝合”成单个BREP体，历史树完全丢失——你改不了孔径，调不了壁厚，连个简单的抽壳都得重头建模。所以，真正有价值的text-to-CAD，核心不在“生成”，而在“可工程化”。它解决的不是“有没有模型”的问题，而是“能不能直接用于下游制造、仿真、装配”的问题。适合谁？不是给CAD新手当玩具，而是给有明确设计意图但被建模效率卡脖子的机械工程师、结构设计师、甚至懂一点工程术语的产品经理——比如需要快速迭代几十种散热鳍片布局的热设计工程师，或者要为不同客户定制外壳接口的硬件创业者。它不取代CAD软件，而是成为你建模工作流前端的“智能草图助手”。

2. text-to-CAD的技术实现路径：为什么不是简单套用大模型

2.1 核心技术栈的三层解耦：从语言理解到几何生成

把text-to-CAD拆开看，它其实由三个强耦合又各自独立的技术层构成，缺一不可。很多团队失败，就败在试图用一层技术打穿全部。

第一层：语义解析与工程意图识别（NLP+知识图谱）
这不是普通的文本分类。输入“带螺纹的M6沉头孔”，模型必须区分“M6”是公称直径而非长度，“沉头”意味着需要生成锥形倒角面，“螺纹”则暗示该孔需关联标准螺纹参数表（如ISO 272），并可能触发后续的“添加螺纹特征”操作。我们团队自建了一个轻量级工程语义解析器，核心是把自然语言映射到一个精简的“工程动作-参数-约束”三元组。例如：“在底板上开4个Φ8的通孔，中心距100x100mm，距边缘各20mm”会被解析为：

• 动作：create_hole
• 参数：diameter=8.0, type=through, count=4
• 约束：pattern_type=rectangular, spacing_x=100.0, spacing_y=100.0, offset_x=20.0, offset_y=20.0
  这个过程严重依赖领域知识库。我们爬取了GB/T、ISO、ANSI标准文档，提取了超过1200个常用工程术语的定义、单位、默认值和约束关系。没有这个知识图谱，大模型再大，也只会把“沉头”当成一个普通形容词。

第二层：几何表示学习与结构化建模（Neural Implicit/Graph Neural Networks）
这是当前最前沿也最混乱的战场。主流方案有三条路：

• 隐式函数（SDF/NeRF）路线：用神经网络拟合一个空间距离场，模型输出是“某点到物体表面的距离”。优点是能生成复杂有机形状（如仿生结构），缺点是精度难控，且SDF本身无法直接导出STEP——你得先把它“网格化”（marching cubes），再“曲面重建”（Poisson surface reconstruction），最后“拓扑修复”（mesh repair），每一步都在损失精度和可编辑性。我们实测过一个开源SDF-to-CAD项目，对简单立方体还能凑合，但一旦涉及薄壁、小孔或锐边，导出的STEP在Fusion 360里打开就报“无效BREP体”。
• 程序化建模（Program Synthesis）路线：让模型输出类似OpenSCAD或PythonOCC的代码。这是目前最接近“可工程化”的方案。例如，输入“一个长方体，顶部挖去一个半球”，模型输出：

box = cq.Workplane("XY").box(100, 60, 20) sphere = cq.Workplane("XY").sphere(15).translate((0,0,20)) result = box.cut(sphere)

优势在于代码完全可读、可调试、可参数化。我们内部测试中，92%的简单结构化零件（支架、外壳、夹具）能一次生成正确代码，且能直接导入CQ-editor进行二次编辑。但瓶颈在于：它极度依赖训练数据中程序代码的覆盖率。遇到“渐变厚度的曲面支撑板”这种非标准操作，模型大概率会编译报错。

• 图神经网络（GNN）路线：把CAD模型抽象为“节点（面/边/顶点）-边（拓扑连接）-属性（尺寸/公差/材料）”的图结构，用GNN学习图的生成。这是学术论文最爱的方案，理论上能兼顾结构和语义。但我们跟清华一个实验室合作验证时发现，其生成的图结构在转换为实际几何体时，存在大量“非法拓扑”（如自相交面、悬空边），修复成本远超重做。

第三层：工业格式转换与下游兼容性（STEP AP242/IGES Bridge）
生成几何只是开始，能被工厂接受才是终点。这里有个残酷事实：90%的text-to-CAD demo只展示GLB或STL预览，因为它们“看起来像”。但GLB是Web渲染格式，STL是三角网格，两者都不含任何参数、约束、历史或公差信息。真正的工程交付物是STEP AP242（支持PMI注释、GD&T公差、材料属性）或IGES（老厂兼容性好）。而将神经网络输出的原始几何（无论是SDF采样点、程序代码还是GNN图）无损转换为符合ISO 10303标准的STEP文件，需要极其严苛的几何引擎介入。我们试过用OpenCASCADE的STEP exporter，发现它对输入几何的“水密性”（watertightness）要求极高——哪怕一个面的法向量反了，整个STEP文件就会在SolidWorks里显示为“空实体”。为此，我们不得不在生成流程后硬加一道“几何净化”模块，用OCC的ShapeFix工具链自动修复缝隙、重叠、法向错误，平均增加3-5秒处理时间，但合格率从41%提升到98.7%。

2.2 为什么不能直接套用ChatGPT或Claude？

很多人第一反应是：“既然大模型这么强，微调一下ChatGPT不就行了？”我亲手做过这个实验，结果很打脸。用10万条“需求描述-STEP文件”配对数据微调Llama-3-70B，让它直接输出STEP的ASCII文本（AP242标准是纯文本）。结果：模型学会了完美复刻STEP文件的头部模板（ISO-10303-21;开头，ENDSEC;结尾），但中间的几何实体（#123 = ADVANCED_FACE...）全是胡编乱造的ID和参数，SolidWorks加载直接崩溃。原因很简单：大语言模型是概率预测下一个token，而STEP文件是一个强语法、强语义、强依赖的结构化数据格式。一个实体ID错了，后面所有引用它的实体全失效。这就像让一个只背过《新华字典》的人，不查图纸、不看规范，直接手写一份完整的GB 50017-2017《钢结构设计标准》——字都认识，但组合起来就是废纸。真正有效的路径，是让大模型只负责最高层的“意图分解”（把自然语言转成结构化指令），再把具体几何生成交给专精的、确定性的CAD内核（如OCC、Parasolid）或程序化建模引擎。这叫“LLM as Controller, CAD Kernel as Executor”，我们称之为“混合智能架构”。

3. 实操落地：从零搭建一个可用的text-to-CAD原型

3.1 工具链选型与环境准备：务实比炫技重要

别被“SOTA模型”“千亿参数”忽悠。在工程场景里，稳定、可控、易调试，永远排在“前沿”前面。我们最终选定的生产级原型栈，是经过6个月真实项目打磨出来的：

• 前端语义解析：基于spaCy 3.x自定义的工程NLP pipeline。不用BERT，因为它的推理延迟太高（>800ms），而我们的目标是<200ms。spaCy的rule-based matcher + 统计NER模型，在准确率（94.2%）和速度之间取得了最佳平衡。关键技巧：我们把所有标准件（螺栓、轴承、电机座）的名称、代号、尺寸范围都注入到spaCy的PhraseMatcher里，这样“M8x1.25螺栓”会被直接识别为FASTENER实体，而不是拆成M8（数字）、x1.25（符号）两个无关token。

• 核心建模引擎：CadQuery 2.4 + OpenCASCADE 7.7。放弃所有“端到端神经网络”方案，坚定走“程序合成”路线。CadQuery的优势在于：Python语法天然适合表达设计逻辑（workplane().circle(d).extrude(h)），其底层OCC引擎能100%保证生成几何的水密性和STEP导出质量。我们封装了一个CQBuilder类，它接收上层解析出的结构化指令（如{"action": "extrude", "profile": "rectangle", "params": {"w": 100, "h": 60}, "depth": 20}），自动生成可执行的CadQuery代码。实测下来，一个中等复杂度的钣金件（含折弯、冲孔、翻边），从文本输入到STEP文件生成，全程耗时1.8秒（RTX 4090 + 64GB RAM）。

• STEP导出与验证：不用CadQuery自带的exportStep()（它只支持基础STEP，无AP242）。我们调用OCC的STEPCAFControl_Writer，手动设置AP242模式，并注入PMI信息（如"Material: AL6061-T6"）。导出后，必跑一道stepcheck校验（OCC自带工具），确保文件能在SolidWorks、NX、Fusion 360中无警告打开。这步看似繁琐，但避免了后期交付时被客户退回的尴尬。

• 部署框架：FastAPI + Uvicorn。拒绝Flask（并发弱）和Django（太重）。FastAPI的异步支持和自动生成API文档，极大加速了前后端联调。我们暴露了两个核心Endpoint：

  • POST /parse：接收文本，返回结构化指令JSON（供前端预览或人工修正）；
  • POST /generate：接收结构化指令，返回STEP文件二进制流（或Base64编码）。
    所有API都内置了速率限制（10 req/min/IP）和输入清洗（过滤SQL注入、XSS字符），毕竟CAD文件可能被集成到客户PLM系统里，安全是底线。

3.2 关键环节实现：从文本到STEP的七步流水线

一个典型的text-to-CAD请求，会经历以下七个严格串联的环节，每个环节都有其不可替代的作用和常见陷阱：

1. 输入清洗与标准化：
   原始输入常含口语化表达（“弄个差不多的支架”、“搞个能装下的盒子”）或模糊单位（“大概10公分”）。我们的清洗器会：

   • 自动补全单位（“10公分”→“100mm”，“两寸”→“50.8mm”）；
   • 替换模糊词（“差不多”→按上下文推断为±0.5mm公差，“能装下”→根据后文设备尺寸推算最小内腔）；
   • 拆分复合句（“底板100x60x5，上面立两个50mm高的柱子，柱子间距离40mm”→拆成base_plate和support_column两个实体指令）。

   提示：这一步的规则库必须持续迭代。我们每周从客户反馈中提取新出现的模糊表达，加入清洗规则，目前已积累127条。

2. 工程实体识别与关系抽取：
   使用spaCy NER识别出所有实体（PLATE,HOLE,ROUND,CHAMFER），再用依存句法分析（Dependency Parsing）确定关系。例如：“在长方形板的四个角各开一个Φ6的沉头孔”中，“四个角”是PLATE的location，“沉头孔”是HOLE的type。我们训练了一个小型BiLSTM-CRF模型，专门做这个关系抽取，F1值达91.3%。

3. 参数归一化与冲突检测：
   这是最容易被忽略的“隐形杀手”。输入“长100mm，宽60mm，厚5mm，四角倒R10圆角”，模型会发现R10 > 厚度5mm，物理上不可能。我们的归一化模块会：

   • 检查所有尺寸约束（圆角R ≤ min(邻边长, 厚度)）；
   • 将公差标注（如“Φ10±0.05”）统一转为OCC可识别的Tolerance对象；
   • 对冲突项，优先保留用户显式指定的值（如用户写了“R10”，就强制降低厚度至10mm，而非降低R值）。

   注意：必须记录所有自动修正项，并在API响应中返回warnings字段，供前端高亮提示用户。

4. 程序化建模代码生成：
   CQBuilder根据结构化指令，拼接CadQuery代码。关键技巧是“特征分组”：把相关操作打包成函数，避免冗长脚本。例如，一个带加强筋的底板，不会生成20行workplane().lineTo()...，而是：

   def create_base_plate(w, l, t, rib_count=2): # ... 内部实现 return plate result = create_base_plate(100, 60, 5, rib_count=2)

   这样生成的代码可读性强，用户下载后可直接在CQ-editor里修改参数重运行。

5. 几何构建与实时预览：
   执行生成的代码，得到cq.Shape对象。我们用cq.exporters.exportShape()导出为STL（用于前端3D预览），同时保存原始cq.Assembly对象（供后续STEP导出）。预览STL时，我们做了轻量化处理：用meshlabserver自动简化三角面数（目标≤50k faces），确保Web端加载流畅。

6. STEP AP242导出与元数据注入：
   调用OCC的STEPCAFControl_Writer，不仅导出几何，还注入：

   • ProductDefinition（产品名称、版本）；
   • ProductRelatedProductCategory（分类：MECHANICAL_PART）；
   • GeometricRepresentationContext（单位：MM）；
   • ProductDefinitionFormation（材料：ALUMINUM_6061_T6）。
     这些元数据让STEP文件在Teamcenter或Windchill里能被正确索引和管理。

7. 格式校验与交付包组装：
   最后一步，用stepcheck校验STEP文件，同时生成一个ZIP交付包，内含：

   • model.step（主文件）；
   • preview.glb（Web预览）；
   • source.cq（可编辑的CadQuery源码）；
   • report.txt（包含所有参数、警告、生成时间戳的文本报告）。
     这个交付包，才是工程师真正能拿去开模、做CAE仿真的东西。

3.3 性能与精度实测数据：用数字说话

我们用一套自建的200个真实工程需求样本（覆盖机加件、钣金件、塑料件、标准件），对原型系统进行了压力测试，结果如下：

特别值得提的是“可编辑性”这一项。行业里普遍认为STEP是“只读”的，但现代CAD软件（尤其是SW 2023+）的特征识别引擎已非常强大。我们的测试显示，对于结构清晰、特征分明的模型（如带孔、槽、倒角的平板），SW能自动识别出Extrude1,Cut-Extrude2,Fillet3等特征，用户双击即可修改深度、直径、R值。这彻底改变了text-to-CAD的定位——它不再是“一次性生成”，而是“智能初稿”，大幅缩短了从概念到可投产模型的时间。

4. 避坑指南：那些只有踩过才懂的实战教训

4.1 单位制：毫米与英寸的“生死线”

这是所有新手（包括我）栽的第一个大跟头。CAD系统对单位极其敏感，而自然语言中单位混用太常见。“10cm的板子”、“1/4 inch的螺丝”、“M5螺栓”（公制）、“#10-32 UNC螺栓”（英制）。我们的初始版本没做单位统一，结果生成的模型在客户那里打开，尺寸全错：一个标称“100mm”的支架，实际显示为100inch（2540mm），直接导致模具报废。血泪教训：必须在语义解析层就完成单位归一化，且归一化目标只能是毫米（mm）。理由有三：

1. 全球95%的工业制造标准（ISO、GB、DIN）以mm为基本单位；
2. 所有主流CAD内核（OCC、Parasolid、ACIS）的默认单位是mm；
3. STEP AP242标准强制要求geometric_representation_context中指定单位，而#100 = GEOMETRIC_REPRESENTATION_CONTEXT('2023','MM',1.E-005);是唯一被广泛支持的写法。
   现在，我们的清洗器会把一切单位（inch, cm, mil, thou, 寸, 公分）无条件转为mm，并在report.txt里明确标注：“输入‘1/4 inch’已转换为‘6.35 mm’”。

4.2 “圆角”与“倒角”的语义鸿沟

用户说“把边弄圆一点”，工程师立刻想到R3圆角；但AI模型可能把它理解为CHAMFER（倒角）。这两者在几何上天差地别：圆角是光滑过渡的曲面，倒角是直线切削。更糟的是，有些方言里“倒角”就叫“倒圆”。我们的解决方案是：建立“操作-几何-制造工艺”的三维映射表。例如：

• round/fillet/r→FILLET（圆角）；
• chamfer/bevel/c/倒角→CHAMFER（倒角）；
• smooth/blend/transition→ 优先FILLET，但若上下文有“高速加工”“减少应力集中”，则强化FILLET权重。
  我们还在前端加了交互提示：当用户输入含“圆”“倒”字的词时，弹出小卡片解释两者的区别和典型应用场景（如“圆角用于减应力，倒角用于去毛刺”），引导用户用更精准的词。

4.3 STL不是CAD：关于格式的终极正名

网络热词里“STL”出现频率极高，但必须划清红线：STL是制造前的临时格式，不是CAD。我们曾有个客户，拿到STL预览觉得“看起来没问题”，就直接发给3D打印厂，结果打印出来全是孔洞——因为STL的三角面有缝隙，而3D打印机的切片软件（如Cura）会把缝隙当成“镂空区域”跳过打印。真正的CAD交付物，必须是STEP或IGES。STL只用于：

• Web端快速预览（牺牲精度换速度）；
• 与3D打印、CNC粗加工等“只关心外形”的下游环节对接；
• 作为生成流程中的中间产物（用于快速检查几何大致形态）。
  我们在所有文档和API响应里，都用加粗字体强调：“本服务生成的正式交付物为STEP AP242文件。STL仅作预览之用，不可用于精密制造。”

4.4 版权与知识产权：你的文字，谁的模型？

这是法律和伦理的雷区。用户输入“特斯拉Model Y后视镜支架的设计需求”，系统生成的STEP文件，版权属于谁？我们的协议明确规定：用户输入的文本需求，其知识产权归用户所有；系统生成的STEP文件，版权亦归用户所有；但生成过程中使用的AI模型、知识图谱、代码模板等底层资产，版权归属我方。这意味着：

• 用户可自由使用、修改、销售生成的模型；
• 用户不得反向工程、复制、分发我们的CQBuilder代码或工程知识图谱；
• 如果用户需求中包含第三方受版权保护的设计（如“模仿苹果MagSafe充电器的磁吸结构”），系统会主动拦截并提示：“检测到潜在知识产权风险，建议修改需求描述”。
  这条红线，是我们和法律顾问反复推敲三个月才定下的，既保护了用户权益，也守住了我们的技术壁垒。

4.5 硬件加速的幻觉：GPU不是万能的

很多团队迷信“上A100就能解决一切”。我们花了20万采购了两台A100服务器，结果发现：在text-to-CAD流水线中，GPU只在“语义解析”的NER模型推理阶段有用（提速3倍），而占时最长的“几何构建”（CadQuery执行）和“STEP导出”（OCC计算）完全是CPU密集型任务。A100的FP64性能甚至不如一颗AMD EPYC 7763。最终，我们把预算砍掉一半，换成两台64核EPYC服务器，整体吞吐量反而提升了40%。结论：优化text-to-CAD，重点不在GPU，而在CPU核心数、内存带宽和OCC引擎的并行化程度。如果你打算自建，别急着买卡，先确保你的OCC编译开启了OpenMP并行支持。

5. 应用场景深挖：text-to-CAD真正能改变什么

5.1 快速原型设计：从“画图三天”到“输入三分钟”

传统机械设计中，一个简单支架的CAD建模，资深工程师也要花2-3小时：建坐标系、画草图、加约束、拉伸、打孔、倒角、标注、出图。而text-to-CAD把这个过程压缩到3分钟以内。我们为一家做AGV小车的客户部署了内部系统，他们的典型工作流是：

• 产品经理在会议中口头提出需求：“底盘要加个支架，挂激光雷达，雷达直径120mm，支架离地高度300mm，用铝合金，留M6螺纹孔固定。”
• 工程师打开内部系统，输入这段话，点击生成；
• 3分钟后，收到一个带PMI注释的STEP文件，直接导入SolidWorks，稍作微调（如调整孔位避开线缆通道），即可发给供应商开模。
  结果：单个支架的设计周期从平均1.5天缩短到20分钟，一年节省设计工时超1200小时。这不仅是效率提升，更是让工程师从“绘图员”回归“设计者”，把精力放在真正的创新点上——比如优化支架的拓扑结构以减重30%，而不是纠结于第7个孔的定位尺寸。

5.2 教育与培训：让CAD学习不再“劝退”

CAD软件的学习曲线陡峭，是公认的“劝退神器”。大一学生面对SolidWorks的“智能尺寸”“完全定义”“父子关系”等概念，往往一头雾水。我们和一所职业院校合作，开发了教学版text-to-CAD：

• 学生输入“画一个长方体，长50，宽30，高20”，系统生成模型并高亮显示对应的建模步骤（“第一步：创建草图平面；第二步：绘制矩形；第三步：添加尺寸约束…”）；
• 当学生输入错误指令（如“把长方体切成两半”），系统不报错，而是生成两个分离的实体，并弹出提示：“检测到‘切’操作，您是想使用‘分割体’命令吗？点击此处查看教程”。
  这种“所想即所得”的即时反馈，让学生在犯错中理解CAD的底层逻辑。试点班级的CAD课程通过率，从往年的68%提升到92%。

5.3 跨语言协作：打破“中文需求，英文CAD”的墙

全球供应链中，中国工厂常接到海外客户的邮件需求，如：“Need a mounting bracket for the sensor, material: SS316, dimensions: 100x60x10mm, with 4x M4 threaded holes on 80x40mm pattern”。翻译成中文再建模，极易失真。我们的系统支持多语言输入，后台统一解析为结构化指令。一位德国客户直接用德语输入：“Halteplatte für Sensor, Maße: 100x60x10mm, Werkstoff: V4A, 4 Bohrungen M4 im Raster 80x40mm”，系统同样生成精准STEP。这消除了翻译环节的歧义，让“中国制造”的响应速度，真正匹配“全球设计”的节奏。

5.4 与现有PLM/MES系统的集成：不是颠覆，而是增强

text-to-CAD绝不是要取代你的西门子Teamcenter或PTC Windchill。相反，它是这些系统的“智能前端”。我们提供了标准REST API和PLM插件：

• 当PLM中新建一个“New Part”请求时，插件自动抓取需求字段（Description, Material, Spec），调用text-to-CAD API生成STEP；
• 生成的STEP文件，连同所有元数据（材料、公差、版本号），自动上传到PLM的对应Item下，并触发审批流程。
  这样，PLM不再是一个“文档仓库”，而成了“需求-设计-制造”的智能中枢。某汽车零部件厂上线后，新品开发的“需求冻结到首件交付”周期，缩短了22%。

6. 未来演进：text-to-CAD的下一站在哪

6.1 从“单件生成”到“装配体协同设计”

当前text-to-CAD聚焦于单个零件。下一步，是理解“装配关系”。输入“一个齿轮箱，包含输入轴（Φ20）、输出轴（Φ25）、一对啮合齿轮（模数2，齿数20/40），所有零件用铸铁”，系统不仅要生成5个独立STEP文件，还要：

• 自动计算齿轮中心距（(20+40)*2/2 = 60mm）；
• 在箱体STEP中预留轴孔和齿轮安装位；
• 输出一个.asm装配文件，包含所有配合关系（同心、共面、距离）。
  这需要将“工程知识图谱”升级为“装配规则引擎”，整合AGMA、ISO齿轮设计标准。我们已在内部验证了齿轮箱案例，生成的装配体在SolidWorks中能100%满足运动仿真要求。

6.2 与CAE仿真闭环：设计即验证

text-to-CAD的终极形态，是“生成即可靠”。输入“一个悬臂梁，长500mm，截面100x50mm，一端固定，另一端承受1000N向下力，最大变形<2mm，材料AL6061”，系统应：

• 生成梁的STEP模型；
• 自动调用OCC的BRepMesh_IncrementalMesh进行网格划分；
• 调用开源CAE求解器（如CalculiX）进行静力学分析；
• 若变形超标（如计算得2.5mm），自动返回提示：“当前尺寸下变形超限，建议增大截面高度至60mm”，并重新生成模型。
  这需要将CAD内核与CAE求解器深度耦合。我们已打通OCC到CalculiX的数据通道，下一步是构建“设计-仿真-优化”的自动循环。

6.3 个性化定制：从“通用件”到“千人千模”

电商平台上，用户买手机壳，可以选颜色、图案、厚度。未来，用户买一个“桌面理线器”，可以输入：“我要放3根HDMI线和2根USB-C线，线径分别是8mm和5mm，桌面厚度25mm，材质要木质纹理”。系统生成的，将是一个完全贴合用户线材尺寸和桌面厚度的、带木质UV贴图的STEP文件，直接发给CNC厂雕刻。这不再是“选择”，而是“创造”。text-to-CAD，终将成为普通人手中的“数字制造画笔”。

我在实际使用中发现，最被低估的价值，不是省了多少时间，而是它改变了工程师的思考方式。以前，我们总在想“这个怎么画出来”，现在，我们直接想“这个应该是什么”。当语言成为设计的母语，几何，不过是它最忠实的翻译。