从Sketch到Excalidraw：为何越来越多团队转向开源白板？

从Sketch到Excalidraw：为何越来越多团队转向开源白板？

在一场远程技术评审会上，产品经理刚抛出一个复杂的系统重构设想，工程师们还没来得及打开Figma模板，有人已经在共享白板上草草画出了三个歪歪扭扭的方框和几条波浪线箭头。几分钟后，这张“涂鸦”演变成了一幅清晰的微服务交互图——而这正是整个团队达成共识的起点。

这样的场景正变得越来越普遍。当设计工具越来越精美、功能越来越复杂时，反而有一群人开始回归“手绘感”的表达方式。Excalidraw，这个最初由微软工程师为个人使用而创建的开源项目，如今已悄然成为许多技术团队日常协作的核心载体。

它没有Figma那样华丽的界面，也不像Sketch那样拥有完整的UI设计生态，但它做对了一件事：让想法的流动比工具本身更重要。

Excalidraw的本质其实很简单——一个基于Web的虚拟白板，用TypeScript和React构建，运行在浏览器里，不需要安装任何客户端。它的名字来自“Excalibur”（王者之剑）与“drawing”（绘画）的结合，寓意以最直接的方式斩断沟通障碍。但真正让它脱颖而出的，是那种看似随意却极具亲和力的手绘风格。

这种视觉语言的背后，藏着一个关键库：Rough.js。它不是简单地给线条加点抖动，而是通过算法模拟人类书写时的肌肉微颤、笔触迟疑和落点偏差。比如画一条直线，Rough.js会生成多段轻微弯曲的路径，并在端点处添加细微回勾，就像你用铅笔在纸上划完最后一笔时不自觉抬手的动作。这种“不完美”的渲染策略，意外地降低了用户的表达压力——毕竟没人会因为草图不够工整而羞于分享想法。

更聪明的是它的状态管理机制。整个画布的数据结构采用不可变模式（Immutable State），每个图形元素都是一个包含id、type、x/y坐标、宽高等属性的对象，存储在Zustand全局状态中。这意味着每一次操作都是一次新状态的生成，而非原地修改。这不仅便于实现撤销/重做，也为后续的实时协同打下基础。

说到协作，Excalidraw走了一条轻量但实用的路线。官方服务器使用WebSocket广播模型，当某个用户拖动一个矩形时，变更会被序列化为一个操作指令（operation），推送给房间内所有其他成员。虽然目前未默认集成CRDT或OT这类高级冲突解决算法，但对于中小型团队来说，这种“最后写入胜出”的逻辑已经足够流畅。如果你追求更强的一致性，社区已有基于Yjs（一种CRDT实现）的增强版方案，比如Excalidraw+，可以在高并发场景下避免数据撕裂。

值得强调的是它的离线优先架构。所有编辑操作默认在本地完成，依赖浏览器的LocalStorage持久化数据。即使网络中断，你依然可以继续画画；一旦恢复连接，变更会自动同步。这对于跨国团队或网络环境不稳定的地区尤为重要。我曾见过一位印度开发者在火车隧道中完成了半张架构图，出站后毫秒级同步到团队画布上。

// 示例：在 React 应用中嵌入 Excalidraw import React from "react"; import { Excalidraw } from "@excalidraw/excalidraw"; function WhiteboardApp() { const [excalidrawData, setExcalidrawData] = React.useState(null); return ( <div style={{ height: "100vh" }}> <Excalidraw initialData={excalidrawData} onChange={(elements) => { // 每次画布变化时保存状态 setExcalidrawData({ elements }); }} onCollabButtonClick={() => { alert("打开协作设置面板"); }} /> </div> ); } export default WhiteboardApp;

上面这段代码展示了如何将Excalidraw作为组件嵌入任意React应用。onChange回调让你能监听每一次笔触变化，适合接入自定义的自动保存逻辑或版本控制系统。很多公司正是利用这一点，把Excalidraw集成进内部Wiki、项目看板甚至CRM系统中，形成统一的知识工作流。

但这还不是全部。真正的转折点出现在AI能力被引入之后。

想象一下：你说“帮我画一个包含用户认证、订单管理和库存同步的电商后台”，下一秒画布上就出现了对应的模块布局。这不是科幻，而是Excalidraw通过插件实现的“Text to Diagram”功能。其背后原理并不神秘，但工程细节至关重要。

首先，前端将你的自然语言输入封装成一段精心设计的Prompt，其中明确要求输出必须符合Excalidraw的JSON Schema，并附带风格约束（如“使用手绘风”、“保持间距合理”）。然后请求被转发至后端网关，调用GPT-4或Claude等大模型进行推理。关键在于，响应格式必须强制设为json_object，并提供详细的Schema校验规则，否则模型可能返回一段散文式的描述而非可用数据。

# 示例：Python 后端调用 GPT-4 生成 Excalidraw 兼容 JSON import openai import json EXCALIDRAW_SCHEMA = { "type": "object", "properties": { "type": {"type": "string"}, "version": {"type": "number"}, "elements": { "type": "array", "items": { "type": "object", "properties": { "id": {"type": "string"}, "type": {"enum": ["rectangle", "diamond", "arrow", "text"]}, "x": {"type": "number"}, "y": {"type": "number"}, "width": {"type": "number"}, "height": {"type": "number"}, "label": {"type": "string"} }, "required": ["id", "type", "x", "y"] } } }, "required": ["elements"] } def generate_diagram(prompt: str) -> dict: system_msg = f""" 你是一个 Excalidraw 图表生成器。根据用户的描述，生成符合以下 JSON Schema 的图表数据： {json.dumps(EXCALIDRAW_SCHEMA)} 要求： - 使用手绘风格词汇（如 'sketch', 'hand-drawn'） - 元素之间保持合理间距 - 箭头表示流向或关系 - 尽量使用矩形表示模块，菱形表示决策点 """ response = openai.ChatCompletion.create( model="gpt-4-turbo", messages=[ {"role": "system", "content": system_msg}, {"role": "user", "content": prompt} ], temperature=0.6, max_tokens=1024, response_format={"type": "json_object"} # 启用 JSON 模式 ) try: result = json.loads(response.choices[0].message['content']) return result except Exception as e: print(f"解析失败: {e}") return {"elements": []}

这个微服务通常部署在企业内网作为AI网关，既能控制成本，又能防止敏感信息外泄。例如，在金融或医疗行业，客户架构图绝不能传到第三方API。此时可以用Llama 3等开源模型搭建私有LLM集群，虽然生成质量略有下降，但安全性和合规性得到了保障。

整个系统的典型架构如下：

+------------------+ +---------------------+ | Client (Web) |<----->| Excalidraw Frontend| | (Browser/App) | | (React + Canvas) | +------------------+ +----------+----------+ | v +----------------------------+ | Real-time Sync Server | | (WebSocket / Firebase) | +--------------+-------------+ | v +----------------------------------+ | AI Gateway Service (Optional) | | (LLM Proxy + Prompt Template) | +--------------+-------------------+ | v +-------------------------------+ | LLM Backend (e.g., GPT-4) | +-------------------------------+

实际工作流也因之改变。以前开一次技术方案会，主讲人要提前几天准备PPT，反复调整配色和排版；现在，会议前10分钟发起人只需输入一句：“展示当前订单系统的上下游依赖”，AI瞬间生成初稿，参会者边讨论边拖拽修改，最终版本直接导出SVG归档到Confluence。

我在某电商平台看到过这样一个案例：新人入职培训时，导师不再播放录制视频，而是带着新人在一个Excalidraw画布上“重建”核心交易链路。每讲解一个环节，就亲手画出对应模块并连线。据反馈，这种方式的记忆留存率远高于传统文档阅读。

当然，落地过程中也有需要注意的地方。比如单个画布元素不宜超过1000个，否则Canvas渲染会出现明显卡顿。建议对大型系统图启用“分组折叠”功能，或将子系统拆分为多个关联画布。另外，若需长期维护重要架构图，应定期导出快照备份，避免因浏览器缓存清除导致数据丢失。

还有一个容易被忽视的设计哲学：克制装饰，专注内容。Excalidraw故意不提供丰富的颜色主题、字体库或图标集，就是为了让注意力始终集中在信息本身，而不是视觉表现上。这与Sketch/Figma的价值取向截然不同——后者鼓励“交付即成品”，而Excalidraw则坚持“过程即成果”。

也正是这种理念差异，解释了为什么越来越多的技术团队选择从Sketch迁移过来。他们不需要每次都产出一份可以放进年报的精美图表，他们需要的是快速捕捉灵感、即时验证假设、共同演化认知的能力。

从更宏观的视角看，Excalidraw的兴起不只是工具替换，更是一种协作文化的回归。它提醒我们，在追求自动化和智能化的同时，也不能忘记人与人之间最原始也最有效的沟通方式——拿起笔，一起画点什么。

未来的白板或许会更加智能，能主动建议架构模式、检测设计缺陷，甚至预测性能瓶颈。但在那之前，我们需要的可能只是一个允许犯错、欢迎涂改、不怕潦草的空间。而Excalidraw正在做的，就是守护这个空间的存在。