Excalidraw记录技术评审：会后结论归档

Excalidraw：用一张“草图”改变技术评审的归档方式

你有没有经历过这样的场景？一场长达两小时的技术评审会结束，白板上画满了架构草图、数据流向和状态转换逻辑。大家意犹未尽地散去，而你——作为会议记录员——却要对着模糊的照片和零散笔记，花三四个小时重绘图表、整理结论，最后塞进 Confluence 的某个角落，再无人问津。

这不仅是时间的浪费，更是知识的流失。那些在讨论中迸发的灵感、被否定的设计路径、最终拍板的关键决策，往往因为缺乏有效的承载形式而迅速褪色。

但如果我们能从“开会即归档”的角度重构这个流程呢？如果会议过程本身就能产出可追溯、可复用、结构化的技术资产，而不是事后补救式的文档搬运？

这就是Excalidraw带来的真正价值：它不只是一个画图工具，而是一种全新的技术协作语言。

为什么是 Excalidraw？因为它懂工程师的“表达焦虑”

我们不缺绘图工具。Visio 精确但死板，Draw.io 功能强大却容易陷入细节，Figma 更适合 UI 设计而非系统推演。而 Excalidraw 的特别之处在于它的“不完美”——那种略带抖动的手绘线条，反而成了它的最大优势。

这种视觉上的“松弛感”，悄然改变了团队的心理状态。没有人再纠结于对齐是否精准、颜色是否协调。当一张图看起来本就不追求美观时，大家的关注点自然就回到了内容本身：这个服务真的需要独立部署吗？这条消息队列会不会成为瓶颈？

更关键的是，它让非主讲人也能轻松参与。一个远程参会的后端工程师可以直接拖动节点调整拓扑，前端同事随手加个注释说明接口预期，产品则用红框圈出自己关心的数据流。所有这些操作实时同步，无需等待谁“腾出手来记一下”。

这才是现代技术协作应有的样子：不是单向输出，而是共同建构。

它是怎么做到的？底层机制比你想得更聪明

Excalidraw 看似简单，实则在用户体验与技术实现之间做了大量精巧取舍。

它的核心基于 HTML5 Canvas，所有图形以对象形式存在内存中。每次绘制矩形或连线，系统都会生成一个包含类型、坐标、样式等属性的 JSON 对象。这些对象通过 WebSocket 实现多端同步——但不是粗暴地推送整个画布，而是只发送变更的操作指令（如“添加元素”、“移动位置”），极大降低了网络负载。

最值得称道的是它的离线优先设计。即使某位成员短暂断网，本地操作依然流畅进行，变更暂存于浏览器。一旦连接恢复，系统会自动合并差异，避免“编辑冲突”打断思路。这种体验上的无缝衔接，正是远程协作中最容易被忽视却又至关重要的细节。

至于 AI 集成，则打开了另一种可能性。你可以输入一句：“画一个订单创建流程，用户提交 → 库存校验 → 支付网关 → 发货通知，用 Kafka 异步解耦。” 几秒钟后，一张结构清晰的初稿就会出现在画布上。

背后的技术链路其实并不复杂：先调用大模型解析语义，提取实体与关系；再将结果映射为 Excalidraw 的元素格式；最后注入前端完成渲染。虽然目前还无法完全替代人工，但对于标准化程度较高的架构模式（比如微服务、事件驱动、CQRS），已经能节省超过 60% 的起稿时间。

import requests def generate_diagram_from_text(prompt: str): llm_response = requests.post( "https://api.openai.com/v1/chat/completions", headers={"Authorization": "Bearer YOUR_KEY"}, json={ "model": "gpt-4o-mini", "messages": [ {"role": "system", "content": "你是一个图表生成助手，请将用户描述转化为 JSON 格式的节点和边列表。"}, {"role": "user", "content": prompt} ] } ) diagram_data = parse_llm_output(llm_response.json()) excalidraw_elements = [] for node in diagram_data['nodes']: element = { "type": "rectangle", "x": node['x'], "y": node['y'], "width": 120, "height": 60, "strokeColor": "#000", "backgroundColor": "#fff", "roughness": 2, "label": { "text": node['label'], "fontSize": 16 } } excalidraw_elements.append(element) for edge in diagram_data['edges']: line = { "type": "line", "points": [[0, 0], [80, 0]], "startBinding": {"elementId": edge['from']}, "endBinding": {"elementId": edge['to']}, "strokeColor": "#000" } excalidraw_elements.append(line) return excalidraw_elements

这段伪代码展示的就是这样一个“AI 快速建模助手”的骨架。企业完全可以将其封装为内部工具，在会议结束后一键生成归档初稿，把原本需要一小时的工作压缩到十分钟内完成。

如何落地？从一次真实的登录方案评审说起

上周我们团队讨论新的 OAuth2.0 登录流程。过去的做法是：先口头阐述，再由一人负责画 PPT，第二天才发出定稿。这次我们尝试了 Excalidraw。

会前，我创建了一个私有房间链接，附带 JWT 鉴权，确保只有项目成员可访问。同时预置了几个常用组件模板：API 网关、认证服务器、第三方平台图标等。

会议开始后，主持人一边讲解，我就在画布上同步构建流程图。说到“用户跳转到 SSO 页面”，立刻拉出一个新框；提到“Token 刷新机制”，马上用虚线标注 refresh 流程。过程中，安全工程师直接在加密传输环节加上锁形图标，运维则在高可用部分标红了潜在的单点故障。

所有人看到的画面始终一致，没有“你那边截图看不清”的尴尬。更重要的是，那些临时冒出的质疑——比如“这一步是不是该加风控拦截？”——可以直接用便签贴在对应位置，形成待办事项。

会后，我复制会议纪要中的关键句：“采用 OpenID Connect 协议，通过 Authorization Code + PKCE 模式实现移动端安全登录”，粘贴进 AI 插件。几秒后，一张规范化的流程图自动生成，与我们手绘版本高度吻合。我稍作调整，导出 PNG 插入 Wiki，同时将 JSON 文件提交 Git 进行版本追踪。

整个归档过程耗时不到 15 分钟，而以往至少需要一个小时。而且这一次，所有人都确认过图表内容，不存在理解偏差。

落地建议：别只把它当画板，要用出“工程思维”

Excalidraw 的潜力远不止于“画得快”。要想真正发挥其效能，需要在使用方式上做些转变：

权限与安全不可妥协

对于涉及核心系统的架构图，务必启用房间密码或集成企业身份认证（如 OIDC）。也可以通过 Docker 私有化部署，彻底掌控数据流向。一条简单的命令即可启动内网实例：

docker run -d \ --name excalidraw \ -p 8080:80 \ excalidraw/excalidraw:latest

这样既能享受云端协作的便利，又能满足合规要求。

版本管理必须跟上

虽然 Excalidraw 提供了快照功能，但建议定期导出 JSON 文件并提交 Git。这样不仅能做 diff 对比，还能在 PR 中直接引用设计图，实现“代码变更 ↔ 架构演进”的双向关联。

善用分层与拆解

当画布过于复杂时（比如上千个元素），性能确实会下降。我的经验是提前规划层级：主图展示高层架构，点击某个模块可跳转到子图详述内部逻辑。类似数据库建模中的 ERD 分层，保持每张图的信息密度适中。

AI 是助手，不是裁判

当前的 AI 图表生成仍存在误读风险。例如把“缓存穿透”误解为“缓存穿通”，或将异步回调画成同步调用。因此，任何由 AI 生成的内容都应经过至少一轮人工校验，尤其是在涉及关键路径时。

与现有工具链打通

我们已在 Obsidian 中嵌入 Excalidraw 编辑器，使得知识库中的每一篇技术文档都能直接编辑图表。也可以通过 iframe 将画布嵌入 Notion 页面，甚至开发 Chrome 插件，让 Jira Issue 右侧直接显示相关设计图。

最后一点思考：工具之外，是协作范式的升级

Excalidraw 的流行，反映的其实是技术团队对“轻量级、高表达力”协作方式的普遍渴求。它让我们意识到，很多所谓的“流程问题”，其实源于工具的错配。

当我们还在用静态文档承载动态讨论时，信息衰减几乎是必然的。而 Excalidraw 提供了一种可能：让决策过程本身成为交付物的一部分。

未来，随着语音识别与语义理解能力的提升，或许我们可以实现这样的场景：会议录音自动转写 → 关键语句提取 → AI 生成候选架构图 → 团队在线评审修正 → 直接归档发布。整个过程无需人工介入，真正实现“会散即归档”。

那一天不会太远。而在今天，我们至少可以迈出第一步：下次技术评审前，别再打开 PPT 或 Word，而是分享一个 Excalidraw 房间链接。

毕竟，最好的文档，从来都不是写出来的，而是“长”出来的。