Excalidraw：当手绘白板遇上AI，技术图一键生成的实践之路

在一次远程架构评审会议中，团队正为如何快速呈现微服务调用链而发愁。有人提议：“要不我们画个图？”——话音刚落，另一人苦笑：“又要开Visio？等我找模板、对齐元素、调整样式……半小时就没了。”这样的场景，在技术团队中屡见不鲜。

正是这类高频痛点，催生了像Excalidraw这样的轻量级白板工具的崛起。它不追求工业级绘图软件的严谨规整，反而以“画得像草稿”为荣。更令人惊喜的是，随着大模型技术的普及，如今只需一句话描述，就能自动生成一张结构清晰的技术架构图——这一切，都发生在浏览器里，无需安装任何客户端。

这背后，是一场关于“表达效率”的静默革命。

Excalidraw 的本质，是一个运行在浏览器中的虚拟画布。它用 TypeScript 和 React 构建，所有图形通过 Canvas 或 SVG 渲染，数据则以 JSON 格式存储。听起来平平无奇？但它的魔力在于那些“反常规”的设计选择。

比如，当你拖出一个矩形时，它不会是数学意义上完美的直角矩形，而是边缘略带抖动、线条粗细不均的“手绘风”。这种效果源于其核心机制之一：sketchification（草图化）。系统会对路径点施加轻微的随机扰动，并结合特定描边算法（如rough.js库），模拟出人类手绘的真实感。

这种“不完美”，恰恰降低了用户的创作压力。不必纠结于对齐与比例，思维可以更自由地流动。许多工程师反馈：“终于不用为了‘看起来专业’而花两个小时修图了。”

更重要的是，它的数据结构极为透明：

{ type: "rectangle", x: 100, y: 100, width: 200, height: 100, strokeStyle: "rough", // 启用粗糙描边 roughness: 2, // 扰动强度 fillStyle: "hachure", // 斜线填充风格 seed: 12345 // 随机种子，确保重绘一致性 }

每一个图形都是可序列化的 JSON 对象。这意味着什么？你可以把整个画布存进 localStorage 实现离线编辑，也可以通过 WebSocket 实时同步给协作成员，甚至能将图表版本提交到 Git——就像管理代码一样管理设计稿。

这一点，在敏捷开发和知识沉淀场景下尤为关键。试想，你在 Confluence 中插入一张 PNG 图片，下次架构变更时，谁还记得原始源文件在哪？而 Excalidraw 的.excalidraw文件本质上就是文本，天然支持 diff 和版本追踪。

如果说 Excalidraw 的基础能力解决了“怎么画得轻松”，那么 AI 的引入，则直接回答了“能不能别画”。

现在，越来越多的团队开始集成 LLM（大语言模型）来实现“自然语言到图表”的自动转换。流程并不复杂，但每一步都需要工程上的精细打磨。

假设你输入这样一句话：

“画一个登录流程：用户输入账号密码 → 认证服务验证 → 成功跳转主页，失败提示错误”

系统首先会将这段描述发送给后端代理服务。这个服务不直接暴露 LLM API 给前端，而是作为中间层进行安全过滤和格式控制。接着，它构造一段精心设计的 prompt 发送给 GPT 或 Claude 类模型：

你是一个专业的技术图表生成器。请根据以下描述生成对应的 Mermaid.js 流程图代码（graph TD 格式）。 要求： - 使用标准 Mermaid syntax - 节点间使用箭头连接 - 不要包含任何解释文字 - 输出仅包含代码块 描述：{用户输入}

为什么强调“不要解释”？因为我们需要的是机器可解析的结构化输出，而不是一段自然语言回复。温度参数通常设为 0.3 左右，降低随机性，提高结果一致性。

返回的结果可能是：

graph TD A[用户输入账号密码] --> B[认证服务验证] B --> C{验证成功?} C -->|是| D[跳转主页] C -->|否| E[提示错误]

接下来才是真正的技术挑战：如何把这个 Mermaid 代码变成 Excalidraw 里的可视元素？

Mermaid 是声明式的，而 Excalidraw 是基于坐标的。我们必须做一次“布局还原”——解析 Mermaid 的节点关系，估算每个元素的位置，避免重叠，再生成带有x/y/width/height的矩形、菱形和箭头对象数组。

这个过程可以用一个简单的映射函数完成：

def mermaid_to_excalidraw_nodes(mermaid_code: str): # 使用正则或专用解析器提取节点与连接 nodes = parse_nodes(mermaid_code) links = parse_links(mermaid_code) excalidraw_elements = [] layout_x, layout_y = 100, 100 row_spacing = 80 for node in nodes: element = { "type": "rectangle" if "[]" in node else "diamond", "id": generate_id(), "x": layout_x, "y": layout_y, "width": 160, "height": 50, "strokeStyle": "rough", "roughness": 2, "text": clean_text(node), # ... 其他字段 } excalidraw_elements.append(element) layout_y += row_spacing # 添加连线 for src, dst, label in links: line = create_arrow(src, dst, label) excalidraw_elements.append(line) return excalidraw_elements

最终，这些元素被注入当前画布，用户看到的，是一张完全可编辑的交互式图表。你可以拖动节点、修改文字、更换颜色——AI 只负责“起个头”，后续仍由人掌控。

整个系统的部署架构也值得推敲。典型的三层结构如下：

+------------------+ +--------------------+ | 用户浏览器 |<----->| Excalidraw 前端 | | (Web App) | | (React + Canvas) | +------------------+ +--------------------+ ↓ +------------------+ | AI 代理服务 | | (Node.js/Python) | +------------------+ ↓ +------------------+ | LLM API 接口 | | (OpenAI/Claude) | +------------------+

前端负责交互与渲染；AI 代理层处理请求调度、缓存、限流和敏感词过滤；最底层对接各类 LLM 提供商。这种分层设计不仅提升了安全性，也为未来切换至私有化模型预留了空间。

例如，金融或政企客户往往不允许核心业务逻辑外传。此时，可在内网部署 Ollama + Llama 3 或 Qwen 模型，让 AI 生成全程在本地完成。虽然推理速度稍慢，但换来了数据闭环的安全保障。

不过，AI 并非万能。实践中常见几个坑：

• 输出不稳定：同一句话，两次生成的 Mermaid 语法可能略有差异，导致解析失败。解决方案是引入 JSON Schema 校验或正则兜底，确保格式合规。
• 布局混乱：AI 不理解“美观”，生成的节点可能挤在一起。建议加入简单的自动排版逻辑，如层级布局（hierarchical layout）或力导向图（force-directed graph）预计算位置。
• 过度依赖：有些用户一旦生成失败就放弃使用。因此必须保留“手动绘制”这一基本路径，AI 仅作为加速器而非唯一入口。

从实际应用来看，Excalidraw + AI 的组合已在多个场景中展现出独特价值。

在 SRE 团队中，故障复盘会议前，负责人只需输入：“展示本次故障的调用链：API网关 → 订单服务 → 支付超时 → 数据库锁等待”，即可快速生成一张应急拓扑图，节省大量准备时间。

在产品需求讨论会上，产品经理说：“我想做个用户注册流程，包括手机号验证、第三方登录和实名认证。” 技术同事当场生成初稿，大家围绕画布即时讨论，边改边聊，效率远超传统文档传递。

甚至有团队将其嵌入 Obsidian 或 Logseq，实现“笔记即架构图”。你写下一堆想法，选中文字，点击“生成图表”，瞬间就把零散记录转化为可视化结构——知识不再沉睡于段落之间。

回过头看，Excalidraw 的成功并非来自某项颠覆性技术，而是对“人本设计”的深刻理解：
它没有试图取代专业工具，而是填补了一个被忽视的空白地带——快速、低负担、可协作的即时表达。

而 AI 的加入，则进一步将“表达成本”压缩到了极致。过去需要 20 分钟手工完成的工作，现在 30 秒就能拿到初稿。这不是简单的效率提升，而是改变了团队的协作节奏：更多尝试、更快反馈、更大胆的创意。

未来，这条路还有更多可能。多模态模型已经能够从语音生成图表，甚至从手绘草图反向重建规范流程图。或许有一天，你会对着手机说：“把我刚才白板上画的东西，转成一张正式的系统架构图”，然后一杯咖啡还没喝完，PDF 就已邮件发出。

对于技术团队而言，真正的生产力革命，往往不在宏大的系统重构，而在这些细微处的体验跃迁。Excalidraw 与 AI 的结合，正是这样一个微小却锋利的切口——它让我们重新思考：工具的意义，不是让人适应它，而是让它适应人。