设计工程师的Agent技术栈

设计工程师需要一套与纯工程师截然不同的Agent技术栈。 标准Agent基础设施以正确性为优化目标：测试通过、类型检查无误、lint规则成立。但至今没有人为设计质量构建同等的基础设施——确保Agent产出的作品看起来经过深思熟虑，而非仅仅能用。设计工程师Agent技术栈的六大组件分别是：字体排版钩子、色彩系统钩子、布局验证、Lighthouse门禁、无障碍lint检查，以及视觉回归测试。它们共同将工艺标准编码到流水线中。

这一差距在每个AI生成的界面中都清晰可见。间距不一致，字号偏离了预设的比例尺，硬编码的十六进制值绕过了token系统，移动端出现布局偏移——因为Agent修改CSS后无人检查CLS。Agent通过了所有测试，满足了所有类型检查，产出了代码审查员会认可的结果——因为代码审查员评估的是逻辑，而非视觉一致性。设计工程师一眼就能发现问题，Agent基础设施却毫无察觉，因为从未有人告诉它该看什么。

面向工程师的Agent基础设施已经快速成熟。钩子阻止危险的git命令，证据门禁要求在标记工作完成前提供证明，质量循环强制要求逐行复查。工程质量可分解为可验证的属性（正确性、性能、安全性、类型安全），每个属性都能映射到一个产生二元结果的工具。

设计质量同样可以分解。品味是一个技术系统，包含四个可编码的组成部分：约束、评估标准、模式识别和整体协调性。前三者可以直接映射到自动化基础设施，整体协调性则需要人类判断。但仅凭这三个维度，就足以防止Agent产出中最常见的设计缺陷。字体排版违规、色彩偏移、布局不稳定、性能回退和无障碍功能失败——这些都可以被机器检测。设计工程师的Agent技术栈正是为此而生。

设计工程师对Agent的需求

纯工程师只问一个问题：代码能跑吗？设计工程师还会追问六个问题，每个都指向视觉质量的不同维度。

视觉一致性。 间距值遵循8像素网格或既定的间距比例。对齐遵守垂直韵律。元素间的比例关系在不同视口尺寸下保持稳定。如果Agent在添加新卡片组件时使用了margin-top: 13px而非var(--space-md)，它就引入了任何测试都捕捉不到的视觉噪声。

字体排版规范。 代码库中每个字号都对应字体比例尺中的某一级。不允许出现游离的尺寸，不允许内联覆盖绕过自定义属性。字重使用遵循既定层级：标题700、正文400、元数据300。如果Agent将副标题设为font-size: 19px，它就凭空创造了比例尺中不存在的一级，视觉层级随之崩塌。

色彩系统合规。 每个颜色值引用设计token，:root和设计token定义之外不允许硬编码十六进制值。对比度至少满足WCAG AA标准，尽可能达到AAA。我网站上的零色彩系统在纯黑底色上使用四个不透明度层级，每一级都通过AAA标准。如果Agent引入了color: #cccccc，它就绕过了token系统，创造了一个未经验证的对比关系。

性能意识。 零累积布局偏移，首次内容绘制保持在预算之内，总阻塞时间不允许回退。Agent必须理解视觉变更会带来性能后果。一个在每次滚动事件中触发布局重算的CSS修改就是性能缺陷，无论它看起来如何。

无障碍性。 语义化的HTML结构、正确的标题层级、必要时添加ARIA属性而非滥用、色彩对比度验证、焦点指示器、屏幕阅读器兼容性。Lighthouse审计能捕获可量化的子集，但Agent还必须维护自动化工具遗漏的结构语义。

品味。 最难编码的维度。元素之间的协调性、装饰的克制、刻意的留白而非偶然的空洞。品味是区分”遵循了每条规则却感觉不对”和”遵循了每条规则且恰到好处”的关键品质。自动化检查捕获违规，品味层则捕获那些”没有违规却缺乏考量”的问题。

设计工程师技术栈的六大组件

每个组件都对应我在Agent生成输出中观察到的一类具体失败模式。这些组件并非理论构想——每一个之所以存在，都是因为出过问题。这和我95个钩子基础设施中每个钩子的诞生故事如出一辙。

1. 字体排版钩子

字体排版钩子验证提交中每个font-size声明是否引用了字体比例尺中的CSS自定义属性。钩子扫描变更文件，查找未映射到已定义级别的原始像素或rem值。

#!/bin/bash
INPUT=$(cat)
DIFF=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Catch font-size declarations that bypass the type scale
if echo "$DIFF" | grep -qE 'font-size:\s*[0-9]+(px|rem|em)'; then
  cat << EOF
{"decision": "block", "reason": "Font size must use a --font-size-* token"}
EOF
fi

这个钩子比较粗糙。更精细的版本会解析数值，检查其像素等价值是否匹配13级比例尺中的任一级别。关键不在于精巧程度，而在于Agent无法在基础设施不标记的情况下引入游离字号。Bringhurst关于和谐字体关系的原则之所以成立，不是因为Agent理解和谐，而是因为钩子强制执行了体现和谐的比例尺。¹

字重也值得单独验证。我的系统使用三种字重：700、400和300。如果Agent将卡片标题设为font-weight: 600，它就引入了一个与既定层级相矛盾的字重。字体排版钩子在这种偏差进入生产环境之前就将其拦截。

2. 色彩系统钩子

色彩偏移是Agent生成的CSS中最常见的设计缺陷。Agent知道深色背景上的文字应该是白色的，但Agent不知道#ffffff应该写成var(--color-text-primary)，也不知道65%不透明度的次要文字是var(--color-text-secondary)而非rgba(255,255,255,0.60)。

色彩钩子扫描:root和设计token定义之外的硬编码颜色值：

# Block hardcoded colors outside token definitions
if echo "$DIFF" | grep -vE '^\+.*:root' | \
   grep -qE '#[0-9a-fA-F]{3,8}|rgba?\('; then
  cat << EOF
{"decision": "block", "reason": "Use color tokens, not hardcoded values"}
EOF
fi

零色彩设计系统——驱动整个网站视觉身份的那个粗野主义约束——使执行变得简单明了，因为调色板总共只有十个token。任何不匹配这些token的颜色值按定义就是错误的。更丰富的调色板需要更细致的验证。基于约束的方法简化了钩子，因为约束本身简化了设计。

3. 布局验证

布局验证捕获两类失败：CSS变更引入的累积布局偏移，以及响应式断点回退。

CLS检测需要测量变更前后的页面状态。预提交钩子无法运行浏览器，但CI流水线可以。基础设施在无头Chrome中对预发布部署运行Lighthouse，将CLS值与上一次构建进行比较，如果差值超过0.01就阻止合并。Google认为CLS低于0.1为”良好”，我的阈值严格10倍，因为我见过0.493的CLS是什么样子，绝不允许回退。

响应式验证需要在定义的断点下检查布局。视觉回归工具在375px（手机）、768px（平板）和1440px（桌面）分别截图，然后与基线图像对比。在375px下头部发生的5像素偏移在1440px下看起来正常，但在移动端对比中就会暴露。修改了max-width属性却未测试响应式行为的Agent，会被自动执行响应式测试的基础设施捕获。

4. Lighthouse门禁

Lighthouse门禁在每次合并到主分支之前运行完整审计。门禁强制执行四个阈值：

这些阈值并非愿景目标，而是反映了当前生产环境的实际得分。任何使任一分数降到100以下的提交都会被阻止。门禁在CI中使用lighthouse-ci运行，结果作为状态检查反馈到拉取请求中。

# lighthouse-ci configuration
assertions:
  performance: ["error", { minScore: 1 }]
  accessibility: ["error", { minScore: 1 }]
  best-practices: ["error", { minScore: 1 }]
  seo: ["error", { minScore: 1 }]
  cumulative-layout-shift: ["error", { maxNumericValue: 0.01 }]

Lighthouse门禁能捕获人类审查员不会注意到的性能回退。如果Agent添加了未优化的图片、阻塞渲染的脚本，或触发无样式内容闪烁的CSS文件，门禁会在变更到达生产环境之前将其阻止。门禁不需要理解变更为何导致了回退，它只需阻止回退，Agent会在下一次尝试的上下文中收到失败原因。

5. 无障碍lint检查

无障碍验证分为两层：静态分析和运行时评估。

静态分析对渲染后的HTML运行axe-core。WCAG 2.1 AA规则集可捕获缺失的alt文本、不当的标题层级、不足的色彩对比度、缺失的表单标签和ARIA误用。检查在与Lighthouse门禁相同的无头Chrome实例中运行，几乎不增加额外开销。

// axe-core integration in CI
const { AxeBuilder } = require('@axe-core/playwright');
const results = await new AxeBuilder({ page })
  .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
  .analyze();

if (results.violations.length > 0) {
  process.exit(1); // Block the merge
}

运行时层捕获静态分析遗漏的问题：HTMX替换后的焦点管理、动态内容的键盘导航、状态变更的屏幕阅读器播报。这些检查需要脚本化交互，而非仅仅DOM检查。无构建方案使页面足够简洁，无障碍覆盖面保持在可控范围内。

无障碍lint是大多数工程师已经熟悉的组件。设计工程师的独特贡献不在于工具本身，而在于阈值：零违规，而非”可接受的”违规。这与追求100/100/100/100 Lighthouse满分的理念一脉相承：以完美为基线，而非期望。

6. 视觉回归测试

视觉回归测试将当前构建的截图与已批准的基线进行对比。对比使用感知差异算法，能检测人类会注意到的变化，同时忽略人类不会注意到的差异（亚像素渲染差异、抗锯齿变化）。

Percy、Chromatic和BackstopJS等工具可以自动化对比流程。流水线在每个定义的断点截图，对基线运行感知差异分析，标记差异超过阈值的页面。页脚中0.1%的像素差异是噪声，但主视觉区域2%的偏移就是回退。

视觉回归是”页面看起来对不对？”这个问题最接近的自动化近似。感知差异分析无法评估布局变更是改进还是退化，只能判断发生了变化。人类审查被标记的差异并决定批准或驳回。自动化的价值在于覆盖率：在每次提交时对每个页面在每个断点进行测试——没有人类会手动完成这项工作。

技术栈如何映射到我的基础设施

这六大组件与我网站上设计工程系列内容中已记录的决策紧密相连。

字体排版钩子强制执行13级字体比例尺——一个内容驱动的递进体系，比例尺以CSS自定义属性的形式存在，钩子确保这些属性是代码库中唯一的字号来源。色彩系统钩子强制执行零色彩设计系统：十个token、四个不透明度层级、无品牌色、不可选择。Lighthouse门禁维护100/100/100/100的满分，防止任何提交撤销为达到这些分数而进行的CSS提取和渲染阻塞消除工作。

无构建方案简化了整个技术栈。无需协调source map，无需处理tree-shaking的歧义，编写的CSS和发布的CSS之间没有转译层。Agent写的就是最终发布的，这意味着钩子验证的就是用户看到的。

证据门禁同样适用于设计审查，正如它适用于工程审查。”字体排版看起来没问题”不是证据。”diff中的每个font-size声明都映射到一个--font-size-* token，经字体排版钩子验证”才是证据。设计系统提供了钩子所执行的token。没有token，就无从验证。没有钩子，token就只是建议。Nathan Curtis精准地识别了这一动态：一个缺乏治理的系统会退化为无人阅读的文档。²

品味层

六大组件捕获违规。字体排版钩子捕获错误的字号，色彩钩子捕获硬编码值，布局验证捕获CLS，Lighthouse门禁捕获性能回退，无障碍lint捕获WCAG违规，视觉回归捕获意外变更。

但这些都无法捕获那些遵循了每条规则却仍然感觉不对的输出。

一个拥有正确字号、合规token、零CLS、Lighthouse满分、完整WCAG合规、无视觉回退的卡片组件——但标题紧贴图片令人窒息，行宽影响可读性，悬停状态显得突兀而非精心设计。所有自动化检查都通过了。卡片是正确的，但卡片并不好。

品味运行在规则层之上。约束捕获违反规则的内容，评估标准捕获未达标的指标，模式识别捕获第二遍审视才能发现的问题，整体协调性捕获只有全局视角才能暴露的缺陷。六个自动化组件处理约束和评估标准。模式识别和整体协调性则需要质量循环：对工作进行强制的第二遍（第三遍、第四遍）审查，每次检验的不是规则是否成立，而是结果是否值得发布。

质量循环是设计工程师赢得”工程师”这半个头衔的地方。发布通过测试的代码只是及格线。发布既通过自动化检查又经受住质量循环考验的界面，意味着维护着机器尚无法评估的标准。Pride Check提出五个问题，最后一个（”我是否让它变得更好了？”）没有自动化等价物。Steve标准同样如此：Blake会在这上面签名吗？

复合效应

每个组件防止一类特定的设计失败。组合在一起，这些组件产生的复合效应超越了各项检查之和。

没有这套技术栈的Agent会话会产生漂移。字号在比例尺之外逐渐累积，颜色值硬编码而非token化，性能以微小的增量回退——单次提交不会触发警报，但数周累积下来变得显而易见。这种漂移在任何单个diff中都看不见，在总量上却一目了然。

有了这套技术栈的Agent会话无法漂移。钩子阻止每一次偏离字体比例尺的行为，色彩系统拒绝每一个硬编码值，Lighthouse门禁捕获每一次性能回退。Agent继承了设计工程师的标准，不是因为Agent理解这些标准，而是因为基础设施强制执行了它们。Agent不需要品味，Agent需要约束，而约束体现了品味。

Jony Ive将Apple的设计流程描述为”不懈的精炼”：通过在固定原则上反复迭代来实现质量，而非通过新奇来追求创新。³设计工程师的Agent技术栈将这一理念操作化了。原则固化在token、比例尺和阈值中，精炼永不停歇，因为自动化在每次提交时都会运行。

将标准编码到Agent技术栈中的设计工程师所做的不仅是在自主生成过程中维护质量，更是在规模化质量。每次会话、每个Agent、每次提交都继承同样的约束。人类仍然评估协调性，仍然运行质量循环，仍然追问输出是否值得发布。但人类不再需要捕获字号违规、硬编码颜色或CLS回退——技术栈已经先行拦截。人类的注意力得以完全集中于机器无法回答的问题。

常见问题

是否需要同时部署全部六个组件？

不需要。从解决最常见失败模式的组件开始。字体排版钩子和色彩系统钩子提供最高回报，因为它们捕获Agent生成的设计缺陷中最频繁的类型。接下来添加Lighthouse门禁和无障碍lint。视觉回归和布局验证对基础设施要求最高，适合在后续阶段引入。

技术栈是否兼容构建工具？

兼容任何前端架构。无构建方案简化了实现，因为编写的代码和发布的代码之间没有转换层。使用构建工具时，钩子需要验证源文件，而Lighthouse和视觉回归验证构建后的输出。组件不变，集成点不同。

Agent能否在没有技术栈的情况下学会品味？

当前的大语言模型不具备品味。模型产出统计学上最可能的输出，而统计上最可能的输出趋向于训练数据的中位水平。技术栈不是在教Agent品味，而是约束Agent，使流水线在缺乏品味的输出发布之前就将其拒绝。这一区分至关重要：将品味编码为基础设施，比寄希望于模型从提示词中内化品味要可靠得多。

视觉回归测试如何处理有意的变更？

有意的变更会产生预期的视觉差异。工作流标记差异，人类审查并批准后更新基线。视觉回归的价值不在于阻止变更，而在于暴露意外变更。Agent修改了按钮颜色的同时，卡片布局也偏移了3像素。颜色变更是有意的，布局偏移不是，视觉回归测试会捕获这个副作用。

参考来源