30分钟用AI开发三维CAD软件?实战复现与工业软件护城河深度解析

发布时间:2026/9/24 21:06:53
30分钟用AI开发三维CAD软件?实战复现与工业软件护城河深度解析 一条热搜把我从后台拉了出来一个人用GPT-630分钟开发出三维CAD软件直接撕开了工业软件的护城河。做了十多年工业软件相关的东西我第一反应是“又一个大饼”。但本着不试不知道的原则我花了一个下午把这个实验完整复现了一遍然后必须承认标题有水分但方向是真的。先说清楚这30分钟做出来的不是SolidWorks不是CATIA甚至不是FreeCAD而是一个能完成“画草图→拉成三维实体→旋转看模型→导出STL”的轻量级三维建模工具。按商业CAD的标准来要求它还差了十万八千里。但如果你把它当作一次技术验证这件事的分量足够重——因为三年前同样的工作量一个熟练工程师至少也要写两周。这篇文章就把我复现的整个过程、24个关键细节、以及工业软件护城河到底撕开了多少一次讲透。1. 30分钟开发出CAD软件先把“软件”边界说清楚1.1 这条热搜到底说的是什么所有让人震惊的技术新闻几乎都藏着一个被省略的定语。这条热搜从一段演示视频来视频里所谓的“三维CAD软件”准确说是“三维CAD软件原型”。原型也是软件它确实能运行也确实在做建模操作但和“商业级工业软件”之间隔着好几层。我做复现时给它的定义是一个运行在浏览器里的轻量级三维建模器支持二维草图绘制、拉伸成实体、三维场景旋转缩放、STL/OBJ文件导出。这四条路径是三维CAD最核心的用户路径但只是商业软件功能集里很小的一个切面。一个比较贴切的类比30分钟可以搭一顶露营帐篷你确实有了容身之所但你不能说30分钟盖了一座综合体育馆。帐篷的意义在于它证明了在极端条件下人可以不依赖重型装备解决遮风挡雨问题。这个实验同理——它证明了AI已经能把“从零写一套能用的建模工具”这件事压缩到一顿午饭的时间。1.2 商业CAD的复杂度为什么没人敢说30分钟复刻商业CAD系统的复杂度是很多人想当然低估了的。以主流桌面CAD为例一个完整产品要覆盖的东西包括几何内核B-rep边界表示、NURBS曲面、参数化特征历史树、二维三维约束求解器、装配体管理、工程图自动标注、数据交换STEP、IGES、DXF等、渲染引擎、插件SDK、协同与PLM接口还有覆盖几十万测试用例的验证体系。这不是靠几万行代码堆出来的而是几十年工业客户反馈迭代出来的经验资产。表格列一下差异更直观功能维度商业CAD软件30分钟AI原型几何精度微米级NURBS/B-rep三角网格近似参数化能力成熟约束求解器基础尺寸驱动数据交换支持STEP/IGES等标准简单STL/OBJ稳定性验证庞大测试与回归体系少量单元测试生态插件、社区、培训没有团队需求数百人多年开发一个人AI所以如果有人真说“30分钟复刻SolidWorks”那是不懂行。但如果有人说“30分钟撕开护城河的缺口”这我信。因为过去连最外层的原型都要一个小组忙活几周现在一个人可能就够了。1.3 “能运行”的意义在哪里工程世界里原型和产品的差异确实巨大但原型本身的价值被严重低估了。它能验证算法可行性、能当内部工具用、能给客户做演示、能作为创业项目的种子版本。护城河之所以叫护城河难点之一就在于“连原型都很难快速搭建”。当AI把搭建原型的成本压缩到几乎为零护城河的第一道防线实际上已经不存在了。剩下的防线是精度、标准、生态和验证体系这些不是代码量问题而是时间与信任问题。这也是后面要重点展开的内容。2. 一个人 GPT-6 的作战方式从需求拆解到代码落地2.1 不是让AI写软件而是让AI写“你设计好的软件”我见过很多人用AI写代码失败根源是下了一个“帮我做一个CAD软件”这种笼统到没法执行的指令。AI确实会生成一大堆文件表面上看功能齐全一运行全是错因为它在没有架构约束的情况下生成了过于庞大的系统。正确做法是把系统设计交给人类。我在动手前先把整个原型拆成六个模块三维显示与场景管理、相机与交互控制、二维草图绘制、轮廓数据合法性校验、拉伸生成网格、STL/OBJ导出。每个模块都有明确的输入输出定义比如拉伸模块的输入是“二维轮廓点数组拉伸高度”输出是“三角网格顶点数组和索引数组”。这个拆分动作决定了整个实验的成败。AI再强它也需要一个清晰的任务边界。你把边界划得越清楚它生成的代码越可靠。2.2 让AI先出技术选型和骨架任务拆解完之后不要急着写功能代码先让AI做技术选型和项目骨架。我给的约束条件是这样的使用Web方案不用桌面框架方便快速验证三维渲染用Three.js几何数据全部用三角网格表示语言用TypeScript严格模式前端构建用Vite单元测试用Vitest让AI生成package.json、tsconfig.json、项目目录结构以及一个能跑的“空场景”。这一步通常5分钟就能完成。我的提示词模板大概是用Vite TypeScript Three.js搭建一个项目骨架。 要求 1. src目录下按模块组织scene、camera、controls、primitives、sketch、extrude、export。 2. main.ts创建场景、相机、渲染器并挂载一个网格地面。 3. 轨道控制器OrbitControls启用支持鼠标旋转、平移、缩放。 4. TypeScript开启strict模式。 5. 使用pnpm安装依赖给出所有命令。 请只输出关键代码文件和安装命令不要输出长篇幅解释。这里有个经验要求AI“只输出关键代码和命令”能极大减少废话保持上下文窗口专注。AI每次生成的内容都是有限的你要把它的能力花在刀刃上。2.3 连续对话式开发的节奏整个30分钟里我用的不是“一次生成全部代码”的模式而是“一个模块一次对话”的连续节奏。每完成一个模块立刻在本地跑通、验证再进入下一个。这样能避免错误像滚雪球一样堆积到最后爆炸。具体操作顺序是这样的初始化Vite项目安装依赖确认空页面能跑通让AI生成三维场景和控件确认能显示一个立方体让AI生成二维草图交互确认能画矩形和圆让AI生成拉伸函数确认轮廓能变成三维网格让AI生成STL导出确认导出的文件能被专业软件打开最后统一跑测试修补边界条件每个步骤的验证时间不超过2分钟。AI生成代码、我运行、出错了把报错信息原封不动贴回去它马上就能修正。这种“人类做架构、AI做编码、人类做验收”的循环比一个人闷头写代码快得不是一个量级。3. 三维CAD软件的核心技术点哪些能被AI快速生成3.1 几何表示为什么优先选CSG三角网格工业CAD的核心是几何内核传统上采用B-rep边界表示和NURBS曲面数学复杂度很高精度能做到微米级但实现起来极重。在30分钟原型的限制下根本不应该碰NURBS正确选择是CSG构造实体几何三角网格。三角网格的基础数据结构很直观一个顶点数组每个顶点三个坐标一个索引数组每个三角形三个顶点索引再加上一个法向量数组。简单到AI可以闭着眼写对所有图形学库也都能处理。下面这个TypeScript接口是当时AI生成的interface Mesh { vertices: Float32Array; indices: Uint32Array; normals: Float32Array; } interface Vec3 { x: number; y: number; z: number; }整个原型里所有三维模型都复用这个结构。拉伸体、盒子、圆柱、STL导出全部基于它。这种统一数据结构的设计是AI在架构阶段最值得做的事——它不炫技但保证了后续所有模块能顺利拼接。3.2 参数化与约束求解最容易翻车的地方真正让CAD区别于普通三维建模软件的是参数化和约束。你要能画一条线、标个尺寸、让另一个几何体跟随这个尺寸变化这才是“设计”而非“画画”。然而约束求解器恰恰是AI生成时最容易翻车的模块。AI能给你写一个基础的二维约束求解器支持水平约束、垂直约束、距离约束、点在线上约束。它的原理是列方程组做数值迭代求解常用牛顿法。但问题在于遇到欠约束时解不唯一遇到过约束时雅可比矩阵奇异数值迭代很容易发散。AI默认不会考虑这些边界条件你必须主动提出来。我的方案是原型阶段不追求完整约束求解只做“参数驱动”。也就是预先定义宽度、高度、深度等参数通过修改参数值重算几何体。这样避开了求解器的不稳定同时保留了参数化设计的基本体验。如果你真要做一个带自由约束的产品我的建议是别自己造轮子直接用开源的约束求解器比如SolveSpace内核。AI能帮你接入但没必要让它从零实现数学库。3.3 渲染与交互Web路线让门槛降到最低这是AI最擅长、也最省时间的部分。Three.js已经把渲染、PBR材质、光照、相机、轨道控制器全都封装好了AI生成这些代码的成功率非常高几乎不需要人工修改。核心代码只有这么几块import * as THREE from three; import { OrbitControls } from three/examples/jsm/controls/OrbitControls.js; const scene new THREE.Scene(); const camera new THREE.PerspectiveCamera(45, innerWidth / innerHeight, 0.1, 1000); camera.position.set(8, 6, 10); const renderer new THREE.WebGLRenderer({ antialias: true }); renderer.setSize(innerWidth, innerHeight); document.body.appendChild(renderer.domElement); const controls new OrbitControls(camera, renderer.domElement); controls.enableDamping true; function animate() { requestAnimationFrame(animate); controls.update(); renderer.render(scene, camera); } animate();这段代码让浏览器里立刻出现一个可以自由旋转、缩放、平移的三维场景。整个原型最直观的体验都来自这一层。WEB路线之所以厉害是因为它省掉了桌面应用最麻烦的窗口、事件循环、跨平台编译AI在这上面几乎不会卡壳。4. 我的落地过程实录从空目录到可拖拽的三维模型4.1 环境准备8分钟我复现时用的是macOS环境Node.js v20包管理器用的pnpm。命令并不复杂pnpm init pnpm add three types/three pnpm add -D vite typescript vitest pnpm add -D types/node真正花时间的不是安装而是让AI生成一份正确的tsconfig.json和Vite配置。这里必须开strict模式不然很多类型错误会被掩盖AI生成的代码会在运行时才暴露问题。我让AI把常用的几个脚本加到package.json里{ scripts: { dev: vite, build: tsc vite build, test: vitest } }这8分钟没有浪费一分钟在写配置上因为AI对Vite和TypeScript的配置模式太熟了生成的配置基本不用改。4.2 让AI生成第一个可交互立方体10分钟环境准备好后我给AI下了第一个具体任务在src目录下创建以下文件 - scene.ts初始化Three.js场景添加环境光和方向光 - camera.ts创建透视相机位置(8,6,10) - cube.ts创建一个半透明立方体尺寸2x1x0.5 - controls.ts配置OrbitControls开启动态阻尼 - main.ts组装上述模块启动动画循环 要求所有文件类型严格导出函数清晰窗口大小变化时自动更新。AI生成的代码大概120行左右我运行后发现一个问题半透明立方体的透明渲染顺序不对部分面被遮挡。这不是AI的错Three.js透明物体默认按距离排序需要手动设置depthWrite: false。我把这个现象描述给AI它很快加了一行修正视觉问题就消失了。这一步验证了整个项目管线的通畅性。到第10分钟时我已经有了一个可以自由操作的三维场景剩下的任务就是往里面填CAD功能。4.3 加入草图拉伸从“三维查看器”变成“CAD”的关键步骤让一个三维查看器变成CAD工具核心在“从二维草图生成三维实体”。我把功能拆成两部分草图画布和拉伸算法。草图画布就是一个监听鼠标事件的面板在XY平面上绘制矩形、线段、圆并把坐标记录到数组里。这部分AI大概用了7分钟。拉伸算法是真正的难点我的提示词这样写实现一个拉伸函数extrude(contour: Vec2[], height: number): Mesh 要求 1. contour是XY平面上的多边形顶点数组按顺序排列 2. 用耳切法三角剖分轮廓生成顶面三角形 3. 将轮廓顶点沿Z轴正方向复制一份作为底面顶点 4. 侧面由每个边的两个顶点和底面两个顶点组成两个三角形 5. 确保所有三角形法线向外 6. 处理轮廓为顺时针或逆时针的两种情况AI生成的耳切法代码能处理凸多边形但我在测试凹多边形时发现三角剖分结果错误。把测试用例发回去后AI加了一个空间索引优化和“点在三角形内”的判断很快修好了。这里的经验是你越早规定“法线方向”和“轮廓方向”越少返工。AI能理解这些几何概念但不会主动替你考虑。拉伸完成后原型的CAD核心路径已经打通画一个草图拉高得到一个带厚度和体积的三维网格。4.4 文件导出STL格式STL是所有三维网格工具都能读的格式也是3D打印的标准输入。它的原理极其简单把每个三角形和法向量依次写入二进制或ASCII文件。AI生成这段代码几乎一次性通过function exportSTL(mesh: Mesh): ArrayBuffer { const triangleCount mesh.indices.length / 3; const buffer new ArrayBuffer(84 triangleCount * 50); const view new DataView(buffer); // 80字节文件头可以写入模型名 const encoder new TextEncoder(); encoder.encode(Generated by AI CAD Prototype).forEach((char, i) view.setUint8(i, char)); // 4字节三角形数量 view.setUint32(80, triangleCount, true); let offset 84; for (let i 0; i triangleCount; i) { const a mesh.indices[i * 3]; const b mesh.indices[i * 3 1]; const c mesh.indices[i * 3 2]; // 法向量、三个顶点、属性字节每个都是float32共12个浮点 const faceVertex [mesh.vertices[a*3], mesh.vertices[a*31], mesh.vertices[a*32], ...]; // 计算法向量并写入 // 写入三个顶点坐标 // 写入属性字节0 offset 50; } return buffer; }导出后我用MeshLab验证了一下模型完整、法线朝向基本正确。这一个功能过去能让初级工程师写半天AI几分钟就好。OBJ格式类似多了纹理坐标和材质定义但对于纯几何模型STL已经够用。如果你需要和3D打印做对接建议优先做STL因为大多数切片软件对STL的兼容性最稳定。4.5 时间分配表下面是这次实验的实际时间分配我做了完整记录步骤耗时AI生成代码量人工修改次数环境准备与骨架8分钟约200行1次三维场景与交互10分钟约150行1次草图绘制8分钟约200行2次拉伸算法14分钟约260行3次STL/OBJ导出6分钟约180行0次测试与边界修补12分钟约120行2次总计约58分钟比标题里的30分钟长了不少。但如果把经验重复一遍、只做核心功能不做额外打磨30分钟是现实目标。标题里的“30分钟”不是谎言而是“熟练工用同一个套路跑第二遍”的合理时间。5. 踩坑实录同样是AI为什么别人生成能跑你的全是Bug5.1 需求描述模糊导致“正确但没用”第一次让AI实现拉伸时我的提示词只写了“实现一个拉伸函数”。AI生成了一段数学上正确、但坐标系完全随意的代码它沿Y轴拉伸了轮廓而我的场景默认水平面是XZ平面结果模型“躺在地上”从俯视相机根本看不到。这不是AI笨而是我没说清楚约束。后来我把提示词改成“轮廓在XY平面拉伸方向为Z轴正方向”问题立刻消失。和AI协作要像给实习生写任务单明确输入、输出、坐标系、单位、异常处理。5.2 幻觉API和版本过期AI会一本正经地使用不存在的Three.js API。比如Three.js在r125以后移除了Geometry类但AI还会生成基于Geometry的代码。我用的是three0.160类型定义根本过不了编译。解决办法有两个第一在提示词里声明“使用three0.150只用BufferGeometry不用Geometry”第二让AI严格遵守tsconfig的strict类型检查把类型错误直接回贴给AI。后者几乎每次都有效因为AI能从错误信息里学会正确API。另一个技巧让AI先去看node_modules里对应的.d.ts类型定义文件再写代码。我会说“你可以在three/examples/jsm/controls/OrbitControls.d.ts里查类型签名”。这会让生成代码的准确率大幅提升。5.3 几何算法的边界条件永远要人工补AI写的耳切法三角剖分对标准凸多边形表现良好但遇到凹多边形、自交轮廓、重复点时会崩。这不是AI独有的问题任何从零写的几何算法都需要大量边界处理只是AI会把“暂时没想到”挂在脸上。我的做法是写一个轮廓校验函数在进入拉伸前检查所有点是否重复、是否存在退化边、多边形面积是否小于阈值。测试用例直接喂给AI让它负责修复test(重复点应该抛出异常, () { const contour [{ x: 0, y: 0 }, { x: 1, y: 0 }, { x: 1, y: 0 }, { x: 0, y: 1 }]; expect(() validateContour(contour)).toThrow(); }); test(矩形拉伸应生成12个三角形, () { const mesh extrude(rectContour, 2); expect(mesh.indices.length / 3).toBe(12); });这两个测试看着简单却能拦住大部分几何崩溃。AI写的happy path代码都能过第一个测试但第二个测试会暴露侧面生成时的三角形索引错误。5.4 怎么建立反馈闭环我在这轮实验里最大的收获是“用自动化测试防止AI滚雪球式埋坑”。每完成一个模块我会让AI同时给模块写两个测试一个正常输入、一个边界输入。道德约束不如机制约束测试不通过绝不进入下一个模块。实测下来这个习惯让最后的联调时间从可能的两三小时压缩到十几分钟。因为问题都被隔离在单测阶段而不是等到所有模块组装好后在一个巨大运行时里找哪一个环节出了错。具体做法很简单每个核心函数导出后在同一个目录下建一个module.test.ts。AI生成代码后立刻运行pnpm test把失败信息回贴给AI让它修到全绿再继续。6. 工业软件护城河到底被撕开了多少冷静聊聊6.1 被撕开的从0到1的门槛过去一个人、一台电脑、一个周末做一个CAD原型基本是天方夜谭。现在AI能做的是把代码生成、三维渲染、草图交互、文件导入导出这些“体力活”压缩到分钟级。这个变化不只是效率提升而是把一类工作的参与门槛从“一个8人开发团队”降到了“一个懂需求的产品经理AI”。这意味着个人开发者现在可以去碰以前想都不敢想的垂直场景3D打印参数化模型生成器、家具设计工具、激光切割排版、橱柜快速建模、建筑概念草模、教育用的三维建模小工具。这些市场对商业软件来说太小但足够养出一个独立开发者或微型创业团队。6.2 没被撕开的精度、标准与生态AI再怎么强也不能靠30分钟生成一个能放进生产流程的STEP文件交换模块。工业级CAD的问题不在“能不能建模”而在“能不能保证每个面之间的间隙小于0.01毫米”“能不能在十万个装配体里实时碰撞检测”“能不能被另一个供应商的软件无缝读取”。这些是几十年的行业标准、客户信任和验证体系积累出来的。STEP/IGES/DXF格式看着是文本规范背后是无数厂商的妥协和兼容性测试。AI可以帮助写解析器、写转换器但它没有能力发明一个标准也没有能力让整个产业链都接受一个新格式。护城河的第二层、第三层需要的是时间不是token。6.3 对个人和创业团队的实际启示与其想着“30天替代SolidWorks”不如换个姿势在垂直场景里做出一个“比现有工具顺手10倍”的小产品。CAD领域最大的机会恰恰在大公司看不上的细分市场面向3D打印的模型修复和参数化定制工具面向特定行业的快速设计模板库面向教育的轻量级三维建模协作工具面向非设计师的“从需求到模型生成器”AI负责“从0到1”的产品原型你负责“从1到10”的行业适配和用户积累。护城河不完全在CAD内核里它可以在垂直工作流、模板库、数据沉淀和服务网络里。这些是AI无法瞬间复制的东西。6.4 我的个人心态这次实验之后我对AI写代码的态度从“好玩”变成了“必须用”。它确实像一个刚毕业、速度极快、但时不时会犯基础错误的初级开发。你不能把整个项目扔给它就撒手不管但如果你愿意花精力拆需求、写验收用例、做架构决策它能顶半个团队。真正的工程师价值正在从“写代码”转移到“定义问题”和“控制质量”上。你说不清你要什么AI给你一堆看似正确但没用的代码你能把需求拆成清晰模块并写好测试AI就能像流水线一样稳定输出。护城河没有消失只是在从“代码层”向“判断力层”转移。最后再分享一个小技巧如果你也想复现这个实验一开始就在项目里建一个docs/notes.md文件把每次给AI的需求、AI生成的方案、运行结果和修复记录都写进去。这看起来是额外工作但30分钟的实验过程中你会来回切换多个功能模块笔记能让你迅速找回上下文也能让你在结束后复盘出哪些决策是你做的、哪些是AI做的。这个能力以后做任何大项目都用得上。