用 AI 真正"画"出你的图表：CodePic MCP 深度使用指南
引言
上周 CodePic 上线了 MCP 支持，你可能看到了公告。但"能用"和"怎么用好"是两码事。
在 MCP 出现之前，即使你在 AI 对话里详细描述了一个系统架构，AI 也只能给你 Mermaid 代码或者纯文本方案。你还是要手动复制、粘贴、调试。现在不一样了——AI 可以直接"看到"CodePic，调用它的工具生成、编辑图表，整个过程就像在对话里完成一样。
MCP（Model Context Protocol）让 AI 能直接调用 CodePic 的工具，而不是只能输出代码。
但这里有个关键点：MCP 改变的不是 AI 的能力，而是你描述需求的方式。
用错了提示词，即使有 MCP 也白搭。用对了，你会发现原来画图这件事可以这么流畅。这篇文章就是教你怎么用对。
一、接入回顾
假设你已经在 Cursor 或 Claude Desktop 上配置好了 CodePic MCP（没有的话看这篇）。现在的状态是：你的 AI 可以访问 CodePic 的 4 个核心工具。
接下来就是如何用好它们。
二、描述需求的艺术
这是最容易被忽视的部分。很多人抱怨"AI 画不好我的图"，其实问题在于描述不够精准。
看这个对比：
❌ 模糊版本：
"给我画一个电商系统的架构图"
✅ 精准版本：
"画一个电商系统架构图，包括：客户端层（Web、App），网关和认证层，核心服务层（用户服务、商品服务、订单服务、支付服务），数据层（MySQL、Redis、Elasticsearch），使用箭头表示服务间调用关系。重点标注支付服务和订单服务的交互。"
差别在于：
- 具体的组件清单 — AI 知道该画什么
- 层级关系 — AI 知道怎么组织
- 交互重点 — AI 知道强调什么
这不是 CodePic 特有的问题，是 AI 协作的通用法则。但在图表领域特别明显。
推荐的提示词结构：
1. 明确图表类型：系统架构图 / 流程图 / 思维导图 / 时序图
2. 列举主要元素：用 bullet points 或编号
3. 描述关系：哪些元素相连、什么关系（调用、继承、包含）
4. 强调重点：哪部分最重要、需要特殊标注
5. 补充约束：尺寸偏好、配色要求（可选）
实际完整例子：
我要画一个电商推荐系统的架构图。
主要组件：
- 用户端：Web 应用、Mobile App
- 推荐引擎：实时推荐、离线推荐
- 特征处理服务：用户特征、商品特征、上下文特征
- ML 模型服务：协同过滤模型、深度学习模型
- 数据存储：特征库（Redis）、模型库（S3）、用户行为数据库（MySQL）
- 日志系统：行为日志、推荐日志
用户交互流程：
用户打开APP → 触发推荐引擎 → 特征处理服务提取特征 → 调用ML模型服务进行推理 → 返回推荐结果 → 用户行为记录到日志系统
重点强调：特征处理和模型推理之间的交互是系统的性能瓶颈，需要用粗箭头标注。
用颜色区分：用户端（蓝色）、核心服务（绿色）、存储层（灰色）。
看到没有？这个例子里，前 3 个框架步骤都体现了，顺序清晰，AI 能理解，你也能看到自己的需求被"翻译"成了什么。这就是高质量提示词的样子。
**实际例子（对应上面的框架）：**
"我要画一个电商推荐系统的架构图。 包含：用户端（Web/App）、推荐引擎、特征处理服务、ML 模型服务、数据存储。 用户点击商品 → 触发推荐引擎 → 特征处理 → 模型推理 → 返回结果。 重点标注特征处理和模型推理的交互，因为这是系统瓶颈。"
## 三、4 个工具的实战玩法
### 1. list_templates
列出可用的模板。如果你不知道从哪开始，先看看有什么现成的。
AI 提示词例子： "用 list_templates 看看有哪些流程图模板，然后推荐一个最适合用户流程梳理的"
### 2. create_from_template
基于模板快速创建。这是快速入门的最好方式。
实战例子：
"用电商流程图模板创建一个图，然后改成这样的用户购买流程： 用户打开APP → 浏览商品 → 选择商品 → 加入购物车 → 进入结账 → 选择地址 → 选择支付方式 → 确认支付 → 订单完成"
AI 会从模板开始，再根据你的流程调整。比从头开始快多了。
### 3. create_diagram
从零开始创建图表。适合模板里没有的场景。
实战例子：
"创建一个微服务架构图，包括：
- 用户界面层：Web、Mobile
- API 网关层：Spring Cloud Gateway
- 微服务层：User Service、Product Service、Order Service、Payment Service
- 数据层：PostgreSQL、Redis、Kafka 用箭头显示数据流向，虚线表示异步消息"
### 4. update_diagram
在已有的图上修改和扩展。这是迭代的关键。
实战例子：
原图已经有了系统主体，现在你说： "在 Order Service 和 Payment Service 之间加一个 Saga 编排器，用虚线箭头表示异步调用流程"
或者： "把数据层的 Redis 换成 Elasticsearch，并添加一个消息队列组件"
update_diagram 的强大之处在于，你不用重新描述整个图，只需要说"改哪里"。
## 四、3 个真实场景
### 场景 1：用自然语言画系统架构
你在设计一个新的数据处理系统，想快速出个架构图来评审。
**你的提示词：**
给我创建一个数据处理管道的架构图：
系统流程：
- 数据源层：数据库、API、文件上传
- 接入层：Kafka Topic（分离不同数据源）
- 处理层：
- 实时处理：Spark Streaming
- 批量处理：Spark Batch
- 存储层：
- 热数据：Elasticsearch
- 冷数据：S3
- 应用层：BI Dashboard、报表系统、数据科学平台
用颜色区分层级，箭头表示数据流向
**结果：** AI 会直接生成可视化的架构图。不用你手工调整 Mermaid 代码，可以在 CodePic 里直接看到，不满意再让 AI 改。
### 场景 2：从需求文档到流程图
产品经理写了一份用户登录流程的需求文档，你需要用流程图可视化它。
**需求文档原文：**
用户登录流程：
- 用户输入邮箱和密码
- 系统校验邮箱格式和密码强度
- 如果校验失败，返回错误提示
- 如果校验成功，检查用户是否存在
- 用户不存在则创建新账户
- 如果用户存在且启用了 2FA，发送验证码
- 用户输入验证码
- 校验验证码，成功则颁发 token，失败则重试（最多 3 次）
- 登录成功，重定向到首页
**你的提示词：**
根据这个需求文档，用 CodePic 创建一个标准的流程图： [粘贴需求文档]
用菱形表示决策点，矩形表示操作，确保所有分支都清晰可见
**结果：** AI 把需求文档自动转成可视化流程图，所有的分支逻辑一目了然。改需求？再改一遍就行。
### 场景 3：在图上迭代添加细节
你已经有了一个初步的系统设计图，现在要在上面加入错误处理和监控。
**你的提示词：**
在当前的订单处理图上，加入以下内容：
- 在支付失败流程上加一个"重试队列"组件
- 给所有服务加一个"监控"连接，指向中央 Observability 平台
- 在订单数据库旁边加一个"日志系统"
- 用虚线表示监控和日志的连接
保持原有的主流程不变，只是补充这些非核心路径
**结果：** AI 理解了你的意图，保留了原图的核心，只在指定位置加入新内容。迭代变得像聊天一样自然。
## 五、AI 画不好的地方
现阶段，CodePic MCP 有几个已知的局限：
**难题 1：超复杂的依赖关系**
如果你的系统有 20+ 个服务，彼此之间有复杂的相互调用，AI 可能会把图画得很拥挤。这时候应该分层或分多个图。
**难题 2：精确的布局要求**
如果你需要特定的组件位置（比如"这个元素必须在左边"），AI 可能做不到。CodePic 的自动布局有局限。
**难题 3：非标准的图表类型**
你如果想画一个完全自定义的、混合了多种符号的图表，AI 可能会困惑。标准的架构图、流程图、思维导图是最安全的。
**出错了怎么办？**
AI 有时候会漏掉某个元素或画错关系。解决办法很简单——直接指出问题：
"刚才漏了一个缓存层，加在数据库和应用服务之间"
或者
"支付服务不应该直接连接用户数据库，中间要加个 API"
AI 会迅速修正。你不需要描述整个图，只需要指出差异。
## 六、最后：去试试吧
如果你还没尝试过用 AI 直接在 CodePic 里画图，现在是最好的时机。去 [codepic.cc](https://codepic.cc) 连上你的 Cursor 或 Claude Desktop，说出你想要的图，看 AI 怎么"理解"你的想法。
第一次可能不完美，但迭代两三次，你会惊讶地发现——原来画图可以这么快。
**核心要点总结：**
- 用精准的描述换来精准的图表
- 从模板开始比从零开始快
- update_diagram 是迭代的关键，改一处就说一处
- 当 AI 出错时，直接纠正，不用重新来
现在就去试。