design.md：让AI Agent产出品牌一致的页面

从零散提示到统一设计规范

Vercel 团队近期分享了他们让 AI Agent 构建"品牌一致"（on-brand）页面的实践方案：核心是一个名为 design.md 的单一文件。这个看似简单的做法,背后其实回应了当前 AI 辅助前端开发中一个长期存在的痛点——AI 生成的界面往往在美学和品牌层面缺乏一致性。

当前主流的 AI Coding Agent（如 GitHub Copilot、Cursor、v0 等）本质上是基于大语言模型（LLM）的代码生成系统。这类系统在生成单个组件或页面时表现出色,但面对跨页面、跨会话的一致性要求时会出现明显短板。

LLM 的概率性生成与无状态特性

大语言模型（LLM）基于 Transformer 架构,通过自回归方式逐 token 生成内容。Transformer 是 2017 年 Google 提出的深度学习架构,彻底改变了自然语言处理领域。其核心创新是自注意力机制（Self-Attention）,允许模型在处理序列时同时关注所有位置的信息,而非像 RNN 那样逐步处理。自回归生成（Autoregressive Generation）是指模型按顺序生成序列,每次根据已生成的内容预测下一个元素。

每次生成时,模型会根据输入的上下文（prompt）计算下一个 token 的概率分布,然后通过采样策略（如 temperature 控制的随机采样或 top-k/top-p 截断）选择输出。这种概率性生成机制决定了即使输入相同的 prompt,每次输出也可能不同。更关键的是,标准 LLM 是无状态的——每次 API 调用都是独立的推理过程,模型无法在不同会话间保持"记忆"。

这就是为什么 AI Coding Agent 在生成单个组件时表现优异,但在需要跨页面、跨会话保持风格一致性时会出现问题：每次生成都是基于当前上下文的独立决策,缺乏持久化的设计约束来维持品牌连贯性。

当你让一个大模型或 Coding Agent 生成页面时,它会输出"看起来能用"的代码,但每次生成的配色、间距、字体、组件风格都可能不同。如果没有统一的约束,几十个页面拼在一起就会显得凌乱,完全谈不上品牌调性。Vercel 的解法是：把所有设计决策集中编码到一个文件里,让 Agent 在生成时始终参照它。解决这一问题的关键在于通过工程化手段——如统一的上下文注入、显式的约束规范——来弥补模型架构层面的局限。

design.md 的三个核心机制

根据 Vercel 官方分享,这套方案由三个环节构成,形成了一个完整的闭环。

一份文件编码设计决策与使用指导

design.md 承担了"设计系统单一真相来源"（single source of truth）的角色。它不是简单的样式表,而是用自然语言 + 结构化规则的方式,把设计决策和使用指导都写进去。

设计系统的传统实现与 AI 可读层

设计系统（Design System）是现代前端工程的核心基础设施,代表性实现包括 Google 的 Material Design、IBM 的 Carbon Design System、Shopify 的 Polaris 等。传统设计系统是一套多层次的规范体系。设计层通常使用 Figma、Sketch 等工具维护视觉规范和组件库；开发层则通过 Design Tokens（设计令牌,如颜色值、字号、间距的变量化定义）、组件库（如 React 组件）和文档站点（如 Storybook）来实现规范的代码化。

Design Tokens 是 Salesforce 在 2014 年提出的概念,已成为设计系统的行业标准。它本质上是将设计决策变量化：将颜色、字号、间距、圆角等视觉属性抽象为命名变量（如 color-primary-500: #3B82F6）,并以平台无关的格式（JSON/YAML）存储。Style Dictionary 等工具可将这些 tokens 转换为各平台代码：CSS 变量、iOS Swift 常量、Android XML 资源等。这种抽象带来单一真相来源、语义化命名和跨平台一致性等优势。

然而,这套体系服务于人类协作：设计师在 Figma 定义规范,工程师参照文档实现组件。但 LLM 难以直接解析这些格式——它无法"看懂" Figma 文件的二进制结构,也难以从零散的 tokens 中推断出完整的设计意图。

design.md 的创新在于引入"AI 可读层"：用 Markdown 的自然语言结构重新编码设计决策,既保留语义信息（如"主色用于强调行动"）,又提供可执行约束（如具体的 Hex 色值）。这使得模型能直接在生成过程中理解并遵循品牌规范,无需额外的解析或转换步骤。这种思路与 OpenAI 提出的 system prompt 工程、Anthropic 的 Constitutional AI 都有相通之处：通过显式约束塑造模型输出的边界。

这样做的好处非常直接：Agent 是靠上下文（context）工作的,一个 Markdown 文件恰好是模型最擅长理解和遵循的格式。相比让 Agent 去解析散落在代码库各处的 CSS 变量或 Figma 文件,一份集中的、语义清晰的 design.md 能让模型更准确地理解"我们的品牌应该长什么样"。它既包含了硬性约束（比如主色值、字号阶梯）,也包含了软性指导（比如"标题应保持简洁有力"这类原则）。

通过评估框架塑造输出质量

光有规范还不够。Vercel 强调,Agent 的输出会经过一个 eval harness（评估框架） 来"塑形"。

评估框架的多层验证机制

评估框架（Eval Harness）在 AI 系统中扮演"质量门控"角色,最早广泛用于模型基准测试（如 EleutherAI 的 lm-evaluation-harness）,近年来逐渐演进为生产系统中的质量门控机制。在工程实现上,它通常包含多层检查机制：

第一层是规则性检查：通过正则表达式、AST 解析等手段验证代码结构——例如检查 CSS 中的颜色值是否来自预定义的 Design Tokens,组件引用是否来自官方组件库。

第二层是语义性检查：利用 LLM 本身或专门的分类模型,判断生成内容是否符合品牌调性——例如通过 prompt engineering 让模型评分"这段文案是否专业且友好"。

第三层是视觉回归检查：通过 Playwright、Puppeteer 等工具生成页面截图,利用像素对比（如 pixelmatch 库）或视觉相似度算法（如 SSIM）检测布局偏移或样式异常。

持续集成/持续部署（CI/CD）是现代软件工程的基石,其中质量门控（Quality Gate）是关键机制：在代码流向生产环境的路径上设置一系列自动化检查点,包括单元测试覆盖率、代码风格检查（如 ESLint）、安全漏洞扫描（如 Snyk）、性能基准测试等。只有通过所有门控的代码才能合并或部署。

在生产环境中,这些检查通常集成到 CI/CD 流水线中——代码提交后自动触发评估,只有通过全部检查的输出才能合并到主分支。Vercel 将这套机制引入设计一致性验证,本质上是借鉴了 CI/CD 流水线的质量卡点思想——任何不符合规范的输出,在进入生产环境之前都必须经过自动化校验,而不是依赖人工 review 来兜底。

这一点尤其值得关注。它意味着 AI 生成页面不再是"生成即交付"的一次性动作,而是有一道自动化质检环节。评估框架会检查生成结果是否符合 design.md 中定义的标准——是否用了正确的配色、组件是否符合规范、布局是否符合品牌调性。不达标的输出会被识别出来,而不是直接进入生产环境。

这本质上是把软件工程中"测试驱动"的理念,迁移到了"设计一致性"这个更主观的领域。这种多层验证策略源自软件测试的"测试金字塔"理念,但应用场景从功能正确性扩展到了设计一致性这一更主观的维度。通过将主观判断转化为可量化指标（如"是否使用了规范色值"而非"看起来是否美观"）,评估框架让设计质量控制实现了自动化。

生产反馈回流形成迭代闭环

第三个环节是闭环的关键：生产环境的反馈会被重新喂回到这个循环里。

软件层的 RLHF 实现

这一设计理念与机器学习中的强化学习人类反馈（RLHF,Reinforcement Learning from Human Feedback）有深层的结构相似性。RLHF 是训练对齐模型的核心技术,包含三个阶段：首先用监督学习训练基础模型,然后让人类对模型输出进行偏好排序（如"回答 A 比回答 B 更有帮助"）,最后用强化学习算法（如 PPO）根据这些偏好信号优化模型策略。

RLHF 由 OpenAI 在 InstructGPT 论文中系统化,其核心价值是解决对齐问题（Alignment Problem）——让 AI 的目标与人类意图一致。这一技术让 ChatGPT 从"能对话"进化为"会对话"。RLHF 的核心思想是通过人类反馈闭环不断改进模型行为,这正是 ChatGPT、Claude 等现代对话模型能够对齐人类偏好的关键。

Vercel 的生产反馈机制在工程层面复现了类似的闭环结构,但无需更新模型权重：生产环境中的真实表现（如用户点击率、人工审查评分）被收集为评估信号,这些信号驱动 design.md 规范文件和评估标准的迭代更新,更新后的规范作为新的上下文约束注入到下一轮生成中,从而提升输出质量。这种"软件层的 RLHF"让系统具备持续学习能力,但绕过了昂贵的模型重训练流程。它体现了一种务实的工程哲学：在模型能力有限的情况下,通过优化输入上下文和输出验证机制来达成目标,而非等待更强大的模型出现。

也就是说,页面上线后的真实表现——可能是用户行为数据、可能是团队的人工审查、也可能是新出现的边界情况——都会成为改进 design.md 和评估框架的依据。这让整个系统具备了持续进化的能力,而不是一套写死的静态规则。

为什么这个思路值得借鉴

从更宏观的视角看,design.md 代表了一种正在成型的 AI 工程化范式：与其追求更强的模型"凭空发挥",不如为 Agent 提供清晰的上下文约束、可验证的输出标准和可迭代的反馈闭环。

LLMOps 与上下文工程

这一实践出现在一个行业转折点上：2024-2025 年,AI Coding Agent 从"辅助提效工具"向"半自主执行角色"快速演进,Devin、SWE-agent、OpenHands 等系统开始承担完整的开发子任务。这一趋势让"如何约束和验证 AI 输出"成为前沿工程问题。

LLMOps（Large Language Model Operations）是指围绕大语言模型应用构建的工程实践体系,类似于 MLOps 对传统机器学习系统的作用。它涵盖提示工程（Prompt Engineering）、上下文管理、输出验证、监控告警、版本控制等全生命周期环节。上下文工程（Context Engineering）是 LLMOps 中的核心方法论,关注如何设计和注入上下文来引导模型输出。由于当前 LLM 的"智能"高度依赖输入质量（即"garbage in, garbage out"）,精心设计的上下文往往比模型本身的能力更重要。

上下文工程的典型技术包括：Few-shot learning（在 prompt 中提供示例）、Chain-of-Thought（引导模型逐步推理）、Retrieval-Augmented Generation（从外部知识库检索相关信息注入上下文）、以及像 design.md 这样的规范文件注入。这些技术的共同特点是通过显式约束塑造输出边界,而非依赖模型"自由发挥"。这种思路与传统软件工程中的防御性编程理念一脉相承——假设系统行为存在不确定性,通过外部约束和验证机制来保障可靠性。随着 AI Agent 在生产系统中承担越来越多实际任务,LLMOps 实践正从"实验性探索"演进为"工程化标准",成为 AI 应用落地的关键基础设施。

design.md 所代表的这套方法论——规范、测试、迭代——恰好对应了软件工程的三大支柱。Vercel 只是把它们应用到了"让 AI 产出品牌一致页面"这个具体场景。

对于任何正在探索用 AI Agent 做前端或内容生成的团队来说,这个模式有很强的可复制性：

• 建立单一规范文件：把你的设计系统、品牌指南以 Agent 友好的格式集中沉淀,而非依赖零散提示词。
• 搭建评估机制：不要相信一次性输出,用自动化手段验证结果是否符合预期。
• 打通反馈回路：让生产数据反哺规范,形成持续改进。

小结

Vercel 的 design.md 实践,看似只是"用一个 Markdown 文件约束 AI",实则展示了如何用工程化思维驯服 AI 生成的不确定性。在 AI Coding Agent 越来越普及的今天,如何保证输出质量与品牌一致性,将成为区分"玩具"与"生产级工具"的关键分水岭。这套"规范—评估—反馈"的闭环,融合了设计系统工程、LLM 评估基础设施和类 RLHF 的迭代机制,或许正是答案的雏形。

核心要点

• AI Coding Agent 基于概率性、无状态的 LLM 架构,缺乏跨会话的品牌一致性记忆
• design.md 通过单一文件集中编码设计决策,为 AI 提供可直接理解的品牌规范
• Eval Harness 评估框架通过规则性、语义性和视觉回归检查自动验证输出质量
• 生产反馈闭环实现"软件层的 RLHF",让系统具备持续改进能力
• 这套实践体现了 LLMOps 的核心理念：通过上下文工程和验证机制驯服 AI 的不确定性