四个月后，我放弃了为 CAD 创建 MCP 服务器，来自哈佛创业团队 CTO 的经验

一支从哈佛走出的创业团队，在 AI+CAD 赛道上撞了墙。

Zhishen Chen（陈同学），是一家 AI 设计工具初创公司 Reer 的 CTO。团队核心成员来自哈佛，带着技术理想，想用 AI 重塑建筑和工业设计流程。

图片来源：Reer 官网

他们瞄准的是 CAD 软件和大语言模型的结合。这个方向听起来很性感：设计师用自然语言描述想法，AI 直接生成 3D 模型。效率革命，降低门槛，听上去是个能改变行业的大故事。

团队选择了 Anthropic 推出的 MCP 协议（模型上下文协议）作为技术路线。这是当时看起来最标准、最有前景的方案。他们做了一个 Rhino MCP 服务器，开源发布。

下载量很快到了 5000 次。数据不错。

但四个月后，这位 CTO 在领英上发了帖子。标题很直接：放弃了。

图片来源：领英

陈同学的复盘毫不留情，直指问题核心。

他们花了两个多月尝试把项目开发成可实际使用的远程协议。测试、迭代、修 bug、优化性能。但越做越发现不对劲。

最后的结论很残酷：MCP 这套协议，根本不适合 CAD。

不是他们能力不行，也不是不够努力，而是技术路线从一开始就选错了。

第一个问题：多实例噩梦。

CAD 软件有个特点——一个文件开一个窗口。设计师可能同时打开好几个项目，每个都是独立的实例。这是行业标准操作。

MCP 呢？它的设计逻辑是服务单个应用的。理论上可以给每个 CAD 实例配一个 MCP 服务器，但管理起来就乱套了。

陈同学用了个形象的比喻："像理清一团意大利面条。"

对创业公司来说，这不只是技术问题，更是成本问题。每多一个实例，就多一份资源消耗。规模一大，服务器成本会直线上升。

第二个问题：单向通信。

MCP 擅长什么？查天气这种事——发个请求，拿个结果，完事。

但 CAD 需要的是持续对话。设计师改个参数，软件要实时反馈。AI 提个建议，软件得马上响应。这是双向的、持续的、交互式的。

虽然 MCP 后来支持了 HTTP 流式传输，但真正的双向交互还差得远。服务器不能主动找客户端说话，会话断了就得重来，交互式更新更是做不到。

这对用户体验是灾难性的。没有设计师愿意每次操作都等半天，然后发现连接断了，之前的工作白做。

第三个问题：延迟翻倍。

加了 MCP 这一层，数据传输路径变长了：请求→MCP 服务器→CAD 软件→MCP 服务器→AI 代理。

如果直接让 AI 调用 CAD 的工具接口呢？路径缩短一半。

对于需要快速迭代的设计工作，这个延迟差距很致命。设计师试一个方案，等两秒。再试一个，又等两秒。一天下来，光等待就浪费了多少时间？

陈同学还提到了其他坑：令牌溢出、CAD 的 API 本来就复杂、安全漏洞一堆。

这篇文章发出后，评论区不少开发者表示"我也踩过这个坑"。

有人指出技术选型的根本问题。一位评论者说，MCP 用错了地方。真正的问题是自然语言、CAD 专用语言和空间理解之间没有桥梁。他建议用 CAD 命令本身来训练语言模型，让 AI 直接"说"CAD 的话。这个思路很有意思。不是让 AI 学会控制软件，而是让 AI 学会软件的语言。

有人选择了极简方案。他把 MCP 工具精简到只剩三个——查看、查询、修改。结果准确率反而提高了。他的逻辑很清楚：与其暴露一堆复杂工具让 AI 手足无措，不如做好最核心的功能。

有人吐槽技术栈。直指 MCP 的设计缺陷：不基于 WebSocket。这个选择让很多本该简单的事变复杂了。如果用 WebSocket，双向通信、实时更新这些问题可能都不是问题。

也有人在分享了自己的踩坑经验。一位工程师用 YOLO 做检测、OCR 提取数据，想从机械图纸里自动抓尺寸。失败了。他发现没有开源库能像人类工程师那样理解工程图纸。

整件事暴露了一个根本问题：通用协议 vs 专业领域。

MCP 是 Anthropic 推出的，目标是让任何应用都能和大语言模型对接。理想很好，但现实很骨感。

CAD 不是普通应用。它有专业的术语体系、复杂的操作流程、实时的交互需求、多实例的使用场景。这些特性不是加一层协议就能解决的。

2 年前，Cursor 创始人也放弃做 CAD+AI 的项目。

第一个打击是数据量。他说，现在的代码模型可能用了上万亿个 token 训练，而 CAD 呢？就算把全世界的 CAD 数据都搜刮来，最多也就 100 亿个 token。这种数量级的差距，根本不是算法优化能弥补的。这根本不够训练出一个有用的模型。

第二个更致命的发现是空间推理能力。创始人的比喻很形象说：你要用 CAD 设计一张桌子，得先画个长方形，然后垂直拉伸变成立体的。模型必须理解这个过程，在脑中想象这个 3D 结构。结果连 GPT-4 都经常搞砸。而 CAD 设计恰恰需要模型在脑子里构建和操作 3D 结构，这正是当前语言模型的死穴。

最后一个问题是工程实现。即使有了好模型，给这些传统 CAD 软件开发插件也是噩梦。即使你有了一个不错的模型，要真正推广并开发出一个好用的插件也是相当困难的，更合理的方法可能是彻底抛弃现在的 CAD 使用方式。

有时候，最勇敢的决定不是坚持，而是承认选错了战场。最后我想表达的是，没有绝对正确或完全走不通的技术路径，只是合适的时机，恰好的场景，用好了当下的技术优势。

期待未来的新进展。

（完）