最近 MCP 在 AI 工具里出现的频率越来越高。像 Cursor、Pixso、墨刀这些工具都在陆续接入或推出 MCP Server，现在已经有越来越多设计、开发和协作类的产品加入进来了。这东西最早是开发者圈子讨论得多，但现在，
它已经开始出现在产品经理和设计师的工作流里了
。
设计师其实就关心几个实在的问题：这东西能读懂真的需求和设计稿吗？生成的界面拿过来能不能直接改？还有，它到底能不能让产品、设计、研发之间少扯几轮皮？
先给个结论：MCP 不会取代产品设计本身，但它会改变 AI 参与设计的方式。以前 AI 在大多数人手里就是个聊天窗口，现在不一样了，它能
直接挂到设计工具里
，读取项目里的信息、调用生成能力，再把结果直接塞回工作流里。
MCP 全称是 Model Context Protocol，模型上下文协议。按官方的说法，它就是一套标准，
让 AI 应用能和外部系统互相打通
。AI 拿到授权之后，就能连上各种数据源、工具和工作流，去读信息，或者直接执行操作。
我们平时用大模型，它能看到的就是对话框里丢进去的文字、图片和文件。它再能聊，要是连不上你用的那些工具，它根本不知道你的项目里有哪些页面，更别指望它直接在 Figma 或者 Pixso 里帮你干活。但接上 MCP 之后，AI 客户端就能自动发现外部工具有什么能力，比如读取组件和页面结构、生成界面、创建设计稿，甚至直接输出 PRD。
Cursor 接 MCP，主要是想
让它的 AI Agent 能读到代码仓库之外的数据和工具
。Pixso MCP Server 则更偏向设计和开发的协作。它不光能把布局、组件、变量这些信息喂给 AI，还支持 Agent 在画布里直接创建或修改 Frame、组件、变量和自动布局。
这么看下来，MCP 在设计领域早就不是“让 AI 看懂设计稿”那么简单了。它现在同时在干两件事：一是把设计背景信息喂给 AI，让它生成的代码更贴合实际；二是反过来，允许 AI 直接调用设计工具，把生成的东西写回设计文件里。设计稿不再是交付给研发的一张图，它本身已经
变成一个 AI 可以读取、可以调用、也可以直接修改的项目上下文
。
现在的产品团队，工具倒是不缺。需求放文档里，流程画在白板上，原型有专门的工具，视觉稿有设计软件，最后再交给研发写成代码。每个工具都能搞定自己那一环，但问题是信息在各个工具之间来回倒腾的时候，经常就断了。产品经理写完了需求，还得跑去跟设计师口头补充一遍；设计做完了，研发拿到手又得重新理解一遍页面逻辑和组件关系。需求一改，文档、原型、设计稿、开发任务全都得跟着动。
大模型出来以后，
也没把这个问题彻底解决
。你可以让通用大模型帮你写 PRD、画页面、写前端代码，但这些东西还是散落在各个聊天窗口和工具里，团队最后只是又多了一堆文件，流程该卡还是卡。
MCP 要解决的，正是
AI 和这些专业工具之间脱节的问题
。往后看，一条比较顺的流程大概是这样的：产品经理把需求丢出来，AI 帮着分析用户任务和页面结构，然后通过 MCP 直接调用设计工具先把界面搭出来，团队评审修改完，再把确认后的设计上下文交给研发去实现。
这个环节的价值，不在于让 AI 一句话搞定整个设计，而是先帮你把脑子里那个模糊的想法，落地成一个能打开、能讨论、也能接着改的具体东西。有了这个东西，团队就不用对着几行文字去脑补页面长什么样，可以直观地判断：入口会不会太深、信息是不是堆太多了、常用操作好不好找。
墨刀 AI 和墨刀 MCP 干的活儿不一样。墨刀 AI 主要负责生成，比如原型、React 应用和 PRD；墨刀 MCP 负责连接，让这些生成能力能进到 Cursor、Codex 这类支持 MCP 的 AI 工作环境里。
目前墨刀 MCP 对外开放了四类工具：
通用生成、HTML 原型生成、React 应用生成和 PRD 文档生成
。配置和授权完成之后，你直接在 AI 客户端里提需求，客户端会去调用墨刀 AI。生成的结果会返回预览地址、任务地址，以及具体的 HTML、React 或 Markdown 内容，同时也会在墨刀里创建对应的文件，方便后续查看、分享和继续修改。
举个例子，你可以在 Cursor 里直接说：“用墨刀 AI 为中小型销售团队生成一个 CRM 客户管理后台，包含工作台、客户列表、客户详情和销售数据看板。客户列表要支持搜索、筛选、负责人切换和批量操作。”如果需求还不太明确，也可以先让 AI 梳理一下页面结构和关键任务，再调用 MCP 去生成原型。第一版出来之后，你可以继续让它补空状态、调整信息层级、加上权限差异，或者再生成一份配套的 PRD。
Pixso MCP 和墨刀 MCP 都基于 MCP 协议
，但现阶段侧重点不太一样：
Pixso MCP 目前主要支持读取设计稿的上下文、把设计转成代码，以及在画布上做操作；
墨刀 MCP 现阶段更偏重把产品想法快速落地成 PRD、HTML 原型或者 React 应用。
如果你已经有完整的设计稿，想让 AI 理解里面的组件和布局来辅助开发，那 Pixso MCP 可能更合适；如果你只有一段需求描述，想赶紧看到可以评审的界面和文档，墨刀 MCP 的路径会更直接。这两者不一定非得二选一，出现在同一条产研流程里也很正常。
目前来看，MCP 比较适合那些目标明确、边界清楚的任务。比如快速出第一版原型、整理 PRD 文档、批量生成结构相似的页面、提取组件和布局信息，或者把设计背景丢给代码生成工具。
但要说到
业务决策和最终的体验判断
，这就不是它能替人做的了。让 AI 把会员体系的页面梳理一遍，它干得来；可你要让它替团队决定积分规则怎么定才不影响利润，它就完全没谱了。同样，生成一个结构完整的后台对它来说不算难，但只凭一句话需求，你让它判断哪种信息层级用户用着最顺手，这基本是强人所难。
品牌视觉、复杂的业务逻辑、无障碍设计，还有隐私合规，以及支付、医疗、金融这类高风险流程，在人工确认之前，最好别让 AI 全权接手。MCP 让 AI 能干的事情变多了，反过来，团队在
权限管理、数据安全和操作范围
上，也得花更多心思去把控。
对设计师来说，比“画得快”更重要的，可能是你能不能把任务描述清楚、给 AI 的上下文够不够充分，以及最后能不能判断生成的东西到底有没有解决问题。页面是秒出来了，但产品方向对吗？工具是能调用了，但每一次调用都有必要吗？这些才更值得琢磨。
MCP 对产品设计的影响，不会是某天突然冒出一个“一键完成所有设计”的神器。更可能的变化是，AI 会慢慢融入到团队已经在用的环境里。你在 Cursor 里写代码的时候，它能通过 Pixso MCP 顺手拿到设计上下文，也能在需要的时候，通过墨刀 MCP 把模糊的需求转化成 PRD、原型或者 React 应用。
