企业官网建设流程全解析

还没到2024年底，text-to-cad这个概念就从技术demo圈子里慢慢渗到了普通CAD用户的桌面。我是在一次给甲方做方案汇报的时候第一次被问到：“能不能给我个工具，我拿一句话就让CAD把图画好？”当时我只能笑笑，但自己心里清楚，这个方向确实已经到了一只脚迈进球场的阶段。

从2023年年底开始，我一直在一个不太起眼的角落里反复测试这类能力——用自然语言描述需求，让程序生成可编辑的CAD图纸或脚本。前前后后试过开源项目、商业插件的测试分支、也自己用Python搭过几条流水线。这篇文章不聊那些复杂的大模型理论，就从一个用过十几年CAD的老用户视角，把text-to-cad到底能做到什么、应该怎么用、哪里还指望不上，一条条讲清楚。

第1章 为什么是现在：text-to-cad从概念走向可用的背后变化

text-to-cad并不是新凭空蹦出来的概念。早在十几年前的参数化设计软件里，就有了“输入参数生成模型”的能力；AutoCAD的块定义、属性提取、动作录制器，本质上也是让人先把需求浓缩成参数，再让软件按图索骥。区别在于，过去这活儿的瓶颈是“人翻译需求”的过程——要把一句人话变成一长串坐标、约束、图层设置，这个翻译动作本身就是最大的成本。而text-to-cad要解决的，正是把这一层翻译从人的脑子里转移到机器推理里。

这几年真正推动它进入实用视野的，是两个条件的巧合。

第一个是自然语言理解能力的跃升。现在的语言模型已经可以比较稳定地把一句口语描述拆解成结构化的参数表，比如提取尺寸、数量、位置关系、材质要求，哪怕你说话不严谨、把毫米和厘米混着说，它也能在上下文里猜出真实意图。这在过去的规则引擎时代几乎做不到，因为规则引擎只能识别严格格式，而人说话天生是模糊、省略、跳跃的。

第二个是CAD生态的开放程度足够了。dwg格式虽然闭源，但经过这么多年各种开源库的反向工程，Python环境下已经能比较可靠地读写dxf、dwg里的图层、块、多段线、标注这些基础结构。再说得直白一点：现在让程序生成一张带图层的CAD图纸，已经不是技术门槛，而是工程习惯问题。

我自己的验证项目大概是从2024年年中开始的，用Python的dxf库搭了一条很简陋的文本转CAD流水线。当时输入的一句话是“矩形墩身，宽1.2米，高15米，混凝土等级C40，承台厚2米，带4根直径25毫米主筋”。结果能生成一个初步的几何线框和简单的钢筋示意图层。虽然离施工图差得远，但整个过程只用了三分钟，其中一半时间花在改提示词上。我当时给朋友发消息说：这玩意儿距离生产力工具，还差图层规范、标注样式、出图比例这几个大坑，但从“演示动画”到“能用原型”这一步，已经跨过去了。

第2章 一句话到一张图：text-to-cad的核心链路拆解

如果你想真正理解这类工具为什么有时候聪明得吓人、有时候又蠢得离谱，就得先看它内部的这几步处理流程。我自己搭流水线的时候，把整个链路拆成了四段，每一段都有各自容易出问题的地方。

2.1 意图解析：把口语揉碎成参数表

这是最关键的一步，也最容易被低估。你输入的“门洞宽1米8，高2米4”和“1800x2400”本质上是一个意思，但机器要经过单位归一化、数值抽取、实体识别才能处理。更麻烦的是这句话“左边留一扇固定扇，右边是活动扇，装上闭门器”里的“左右”“活动”“固定”这些词，都是需要联系工程常识才能理解的。

我这里给出的建议是，无论你用什么工具，写提示词时尽量比日常跟同事交代更严谨一点：先说“画什么”，说清楚是平面图还是立面图还是三维体量；再说尺寸，统一单位；最后说图层和命名要求。我发现，只要提示词里把“图层叫XX”“单位用毫米”“图块命名DK-01”这些约束说在前面，生成结果的可编辑性会高很多。

2.2 参数映射：从尺寸数字到CAD对象的转换

参数表拿到之后，接下来就是把它映射成CAD里真正存在的对象。这一步有很多“约定俗成”的规则，比如在平面图里，墙体要用双线或band，窗口要有开启线，门的弧线要说明开启方向，剪力墙还要在平面图里画填充图例。这些规则不在语言模型的知识范围之外，但它写出来的代码或者dxf实体，并不总能正好符合你单位的图例标准。

我自己在测试中最常用的做法是：让生成逻辑固定对接一套自定义模板。比如图纸里所有门窗都必须走自己定义的块定义（Block），所有文字标注都必须落在这套模板指定的图层上。这样生成结果虽然灵活度降低，但至少保证每个图元都能被后续编辑识别。如果你就直接拿通用模型去“自由发挥”，那出来的图十有八九图层混乱、标注字体找不到、图块全是散线，比手画还难收拾。

2.3 几何生成：坐标系与对正逻辑的处理

几何生成环节最烦人的不是复杂曲面，而是最基础的“对正”。例如“门的中心线和墙的中心线重合”这句话，机器得先找到墙中线，再把门块插入到对应位置，还得考虑门的开启方向朝里还是朝外，是平开还是推拉。一个不了解施工图常识的模型很容易生成一个看起来合理、但插入点偏离墙体50毫米的门。

在我自己的脚本流程里，解决方式是写死一套“锚点定义”：每个图块生成前，先要求模型输出它的插入基准点相对于构件自身的位置关系，然后再把基准点对齐到墙轴线或柱心。这个方法虽然老土，但很大程度上规避了“看起来对，量下来全歪”的情况。

2.4 校验回归：几何合法性过滤

这是我自己认为最不能省的一步。无论模型的语言能力多强，几何合法性都得靠软件来兜底。我在测试里专门写了一个简单的校验器，检查生成结果里有没有零长度线段、面积负值自相交多边形、超出边界的坐标。别小看这层检查，它帮我拦下了非常多肉眼第一眼根本看不出的问题。

打个比方，你用生成工具画一个房间平面图，模型可能把所有墙体画完了，但某个墙角的过度修剪让两段墙之间实际上没有闭合，最后这个房间的面积怎么都算不对。这正是text-to-cad现在最容易埋雷的地方——它生成的图看起来完整，但几何层面未必闭合、连续、满足拓扑关系。这种隐患，做设计的人第一眼通常看不出来，等算面积或者做碰撞检查时才暴露。

第3章 我实际测试过的工具与方案：真实水平与选型边界

要说清楚现在的落地水平，光讲原理不够。我从去年到现在，陆续接触过三类不同的实现路线，每类都有自己的优势和明显的边界。

先说说第一类。通用语言模型配合dxf库的组合，灵活性最高，你可以让它生成批量修改脚本、按参数绘图的函数、甚至自动整理图层。但代价是，你需要能读懂它写出来的Python代码，出错了还要会调试。对普通绘图员来说，这个门槛不低。我在测试里经常遇到的是它以为自己写对了，结果dxf库里的某个函数参数格式不对，跑起来报错，然后得把报错信息再喂回给模型，让它自己改，来来回回三五轮很正常。

第二类是商业软件里的嵌入式人工智能。这类最适合普通CAD用户，因为它把往返对话包装成了更像“命令”的形式。你不用看代码，只需要输入一句话，它把这句话解析成活断的CAD命令组合。但问题也很明显——它对需求的理解还是偏向模板化，比如你问“把门改成子母门”，它能识别关键词；可要让它理解“楼电梯前室的门需要甲级防火门且向疏散方向开启”，这种带专业规范约束的需求，它的回应就要看运气了。

第三类垂直插件，实用性反而是我目前最推荐的。它不是让人工智能去理解一切，而是把人工智能限制在很小的专业领域里。比如做地形处理的时候，你输入“把这块范围里的等高线按间距0.5米重新生成”，这类插件能真正做得比通用方案好，因为它的数据结构和行业画法都是预先定义好的。一旦输入超出了它被圈定的专业范围，它的表现就迅速退化，甚至会给出完全不合常识的输出。

所以你看，选型的核心不是问“哪个更智能”，而是想清楚“我让它处理的需求边界在哪里”。

第4章 把text-to-cad接进真实工作流：三个典型场景的落地方案

工具最终是拿来用的。我在测试过程中慢慢形成了一套自己的使用思路，核心就一句：不要把text-to-cad当画图超人，而是把它当调度员和批量操作员。也就是说，让它帮你解析需求、生成脚本、处理重复劳动，而不是让它一口气帮你出整张大图。下面几个场景是我实际验证过、普通CAD用户也可以参考的。

4.1 场景一：图纸合并与图层规整

很多单位现在还在靠人工处理图纸合并，把几个分包提资的文件攒到一张底图里，再逐个图层整理。这类活儿重复性强、规则明确、说不上多难但极度耗时。我试过一种做法：把合并要求和来源文件清单用自然语言描述给模型，让它生成一个处理脚本，自动打开源文件、按预设顺序插入到目标图纸、把同名图层合并、清理掉多余的空白图层。

这个做法跑通之后，效果非常明显。以前一个标准层几十张提资图合并整理，熟练的绘图员也得忙小半天，现在脚本跑一批图纸，过程基本不需要人看，最后只需人工复核一遍图层对不对。当然，脚本第一次运行前总要经历几轮调试，但一旦把调试模板固定下来，后续每次合并新图，只需要更新文件路径和层名对照表，效率提升是实打实的。

4.2 场景二：面对地形图切地形的辅助处理

做市政或总图的人应该熟悉“切地形”这三个字——拿到原始地形图，按道路中心线或建筑范围切出需要的断面或局部平面。这个操作在CAD里面对大量等高线、高程点数据时特别烦人，因为数据量大、视觉上又不容易看清。

我试过用自然语言描述“沿着这条路线每隔20米切一个横断面，范围两侧各30米，保留原始高程点”，让模型去配合相关的垂距处理逻辑。它能生成一个操作序列，自动计算剖切位置、框选数据、生成断面雏形。我必须坦白，这类处理里原始软件的示坡线方向、等高线内插密度、异常高程点这些东西，模型的判断依然需要人工抽检。但有一点是确定的：它把最机械的“拾取、选择、偏移”动作从人身上剥离了，你只需要审查它拾取得对不对。

4.3 场景三：Layout出图与视口布置

网上关于CAD导入layout步骤的提问一直居高不下，就是因为模型空间画图、布局空间出图这个操作，对新手来说有点绕，对老手来说则是重复劳动。text-to-cad在这个领域有一个很实际的应用思路：你用文字描述图框规格、视口比例、图纸编号和说明栏内容，它生成一段脚本来自动创建布局、放好视口、锁定比例、填好图号。

我自己试过的效果是，常规的矩形视口和标准图框，生成结果相当稳定。但碰到异形视口、需要裁剪轮廓的图纸，或者图纸编号要按工程逻辑自动生成的情况下，还是得先跑一遍，看看哪些逻辑需要手调。这类应用的优点很明确——它等于把“画图规则”变成了一种可复用的描述语言，今天告诉它怎么布置，下次它就能按同一套规则帮你批量执行。

第5章 用text-to-cad跑了三个月之后，我遇到的真实问题和解决思路

光说好的不算负责任，我把实际使用中踩过的坑和对应的解决办法，按类别整理出来，给准备入手的同行一个参照。

5.1 单位混用与比例失控

这是出现频率最高的问题。CAD文件里最常见的是毫米制，但老图纸和仿照国外标准绘制的文件里可能藏着英寸、厘米、甚至以1:100出图为前提的注释性缩放。语言模型对单位的理解并不总是和图纸实际情况一致。比如我输入“门洞宽1米8”，它生成一个1800mm宽的门，思路没问题；但我如果输入“门洞宽1.8”，没有加单位，它就可能按1.8mm生成一个根本画不出来的小点。

解决这个问题，我现在的做法很粗暴——在提示词模板的开头固定写一句“以下所有尺寸均以毫米为单位，输出前先转换为毫米数值”，并且在生成逻辑里加一层单位校验，任何图元尺寸小于10毫米时自动标记为可疑对象。这套办法不能解决所有问题，但把最影响观感的比例错误拦截住了。

5.2 图层体系和字体样式的混乱

这是目前最让CAD老手头疼的一点。大模型生成的图纸，图层名字经常是它臆想出来的，什么“Layer 1”“墙-WALL”“defpoints”，和公司的图层标准完全不搭。导入到正式项目里，轻则看着乱，重则影响后续的图纸归档和提资。

我的应对思路是：把公司图层标准做成一个独立的模板文件，让生成脚本始终从这个标准模板出发，而不是裸建文件。如果模型生成了新图层，脚本会强制把它映射到标准图层表中，或者干脆合并进默认图层。文字方面，我会预先指定字体文件使用工程汉字字体，避免生成结果落到系统默认字体上导致打开时文字变成问号。

5.3 看起来正确的幻觉对象

这一条我必须重点强调。text-to-cad有一个非常危险的表现：生成的结果在视觉上完美，但逻辑上完全不对。我遇到过一个最典型的例子，让它生成一个L形楼梯剖面，它输出的图形像模像样，梯段、平台、扶手都在，但仔细量尺寸时发现，相邻梯段的高度差算错了，踏面宽度也违反了规范。

这类问题之所以危险，是因为人眼会被合理的视觉外观欺骗，而几何数值上的错误需要专门去核查才能发现。所以我后来的习惯是，让任何AI生成的图纸在进入正式流程前，必须强制过一遍参数校验清单，包括最小净高、楼梯踏高踏宽比、门窗洞口离地高度这些核心数值。校验清单不复杂，但能拦住大部分“看起来不错”的脑补结果。

5.4 可编辑性不足

老CAD用户最在意的一件事，是生成的图能不能改。我遇到过不少生成结果，所有线条全是炸开的散线段，没有块结构，没有属性，改一处门的位置得手动挪十几根线。这说明生成模型的图块意识还不够强。

我的建议是，在提示词阶段就要固化和图块相关的约束，比如“所有门洞使用预定义的块DK01，插入点和开启角度由参数控制”。如果你用的工具支持自定义模板，尽量提前把标准块定义塞进模板里，让生成结果引用而不是重画。可编辑性这一关不过，再快的生成速度都没有实际意义。

第6章 给不同角色的实操建议：如何把text-to-cad用出真正的效率

最后这部分，我想分角色聊一聊，毕竟CAD用户群体跨度很大，从刚入门的制图初学者到背了一堆项目经验的工程师，用这个技术的方式应该完全不一样。

6.1 给CAD制图初学入门者：先拿它当辅助，别拿它当老师

如果你是刚接触CAD的新手，我反而建议不要第一时间依赖text-to-cad。原因很简单，它生成的东西偶尔是错的，而你还不具备判断对错的能力。新手学CAD，头几个月应该先把线、图层、标注、块、布局这一套基本功用传统方式练扎实，等你能一眼看出哪根线不该出现在那个图层的时候，再开始尝试用文本生成工具。

届时你的角色从“操作者”变成了“审查者”，这才是适合你的姿势。你可以让文本生成工具帮你搭好初步框架，然后自己一句一句地对图、校正、完善。这个过程里你学到的东西，比纯手画一遍还要多，因为你是在带着挑剔的眼光看一张错的图，这比闷头画正确图更能锻炼识图能力。

6.2 给一线设计绘图人员：把重复劳动拆解成“描述+审查”

对于平时已经在大批量画图的设计者，最实际的做法是把工作拆分。凡是重复度高、规则明确、结果可验证的任务，比如批量建块、图层清理、相同构件布置、图框填充，都值得尝试交给text-to-cad去生成脚本或命令序列。你的重点放在两件事上：一是把需求描述得足够准确，二是对生成的最终结果做抽样复核。

我自己常用的模板是：“任务背景+处理范围+具体规则+图层输出要求+核查项”。比如要批量给多张图纸加图框，我会写：“把当前目录下所有DWG文件在模型空间插入A2标准图框，图框左下角对齐原点，图号从图1-01开始递增，每个文件生成后自动保存备份。”这样一个描述，配合调试好的脚本，能省掉我一下午的重复操作。

6.3 给天天和地形、市政打交道的朋友：先解决数据预处理

做地形处理、切地形、道路断面这一块的同行，我对你们的建议比较具体：别一上来就指望它自动完成切地形。先把原始数据的清洗、坐标转换、建TIN、等高线检查这些前处理环节，用文本生成脚本自动化掉。数据干净了，切出来的地形自然就准；数据没洗好，后面任何分析都是白搭。text-to-cad可以帮你节省大量前处理时间，但它目前还做不到替代你对地形数据的专业判断。

另外一个我在市政项目里的体会是：这种工具需求量最大的不是“生成地形”，而是“生成地形处理过程中的中间文件”。生成辅助线、生成剖切位置标记、生成土方计算范围框，这些不起眼的中间步骤恰恰是它做得又快又好的，因为它不需要理解复杂工程语义，只需要按规则画出来。

6.4 给大家庭里管软件安装和维护的半个IT

最后做个补充。很多CAD使用者都会被软件安装、激活、重装这类基础问题卡住。虽然这不直接属于text-to-cad的范畴，但这个技术也能帮上忙——它可以通过对CAD卸载残留、环境变量、依赖运行库这些问题的语义理解，生成一份针对性的排查脚本清单，甚至自动生成一个检查计算机环境的批处理命令。比起满网络找安装教程，直接把你电脑的情况描述出来，让AI生成针对性的建议方案，往往解决得更快。

我自己在处理CAD反复安装失败的时候，就试过用类似思路：描述错误提示、系统版本、之前卸载过的软件，让工具生成一份检查清册，逐项排查注册表残留和启动项冲突，效率确实比毫无头绪地翻帖子高。

第7章 我目前的使用习惯与最后想说的话

现在我的工作流里，text-to-cad已经是一个固定角色，但它的定位很明确——辅助，不是替代。凡是需要创造性的方案设计、需要工程经验判断的地方，我都自己动手；凡是批量、重复、规则清晰的操作，我会尽量用自然语言描述给工具，让它生成脚本、生成图块、生成图层处理方案。我用它最频繁的场景，反而是那些不起眼的地方：批量改名、图层映射、图框套用、视图布置。这些活儿以前看着容易，但一旦图纸量大起来就是纯纯的体力消耗。

我也见到过一些把text-to-cad捧到“输入一句话就出整套施工图”位置的讨论，说实话这种期待除了给自己添堵没有别的好处。以当前的水平，它能稳定解决的大多是规则明确、边界清晰、结果可验证的任务；但凡涉及到规范强条、多专业协调、异形空间处理，人工判断依然不可替代。

如果你打算开始接触这个方向，我的建议是从小处入手：先找一个你工作中最简单、最标准的重复动作，试着用自然语言描述它，让工具生成脚本或命令序列，跑通了再慢慢扩大范围。别一开始就想着“全员AI出图”，那样你大概率只会得到一个需要大量返工的数字垃圾场。

这几个月用下来，我最深的体会不是“AI有多能干”，而是“把需求讲清楚”这件事本身比想象中难。很多次工具生成结果不理想，回头看我自己的描述，才发现是我把约束条件漏了，或者把尺寸说含糊了。text-to-cad推着每个用CAD的人养成了一个新的职业习惯——开口说话之前，先想明白自己要的到底是什么。光是这一点，就值得目前在犹豫的同行们都去试一试。