好设计的新标准

过去很长一段时间里，设计师和开发人员之间有一条清晰的分界线。设计师负责研究用户、梳理流程、绘制界面和制作原型，开发人员负责把这些材料变成可以运行的产品。设计稿完成，意味着设计工作进入了“交付”阶段。至于代码如何组织、数据如何流动、界面在真实环境中如何运行，通常被看作实现问题。

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

AI Coding 工具可以根据自然语言、界面截图、设计文件和代码上下文生成可运行的产品。设计师不必先熟练掌握一门编程语言，也可以搭建网站、桌面应用、插件和功能原型；工程师也可以直接从需求描述生成界面；产品经理和研究人员同样能够把想法做成可操作的 Demo。过去只有少数角色能把想法变成软件，现在“做出来”的门槛正在快速降低。

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

因此，Agent 时代设计师的新工作，不是简单地从“画图的人”变成“写代码的人”，而是从描述产品，进一步走向构建、约束、验证和协作交付产品。设计师需要处理的材料也从页面、流程和组件，扩展到代码、设计 token、结构化上下文、权限、规则、版本记录和 AI 的行为轨迹。

本章将从五个方面讨论这种变化：为什么设计师需要构建可运行的东西；设计系统为什么会变成 Agent 的操作系统；人机责任图、上下文地图和权限模型为什么会成为新的交付物；为什么设计需要同时服务人与 Agent；以及当代码回到画布、AI 进入协作流程之后，团队应该如何重新建立共同事实和交付责任。

6.1　设计师也要写代码：从画图到构建可运行的东西

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

每次新媒介出现，设计师都会遇到同一个问题：如果只理解结果长什么样，而不了解结果是如何产生的，就很难判断方案的边界。

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

6.1.1　静态原型为什么不够了

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

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

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

所以，Agent 时代的原型需要从可点击升级为可执行。它不一定要使用生产级架构，也不一定一开始就追求视觉完成度，但至少要让一条核心 loop 运行起来：输入目标、读取上下文、拆解任务、调用工具、展示进度、请求确认、处理失败、输出结果并留下记录。

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

6.1.2　“写代码”不等于转行做工程师

如果把“写代码”理解为设计师必须独立掌握复杂前后端架构、数据库、部署、安全和运维，那么这个要求既不现实，也没有必要。AI Coding 降低了从想法到运行结果的门槛，但没有消除专业工程的复杂性。

对大多数产品设计师来说，更重要的是形成三层能力。

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

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

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

这三层能力共同说明：设计师不一定要成为工程师，但需要对可运行体验具有技术判断力。过去设计师通过图稿表达意图，再由开发人员翻译；现在设计师可以把一部分意图直接变成运行结果，同时也要承担检查翻译是否准确的责任。

6.1.3　从想法到可运行体验

在一次个人网站的改版实践中，笔者先用图像生成工具探索视觉方向，再把选中的方向转换为网页结构和设计 token，最后让 AI Coding 工具基于原有数据与页面架构完成重构。这个流程最有价值的地方，不是用了多少工具，而是始终保留了几个稳定对象：网站原有的数据结构、页面信息架构、设计 token，以及明确的修改范围。

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

一个更稳定的 AI Coding 流程通常包括以下内容：

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

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

图4-1　L1 结果证据：可运行 Demo 不只要“有页面”，还要覆盖核心流程、主要状态、响应式表现和设计系统约束。

6.1.4　可运行不等于可交付

AI Coding 最容易制造的误解，是把“代码跑起来”当成“工作已经完成”。其实，可运行只能证明方案具有某种可行性，离真实交付还有很远。

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

如果涉及真实用户数据、支付、权限、生产环境或外部发送，仅靠设计师和 AI 的判断更不够。工程师仍然需要对架构、性能、安全和可维护性负责。设计师的新责任不是取代研发，而是把体验问题更早带进代码，把设计意图更直接地带进实现，并在交付前对运行结果进行更完整的检查。

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

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

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

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

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

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

这些能力的核心不是记忆语法，而是计算思维：把复杂问题拆解成对象、状态、规则和关系，再用运行结果验证假设。AI 可以补齐大量实现细节，但任务如何拆、边界如何定、结果如何验收，仍然需要设计师和团队作出判断。

6.2　设计系统从组件库变成 Agent 的操作系统

设计系统最初主要解决人与人之间的协作问题。设计师通过组件、样式和规范保持一致，开发人员通过对应的代码组件提高复用效率。一个成熟的设计系统可以减少重复劳动，也能避免同一种功能在不同页面里出现完全不同的表达。

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

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

因此，Agent 时代的设计系统不能只说明“有什么”，还要说明“什么时候用、为什么用、不能怎么用、运行时如何表现”。它更像 Agent 的操作系统：提供可调用的能力，也规定能力之间的关系和边界。

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

为了让 Agent 稳定工作，设计系统至少需要包含以下几层内容。

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

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

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

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

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

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

从这个角度看，设计系统的价值不再只是让页面看起来一致，而是把团队的产品判断压缩成 Agent 可以调用、执行和检查的上下文。

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

这样一来，Agent 接收到的就不再是一张“按钮长什么样”的参考图，而是一份关于按钮如何参与产品行为的合同。设计师的工作也从绘制组件，延伸到定义组件的语义、行为和责任。

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

在 AI Coding 的实践中，设计 token 会显著降低视觉改版成本。只要信息架构、数据结构和组件关系没有发生变化，调整 token 就可以快速改变大量页面的颜色、字体、间距和风格。这也是为什么设计 token 比一份只供阅读的视觉规范更适合 Agent。

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

所以，真正能成为 Agent 操作系统的设计系统，必须同时包含参数、组件、语义、行为和边界。对 Agent 来说，示例和反例同样重要。告诉它“这是正确的表格”不够，还要告诉它“什么情况下不要用表格”“哪些列不能隐藏”“数据为空和没有权限分别如何表达”。

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

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

过去，资深设计师的很多判断存在于个人经验里。例如，他知道 B 端表格应该如何控制信息密度，知道错误提示需要包含什么，知道评审一个表单时先检查哪些状态。这些经验可以写成文档，但文档是否被阅读、是否被准确执行，仍然取决于个人。

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

这意味着设计师过去在晋升材料里总结的“方法论”，开始有机会变成真正可运行的生产工具。方法不再只是描述“我通常怎么做”，而要明确输入是什么、执行顺序是什么、输出什么、什么情况下停止、失败后如何处理、哪些步骤必须由人确认。

图4-2　L3 方法证据：一次成功只有在被拆成任务、规则、验证、重试与人工审批后，才可能成为可复用的 AI 开发系统。

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

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

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

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

当设计系统成为 Agent 的操作系统后，维护它就不只是 DesignOps 的整理工作，而是一项直接影响产品行为的治理工作。

这并非只是一种未来设想。Figma 在介绍设计系统与 MCP 的实践时，把远程 MCP Server 描述为让 Agent 取得组件、变量和设计上下文的标准连接层；Code Connect 则把设计组件与代码库中的真实实现建立映射。¹² 这两个案例只能证明机器读取设计系统的基础设施正在出现，并不能证明“接入后自然会生成好设计”。恰恰相反：连接越顺畅，团队越需要补齐语义、禁用条件、行为状态和测试规则，否则 Agent 只是更高效地调用一套信息不完整的组件库。

6.3　新的交付物：人机责任图、上下文地图、权限模型

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

当 AI 开始理解目标并代表用户行动后，只回答这三个问题不够了。团队还需要明确：一段任务中哪些部分由人负责，哪些部分可以委托给 AI；AI 做出判断时使用了哪些材料；它能读什么、写什么、执行什么；遇到风险时在哪里停下；出了问题之后谁来接管和追责。

因此，Agent 产品会出现三类新的核心交付物。

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

6.3.1　人机责任图：把“谁来做”画清楚

用户旅程图通常以用户为唯一行动者，系统只在每个触点提供反馈。人机责任图则需要同时画出用户、Agent、系统规则和团队责任人。

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

一张可用的人机责任图至少要标出以下内容：

• 任务的每个阶段由谁发起；
• AI 在该阶段是观察、建议、协作、待确认执行，还是可以自动执行；
• 人在其中是操作者、协作者、顾问、审批者，还是观察者；
• 哪些结果必须由人修改或确认；
• 哪些动作可以撤销，哪些动作会产生外部影响；
• AI 失败、越权或不确定时升级给谁；
• 最终对业务结果负责的人是谁。

这里最容易出现的错误，是把“AI 能做”直接等同于“AI 应该做”。模型有能力生成并发送邮件，不代表产品就应该默认授予发送权限；Agent 能根据历史数据给出折扣建议，也不代表它应该独立决定商业承诺。能力是技术事实，责任是设计和组织决策，两者不能混在一起。

人机责任图也不应该在项目早期画完后就保持不变。原型跑出新的越权案例，eval 暴露新的失败模式，真实用户出现新的接管需求，都可能让责任边界移动。因此它更像一份可验证的假设：先画出第一版，再用运行证据不断修正。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

权限模型最终要落到系统能力，而不是停在文档里。高风险工具应该默认不可用，重要写操作应该进入审批，执行结果应该留下审计记录，用户应该能够暂停、降权、撤销和回滚。只有这样，边界才不会因为一次含糊对话而被突破。

6.3.4　把三种交付物放进一个真实任务

如果三种交付物彼此独立，团队仍然很难在开发和验收时使用。一个更直观的方法，是把它们放进同一条任务链里。下面以“处理客户退款申请”的 Agent 为例。

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

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

6.3.5　Spec：把三种交付物连接成可执行合同

人机责任图、上下文地图和权限模型需要被组织进团队和 Agent 都能读取的 Spec。这里的 Spec 不是更长的需求文档，而是一份可执行、可追溯、可验收的共同合同。

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

对于复杂项目，还可以把内容拆成不同文件：PRD 说明为什么做、为谁做和做什么；Design 说明体验、状态和交互如何工作；Plan 和 Tasks 说明准备怎样实施；Test 或 Eval 说明如何判断结果是否正确；Git 和 PR 保存每次实现变化与评审记录。

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

当然，并非每一个低风险功能都需要完整的人机责任图、上下文地图和权限模型。一个只在本地整理草稿、所有结果都可撤销的工具，可以使用简化版本；一个会动用资金、生产数据、账号权限或对外发送信息的 Agent，则需要更完整的责任、边界和审计设计。交付物的重量应该跟着风险、影响半径和可撤销性变化，而不是为了显得专业堆积文档。

图4-3　L2 过程证据：Spec 既是开发前的输入，也是开发后的真实记录；需求、实现、测试和版本记录需要形成闭环。

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

6.4　给两个读者做设计：人与 Agent

过去谈用户体验时，默认用户是人。设计师关心人是否看得懂页面，能否找到入口，能否通过视觉层级理解信息，能否在操作后获得清晰反馈。

当 Agent 开始代替用户查找、比较和执行任务后，产品多了一类非人类读者。界面、数据和服务现在需要被理解两次：一次是人理解，一次是 Agent 解析。

这并不是全新的现象。《Sentient Design》以 18 世纪 70 年代的韦基伍德陶瓷为例：品牌为亲自到店的顾客提供强调氛围、品味和身份的展示空间，同时为代表主人采购的仆人与职员提供图录、样品盒和系统编号。³ 两条服务路径面对同一批商品，却使用不同的信息结构：人需要感受和意义，中间代理需要明确规格和可执行信息。

今天的 Agent 也是新的中间代理。它可能替用户搜索商品、预约服务、填写表单、操作网页或调用企业系统。设计师不仅要让人喜欢一个产品，也要让 Agent 能稳定理解产品提供了什么、当前状态是什么、哪些动作被允许、执行是否成功。

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

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

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

如果只有视觉而没有语义，Agent 就只能“看图猜设计”；如果只有接口而没有人类体验，品牌、信任和情感价值又会被压缩成一组参数。双读者设计的难点，正是让两条路径共享事实但不互相牺牲。

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

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

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

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

6.4.2　面向 Agent 的“可访问性”

人类无障碍设计要求界面不只对视觉上看得见的人可用，还要支持屏幕阅读器、键盘操作和不同感知能力。面向 Agent 的设计可以借用类似思路：一个对象不能只在视觉上像按钮，还要在结构上确实是按钮；一个状态不能只靠颜色表达，还要有明确文本或字段；一个操作完成后，不能只闪过一条提示，还要返回可验证的结果。

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

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

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

6.4.3　不要让 Agent 把品牌压缩成“最便宜的接口”

当 Agent 代替用户做比较时，它天然偏好可量化的信息，例如价格、速度、参数和评分。但很多选择并不只由这些指标决定。用户也会关心品质、审美、可持续性、服务态度、文化认同和品牌价值。

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

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

因此，给两个读者做设计，最终会让设计师同时进入界面层、语义层和服务层。设计不仅是安排人看到的内容，也是在定义机器如何理解产品、用户和任务。

6.4.4　同一项体验需要测试两次

面向人的测试会关注：用户能否理解、是否信任、能否判断和接管。面向 Agent 的测试则要关注：它能否找到正确对象、读取正确状态、遵守权限、处理错误并验证结果。

一个页面对人很好用，不代表 Agent 能可靠操作；一个接口对 Agent 很高效，也不代表人能理解 Agent 做了什么。成熟的产品需要把两类测试放在一起：既观察人如何完成任务，也让不同 Agent 在代表性场景中解析和执行，并比较它们是否出现不一致、误操作和无法恢复的失败。

这会成为新的设计质量维度：产品不仅要对人可用，也要对代表人行动的 Agent 可理解。

6.5　团队协作的新维度：代码回到画布，AI 参与度需要被看见

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

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

Figma 近年的方向很能说明这种变化。Figma Make 把设计材料推进为可运行原型，MCP 让 Coding Agent 读取结构化设计数据，Code Layers 尝试把可运行代码带回共享画布，Agent Skills 则让团队把反复使用的方法封装成可执行能力。⁴ 这些功能是否会成为最终形态仍需要观察，但它们共同指向一个趋势：设计、代码、规则和团队讨论不再适合被分散在互相隔绝的工具里。

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

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

Agent 时代的团队需要一组持续同步的共同事实：当前代码、当前 Spec、当前设计系统、当前权限和当前 eval 结果。

代码说明产品实际上做了什么，Spec 说明团队希望它做什么，设计系统说明它应该如何表达和约束，权限模型说明它可以做到哪一步，eval 和用户反馈说明它是否稳定做对。任何一项长期落后，都会让团队产生不同版本的真相。

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

6.5.2　AI 参与度为什么需要被看见

过去团队通常知道一份产物由谁完成。现在，同一份方案可能包含人的研究判断、AI 的资料整理、设计师的方向选择、Agent 生成的代码、另一个 Agent 的审查，以及工程师最后的修改。如果这些过程完全不可见，团队很难判断结果的可信度，也难以在出现问题时找到责任和修复入口。

AI 使用披露不应该变成“是否使用 AI”的羞辱标签，也没有必要估算一个含糊的“AI 占比”。更有价值的是披露 AI 参与的类型和关键决策点，例如：

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

这些信息可以通过设计历史、Commit、PR、决策记录和验收清单保存。它们的目的不是还原每一次对话，而是让团队知道重要判断从哪里来，哪些地方可以复用，哪些地方需要重新检查。

例如，同一份页面改版可以留下这样一条简明记录：设计师根据用户反馈定义问题，Agent 使用现有设计 token 和代码组件生成第一版，设计师否定了其中的信息结构，工程师修正了数据加载方式，第二个 Agent 检查可访问性，最后由产品、设计和研发共同通过验收。这样的记录不会削弱人的贡献，反而能让团队看见每个角色在哪里提供了关键判断。

6.5.3　角色融合不等于责任消失

当设计师能写代码、工程师能生成界面、产品经理能做原型时，传统角色的执行边界确实会融合。但专业责任不会因此自动消失。

设计师仍然需要对用户目标、交互行为、信息表达、边界状态和整体体验负责；工程师需要对架构、安全、性能、可维护性和生产稳定性负责；产品经理需要对业务目标、范围和优先级负责；研究人员需要对用户证据和解释质量负责。AI 可以参与每一项工作，但它不能成为模糊责任的借口。

更成熟的协作方式，是在项目开始时明确每项决策的 owner，在 Spec 中记录责任和验收条件，在代码和设计变化时邀请相应角色评审。角色可以一起构建，但必须知道谁最终做判断、谁有否决权、谁处理上线后的问题。

这也解释了为什么设计师的新工作会向上下游延伸。前端，设计师要参与问题定义、研究证据和上下文组织；中间，设计师要参与可运行原型、代码实现和行为检查；后端，设计师要参与发布验收、问题复盘和规则更新。设计不再是一段独立工序，而是贯穿产品行为形成和持续校准的责任。

6.5.4　验收是新的协作中心

生成速度提高之后，团队最稀缺的能力往往不是再生成一版，而是迅速判断哪一版正确、哪里不对、能否合并和上线。

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

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

一个适合 AI 生成项目的设计验收，可以按照“范围—行为—系统—风险—结果”五层展开。

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

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

图4-4　L4 交付证据：会生成代码不等于可以交付，团队还需要对上下游协作、实现评审、状态边界、可访问性、性能和真实结果负责。

6.5.5　从个人能力到组织能力

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

可以用四层证据理解设计师 AI Coding 能力的成熟度：L1 用可运行 Demo 证明“能做出来”；L2 用 Spec 和版本记录证明“能稳定做对”；L3 用 Skills 和 Agents 证明“能重复复用”；L4 用协作、验收和业务结果证明“能对交付负责”。

这四层不是工具熟练度排行榜，而是责任范围的扩大。越往后，设计师展示的越不是个人操作速度，而是让团队能够理解、复用、检查和信任这套方法的能力。

本章小结

Agent 时代，设计师的新工作可以概括为五次迁移。

第一，从画静态结果迁移到构建可运行体验。代码开始像草图、原型和组件一样，成为设计材料。设计师不一定要转行做工程师，但需要能构建、检查、修改和参与交付。

第二，从维护视觉规范迁移到建设 Agent 的操作系统。设计系统需要把 token、组件、语义、状态、代码映射和团队规则变成机器可读取、可执行、可评估的上下文。

第三，从交付页面与流程迁移到交付责任、上下文和权限。人机责任图、上下文地图、权限模型和持续更新的 Spec，将设计意图变成团队与 Agent 的共同合同。

第四，从只为人设计迁移到同时为人与 Agent 设计。人需要可理解、可信和有品牌感的体验，Agent 需要稳定语义、明确权限和可验证结果，两者必须共享同一套事实。

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

这一章讨论的是“设计师交付什么、如何工作”。当交付物从一组确定的界面，变成一个会读取上下文、调用工具并持续变化的系统，评价设计的标准也必须随之改变。下一章将继续回答：在这样的系统里，怎样才算设计得好？可用性之外，可信、可回溯、可接管，以及用户判断力是否被保留，会成为新的质量底线。

¹ Figma, “Design Systems and AI—Why MCP Servers Are the Unlock,” 2026，https://www.figma.com/blog/design-systems-ai-mcp/ 。

² Figma Developer Docs, “Code Connect,” https://developers.figma.com/docs/code-connect/ 。

³ Josh Clark with Veronika Kindred, Sentient Design: Crafting Intelligent Interfaces with AI, Rosenfeld Media, 2026，章节 “When the Agent Is Your Customer”；本地原文见 converted-epubs/Sentient Design/sections/072-When-the-Agent-Is-Your-Customer.md。

⁴ Figma, “Figma’s design agent, now with custom tools and greater context,” 2026，https://www.figma.com/blog/agent-custom-tools-context-skills/ 。