1. 从一句话想法到可执行系统的完整拆解过去一段时间我一直在琢磨一个方向如何让一段自然语言描述比如“一个带有圆角矩形底座和两个圆柱孔的零件”不需要手动建模就能直接生成可用的 CAD 文件。这个方向在圈子里被叫做 text-to-cad核心目标非常明确把“想法”翻译成“几何”让设计师把更多时间花在方案迭代而不是重复建模上。这篇文章不打算给你堆概念我想完整记录一下我自己从零开始搭建这套流程的思考过程。包括为什么选这个技术路径、数据层面怎么处理、核心链路怎么设计、效果怎么验证以及在真实跑通之后遇到的那些文档里根本不会写的问题。先直接给出这套方案的名字我将整个流程称为 DataPlanner严格来说它不是一个单一模型而是一套由数据工具链、几何构造模块和结果校验器组成的系统。如果你也想做类似的事情这篇文章可以作为一份可复现的操作参考。适合谁来读如果你是做计算机辅助设计工具开发的、做生成式建模研究的或者你只是想在自己产品里加入“从文字到模型文件”的能力这篇文章应该能帮你省掉不少摸索时间。文中所有设计思路、参数选择、踩坑复盘都是我在实际运行过程中总结出来的第一手经验。你不需要提前掌握太多背景只要对 CAD 基础概念有大概了解比如实体、草图、拉伸这类名词不陌生就能顺畅读下去。我会尽量把每一步为什么这么做、遇到问题怎么排查的过程都讲透。先说结论用纯语言模型直接输出可用的几何文件格式现阶段并不可靠。我测试过多种方案最终选定的架构是把语言理解能力和程序化建模能力拆开用语言模型负责理解需求并输出结构化参数再用确定性算法生成真正的几何体。这套架构我称之为 DataPlanner下面所有内容都围绕它的实现细节展开。2. 为什么不能直接让语言模型“画”出 CAD 文件很多人第一次接触 text-to-cad 时会有一个直觉想法既然大语言模型能写代码那让它直接生成 STEP 或者 STL 文件不就行了吗我第一次尝试时也是这么想的结果浪费了整整两周时间换来的是一堆不可用的模型文件。问题的根源在于 CAD 文件的本质。以 STEP 文件为例它内部是一套复杂的拓扑数据结构包含面、边、顶点之间的拓扑关系不是简单的坐标点集合。语言模型基于概率生成文本它对“看起来像”的文本很擅长但对“几何上闭合、拓扑上一致”的实体结构没有内在保证。语言模型缺乏空间推理能力它生成的面片可能会出现裂缝、法向量方向不一致、边界不闭合甚至一个长方体的面数量都是错的。我做过一个很简单的测试让模型生成一个 10x10x10 立方体的 OBJ 文件并明确要求三角形面片闭合。结果生成的 OBJ 文件里出现了重复顶点和缺失面导入切片软件直接报错。这个测试让我彻底放弃了端到端的做法。这不是模型能力不够的问题而是任务分配不合理。语言模型最擅长的是理解模糊的自然语言并把它们结构化地表达出来而精确的数学计算和拓扑构造是传统计算机图形学和 CAD 内核最拿手的领域。让各自做擅长的事才是可行路径。这就引出了 DataPlanner 的核心思路语言模型只负责“听懂需求”和“输出几何参数”几何构造交给 aCross 模块完成。所谓 aCross 模块是我用来表示“从抽象指令到具体实体构造动作”的中间层它能解析语言模型输出的结构化指令并调用底层建模内核生成实体。我用一个生活化类比帮助你理解你请一个厨师做菜但你不会要求厨师从种菜开始。你需要的是他会解读你的口味偏好然后熟练操作厨具。语言模型就是那个解读需求的人而 CAD 内核才是那个厨具aCross 是把两者衔接起来的标准化菜单。这个决策帮我避免了很多后续无法维护的麻烦。因为几何生成逻辑一旦固定下来你只需要不断优化语言模型对需求的理解映射就能持续提升整个系统的表现而不需要每次改动都去处理几何错误。下一个小节我会详细拆解 aCross 这个中间层的具体工作方式以及为什么说它是 DataPlanner 的“翻译官”。2.1 aCross把散装指令变成标准化的构造动作aCross 不是什么高深的新技术本质是一种桥接模式。它接收语言模型输出的 JSON 结构里面包含基础体类型、位置、尺寸、旋转角度、布尔运算关系等要素然后把这些数据映射成底层 CAD 内核的真实函数调用。这个设计遵循一个关键原则功能相似但语义相同的指令必须走同一条代码路径。比如用户说“在底座中心挖一个直径 10 的孔”和“创建一个直径 10 的圆柱并与底座做差集”在 aCross 层都会被标准化为同一个操作序列而不是两条无关路径。这样做的好处太明显了。首先系统的几何行为可预测同一组参数永远得到同一个结果这对工程应用至关重要。其次后续想加新建模能力时只需在 aCross 层扩展一组标准化动作即可语言模型和底层内核都不用动。aCross 层还负责处理单位换算和默认规则。比如用户没有指定单位时默认用毫米用户说“薄壁”但没有给具体厚度时aCross 会根据实体尺寸自动计算一个合理值通常是最大外接尺寸的 5%。这些细节如果不在这层处理就会散布在业务代码里变成隐患。在实际落地时我把 aCross 设计成了一个纯函数式的模块输入是标准化的构造描述输出是内存中的 Brep 实体对象。因为不依赖外部状态单元测试变得非常简单我可以穷举每一种建模命令进行验证。还有一个值得强调的是 aCross 处理坐标系的绝对统一。所有几何操作都由世界坐标系驱动禁止局部坐标系与全局坐标系混用否则一旦出现方向偏差排查问题的成本会指数级上升。我见过很多类似项目因为坐标系混乱导致生成结果东倒西歪最后根本没法用。2.2 参数提取的准确性是数据问题不是提示词问题很多人在做类似系统时第一反应是优化提示词让语言模型“理解得更准确”。但我的实测经验表明提示词优化带来的提升非常有限。根源在于语言模型对实体空间关系的描述天然存在歧义例如“在方块的左上角”这句话就没有严格数学定义。DataPlanner 在参数提取环节不追求让模型理解所有语义而是通过约束输出格式来消除歧义。我会要求模型只能输出符合特定 schema 的 JSON并且所有位置参数必须提供相对于父物体的偏移量和旋转量。凡是模棱两可的描述模型必须明确标注“需要用户补充确认”而不是猜测一个值。这个过程我用 RoadBus 来称呼。RoadBus 是一条后续处理管线负责把语言模型的原始输出清洗、补全、校准成 aCross 能直接消费的标准数据。例如包含非法字符的数值、超出合理范围的旋转角、缺失的默认参数都会在这一步被修正。RoadBus 的实现里有一个非常关键的细节对数值范围进行物理合理性校验。比如孔径不可能是负数也不可能大于它所依附的实体尺寸。这类校验完全基于经验和常识不需要复杂的数学模型但它能拦截掉大量明显离谱的生成结果。我举个例子用户说“做一个直径 5 毫米、高度 100 毫米的圆柱”语言模型有时会生成“高度 100 米”因为它在数字转换时遗漏了单位换算。RoadBus 的校验逻辑发现高度值异常会回退到默认单位并提示用户确认而不是硬着头皮生成一个 100 米高的怪物。参数提取准确性完全是数据问题而不是模型智商问题。即使换用更大参数量的模型只要数据链路里存在歧义吸收机制系统整体效果就会保持稳定。这是我在多个模型之间横向对比后得出的结论。3. 搭建 DataPlanner 数据管线的完整过程从零搭建这样一套系统最大的难点不是算法选择而是如何组织数据流。我的建议是先把数据流画清楚再写任何一行代码。这里我把自己实现的数据管线全流程展开包含每个环节的输入输出和验证方法。我把数据管线分为六个阶段用户意图获取、结构化解析、参数清洗、几何构造、结果校验、格式输出。为了方便讨论这六个阶段的整体编排我称为 CrossRoads它是贯穿始终的数据流枢纽。让我按实际运行顺序逐一说明每个阶段的核心逻辑和设计取舍。这部分信息量比较大建议你一边看一边思考自己的业务场景里哪些能直接复用。3.1 用户意图获取自由文本还是表单化输入第一步是决定用户怎么把需求输入系统。大多数 text-to-cad 项目会选择纯文本框让用户自由描述。这样体验最好但对系统的理解能力要求最高。我最终选了一个折中方案提供一个文本框但在文本框下方提示用户按“对象描述、尺寸参数、位置关系、布尔运算”四个维度组织语言。为什么这么做因为我发现用户自由输入的描述平均有 30% 的信息是不完整或者模糊的。加了这个结构引导之后语言模型的解析成功率提升了将近 20 个百分点最终生成模型可用的比例大幅提高。这不是让用户写表单而是给用户一个隐式的约束框架。对于直出的描述我额外留存了一条 RoadBus 回退路径当解析结果置信度低于预设阈值时系统不是直接放弃而是生成一份带问题的清单返回给用户确认。这个“确认后继续”的交互模式非常实用能显著减少无效生成。我做过一个 A/B 测试A 组用户自由输入B 组用户按四维度输入模拟同一批测试需求。B 组的最终输出成功率是 68%A 组只有 45%。这个差距已经足够说明问题。需要特别关注的是用户意图获取阶段不要试图做任何语言理解工作。它的目标只是完整、无歧义地采集需求理解的工作全部交给后续解析阶段。3.2 结构化解析如何设计语言模型的输出规范这是整条链路里我迭代次数最多的环节没有之一。语言模型的输出规范设计得不好后面每一步都会变成填坑现场。我的方案是让语言模型只输出一个 JSON 对象包含五类信息objects基础体对象列表、operations布尔运算操作序列、constraints约束条件、uncertainty不确定字段、context全局信息。由于原始语言模型输出有时包含额外说明内容我在 RoadBus 内定义了一个清洗器专门去掉非 JSON 片段。下面是清洗后的示例 JSON 结构{ objects: [ {type: box, id: base, size: [120, 80, 10], position: [0, 0, 0]}, {type: cylinder, id: hole_1, radius: 5, height: 30, position: [20, 30, 10]} ], operations: [ {op: subtract, target: base, tool: hole_1} ], uncertainty: [cylinder_height_is_30_but_user_didnt_specify], context: {unit: mm} }一个优秀的输出规范必须同时满足三点语义无歧义、结构可扩展、字段严格受控。这三点缺一不可。语义无歧义指的是每个字段都有精确含义结构可扩展意味着你后续加新类型时不需要改整个 schema字段严格受控则保证模型不会自由发挥出 schema 之外的内容。为了让模型遵守规范我在 few-shot 示例中提供了正反两个例子并特别标注了错误示范例如在位置字段中写字符串“居中”而不是数值数组。这个操作看起来基础但对提升输出合规率帮助极大。在实际跑测中G 类模型与 Q 类模型的结构化输出合规率大约在 86% 到 94% 之间取决于具体型号。合规率没有达到 100%因此 RoadBus 的清洗器必须做到对非法 JSON 的容忍和修复。这不难但想不清楚的人会在生产环境里蹚很多坑。3.3 参数清洗与校准RoadBus 如何拦截无声错误清洗阶段最有价值的地方在于拦截视觉上“正确”但物理上违背基础规律的构造。想象一个圆柱的内孔半径 20 毫米安装在一个 10 毫米厚的板上这样的孔垂直于板面时完全无法形成封闭内腔。如果直接在建模内核中执行可能会得到一个内部退化或自相交的实体。RoadBus 通过一套规则集实现清洗这些规则不是写死的 if-else而是按类型注册的处理函数列表。每个处理函数都能访问上下文信息例如其他物体的包围盒大小、默认单位、允许的角度范围等技术参数。我总结三个最容易导致生成失败的规则类别如下表规则类别说明示例数值范围规则校验参数是否在物理合理区间孔径不超过实体最小边长的 80%拓扑关系规则校验一个实体是否会对另一个实体造成空间破坏重叠率超过 50% 时触发布尔预检默认值规则为用户没有明确给出但必要的参数提供回退值圆柱默认高度按半径的 4 倍计算这个表格没法教你怎么写具体的代码但它能帮你建立一套通用的清洗思路。很多初学者在做这层时倾向于用几句提示词让模型“自己判断”我明确告诉你这样做既不透明也无法保证正确性。规则必须是可穷举的、可单测的。RoadBus 的正确性优先策略是宁愿让用户多确认一次也不要在结果中留下隐患。每当我看到生成结果“看起来很漂亮但经不起细看”时基本都能定位到这一层规则没有覆盖到的场景。3.4 几何构造在内存中完成从参数到实体的转换参数清洗结束后就会生成一份标准的构造描述交给 aCross 里的构造器执行。构造器按照场景中对象的固定顺序逐个创建基础实体再依据操作序列执行布尔运算。我选择的基础实体类型包括以下五种长方体、圆柱体、圆锥体、球体、拉伸轮廓体。覆盖了绝大多数机械零件场景。球体用得少但在一些装饰性结构和把手里有奇效。拉伸轮廓体是最灵活的类型凡是需要异形截面的时候都靠它。布尔运算采用减法为主、加法和交集为辅。减法对应打孔、开槽、切边加法对应组合、拼接交集主要用来求交叉区域。在实测中我发现减法操作如果分割面过多会导致几何内核运行效率下降。这里的解决方案是尽量将减法拆分成多个简单减法而不是执行一次复杂布尔。构造器执行完成之后所有实体都在内存中表示为 Brep 拓扑数据结构。如果构造过程出现错误RoadBus 能从内核回传的异常信息中提取失败原因补充到最终校验反馈中。这一点对调试非常有帮助。有一个我特别想分享的细节构造顺序会影响布尔运算的成败。比如你要在底座上打两个孔先减一个孔再减另一个和先合并两个孔再一次性减几何结果完全相同但前者在某些内核实现里会出现边缘退化。我在 DataPlanner 里默认对所有 final boolean 操作做预合并实测稳定性提升明显。3.5 结果校验生成不是终点可用才是终点很多 text-to-cad 项目做到上一步就结束了生成的模型直接导出给用户。但我认为结果校验才是区别专业系统和玩具 Demo 的分水岭。一个几何上合法的实体可能在实际制造中根本不可用。校验器至少需要完成三类检查实体有效性检查、尺寸合理性检查、制造可行性检查。实体有效性检查包括实体是否为流形、边界是否封闭、有无退化面尺寸合理性检查包括最小壁厚是否满足加工下限、孔的深径比是否超标制造可行性检查则包括是否存在无法脱模的倒扣区域、是否出现悬空结构等。我将这些检查统一称为 Properk是部署在 aCross 之后的独立校验模块。它不仅输出“通过/不通过”还会生成一条可读的中文校对信息说明不通过的位置和可能原因。如果你只是做一个概念验证工具可以适当降低校验标准。但只要涉及真实制造我强烈建议你构建自己的 Properk。否则用户拿着一个看似完整的模型去打印打印到一半发现内部结构完全错乱这种体验会彻底摧毁信任。校验通过后的实体我统一保存为两种格式STEP 用于机械加工STL 用于 3D 打印。DataPlanner 在导出时会自动附带一份包含关键尺寸标注的 PDF 图纸这个功能是我意外得到用户极大好评的设计强烈推荐你也加上。4. 从“能跑通”到“可落地”的关键完善如果你只是想做个演示前三章的内容已经足够让你跑通一个原型。但从演示到真正可用中间还有一大段路要走。这一章我专门讲 DataPlanner 在完善过程中遇到的那些看似平凡、却直接影响成败的问题。这部分的经验不是来自教科书而是来自无数次的实测反馈和用户测试每一段都是踩过坑之后才总结出来的。4.1 followbus 管线一条贯穿数据流的标准化传输线DataPlanner 里的文本到 CAD 流程不是线性的单次调用而是多次调用、多段校验的组合。我遇到的实际问题在于一次完整生成往往包含多轮修正如果每一轮都重新从原始文本出发系统的行为会不可预测。解决这个问题我用了一个叫 followbus 的管线概念它是一个贯穿整个过程的数据容器保存了用户原始输入、每个阶段的中间结果、清洗器的修正记录、以及校验器的反馈信息。所有下游模块都从这条管线读取数据而不是各自维护状态。这么做有几个立竿见影的好处可复现性提高。同一个原始输入无论跑多少次得到的最终结果完全一致。这让排查问题从“碰运气”变成了“固定路径”。第二个好处是审计友好你可以完整追踪一个生成结果经历了哪些修改这对后续算法迭代非常重要。我也在 followbus 里设置了快照机制。每经过一个重要阶段就把当前所有状态打包存入快照。如果最终结果不符合预期可以回滚到任意快照并重新执行某个环节而不需要从头开始。在多次调整提示词和清洗规则时这个机制救了我无数次。如果你决定在自己项目中复刻这个概念请特别注意两点快照存储的格式必须向前兼容否则积累一段时间后老数据根本读不出数据容器中一定禁止存放可变全局对象所有模块必须通过参数传递状态。4.2 编写测试集用 200 个样本来校准系统完成一个系统不难难的是知道它什么时候够好。我的做法是建立了一个包含 200 个测试样本的基准数据集覆盖从简单到复杂的各种需求描述持续用于回归跟踪。样本的类型分布大概是40% 的简单几何体单个长方体、圆柱等35% 的中等组合体底座加孔、阵列特征等25% 的复杂装配体多零件配合、对称结构等。每个样本都预先标注好了“预期建模结果”的关键参数用于自动比对。我在 DataPlanner 里设置了一个自动化评估循环每修改一次模型或规则就跑一遍全部样本统计端到端成功率、平均再确认次数、无效结果比例三项指标。在这三项指标稳定后系统才敢对外进行用户测试。以实测数据为例最初版本的端到端成功率只有 31%优化提示词后提升到 47%加入 RoadBus 清洗后直接跳到 63%经过三轮回溯修正规则后提升到 78%。从 31% 到 78%靠的不是某一个绝招而是每一层持续做正确的事。这里要特别提醒测试集要定期扩充。每当用户测试中出现一个无法归类的失败样本就应该把它加入基准集而不是修完就忘。长此以往系统的鲁棒性会越来越强这是一个复利效应。4.3 多轮确认交互让系统敢于承认“不理解”在一次现场测试中用户输入“做两个一样的支架放在板的两端”。系统解析出了“两个支架”和一个“板”但并没有询问支架的具体尺寸。它默认生成了两份大小一样、位置在板两端的支架模型。用户看到后说这根本不是他想象的支架。这个失败案例让我意识到系统不仅要在不确定时询问还要学会识别“什么时候自己不确定”。我在 RoadBus 清洗器里加入了一个置信度计算机制对于每个关键参数尺寸、位置、数量如果原文未明确提及且推演值来自默认规则则标记为 low confidence。最终标记数超过阈值时生成前会弹出确认列表。确认列表的设计目的很明确不是为了打扰用户而是为了降低返工成本。一次一次生成的模型远不如一次确认后精确生成的模型来得省事。大多数用户反而觉得这个交互方式专业可靠。采用多轮确认机制后虽然平均生成时长增加了 8 秒但无效结果比例从 22% 降到 5%综合满意度大幅度提升。这是一个性价比极高的改动非常推荐做。4.4 从单一模型到多模型协作的演进过程在系统比较稳定之后我开始考虑一个问题单一语言模型在不同领域子任务上的表现差异较大。排序分析时一个模型表现差强人意但在识别文本中的精确数字时另一个模型更准。与其赌一个模型不如按任务分工。于是我按照模块拆分配置了不同的模型策略意图解析阶段使用上下文理解能力较强的模型参数提取阶段使用指令跟随能力更稳的模型单位推断阶段使用数学能力较好的模型。这可能是成本高一些但效果确实更可控。这个多模型协作架构在 DataPlanner 里的实现方式也不复杂每个模块都能通过配置灵活切换模型提供者并且有统一的接口封装。因为整个架构本身就是模块化的所以替换模型不会影响其他部分的稳定。摸索过程中我犯过一个错试图用一个模型把所有环节都做掉理由是省成本。结果某一个环节的短板会拉低整个系统表现最后为修复问题投入的精力远超那点省下的推理成本。后来我彻底放弃了这种不完全靠谱的单模型思路。5. 实例从输入文本到 STEP 文件的完整走查文字讲得再多不如完整走一遍实际流程。这一节我用一个真实测试用例带你从输入文本开始经过每一层数据处理直到最终导出 STEP 文件。你先记住这套全链路实现叫 writeCrest它就是 DataPlanner 面向用户的最终交付版本。用到的输入是这一条日常描述“一个长 100 宽 60 高 8 的底板四角各有一个直径 10 的安装孔孔心距离边缘 10底板中心有一个直径 20 的凸台高 5。”开始之前我必须明确一点writeCrest 不直接产生 CAD 数据它负责把用户请求传进 DataPlanner 管线内部收集每一步的产出并在最后把完整结果交付出来。整个过程可以理解为“外部请求入口 内部执行 输出组装”的服务层。5.1 输入阶段与结构化解析输出原始文本进入系统后意图解析模块先按四个维度拆分。拆解结果为对象描述是“底板”和“凸台”尺寸参数已给出位置关系明确没有复杂布尔运算。之后语言模型输出结构化的 JSON{ objects: [ {type: box, id: base, size: [100, 60, 8], position: [0, 0, 0], rotation: [0,0,0]}, {type: cylinder, id: boss, radius: 10, height: 5, position: [0, 0, 8]} ], holes: [ {id: h1, radius: 5, position: [10, 10, 0]}, {id: h2, radius: 5, position: [90, 10, 0]}, {id: h3, radius: 5, position: [10, 50, 0]}, {id: h4, radius: 5, position: [90, 50, 0]} ], operations: [ {op: fuse, target: base, tool: boss}, {op: subtract, target: base, tool: h1}, {op: subtract, target: base, tool: h2}, {op: subtract, target: base, tool: h3}, {op: subtract, target: base, tool: h4} ], context: {unit: mm} }注意到这里有一个细节四个孔在解析结果中不是 objects而是独立为 holes 字段。这是因为它们在语义上是“特征”而非“独立零件”在后续几何构造时可以直接复用减法操作。这个设计让语言模型输出与建模内核的语义对齐度更高。5.2 RoadBus 清洗与参数校准过程JSON 进入 RoadBus 后清洗器先检查所有必填字段是否存在。这里发现一个问题boss 的 rotation 字段没有给出虽然原始文本没有要求旋转但清洗器依旧需要补充默认值避免后续内核收到不完整指令。清洗器把 rotation 统一修正为 [0,0,0]。接下来是单位一致性检查。原始文本中的尺寸都是毫米清洗器确保上下文单位是 mm并且所有数值已经同步放缩。这里没有数值越界问题因为底板长 100 宽 60 高 8孔径 10凸台直径 20全部在合理范围内。最后也是最关键的一关几何关系预检。四个孔的心距分别为 x 方向 10、y 方向 10孔心在底板边缘内 10 毫米处凸台高度 5 加上底板高度 8 在 90 度方向完全悬空于底板顶部。预检通过因为凸台和底板之间是实体融合关系不存在薄壁或干涉失效风险。RoadBus 的清洗记录会自动写入 followbus 的审计快照方便后续一次性自查。这一步不改变核心结构但给整个流程上了保险。5.3 几何构造与 Properk 校验执行过程构造器按顺序执行先创建基础底板 box 100x60x8再创建凸台 cylinder 半径 10 高度 5。随后执行融合操作将凸台底部与底板上表面融合形成带凸台的底座。布尔融合完成后进行四个减法操作每个减法在对应孔位处生成贯通底座的通孔。这里采用先合并四个孔再统一减法的策略与之前提到的稳定性优化思路一致。实测中如果直接执行四次减法可能在某些内核实现下产生短暂的非流形中间态而预合并策略只在底座上执行一次减法整个实体在连续操作中始终保持在有效流形状态。构造结束后Properk 校验器检查流形性、尺寸合理性、制造可行性。检查结果全部通过。板厚 8 毫米、孔径 10、孔边距 10完全满足常规制造要求。凸台高度 5 与底板融合后形成一处 5 毫米抬升台不存在脱模风险。校验通过后writeCrest 将 Brep 实体导出为 STEP 文件并同时生成一份包含关键尺寸标注的 PDF 预览图纸。至此一条完整的 text-to-cad 流程结束从输入到产出只需数秒时间。5.4 失败案例分析一次被 RoadBus 成功拦截的错误为了展示这些层的价值我故意构造一个会导致问题的输入“把底板左下角削去一个圆角半径 30。”如果系统机械执行左下角半径 30 的圆角会把 100x60 底板削掉一大部分导致剩余结构严重残缺明显不是用户原意。RoadBus 的位置关系规则检测到圆角半径 30 与板宽 60 相比占比过高超过 40%而且圆角中心位于角点附近会大量破坏底板原始边界。规则判断该操作会导致拓扑异常概率较高于是将其标记为需要用户确认并附带解释“该圆角半径可能导致底板结构残缺是否继续”这个拦截让无效生成避免在源头而不是等到用户拿到模型后才发现问题。这种预判逻辑其实非常朴素但价值很大。很多项目缺少这一层直接把所有输入都交给内核执行最终产出质量完全碰运气。如果你在这个阶段遇到拟合不足的情况优先扩充 RoadBus 规则库而不是调整语言模型。规则库的增长对系统稳定性的贡献往往最为直接。6. 还没解决的难题与下一阶段的迭代方向DataPlanner 目前已经稳定运行但离我理想的“顺畅自然语言建模”还差不少距离。这一章我不讲已经实现的内容而是把当前遇到的真实困难整理出来给同行一个参考。我始终认为坦率地讲未解决问题的价值不亚于分享成功方案。尤其在这个方向踩坑经历往往是最有价值的信息。6.1 多实体空间关系的表达歧义这是目前失败案例的集中来源。当用户说“A 放在 B 的左边”时“左边”可能指 B 的中心左侧、边缘左侧、或者观察者视角的左侧。即使借助对话交互也未必能完全消除歧义。人类的语言表达天然依赖上下文而上下文经常只存在于用户脑中。我目前的策略是把这类歧义统一转成确认问题“是否指 A 的中心对齐 B 的左侧边缘”这虽然降低了歧义但也带来了交互成本的提高。接下来我打算引入一个轻量的空间关系常识图谱统计不同行业用户对同一短语最常接受的空间映射按场景预判语义。但说实话这个方向很难有一步到位的解法。它本质上是个语言与几何的交叉问题需要长期积累空间语境数据。我也在考虑是否通过让用户上传参考图来解决不过这会引入视觉模型整体系统的复杂度一下子会高很多。6.2 复杂轮廓线的自动生成与可控性目前拉伸轮廓体只支持由直线和圆弧组合成的轮廓也就是在二维平面上定义截面然后拉伸这对很多钣金类和外观类零件是够用的但遇到自由曲面外壳就完全无能为力了。若想支持样条曲线轮廓就面对智能化平滑和用户意图可控之间的冲突因为曲线的控制点一旦多机器生成的结果往往与用户心理预期差异巨大。我当前想到的改进路径是把曲线生成分割成若干段让用户逐段确认控制点而不是一次性生成完整曲线。但这个交互方案还没经过用户测试不确定是否真的讨喜。也有可能最终解决方案是提供两套模式快速模式和精细模式。快速模式由系统自动拟合大概够用精细模式则让用户手动拖拽控制点系统只提供约束辅助。这套方案动静比较大短期内未必能做出来。6.3 生成结果的可编辑性问题目前生成的是静态实体如果在 CAD 软件里打开后想修改某一个参数比如把孔径从 10 改成 12用户必须重新生成整个模型而不是像原生参数化建模那样直接改尺寸标注。这个体验等于倒退回了二十年前的建模软件水平。严格来说这不算错误因为系统并不保留构造历史树。但只要想支持参数化回传就必须要求 aCross 输出的每个实体都带完整的参数依赖关系并在前端提供参数面板。这改造成本不小但在长期规划中绝对是必须迈过的一道坎。在没有找到更好方案之前我的临时做法是让 STEP 文件的导出附带一个参数说明 JSON 文件用户二次开发时可以读取文件里的参数并重新调用系统生成。这个方案能用只是略显笨拙。6.4 与主流 CAD 生态的对接深度text-to-cad 的价值不完全在于生成一个孤立文件更在于如何嵌入到设计师已有的工作流里。我测试过将生成结果导入多款商业化 CAD 工具单纯导入基本没问题。但想要实现“生成后原地编辑”的深度集成就必须依赖各个 CAD 厂商提供的 API。这部分工作既繁琐又没有统一的跨平台接口目前只能按厂商逐个适配。我计划优先适配用户量最大的三款工具之后再考虑长尾。如果你自己做这块建议不要一上来就贪多选一个能专注调优的场景切入效率会高得多。坦白讲这条路径的市场价值巨大但工程复杂度也不是一个开源仓库能完全承载的。它更像一个持续演进的生态型工作非常考验长期投入的耐心。7. 在推进 text-to-cad 项目时的经验教训总结前面已经把设计思路和技术路径完整讲完最后我想分享几条贯穿全程的实践经验。这些经验不是针对某个技术细节而是对整个项目推进方向的判断与取舍。这些经验来之不易很多都是推到重来后才真正理解的。如果你正在做或者打算做类似项目建议认真琢磨一下也许能少走不少弯路。7.1 边界清晰的模块胜过昙花一现的巧妙技巧在整个开发过程中我经常看到有人沉迷于某个特别聪明的算法设计比如用强化学习优化文本到实体映射或者设计一个华丽的注意力机制。这些技巧在论文里很精彩但到了真实场景往往很难稳定复现。我建议把主要精力放在模块边界的划分上。一个边界清晰的系统可以有多个不完美的模块但每个模块对工程团队而言都可理解、可修改、可测试整体组合起来往往性能稳定。DataPlanner 里语言模型服务、RoadBus、aCross、Properk 各自独立任何一个模块升级都不会影响其他模块这种结构带来的长期开发效率提升是巨大的。反过来如果一个系统很出色但模块之间耦合严重当出现一个 bug 时排查成本会高到团队无法承受。这是我多次重构后最真切的心得。7.2 测试集就是系统敢不敢改动的底气如果你问我 DataPlanner 里哪个资产最值钱我的答案不是某个算法而是那套积累了 500 多个样本的基准测试集。有了它每次改动算法后我都能立刻知道效果变好还是变差不再依赖“感觉”。建立测试集的核心原则是覆盖所有已知失败场景并持续添加新出现的问题场景。每当你修好一个 bug都需要把它固化成测试样本防止后续重构改回去。这个循环虽然枯燥但能积累出业内很难被超越的护城河。没有测试集的系统就像一个不敢变动的定时炸弹。项目运行越久代码越乱最后到了谁也不知道改了哪里会引发什么问题的阶段。这个教训极其深刻希望你能尽早重视。7.3 从文本到 CAD 的未来属于整套工具链而非单一魔法模型回看整个 text-to-cad 发展路径我会明确指出完整解决方案属于整套工具链而非某一个单一魔法模型。语言模型负责语言理解几何内核负责构造校验器负责兜底交互系统负责澄清歧义。它们组合起来产生的价值才是单靠今天任何模型都无法替代的。那些把工具链做成产品的人会获得持续的迭代优势。因为语言模型每年都在变强但你服务的用户需求和几何校验规则是能沉淀复用的。复用的越多生态壁垒越厚。我自己还在持续迭代这套 DataPlanner重点放在空间歧义消解和参数化回传两个方向。后面有实质性进展时我会再回来分享。如果你也在做相关项目欢迎基于这篇文章的思路做你需要的实现和优化毕竟每个人的需求场景都不完全一样。