Show HN：Reladraw——一种由你决定事物摆放位置的图表语言

整体反响

• 许多评论者都很兴奋；不少人表示，这填补了自动布局工具（Mermaid、Graphviz、D2）与手动工具（Draw.io、Excalidraw）之间长期存在的空白。
• 一个常见痛点是：总得和布局引擎“搏斗”，才能贴合脑海中的图景；Reladraw 显式的相对放置方式被认为是一种解脱。
• 有人表示会在实际工作图表中尝试，或将其集成到笔记/IDE 工作流中（Obsidian、VS Code、IntelliJ）。

与现有工具的比较

• 与 Pikchr 和 pic 相比：那些更像“乌龟绘图”或基于坐标/偏移的方式；Reladraw 则是基于约束/关系的方式（例如“在 A 的右边”）。
• 与 Mermaid/Graphviz/D2 相比：那些会自动决定布局；Reladraw 让用户/代理决定摆放位置，但仍会处理算术和碰撞间距。
• 与 TikZ/PlantUML 相比：TikZ 更强大，但对 LaTeX 依赖更重；PlantUML 更灵活，但仍然偏向布局提示。Reladraw 旨在成为一个更窄、更直接的图表 DSL。
• 有人表示，D2 的 TALA 已经提供了高级的受约束布局，但也有人觉得它仍然无法像 Reladraw 那样给出确定性的控制。

语言设计与能力

• 强调节点、边，以及简单的相对关系（左/右/下/上）。
• 边支持直角（尖角/圆角）、样式（实线/虚线/点线）、粗细，以及带有侧边端口的连接，并且在同一侧有多条边时支持间距。
• 冲突或含糊的约束会产生明确错误，而不是静默覆盖；关于严格报错还是警告、以及合理默认值，存在讨论。
• 当前理念：不使用块结构，不使用多行语句；多位评论者请求支持续行和多行/长标签，并指出了解析器上的取舍。
• 计划中的功能：自定义属性、变量、函数、可能带参数的宏，以及更好的复用机制（例如用于序列图/C4 风格图表）。
• 讨论了从外部数据（CSV/JSON）进行参数化，以及更程序化的生成方式。

路由、主题与 bug

• 目前还没有完整的避障自动布线，但边可以“从节点之间穿过”；一些用户希望减少路由上的微操。
• 直角边和曲线边的行为仍在迭代中；有人报告了边曲率和主题方面的 bug，并且很快得到了修复。
• 现在已有多个主题（浅色/深色，包括一种类似“Vesper”的主题）；最初还提到过 Safari/主题方面的小故障。

生态与集成

• 已经存在一个用于渲染和语法高亮的 VS Code 扩展。
• 像 GitHub 上那样通过 mermaid 在 Markdown 中嵌入的方式，目前还做不到；本地工具可以通过插件来支持。
• CLI 目前输出的是渲染后的图表，但也有人希望有一种只输出已解析位置（JSON）的模式，这样就能使用其他渲染器/后端。
• 实现基于 TypeScript/Node；有人希望有更小、无依赖的二进制文件。提到了用 scriptc 和 Deno 等工具做实验，但在二进制体积上存在取舍。

AI/代理与工作流

• 多位评论者明确表示，希望这是一个“对代理友好”的图表 DSL：代理可以表达相对布局，而不是猜坐标或和自动布局较劲。
• 也有人主张更“视觉优先”的方式（纯视觉编程/UML），而另一些人则表示，让代理驱动 Draw.io 或 Graphviz 的效果也不错。
• 有人提到，他们现在往往只是提示前沿模型直接生成 SVG，但其他人认为一个稳定的 DSL 在可复现性和控制性方面很有价值。

批评与怀疑

• 有些人认为，在加入多行/续行支持之前，这种语法和约束对长标签和复杂布局可能会显得笨拙。
• 有人担心语言碎片化，以及是否应扩展 Mermaid 或 D2；另一些人则认为，把自动布局和强约束混在一起会过于复杂。
• 一位评论者质疑，如果项目的大部分看起来像是 LLM 生成的，那么它的价值何在，并由此对项目表示怀疑；而其他人则反驳了这种看法。
• 总体而言，大家对这个概念既感到兴奋，也认识到：长期采纳取决于易用性、复用能力和生态支持。