“这个槽改一下尺寸能不能直接出一段程序”这句话我在车间里隔三差五就能听到。围绕“自然语言指令 → CNC 可执行 G 代码”这件事圈里最近有个说法叫 GLLM本质就是 G 代码和大语言模型的融合路径。非标件、工装、夹具、样品试制图纸一天改三版每次都要从头建模、选刀路、设参数、后处理开 CAM 软件的功夫比真正干活还长。大语言模型火起来之后我试着把这条链路搬到数控编程里让师傅直接用自然语言说清楚加工要求模型翻译成机床能跑的 G 代码。这篇文章把我从零搭这套工作流的完整过程写下来包括链路设计、提示词工程、模型选型、程序校验以及我踩过的几个真坑给想在机加工环境里引入 AI 辅助编程的朋友做参考。1. 为什么 CNC 编程值得走“自然语言直出 G 代码”这条路1.1 传统流程的尴尬改一个尺寸重跑一遍软件传统 G 代码程序怎么来的大多数情况是走一遍完整链路拿图纸、建三维模型、用 CAM 软件选刀路、设置切削参数、后处理成机床能识别的代码再传到设备上。这套流程对批量产品和复杂型腔没毛病但对多品种、小批量的活儿非常磨人。我碰到过不少老师傅操机水平很高一看图纸就知道怎么干可 CAM 软件点起来就是不如年轻人快。反过来年轻工艺员软件熟但切削参数吃不准出的程序还要现场反复试。最难受的是改版一个孔从直径 8 改成 10或者槽的深度从 5 变成 6看着就是改一个数字实际上模型要更新、刀路要重新生成、后处理再跑一遍。软件打开关关小半天就没了。这类场景里真正消耗精力的反而不是“加工”而是“把需求翻译成程序”的重复劳动。对二维轮廓、点位加工、简单铣削这类任务翻译过程高度规则化本质上就是结构化表达天然适合用语言模型来做初稿生成。你不需要它替代 CAM只需要它把重复翻译的环节抽掉。1.2 LLM 在文本转代码上的迁移能力被低估了很多人一听“让大模型写 G 代码”第一反应是“这东西也能写数控程序”其实 G 代码是一门非常“小”的语言。指令集就那么几十个G00 快速定位、G01 直线插补、G02/G03 圆弧插补、G90/G91 绝对/增量坐标、G40/G41/G42 刀具补偿、G43 长度补偿、M03/M05 主轴启停、M06 换刀、M30 程序结束。语法规律极强自由发挥空间远小于 Python 或 C。而大语言模型最擅长的恰好就是把一段受约束的自然语言转化成结构化代码这在软件行业已经被验证过无数次。对 G 代码来说它更像“翻译”而不是“复杂推理”。只要你把机床参数、刀具信息、编程习惯作为上下文喂给它它的输出质量会非常接近老工艺员的手写水平。但边界必须划清楚三维曲面刀路、五轴联动、干涉检查这类需要几何计算和布尔运算的工作LLM 做不好也不该让它做。它不是 CAD不会算真正的最优刀轨。你可以把它理解成一个听得懂工艺要求的熟练文员能帮你把需求整理成工序草稿但复杂曲面怎么摆刀路还是得交给专业 CAM。1.3 这条路径解决的真实痛点这几年我接触到的真实需求高度集中样品打样、非标工装、设备改造、实验件加工。这些场景的共同点是“数量少、改得快、等不起”。批量产线反而不太需要这套程序早就固化在工艺库里了。一台加工中心旁边如果有几位师傅能对着屏幕说一句“铣一个 100×50×6 的矩形槽中心在 X50、Y-25”几分钟内拿到初版程序再由有经验的工艺员审核修正整个节拍会快非常多。适合用 GLLM 的人群也很清晰个体加工户、小批量工厂的工艺员、实验室设备用户、做柔性制造的研发团队。不适合的场景同样清楚大批量生产、高精密复杂曲面、需要严格过程追溯的航空医疗零件这种地方宁可继续用传统CAM也不要拿模型去赌安全性。2. 从一句话到一段 G 代码GLLM 链路的关键节点拆解2.1 整体链路指令解析 → 翻译生成 → 规则校验 → 仿真验证 → 上机我把整个 GLLM 工作流拆成五段流水线每一段负责一件明确的事。第一段是指令解析。用户说的“铣一个 100×50×6 的矩形槽”是一句自然语言系统要把它拆成几何尺寸、材料、刀具号、粗精加工要求这些结构化信息。第二段是翻译生成大模型根据解析结果生成初版 G 代码草稿这段输出不一定能直接用但已经能看出工艺思路。第三段是规则校验用脚本检查语法、坐标超程、补偿指令是否缺失、有没有危险参数。第四段是仿真验证把程序放进数控仿真环境看刀路轨迹是否碰撞、是否过切。第五段才是上机试切先空运行、再单段执行、降速试切、首件测量。这五段里技术难度最大的不是模型生成而是最后两段。很多刚开始尝试 GLLM 的人看到模型输出了一段格式工整的 G 代码就兴奋直接传进机床开跑这是大忌。翻译得再漂亮代码也可能在 Y300 的位置超了行程或者补偿方向反了导致过切一整刀。必须记住一件事语法正确 ≠ 轨迹正确 ≠ 工艺正确三个正确全部达成程序才算真的能用。2.2 输入侧把机床、刀具、材料参数先固定下来让模型生成 G 代码最忌讳每次把参数临时说一遍。你想想如果上下文里没有机床行程和转速上限模型只能按“最通用甚至最理想”的参数生成坐标可能跑到 Y600转速可能写到 12000。那在你这台设备上根本没法跑。我的做法是在对话开始时固定一张“环境卡片”把设备参数一次性写进去。下面是一个可以参考的示例[设备与编程约定] 机床三轴立式加工中心 坐标模式G90 绝对坐标 单位G21毫米 工件坐标系G54 行程范围X 0~500Y -300~300Z -250~0 主轴转速上限10000 rpm 进给速度范围F 10~3000 mm/min 刀具表T1 直径10mm平底刀、T2 直径6mm球头刀、T3 直径3mm中心钻、T4 M8丝锥 切削液开启 补偿方式刀具半径补偿G41/G42长度补偿G43/Hxx这张环境卡片就是模型的“上下文约束”。没有它模型对设备一无所知只会写出“通用代码”。有了它生成结果才能贴合实际设备。不管用本地模型还是云端接口这一段都建议固化成模板每次新会话直接套用。2.3 输出侧约定程序三段式结构光约束输入还不够输出也得有规矩。G 代码有个特点模态指令会延续。比如 G01 一旦生效后面每行只要不写新指令默认还是直线插补G90/G91 一旦切换后面所有坐标含义都会变。这种延续性给人眼检查带来了不小的麻烦所以必须让模型按固定结构输出。我要求所有生成结果都分成三段程序头、加工段、程序尾。程序头负责初始化包括 G90/G21/G54/G17/G40/G49/G80换刀、长度补偿、主轴启动。加工段负责定位、下刀、切削、抬刀按工序顺序分段注释。程序尾负责取消补偿、主轴停止、冷却关闭、M30 程序结束。定义一个标准模板效果很直接即使模型某段生成有误人眼扫一遍就能快速定位脚本做规范检查时也能更准确判断结构是否完整。对 LLM 来说有结构的输出比自由发挥可靠得多这个习惯值得从第一天就养成。3. 让模型说机床上能跑的“专业话”提示模板与示例库设计3.1 角色设定与规则注入如果直接问大模型“帮我写个铣槽程序”它大概率会给你一段教科书式的示范代码格式没问题但完全不贴设备。想让模型说出机床上真正能跑的“专业话”角色设定和规则注入必不可少。这是我目前用得比较顺手的提示模板[系统角色] 你是一位有二十年数控加工经验的工艺工程师只输出标准G代码不要解释过程不要闲聊。 [任务] 根据用户输入生成一段可执行的G代码。 [规则] 1. 使用绝对坐标G90单位G21工件坐标系G54 2. 程序头必须包含G17、G40、G49、G80 3. 换刀时使用Txx M06并配合G43 Hxx做长度补偿 4. 进给速度F的单位为mm/min转速S为rpm 5. 所有结果用“程序头 / 加工段 / 程序尾”三段式输出 6. 坐标数值保留到小数点后三位 7. 禁止使用未定义的G指令禁止在行程范围外生成坐标 8. 涉及刀具半径补偿时必须说明用的是G41还是G42。规则不是写得越多越好关键是规则本身要能被机械检查。比如第 7 条“禁止超程”模型不一定每次都能严格兑现所以后面还要靠脚本兜底。但把规则写清楚至少能把“自由发挥”压到最低。实际测试下来有了这套约束输出质量明显比裸写提升一截。3.2 Few-shot 示例库让模型看到“正确长什么样”只给规则还不够因为模型读过互联网上海量的 G 代码但那些代码格式五花八门有教材示例、有比赛题目、有论坛帖子风格完全不统一。最有效的方式是在提示词里塞入一两个“你自己验证过”的短程序作为 few-shot 示例。模型会模仿你给的结构、注释风格、程序头尾而不是套用它在网上见过的混沌样本。比如我给点孔和铣方各准备了一个精简示例对话时先甩给模型“仿照下面这段程序的风格来写。”效果立竿见影尤其对参数量较小的本地模型few-shot 比空口提要求管用得多。这里有个注意点示例库里不要放太复杂的五轴联动或宏程序。模型复刻不了复杂逻辑反而会把无关的语句和奇葩的坐标变换也抄进去。示例应该挑“逻辑简单、格式规范、你已经验证能跑”的典型程序。如果你有一批历史工艺库挑 20 个典型程序做一次低秩微调效果会更好但这属于进阶操作。3.3 模型选型与部署选择聊到模型选型我做了个对比表格方便大家根据场景判断对比项本地开源权重模型云端大模型API数据保密数据不出内网适合图纸保密要求高的场景需要把程序文本发给外部接口存在合规风险部署成本需准备显卡和推理服务初期投入较高按调用次数计费起步几乎为零响应延迟受本地硬件影响通常是秒级取决于网络一般也可接受定制能力可以微调深度适配自家工艺规范只能通过提示词和少样本控制适合场景工厂内部工具、批量生成、频繁迭代技术验证、Demo、低频个人使用如果只是个人试试水用云端 API 无疑最快。如果准备做成团队工具我会强烈建议上本地部署加微调。工艺数据这东西尤其是零件图纸和加工程序很多工厂不希望它离开内网。我记得有一次给某个做设备改造的小团队搭方案他们最大的顾虑不是模型效果而是“程序传到外部接口后客户图纸算谁的”最后就定了本地模型路线。不管选哪种我都建议在后端保留一个独立规则引擎做前置校验不要把模型输出当最终结论。模型提供的是翻译能力规则引擎提供的是安全兜底两者配合才能放心。4. 比生成更重要的环节程序校验、轨迹仿真与安全底线4.1 一个可落地的校验脚本语法、坐标超程、代码规范性我必须说一句大实话大模型输出的代码本质上是“概率性的文本草稿”不是经过编译器验证的程序。它能写得像 G 代码但不代表每一行都合法、安全。我自己的习惯是先写一个脚本把文本过一遍再做轨迹仿真最后才空运行。脚本不一定多复杂关键是能拦住低级错误。下面是我早年写的一个简化版校验脚本思路可以迁到自己的环境里import re def load_gcode(path): with open(path, r, encodingutf-8) as f: return f.readlines() def parse_codes(lines): codes [] for idx, raw in enumerate(lines, 1): text raw.split(()[0].strip() # 去掉括号注释 for m in re.finditer(r([A-Z])(-?\d\.?\d*), text): codes.append((idx, m.group(1), float(m.group(2)))) return codes def check_bounds(codes, limits): problems [] for line_no, code, val in codes: if code in (X, Y, Z, I, J, K): lo, hi limits[code] if not (lo val hi): problems.append(f第{line_no}行: {code}{val} 超出范围 [{lo}, {hi}]) return problems def check_mandatory(text, required): missing [] for kw in required: if kw not in .join(text): missing.append(kw) return missing if __name__ __main__: lines load_gcode(demo.nc) codes parse_codes(lines) limits {X: (0, 500), Y: (-300, 300), Z: (-250, 0), I: (-50, 50), J: (-50, 50), K: (-50, 50)} print(check_bounds(codes, limits)) print(check_mandatory(lines, [G90, G54, M30]))这段脚本虽然只用了正则表达式不解析模态逻辑但对超程、缺 M30 这类低级问题非常有效。真正严谨的做法是把 G 代码解析成模态状态机检查 G01/G02/G03 是否处于合法状态刀具补偿有没有在程序尾取消这些都可以在做内部工具时逐步加上。实用主义地说先把最危险的几类问题拦下来比追求完美检查器重要得多。4.2 机床侧验证空运行和单段执行脚本检查和仿真都过了也不代表机床就能直接开跑。我的流程永远是台阶式验证先做空运行。把倍率放在空运行挡让机床快速跑一遍程序轨迹重点观察会不会撞行程限位、Z 轴抬得够不够高。这一步能看到空间运动关系但一定要知道它的局限空运行发现不了刀补方向错控制器不会报错它只会忠实地按你的程序走。然后做单段执行。把 Z 轴整体抬高到安全高度开启单段模式每按一次“循环启动”只执行一段。眼睛盯住坐标变化确认没有异常动作后再进入下一步。接着降速试切把进给速度临时降到正常值的 20% 到 50%实际切一刀就停听声音、看切屑确认一切正常。最后做首件复测量关键尺寸合格后才敢继续跑下一件。4.3 安全底线哪些情况绝对不要上机下面列的是我自己的红线任何人问我要 GLLM 落地方案我都会先讲这一条未经校验脚本和仿真验证的程序一律不上机。程序里出现超出机床行程的坐标不修改不允许运行。工件坐标系与程序假设不一致时不上机。刀号、刀具直径、主轴转速与程序表不一致不上机。现场没有人熟悉急停机制不上机。大模型生成只是草稿执行前的最终责任在人和工艺审核流程。这句话我希望每个想用 GLLM 的人都能记住。模型能帮你省掉大量重复劳动但不会替你对安全负责。5. 一个可复现的落地案例矩形槽铣削的自然语言转 G 代码5.1 原始指令与系统状态放到具体例子来看会更容易理解整个链路是怎么运作的。假设用户输入是这样一句话“材料 6061 铝合金工件原点在左上角上表面用 T1 直径 10mm 平底刀铣一个长 100、宽 50、深 6 的矩形槽槽中心在 X50、Y-25分两层每层 3mm粗铣留 0.3mm 余量最后一刀精铣到位。”系统环境卡片就用“2.2”里那段工件坐标系 G54行程范围 X0~500、Y-300~300、Z-250~0T1 是直径 10mm 平底刀。这个任务非常典型简单二维轮廓、分层加工、粗精分离是 GLLM 最容易做好的类型很适合作为第一个跑通的项目。5.2 第一次生成的初稿以及我要求模型修正的过程第一次让模型生成它给出的初稿往往是这样的O3010 (SLOT_100X50_D6) G90 G21 G54 G17 G40 G49 G80 T1 M06 S6000 M03 G00 X50.0 Y-25.0 G00 Z5.0 G01 Z-6.0 F600.0 G00 Z50.0 M05 M30这程序看起来要素齐全实际上一堆问题直接一刀下到 Z-6根本没有分层没有 G43 H01 长度补偿中心下刀直接砸向材料对刀具极不友好没有粗精分离没有 XY 方向的切削路径。如果谁把这个版本直接传进机床等于在工件中心扎了一刀就抬起来根本不算铣槽。GLLM 工作流最核心的交互方式不是你去手改代码而是用自然语言给模型下达修正指令。我就这么要求它“请按两层分刀第一层下到 Z-3.0第二层下到 Z-6.0每层先做平行往复粗铣留 0.3mm 余量再做精铣轮廓程序头加 G43 H01定位到起始角点下刀不要用中心下刀。”模型收到这条修改意见后会重新生成一个更贴近实际工艺的版本。5.3 最终版程序与验证清单经过一轮修正最终版程序的结构大致是这样为了版面清晰省略了槽底清理和精铣的完整分步实际程序会比这个长O3020 (SLOT_100X50_D6_FINAL) (--- HEADER ---) G90 G21 G54 G17 G40 G49 G80 T1 M06 S6000 M03 G43 H01 Z50.0 (--- ROUGH LAYER 1 : PARALLEL CLEAN ---) G00 X30.0 Y-15.0 G00 Z5.0 G01 Z-3.0 F200.0 G01 X70.0 F600.0 G00 Z5.0 G00 X70.0 Y-25.0 G01 Z-3.0 F200.0 G01 X30.0 F600.0 G00 Z5.0 G00 X30.0 Y-35.0 G01 Z-3.0 F200.0 G01 X70.0 F600.0 G00 Z5.0 (--- ROUGH LAYER 2 : PARALLEL CLEAN ---) G00 X30.0 Y-15.0 G01 Z-6.0 F200.0 G01 X70.0 F600.0 G00 Z5.0 G00 X70.0 Y-25.0 G01 Z-6.0 F200.0 G01 X30.0 F600.0 G00 Z5.0 G00 X30.0 Y-35.0 G01 Z-6.0 F200.0 G01 X70.0 F600.0 G00 Z5.0 (--- FINISH ---) G00 X30.0 Y-15.0 G01 Z-6.0 F150.0 G01 X70.0 G01 Y-35.0 G01 X30.0 G01 Y-15.0 G00 Z50.0 (--- END ---) M05 M30这版程序明显更接近老师傅手写的水平有程序头初始化、有长度补偿、分层清楚、粗精分离下刀点也避开了中心。但我要再强调一遍不同控制器的语法略有差异刀具悬伸长度、夹具位置也会影响实际参数所以这里更多是展示工作流具体数值必须按自己的设备调整。最终上机前我的验证清单是固定的脚本检查通过确认没有坐标超程、没有缺少 M30 和 G43数控仿真环境里走一遍轨迹确认没有碰撞空运行一遍观察各轴动作单段执行逐步放行降速试切首件复测尺寸。每一步都确认没异常才敢进入下一步。5.4 这个案例还能怎么扩展单条指令转 G 代码只是第一步。后面能扩展的方向很多把“输入自然语言 出 G 代码 校验脚本 仿真记录”包装成内部网页工具让没写过代码的人也能用把历史验证过的程序收集起来做本地模型微调让输出越来越贴近自己厂里的工艺习惯把材料、刀具、切削参数沉淀成知识库让模型不再只生成“看起来对”的程序而是真的按工艺规范来生成。如果你已经把第一条矩形槽程序跑通后面的迭代就只是时间问题。6. 我踩过的那些“看似正确但实际危险”的坑6.1 坐标模式切换G90/G91 混用的隐形风险有一段时间我用 LLM 生成程序用得很顺直到某次处理一个较长的轮廓程序模型在中段突然插了一行 G91。从那行开始所有坐标都变成增量值整个轮廓整体偏移了一个固定量。最可怕的是机器不报警因为每一行单独看都合法控制器只会按指令走。如果不是下刀前空运行仔细盯着轨迹看很可能直接就压到工件上了。这个坑的根源在于模型会按照“局部看起来合理”的方式切换坐标模式但人的习惯是全程 G90。对策很简单规则里强制写明“全程使用 G90禁止出现 G91”同时让校验脚本把 G91 当作危险字串报警。宁可误报也不能放过。6.2 刀具半径补偿方向G41/G42 靠模型判断不靠谱刀具半径补偿这个坑更隐蔽。G41 是左补偿G42 是右补偿具体用哪个要结合走刀方向、顺铣还是逆铣来判断。模型其实很难每次都算对这个方向尤其当轮廓形状不规则、走刀方向绕来绕去的时候。我就遇到过模型把 G42 写成 G41 的情况。仿真轨迹看起来是在走轮廓但实际加工会整体过切一个刀半径。更麻烦的是如果程序里漏了刀补加工尺寸又会偏大一个刀具直径。这类问题靠校验脚本很难直接发现因为代码本身合法。我的对策是轮廓加工优先让模型关闭刀补直接给出中心轨迹如果工艺必须启用刀补就把“补偿方向和走刀方向一起复查”列为人工复核的固定项绝不当自动化可省略的一步。6.3 圆弧插补与进给速度模型会“编造”看起来像样的数字G 代码里有很多“成立性”的条件。比如 G02/G03 圆弧插补指定 R 半径时无法画整圆圆心向量 I/J 必须与终点匹配模型在生成这些参数时很容易给出视觉上像模像样、但数值不自洽的组合。进给速度也是重灾区它可能以 mm/min 为单位也可能误按某些旧设备习惯写成 mm/rev数量级差出几十倍。切削参数同样如此S12000、F2000 配 10mm 平底刀加工钢件基本是灾难但在模型眼里它只是普通数字。这些问题无法靠提示词根除因为大模型本质上是在做“看起来合理”的预测。有效的办法是把 S/F 上下限写进校验脚本做一个“参数体检”进给超过指定上限直接标红圆弧指令做几何一致性检查I、J 向量与终点不匹配就报错。工具不复杂但能把“编造的数字”挡在机床之外。最后说点个人的体会。GLLM 这套东西最有价值的不是“完全自动”而是把工艺人员的注意力从重复劳动里解放出来。我在实际项目里始终把模型生成当第一版草稿校验、仿真、空运行一步都不少。机床上贴一张上机前自检清单——程序有没有 G90/G94/G21、有没有 M30、刀具对不对、行程够不够——这张纸比任何模型都管用。把人的经验和模型的效率放在正确的位置上这条路才能真正落地。
