一位开发者在大规模用 AI 批量产出 Web 工具时，将设计锁定方式分三阶段演进。此前文章收到评论，希望看到 JSON 方案与设计系统方案并排对比。作者实际构建并测量了这条未走的路，将两种方案在匹配测试条件下并排展示。
测试条件：同一 BMI 计算器，两侧各用独立 Claude Opus 4.8 会话，只交给 AI 对应方案的「工具包」，一次性生成、不做后续修改，且不让任一侧读取生产版 BMI 计算器。JSON 方案交出条目 schema（4 个结构键加 7 个模板读取的字符串键），AI 写出 34 行完全符合 schema 的目录条目；设计系统方案交出 BMI 固定模板、构建指南、模式集合、模板规范，AI 写出 313 行页面模板及 5 种语言词典。
并排看，JSON 方案页面显单薄，但作者指出这并非方案本身缺陷——把该时代机制构建到当前同等水平，外观应一致。明暗主题差异也非方案区别，只是各自延续了当时实际配置。真正差异在两种方案的「磨损方式」：JSON 方案固定模板在 JavaScript 侧硬编码了 WHO 四段标签英文，无对应 JSON 键，导致日语和西班牙语版本判定结果仍显示英文；设计系统方案则当场生成全部五种语言的四段标签。
设计系统方案也有两处瑕疵：一处是类列表中混入被禁止的 bg-white，虽无实际效果但违反规则，只能靠机器检查类字符串发现；另一处是刻度标记视觉上难以辨认指向位置，无规范约束，机器检查无法捕获。
作者在不破坏 JSON 方案规则的前提下扩展至同等表达水平：目录条目从 34 行增至 343 行，schema 词汇从 11 词增至 113 词，渲染器从 433 行增至 914 行，而 BMI 专用模板从 53 行缩至 1 行。扩展后条目比设计系统方案一次性写出的模板还大。计算公式移入 JSON 后由 AI 编写，变量名拼错或顺序错误会静默变成 NaN，实际还遇到浮点运算顺序问题。作者此前预测「继续增肥 schema 和渲染器，最终会走向手工重建 HTML 和 CSS」，此次首次成为真实产物。
两种方案本质是两种一致性保障哲学：JSON 方案属预防型，AI 可用的颜色和部件固定，漂移在构造上不可能发生，但所有新增表达都堆在 AI 之外，工具越多共享渲染器越臃肿；设计系统方案属检查型，AI 自由组装、成本低、可随工具数量扩展，但一致性依赖检查与修正之网的精度，无规则约束的缺陷会漏过。检查型成本未体现在本次一次性对比中，因为作者刻意未运行检查流程——实际运营中每个生成工具都要过机器检查和人工检查，最多修三轮。作者最终选择设计系统方案，因其有数百个外观各异的 Web 工具，无法按类型归并。验证于 2026 年 8 月，环境为 Claude Opus 4.8 生成、Playwright headless Chromium 截图。
#开发者 #工具 #AI #JSON #设计系统 #Web开发 #前端 #Claude #Opus48 #BMI计算器
@DevToolboxHub