提升会议效率：用Excalidraw做实时技术方案讨论

提升会议效率：用 Excalidraw 做实时技术方案讨论

在一次紧急的系统故障复盘会上，团队围坐一圈，主讲人翻着一页页静态 PPT 讲解调用链路。有人提问：“这个服务到底有没有走缓存？”——没人能立刻回答。图是死的，逻辑藏在嘴里，信息不同步，讨论陷入僵局。

这场景你是否熟悉？我们每天都在开会，但大多数技术会议依然停留在“我说你听”的单向传递模式。文档和幻灯片无法动态响应讨论中的新想法，而专业建模工具又太重、太慢，根本不适合头脑风暴。直到最近，越来越多的技术团队开始转向一种更轻盈的方式：打开一个链接，所有人同步进入一块虚拟白板，边说边画，即时成形。

这其中，Excalidraw正悄然成为许多工程师的心头好。它不是什么复杂的设计软件，而是一个极简的手绘风格在线白板。没有华丽的界面，也没有冗长的学习曲线，但它解决了最关键的问题：如何让技术沟通变得可视、可改、可协作。

当你在浏览器里打开 Excalidraw，第一眼可能会觉得它“有点糙”——线条歪歪扭扭，图形像是手画的。但这正是它的聪明之处。这种“不完美”的视觉风格，反而消解了人们对“画得好看”的焦虑。谁都能上手，哪怕你连矩形都画不直。更重要的是，它的底层是一套完整的图形状态管理系统，所有元素都是结构化的数据对象，支持精确编辑、连接关系维护和版本追踪。

它的核心绘图引擎基于rough.js实现，通过算法模拟真实笔触的抖动与偏移。比如一条直线，并非像素级对齐，而是带有轻微的“波浪感”，就像你在纸上随手一划。这种效果不是贴图伪装，而是由数学函数实时生成：

const line = rc.linearPath(points, { stroke: '#000', strokeWidth: 2, roughness: 2.5, // 控制“粗糙度”，值越大越像手画 bowing: 1.5 // 控制曲线弯曲程度 });

这些参数被统一应用在整个 UI 中，形成了一种高度一致的视觉语言。你可以把它理解为“工程化的草图”——既保留了草图的灵活性，又具备数字工具的可控性。

更关键的是，每个图形都不是一张图片，而是一个 JSON 对象，包含类型、位置、尺寸、文本、样式以及与其他元素的连接关系。这意味着所有的操作都可以被捕获为状态变更，从而轻松实现撤销/重做、多人同步和历史回溯。

真正让 Excalidraw 脱颖而出的，是它与 AI 的结合。过去，开一场架构评审会，往往要提前花几个小时画图。现在，只需要一句话：“帮我画一个包含用户服务、订单服务和支付网关的微服务架构，数据库用 MySQL，缓存用 Redis。” 几秒钟后，一张初步的结构图就出现在白板上了。

这背后其实是两个系统的协同工作。首先是自然语言理解（NLU）模块，通常由大模型如 GPT 或本地部署的 Llama 系列完成。它会从你的描述中提取出实体（如“Redis”）、角色（如“缓存”）和层级关系（如“用户服务调用订单服务”）。然后，这部分结构化数据会被送入一个布局引擎，自动安排组件的位置、添加连接线、标注接口协议，并输出为 Excalidraw 可识别的 JSON 格式。

def generate_excalidraw_elements(prompt: str): system_msg = """ 你是一个Excalidraw图表生成助手。请根据用户的描述，输出一个符合Excalidraw元素格式的JSON数组。 每个元素包含：type ("rectangle"|"diamond"|"arrow"), label, x, y, width, height, and connectors. 使用相对坐标，尽量水平排列主要组件，垂直方向留出空间给数据库或外部系统。 """ response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[ {"role": "system", "content": system_msg}, {"role": "user", "content": prompt} ], temperature=0.5 ) try: elements = json.loads(response.choices[0].message['content']) return elements except Exception as e: print("解析失败:", e) return []

这套流程看似简单，但在实际使用中需要精心设计提示词（prompt engineering），确保模型不会把“Kafka”误认为前端框架，也不会把“API 网关”画成数据库。我们曾测试过一些通用模型，结果它把“消息队列”画成了邮箱图标——显然不符合技术语境。因此，很多团队会选择微调专属的小模型，或者在提示词中嵌入领域知识库，提升生成准确率。

而且，AI 生成的内容并不是终点，而是起点。它产出的图可以被任何人拖拽、重命名、换颜色、加注释。你可以右键某个服务节点，选择“放大为子图”，深入到其内部模块设计；也可以用不同颜色标记两种备选方案，进行对比决策。这种“AI 初稿 + 人工精修”的模式，把原本需要半天准备的工作压缩到了几分钟。

整个协作系统的架构其实很清晰，分为三层：

+---------------------+ | 客户端 (Web) | | - React UI | | - 手绘引擎 (Excalidraw core) | | - WebSocket 客户端 | +----------+----------+ | v +---------------------+ | 协作服务层 | | - WebSocket Server | | - 房间管理 (Room) | | - 操作广播与合并 | | - 可选：AI 接口网关 | +----------+----------+ | v +---------------------+ | 数据持久化层 | | - 文件存储（S3/本地）| | - 版本快照记录 | | - 可选：数据库（PostgreSQL）| +---------------------+

客户端负责渲染和交互，协作服务层处理多用户并发编辑。这里的关键是冲突解决机制。Excalidraw 默认采用类似 Operational Transformation（OT）的策略，将每个用户的操作（如移动一个框、修改一段文字）封装为增量更新，在服务器端进行合并后再广播给其他成员。虽然目前尚未完全支持 CRDT（无冲突复制数据类型），但对于绝大多数技术讨论场景来说，延迟和冲突已经控制在可接受范围内。

数据层则用于保存最终成果。每次会议结束时，主持人可以把白板导出为.excalidraw文件（本质是一个 JSON），存入 Git 或知识库。由于格式开放，后续还能通过脚本批量提取信息，比如自动生成 API 依赖关系表或服务拓扑图。

这样的工具改变了我们的会议节奏。以前是“先准备好再说”，现在变成了“边想边画”。上周我们做一次 Sprint 规划会，产品经理刚说完需求，技术负责人就打开了 Excalidraw，一边听一边拉出了三个服务模块。前端同事立刻补充：“这里需要一个配置中心”，说着就把 Consul 拖了上去。后端马上回应：“那鉴权就得统一做在网关层。”——整条链路就这样一点点浮现出来。

当有人提出质疑时，也不再只是口头争论。我们会复制一份当前视图，左边保留原方案，右边尝试新结构。用红色标注风险点，黄色贴便签写待办事项。会议结束前，所有人能看到一张凝聚共识的图，而不是一堆零散的笔记。

这也带来了一些新的实践建议。比如，不要试图在一张图上塞下整个系统。我们吃过亏：一张白板上有二十多个服务、七八条数据流，最后谁也看不懂。后来我们约定“一张图一个主题”——概览图只展示核心组件，详细设计另开子图。团队还制定了简单的图例规范：蓝色矩形是服务，圆柱体是数据库，云朵是第三方系统。虽然看起来像小孩画画，但只要大家懂就行。

另外，别忘了锁定功能。有一次重要评审会，一位实习生不小心把主流程图拖乱了，全场尴尬。现在我们会把定稿部分“分组+锁定”，避免误操作。AI 生成的内容也要谨慎对待——它可以快速搭骨架，但细节必须人工验证。毕竟，模型不知道你们内部的命名规范，也不了解那些没写进文档的隐性依赖。

回头看，Excalidraw 的价值远不止于“画图方便”。它本质上是在重构技术沟通的范式：从“展示型会议”转向“共创型讨论”。传统方式中，会议是信息的终点站——PPT 做好了，内容就固定了。而在 Excalidraw 的世界里，会议本身就是产出过程。每个人都是参与者，每句话都可能变成图上的一个节点。

尤其在远程办公已成为常态的今天，这种实时可视化的协作显得尤为重要。屏幕共享总有延迟，语音通话容易遗漏细节，而一块共享白板能让所有人保持在同一认知平面上。无论是初创团队快速验证 MVP 架构，还是跨部门协调复杂系统升级，它都能让讨论更聚焦、决策更高效。

也许未来某天，我们会看到更多智能辅助功能加入进来——比如自动检测循环依赖、推荐高可用设计模式，甚至对接监控系统实时显示服务健康度。但至少现在，Excalidraw 已经证明了一件事：最强大的工具，未必是最复杂的那个。有时候，一支能写字的笔，一块人人可写的白板，就足以点燃一场高质量的技术对话。

这种简洁而有力的设计哲学，或许才是它最值得被推广的原因。