用 JSON 固化 AI 界面的得与失

批量使用 AI Agent 生成 Web 工具时，你迟早会撞上这堵墙：每次生成，设计都会发生漂移。明明使用相同的指令，颜色、间距和组件形状却总会出现细微差异。在维护覆盖五种语言地区的 600 多个工具时，我先后经历了三个试图锁定设计的阶段。每个阶段都有值得记录的失败教训。

阶段 1：用 JSON 定义 UI → 确实锁住了。然后呢

第一次尝试：使用 JSON 定义每个工具的 UI，再根据它生成页面。适用范围是没有图片预览的简单计算器类工具。标签、输入和输出都表示为 JSON 值，再通过固定的流水线渲染。

作为一种锁定机制，它确实有效。JSON 里写了什么，最终就渲染什么——不同生成批次之间的漂移消失了。

但生成出来的界面毫无生气。到处都是直线，连一条曲线都看不到。每个值都待在自己的小格子里。说得直白一点：它看起来就像电子表格。

事后来看，问题出在结构上。在 JSON 定义方案中，表现力的上限取决于 renderer 实现了什么。你当然可以不断给 schema 添加圆角、渐变和各种特殊间距，但这意味着 schema 和 renderer 会无休止地膨胀，而这条路走到最后，无非是重新发明一遍 HTML 和 CSS。

消灭设计漂移的机制，也一并扼杀了设计的表现力。

阶段 2：锁定 design tokens，而不是 layout

策略调整：不再锁定结构（layout），只锁定身份特征（由颜色、字体、圆角和间距构成的系统）。

具体来说，以一份 CSS variables 文件作为唯一权威来源，所有工具只能使用其中的变量，包括调色板、字体、圆角和阴影。与此同时，再维护一套持续演进的 UI kit——它是一份可以直接在浏览器中打开的参考实现。“这个项目的卡片、按钮和输入框应该长这样”，通过实际运行的 HTML 表达，而不是写成一份规范。给 AI 的指令也从“严格按照这个 JSON 渲染”，变成了“使用这套 UI kit 中的组件和变量，自由组合 layout”。

结果是：layout 可以针对每个工具分别优化，同时品牌风格仍然保持一致。这相当于把阶段 1 的锁定粒度反转了。阶段 1 锁定一切，表现力随之消亡；阶段 2 只锁定 tokens，让组合方式保持自由。

还有一个有利因素：模型自身的设计能力随着每次发布不断提升。“自由组合”能够成立，前提是模型交付的组合效果足够好。阶段 1 的前提——“自由组合必然导致漂移”——在当时确实成立，但后来，时间让这个前提失效了。

阶段 3（现在）：有官方轨道，就沿着官方轨道走

如今，Claude Code 中的 skill 机制和官方 design-system 集成，正在覆盖越来越多“教会 AI 遵循你的设计规范”这类需求。真正还需要自行构建的部分正不断缩小，只剩下那些确实属于项目特有的内容：你的 tokens 和 UI kit。

从这段经历中可以带走什么

第一，“锁住了”并不等于“成功了”。评估一种锁定机制时，也要把它的副作用算进去。阶段 1 达成了目标，却依然失败了。

第二，要选择合适的锁定粒度。一路锁到 layout，得到的就是电子表格；只锁定 tokens，品牌一致性就能与组合自由并存。

第三，要给你的前提设定一个有效期。“自由组合必然导致漂移”曾经是事实，后来却不再成立。一旦某种机制赖以成立的前提已经崩塌，就应该抛弃这种机制。

阶段 1 的 JSON 方案并非在所有场景下都是错的。对于那些以结构统一为核心价值的输出——报告、表单，以及真正类似电子表格的产物——使用 JSON 定义依然是正确答案。我的场景是 Web 工具 UI，所以它并不适合。

这整个演变过程与 2025 至 2026 年间的模型能力提升同步发生。随着模型能力继续发展，最合适的锁定粒度也会不断变化。

时间范围：2026 年上半年（阶段 1 的 JSON 目录仍保存在 2026 年 3 月的一份备份中）。环境：Claude Code / 600 多个 Web 工具 × 5 种语言地区。

若要采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。