Atlassian 在其关于便携设计上下文的实验记录

Atlassian’s DESIGN.md is here: what we learned testing portable design context in practice

中回顾了 Team ‘26 大会现场的这样一个场景：团队在 Figma Make 的仪表盘生成任务里输入了完全相同的提示词，唯一变量是一份名为 DESIGN.md 的便携上下文文件。加入文件的生成结果，在配色、栅格间距、圆角形状、字体排印以及整体视觉层级上，都与 Atlassian 自身的设计风格表现出更高的一致性。

但同样是这家公司，在另一个针对基础登录页面的对照实验中，把 DESIGN.md 作为唯一的上下文输入提供给大语言模型，得出的表现却走向了反面。在这个看似简单的生成场景里，单靠一份 Markdown 文件的方案比接入结构化工具或技能包的方案耗时更长、费用更高，并且经历了明显更多的对话轮次。

这两个截然相反的实际表现说明，问题并不在于那份 Markdown 文件写得是否优雅详尽，而在于它究竟是作为孤立文件被直接投喂给模型，还是被置于一个具备工程约束的完整系统当中运作。当团队试图让 AI Agent 承担实际的产品设计与界面实现时，如何界定一份文件的能力边界，何时该止步于一份文件，又在何时必须构建起真正的工程 Harness，构成了当前界面工程中最值得推敲的技术分野。

一份文件的能与不能

便携格式与设计意图

从文件形态来看，design.md 本质上是一份轻量级的纯文本便携规范。在实践中，这类文件的前半部分通常由机器易于解析的键值或设计变量构成，用来界定颜色、间距、圆角与字阶等基础样式；后半部分则以人类与 Agent 均可理解的自然语言编写，集中陈述布局逻辑、信息层级划分、视线引导原则以及排版约束。

它的主要定位在于捕捉高阶的设计意图，告诉模型一个产品界面在直觉上应当具备怎样的气质与组织形态。这份文件天然不包含生产环境里的全部技术细节，它没有绑定具体的前端代码库依赖，缺少针对语法与样式的静态检查工具，更无法囊括团队在 Figma 画布中沉淀下来的庞大变体组合与边界场景。它是一张经过高度浓缩的意图摘要，旨在以最低的流通成本跨越不同工具之间的壁垒。

跨越工具的原型生成

这种脱离具体工程绑定的便携属性，让它在特定场景下展现出极为显著的实用价值。当设计团队需要从零搭建新功能的概念原型、在完全陌生的外部工具中快速生成交互界面，或者尝试把现有的设计语言移植到新的技术栈与操作系统时，直接附带一份设计意图文件往往是成本最低的启动方式。

在为企业客户定制主题风格，或者编写报告、统计图表、数据看板这类重在结构呈现而非工程闭环的动态界面时，这种文件能够迅速对模型的发散生成起到收拢作用。它让模型在缺乏代码库访问权限的环境下，依然能够大致遵循既定的视觉律动，避免生成完全违背品牌直觉的杂乱界面。

登录页测试的真实代价

一旦把应用场景切换到真实工程环境，单一文件作为上下文输入的物理瓶颈就会暴露出来。大语言模型以 token 为基本单位处理文本，每个 token 由几个字符或单字构成。纯文本文件的单次加载看似廉价，在实际交互中却会引发巨大的累计开销。

Atlassian 在针对简单登录页面的对照测试中记录了详实的基础数据。当只提供单一的 DESIGN.md 作为设计上下文时，Agent 平均消耗了 721 万 token，耗时 6 分 46 秒，经历了 45.3 轮交互才完成任务。作为对比，通过模型上下文协议 MCP 接入设计系统的方案，平均消耗为 375 万 token，耗时 5 分 1 秒，交互轮次降至 35.1 轮；而采用技能机制 Skill 的方案，平均消耗为 443 万 token，耗时 5 分 23 秒，交互轮次为 36 轮。

官方在总结该实验时指出，仅仅依赖 DESIGN.md 的方案大约多消耗了 92% 的 token，而且在不同测试运行之间，token 消耗量的方差高达约 2.7 倍，表现出极大的不稳定性。

六页盲测的质量边界

在另一组来自 Vercel 的实践中，研究团队在

How our agents build on-brand pages with design.md

中记录了针对三个典型桌面端界面场景展开的盲测。他们为每个场景分别在有 design.md 和无 design.md 的条件下各生成一次页面，并严格保留模型的第一次尝试结果作为评估样本。

引入基于明确规则的确定性检查后的统计表明，引入 design.md 的三个页面总共被检测出 39 个已知故障，而未引入该文件的三个页面则检测出 91 个已知故障，已知故障的数量减少了 57%。表面上看这展现了设计规则的规范效果，但评估结果同时记录了一个不可忽视的事实：参与测试的全部六个页面中，每一页都至少存在一个严重到足以阻止其发布的致命问题。

单一文件缺失的支柱

从工程机理深入观察便能发现，一份孤立的 design.md 无论字数扩充到何种程度，在面对复杂的代码生产任务时依然力不从心。它所面对的核心障碍不在于文件包含的内容量是否充足，而在于单体文件缺乏在真实工程语境下使规则落地的支撑构件。

它缺少精准的按需检索机制，迫使模型在每次思考时都必须通读全篇无关条目；它缺少确定的执行边界，无法像编译期类型检查那样机械拦截语法或样式上的违规代码；它缺少能够伴随业务迭代而自我修正的维护通路，最终只能沦为与代码库脱节的陈旧说明。这三处能力的缺口，正好揭示了为什么生产级别的落地必须依赖完整的分层架构。

仓库外与仓库内的两条路

代码库作为唯一分岔点

要理清 Harness 的形态选择，首先需要回答一个本质问题：当前的 Agent 是否具备直接读取、修改并运行目标代码库的完整权限与工程环境。这是决定一切上下文组织形式的唯一分岔点。

如果答案是否定的，任务目标仅仅是在外部交付独立的产物，那么试图将复杂的工程依赖强行打包灌输给模型只会徒增损耗。反之，如果 Agent 已经工作在主干仓库之中，其交付结果需要直接合并入主干分支并部署上线，那么企图依靠一份脱离代码语境的文本指导模型完成严谨的工程作业，在工程上也同样是不切实际的。

仓库外的轻量路径

在代码库之外的场景里，目标产物通常是独立的分析报告、产品架构提案、一次性的活动落地页，或者在设计工具之间流转的高保真交互原型。面对这类任务，Vercel 探索出了一套轻量化的三层支撑体系。

最顶层是由 design.md 编码的核心意图，重点规范读者的阅读任务、证据链条的组织逻辑以及整体版面的构图判断；中间层借助外部公开托管的样式表，在限定范围内提供严格受控的 CSS 类名与设计变量，模型在生成 HTML 时仅需引用这些既定类名，样式表本身则由浏览器在渲染阶段直接加载，完全不占用模型有限的上下文窗口；最底层则设立持续的评测循环，将人类对产物的审美直觉与逻辑纠偏，逐步沉淀为具体的文字指导、样式原语或确定性测试用例。

仓库内的工程路径

当 Agent 深入到真实的企业生产代码库内部时，它所要面对的就不再是单纯的视觉呈现，而是庞杂的依赖树、无障碍标准、状态管理以及长久累积的代码约定。

在这一路径上，Vercel 在

Teaching agents product design at Vercel

中介绍的内部 product-design 方案展现出鲜明的系统工程特性。该方案由三个相互咬合的部分紧密组成：提供产品判断与代码库背景的 Agent Skill 帮助模型理解业务逻辑与选型偏好；代码静态检查工具 linter 负责自动执行清晰、可机械判定的规则；贯穿协作现场的闭环流程则持续从 Slack 讨论、Figma 批注与 GitHub Pull Request 中抽取设计共识，为工程指导原则提供更新提案。

Atlassian 则在

Teaching AI to speak our design language

中阐述了从真源构建切入的路径。他们没有人工撰写孤立的文档，而是将组件库、图标资产、设计变量、静态检查规则以及基础指导规范，全部解构成结构高度一致且机器可读的类型定义与数据结构，与实际的前端组件源码共同存放在同一个 TypeScript 文件体系之中。基于这份统一定义的真源，系统再通过编译脚本自动化输出 ADS MCP、设计系统 Skill、DESIGN.md 以及后续任何可能出现的接入格式。

两种路径的权衡对照

为了在技术选型时建立清晰的判断标准，下表从多个工程维度对仓库外与仓库内两条路径的具体实践进行了对比。

评估维度	产物导向的仓库外路径	工程导向的仓库内路径
判定依据	Agent 无法访问生产代码库与工程工具链	Agent 具备代码库读写、编译与运行权限
典型场景	独立报告、概念提案、一次性活动页、工具间原型	生产环境功能研发、线上缺陷修复、设计系统演进
核心载体	design.md 配合外部公开样式表与渲染时加载	结构化真源、定制 Agent Skill 与本地 linter
约束方式	文字指导加样式原语，机械故障进行确定性检查	可机械判定的规则由 CSS、类型、组件 API 与 linter 执行，判断类内容留在文字规则
调用入口	协作现场的统一 Agent 入口，返回截图与部署 URL 一类可核查产物	MCP、Skill 或统一 Agent 接口，分发到 Cursor、Slack、Rovo、Figma Make 等工具
验收方式	视觉走查、截图核验与在线预览链接确认	特定任务的准确率、错误数、耗时、token 与工具调用评测，加代码健康检查
典型错配	为一次性报告搭建重型真源与 MCP，工程投入过度	仅扔一份 design.md 进生产库，导致开销激增且故障频发

在实际工程落地中，最常见的失误往往就发生在这两种路径的错配上。在仅仅需要一份分析报告的探索阶段，过早地引入重型数据结构与复杂的通信协议，会使前期工程成本大幅攀升；而在要求极高的生产代码库中，如果仅仅图省事塞入一份单体设计文档，往往会导致交互开销失控，模型在上下文膨胀中频繁遗忘规则，最终所有细节故障仍然只能依赖工程师逐行人工排查。

面向交付物的选型判断

选择何种技术方案，本质上是对交付物生命周期与质量容忍度的权衡。仓库外路径追求的是极高的流转速度与最低的介入成本，它允许在最终实现中存在轻微的非常规代码，只要浏览器渲染出的视觉与逻辑结构达标即可。

而仓库内路径的唯一目标是保障生产环境的代码健康度。它要求每一次生成都必须规范地嵌入既有的架构体系，遵循统一的状态管理模式，并能够经受住自动化测试与构建工具的严苛检验。先认清产物的终点，才能决定上下文的起点。

设计上下文的五层架构

拆分上下文的核心动因

之所以不能将所有的设计系统资产无差别地打包堆叠，是因为大语言模型的注意力机制具有明显的物理衰减规律。当数万行的组件文档、API 规范、无障碍条款与设计原则被一股脑塞进提示词时，模型在单次推理中不仅需要分摊注意力计算，还极易在繁杂的信息中产生规则漂移与选择性遗忘。

前文提及的登录页测试中出现的 token 爆炸与时间损耗，正是由于模型在每一个简单决策时都被迫通读整本规范手册所致。要让 Agent 在真实工程中稳定工作，就必须打破这种单体信息架构，根据信息性质与决策时机将上下文进行解耦拆解。

承载取向的意图层

意图层承载了整个体系的核心设计取向，它回答的是“我们为什么这样设计”以及“在何种情形下允许打破常规”的高阶问题。这一层正是 design.md 后半部分原本承担的核心内容。

它并不描述某个按钮组件具体接收哪些参数，而是阐述系统在信息层级上的轻重缓急、留白的节奏规律、对极端数据的排版包容度，以及当视觉美感与信息密度发生冲突时的取舍准则。意图层提供的是一种评价标准，使得 Agent 在面对未曾预设的界面状态时，能够基于一致的价值观做出符合团队审美的自主裁决。

机器可读的真源层

真源层以统一的机器可读格式集中维护系统的结构化数据源头，所有下游输出皆由其生成。它彻底剥离了含糊不清的自然语言修饰，用字段、类型与格式规则严格的 Schema 来固化所有事实，构成系统的客观事实基石。

在这一层中，每一个 UI 组件、图标资产、基础 Token、静态检查规则乃至文案准则，都被拆解为结构严密的数据实体。它们清晰标明自身的调用场景、代码片段、属性接口定义、无障碍实现标准以及支持的状态分支。最关键的是，这些数据实体与实际的工程代码存放在同一物理位置，享受同等的版本控制，任何设计系统的更新都会直接同步至真源，从根源上避免了文档与代码脱节的问题。

掌控节奏的披露层

即使真源层的数据足够精准，也不能在任务伊始便全盘抛给模型。披露层的作用在于建立一套基于执行阶段的渐进式披露机制：模型执行到特定步骤时才获得对应层级的上下文，避免窗口从一开始就被塞满。

在仓库根目录下，可以通过极短的入口文件定义各类场景的触发规则；在进入具体的执行单元后，通过内部配置文件严格规定上下文的读取顺序与治理逻辑；当 Agent 进入特定功能模块的代码编写阶段时，系统再按需检索对应的业务参考文档。对于有成熟先例的场景，提供经过上线检验的最佳实践范例；对于尚未建立标准的领域，则明确展示规范缺口清单。每一条规则都被赋予稳定的唯一编号、适用范围、明确特例以及正反示例，确保模型在正确的节点获取精确的信息切片。

执行确定的约束层

凡是能够依靠机器算法确切判定的事实，绝不应当交由大语言模型去碰运气，这是构建高效 Harness 的核心工程分水岭。约束层正是由这类具备确定性阻断能力的工具链组合而成。

样式的绝对边界由底层受控的 CSS 体系与样式原语筑牢，组件的传参有效性由编译器的静态类型系统直接防御，代码的调用合规性与无障碍属性遗漏则由静态检查工具在后台毫秒级拦截。留给自然语言提示词去处理的，仅仅是那些涉及语义理解、信息组织权衡与主观审美判断的模糊空间。

持续演进的反馈层

任何系统如果不具备自我修正的循环机制，都会随着业务的发展而不可避免地逐渐失效。反馈层的存在，就是为了在日常的产研协作中捕捉偏差，使上下文能够持续吸收来自生产一线的养分。

这一层建立在具体的协作工具与代码审查流程之上。它持续收集来自即时通讯群组中的设计讨论、Figma 画布上的走查评审意见以及代码合并请求中的人工修改痕迹。系统将这些零散的反馈加以聚合，自动提炼出针对设计规范的更新候选条目，在经过设计系统团队的人工核准后，合流并入真源层完成系统闭环。

五层架构的落地价值

这五层架构的划分并非空中楼阁，它精准映射了工业级落地的具体步骤。意图层保障方向，真源层沉淀资产，披露层降低开销，约束层守住底线，反馈层驱动演进。

明确了各层的边界与职责分配，团队在推进实际建设时才能有的放矢。后续的搭建工作，正是沿着这一逻辑序列由浅入深地逐步展开。

搭建上篇：输入与真源

真实任务与基线建立

第一步的任务是建立评估基线，为后续的上下文调整提供客观的比对参照。没有度量衡的提示词调整，绝大多数时候只是在盲目碰运气。

在工程实践中，团队必须从实际业务里提炼出一批具有代表性的真实测试场景，例如 Vercel 在其探索过程中固定采用了七个核心场景。在这个阶段，需要严格锁定测试所用的模拟输入数据、目标模型版本、提示词模板以及渲染时的视口尺寸，在完全不接入任何设计系统或辅助工具的裸模型状态下进行反复运行。

团队需要完整留存这一阶段的原始输入输出记录、生成的代码文件、界面渲染截图，并精确统计单次任务所耗费的时间与 token 数量。记录下这些最原始的试错过程与人类反馈意见，才能勾勒出基线状态的真实轮廓。

这一步的完成标准是：拥有固定的真实业务场景集合，锁定模拟输入、测试模型与渲染视口，完整记录了未引入 Harness 时的提示词、产出代码、界面截图以及耗时与消耗记录。

编写最小意图文件

第二步是在不引入技术实现细节的前提下，补充设计体系的意图层。许多团队在这个阶段最容易犯的错误，就是将整本组件手册不加节制地翻译成自然语言。

一份合格的最小意图文件，应当把篇幅克制在极短的尺度内，专注于提炼那些通过代码肉眼可见的全局决策。它需要讲清楚界面的主要受众与核心阅读任务，规定数据图表与关键证据应当如何排布展示，明确不同版块之间的构图逻辑与视线流向。在此基础上，清晰界定每条设计原则的生效范围、常见特例以及系统中允许使用的全局样式原语。

坚决剔除诸如“界面应当保持现代美观”“交互需要流畅丝滑”这类空洞的愿望式描述，也切忌在这一步抄写任何具体的组件参数或底层实现逻辑。

这一步的完成标准是：意图文件能够在一屏之内完整读完，通篇不包含全量规范与具体组件的技术实现细节。

沉淀结构化真源

第三步是将设计规范转化为机器可解析的结构化真源，使下游的分发格式由脆弱的手工维护转变为自动化的生成物。这是整个系统能否规模化落地的分水岭。

团队需要对既有的设计系统进行一次系统化的结构拆解。利用 TypeScript 的类型系统或标准化的 Schema 格式，将所有的色彩与尺寸变量、通用组件的属性定义、无障碍规范条目、标准文案范式以及交互状态分支，逐一封装为独立的强类型对象。每个组件实体都需要清晰附带其适用场景的文字说明、标准的代码使用示例、输入参数的取值约束以及无障碍标签的强制要求。

最关键的组织原则在于，这套 Schema 必须与前端组件的实际源代码存放在同一代码仓库的相同目录下，接受统一的版本变更与审查流水线约束。任何对组件实现的修改，都必须强制同步更新其对应的真源描述。

这一步的完成标准是：定义出的 Schema 完整覆盖用法说明、代码范例、属性接口、内容规范与无障碍要求，且与生产代码同处一地并受版本控制管辖。

索引与渐进式披露

第四步是构建索引体系与按需调取的披露层，防止模型在单次会话中因为信息过载而迷失。

在体系设计上，应当将触发入口的体积压缩到极致。放在仓库根目录下的入口文件仅负责声明任务类型的判定逻辑与对应资源的加载时机，其本身不包含具体的规则正文。当任务明确命中某一类界面开发时，再调度专职的 Agent Skill 去驱动完整的执行流程。

具体的规则与参考资产必须按业务领域进行物理拆解，分别归入产品逻辑判断、界面视觉质量、系统状态韧性、文案语言规范以及特定页面的参考资料当中。对于团队在实际业务中沉淀下来的优秀范例，提炼为具有普适性的最佳实践模块供模型参考；对于尚未建立明确设计规范的模糊地带，则建立一份公开的缺口清单，明确告诫模型在这些区域禁止盲目发散，必须采用最保守通用的方案处理。每一条下沉的细则都必须打上全局唯一的固定编号，清晰标明其来源、生效环境、豁免特例并附带明确的正反对比用例。

这一步的完成标准是：外部触发入口只声明触发时机；每条规则带有稳定的唯一标识符、来源出处、生效范围、特例说明与正反示例；未建立规范的区域具备公开的缺口清单。

阶段完成标准对照

为了方便在落地过程中核对进度与纠偏，下表梳理了前四步的核心指标、高发错误以及进入下一步的明确信号。

搭建阶段	完成标准	常见错误	进入下一步的信号
步骤 1：真实任务与基线	业务场景固定，锁定环境与输入，留存无 Harness 时的耗时与截图	使用人工捏造的非真实场景；测试时频繁更换模型或视口尺寸	拿到未经修饰的基线耗时、token 消耗与已知故障数据
步骤 2：最小意图文件	文件一屏内可通读，仅包含构图判断与意图，无全量代码规范	堆砌主观形容词；试图把整个组件库的文档原样抄写进去	提示词能稳定引导模型生成符合品牌大体构图的界面框架
步骤 3：结构化真源	Schema 涵盖用法、代码、props 与无障碍，与源码物理同存	将真源作为外部独立文档维护；缺少强类型检查与代码同步机制	能够通过脚本从 TypeScript 源码目录自动导出其他格式文档
步骤 4：索引与渐进披露	入口极简，规则具备稳定 ID 与正反例，存在公开的缺口清单	把所有参考规则打成一个大文件注入；规则缺乏正反例对比	能够在特定任务中只调取相关页面的规则，上下文占用保持平稳

完成这四步，团队实际上就已经为 Agent 准备好了一套结构清晰、内容精准且不会轻易引起注意力涣散的上下文知识库。但光有知识库还不足以确保产出代码的万无一失，接下来的重心必须转移到运行时的确定性执行与入口收敛上。

搭建下篇：约束与入口

划定边界的样式原语

第五步是为设计系统收敛样式原语与组件边界，从根本上压缩模型的试错空间。自由度过高往往容易导致生成的代码偏离规范。

在实际实现中，必须为模型提供语义明确且边界严格封闭的设计变量与类名工具。模型在组装界面时，被严格限制只能从既定的样式原语集合中进行挑选，杜绝其自行编写任意取值的内联样式或随意的全局覆盖。

这里存在一个极其关键的工程取舍：能够不进入模型上下文窗口的内容，就坚决不放进去。在外部轻量级路径中，Vercel 采用将公共样式表托管在外部的方式，页面在渲染时由浏览器引擎直接拉取并解析这套样式规则。大语言模型只需要知道“这个卡片容器应当使用哪一个类名”，而无需去理解甚至记忆这个类名背后对应的数十行具体 CSS 属性。这种方式不仅大幅节约了昂贵的 token 资源，更将样式的最终解析权牢牢收拢在受控的确定性运行环境中。

这一步的完成标准是：模型生成的代码仅能调用受控的 Token 与类名原语，公共样式资源无需进入提示词上下文即可在浏览器中完成解析。

机械规则交给静态检查

第六步是将所有确定性的工程规则下沉至静态检查系统，减轻提示词层面的注意力负担。

很多团队习惯于在给模型的提示词里巨细靡遗地强调各种编码细节，例如“不要使用带有未转义字符的属性”“所有交互元素必须包含无障碍标签”“必须使用特定的图标导入语法”。这类规则不仅数量庞大，而且在长上下文环境下极易被模型忽略。

更具工程确定性的做法，是将这些完全符合机械判定逻辑的要求，统统转化为项目的 linter 规则或编译器类型约束。在本地构建流水线或 Agent 的运行时容器中，一旦模型生成了违背这类规则的代码，静态检查工具会立即抛出包含精确行列号与修复建议的错误日志，驱动模型根据明确的报错信息进行定向修正。留存在自然语言指导文件里的，应当仅仅是那些需要结合业务上下文权衡的非机械判断。

这一步的完成标准是：提示词中不再重复叮嘱任何可以通过编译器或静态检查工具自动拦截的机械规则。

统一在协作现场的入口

第七步是为团队打造位于实际工作界面的统一调用入口，将设计上下文无缝注入日常协作。脱离了生产环境的独立演示往往难以真正推行。

在这一点上，两家代表性企业的探索展现出殊途同归的工程取向。Vercel 在其实际业务协作中，将设计能力深度集成到即时通讯工具 Slack 之中。团队成员通过基于内部开发框架 eve 的

@design

-agent 机器人发起交互，Agent 在后台自动加载当前最新的 design.md 文件与公共样式表，完成代码生成与临时渲染后，直接在讨论线程中返回界面的高清渲染截图与能够实时交互的预览部署链接，供产研团队即时核验。

Atlassian 则致力于将统一的设计真源分发至多端开发环境。通过 ADS MCP 协议、专门打包的设计系统 Skill 以及结构化的内容输出，他们把统一的设计上下文无缝输送到了 Cursor 编辑器、企业内部的 Slack 协同空间、智能助手 Rovo 以及设计工具 Figma Make 之中。无论团队成员身处编码工具、设计画布还是沟通平台，调用的都是同一套设计系统内核。

这一步的完成标准是：团队成员能够在日常协作工具中通过单一指令或入口触发 Agent，并能直接拿到可核查的产物，包括真实截图、预览环境链接或可运行代码。

接口形式背后的共性

业界关于究竟应当全面拥抱 MCP 还是优先采用 Skill 的争论，在具体的工程实践面前往往显得流于表面。MCP 的本质在于定义了一套跨系统的通用通信协议，适合在需要动态跨工具检索数据、连接远程服务的复杂 IDE 环境中使用；而 Skill 则更偏向于在受控框架内打包特定业务流程的执行逻辑与伴随知识。

采用何种接口协议，很大程度上取决于具体团队现有的工程工具链与宿主环境。从深层治理逻辑来看，两家公司的重心高度重合：核心都在于必须建立一个让团队随时随地能够触达的统一入口，建立一套免于人工手工同步的真源发布管线，并最终形成能够持续自我修正的工程闭环。

约束执行的标准对照

搭建下半程的重心完全落在工具的硬性约束与工程落地形态上，下表归纳了最后三个构建步骤的核心衡量指标与典型误区。

搭建阶段	完成标准	常见错误
步骤 5：组件与样式原语	生成代码仅调用受控类名与 Token，公共样式不进入模型上下文	将庞大的 CSS 全文直接贴入提示词，允许模型自由书写任意样式
步骤 6：确定性静态检查	机械规则全部由 linter 或类型系统拦截，提示词中无重复叮嘱	在自然语言提示词中反复人工强调语法细节，缺少自动化拦截程序
步骤 7：统一协作入口	成员在日常工具中单点触发，直接返回截图、预览链接或可用代码	要求工程师切换到独立隔离的终端环境使用，无法即时拿到视觉凭证

当约束具备了确定性的执行力，且调用入口被稳固安放于工程师与设计师的日常作业链路中时，整套 Harness 的骨架才算真正搭建成型。但要使这套体系在长期的业务迭代中不至于迅速老化，还必须建立起严密的评测与治理体系。

评测数字与治理机制

评测与修正的执行路径

第八步是为整套 Harness 建立可量化、可持续的评测与修正闭环，它是保持系统规则有效与稳定的核心手段。

在实际运作中，不能依赖个别工程师主观的随机抽查，而必须执行严格的盲测机制。选定基线场景后，保留模型的首轮尝试产物，对每一个变更版本打上不可篡改的标识记录。当评测流程发现生成结果存在缺陷时，修复策略必须遵循“就低不就高”的收敛原则：凡是涉及主观审美与信息组织的偏差，才将修正意见补充进意图文件；凡是涉及反复出现的布局范式，应当将其沉淀为样式表中的可复用原语；凡是涉及能够被逻辑判定的机械缺陷，必须立即编写成新的 linter 规则或测试用例，坚决杜绝把所有问题都简单归咎于提示词并无休止地扩充文本。

意图文件的真实探索成本

许多人容易低估一份精简设计文件的诞生过程，误以为这只是设计师随手撰写的一份简单纪要。现实中的工程投入往往表现出截然不同的沉重形态。

Vercel 在复盘其内部一份高品质 design.md 的孵化历程时透露，整个构建与校准过程总共经历了 200 多次实际运行。这 200 多次运行中，既有完整任务轮次，也有局部规则的定向检查、异常边界的试运行和中途推倒重来的工程弯路。要将人类模糊的美学感知蒸馏为模型能够稳定理解且极少产生歧义的精准指令，背后需要经历极其繁琐的工程打磨。

结构化上下文带来的改进

Atlassian 在

Atlassian Design System: Building the context engine for the AI era

记录的定向查询测试中，由结构化内容支持的 MCP 相比未配置 MCP 的基线 Agent，最高带来了 52% 的查询准确率提升。而在同样来自 Atlassian 的代码生成测试中，结构化真源驱动的环境使最终代码准确率提升了 4.9%，同时伴随着错误减少 11%、任务完成时间平均缩短 34%、token 消耗减少 16% 以及工具调用频次下降 26%。

人工治理与系统维护

第九步是确立长期的人工治理机制与责任边界，这是避免系统随着人员流动与业务变更而失效的重要防线。

一套健壮的 Harness 必须具备严密的人工介入通道。来自业务现场的反馈不能未经审核就直接写入真源，系统必须引入明确的审核流程与责任归属人。每一条规则的增补、修改与废弃，都必须伴随着版本号的递进，并在代码仓库中留下可溯源的提交记录。对于设计系统尚未覆盖的空白领域，必须保持缺口清单的公开透明，防止 Agent 在规范盲区肆意发挥。

Atlassian 将 AI 原生设计系统的长期健康归纳为四个有机维度：AI 能够顺畅理解规范、AI 能够熟练使用规范构建界面、由 AI 探索出的新兴交互模式能够反哺沉淀为系统资产、以及 AI 能够协助团队维护系统自身的健康度。在他们的实践中，真源内容的每一次更新，都会在后台自动化触发评测流水线与代码健康检查，确保新的规则不会对既有业务产生破坏性的副作用。

Harness 并非一次性配置完成即可一劳永逸的静态资产，而是一套需要持续投入工程资源与人工治理的动态演进系统。

角色变化：对结果负责

审美与实现的交汇点

伴随着上下文工程与 Agent 基础设施的演进，团队中不同技术角色的职责分工正在经历深刻的重组。这种变化在设计工程这一交叉领域体现得尤为剧烈。

Vercel 在

Design Engineering at Vercel

中对设计工程师这一角色给出了明确的界定：这类人才必须将敏锐的审美感知力与扎实的前端工程能力深度结合，能够从本质上深刻理解业务所面临的问题，并拥有自主完成设计、代码构建乃至最终发布上线的全栈能力。在日常关注的维度上，他们不仅要在宏观上审视可复用组件的架构合理性与运行性能，更要在微观上死磕跨浏览器的一致表现、多模态输入的交互体验、对系统偏好的精细适配以及毫不妥协的无障碍访问标准。

从环节转向交付结果

长期以来，软件工业的研发流水线习惯于将产研工作切割为彼此孤立的工序环节：产品经理输出需求文档，设计师在画布上勾勒静态视觉稿，前端工程师对着设计稿在代码中还原像素，最后由测试人员把关验收。在这一链条中，每个人都倾向于只对自己所处的那一环节的交付物负责。

当高水准的 Harness 能够接管大量重复性的界面搭建工作时，关键的转变不再是表面上要求某个人“既要画界面又要写代码”，而是整个团队的工作重心理应从负责单一的“流程环节”，彻底转向为最终的“线上结果”负责。设计师与工程师不再需要耗费海量精力在枯燥的设计走查与像素还原拉扯上，而是共同对最终交付给用户的实际产品体验承担直接责任。

贴近代码的设计探索

在这种演进趋势下，一部分具有前瞻视野的设计实践者开始主动打破工具之间的无形藩篱。Cursor 的设计负责人 Ryo Lu 在教程访谈

Full Tutorial: Design to Code with Cursor’s Head of Design

中展示了一种直接在代码编辑器中完成功能设计与原型构建的全新工作流。

在这种工作模式下，设计探索不再局限于静态画布上的图层排布，而是从第一天起就直接借助 Agent 运行在真实的代码环境之中。代码原型天然具备完整的数据状态管理、极限文本溢出处理以及真实的浏览器响应反馈，它从根本上消除了传统设计在交接给工程团队时可能产生的海量信息损耗与认知偏差。

画布工具的实际位置

在设计工具与代码环境的关系上，Ryo Lu 在访谈

Ryo Lu — It’s All the Same Thing

中同样给出了直接的回答：早期的产品架构探索、模糊概念的发散碰撞，以及需要二维空间精确布局与自由排布的场景，他依然会毫不犹豫地使用 Figma。真正的趋势是设计师更主动地向代码库与运行中的真实软件靠拢，缩短意图与实现之间的距离，而不是在图形界面与代码之间做非此即彼的选择。

走向结果的基础设施

从真实的业务痛点出发，深入到具体的代码上下文与运行环境中去，最终对用户看到并使用到的产品结果承担完整责任，是整个软件构建形态演进的确定方向。

回顾全文所详述的拆解与搭建过程，从最初那份捕捉设计原则的最小意图文件，到细致解构的结构化真源，再到严格防御的静态检查与深度整合的协作入口，这一套层层递进的 Harness，其根本价值绝非为了替代人类的专业思考。它所承担的全部使命，是作为一套坚固的基础设施，将人类的审美取向与工程严谨性转化为 Agent 能够理解并执行的代码语言，让创造者得以从无尽的机械重复中抽身出来，专注于那些真正需要倾注智慧与热情的创造性裁决。