2026 年 7 月 15 日，开发者 Simon Willison 在查看 xAI 新近开源的 Grok CLI 编程代理代码时，发现了一段用 Rust 编写的 Mermaid 终端渲染器。随后，他借助 Claude Code for web 将其编译为 WebAssembly，做成浏览器工具 grok-mermaid。
用户输入 Mermaid 语法，页面会输出由 Unicode 字符组成的流程图，还能调整最大宽度、复制纯文本或生成分享链接。这件事的技术门槛不算高，意义也不在“浏览器终于能画 Mermaid”。更准确的判断是：AI 编程代理与 WebAssembly 正在压缩开源代码的再利用成本，一段藏在 CLI 项目里的内部组件，可以很快变成独立可用的小工具。
Grok CLI 的 Rust 渲染器，被直接编译成了 WebAssembly
这段代码来自 Grok CLI 仓库中的 `xai-grok-markdown/src/mermaid.rs`。源码将其描述为一个“自包含的 Mermaid 图表终端渲染器”。
Willison 没有重写一套 JavaScript 版本，而是保留 Rust 实现，将代码编译成 WebAssembly，再封装成网页界面。这里应当叫“跨环境复用”，而非“跨语言移植”：核心逻辑仍是原来的 Rust，只是换到了浏览器执行。
公开截图展示了一张请求处理流程图，包含：
graph TD的自上而下布局- 普通节点与判断节点
- 带文字的分支连线
- 实线、虚线和粗线箭头
- 401、429、200 等响应节点
这足以证明基础流程图可以工作，但不能据此推断它兼容完整 Mermaid 语法。原帖也没有提供语法支持清单、性能测试、浏览器兼容范围或复杂图表的渲染结果。
另一个容易被误读的地方是，这并非 xAI 正式发布的浏览器产品，而是外部开发者对开源代码的一次再利用实验。把它上升为 xAI 的产品战略动作，证据不足。
纯文本图表没有取代 SVG，但更适合终端和 AI 编程场景
Mermaid 原本就能在浏览器中渲染图表，官方 Mermaid.js 通常输出 SVG；官方命令行工具 @mermaid-js/mermaid-cli 则可生成 SVG、PNG 或 PDF。grok-mermaid 的差异不在“能不能画”，而在输出结果仍是文本。
| 路线 | 主要输出 | 更适合的场景 | 现实代价 |
|---|---|---|---|
| Mermaid.js | SVG | 网页、文档站、正式展示 | 需要浏览器渲染环境，输出不便直接贴进终端 |
| Mermaid CLI | SVG、PNG、PDF | 构建流程、发布文档、导出图片 | 工具链和运行依赖通常更重 |
| grok-mermaid | Unicode 框线文本 | 终端、日志、代码审查、AI 对话 | 布局精度和语法覆盖可能有限 |
Unix 工具链长期偏爱纯文本，并非审美保守，而是文本容易搜索、复制、比较和进入管道。到了 AI 编程代理场景，这个旧习惯又有了新用途：代理可以在终端里直接展示流程，不必生成图片，也不必要求用户打开额外文件。
这对两类人最实际。
一类是 CLI 和编程代理开发者。如果产品需要在终端显示调用链、状态机或请求流程，grok-mermaid 提供了一条较轻的实现路径。团队可以先用现成页面验证效果，再决定是否把 Rust 组件接入自己的工具。
另一类是维护技术文档的工程团队。纯文本图适合放进 issue、代码评审和故障记录，但正式文档仍应优先使用 Mermaid.js 或 Mermaid CLI 输出的 SVG、PNG。前者便于沟通，后者更适合交付，两者不必二选一。
生产采用前，语法覆盖和字符宽度比“能运行”更关键
Unicode 框线图有一个老问题：字符宽度并不总是稳定。不同终端、字体和操作系统可能采用不同的宽度计算规则。英文标签通常问题较少，换成中文、表情符号或混合字符后，边框和箭头可能错位。
Mermaid 本身也不只有流程图。序列图、类图、状态图、甘特图和 ER 图的布局逻辑差异很大。当前演示只能确认部分流程图语法可用，不能证明这些图表都能正确转换。欲速则不达，生产接入前至少要补做三类测试：
- 用团队现有 Mermaid 文件检查语法覆盖
- 在常用终端中测试中文和宽字符对齐
- 核对上游仓库许可证、更新方式及维护责任
原帖没有给出基准测试，也没有承诺长期维护。如果只是临时查看流程图，直接使用 在线工具 已经足够；如果准备嵌入企业 CLI 或文档流水线，更稳妥的做法是保留官方 Mermaid 渲染作为兜底。
接下来真正该观察的，不是页面又增加多少按钮，而是项目能否公布明确的语法支持矩阵、建立复杂图表测试集，并处理中文字符宽度。这三项决定它会停留在有趣的演示，还是成为可靠的终端组件。