一支从哈佛走出的创业团队，在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 使用方式。

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

期待未来的新进展。

（完）