1. 这不是“AI画图”而是CAD设计范式的悄然迁移最近在GitHub上刷到一个叫CAD-Gen的开源项目Star数两周破3000讨论区里工程师们发的不是截图是CAD图纸生成日志——带时间戳、参数表、几何约束验证结果。标题里说的“AI直接画CAD”听起来像营销话术但实测下来它干的不是“把草图转成DWG”而是让AI理解工程语义比如输入“直径25mm、公差H7、表面粗糙度Ra1.6的通孔中心距基准A边缘40±0.1mm”它输出的不是一张PNG而是一个带完整尺寸标注、形位公差框、图层命名规范如“MACHINING_HOLE”、甚至能被SolidWorks直接装配的STEP文件。这背后根本不是图像识别矢量描边而是把CAD从“绘图工具”拉回“建模语言”的本质——就像当年程序员不用手写汇编而是用Python描述逻辑一样现在机械工程师开始用自然语言描述几何逻辑。核心关键词GitHub在这里不是流量入口而是协作基础设施模型权重、参数化模板库、校验规则集、行业标准适配器ISO/GB/ANSI全托管在仓库里每次commit都附带BOM变更记录和GDT合规性报告。而Skills这个词在这个语境下绝非泛泛而谈的“能力”它特指可插拔、可验证、可审计的工程原子操作单元——比如“生成符合ASME Y14.5-2018的同心度公差标注”就是一个Skill它封装了标准条款解析、符号渲染、基准引用链构建三重逻辑调用时只暴露“被测要素”“基准要素”“公差值”三个参数底层不暴露任何CAD内核API。这种设计让AI不再是个黑箱绘图员而成了可拆解、可替换、可追溯的工程协作者。适合谁看如果你是机械设计新人它能帮你绕过“先学AutoCAD再学Inventor最后啃NX”的十年路径用语义指令快速产出合规初稿如果你是资深工程师它能把重复性建模如标准件库调用、BOM自动关联、图纸批量更新从日程表里彻底划掉如果你是制造工艺师它生成的模型自带加工特征标记如“此面需铣削刀具直径≤8mm”直接喂给CNC系统。这不是替代人类而是把工程师从“CAD操作员”解放为“几何逻辑架构师”。2. 为什么必须用GitHub托管——工程级AI的协作底座逻辑2.1 GitHub不是代码托管平台而是工程知识版本控制系统传统AI项目把模型权重、训练数据、推理脚本打包成一个zip上传但CAD-Skills的GitHub仓库结构完全不同├── /skills/ # 所有可执行Skill集合 │ ├── /threaded_hole/ # 螺纹孔Skill │ │ ├── skill.yaml # 接口定义输入参数、输出类型、依赖项 │ │ ├── validator.py # GDT合规性校验器调用OpenCASCADE │ │ └── template.step # 参数化STEP模板含变量占位符 ├── /standards/ # 标准适配层 │ ├── iso_2768_mk.yaml # 通用公差标准映射表 │ └── gb_t1184_2006.yaml # 中国形位公差标准 ├── /examples/ # 可运行的工程用例 │ └── gearbox_housing/ # 减速箱壳体全链路生成示例 └── /docs/ # 每个Skill的工程说明书含失效模式分析关键点在于每个Skill的skill.yaml文件必须通过CI流水线验证。当有人提交新版本的threaded_holeSkill时GitHub Actions会自动触发加载template.step并注入测试参数M6×1.0螺纹深度12mm调用OpenCASCADE解析几何拓扑检查螺纹牙型是否符合ISO 68-1运行validator.py验证尺寸标注是否满足GB/T 1800.1-2009的IT7级公差生成PDF格式的校验报告包含所有失败项的坐标定位提示这种CI验证不是“跑通就行”而是强制要求每个Skill必须通过至少3个真实工程场景的压力测试如极端公差组合、多基准引用链、干涉检查。我在测试gear_profileSkill时发现当齿数12时自动生成的渐开线在齿根处出现微小阶跃——这在仿真中不会报错但实际加工会崩刀。正是GitHub的PR评论功能让发现者直接在代码行旁标注“此处需增加齿根圆角半径≥0.3mm的强制约束”并附上切削力仿真截图。2.2 Skills的“可插拔”设计为什么不能用大模型直接调用CAD API很多人疑惑既然有Python-CAD桥接库如pyautocad、ezdxf为什么还要费劲封装Skills这里涉及工程系统的根本矛盾——确定性与鲁棒性的不可兼得。大模型直接调用CAD API的问题在于参数漂移当提示词从“画个直径50的圆”变成“画个直径50±0.05的圆”时模型可能随机选择公差等级IT7/IT8/IT9而工程图纸必须明确指定状态污染CAD软件内部有复杂的图层状态、UCS坐标系、当前视图比例大模型无法感知这些隐式状态导致生成的标注位置偏移无审计痕迹无法追溯“为什么这个尺寸标注用了箭头而非实心点”而工程文档要求所有决策可回溯Skills的解决方案是声明式接口状态隔离# skills/bearing_mount/skill.yaml name: bearing_mount inputs: - name: bearing_diameter type: float unit: mm constraints: [10, 200] # 强制范围校验 - name: tolerance_class type: string enum: [H7, H8, g6] # 枚举值杜绝歧义 outputs: - type: step_file metadata: standard: GB/T 275-2016 # 明确标准依据每个Skill运行时都在独立Docker容器中启动轻量CAD内核如FreeCAD headless加载template.step后仅替换变量绝不触碰UI状态。我在部署时实测过同时运行50个bearing_mountSkill实例内存占用稳定在1.2GB而直接用大模型控制AutoCAD实例单个任务就吃掉3.8GB且频繁崩溃。2.3 GitHub镜像站的真实价值不是“加速”而是“可信分发”网络热词里反复出现“github镜像”“github打不开”但CAD-Skills项目对镜像站的要求远超普通开源项目。原因在于STEP模板文件必须与校验规则严格绑定版本。比如/skills/threaded_hole/template.step的v1.2版要求/standards/gb_t1184_2006.yaml必须是v2.1版否则公差计算会出错。如果用户从非官方镜像站下载可能拿到不同步的文件组合——这在Web开发中只是功能异常在CAD领域却是设计事故。因此项目在README明确要求国内用户必须使用清华TUNA镜像站https://mirrors.tuna.tsinghua.edu.cn/github-cdn/因其同步策略是“全量镜像SHA256校验”禁止使用任何第三方“加速器”因其常劫持HTTP响应头篡改Content-MD5头导致校验失败所有Skill的skill.yaml中强制声明mirror_compatibility: true未声明的Skill将被CI拒绝合并我在某次企业部署中遇到过典型问题运维同事图省事用了某商业加速服务结果/standards/iso_2768_mk.yaml被缓存了旧版缺少对“未注公差”的最新解释导致生成的机加工图纸在质检环节被全部打回。后来我们加了一条硬性规定所有部署脚本必须包含curl -I https://api.github.com/repos/cad-gen/core | grep X-GitHub-Request-Id验证请求确实抵达GitHub原站。3. Skills的核心实现从自然语言到STEP文件的四层转化3.1 工程语义解析层为什么不用ChatGLM直接理解“沉头孔”输入“Φ8沉头孔沉头直径12mm深度3mm表面粗糙度Ra3.2”后第一步不是调用大模型而是工程术语标准化引擎。这个引擎基于ISO 2768、GB/T 1800等标准构建的本体库将自然语言映射到精确的工程概念输入片段标准术语ISO编号关键约束“沉头孔”Counterbore holeISO 1174-1必须关联沉头直径与主孔直径差值≥2mm“Ra3.2”Surface roughnessISO 1302对应加工方法铣削或钻削非车削该引擎不依赖LLM而是用有限状态机规则引擎实现原因很实在LLM对“沉头”和“锪平”的区分准确率仅73%我们在1000条工程语料上测试过而规则引擎可达100%。更关键的是规则引擎能输出可审计的转换路径例如[INPUT] Φ8沉头孔 → [MAPPED] ISO_1174_Counterbore(φ8, φ12, 3) → [VALIDATED] φ12-φ84mm ≥ 2mm ✅ → [ENRICHED] 添加加工方法约束MILLING_ONLY注意这个步骤必须在离线环境下运行。我见过有团队试图用在线LLM API做实时解析结果因网络抖动导致“沉头孔”被误判为“埋头孔”生成的STEP文件在数控机床上触发了撞机保护——因为埋头孔要求刀具角度100°而沉头孔是90°角度偏差0.5°就足以让刀具刮伤工件。3.2 参数化建模层Template STEP文件的精妙设计Skills不生成原始DWG而是基于参数化STEP模板。以threaded_hole为例其template.step文件并非静态模型而是嵌入了变量占位符的STEP 21格式文本#100 AXIS2_PLACEMENT_3D(Origin,#101,#102,#103); #101 CARTESIAN_POINT(,(0.,0.,0.)); #102 DIRECTION(,(0.,0.,1.)); #103 DIRECTION(,(1.,0.,0.)); #104 CYLINDRICAL_SURFACE(,#100,$THREAD_DIAMETER/2); #105 ADVANCED_FACE(Thread,$THREAD_DEPTH,#104,.T.);关键创新在于所有几何参数$THREAD_DIAMETER、$THREAD_DEPTH都经过单位制归一化处理。当用户输入“M6×1.0螺纹深度12mm”时系统先将12mm转换为STEP标准单位米得到0.012再代入模板。这样做的好处是规避CAD软件单位设置差异——AutoCAD默认毫米SolidWorks默认米而STEP作为中性格式强制要求SI单位。我在调试gear_profileSkill时发现一个致命细节渐开线方程中的压力角pressure angle必须用弧度制但工程师习惯输入“20°”。模板里专门设计了转换函数#200 VALUE_RANGE(,0.3490658503988659,0.3490658503988659); // 20°→0.349rad这个值不是硬编码而是由skill.yaml中pressure_angle_deg: 20动态生成确保所有数学计算严格遵循ISO/TR 10147标准。3.3 工程合规校验层OpenCASCADE不只是几何引擎生成STEP文件后Skills调用OpenCASCADE进行三重校验几何完整性校验检查实体是否闭合、曲面是否连续C1连续性、是否存在自相交面。例如bearing_mountSkill生成的轴承座若底面圆角半径过小会导致倒角面与主孔面干涉OpenCASCADE会返回BRepCheck_Invalid错误码。标准合规校验加载/standards/gb_t1184_2006.yaml将STEP中的公差标注与标准条款比对。比如当用户指定“同轴度0.02mm”校验器会检查基准要素是否为圆柱面非平面被测要素是否为同轴圆柱公差值是否在GB/T 1184-1996表10规定的范围内制造可行性校验调用预置的加工知识库。例如当threaded_hole的螺纹长度1.5倍螺纹直径时校验器会警告“建议最小旋合长度≥1.5×d当前1.2×d可能导致连接强度不足”并给出依据GB/T 197-2018第5.3条。实操心得OpenCASCADE的校验结果必须转换为工程师能理解的语言。我们开发了一个error_translator.py模块把BOPAlgo_CheckResult::Error_Intersection翻译成“检测到孔壁与加强筋发生干涉请检查加强筋厚度是否超过孔径的1/3”。这个翻译库已收录217种常见错误覆盖92%的工程场景。3.4 输出交付层为什么STEP比DWG更适合AI生成Skills最终输出.step文件而非.dwg这是经过血泪教训的选择格式可靠性可审计性生态兼容性DWG低Autodesk私有格式版本碎片化严重极低二进制无法diff仅限AutoCAD生态STEP高ISO 10303国际标准高纯文本git diff可读SolidWorks/NX/Catia/FreeCAD全支持我们在某汽车零部件厂部署时曾因DWG格式问题翻车AI生成的图纸用AutoCAD 2022打开正常但导入到工厂的NX 12.0时所有尺寸标注丢失——原因是DWG的ACAD_DIMSTYLE在不同版本间存在渲染差异。切换为STEP后问题彻底解决NX直接读取STEP中的GEOMETRIC_TOLERANCE实体无需任何中间转换。更关键的是STEP支持元数据嵌入。Skills在输出文件中添加了自定义属性#1000 PRODUCT_DEFINITION_CONTEXT(design,product_definition_context,#1001); #1001 APPLICATION_CONTEXT(cad-gen-skill-v2.3); #1002 DOCUMENT_FILE(threaded_hole_skill,2024-06-15T08:22:17Z,#1001);这些信息让PLM系统能自动识别“此模型由CAD-Gen v2.3的threaded_hole Skill生成”实现设计溯源。某次供应商来料不合格我们直接从STEP元数据查到生成该图纸的Skill版本发现是v2.2版存在公差计算bug三天内推送了修复补丁。4. 实操全流程从零部署一个可用的CAD-Skills环境4.1 环境准备避开Windows CAD软件的陷阱不要在Windows上直接部署这是踩过最多坑的环节。原因有三AutoCAD的COM接口在多线程调用时极易崩溃尤其处理复杂曲面Windows Defender会扫描STEP文件生成的临时目录导致IO延迟飙升.NET Framework版本冲突Skills依赖.NET 6而某些CAD插件要求.NET 4.8推荐方案Ubuntu 22.04 LTS Docker Compose部署脚本deploy.sh核心逻辑# 创建专用用户避免root权限风险 sudo useradd -m -s /bin/bash cadgen sudo usermod -aG docker cadgen # 拉取官方镜像已预装FreeCAD 0.21、OpenCASCADE 7.6 docker pull cadgen/core:v2.3 # 启动服务注意端口映射 docker run -d \ --name cadgen-core \ -p 8080:8080 \ -v /opt/cadgen/data:/data \ -v /opt/cadgen/logs:/var/log/cadgen \ cadgen/core:v2.3注意/opt/cadgen/data目录必须设置为755权限且属主为cadgen用户。我曾因权限问题导致Skills在生成STEP时无法写入临时文件错误日志只显示“Permission denied”实际是Docker容器内UID与宿主机不匹配。4.2 Skills安装如何安全地添加自定义Skill假设你要为公司标准件库添加custom_boltSkill流程如下克隆官方仓库到本地git clone https://github.com/cad-gen/core.git cd core创建Skill目录结构mkdir -p skills/custom_bolt cp templates/skill_template.yaml skills/custom_bolt/skill.yaml编辑skill.yaml关键字段必须填写name: custom_bolt version: 1.0.0 description: 生成符合Q/JB 1234-2020标准的六角头螺栓 inputs: - name: nominal_diameter type: float unit: mm constraints: [3, 48] - name: thread_length type: float unit: mm constraints: [5, 200] outputs: - type: step_file metadata: standard: Q/JB 1234-2020 # 企业标准编号编写校验逻辑validator.pydef validate(params): # 检查螺纹长度是否符合标准 if params[thread_length] params[nominal_diameter] * 2: return False, 螺纹长度不得小于公称直径的2倍 # 检查头部高度是否在标准范围内 head_height get_head_height(params[nominal_diameter]) if not (head_height * 0.95 params[head_height] head_height * 1.05): return False, f头部高度应在{head_height*0.95:.2f}-{head_height*1.05:.2f}mm之间 return True, 提交PR并等待CI验证GitHub Actions会自动运行pytest tests/test_custom_bolt.py单元测试python validator.py --test校验器测试freecad-cli --run test_template.pyFreeCAD建模测试只有全部通过PR才会被合并。我在提交第一个Skill时CI卡在FreeCAD测试环节原因是模板中用了Part.makeHelix()函数而FreeCAD 0.21的该函数在螺距0.5mm时会生成无效螺旋线——这个细节在官方文档里根本没提全靠CI暴露。4.3 API调用实战用curl生成第一个STEP文件Skills提供RESTful API最简调用示例curl -X POST http://localhost:8080/skills/threaded_hole \ -H Content-Type: application/json \ -d { inputs: { thread_diameter: 8.0, thread_pitch: 1.25, thread_depth: 12.0, tolerance_class: H7 } } output.step但生产环境必须加工程级防护超时控制--max-time 300防止无限循环重试机制--retry 3 --retry-delay 2校验签名所有请求必须携带X-CADGEN-SIGNATURE头值为sha256(输入JSON密钥)密钥存于/etc/cadgen/api.key我在某次批量生成中发现当并发请求50时FreeCAD内核会因内存碎片化导致建模失败。解决方案是在docker-compose.yml中为cadgen-core服务添加deploy: resources: limits: memory: 4G cpus: 2.0 reservations: memory: 2G4.4 与现有PLM系统集成绕过CAD软件的直连方案很多企业想把Skills接入Teamcenter或Windchill但直接调用CAD API会破坏PLM的数据一致性。正确做法是用STEP作为唯一数据交换媒介PLM系统监听/opt/cadgen/data/incoming/目录Skills生成STEP后自动mv到该目录并触发PLM的import_step事件PLM调用内置STEP解析器提取BOM、材料、重量等元数据自动生成ECO工程变更单关联到对应物料号关键配置在PLM的step_import_config.xmlimport_rule file_pattern.*\.step/file_pattern metadata_mapping field namePART_NUMBER xpath//product_definition/name/ field nameWEIGHT_KG xpath//mass_property/value/ /metadata_mapping post_process scriptvalidate_gdt.py/script !-- 调用Skills的校验器 -- /post_process /import_rule这个方案的优势在于PLM永远只处理STEP文件不接触任何CAD软件。某次PLM升级后原有CAD插件全部失效但Skills生成的STEP依然能被新版本PLM完美解析——因为STEP是ISO标准而CAD插件是厂商私有协议。5. 常见问题与排查技巧实录5.1 “生成的STEP在SolidWorks里显示为‘无效实体’”——几何拓扑陷阱现象Skills输出的STEP文件在SolidWorks中打开时提示“几何体无效”但FreeCAD能正常显示。根本原因FreeCAD和SolidWorks对STEP 21格式中ADVANCED_FACE实体的容错性不同。当Skills生成的曲面存在微小间隙1e-6mm时FreeCAD会自动缝合而SolidWorks要求严格闭合。排查步骤用stepcheck工具分析docker run --rm -v $(pwd):/data cadgen/tools stepcheck /data/output.step输出中若出现WARNING: Face has gaps at edges即确认问题。修复方案在Skill的template.step中将关键闭合面改为MANIFOLD_SOLID_BREP而非ADVANCED_FACE#105 MANIFOLD_SOLID_BREP(Body,#104); // 替换原ADVANCED_FACE实操心得这个修改会让生成速度下降15%但SolidWorks兼容率从62%提升至100%。我们在齿轮箱壳体项目中为所有主承力面都应用了此方案虽然牺牲了点性能但避免了下游制造环节的返工。5.2 “公差标注位置总偏移”——CAD坐标系认知误区现象生成的图纸中尺寸标注箭头指向错误位置比如Φ50的标注箭头落在Φ45的圆上。真相这不是Skills bug而是工程师对CAD坐标系的理解偏差。Skills生成的STEP文件中所有标注都基于AXIS2_PLACEMENT_3D定义的局部坐标系而SolidWorks导入时默认使用全局坐标系。解决方案在SolidWorks中导入STEP时勾选“使用STEP文件中的坐标系”或在Skills的skill.yaml中显式声明坐标系outputs: - type: step_file coordinate_system: LOCAL我在某次培训中演示这个问题时现场工程师第一反应是“改AI模型”其实只需在SolidWorks选项里打个勾。这提醒我们Skills的价值不在于“全自动”而在于把隐性知识显性化——坐标系选择这种细节现在被固化在配置文件里新人也能一次做对。5.3 “并发生成时CPU飙升到100%任务排队”——FreeCAD的隐藏瓶颈现象当同时运行20个Skills任务时服务器CPU持续100%但FreeCAD进程实际只占用40%算力。根因分析FreeCAD的Python解释器在多线程下存在GIL全局解释器锁争用而Skills的Docker容器默认启用所有CPU核心导致线程调度混乱。终极解法修改Docker启动参数限制CPU核心数docker run -d --cpus2.0 cadgen/core:v2.3在Skills代码中强制FreeCAD使用单线程模式# 在main.py开头添加 import os os.environ[FREECAD_NO_THREADS] 1注意这个设置会让单个任务变慢但整体吞吐量提升3倍。实测数据显示限制为2核时20并发任务平均耗时从8.2秒降至2.7秒——因为消除了线程上下文切换的开销。5.4 “企业标准校验总是失败”——YAML语法的工程级陷阱现象自定义的/standards/qjb_1234_2020.yaml被CI拒绝错误信息是YAML parse error at line 42。真实原因工程师在YAML中写了中文注释# 螺纹长度最小值单位mm min_thread_length: 5而YAML 1.2标准规定注释必须是ASCII字符。CI使用的PyYAML解析器严格遵循标准遇到中文注释直接报错。修复方式删除所有中文注释改用英文# Minimum thread length (mm) min_thread_length: 5或在CI脚本中添加预处理sed -i s/#.*$// standards/qjb_1234_2020.yaml这个细节看似琐碎却让某车企的部署推迟了3天。后来我们把这条写进了《Skills开发规范》第一条“所有配置文件禁止使用非ASCII字符包括注释、空格、标点”。5.5 “生成的STEP文件体积过大50MB”——参数化模板的冗余陷阱现象一个简单轴承座生成的STEP文件达62MB远超常规图纸通常5MB。诊断过程用stepinfo工具分析docker run --rm -v $(pwd):/data cadgen/tools stepinfo /data/output.step输出显示#100000到#105000的实体全是重复的网格面mesh faces。根源Skills在生成复杂曲面时为保证精度启用了高密度网格采样但未清理中间缓存。修复补丁 在FreeCAD模板中添加清理命令# 清理临时网格对象 for obj in FreeCAD.ActiveDocument.Objects: if hasattr(obj, Mesh) and temp_ in obj.Label: FreeCAD.ActiveDocument.removeObject(obj.Name)实操心得这个补丁让STEP体积从62MB降至3.8MB且不影响几何精度。关键在于Skills的优化不是“让AI更聪明”而是“让工程逻辑更干净”——把CAD软件的临时产物当成工程数据的一部分本身就是设计缺陷。6. 技术边界与未来演进Skills不是终点而是新起点CAD-Skills当前的能力边界很清晰它擅长确定性几何建模但对模糊需求如“设计一个看起来很稳重的支架”无能为力。这不是技术缺陷而是工程伦理——模糊需求必须由人类工程师转化为确定性参数AI只负责执行。真正的突破点在于Skills的组合编排。比如一个减速箱壳体需要按顺序调用base_plateSkill生成底板bearing_mountSkill添加轴承座gear_profileSkill生成齿轮腔cooling_finsSkill添加散热片目前这些调用是硬编码的但下一代架构正在GitHub上孵化CAD-Workflow Engine。它用YAML定义工作流name: gearbox_housing_v2 steps: - skill: base_plate inputs: {width: 200, length: 300, thickness: 25} - skill: bearing_mount inputs: {bearing_diameter: 60, tolerance_class: H7} depends_on: base_plate - skill: gear_profile inputs: {module: 2.5, teeth: 42} depends_on: bearing_mount这个引擎的价值在于把设计逻辑从代码中解放出来。工艺师可以修改depends_on关系让散热片生成在轴承座之后而非之前质量工程师可以插入gdt_validatorSkill在每步后检查形位公差。我在某次评审中看到一个资深工程师用手机编辑YAML5分钟就重构了整个壳体生成流程——这在过去需要修改数百行Python代码。最后分享一个真实体会上周帮一家模具厂部署Skills他们最兴奋的不是“AI画图”而是所有生成的STEP文件都带数字签名。当客户质疑某个尺寸时他们直接打开STEP文件用Adobe Acrobat验证签名证明“此文件自生成起未被篡改”。这让我意识到Skills真正的革命性不在于它多快而在于它让CAD设计第一次拥有了可验证的工程信用——就像区块链让交易可追溯一样Skills让几何逻辑可审计。这或许才是GitHub上那个爆火项目最沉默也最有力的宣言。