Excalidraw绘图逻辑拆解：为什么它看起来更自然？-开发者社区

Excalidraw绘图逻辑拆解：为什么它看起来更自然？

在远程会议的共享白板上，你有没有遇到过这样的场景？一个人小心翼翼地拖出一个完美对齐的矩形，另一人却说：“能不能画得随意点？太规整了反而显得假。”这背后其实反映了一个深层问题：数字工具越精确，人与人之间的沟通反而可能越有距离感。

传统图表工具追求的是“正确”，而 Excalidraw 想要的是“像人画的”。这种看似简单的视觉差异，实则是一套精密设计的技术体系在支撑——从线条抖动的算法控制，到多人协作时的数据同步策略，再到用一句话生成完整架构图的 AI 能力。它不是简单地给图形加个滤镜，而是重新思考了“可视化协作”这件事的本质。

手绘风格是如何“伪造”出来的？

很多人以为 Excalidraw 的手绘效果是某种 SVG 滤镜或者 CSS 样式叠加的结果，但实际上，它是在路径生成阶段就主动引入“错误”——让线条不再笔直、让矩形边角微微扭曲，从而模拟真实纸笔作画时的不稳定性。

比如你画一条直线，系统并不会直接调用<line x1 y1 x2 y2 />，而是将这条线拆成十几个小段，每一段都做微小偏移。这个过程有点像书法中的“屋漏痕”：雨水顺着墙面流下，不会走直线，而是带着自然的弯曲和停顿。Excalidraw 用两种扰动机制来复现这种质感：

随机抖动（Roughness）：每个点上下左右轻微晃动，模拟手部肌肉的微颤；
弓形弯曲（Bowing）：中间部分偏移最大，两端贴近原位，形成类似毛笔中锋运笔的弧度。

// 简化版手绘线生成逻辑 function generateHandDrawnLine(x1, y1, x2, y2, options = {}) { const { roughness = 1.5, bowing = 0.5 } = options; const segments = 10; const dx = (x2 - x1) / segments; const dy = (y2 - y1) / segments; const len = Math.hypot(dx, dy); const unitPerpX = -dy / len; const unitPerpY = dx / len; return Array.from({ length: segments + 1 }, (_, i) => { const t = i / segments; const x = x1 + dx * i; const y = y1 + dy * i; // 组合抖动与弓形效应 const jitter = (Math.random() - 0.5) * roughness * 2; const bow = Math.sin(t * Math.PI) * bowing; // 中间最大 const offset = jitter + bow; return { x: x + unitPerpX * offset, y: y + unitPerpY * offset }; }); }

这套算法的关键在于“可控的不确定性”。如果完全随机，图形会杂乱无章；如果不加随机，又会回到机械感的老路。Excalidraw 的聪明之处在于：所有扰动都基于一个固定种子（seed）生成，这意味着同一图形每次刷新都长得一样——既保留了手绘感，又确保了可编辑性。

你可以想象成一位擅长模仿潦草笔迹的设计师，每次都“故意”画得不太整齐，但风格始终一致。这种一致性对于团队协作至关重要——没人希望昨天画的框今天变形了。

此外，描边粗细也不是恒定的。通过动态调整stroke-width，配合轻微的锯齿状填充（hachure pattern），连阴影和色块都能透出纸张纹理的感觉。这些细节叠加起来，才构成了那种“像是开会时随手记下的草图”的氛围。

多人同时画画，怎么做到不打架？

当三个人同时在一个白板上拖动元素、添加文字、连线时，数据冲突几乎是不可避免的。主流解决方案有两种：Operational Transformation（OT）和 CRDT（Conflict-free Replicated Data Type）。前者是 Google Docs 使用的技术，后者则是近年兴起的新范式。

Excalidraw 并没有选择复杂的全量 CRDT 实现，而是采用了一种轻量级但高效的折中方案：基于唯一 ID 的增量状态广播。

每个图形元素创建时都会获得一个全局唯一的 ID（如element-abcd1234），这个 ID 由客户端生成，通常结合时间戳与随机哈希。服务器不做逻辑判断，只负责转发变更消息。当用户移动一个矩形，前端发出一个{ type: 'UPDATE_ELEMENT', payload: { id: 'abcd1234', x: 150, y: 200 } }消息，服务端立刻推送给其他成员，各客户端根据 ID 找到对应元素并更新位置。

// Node.js + WebSocket 同步示例 const wss = new WebSocket.Server({ port: 8080 }); const boards = {}; wss.on('connection', (ws) => { const boardId = parseBoardId(ws); ws.send(JSON.stringify({ type: 'INITIAL_STATE', payload: boards[boardId] || [] })); ws.on('message', (data) => { const message = JSON.parse(data); if (message.type === 'UPDATE_ELEMENT') { const { id, updates } = message.payload; const elements = boards[boardId]; const index = elements.findIndex(e => e.id === id); if (index > -1) { Object.assign(elements[index], updates); } // 广播给其他人 wss.clients.forEach(client => { if (client !== ws && client.readyState === WebSocket.OPEN) { client.send(data); // 原样转发 } }); } }); });

这种方法的优势在于简单可靠。虽然没有实现真正的无冲突复制，但在实际使用中，绝大多数操作都是“按元素粒度”进行的——你改你的框，我连我的线，很少出现两个人同时编辑同一个文本的情况。即使发生冲突，也可以通过最后写入胜出（last-write-wins）策略快速解决。

更重要的是，这种架构允许完全自托管。企业可以把它部署在内网，无需依赖第三方云服务，这对金融、医疗等敏感行业尤为重要。相比之下，Miro 或 Jamboard 这类闭源工具尽管功能丰富，但数据必须经过其服务器，存在合规风险。

当然，它也有局限。比如无法支持离线后长时间断联再同步的场景（此时需要 CRDT 的版本向量机制）。不过对于一场两小时的设计讨论来说，这点妥协换来的是更低的技术门槛和更高的透明度，显然是值得的。

一句“画个三层架构图”，是怎么变成可视化的？

如果说手绘风格降低了表达的心理门槛，那么 AI 生成功能则直接打破了“从想法到图像”的启动障碍。很多人的创作卡点不在构思，而在面对空白画布时的犹豫：“先画哪个框？怎么排版？”Excalidraw 的 AI 插件做的，就是帮你迈出第一步。

它的核心流程是一个三段式流水线：

语义解析：把自然语言转换成结构化信息；
图建模：确定节点关系与布局逻辑；
渲染注入：生成符合手绘风格的图形元素。

以输入“画一个微服务架构，包含 API Gateway、User Service 和 MySQL”为例，系统会先调用大模型提取关键实体和层级关系：

import openai import json def generate_diagram_elements(prompt): system_msg = """ You are a diagram planner. Output JSON with: - diagram_type - elements: list of {id, type, label, position_hint} - connections: list of {source_id, target_id} Use placeholder positions. Return only valid JSON. """ response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[ {"role": "system", "content": system_msg}, {"role": "user", "content": prompt} ], temperature=0.3 # 控制输出稳定性 ) raw_output = response.choices[0].message['content'] try: spec = json.loads(raw_output) return transform_to_excalidraw_format(spec) except json.JSONDecodeError: raise ValueError("LLM returned invalid JSON")

这里有个关键设计：提示词明确要求模型返回带id的结构化数据，并且连接关系使用 source/target 引用，而不是直接描述“API Gateway 指向 User Service”。这样做的好处是后续映射更稳定，避免因语言表达差异导致解析失败。

拿到结构后，系统将其转化为 Excalidraw 兼容的元素格式：

{ id: "auto-1001", type: "rectangle", x: 100, y: 100, width: 80, height: 40, text: "API Gateway", strokeColor: "#000", backgroundColor: "#fff", fillStyle: "hachure", roughness: 2, strokeWidth: 1 }

注意其中roughness: 2和fillStyle: "hachure"字段——这保证了 AI 生成的内容和手动绘制的图形风格完全统一。否则就会出现“左边是手绘风，右边是印刷体”的割裂感。

整个过程不到两秒。用户看到的是一幅已经搭好骨架的草图，接下来可以自由调整位置、更换样式、补充说明。AI 没有替代人类，而是充当了一个高效的“初稿助手”。

它到底适合谁？又该注意什么？

Excalidraw 的典型应用场景远不止于技术团队画架构图。在教育领域，老师可以用语音输入快速生成流程图辅助讲解；在产品评审会上，产品经理一句话就能拉出竞品分析框架；甚至非营利组织用它来做项目规划，因为“看起来不像正式文件，大家更敢提意见”。

但任何工具都有适用边界。以下是几个实践中值得留意的要点：

别过度依赖 AI：LLM 对专业术语的理解仍有偏差。例如“事件溯源架构”可能被误解为普通事件驱动模式。建议搭配上下文提示词，如：“请按照 DDD 领域驱动设计原则理解以下术语……”
网络环境影响体验：实时协作依赖稳定的 WebSocket 连接。跨国团队建议使用 CDN 加速或就近部署实例。
隐私优先策略：涉及敏感数据时，应关闭外部 AI 接口，改用本地运行的小型模型（如 Llama 3 8B），或完全禁用 AI 功能。
移动端交互优化：触摸屏上的长按、双指缩放等手势需特别处理，避免误触删除或误判为拖拽。

部署架构上，它可以非常灵活：

[浏览器] │ ├── HTTPS → [静态资源服务器] ├── WSS → [WebSocket 协同服务] └── POST → [AI 网关] → [OpenAI / 本地模型] [数据层] ├── 本地存储：localStorage / IndexedDB └── 远程持久化：Firebase / 自定义后端 / Excalidraw Live

你可以把它当作纯前端应用运行在本地，也能集成进内部知识库系统，甚至嵌入 Notion 替代品中作为可视化模块。