在聊天里画架构图：OpenClaw + CodePic MCP 实战指南

引言

跟 AI 聊完系统设计，还要手动打开白板把内容重新画一遍——这个切换动作不大，但它每次都打断思路。OpenClaw 挂上 CodePic MCP 之后，这步消失了：你在 Telegram 或 Discord 里描述需求，AI 直接调用 CodePic 画好图，返回链接给你。

OpenClaw 是什么

OpenClaw 可通过网关连接聊天渠道与代理工具。本地运行网关不代表所有数据留在本地：聊天消息、模型请求和远程 CodePic 操作可能经过不同服务。

安装要求请查看当前入门文档。本文重点是 CodePic 连接，不假设所有渠道、模型和运行环境都使用同一配置。

配置 CodePic MCP

当前 OpenClaw 官方说明把托管的对外服务放在 mcp.servers 下，旧文顶层 mcpServers 示例不再作为当前配置指引。

1. 登录 CodePic，在API Key 设置创建密钥；不要贴到聊天、截图或共享仓库。
2. 在 OpenClaw Control UI 的 Settings → MCP 添加 Streamable HTTP 服务，地址为 https://codepic.cc/api/mcp/mcp。通过该版本支持的密钥或环境机制，在局部配置编辑器提供 Authorization bearer 请求头。
3. 检查已保存配置，再探测实际能力。确认目标代理会话能发现 CodePic 工具，保存地址本身不能证明连接成功。
4. 文档变更工具仍受客户端工具策略控制。先用不敏感示例测试，检查返回文档，再用于真实讨论。

参见官方连接指南与配置参考。界面和运行环境投射可能随版本变化，本文不声称已对读者本机环境进行端到端验证。

实际操作：在消息里画图

场景 1：从零画一张微服务架构图

你在做技术评审，需要一张系统架构图，不想手动画。

在 Telegram 里发给 AI：

帮我用 CodePic 画一个电商微服务架构图。

组件：
- 客户端：Web、iOS App、Android App
- API 网关：统一入口，负责鉴权和路由
- 微服务层：用户服务、商品服务、订单服务、支付服务
- 消息队列：Kafka，连接订单服务和支付服务
- 数据层：PostgreSQL（用户/订单）、Redis（缓存）、Elasticsearch（商品搜索）

用箭头表示调用方向，Kafka 用虚线箭头表示异步。支付服务和订单服务之间的连接加粗标注。

AI 调用 CodePic 的 create_diagram，直接生成图表，回复你一个 CodePic 链接。打开链接就是画好的图。

不满意，接着说：

把 Elasticsearch 换成 Meilisearch，商品服务旁边加一个图片存储（S3），两者之间用虚线连接。

AI 调用 update_diagram 改好，再发新链接。整个过程没有打开 CodePic，没有拖拽任何元素。

场景 2：在已有图上迭代修改

你已经有一张订单处理流程图，团队讨论后决定加一层缓存，同时补一个失败重试机制。

在 Discord 里：

在当前的订单处理图上做两处修改：

1. 加缓存层：Redis 缓存放在"查询订单"步骤前，先查缓存，命中直接返回，未命中再查数据库，查完写入缓存。用虚线框标出缓存组件。

2. 加重试机制：支付失败时，加一个"重试队列"节点，最多重试 3 次，超过后走"人工处理"分支。

主流程保持不变，只补这两部分。

AI 拿到图表 ID，调用 update_diagram，在原图上加入这两个部分，保留原有结构。改完发你更新后的链接。

关键点： 用 update_diagram 时，描述里要明确说"保持原有流程不变，只改 X 部分"。AI 默认会在原图基础上操作，但加这句话能减少误改的概率。

适合谁，怎么开始

适合：

• 个人开发者，机器长期开着，需要在电脑端随时调用 AI + 画图
• 技术团队，用 Discord/Telegram 协作，需要在对话里直接产出可视化图表

不适合：

• 需要多人实时协作编辑图表的场景（CodePic 当前不支持协作）
• 需要像素级精确排版的设计稿（用专业设计工具）

开始的三步：

1. 安装 OpenClaw，接入 Telegram（配置最快，5 分钟内跑通）
2. 获取 CodePic API 密钥，写入 ~/.openclaw/openclaw.json
3. 重启 Gateway，在 Telegram 里发"帮我用 CodePic 画个流程图"测试

相关文档：

• OpenClaw 安装：docs.openclaw.ai
• CodePic MCP 配置：codepic.cc/zh/blog/codepic-mcp-launch

常见问题

当前 OpenClaw 应在哪里配置 CodePic？

当前官方说明将托管的对外 MCP 定义放在 mcp.servers 下；按安装版本核对，并验证实际工具发现。

网关本地托管就代表图表数据全部留在本地吗？

不代表。云模型、聊天服务和远程 MCP 服务都可能接收处理所需信息，应逐个检查实际链路。

如何稳妥修改已有图？

先确定文档，用 get_diagram 读取当前状态，提出范围明确的修改，再查看结果后分享。

分层排查连接

分别检查配置、连通、认证和工具策略。设置中出现服务只证明已保存定义，探测成功只证明能响应；实际会话中的文档变更还需正确认证与权限。

工具缺失时，确认目标运行环境收到服务且过滤规则没有排除工具。发现工具成功、创建失败时，应看认证和授权结果，不反复重装；复制日志和截图时去掉密钥。

返回文档链接后，核对组件、关系和方向，工具调用成功不证明架构表达正确。小修改复用原文档标识，先读取当前状态，再提出“在 API 与 worker 之间加一个队列，其他连接保留”这样有边界的要求。随后检查标签、方向和删除内容，不假设聊天自动撤销上次写入。

最后测试真正使用的聊天渠道，Control UI 成功不证明所有消息会话的工具、身份或批准方式相同；对外分享前保留人工检查。

共享聊天的受众可能与私人会话不同，发送查看链接前确认文档和读者，并区分审核草稿与获批架构依据。