Open-sourcing Eraser Diagrams开源 Eraser Diagrams

Eraser Diagrams is an AI-native, coordinate-aware diagram format, open-sourced under the MIT license. The spec, a reference renderer, and a gallery of examples are live at github.com/eraserlabs/eraser-diagrams. This post is about why it needs to exist.Eraser Diagrams 是一种 AI 原生、支持坐标感知的图表格式，现已在 MIT 许可协议下开源。其规范、参考渲染器及示例库均可在 github.com/eraserlabs/eraser-diagrams 查看。本文将探讨为何它有存在的必要。

What changed发生了什么变化

Until recently, LLMs could not be trusted with layout.直到最近，大语言模型在布局方面还不可信。

More precisely: they were poor at translating design intent into coordinates. Ask a model to place shapes on a canvas and you’d get overlapping nodes, orphaned labels, spaghetti lines. This is why AI diagram generators – Eraser included – have always relied on deterministic layout engines like ELK. The model decided what connects to what; the engine decided where everything goes. That division of labor was the only way to guarantee legible output.更准确地说：它们不擅长将设计意图转化为坐标。如果你让模型在画布上放置形状，你会得到重叠的节点、孤立的标签和杂乱的线条。这就是为什么 AI 图表生成器（包括 Eraser）一直依赖 ELK 等确定性布局引擎的原因。模型决定连接关系，而引擎决定元素位置。这种分工是保证输出清晰可读的唯一途径。

Then, in late 2025 / early 2026, it stopped being necessary. Frontier models became genuinely fluent at coordinate-based layout.然而，在 2025 年底到 2026 年初，这种做法不再必要了。前沿模型已经能够真正流畅地处理基于坐标的布局。

Which means the model can now be asked for much more than hierarchy and direction. It can be asked for the layout itself.这意味着，现在不仅可以要求模型处理层级和方向，还可以要求它处理布局本身。

“Make it fit on a slide”“让它适合放在幻灯片里”

To give layout engines their due: they’re great for small, simple diagrams. They assume a strong primary direction and then optimize, mostly to minimize line crossings. For a ten-node flowchart there are only so many ways to lay things out, and the engine usually finds a good one.不可否认，布局引擎在处理小型、简单的图表时表现出色。它们假设存在一个明确的主方向，然后进行优化，主要是为了尽量减少线条交叉。对于一个十个节点的流程图，布局方式有限，引擎通常能找到不错的方案。

But past a certain size and complexity, minimizing crossings starts working against what a diagram is actually for: telling a story, in reasonable dimensions.但一旦规模和复杂度超过一定程度，最小化交叉反而会违背图表的初衷：即在合理的尺寸内讲清楚一个故事。

We knew we’d hit a wall when one of our most common user prompts – “make this diagram fit on a slide” – was frustratingly inexpressible in our own pipeline. When the model can only say “A connects to B” and the engine owns every coordinate, that request has nowhere to go, so it gets ignored. Same for “put the databases on the right column,” “span the monitoring group across the entire bottom,” and every other instruction about where. With older models, this was a cost we accepted. But the latest models dissolve this problem: we can let them say where things go.当我们最常见的用户提示之一——“让这个图表适合放在幻灯片里”——在我们的流程中变得难以实现时，我们意识到遇到了瓶颈。当模型只能说“A 连接到 B”，而所有坐标都由引擎掌控时，这个请求就无处落实，只能被忽略。同样的情况也适用于“把数据库放在右侧栏”、“让监控组横跨整个底部”以及其他关于位置的指令。对于旧模型，我们不得不接受这种代价。但最新的模型解决了这个问题：我们可以让它们直接决定元素的位置。

Why diagrams matter为什么图表很重要

A fair question: in an age where AI agents do most of the execution work anyway, aren’t ASCII diagrams and Mermaid good enough? Do we need anything better?一个合理的问题是：在 AI 智能体已经承担了大部分执行工作的时代，ASCII 图表和 Mermaid 不就够了吗？我们还需要更好的东西吗？

For the agents – no. An agent is roughly indifferent to whether information arrives as a wall of text, a diagram, or binary. But humans process visual information far more efficiently than text, and humans are the ones who have to keep up. The ultimate bottleneck of the AI era won’t be getting agents to generate work; it will be the human capacity to process, evaluate, and govern the enormous volume of complex work that agents produce.对于智能体来说，不需要。智能体并不介意信息是以大段文本、图表还是二进制形式呈现。但人类处理视觉信息比处理文本高效得多，而人类才是需要跟上进度的一方。AI 时代的最终瓶颈不在于让智能体生成工作，而在于人类是否有能力处理、评估和管理智能体所产生的大量复杂工作。

A clean, legible diagram attached to an implementation plan, a pull request, or a system map can be the difference between an agentic project that is governable and one that isn’t. And if diagrams are how humans keep up, they should exploit every piece of visual / spatial circuitry we are born with: directionality, symmetry, proportion, relative positioning, color, rich text, and motion.一张清晰、易读的图表，如果附在实施计划、拉取请求（PR）或系统架构图中，往往决定了一个智能体项目是否可控。如果图表是人类跟上进度的关键，那么它们就应该充分利用我们与生俱来的视觉/空间感知能力：方向性、对称性、比例、相对位置、颜色、富文本和动态效果。

Why a new format为什么要设计一种新格式

For the last two or three years, AI diagramming has been synonymous with Mermaid – deservedly. “Produce a Mermaid diagram” was a magic incantation: near-optimal tradeoffs between visual richness, speed, required model intelligence, and instruction-following, backed by copious Mermaid syntax in every pre-training corpus. It’s what opened people’s eyes to AI diagramming in the first place.在过去两三年里，AI 绘图几乎等同于 Mermaid，这实至名归。“生成一个 Mermaid 图表”曾是一句魔法咒语：它在视觉丰富度、速度、模型智能要求和指令遵循之间取得了近乎最优的平衡，并且每个预训练语料库中都有大量的 Mermaid 语法支持。正是它最初让人们认识到了 AI 绘图的潜力。

But Mermaid is a relationship language. It has no way to say where anything goes – layout is delegated to an engine by design. So the new fluency has no way in. LLMs have silently outgrown Mermaid, largely unbeknownst to the people prompting them – and, in a sense, to the models themselves.但 Mermaid 是一种关系语言。它无法指定元素的位置——布局设计上就是委托给引擎的。因此，模型新获得的能力无法发挥作用。大语言模型在不知不觉中已经超越了 Mermaid，而提示它们的用户，甚至模型自身，往往并未意识到这一点。

So then, why not use an existing coordinate-aware format? We looked hard at the candidates.那么，为什么不使用现有的支持坐标的格式呢？我们认真考察了候选方案。

SVG and HTML are coordinate-native but too low-level. A box with a label is a pile of paths and tspans; there is no node, no edge, no group – nothing to validate against, and no way to move a box without recomputing every line attached to it.SVG 和 HTML 虽然是坐标原生的，但层级太低。一个带标签的框本质上是一堆路径和 tspans；没有节点、没有边、没有组——无法进行校验，移动一个框时也无法在不重新计算所有连接线的情况下完成。

Draw.io XML has the right semantics but was designed as a GUI’s save format, not a generation target: verbose, cryptic, and expensive in tokens.Draw.io XML 具有正确的语义，但它是作为 GUI 的保存格式设计的，而非生成目标：它冗长、晦涩，且消耗大量 Token。

Graphviz, D2, and PlantUML are excellent relationship languages that, like Mermaid, hand layout to an engine.Graphviz、D2 和 PlantUML 是优秀的关系语言，但和 Mermaid 一样，它们将布局交给了引擎。

And yes, we know that ours is yet another standard. And our bet is that semantic nodes and edges, plus explicit coordinates, plus strong defaults, designed for token-efficient LLM emission is a genuinely unoccupied point in this space – not a fifteenth standard for an occupied one.是的，我们知道这又是一个新标准。但我们深信，针对大语言模型生成而设计、具备语义化节点与边、支持显式坐标、且拥有强大默认值的格式，在这一领域确实是一个尚未被占据的空白点——而不是在已有标准之外再增加第十五个标准。

What it looks like它看起来是什么样的

{
  "entities": [
    { "tag": "Icon", "id": "client", "icon": "user",
      "x": 190, "y": 40, "texts": [{ "text": "Client" }] },
    { "tag": "Group", "id": "vpc", "color": "blue",
      "x": 40, "y": 190, "width": 420, "height": 190,
      "title": { "text": "Production", "icon": "server" } },
    { "tag": "Icon", "id": "api", "icon": "node",
      "containerId": "vpc", "x": 190, "y": 270,
      "texts": [{ "text": "Orders API" }] },
    { "tag": "Icon", "id": "db", "icon": "postgres",
      "containerId": "vpc", "x": 350, "y": 270,
      "texts": [{ "text": "Postgres" }] }
  ],
  "connections": [
    { "from": "client", "to": "api",
      "label": "HTTPS", "endArrowhead": "triangle" },
    { "from": "api", "to": "db",
      "label": "reads", "endArrowhead": "triangle" }
  ]
}

Three principles shaped the design:设计遵循三个原则：

Trivial to bootstrap. Strong defaults for styles, icons, spacing, and typography mean an LLM – or a human – can emit a handful of lines of JSON and get something presentable. Icons resolve by name, connections route themselves, and a PNG falls out the other end; none of it needs extra code to wire up.极易上手。样式、图标、间距和排版的强大默认值意味着大语言模型（或人类）只需输出几行 JSON 即可得到美观的图表。图标通过名称解析，连接线自动路由，最后直接生成 PNG；这一切都无需额外的代码配置。

Deeply customizable. Every default is overridable – styling, connectors, animation (coming soon) – and you can define your own components. A tag is simply a schema plus markup and CSS. You can add a custom card shape, a UML class box, or a Gantt bar. Or narrow instead of extend: restrict which colors are legal, or bundle styling into named variants.高度可定制。每个默认设置都可以覆盖——包括样式、连接器、动画（即将推出）——你还可以定义自己的组件。标签只是架构、标记和 CSS 的组合。你可以添加自定义卡片形状、UML 类框或甘特图条。你也可以进行限制：规定哪些颜色合法，或者将样式捆绑为命名变体。

Inert by default. LLM output you intend to render can be an attack surface if it needs to be computed. However, since JSON is data, not code, it can be schema-validated before anything touches a browser. Our component dialect deliberately cannot compute: no arithmetic, no string building, no arbitrary execution. Icons are sanitized fail-closed. You can safely accept the diagram output even though you don’t control the LLM that created it.默认惰性（Inert）。如果大语言模型的输出需要计算才能渲染，那它可能成为攻击面。然而，由于 JSON 是数据而非代码，它可以在进入浏览器之前进行架构校验。我们的组件方言刻意不支持计算：没有算术运算，没有字符串构建，没有任意执行。图标经过清理且默认关闭。即使你无法控制生成图表的大语言模型，你也可以安全地接收其输出。

Why we’re open sourcing it为什么我们要开源它

Because it’s the fastest way to the largest impact. If human comprehension is the bottleneck on human–agent collaboration, the fix shouldn’t live inside any one product. We want this format everywhere an agent needs to show a human what it did: agent frameworks, PR bots, documentation pipelines, and IDEs.因为这是实现最大影响力的最快途径。如果人类理解能力是人机协作的瓶颈，那么解决方案就不应该局限于某一个产品内部。我们希望在任何智能体需要向人类展示其工作的地方都能使用这种格式：智能体框架、PR 机器人、文档流水线和集成开发环境（IDE）。

And here’s the candid business logic: we’re commoditizing the format and betting we can build the best tools and services on top of it. MIT licensed, free for commercial use, closed to contribution.坦诚地说，我们的商业逻辑是：我们将格式商品化，并押注于基于此构建最好的工具和服务。采用 MIT 许可，免费用于商业用途，但不接受贡献。

The spec, renderer, and examples are at github.com/eraserlabs/eraser-diagrams. Tell us where it breaks.规范、渲染器和示例请见 github.com/eraserlabs/eraser-diagrams。欢迎反馈它的不足之处。