设计师的新工作

在许多数字产品团队的典型交付叙事里，设计师负责研究、流程、界面与原型，开发人员负责把这些材料变成可以运行的产品。真实协作从来没有这么整齐：数据、平台能力和实现约束一直会反过来改变设计。只是设计稿与代码常被保存在不同工具中，“设计完成”与“实现开始”仍容易被当成两个阶段。

这条分界线正在变得模糊。

本章所说的AI 编程工具，是指能够结合自然语言、设计材料和代码上下文生成或修改代码的工具。它们让更多角色有机会做出可运行草稿，但能力因任务、代码库、工具和使用者而异：能生成一个局部原型，不等于能独立搭建、维护和发布完整产品。

但门槛降低不等于工作变简单了。一个页面能运行，不等于它可以交付；AI 能生成代码，不等于代码符合现有架构；一个 Demo 看起来完整，也不等于它覆盖了真实数据、异常状态、权限边界、响应式布局和可访问性。生成速度越快，团队越容易在短时间内得到大量“差不多能用”的结果，也越需要有人判断：做的到底是不是正确的问题，AI 改动了什么，哪些地方没有遵守设计系统，哪些结果只能用于演示，哪些结果可以进入生产环境。

因此，Agent 时代设计师的新工作，不是从“画图的人”统一转职为“写代码的人”，而是在职责需要时走近可运行材料，参与构建、约束、验证与协作交付。不同岗位的深度可以不同；产品、工程、安全、研究、业务和运营的专业责任也不会因设计师能改代码而消失。设计材料则从页面、流程和组件，扩展到代码、设计 token、结构化上下文、权限、规则、版本记录和 Agent 的行为轨迹。

本章将从五个方面讨论这种变化：什么情况下设计师需要构建可运行的东西；设计系统怎样成为 Agent 的约束上下文；前文的分工、上下文和权限怎样变成交付物；产品怎样同时服务人和代表人行动的 Agent；以及当代码回到画布、AI 进入协作流程之后，团队如何维护共同事实和交付责任。

图 6-1 设计工作进入可运行交付后的闭环

这不是一条由设计师单独包办的流水线。第四章已经说明怎样把委托主张关联到边界、原型和三路证据，第五章已经说明怎样用证据作出验收决定。本章只向前一步：这些对象怎样成为团队和 Agent 都能使用、能够随实现更新的交付材料，以及设计师在其中承担什么、不能替别人承担什么。

6.1　代码进入设计材料：从描述到可运行验证

“设计师要不要写代码”并不是一个新问题。互联网早期，一些设计师通过 HTML、CSS 和 JavaScript 理解网页这种新材料；移动互联网出现后，触摸、传感器、设备性能和平台规范进入设计判断；AR、VR、智能硬件和智能座舱又把三维引擎、摄像头、定位、网络延迟和多模态识别带进项目。

这些媒介反复暴露同一个问题：如果只理解结果长什么样，却不了解结果怎样产生，就很难判断方案边界。

Agent 时代只是把这个问题推到了更前面。代码不再只存在于设计之后，而开始进入设计过程本身。设计师可以先写一份需求和体验说明，让 AI 生成一个粗糙但可运行的版本；在真实运行中发现状态、数据和逻辑问题；再修改 Spec、设计系统和代码，继续验证下一版。此时，代码和过去的草图、线框图一样，首先是一种思考材料。

6.1.1　静态原型为什么不够了

传统原型擅长回答“用户看到什么”和“用户点完之后去哪里”。对于规则明确的确定性软件，这通常足以帮助团队讨论信息架构、主流程和界面表达。

但 Agent 产品的关键体验发生在运行过程中。AI 会如何理解一句含糊的目标？它会读取哪些材料？它会先做哪一步？工具调用失败后如何恢复？遇到高风险操作会不会停下来？用户中途改变目标时，已经完成的步骤如何处理？这些问题很难通过几张静态页面回答。

例如，设计一个“帮助销售人员整理客户线索”的 Agent，静态原型可以画出客户列表、线索详情和生成摘要的按钮，却无法证明 Agent 会不会把内部备注发给外部客户，也无法证明它能区分“起草跟进邮件”和“直接发送邮件”。只有把最小行动链真正跑起来，团队才能看到上下文、权限和状态之间的关系。

所以，当关键假设发生在运行时，原型需要在可点击页面之外增加可执行层。静态草图仍适合讨论信息结构和方向，可点击原型仍适合检查确定性交互；只有要验证 Agent 怎样读取上下文、调用工具、请求确认、处理失败和留下记录时，团队才需要真正跑起最小行动链。可执行不等于生产级，也不要求第一版追求视觉完成度。

这也是代码进入设计工作的第一个原因：有些体验只有运行之后才存在。

6.1.2　接触代码不等于转行做工程师

如果把“接触代码”理解为所有设计师都必须独立掌握复杂前后端架构、数据库、部署、安全和运维，这个要求既没有说明岗位情境，也混淆了设计参与和工程责任。AI 编程降低了从想法到运行草稿的门槛，没有消除专业工程的复杂性。

对选择进入可运行材料、或岗位明确要求参与实现的设计师，可以按责任逐层建立三类能力。

第一层是构建能力。设计师能够把一个想法做成可操作的 Demo，用真实交互而不是一组截图说明方案。这个 Demo 可以使用模拟数据，也可以只覆盖一条核心流程，但它应该能够被体验、被测试和被讨论。

第二层是检查和修改能力。设计师不一定能从零手写整个项目，但可以学习看懂项目基本结构，知道 AI 修改了哪些文件，通过运行结果、代码变更对比（diff）、控制台信息和测试结果发现明显问题，并要求 AI 在限定范围内修正，而不是每次都推翻重做。

第三层是交付协作能力。直接参与代码交付的人需要理解版本、分支、提交记录（commit）、合并评审（pull request，简称 PR）、测试和验收记录的作用。因为当设计开始直接改变代码时，设计决策就不再只存在于设计文件和评审纪要里，它会成为真实产品的一部分。没有版本管理，团队无法知道谁改了什么，也无法在结果变差时可靠地回退。

这三类能力不是全体设计师的统一晋升阶梯。它们说明的是：参与可运行交付越深，就越需要相应的技术判断和协作能力；没有获得工程与发布授权，仍不能独立作出工程或上线决定。

6.1.3　从想法到可运行体验

在一次个人网站的改版实践中，我先用图像生成工具探索视觉方向，再把选中的方向转换为网页结构和设计 token，最后让 AI 编程工具基于原有数据与页面架构完成重构。这个例子只能说明我的一次工作选择，不代表所有项目都应先生成图像或由设计师直接改代码。它真正提供的经验，是始终保留几个稳定对象：原有数据结构、页面信息架构、设计 token 和明确的修改范围。

如果一开始就让 AI “重新设计整个网站”，它很可能连内容、结构和交互一起重写，最后得到一个看起来新、却无法延续原产品的结果。相反，当设计师说明“数据结构不变”“使用现有组件”“以新的设计 token 替换视觉层”“只修改指定页面”时，AI 的生成空间被压缩，结果也更容易检查。

针对这类已有产品的局部改版，可以采用下面这条轻量闭环：

1. 先说清用户问题、业务目标和本次范围，不急着生成界面。
2. 用 PRD、Design Spec 或简明说明记录核心流程、数据、状态和非目标。
3. 确定设计系统、组件、设计 token 和视觉参考，避免 AI 每次重新发明一套风格。
4. 生成最小可运行版本，优先验证核心流程和数据结构。
5. 检查加载、空状态、错误、禁用、权限不足、数据异常和响应式表现。
6. 通过真实使用和反馈修正 Spec，再进行增量修改。
7. 用版本记录保存每一轮变化，并在合并前完成设计与工程验收。

这里有一个容易被忽略的顺序：视觉不一定要在第一版达到最终质量。对于一个尚未验证需求和结构的产品，过早打磨细节可能会放大返工成本。设计师可以先让核心流程跑通，再依据真实框架重构视觉。但这不等于审美不重要，而是把审美放到更有依据的阶段。产品进入真实使用后，视觉、品牌和细节仍会影响理解、预期与长期使用，需要由相应设计负责人和相关团队继续检查。

6.1.4　可运行不等于可交付

AI 编程最容易制造的误解，是把“代码跑起来”当成“工作已经完成”。其实，可运行只能说明某些假设可以在当前条件下继续验证，离真实交付还有很远。

设计师至少需要检查以下问题：交互是否符合预期；是否遗漏加载、空、错、禁用和异常状态；是否破坏现有组件；是否重复实现已有能力；页面在不同屏幕下是否正常；键盘操作和可访问性是否成立；文案是否清楚；数据异常时是否有兜底；AI 是否修改了任务范围之外的文件；以及结果是否经过产品、研发和测试共同确认。

如果涉及真实用户数据、支付、权限、生产环境或外部发送，仅靠设计师和 AI 的判断更不够。组织需要让工程、安全、测试、业务等有权角色完成各自评审。设计角色的新增贡献不是取代研发，而是把体验问题更早带进代码，把设计意图更直接地带进实现，并参与对运行结果的检查。

换句话说，AI 让设计师更容易做出产品，也让“这个产品为什么值得被做、是否真的做对、出了问题如何处理”变得更重要。

6.1.5　设计师需要把技术学到什么程度

设计师面对代码时，最容易走向两个极端。一个极端是认为 AI 什么都能写，所以完全不需要理解技术；另一个极端是认为必须先系统学习几年计算机专业知识，才有资格做可运行原型。更合适的判断，是根据设计师要承担的责任决定学习深度。

如果目标只是探索一个低风险概念，设计师能够启动项目、修改内容、检查核心交互和保存版本，通常已经足够。如果要进入现有代码库，就需要进一步理解项目结构、组件复用、数据来源、依赖关系和测试。如果要推动结果上线，还必须让工程、安全、测试和运维角色参与，不能把个人 Demo 的做法直接复制到生产环境。

对产品设计师来说，可以优先建立以下技术理解：

• 能区分界面、状态、数据和业务规则，知道问题大概发生在哪一层；
• 能看懂组件、属性、输入、输出和事件之间的基本关系；
• 能理解响应式、异步加载、接口失败、权限不足等运行状态；
• 能通过 diff 判断 AI 修改范围是否合理；
• 能运行基本检查和测试，知道“没有报错”不等于“体验正确”；
• 能说明哪些内容只是演示，哪些内容已经达到可合并或可发布条件。

这些能力的核心不是记忆语法，而是把复杂问题拆成对象、状态、规则和关系，再用运行结果检查假设。AI 可能补齐部分实现细节，但任务怎样拆、边界怎样定、结果怎样验收，仍需要团队中相应角色作出判断。

图 6-2 代码作为设计材料的三层参与，不等于承担全部工程责任

6.2　设计系统扩展为 Agent 的约束上下文

设计系统通常先服务设计与工程协作：设计侧通过组件、样式和规范保持一致，工程侧通过对应代码组件提高复用效率。成熟程度和实际收益因组织而异；本章只关注 Agent 加入后需要补充什么。

当 Agent 开始生成界面和代码之后，设计系统多了一类读取者：Agent。

机器不会像熟悉业务的设计师一样，看到一套组件后自然理解“什么时候该用主按钮”“这个表格为什么不能做成营销卡片”“删除操作为什么不能和普通操作放在一起”。如果设计系统只有组件截图、尺寸和颜色，Agent 只能根据通用模式猜测。它可能使用了正确的颜色和圆角，却在错误的场景里选择了错误的组件。

因此，Agent 时代的设计系统不能只说明“有什么”，还要说明“什么时候用、为什么用、不能怎么用、运行时如何表现”。有人把它比作 Agent 的“操作系统”，但本书只把这个说法当作有限比喻：设计系统提供一部分可调用的组件与规则，不负责模型、工具、权限、任务状态和运行控制的全部系统职能。

6.2.1　从视觉规范到机器可执行规则

团队可以用下面六层作为初始检查表，再按产品和现有设计系统取舍。

第一层是设计 token。颜色、字体、字号、间距、圆角、阴影、动效时长和断点等视觉变量，应该以结构化方式保存，并与代码中的变量保持映射。设计 token 解决的是“基础参数是否一致”。

第二层是组件和变体。系统不只要列出按钮、输入框、表格和卡片，还要说明它们有哪些状态、属性、尺寸和组合方式，并尽可能映射到真实代码组件。组件层解决的是“Agent 调用什么”。

第三层是语义和使用规则。主按钮用于当前页面最重要且明确的动作，危险操作必须使用专门样式并显示后果，空状态需要区分“没有数据”和“加载失败”。这类规则解决的是“为什么在这里这样用”。

第四层是行为与状态。组件在加载、成功、失败、权限不足、数据过长、网络中断和跨设备情况下如何变化，不能只依赖开发人员临场补充。行为层解决的是“产品运行起来之后会发生什么”。

第五层是代码映射和质量检查。设计组件对应哪个真实代码位置，哪些属性可以修改，哪些部分不允许覆盖，生成结果怎样进行可访问性与规则自动检查，都需要成为 Agent 可读取的信息。代码层解决的是“怎样进入真实工程而不破坏系统”。

第六层是治理。规则由谁维护，修改后怎样通知团队，旧版本怎样兼容，Agent 生成的新模式能否进入公共组件库，都需要有明确流程。治理层解决的是“这套约束上下文怎样持续演化”。

从这个角度看，设计系统的价值不再只是让页面看起来一致，还要把一部分经过验证的产品判断写成 Agent 可以读取、执行和检查的上下文。没有被写入设计系统的领域规则、权限和责任，仍应留在各自的系统与治理对象中，不能被组件库吞并。

例如，传统设计规范可能只展示一个主按钮的颜色、字号、圆角和间距。面向 Agent 的规则还需要补充：一个页面默认只有一个主动作；危险操作不能使用普通主按钮；提交过程中按钮进入加载状态且不可重复触发；提交失败后保留用户输入；按钮文案使用明确动词；键盘焦点和屏幕阅读器名称必须可用；代码实现必须调用现有 Button 组件，而不是重新写一套样式。

这样一来，Agent 接收到的就不再是一张“按钮长什么样”的参考图，而是一组关于按钮怎样参与产品行为的规格约束。设计工作也从绘制组件，延伸到定义组件的语义、行为和边界。

6.2.2　设计 token 很重要，但它不是全部

在信息架构、数据结构和组件关系保持不变的局部改版中，设计 token 可以降低成批修改颜色、字体、间距和风格的成本，也比只供阅读的视觉规范更容易被工具读取。但具体收益取决于 token 是否真正映射到代码、页面是否复用组件，以及团队有没有控制生成范围。

但设计 token 只能回答“长什么样”，不能回答“是否应该这样做”。如果只把设计系统理解成一组 token，Agent 可能生成视觉统一但体验错误的产品。例如，它可以让所有按钮使用正确色值，却不知道一个高风险删除动作应该先展示影响范围；可以生成完全符合间距规范的表单，却不知道某个字段只在特定权限下出现。

所以，要成为有效约束上下文，设计系统不能只有 token，还要按需要关联组件、语义、行为和边界。示例和反例同样重要：告诉 Agent“这是正确的表格”不够，还要说明什么情况下不要用表格、哪些列不能隐藏，以及数据为空和没有权限分别怎样表达。

6.2.3　Skill：把个人经验变成团队可执行的方法

设计系统解决的是稳定复用产品语言，Skill 进一步解决稳定复用工作方法。

这里的 Skill 指把适用条件、输入、步骤、验证、失败处理和必要资产封装成可被 Agent 调用的任务方法。它不是跨平台统一标准：不同工具的文件格式、触发规则、权限和运行方式可能不同，团队不能因为文档名称叫 Skill，就默认方法已经可靠。

过去，资深设计师的很多判断存在于个人经验里。例如，他知道企业产品的高密度表格怎样取舍信息，知道错误提示需要包含什么，知道评审一个表单时先检查哪些状态。这些经验可以写成文档，但文档是否被读取和准确执行，仍然取决于工作机制。

当这些方法被封装成 Skill 后，团队可以让 Agent 在特定任务中自动调用。例如，在每次生成页面后检查空状态、错误状态和可访问性；在修改文案时遵守品牌语气；在设计高风险流程时检查确认、回退和审计记录；在提交 PR 前对照设计 token 和组件映射进行检查。

这意味着设计师过去在晋升材料里总结的“方法论”，有机会变成可运行的团队工具。方法不再只是描述“我通常怎么做”，而要明确输入、适用范围、执行顺序、输出、停止条件、失败处理、验证方式和必须由人确认的步骤。一次运行成功只能证明一个样本跑通；只有跨代表性任务反复验证、记录失败并明确维护人，才可以主张它具有复用价值。

6.2.4　设计系统也可能规模化放大错误

一套规则能被 Agent 反复调用，意味着好判断可以被放大，错误判断也会被放大。

如果一个组件本身缺少可访问性，Agent 会在更多页面里复制这个问题；如果一条文案规则对少数用户不友好，它会被快速应用到更多场景；如果 Skill 只检查视觉一致性，不检查真实任务结果，团队可能得到大量“看起来很规范”的错误设计。

因此，Agent 时代的设计系统还需要版本、评审、测试和反馈。每次规则修改都应该知道影响了哪些组件、页面和 Agent 工作流；重要 Skill 应该有适用范围、维护人、失败样本和效果记录；新的团队经验不能因为一次个别反馈就立即成为全局规则，而应先在代表性任务中验证。

当设计系统进入 Agent 的约束上下文后，维护它就不只是设计系统运营（DesignOps）的整理工作，也会直接影响生成结果和产品行为。

Figma 的官方说明提供了一个当下实例：其模型上下文协议服务器（Model Context Protocol Server，简称 MCP Server）可以向 Agent 提供组件、样式、变量和标注等设计上下文，Code Connect 则把设计组件与代码库中的真实实现建立映射。¹² 这些产品事实只说明机器取得设计上下文的基础设施正在形成，不能证明“接入后自然会生成好设计”。连接越顺畅，团队越需要补齐语义、禁用条件、行为状态和测试规则，否则 Agent 只是更高效地调用一套信息不完整的组件库。

图 6-3 面向 Agent 的设计系统需要增加语义、行为与边界规则

6.3　把分工、上下文和权限变成交付物

在传统界面项目里，常见交付物包括用户旅程图、信息架构、线框图、视觉稿、动效说明和设计规范。这些材料主要回答三个问题：用户要完成什么任务，界面如何组织，最终效果应该是什么样。

当 Agent 开始围绕目标连续行动后，只回答这三个问题不够了。团队还需要明确：一段任务中怎样分配判断与执行，Agent 使用了哪些材料，能读什么、写什么、执行什么，遇到风险时在哪里停下，以及出了问题之后谁接管、谁有权决定、谁负责处理后果。

第二至第四章已经分别讨论行为合同、人机分工、上下文、边界和权限。本节不把它们重新发明成一套新理论，而是提出一个交付要求：当这些对象会影响代码、工具调用和验收时，它们不能只留在讨论里，必须进入可维护、可追踪的项目材料。下面三类材料可以分开，也可以合并进同一份 Spec；是否需要完整版本，应按风险和项目规模决定。

表 6-1　三类可运行交付材料

这三种材料并不是为了增加文档数量，而是把过去隐含在产品经理、设计师和工程师脑中的判断外化。只有外化之后，人和 Agent 才有可能依据同一组事实工作。

6.3.1　人机分工与后果处理图：把执行和责任分开

第四章已经把这份材料命名为“人机分工与后果处理图”。它需要同时呈现用户、Agent、系统规则、组织角色和受影响者；重点不是找一个人包办“最终责任”，而是把执行、判断、批准、接管、补救与有权决定的范围分别落实。

仍以销售线索 Agent 为例。它可以自动读取公开客户信息和企业内部客户记录，可以整理线索并建议跟进优先级，可以起草邮件；但是否联系客户、使用哪种价格策略、是否承诺交付时间，可能必须由销售人员决定。若邮件涉及合同、折扣或敏感信息，还需要升级给主管或法务。

一张可用的分工图至少要标出以下内容：

• 任务的每个阶段由谁发起；
• Agent 在该阶段是观察、建议、协作、待确认执行，还是可以自动执行；
• 人在其中是操作者、协作者、顾问、审批者，还是观察者；
• 哪些结果必须由人修改或确认；
• 哪些动作可以撤销，哪些动作会产生外部影响；
• AI 失败、越权或不确定时升级给谁；
• 谁会受到结果影响，谁负责发现、控制和补救不同后果；
• 每个组织角色拥有什么决定权，又不能替谁签署。

这里最容易出现的错误，是把“AI 能做”直接等同于“AI 应该做”。模型能够生成邮件，不代表 Agent 系统已被授予发送权限；Agent 能根据历史数据给出折扣建议，也不代表组织已经授权它作出商业承诺。能力是系统事实，权限是产品与组织决定，后果处理职责还要由有权角色落实，三者不能混在一起。

分工图也不应该在项目早期画完后就保持不变。原型跑出新的越权案例，eval 暴露新的失败模式，任务角色研究发现新的接管条件，都可能要求团队重新决定分工与后果处理。改变权限或自主范围时，还要返回第四章入口门和第五章重验条件，不能只悄悄改图。

6.3.2　上下文地图：把“Agent 知道什么”变得可见

传统设计项目里，大量上下文存在于人的脑中。设计师知道目标用户是谁，产品经理知道本季度目标，研发知道历史代码约束，运营知道哪些表达会引发投诉。人类通过会议、文档和长期合作把这些碎片拼在一起。

Agent 不会自然获得这些知识。如果只给它一句任务描述，它只能依靠通用训练数据和当前对话补全缺失信息。结果可能看起来合理，却并不符合团队真实情况。

上下文地图的作用，是把 Agent 完成任务所需的材料按来源、用途和风险组织起来。常见上下文包括：

• 任务上下文：本次目标、范围、截止时间和交付格式；
• 用户上下文：角色、偏好、历史行为、权限和当前状态；
• 项目上下文：产品定位、业务目标、目标用户、历史决策和版本信息；
• 设计上下文：组件、token、品牌语气、交互原则、研究结论和已验证案例；
• 工程上下文：代码仓库、接口、数据结构、性能要求和不可修改区域；
• 组织上下文：审批流程、合规要求、责任人和升级路径；
• 外部上下文：公开资料、第三方数据、行业规则及其时间和可信度。

每类上下文还要回答：由谁维护，多久更新一次，是否包含敏感信息，Agent 能否自动读取，用户是否能看到和删除，输出结果是否需要引用来源。

如果缺少这些说明，所谓“让 Agent 了解更多上下文”很容易变成无限收集数据。上下文不是越多越好。无关材料会增加冲突和误判，过期材料会让 Agent 做出错误决定，敏感材料则可能带来隐私和权限风险。设计师需要做的是上下文架构，而不是上下文堆积。

6.3.3　权限模型：把边界放进系统，而不是写在提示词里

仅仅告诉 Agent“不要做危险操作”是不够的。提示词是一种软约束，权限才是硬边界。

权限模型需要把 Agent 的能力拆成读取、生成、修改、执行和对外影响等不同层级。例如，一个代码 Agent 可以读取整个仓库，但只能修改当前功能目录；可以运行本地测试，但不能访问生产密钥；可以准备部署计划，但不能直接部署生产环境。一个邮件 Agent 可以读取收件箱并生成草稿，但对外发送必须经过用户确认。

设计权限时，可以重点考虑四个变量。

第一，风险。操作是否涉及资金、隐私、生产数据、账号权限、外部沟通或法律承诺？

第二，可撤销性。结果是否可以完整回退？删除一份临时草稿和删除生产数据库显然不能采用同一种确认策略。

第三，影响半径。操作只影响当前用户、当前文件，还是会影响整个团队、全部客户或外部公众？

第四，置信度和证据。Agent 是否有足够依据执行？当信息冲突、缺失或不确定时，是否会主动停止？

权限模型最终要落到可执行控制，而不是停在文档或提示词里。哪些工具默认不可用，哪些写操作需要什么授权，执行结果保存什么回执，哪些状态能暂停、降权、撤销、回退或补偿，都要随具体后果确定。文档负责说明和追踪，技术控制负责真正阻止越界，两者缺一不可。

6.3.4　把三种交付材料放进同一教学任务

如果三种交付材料彼此独立，团队仍然很难在开发和验收时使用。一个更直观的方法，是把它们放进同一条任务链里。下面继续沿用第四、第五章的客户退款 Agent；这不是新案例，而是把包含 H-01 政策冲突主张的退款任务转成团队可交付的记录。

表 6-2　退款教学任务中的分工、上下文与权限

同一张表把责任、依据和权限放在一起后，设计师更容易发现遗漏。例如，如果 Agent 负责计算金额，却没有读取优惠和已使用权益的上下文，结果就可能错误；如果系统要求人工批准，却没有提供计算依据和影响范围，审批也只是形式；如果发送通知和执行退款使用同一个确认按钮，用户可能在没有意识到资金已经变化时完成操作。

这种任务表可以继续转化为界面状态、工具接口、测试用例和验收清单。它不是另一张只供汇报的图，而是连接设计、代码、测试和治理的骨架。

6.3.5　Spec：把交付材料连接成可维护约定

分工与后果处理、上下文和权限需要被组织进团队与 Agent 都能读取的 Spec。这里的 Spec 指项目当前有效的规格说明，不是法律合同，也不意味着每句话都能被机器执行。它应把叙述性判断与可被代码、测试或 Agent 读取的结构化部分关联起来，并允许团队追溯和验收。

一份供 AI 编程和 Agent 开发使用的 Spec，可以按项目需要包含：用户目标与业务目标、范围与非目标、页面和信息结构、核心流程、数据结构、组件行为、状态转换、异常与边界、不可修改区域、权限规则、验收标准，以及“当前版本明确不做什么”。

对于复杂项目，可以按团队习惯拆成不同文件。例如，PRD 说明为什么做、为谁做和做什么；Design Spec 说明体验、状态和交互怎样工作；实施计划与任务记录说明准备怎样实现；Test 或 Eval 说明怎样取得证据；版本控制和评审记录保存每次实现变化。文件名不是重点，关键是对象、版本和决定能相互定位。

最重要的是，这些文件不能只在开发前使用。真实代码会不断暴露旧文档里没有记录的事实，设计和实现也会在迭代中变化。每一轮完成后，团队都需要把新的边界、状态和决策回写到 Spec，使它成为项目的真实记录，而不是一份已经过期的前期输入。

当然，并非每一个低风险功能都需要三份独立文档。一个只在本地整理草稿、所有结果都可撤销的工具，可以在一页 Spec 中合并说明；一个会动用资金、生产数据、账号权限或对外发送信息的 Agent，则需要更完整的分工、边界、证据和审计记录。交付物的重量应该跟着后果、影响范围和可逆性变化，而不是为了显得专业堆积文档。

这也改变了设计交付的定义。过去设计师交付的是“请把它实现成这样”；现在设计师还要交付“它为什么这样行动、依据什么、不能做什么、怎样证明做对了”。

图 6-4 三类可运行交付材料及其相互定位

6.4　给两类访问者组织同一事实：人与 Agent

用户仍然是人以及会受到结果影响的人。Agent 不是因此获得了与人相同的用户身份；它是在授权范围内代表人读取或操作产品的系统访问者。设计师既要关心人是否看得懂、能否判断和接管，也要关心机器访问路径是否能稳定识别对象、权限、状态与结果。

当 Agent 开始代替用户查找、比较和执行任务后，同一产品事实需要服务两种读取方式：人通过语言、视觉、声音和交互理解；Agent 通过页面语义、结构化数据、API 或工具说明解析。这里的“两类访问者”只是设计视角，不表示两者拥有相同利益、责任或决定权。

6.4.1　人和 Agent 需要的信息并不相同

表 6-3　同一事实的两种读取需求

为 Agent 设计，并不意味着视觉和品牌不再重要，也不意味着所有页面都要变成给机器看的表格。更合理的做法，是让人和 Agent 共享同一套底层语义，再分别使用适合自己的表达方式。

例如，一个按钮在人类界面中可以通过位置、颜色和文案表达重要性；在机器层面，它还需要有明确的操作名称、对象、权限要求和结果状态。一个订单页面可以为人展示图片、价格和物流进度，同时通过结构化字段让 Agent 知道订单编号、可取消时间、退款条件和当前状态。

如果只有视觉而没有语义，依赖页面操作的 Agent 可能只能根据像素和位置猜测；如果只有接口而没有人类体验，品牌、理解和情感价值又会被压缩成一组参数。设计难点不是给两者各造一套互不相干的产品，而是让两条访问路径共享对象、规则和外部状态，同时使用适合各自的表达。

这里还需要区分两种 Agent 使用产品的方式。

一种方式是 Agent 操作原本为人设计的图形界面，例如读取屏幕、点击按钮和填写表单。它的优点是可以直接使用现有软件，不需要所有产品立即改造；缺点是对布局变化、弹窗、动画和模糊状态非常敏感，也更难确认操作是否真的成功。

另一种方式是 Agent 通过 API、MCP 或其他结构化工具直接调用产品能力。它不需要模拟人的手指，而是用明确的输入输出完成任务。这种方式通常更稳定、更高效，也更容易限制权限和保留审计记录，但需要产品团队提前把对象、动作、状态和错误设计清楚。

现实产品往往会同时存在两条路径。Agent 可以在没有接口时临时操作 GUI，在高频和高风险任务中使用结构化工具。设计师需要判断哪种方式适合当前场景，而不是默认让 Agent 永远操作人类界面，或默认所有能力都应该完全开放成接口。

6.4.2　机器可操作性不等于人类无障碍

语义结构、明确状态和键盘可操作性既能帮助部分辅助技术，也可能帮助操作 GUI 的 Agent，但两者不能被合并成同一目标。人类无障碍关乎残障者平等使用产品的权利与实际体验；机器可操作性关乎 Agent 能否稳定解析和调用。团队可以复用基础设施，不能用“Agent 能读”替代对真实残障用户的无障碍研究与标准符合性。

设计师可以重点检查以下内容：

• 页面和数据是否有清楚、稳定的语义层级；
• 对象、字段和操作名称是否一致，避免同一概念在不同位置使用不同含义；
• 组件状态是否能被机器读取，而不只依赖颜色、位置和动效；
• 权限不足、数据缺失、网络失败和业务拒绝是否有不同错误类型；
• 高风险操作是否提供影响范围、确认条件和可逆性信息；
• API、MCP 或其他工具接口是否明确描述输入、输出和副作用；
• Agent 执行后是否能够确认结果，而不是只能假设成功。

这类工作看起来接近信息架构、内容设计和工程规范，但它最终决定的是体验。因为 Agent 一旦读错对象、误解状态或错误判断结果，用户感受到的仍然是产品“不可靠”。

6.4.3　不要让工具字段把品牌压缩成“最便宜”

当比较工具只提供价格、速度、参数和评分等字段时，Agent 更容易围绕这些可用信号优化。但很多选择并不只由这些指标决定。用户也会关心品质、审美、可持续性、服务态度、文化认同和品牌价值。问题不在于 Agent 有一种“天然偏好”，而在于产品向它暴露了什么目标、数据和约束。

如果这些内容只存在于广告口号和设计师的感觉里，Agent 很难稳定理解。设计团队需要思考怎样把品牌定位、语气、价值取舍、适用人群、案例和可核验证据组织成结构化信号。这不意味着把品味简化成一个分数，而是让 Agent 有机会理解“为什么最便宜的不一定最合适”。

同样，用户自己的偏好也应该能够被保存、检查和修改。例如，一个用户始终优先选择可维修、可持续的产品，那么这些偏好需要成为 Agent 的长期约束，而不是每次重新输入。用户还应该知道系统记住了什么，能够纠正和删除错误推断。

因此，面向两类访问者组织事实，会让设计工作同时进入界面层、语义层和服务层。设计不仅安排人看到的内容，也参与定义机器怎样读取产品、用户授权和任务状态。

6.4.4　两条访问路径要在一个任务里联合测试

面向人的证据关注：任务角色能否理解依据，根据证据接受、核验或拒绝，并在需要时接管。面向 Agent 系统的证据关注：它能否找到正确对象、读取正确状态、遵守权限、处理错误并验证结果。

一个页面对人很好用，不代表 Agent 能可靠操作；一个接口对 Agent 很高效，也不代表人能理解它做了什么。但这不是把同一体验机械地“测两次”。团队要沿同一项端到端任务关联系统 eval、任务角色用户研究和必要的专家审查：系统怎样取得状态并行动，人看见什么证据并作出什么决定，外部结果如何回写，失败时两条路径怎样汇合。

这也不是在第五章七个维度之外再加一个孤立的“Agent 可理解性”总分。机器访问失败会分别落入任务与使用质量、行为边界、可回溯、接管恢复或治理主张；它必须按具体失败后果验收。

图 6-5 人类可理解与机器可操作需要联合测试

6.5　团队协作的新维度：代码回到画布，关键 AI 参与可追溯

传统设计协作常常以“交付”为分界。设计师在画布中完成方案，开发人员在代码仓库中完成实现，双方通过标注、评审和走查减少翻译损耗。即使采用敏捷流程，设计文件和真实产品仍然经常是两个世界。

AI 编程和可运行设计工具正在让代码重新进入画布。团队可以在设计阶段查看真实交互、真实状态和响应式表现，也可以把代码中的组件、token 和限制带回设计环境。设计评审因此不再只评“稿”，还会评运行之后暴露的行为。

Figma 的产品变化可以作为一个当下样本。Figma Make 已用于生成和编辑可运行原型；Figma MCP Server 向外部 Agent 提供设计上下文；Code Layers 把 React 支持的交互代码带进画布；官方文档也把 Skill 描述为可复用的指令集。³ 其中部分代码与画布能力在 2026 年仍处于 beta 或分批开放，不能据此断言所有设计工具都会汇合成同一种形态。这个样本能支持的只是：设计材料、运行结果和团队讨论正在出现新的连接方式。

这个变化不会自动带来更好的协作。如果每个人都在自己的 AI 对话里快速生成结果，团队反而更难理解产物从哪里来、依据什么、谁做过判断。个人生产速度提高之后，组织的审查、合并和决策能力可能成为新的瓶颈。

6.5.1　从交付文件到维护共同事实

Agent 时代的团队需要维护一组能够互相定位的当前事实：代码、Spec、设计系统、权限配置、测试与验收结果。

代码和部署配置说明当前系统实际上会做什么，Spec 说明团队批准它做什么，设计系统说明怎样表达和复用，权限配置说明技术上能做到哪一步，测试与用户证据说明已观察到什么。它们都可能不完整，不能把任一份文件宣布为绝对“唯一真相”；团队需要记录版本和差异，知道冲突时由谁判断、怎样回写。

因此，代码进入画布真正重要的地方，不是让设计师在 Figma 里多看几行代码，而是让设计、实现和评审使用同一份运行材料。团队可以比较设计意图与真实结果，可以直接标出某个状态哪里不对，可以在代码变化后同步更新对应规则，也可以把已经验证的交互沉淀进组件和 Skill。

6.5.2　为什么要记录关键 AI 参与

同一份方案可能包含人的研究判断、AI 的资料整理、设计师的方向选择、Agent 生成的代码、另一个 Agent 的审查，以及工程师最后的修改。若这些过程完全不可见，团队会更难判断哪些证据仍然适用，也难以在出现问题时找到修复入口。

记录不应变成“是否使用 AI”的羞辱标签，也没有必要估算一个含糊的“AI 占比”。记录深度要跟随风险和可追溯需求：低风险草稿可以只保存关键版本，高影响改动则要说明 AI 参与类型、输入来源和关键决策点，例如：

• AI 用于检索和整理了哪些资料；
• AI 生成了哪些方案或代码；
• AI 使用了哪些上下文、模型、Skill 和工具；
• 人在哪些地方选择、修改、拒绝或接管；
• 哪些结果经过自动测试，哪些结果经过人工验收；
• 当前还有哪些已知限制和未验证假设。

这些信息可以通过设计历史、提交记录、代码评审、决策记录和第五章的验收包保存。目的不是还原每一次对话，而是让重要主张能回到输入、版本、人工决定与验证结果，并在变化后判断哪些地方需要重验。

例如，同一份页面改版可以留下这样一条简明记录：设计师根据用户证据定义问题，Agent 使用现有设计 token 和代码组件生成第一版，设计师否定了其中的信息结构，工程师修正数据加载方式，另一个 Agent 提供可访问性检查线索；最后，各角色完成授权范围内的评审，由有权人作出合并或发布决定。这样的记录让团队看见每个角色在哪里提供了关键判断，也不会把自动检查写成人工验收的替代品。

6.5.3　执行边界融合，决定权限仍要明确

当设计师能修改代码、工程师能生成界面、产品经理能做原型时，传统角色的执行边界确实会融合。但做过某一步，不等于自动获得相关发布、风险接受或专业签署权。

团队应按组织授权和项目情境分派职责。设计角色通常组织用户目标、交互行为、信息表达、边界状态与体验证据；工程角色通常负责架构、安全、性能、可维护性和生产稳定性；产品与业务角色决定目标、范围与优先级；研究角色负责研究方法、用户证据及其解释边界。实际分工可以重叠，但不能把“通常”写成法律归责，也不能让 AI 成为无人作决定的借口。

项目开始时应明确每类决定的授权人，在 Spec 中记录职责和验收条件，在代码、权限与设计变化时邀请相应角色评审。角色可以一起构建，但必须知道谁能决定进入、合并、发布、降权和停止，谁有否决权，谁处理上线后的不同后果。

这也解释了为什么部分设计岗位会向上下游延伸：前端参与问题定义、研究证据和上下文组织，中间参与可运行原型与行为检查，后端参与授权范围内的发布评审、问题复盘和规则更新。参与深度随岗位和项目变化，不能据此把全部产品责任集中到设计师一人。

6.5.4　验收是新的协作中心

候选生成变快后，团队的验证与决定能力可能成为瓶颈。第五章已把这写成需要用项目数据检查的工作假设，本节不把它升级成普遍规律，只讨论协作怎样围绕验收组织。

过去的设计走查常常集中在视觉还原和主流程。Agent 时代的验收需要覆盖更大的范围：交互是否符合预期，状态和边界是否完整，是否破坏已有组件，是否出现重复代码，响应式和键盘操作是否正常，可访问性是否满足要求，动效是否影响性能，错误反馈是否清楚，数据异常时是否有兜底，以及 AI 是否修改了未经授权的范围。

更重要的是，团队要保存“AI 最初生成了什么、哪里不符合要求、谁如何纠正、最后怎样验证”的证据。这个过程比一张漂亮的最终截图更能证明设计师和团队可以对交付负责。

设计走查可以用“范围—行为—系统—风险—结果”五个视角先整理问题，但正式发布结论仍应进入第五章的质量主张、三路证据、门槛、残余风险和有权决定。

范围层检查本次修改是否仍然服务原目标，是否出现未经要求的额外改动；行为层检查流程、状态、反馈和跨设备表现；系统层检查组件复用、代码结构、数据和设计 token；风险层检查权限、隐私、安全、可访问性和不可逆操作；结果层则检查用户是否真的更容易完成任务，业务目标是否改善，以及新问题是否被带回下一轮 Spec 和 Skill。

这种验收不是设计师一个人把所有事情检查完，而是让不同专业围绕同一份运行结果完成各自判断。设计师负责把体验问题组织出来，并确保它们不会在“代码已经能跑”的压力下被忽略。

6.5.5　从个人能力到组织能力

当一名设计师偶然用 AI 做成一个 Demo，这是个人尝试；当他能用 Spec、版本和验收稳定完成第二个项目，这是可复现过程；当团队把方法沉淀成设计系统、Skill、模板和 eval，它才成为组织能力。

可以用四种证据区分“做出来”与“能交付”：可运行原型证明某项假设能被体验；Spec 与版本记录证明范围和变化能够追踪；经过多任务验证的 Skill、模板与设计系统证明部分方法能够复用；跨专业验收和运行结果则证明团队有条件对限定范围作出交付决定。它们不是个人能力等级，也不存在取得后一项就自动包含前一项的关系。

图 6-6 从个人使用 AI 到组织形成可维护能力

本章小结

对参与 Agent 产品的设计师而言，新工作可以概括为五项扩展。

第一，从只描述静态结果扩展到按需构建可运行体验。代码开始像草图、原型和组件一样成为设计材料；参与越深，越需要相应的构建、检查、修改和协作能力，但这不是全体设计师的统一岗位命令。

第二，从只维护视觉规范迁移到为 Agent 提供约束上下文。设计系统需要把 token、组件、语义、状态、代码映射和经过验证的团队规则变成机器可读取、可执行、可检查的材料，但它不是 Agent 系统的全部“操作系统”。

第三，从交付页面与流程迁移到同时交付分工、后果处理、上下文和权限。分工图、上下文地图、权限模型和持续更新的 Spec，把设计意图变成可维护、可追踪的共同约定；它们不是法律合同，也不需要在所有低风险项目中拆成独立文档。

第四，从只考虑人类界面迁移到同时考虑人和代表人行动的 Agent。人需要可理解、可判断和有品牌感的体验，Agent 需要稳定语义、明确权限和可验证结果；两条访问路径必须共享事实，但人仍是用户与权益主体。

第五，从个人产出迁移到协作交付。代码、设计、Spec、版本、AI 参与记录和验收结果共同构成新的设计证据，角色可以融合，但责任必须更清楚。

这一章讨论的是“设计师交付什么、如何工作”。第五章已经回答怎样用质量主张、证据和门槛判断当前版本是否可以通过；第七章将把视线移向更长时间尺度，讨论个体化、运行时界面、环境化体验和上线后的持续维护怎样改变设计，以及能力扩大之后怎样继续为人保留选择。

¹ Ana Boyer, “Design Systems and AI: Why MCP Servers Are the Unlock,” Figma, 2025 年 8 月 6 日，https://www.figma.com/blog/design-systems-ai-mcp/ 。本文只引用其对 MCP Server 可提供组件、样式、变量与标注上下文的产品说明，不采用文中的推广性效果承诺。

² Figma Developer Docs, “Code Connect,” https://developers.figma.com/docs/code-connect/ 。该功能把设计文件中的组件与代码库实现关联，并可为 Figma MCP Server 提供实现上下文；访问于 2026 年 8 月 9 日。

³ Figma, “Figma Make, Now on Your Local Code,” 2026 年 5 月 28 日，https://www.figma.com/blog/figma-make-now-on-your-local-code/ ；“Code on the Figma Canvas,” 2026 年 6 月 24 日，https://www.figma.com/blog/code-on-the-figma-canvas/ ；Figma Developer Docs, “Create Skills for the Figma MCP Server,” https://developers.figma.com/docs/figma-mcp-server/create-skills/ 。截至 2026 年 8 月 9 日，官方说明仍把部分本地代码与 Code Layers 能力标为 beta 或分批开放；Skill 的定义和格式属于相应工具实现，不是跨平台标准。