Tavero 检查 AI 生成界面的样式偏移

用 coding agent 写 React 页面，单看每页都过得去，放在一起却像几套产品：按钮圆角不同，卡片间距各异，主色也总差一点。作者开发的免费开源工具 Tavero，就是把这些视觉漂移找出来，定位到源码，再交回 agent 修复。

它的思路值得看：扫描浏览器实际渲染的结果，用项目组件和设计令牌作为参照，再通过 MCP 把发现、修改和复查串起来。不过，检测出差异和判断差异是否合理，仍然是两件事。

页面为什么会越写越不像同一个产品

作者给出的原因很具体：agent 每次都在页面里重新写按钮，因为它不知道，或者忘了项目里已有 src/components/Button.tsx。

于是 Team 出现灰底黑边按钮，Reports 用胶囊形，Settings 用红色，Billing 则用了接近主色、但不完全相同的 #4263eb。每一次局部生成都能成立，累积起来却破坏了统一性。

Tavero 从运行中的 React 应用取样，覆盖 mobile、tablet、desktop 三种宽度，检查四类问题：

• Buttons：识别不同按钮样式、近似重复样式，以及绕过共享组件直接写在页面里的按钮。
• Cards：比较卡片容器的背景、边框、圆角、内边距和阴影。
• Colors：找出设计令牌之外的颜色，提供最近的令牌及字面量位置。
• Scales：检查圆角、间距、字号和阴影是否落在令牌声明的尺度内。

设计令牌（design tokens）可以理解为项目认可的样式取值表。Tavero 不只是说「看着不统一」，而是指出「这里用了什么，项目规定了什么」。

作者的 Acme 演示包含 6 个页面、3 种宽度，找出了 7 种文字按钮样式。下面的结果把共享按钮和页面自写按钮放在一起比较：

Button "primary" · canonical · 9 renders
  src/components/Button.tsx:4  bg #3b5bdb, radius 6, padding 10/16, 14px/600
written in Team · 3 renders
  src/pages/Team.tsx:6         bg #f0f0f0, radius 0, padding 1/6, 13px/400, border 2px #000
written in Settings · 3 renders
  src/pages/Settings.tsx:12    bg #e03131, radius 4, padding 10/16, 14px/600
written in Billing · 3 renders
  src/pages/Billing.tsx:8      bg #4263eb, radius 8, padding 11/18, 14px/600

重点看 src/pages/Billing.tsx:8：它与共享按钮的差别同时涉及颜色、圆角和间距。单独修正颜色，并不等于整个按钮已经统一。另一个尺度检查还发现了 4px、8px、14px、999px 圆角，而项目声明值是 10px、6px。

怎样让 agent 根据发现完成修复

Tavero 以 MCP server 运行。MCP 在这里承担的作用，是让 agent 直接调用检查工具并读取结果。

整个过程从 tavero_context 开始：用约 1,500 tokens 提供标准组件、令牌和约定。示例里明确告诉 agent，操作按钮应使用 src/components/Button.tsx 的 Button，通过 variant 选择变体；令牌包括 --acme-primary #3b5bdb、--acme-radius 10px 和 --acme-space 16px。

接着，tavero_findings rule=colors 列出颜色问题，tavero_finding f_ff30adc07c 展开具体位置：src/app.css:33 写死了 #4263eb，建议改用 var(--acme-primary)，与目标颜色的差异标为 ΔE 3.5。

修改后调用 tavero_scan routes=/billing rules=colors，只复查相关路由和规则，再用 tavero_diff 确认问题是否进入 resolved 列表。

修复是否完成，要由复查结果确认。

作者报告，这次运行使用 Claude Code 和 Opus 5.5，在 Acme 演示副本上没有使用 shell，耗时 29 秒，共 10 轮。这是一次具体演示的成绩，不能直接当作普通项目的速度承诺。

接入 Claude Code 时，把下面的配置放进 .mcp.json：

{
  "mcpServers": {
    "tavero": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "tavero", "mcp"]
    }
  }
}

关键是 args 这一行，它通过 npx -y tavero mcp 启动服务。Cursor 使用相同配置块，文件位置是 .cursor/mcp.json；tavero mcp --print-config 还能打印 Codex、Gemini CLI、Antigravity、VS Code 和 Windsurf 的配置。

我的判断

我认同它把「检查结果」变成 agent 可执行任务的方向。相比只在提示词里提醒遵守设计规范，文件、行号、当前值和建议值更容易形成明确的修改目标；相比人工逐页找差异，它也更适合反复检查。

但视觉不同，只能证明存在差异，不能直接证明存在错误。

作者也给人保留了决策入口：在本地面板用键盘逐项标记。Fix 表示确认要修，agent 优先看到；Intended 表示有意如此，在该发现扩大前对 agent 隐藏；Canonical 则把某个变体命名为参照。还可以附留言，决策会在 agent 下次调用时送达，无须重新扫描。不过，原文没有解释「发现扩大」具体如何判定。

它还依赖项目已有可信的组件和令牌。若规范本身混乱，最近的颜色令牌也未必符合业务语义。原文没有给出误报率、大型项目表现，也没有与 lint、视觉回归测试的对照数据，因此目前更适合把它视为一种可尝试的检查方式。

能拿来做什么

• 在 agent 开始写 React UI 前，先让它读取 tavero_context，明确共享组件和令牌，再生成页面代码。
• 把跨页面按钮、卡片和颜色检查放进验收流程，优先处理重复实现和偏离既定取值的问题。
• 遇到危险操作按钮等特殊样式，先人工标记意图，再交给 agent 修改；每次修改后按相关路由和规则复查，并查看 tavero_diff。