Excalidraw AI生成后端服务依赖关系图

Excalidraw AI生成后端服务依赖关系图

在一次深夜的线上故障复盘会上，团队争论不休：订单服务到底有没有直接调用库存服务？没人记得清最初的架构设计了。这时有人打开浏览器，输入一句自然语言：“画一个包含订单、支付、用户和库存服务的微服务依赖图，订单服务同步调用用户服务并异步通知库存服务。”三秒后，一张清晰的手绘风格架构图出现在共享白板上——争议瞬间平息。

这不是科幻场景，而是越来越多技术团队正在经历的真实工作流。随着微服务架构的普及，系统内部的服务调用链路变得愈发复杂，传统的绘图方式早已跟不上敏捷迭代的速度。而像Excalidraw这样的开源白板工具，结合大语言模型（LLM）的能力，正悄然改变我们表达和理解系统结构的方式。

Excalidraw 最初吸引开发者的是它那独特的“手绘风”界面——看似随意的线条与字体，实则是一种精心设计的认知亲和力。这种风格降低了图表的权威感，鼓励团队成员自由评论与修改，特别适合在技术评审或头脑风暴中使用。更重要的是，它的核心架构并非只是一个静态画布，而是一个基于现代协作理论构建的实时同步系统。

其底层采用Yjs实现的 CRDT（无冲突复制数据类型）机制，使得多个用户可以在不同网络环境下同时编辑同一张图，且无需加锁或手动合并。每个用户的操作被序列化为增量更新，通过 WebSocket 推送到协作服务器，并在所有客户端自动融合成一致状态。这意味着即使你在地铁隧道里断网十分钟，重新连接后依然能无缝接续之前的编辑。

// Yjs 协作初始化示例 import * as Y from 'yjs'; import { WebsocketProvider } from 'y-websocket'; const doc = new Y.Doc(); const provider = new WebsocketProvider('wss://your-excalidraw-server/ws', 'shared-drawing', doc); const yShapes = doc.getMap('shapes'); yShapes.observe((event) => { console.log('Shape update:', event.changes); }); export default doc;

这段代码虽然简短，却承载着分布式协作的核心逻辑。Y.Doc是全局共享的状态容器，WebsocketProvider负责网络通信，而yShapes则是存储图形元素的动态映射。任何对它的修改都会自动广播并同步到其他端点。生产环境中还需注意启用 WSS 加密和身份验证中间件，避免敏感架构信息泄露。

但真正让 Excalidraw 脱颖而出的，是它与 AI 的深度融合。想象一下，你不再需要手动拖拽矩形框、调整连线角度、反复确认服务名称拼写，只需描述你想表达的关系，AI 就能帮你生成初步草图——这正是当前许多高效团队已经实现的工作模式。

这一过程的关键在于将自然语言转化为结构化的图形指令。通常的做法是通过封装 LLM 接口，引导模型输出符合特定 schema 的 JSON 数据：

import openai import json def generate_dependency_diagram(prompt: str): system_msg = """ You are an architecture diagram assistant. Convert natural language into structured JSON for Excalidraw. Output format: { "nodes": [{"id": "A", "label": "Order Service", "x": 100, "y": 100}], "edges": [{"from": "A", "to": "B", "label": "HTTP POST"}] } Use logical positioning (left-to-right flow). Label edges with protocol if mentioned. """ response = openai.ChatCompletion.create( model="gpt-4o", messages=[ {"role": "system", "content": system_msg}, {"role": "user", "content": prompt} ], temperature=0.3 ) raw_output = response.choices[0].message['content'] try: diagram_data = json.loads(raw_output) return diagram_data except json.JSONDecodeError: raise ValueError("LLM returned invalid JSON") # 示例调用 diagram = generate_dependency_diagram( "Payment Service calls User Service and Notification Service asynchronously." ) print(json.dumps(diagram, indent=2))

这个函数看似简单，但在实际应用中却蕴含诸多工程考量。首先，temperature=0.3的设置是为了抑制模型的创造性，确保输出稳定可解析；其次，必须建立严格的 JSON 校验机制，防止格式错误导致前端崩溃；最后，建议缓存常见模式（如“C4 模型四层结构”），以减少 API 调用频率和成本。

从系统架构角度看，整个流程形成了一条清晰的数据流水线：

[用户浏览器] ↓ HTTPS [Excalidraw 前端 UI] ↓ WebSocket / REST API [Excalidraw 后端服务（含协作引擎）] ↓ HTTP 调用 [AI Gateway 服务] ↓ API Key 认证 [大语言模型 API（如 OpenAI）] ↑ 返回结构化 JSON [AI Gateway] → [转换为 Excalidraw Elements] → [返回给前端]

在这个链条中，AI Gateway 扮演了关键角色：它不仅是代理转发器，更是安全过滤层和上下文增强器。例如，在企业内部部署时，可以在此阶段注入项目上下文（如服务命名规范、常用缩写表），从而提升识别准确率。更进一步地，一些团队选择在内网运行私有 LLM（如 Ollama + Llama 3），完全规避数据外泄风险。

当用户输入“订单服务调用用户服务获取用户信息，然后发送事件到 Kafka，由支付服务消费”这类描述时，AI 不仅要识别出三个服务节点，还要判断两种不同的通信模式：同步 HTTP 请求 vs 异步消息队列。理想情况下，生成的图元会用实线箭头表示前者，虚线加图标表示后者，甚至可以根据是否提及“重试”、“死信队列”等关键词来建议容错设计。

相比传统绘图方式，这种方式解决了多个长期存在的痛点：

不过，要在生产环境稳定落地这套方案，还需要一系列设计考量：

• 提示工程优化：制定标准模板能显著提升生成质量。例如：
  ```
  请生成一个后端服务依赖图，包含以下服务：
• {{service_name}}: {{description}}
  它们之间存在以下调用关系：

• {{caller}} → {{callee}} via {{protocol}}
  使用左到右的流向布局。
  ```

• 权限与审计：在金融或医疗等行业，应对 AI 生成功能记录完整日志，追踪谁在何时生成了何种图表，满足合规要求。

• 性能优化：对于超过 50 个服务的大型系统，应采用分层生成策略——先绘制高层模块边界，再逐层展开子系统，避免画布过于拥挤。

• 风格统一：预设颜色编码规则（如红色代表外部第三方系统、蓝色代表内部通用组件、绿色代表业务专属服务），有助于快速识别关键路径。

• 安全合规：严禁在公有模型中输入真实 IP 地址、数据库名或敏感接口路径。推荐使用脱敏别名（如 svc-order、module-auth）进行建模。

值得强调的是，AI 生成并不是要取代工程师的思考，而是把他们从重复性劳动中解放出来。一张自动生成的依赖图从来不是终点，而是讨论的起点。真正的价值在于，团队能在更短时间内达成共识，并将精力集中在架构决策本身，而非绘图技巧上。

展望未来，Excalidraw 与 AI 的结合还有更大想象空间。比如，可以从 Git 仓库自动分析代码中的服务调用关系，生成初始依赖图谱；也可以集成 APM 工具（如 Prometheus、Jaeger），在图中标注实际流量、延迟热点或错误率异常；甚至支持语音输入，实现“边讲边画”的实时协作体验。

在一个“可视化即沟通”的时代，Excalidraw 正在重新定义技术协作的本质。它不仅是一款工具，更是一种新型的团队认知基础设施——让复杂系统的理解和传递变得更轻盈、更直观、更人性化。