北京
那天下午，我把一个架构描述扔进Claude，它返回了一张干净得让我愣住的SVG——布局工整、图标恰当、配色甚至有点设计师的审美。我盯着屏幕滚动，心里跳出一个很具体的念头：这东西能不能直接塞进我的CI流水线？能不能在我自己的产品里，让用户点个按钮就吐出一张类似的图？我打开终端敲了npm install，然后才意识到，Claude Artifacts没有包名，没有API端点，也没有暴露任何可嵌入的渲染路径。那只是聊天框里一个漂亮的功能，不是我可以调用的基础设施。
如果你也曾经被这种“看起来什么都能做，但什么都带不走”的瞬间击中过，大概就明白为什么我非要做Glyphic。Claude证明了大型语言模型完全有能力描述一张好图——这个认知已经被验证了，不需要再讨论视觉质量够不够。真正没被解决的，是那一步之后的事情：你拥有这套绘图能力吗？你能在自己选的运行环境里调用它吗？你能在模型切换时，依旧用同一个渲染管道生成图表，而不用把前端逻辑重写一遍吗？答案很统一：不能。而这个“不能”，恰恰是我动手的起点。
当时摆在面前的选择，掰着指头数就三个。Claude Artifacts本身，输出确实美，但它锁定在Claude的云端，没有编程接口，不能从LangChain里调用，不能部署到Lambda，更不可能嵌入你自己的SaaS产品。它只是一个功能，不是一块积木。另一条路是Mermaid、D2、Graphviz这些开源方案，直觉上是对的，开源且可嵌入，可一旦走到服务端渲染，问题就来了。Mermaid依赖无头浏览器，服务器上得拖一个大约300MB的Chromium，冷启动要用秒算，而且浏览器进程出现在你的代理循环里，稳定性天然打折。D2是Go二进制，带着自己的领域特定语言，Graphviz是上世纪九十年代的C依赖。更关键的是，它们全都依赖文本DSL——一种脆弱的语法，一个拼写错误就能让整个渲染崩溃。而这些DSL，从来就不是为了“让机器稳定地写”而设计的，更别指望流水线放心消费。
所以Glyphic被设定在一个完全不同的前提上：模型用严格类型化的JSON来描述图“意味着什么”，一个确定性的引擎接管布局和渲染。没有DSL可出错，没有浏览器横在技术栈里，也没有厂商锁定。这份JSON会被Zod模式严格校验，一旦模型输出有偏差，返回的是可修复的错误信息，而不是蓝屏式崩溃。这意味着任何能吐出JSON对象的模型——Claude、GPT、Gemini、Llama、Mixtral，甚至你笔记本上微调过的7B模型——都能驱动Glyphic。切换模型、混合使用、本地运行，这些都不会给渲染层造成任何涟漪。你不用再为某个模型的图表能力，去绑架整个技术选型。
把无头浏览器从流程里拿掉，是我刻意保持的干净结构。所有“服务端渲染图表”的路径我几乎都翻过一遍，最后总是落在Chromium的壳上。Glyphic不做这件事，布局靠数学图引擎ELK、d3-hierarchy和d3-sankey直接算，SVG转PNG由Rust写的@resvg/resvg-js原生完成，全程在进程内，没有DOM，没有浏览器。真实收益很直白：你可以把引擎部署到Lambda、Cloud Run、边缘计算节点、CI运行器、Docker容器里，不用装Chromium，不用填--no-sandbox标记，也不用忍受冷启动税。SVG生成耗时5到15毫秒，全原生PNG光栅化大约800毫秒——依旧远快于启动一个浏览器。整个引擎不过是一次正常的npm install，没有300MB的二进制包袱。这就是我想要的“可拥有的基础设施”：你自己掌控，随处嵌入，不绑定任何模型，而且跑得飞快。
回头来看，这个方向的选择比一个开源工具的命名更重要。当图表生成这件事被从聊天框里拆出来，变成可独立调用的渲染管道，它改变的其实是AI代理和流水线之间的耦合方式。一个代理产生洞察、描述关系，而glyphic只负责把这种描述变成视觉事实，不关心模型是谁、不限制部署位置。它让“用模型画图”从某个产品的功能，变成工程团队可以随意组合、随处兜底的积木。这种自由，才是兴奋感的源头。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
