惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
MyScale Blog
MyScale Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
人人都是产品经理
人人都是产品经理
C
Check Point Blog
宝玉的分享
宝玉的分享
B
Blog RSS Feed
博客园 - 三生石上(FineUI控件)
量子位
Martin Fowler
Martin Fowler
酷 壳 – CoolShell
酷 壳 – CoolShell
Jina AI
Jina AI
IT之家
IT之家
阮一峰的网络日志
阮一峰的网络日志
博客园 - 叶小钗
J
Java Code Geeks
The Cloudflare Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
腾讯CDC
P
Proofpoint News Feed
美团技术团队
H
Help Net Security
B
Blog
博客园_首页

少数派

派早报:Google 发布 Fitbit Air 等 - 少数派 「新人报到」確認需求,再開始 - 少数派 从 SOLO 独立开发者社区,我看到了越来越多开发者开始做自己的产品 - 少数派 我怎么管理那些"不常做,但总会忘"的生活事项 - 少数派 人形机器人量产元年,数据才是具身智能的“生死线” - 少数派 BuhoLaunchpad 高度还原 Mac 启动台:开发历程与思考 - 少数派 五年陪伴依然不舍,DIY 换壳后让罗技 MX Master 3 继续服役 - 少数派 新玩意 240|少数派的编辑们最近买了啥? - 少数派 一日一技|为什么你应该关闭 iOS 的键盘声音 - 少数派 我做了个插件和 Skills,一键提取任何网站的设计规范 Design.md - 少数派 住在三四线城市的你,该开始录播客了 - 少数派 甘南秘境,大白高国 - 少数派 AI的审美:谁让把我变成川内倫子 - 少数派 返工怎能不烦恼,打工人片单总有一部是你的「嘴替」 - 少数派 为了让「上厕所」更健康,我做了一个小工具 - 少数派 AI + Skill,能够让生成的文章去除 AI 味吗? - 少数派 新玩意|韶音OpenDots ONE 耳夹式耳机 - 少数派 《美满》| 在每一个春天的晚上相爱(362) - 少数派 新玩意|优篮子 PS01 MagSnap 磁吸支架 - 少数派 自我整合手记 | 我开始早睡了:用稳定规则,为自由托底 - 少数派 用龙虾(OpenClaw)两个多月,我最深的12个体会 - 少数派 听歌时间到,12 张你可能错过的 2025 华语乐坛好专辑 - 少数派 承诺能追吗 - 少数派 macOS 26启动台没了? 我做了个不一样的App启动器 - Keboard - 少数派 《四海为家的人》| INTJ对话INTJ(361) - 少数派 你发过的那些黑历史,是时候一次清干净了 - 少数派 新玩意:安安静静玩,越玩越专注:计客密码机 - 少数派 iPad 用户首次体验 Android 平板:vivo Pad6 Pro - 少数派 数据逻辑强 - 少数派 极北行+ | 一路向北,探访日本至北之地 | 001 - 少数派
四个月后,我放弃了为CAD创建MCP服务器,来自哈佛创业团队 - ...
2025-10-23 · via 少数派

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

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

期待未来的新进展。

(完)