Excalidraw AI错误生成的纠正机制设计

Excalidraw AI错误生成的纠正机制设计

在智能设计工具飞速发展的今天，AI 已不再是“锦上添花”的附加功能，而是真正介入创作流程的核心角色。Excalidraw 作为一款广受开发者和技术团队青睐的手绘风格白板工具，在引入自然语言驱动的图表生成功能后，显著提升了架构草图、流程绘制和头脑风暴的效率。但随之而来的问题也愈发明显：当 AI 把“微服务”画成“单体”，把“并行验证”连成“串行步骤”时，用户面对的不只是一个错图——更是一次对信任感的消耗。

如何让 AI 不仅“快”，还要“准”？更重要的是，当它出错时，能否像人类协作者一样听懂反馈、快速调整，而不是要求你从头再来一遍？

这正是我们关注的核心问题：如何构建一种轻量、高效且自然的纠错机制，使 AI 绘图既保持自动化优势，又具备可交互、可修正的灵活性。

AI 错误从何而来？

先看一个典型场景：

用户输入：“画一个包含前端、后端和数据库的三层架构。”

理想输出应是三个层级分明的模块。但若模型训练数据中“三层架构”多与“Spring Boot + MySQL”绑定，而当前上下文未明确提及框架，AI 可能直接生成一个整合式应用框图——看似合理，实则偏离本意。

这类错误的本质，并非单纯的“识别不准”，而是语义映射断层：大语言模型（LLM）将自然语言转化为结构化描述（如 JSON 节点关系），再由渲染引擎转为图形。一旦中间环节理解偏差，最终结果就会“差之毫厘，谬以千里”。

更麻烦的是，这种错误往往带有隐蔽性。用户需要逐节点检查逻辑流、组件命名和连接关系，才能发现异常。对于复杂系统图而言，这几乎等同于人工复核整张图，极大削弱了 AI 提效的价值。

而且，目前多数 AI 绘图工具的默认应对方式仍是“重新生成”——这意味着放弃已有成果，重新组织语言，祈祷下一次运气更好。这种方式不仅耗时，还容易破坏已达成共识的设计部分，尤其在协作环境中可能引发混乱。

真正的“智能”不在于不出错，而在于知道怎么改

与其追求完美无误的 AI，不如接受它的局限性，并设计一套能让用户轻松纠正它的机制。关键在于：让用户用最自然的方式表达“这不是我想要的”，系统则自动推断意图并精准修复。

我们在 Excalidraw 中提出了一种复合型纠错架构，融合了三个核心理念：

• 双向反馈回路：不仅仅是用户改图、AI 被动响应，而是通过操作行为反向训练模型理解团队语义；
• 可解释性标注：高亮显示 AI 添加某个元素的理由（例如，“检测到‘缓存’一词”），增强透明度；
• 局部编辑锁定：只更新出错区域，保留其余内容不变，避免“牵一发而动全身”。

这套机制的目标很明确：让修正过程比重新生成更快、更直观、更低认知负担。

如何让 AI “听懂”你的修改动作？

用户的每一次拖动、删除或重命名，其实都是一条隐含语义指令。比如：

• 删除某个节点 → “这个不该存在”
• 移动位置 → “布局不合理”
• 修改标签 → “名称不准确”

如果我们能把这些操作翻译成 AI 能理解的语言，就能实现“无需打字”的修正。这就是AICorrectionEngine的核心思路。

class AICorrectionEngine: def __init__(self, llm_client, sketch_renderer): self.llm = llm_client self.renderer = sketch_renderer self.correction_history = [] def apply_correction(self, original_prompt: str, generated_elements: list, user_edits: list): correction_intent = self._infer_intent(user_edits, generated_elements) if not correction_intent: return generated_elements delta_prompt = f"根据以下修正：{correction_intent}，调整原设计" full_context = f"原始需求：{original_prompt}\n修正要求：{delta_prompt}" updated_structure = self.llm.generate( prompt=full_context, temperature=0.3, max_tokens=200, stop=["}"] ) final_elements = self._merge_updates(generated_elements, updated_structure) self.correction_history.append({ 'prompt': original_prompt, 'edit_log': user_edits, 'intent': correction_intent, 'updated_json': updated_structure }) return final_elements def _infer_intent(self, edits: list, elements: list) -> str: intent_parts = [] element_map = {e['id']: e for e in elements} for edit in edits: eid = edit.get("element_id") action = edit.get("action") if action == "delete" and eid in element_map: elem = element_map[eid] intent_parts.append(f"移除不必要的 {elem['type']} '{elem.get('label', '')}'") elif action == "move": intent_parts.append(f"调整 {eid} 的位置以改善布局") elif action == "rename": new_label = edit.get("new_value") intent_parts.append(f"将 {eid} 的标签更正为 '{new_label}'") return "; ".join(intent_parts) if intent_parts else None def _merge_updates(self, old_elements: list, update_json: str) -> list: try: updates = json.loads(update_json) updated_ids = {item['id'] for item in updates} result = [] for elem in old_elements: if elem['id'] not in updated_ids: result.append(elem) result.extend(updates) return result except Exception as e: print(f"[WARN] 合并失败，回退到原始结构: {e}") return old_elements

这段代码的关键不在复杂度，而在意图还原能力。_infer_intent函数将低级操作（如 delete node_5）升维为高级语义（“移除了多余的 Redis 缓存节点”），再结合原始 prompt 构造出增量指令。LLM 接收到这条“上下文丰富”的请求后，只需微调结构即可返回更新后的 JSON，而非重新生成整幅图。

更重要的是_merge_updates实现了真正的“局部更新”。未被修改的元素原样保留，确保团队之前确认的部分不受影响。这对于多人协作场景尤为关键——没人愿意看到自己刚确认完的模块突然消失。

整个流程可在前端 Web Worker 中运行，主界面依然流畅响应。实测平均耗时约 800ms，远低于完整推理所需的 2s+，真正做到“边改边看”。

手绘风格一致性：别让 AI “露馅”

另一个常被忽视的问题是视觉割裂。即使结构正确，如果 AI 生成的图形线条太规整、角度太精确，一眼就能看出“这不是人画的”，会破坏整体协调感。

Excalidraw 的魅力正在于那种略带潦草、仿佛手写笔记般的美学风格。为了保证 AI 元素无缝融入，必须强制使用相同的渲染参数：

const roughConfig = { roughness: 2.5, bowing: 1.5, stroke: "#000", strokeWidth: 1.2, fillStyle: "hachure", hachureAngle: -45, hachureGap: 6 };

所有 AI 生成的矩形、箭头、文本框都必须通过rough.js渲染，禁用标准 SVG 路径。同时设置固定随机种子（seed），确保同一元素多次加载外观一致。

此外，还需支持动态适配：
- 用户切换深色模式？AI 元素自动变灰白描边；
- 团队启用了自定义主题？同步颜色与笔触风格；
- 移动端性能紧张？临时降低hachureGap或关闭填充细节。

这样做不仅能维持品牌一致性，也为未来扩展打下基础——比如允许导入某位成员的手绘模板风格，让 AI 模仿其笔迹生成图形。

实际工作流中的表现：一次典型的修正旅程

让我们走一遍真实使用场景：

1. 用户输入：“画一个用户注册流程，包括邮箱验证和短信验证两个并行步骤。”
2. AI 生成流程图，但错误地将两者串联执行（先邮箱，再短信）。
3. 用户发现逻辑错误，手动删除“短信验证”节点及其连接线。
4. 系统捕获delete操作，触发_infer_intent得到：“移除不必要的串联步骤”。
5. 构造 delta prompt：“原需求为并行验证，请改为并列分支结构”。
6. LLM 返回更新后的节点关系 JSON，新增“短信验证”为同级分支。
7. _merge_updates保留原有“邮箱验证”，合并新结构。
8. 渲染器重新绘制连接线，形成正确并行结构。
9. 结果实时同步至其他协作成员。

全程无需重新输入提示词，也不用手动拉线排版。AI 在用户“删一下”的瞬间就明白了意图，并完成了重构。

更进一步，系统后台默默记录这次纠正事件。一段时间后分析发现，“并行”、“同时”、“一起”等词汇频繁被修正为分叉结构——说明模型对并发语义理解不足。这些数据可用于构建微调数据集，逐步提升本地适配精度。

工程落地中的那些“坑”与对策

在实际集成过程中，我们也踩过不少坑，总结出几条重要经验：

1. 别让用户“被学习”

虽然每次纠正都是宝贵数据，但不能静默上传。应在首次检测到修正行为时弹出轻量提示：“是否让 AI 学习这次修改？”尊重用户选择权，避免造成监控焦虑。

2. 权限要分级

在协作场景中，普通成员可以修正图形，但大规模结构调整（如重绘整个架构）应限制为创建者或管理员操作，防止误触导致全局变动。

3. 性能隔离不可少

AI 纠正任务建议放在 Web Worker 中执行，避免阻塞主线程导致 UI 卡顿。特别是移动端设备资源有限，更要做好任务调度。

4. 有网靠模型，没网靠规则

网络异常时不能完全瘫痪。可内置一个轻量级规则库，涵盖常见修正模式：
- 删除数据库图标 → 移除相关连接线
- 将“API 网关”重命名为“负载均衡” → 替换图标并更新上下游标签
这样即使离线也能完成基础修正。

5. 隐私保护是底线

用户关闭“发送使用数据”选项后，所有correction_history应仅保存于本地 IndexedDB，定期清理，绝不外传。

这套机制的意义，远超一张图的修正

表面上看，我们解决的是“AI 画错了怎么办”的问题。但实际上，这套机制正在重塑人机协作的设计范式。

它让 AI 从一个“黑箱执行者”转变为“可沟通的协作者”。你不需要成为提示工程专家，也不必反复试错，只需要像指导同事一样，指出哪里不对，它就会立刻改正。

更重要的是，每一次纠正都在沉淀组织的知识习惯。随着时间推移，系统越来越懂你们团队常说的“中台”、“对接”、“兜底”到底意味着什么。这种个性化适应能力，才是 AI 工具真正产生长期价值的地方。

而且这一架构具有很强的通用性。无论是 Figma 中的 UI 自动生成，还是 Miro 里的思维导图推荐，只要涉及“语言→图形”的转换，都会面临类似的歧义与修正挑战。我们的方案提供了一个清晰的技术路径：感知操作 → 推断意图 → 增量更新 → 数据闭环。

下一步：让 AI 更“懂你”

未来还有更多值得探索的方向：

• 手势预测：在触摸屏上，长按+滑动是否预示着“我想拆分这个模块”？提前感知意图可实现零延迟修正。
• 跨文档迁移：在一个项目中学会的术语规范，能否自动应用到新文档？借助向量数据库做语义检索是个可行方向。
• 自研轻量模型：过度依赖通用 LLM 成本高、延迟大。训练一个专用于“图表修正”的小模型，或许能实现完全本地化运行。

技术终将回归体验。最好的 AI，不是永不犯错的那个，而是最擅长从错误中学习，并迅速弥补的那个。在 Excalidraw 的世界里，我们希望每一张被修正的图，都不只是修正一次输出，而是推动整个系统变得更聪明一点。