设计 Harness：从 design.md 到可维护的上下文工程
本文整理自 X（Twitter）用户 @NiallxYoung 的文章《设计 Harness：从 design.md 到可维护的上下文工程》。
原文地址：https://x.com/NiallxYoung/status/2095769528785617353
Atlassian 在 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 的实践中，团队针对三个典型桌面端界面场景做了盲测。他们为每个场景在有、无 design.md 的条件下各生成一次页面，并严格保留模型的第一次尝试作为评估样本。
引入确定性检查后的统计表明：有 design.md 的三个页面总共被检出 39 个已知故障，没有该文件的三个页面则检出 91 个，已知故障减少了 57%。这表面上是设计规则在起规范作用，但评估同时记录了一个不可忽视的事实：参与测试的全部六个页面，每一页都存在至少一个严重到足以阻止发布的致命问题。
单一文件缺失的支柱
从工程机理看，一份孤立的 design.md 无论扩写到多长，面对复杂的代码生产任务依然力不从心。障碍不在内容量够不够，而在单体文件缺乏让规则落地的支撑构件：
- 缺少精准的按需检索机制，模型每次思考都得通读全篇无关条目；
- 缺少确定的执行边界，无法像编译期类型检查那样机械拦截语法或样式违规；
- 缺少随业务迭代自我修正的维护通路，最终沦为与代码库脱节的陈旧说明。
这三处能力缺口，正解释了为什么生产级落地必须依赖完整的分层架构。
仓库外与仓库内的两条路
代码库作为唯一分岔点
要理清 Harness 的形态选择，先回答一个本质问题：当前 Agent 是否具备直接读取、修改并运行目标代码库的完整权限与工程环境。这是决定一切上下文组织形式的唯一分岔点。
如果答案是否定的，任务目标只是在外部交付独立产物，那试图把复杂工程依赖强行打包灌输给模型只会徒增损耗。反过来，如果 Agent 已经工作在主干仓库里，交付结果需要直接合并进主干分支并部署上线，那想靠一份脱离代码语境的文本指导模型完成严谨工程作业，同样不切实际。
仓库外的轻量路径
代码库之外的场景里，目标产物通常是独立分析报告、产品架构提案、一次性活动落地页，或在设计工具间流转的高保真原型。面对这类任务，Vercel 探索出一套三层支撑体系：
- 顶层由 design.md 编码核心意图，规范读者的阅读任务、证据链条的组织逻辑与整体版面的构图判断；
- 中间层借助外部公开托管的样式表，提供严格受控的 CSS 类名与设计变量，模型生成 HTML 时只引用这些既定类名，样式由浏览器渲染时加载，完全不占用模型有限的上下文窗口；
- 底层设持续的评测循环，把人类对产物的审美直觉与逻辑纠偏，逐步沉淀为文字指导、样式原语或确定性测试用例。
仓库内的工程路径
当 Agent 深入真实企业生产代码库，面对的就不再是单纯视觉呈现，而是庞杂依赖树、无障碍标准、状态管理以及长期积累的代码约定。Vercel 内部 product-design 方案（详见 Teaching agents product design at Vercel）表现出鲜明的系统工程特性，由三部分咬合：
- 提供产品判断与代码库背景的 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 多次实际运行——既有完整任务轮次，也有局部规则的定向检查、异常边界试运行与中途推倒重来的弯路。要把人类模糊的美学感知蒸馏成模型稳定理解、极少歧义的精准指令，背后是极其繁琐的工程打磨。
结构化上下文带来的改进
Atlassian 定向查询测试里，由结构化内容支持的 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 能理解并执行的代码语言，让创造者从无尽机械重复中抽身，专注于真正需要倾注智慧与热情的创造性裁决。
参考来源
- Atlassian's DESIGN.md is here: what we learned testing portable design context in practice — https://www.atlassian.com/blog/ai-at-work/atlassians-design-md-is-here-what-we-learned-testing-portable-design-context-in-practice — Atlassian
- Teaching AI to speak our design language — https://www.atlassian.com/blog/ai-at-work/teaching-ai-to-speak-our-design-language — Atlassian
- Atlassian Design System: Building the context engine for the AI era — https://www.atlassian.com/blog/ai-at-work/atlassian-design-system-building-the-context-engine-for-the-ai-era — Atlassian
- Teaching agents product design at Vercel — https://vercel.com/blog/teaching-agents-product-design-at-vercel — Vercel
- How our agents build on-brand pages with design.md — https://vercel.com/blog/how-our-agents-build-on-brand-pages-with-design-md — Vercel
- Design Engineering at Vercel — https://vercel.com/blog/design-engineering-at-vercel — Vercel
- Full Tutorial: Design to Code with Cursor's Head of Design — https://creatoreconomy.so/p/design-to-code-with-cursor-head-of-design-ryo-lu — Peter Yang
- Ryo Lu — It's All the Same Thing — https://www.dialectic.fm/34-Ryo-Lu-It-s-All-the-Same-Thing-2cd46137d5888051889cfd660458f2a3 — Dialectic