你让 AI 给医院做一个预约页面，它很快就能画出搜索框、日期选择器和确认按钮。页面看起来像那么回事，却可能忽略老人看不清小字、患者手边没有病历号，或者医院不允许某些科室线上预约。问题不一定出在“画得不好”，而是 AI 根本没拿到这些信息。
Nielsen Norman Group 的 Tony Alicea 提出，当 AI 开始生成原型、功能乃至可运行的软件，UX 的核心交付物也要改变：不只是写给同事看的研究报告，而是整理出 AI 能直接使用的 context——也就是它工作时能看到的任务说明、规则、例子和背景信息。文章把这项工作称为“UX-context design”。需要先说明：这是一篇框架性文章，没有实验、样本量或效果指标，以下判断均来自作者的主张，不能视为已经验证的行业结论。
AI为什么总画出“平均界面”
AI 见过大量常见界面，因此知道一个搜索页通常长什么样。但据 Alicea 的解释，它不会自动知道你的用户是谁、业务有哪些限制、团队采用什么设计规范，也不知道研究人员此前发现了什么。没有这些 context，它只能依照一般模式生成一个相对通用的方案。
这像请一位熟练的建筑师给陌生家庭设计住宅。建筑师可能交出一栋标准的两层房，却不知道屋主使用轮椅、家里有婴儿，或两个人都需要在家办公。房子并非不能住，只是没有针对真正的生活来设计。
这里的 context engineering，可以理解为给 AI 布置一间完整的工作室：把任务、规则、案例、数据和工具放在它伸手可及的位置。对 UX 来说，就是把用户需求、业务规则、无障碍要求和组件规范等设计约束，变成生成界面时能够调用的工作环境。
设计决定已经散到更多人手里
文章观察到，在一些组织里，设计师已不是唯一生成设计方案的人。产品经理可能让 AI 在开会前做一张原型；工程师可能让编程助手增加导出功能，而助手会顺带决定按钮放在哪里、文案怎么写、报错时显示什么。这些看似细小的选择，本身就是设计决定。
作者因此不主张把 AI 工具只锁给设计师使用，而是把目标改成：无论谁发出指令，生成结果都能带上组织对用户和设计标准的理解。这也改变了 UX 交付物的对象。过去，人物画像、用户旅程、研究报告和标注线框图主要供人阅读，再由人解释并作出决定。若 AI 参与更多构建工作，它也会成为这些知识的消费者。
报告不能原样塞给机器
传统 UX 文档为人的注意力而设计。人物画像放一张照片、起一个名字，是为了帮助同事记住并理解某类用户；AI 不需要被这种叙事说服，它需要的是照片和名字背后的推理依据。
这就是“机器可读设计知识”的含义：把散落在文档里的原则，整理成结构清楚、可以检索或核对的信息，让系统稳定引用。文章也提醒，可以让 AI 从原始访谈记录中提取洞察，但若缺少人的指导，重要结论可能淹没在噪声里，模型也可能抓错重点。因此，所谓 AI-ready（为 AI 准备好的）交付物，仍需由熟悉研究与设计的人筛选，并让不同岗位的使用者容易取得。
一个已经出现的文件范例
文章以 Google Labs 在 2026 年 4 月开源的 DESIGN.md 为例。按照文中介绍，它源自 Google 的 AI 设计工具 Stitch，目前是一份任何人都能采用的草案规范。文件与产品代码放在一起，一部分记录颜色、字号、间距和圆角等精确数值；另一部分用普通文字解释这些数值的用途、适用方式以及应做和不应做的事。
它的关键不只是文件格式，而是取消了一次性的“交接”：AI 工具每次生成内容时都能读取这份设计上下文。作者进一步设想更宽泛的 UX.md，用来连接视觉标准、代码中的真实组件和研究结论。例如，与其交给 AI 一份完整报告，不如明确写出：“当设置流程要求用户提供手边没有的信息时，用户会放弃。”这类陈述更接近机器可以据以判断的约束。
UX交付的，是可持续使用的判断
这套思路值得关注，因为它没有把 UX 简化成“让 AI 画得更漂亮”。真正需要迁移的是组织已经知道、但常常只存在于报告和个人经验里的判断。UX-context design 的任务，是发现这些知识，整理它们，放进 AI 的工作环境，再用团队实际采用的模型测试和修订。
换句话说，界面可以由 AI 出图，但“为什么要这样设计”仍需要 UX 提供。交付物从一份等待阅读的文档，逐渐变成持续参与生成过程的约束。
局限与未知
- 文章没有提供对照实验或量化结果，无法证明加入 context 后能改善多少，也不能断言通用输出与适配用户的输出主要只差 context。
- UX.md 仍是作者提出的设想；供稿在示例列表开头截断，完整结构、维护方式和验证标准均未披露。
- 文中的组织实践属于概括性观察，不宜外推为所有公司都已让 AI 广泛承担设计决定。