最近一段时间，我开始做一了个小项目，暂时叫 MechCAD。

它想解决的问题很简单：我画一张手绘机械草图，上传到网页里，再写一句这个零件大概是干什么用的，然后系统帮我生成一个 3D 机械模型，最好还能导出 STEP、STL、OBJ 这些文件。

听上去像是“图片识别 + 代码生成”，但真正做下来以后，我发现这个问题没那么简单。机械建模不是画一个看起来差不多的东西。它要处理尺寸、基准、孔、槽、台阶、壁厚、倒角、这些东西。AI 如果只是凭感觉画一个差不多的模型，对工程来说其实用处不大。

这个项目现在还只是原型，但它已经从一个很粗糙的 demo，慢慢变成了一个有工程流程的 AI CAD 工作台。所以我把这段开发过程整理一下，也算是给自己留个记录。

首先需要做的事模型选型，我初步的方案是强vl+agent 建模，于是选用了qwen-vl-235b，他的空间能力算是开源里最强的了，建模操作选用了minimax（后来发现gpt两端干的都更好，当然了，贵有贵的道理）

v0我做的是 Gradio 版本。Gradio 上手快，适合验证想法。第一版流程大概是：用户上传手绘图，OpenCV 做一点图像预处理，然后视觉模型读图，后端模型生成 Build123d 代码，本地执行代码，最后生成 STEP 文件和 3D 预览。

这一版很快就跑通了。能上传图，能生成模型，也能下载文件。刚开始看到模型出来的时候还是挺兴奋的，至少说明这个方向不是完全没戏。

这是大致架构。

但多试几次以后，问题也很明显。

最大的问题是，最早我是让 AI 直接写 Build123d 的 Python 代码。这个方式看起来最灵活，但实际上很不稳定。AI 会写错 API 参数，会把建模顺序搞乱，也会在尺寸不完整的时候硬生成。有时候代码直接报错，有时候代码能跑，但是模型和图纸并不一致。

比如我一直拿一张发动机外壳的草图测试。系统有一次把管子画出来了，但是槽没有画。这个问题很典型，因为机械零件里真正重要的往往不是主体，而是那些局部特征。管子主体画对了，但槽没了，这个零件就还是错的。

当然还体现出模型的本身能力也很重要，至少minimax比gpt的多模态能力差太多。

后来我开始反思：为什么 SolidWorks 这种 CAD 软件比较稳定？它不是一次性凭空生成一个复杂三维形状，而是一步一步建模。先选基准面，再画草图，再拉伸或旋转生成主基体，然后切孔、切槽、做台阶，最后再做倒角、圆角、阵列。

也就是说，真正可靠的 CAD 建模背后是一棵特征树。

所以我把项目思路改了。不再让 AI 直接写任意 Python，而是让 AI 输出一个类似 SolidWorks 特征树的 JSON。我把它叫做 FeaturePlan。

AI 现在要做的不是“直接造模型”，而是先做工程规划。它要判断这个零件大概是什么类型，是管件、板件、法兰，还是支架；然后确定主基体，比如空心圆柱、普通圆柱、盒体；接着再按顺序列出孔、槽、台阶、凸台、阵列、倒角这些特征。

每个特征都必须带尺寸、位置、依赖关系和证据。缺尺寸就不能建，缺定位也不能建，尺寸冲突也不能建

这里我选择 Build123d 作为早期 CAD 后端，主要是因为它适合快速验证。Build123d 官方文档里把它定义为一个基于 Python 的参数化 BREP CAD 框架，底层基于 Open Cascade，能用于 3D 打印、CNC、激光切割等制造场景，也能导出到常见 CAD 工具链里。它的设计教程也强调从视图分析、对称性、原点选择、2D 截面、拉伸、旋转这些步骤开始建模，这和我想模仿的“工程师式建模流程”比较一致。

模型选择上，我一开始采用了双模型思路：前面一个视觉模型读图，后面一个规划模型生成 FeaturePlan。

视觉模型最早考虑 Qwen-VL 这一类模型，原因很现实：它对中文环境比较友好，价格也相对可控。根据阿里云 Model Studio 当前公开价格，国际版 qwen-vl-plus 是输入 $0.21 / 100 万 tokens，输出 $0.63 / 100 万 tokens；qwen-vl-max 是输入 $0.8 / 100 万 tokens，输出 $3.2 / 100 万 tokens。对于早期 MVP 来说，我更倾向先用 plus 级别模型做读图，因为一次草图分析不应该太贵，预算要能支撑几十个真实用户测试。

后端规划模型一开始试过 MiniMax M3。选择它的原因也不是玄学，而是它适合处理长上下文和代码/结构化输出。MiniMax 官方介绍里提到 M3 支持 1M 上下文和原生多模态理解，也支持 thinking 开关。它的 Token Plan 页面也明确把 M3、图像、语音等放在共享额度里，Plus 年付计划标称大约每月 17 亿 M3 tokens。对我这个项目来说，规划模型需要吃进去视觉 JSON、用户描述、工程规则、FeaturePlan schema，还要输出结构化 JSON，所以长上下文和代码能力比较重要。

不过后来我没有把项目锁死在 Qwen 和 MiniMax 上。因为实际测试中我发现，不同模型在不同环节表现差异很大。有的模型读图强，有的模型结构化输出更稳，有的模型便宜但容易漏特征。所以我把代码改成了“前端视觉模型”和“后端规划模型”两个角色，不再绑定具体厂商。只要兼容 OpenAI 或 Anthropic 风格接口，理论上都可以配置。

当然，光看模型价格没意义，关键还是生成质量。实际测试下来，我最大的感受是：模型能力不是唯一瓶颈，流程设计更重要。如果让 AI 一次性写完整 CAD 代码，强模型也会犯错；如果把任务拆成读图、规划、校验、执行、提问几个阶段，中等模型也可能做得更稳。

模型能力决定下限，提示词工程提升上限

所以项目里我加了严格模式和智能模式。

严格模式下，只使用图纸上明确标注的尺寸，或者用户明确输入的尺寸。缺尺寸就提问，不允许 AI 自己猜。这个模式更适合工程图纸。

智能模式下，AI 可以提出建议，比如壁厚可能偏薄、孔径接近 M6、槽深需要确认。但这些建议默认不会直接写进可执行模型，必须用户确认后才生效。

后来 Gradio 版本也逐渐不够用了。因为我想做的不只是一个上传生成工具，而是一个可以迭代修改的 AI CAD 工作台。用户应该能看到特征树，点击某个特征修改尺寸，也应该能用自然语言说“把中心孔改成 12mm”“删除顶部槽”“新增 4 个 M6 孔”。

这些交互用 Gradio 做起来比较别扭，所以我把项目切到了新架构。

现在前端是 React + TypeScript + Vite + Three.js，后端是 FastAPI + WebSocket，CAD 计算放在独立 worker 里。FastAPI 官方本身就支持 WebSocket，可以在前后端之间推送状态，这很适合这种“上传、读图、规划、校验、建模、导出”的长流程任务。前端用 React 和 Three.js，则是为了以后能做更像 CAD IDE 的界面，比如特征树、属性面板、3D 视口联动。

现在界面大概分成几个区域：左边是输入、图片上传、模式选择、模型配置和特征树；中间是 3D 预览；右边是属性面板；底部是待确认问题、AI 对话修改、日志和 FeaturePlan JSON。

最近调试的时候，我也遇到了一些很实际的问题。

一个是 3D 预览空白。最开始我以为是 Three.js 的问题，后来发现很多时候是后端根本没成功生成 STL 或 OBJ。于是我把报告改得更明确：CAD worker 成功还是失败，产物有没有生成，哪些特征跳过，跳过原因是什么。这样用户至少知道问题发生在哪里。

另一个是 Build123d 报错。一开始我怀疑是模型能力问题，后来发现不完全是。很多错误来自任务拆分不清楚。比如 AI 想开槽，但槽宽不明；想切孔，但孔中心没有定位；想做环槽，但不知道槽底外径。后来改成 FeaturePlan 以后，这些不确定项会变成问题，而不是直接变成错误模型。

还有一个问题是中文乱码。有些文件在开发中出现了错误编码，导致页面、日志、测试文案里出现乱码。这个问题很影响体验，因为我本来就要回答工程参数，如果问题本身都看不懂（ai提问很入机），那整个交互就断了。后来我把前端文案、后端日志、AI 提示词调用层和测试断言都清理了一遍。

目前这个项目已经有一些基本验证数据。

后端单元测试现在是 51 个用例通过，覆盖 FeaturePlan 校验、API、session、CAD worker、事件系统等。前端测试是 7 个用例通过，主要覆盖属性面板的尺寸编辑、确认状态和保存逻辑。前端生产构建也能通过。这个测试规模不算大，但至少说明现在的主流程不是完全靠手工试出来的。

实际功能上，如果输入：

“外径 50mm，内径 30mm，长度 80mm 的管件”

系统可以识别为管件，并生成空心圆柱模型，CAD worker 能正常导出产物。

如果输入：

“管子带顶部槽”

系统不会直接瞎建，而是识别成管件，同时把缺失项列出来：管件主尺寸缺外径、内径、长度；环槽缺槽宽、槽底外径或槽深，还缺端面定位。

所以 MechCAD 后面的方向，不是追求“AI 一次性自动完成所有 CAD 工作”，而是做一个能交流、能提问、能受控建模的辅助工具。

接下来我准备继续做几件事。

第一是多拿真实手绘图测试。现在样例还太少，主要测试了管件和板件。后面要多测法兰、支架、轴套、孔阵列、矩形槽、台阶轴这些常见结构。

第二是继续优化提问方式与提示词工程。现在系统已经能问问题，但有些问题还偏程序化。比如内部需要z平面，但不应该直接问用户zstart是多少，而应该问“槽从左端还是右端开始？距离端面多少毫米？”这类问题必须让普通人能看懂。

第三是做增量修改。比如我说“把槽宽改成 10mm”“删除顶部槽”“新增 4 个 M6 孔”，系统应该只修改对应特征，而不是整棵树重新生成。

第四是继续增强 3D 交互。现在只是基础预览，后面希望能点击模型特征、联动特征树、高亮尺寸、显示简单测量。

总的来说，MechCAD 现在还只是一个原型，离真正可用的 CAD 软件还差很远。但它已经从最初的“AI 写 CAD 代码 demo”，慢慢变成了一个有工程流程的 AI CAD IDE 雏形。

我觉得这个方向是值得继续做的。后续会以这个为主要优化：ai看懂了什么，ai没看懂什么，ai需要你确认什么。这样它才可能从一个好玩的 demo，慢慢变成一个真正有用的工具。

另外我接下来想做的一个细化方向是适配固体发动机的二维图转3d