1. 从草图到感知：AI设计范式的根本性转变

在过去的十年里，我参与和主导过不少涉及人工智能功能的产品设计。从最早的推荐算法优化，到后来的智能客服、内容生成助手，再到如今遍地开花的AIGC应用，我最大的感触是： 设计AI，本质上是在设计一种“关系” 。这种关系不再是用户与一个静态、确定、可预测的工具之间的关系，而是与一个动态、不确定、甚至带有某种“性格”的智能体之间的协作关系。传统的用户体验设计工具箱，在面对这种新型关系时，开始显得力不从心。

想想看，我们习惯的UX设计流程是什么？通常是“定义问题 - 用户研究 - 信息架构 - 线框图/原型 - 可用性测试”这样一个相对线性的过程。我们依赖低保真原型（比如在Figma或Sketch里画的线框图）来快速验证界面布局和交互流程。这些原型是“有形”的，按钮就在这里，点击后跳转到那个页面，状态是可枚举的。但AI系统的核心交互，往往是无形的、基于意图的。比如，用户对智能写作助手说“把这段写得更有说服力一点”，这个“更有说服力”背后可能对应着十几种不同的文本改写策略，而AI的选择对于用户来说是一个黑盒。传统的线框图根本无法表达这种抽象意图的输入和概率性的输出。

这就引出了AI设计面临的第一个核心挑战： 如何为抽象和动态的交互进行“草图构思”？ 我们无法像画一个按钮那样，去“画”出一段自然语言对话的多种可能走向。第二个挑战更为深刻： AI系统天生会犯错，且行为会随时间演变，这与经典的可预测、一致性可用性原则直接冲突。 我们如何设计，才能让用户不仅能用，还愿意信任并接纳一个不完美的伙伴？这不仅仅是技术问题，更是设计哲学和心理学问题。

微软研究院在CHI大会上发表的三篇论文，恰好从三个紧密关联的层面，为我们提供了极具实操价值的思考框架和工具： 构思工具、设计准则和期望管理 。它们共同指向一个目标：将AI从神秘的技术黑箱，转变为用户可以理解、预期并与之有效协作的透明伙伴。接下来，我将结合自己的实战经验，对这三个层面进行深度拆解，并补充大量在学术论文之外、真实项目中会遇到的细节与抉择。

2. 核心挑战解析：为什么传统UX方法在AI面前失灵了？

在深入具体方法之前，我们必须先理解问题的根源。传统设计方法在AI系统面前失灵，并非因为这些方法本身不好，而是因为它们所应对的问题域发生了根本性变化。

2.1 从有形交互到抽象意图

传统软件交互是“直接操纵”范式：用户通过点击、拖拽等物理动作，直接对屏幕上的对象进行操作，结果立即可见且确定。设计原型可以完美模拟这种交互。但AI交互，尤其是基于自然语言处理（NLP）和大型语言模型（LLM）的交互，是“意图传达”范式。用户输入一段模糊的指令或问题，AI需要解读意图，并在其庞大的参数空间中生成一个响应。这个过程中存在多重不确定性：

1. 意图理解的歧义性 ：用户说的“简洁一点”，是指缩短长度，还是改用更简单的词汇，或是调整句子结构？
2. 生成结果的多解性 ：对于同一个意图，AI可以生成无数种在技术上“正确”但风格、语气、侧重点各不相同的输出。
3. 输出评估的主观性 ：结果的好坏没有绝对标准，严重依赖用户的具体场景和主观偏好。

实操心得 ：在项目早期，我们团队曾试图用传统的用户故事地图（User Story Mapping）来定义AI功能。结果发现，写出来的用户故事（如“作为一个营销人员，我希望AI能帮我生成广告文案，以便快速完成工作”）过于笼统，完全无法指导具体设计。后来我们将其拆解为“意图层”和“反馈层”故事。例如：“当我对生成的文案说‘更年轻化一些’时，我需要能快速预览3种不同方向的修改（如使用网络流行语、调整句式节奏、引用年轻文化符号），并选择最接近我预期的一种。” 这迫使我们去思考如何设计界面，来暴露和收敛这种抽象意图。

2.2 从静态系统到动态实体

传统软件上线后，功能和行为基本固定，直到下次版本更新。AI系统，特别是那些包含在线学习或定期微调机制的模型，其行为会随着新数据流入而持续演化。今天能完美回答的问题，明天可能因为模型微调或数据漂移而给出略有不同的答案。这种动态性带来了两大设计难题：

1. 可预测性原则的失效 ：用户体验的基石之一是“一致性”，用户学会一个操作后，期望下次同样操作能得到同样结果。AI的动态性打破了这种一致性保证。
2. 测试与评估的复杂性 ：如何测试一个行为会变化的系统？传统的可用性测试捕捉的是某个时间点的快照，但AI系统的体验是时间轴上的曲线。我们需要新的评估方法，关注长期信任度、适应性和用户满意度趋势。

2.3 从完美工具到不完美伙伴

用户对传统软件的容错预期是“零容忍”：计算器不能算错，保存按钮必须能保存。但所有AI系统都有错误率，只是高低不同。用户对AI的容错预期更为复杂，它取决于：

• 错误的代价 ：音乐推荐出错了，代价很小；医疗诊断建议出错了，代价巨大。
• 纠错的成本 ：发现错误并修正它有多难？是点一下“撤销”，还是需要从头开始？
• AI带来的价值 ：即使有错误，AI提供的效率提升或能力扩展是否足以让用户容忍这些错误？

这就将设计焦点从“消除所有错误”不切实际地转向了“管理错误预期和提供优雅的恢复路径”。设计不仅要考虑功能，更要考虑如何构建合理的用户心理模型。

3. 构思阶段：为抽象交互绘制草图——NLP笔记本实践

面对“如何为自然语言交互画草图”这个难题，微软论文《Sketching NLP》提出的“笔记本”概念，给了我极大的启发。它本质上是一种 面向AI的交互原型工具 ，将设计思维的探索过程与NLP技术的可能性进行了深度融合。

3.1 传统工具的局限与笔记本的诞生

传统线框图（Wireframe）擅长表达空间布局和控件，但对时序、对话流和内容变体的表达能力很弱。故事板（Storyboard）能讲故事，但难以快速迭代和连接真实的技术能力。论文中的“笔记本”是一个巧妙的混合体：它看起来像一个增强版的文本编辑器，但集成了快速调用NLP API、并排对比多种输出、标注设计意图和模型限制的能力。

它的核心价值在于创建了一个“共同语言”的场域 ：

• 设计师 可以在里面用自然语言描述设计想法，并立刻看到大致的AI输出效果，避免了“纸上谈兵”。
• NLP科学家 可以看到设计需求具体对应哪些技术挑战（如实体识别、情感分析、文本生成），并能快速反馈当前模型能力的边界在哪里。
• 潜在用户 可以通过与这个“可交互的草图”互动，提供关于输出结果是否有用、是否符合预期的反馈，这种反馈比对着静态图片想象要真实得多。

3.2 实操：如何构建你自己的“AI设计笔记本”

论文描述的是研究环境，但在实际工作中，我们可以用现有工具组合快速搭建一个轻量版的设计探索环境。以下是我们团队采用过的一个有效流程：

步骤一：定义探索框架 不要一上来就画界面。先和产品经理、算法工程师一起，明确要探索的 核心AI能力 和 关键用户意图 。例如，针对“智能邮件起草”功能，核心能力可能是“根据关键词和上下文生成邮件草稿”，关键意图则包括“正式商务邀约”、“委婉的催办提醒”、“友好的会议纪要分享”等。

步骤二：选择原型工具 我们放弃了高保真UI设计工具，转而使用：

• Notion或Coda ：作为“笔记本”本体。它们支持富文本、数据库、并能轻松嵌入交互元素。
• 简单的前端界面（如用Streamlit或Gradio快速搭建） ：用于连接真实的或模拟的AI API，提供可交互的输入输出区域。
• API测试工具（如Postman） ：用于快速尝试不同的提示词（Prompt）和参数，理解模型行为。

步骤三：进行“技术-设计”探索循环

1. 设计假设 ：在Notion中，写下一条用户可能发出的指令，如“帮我写一封邮件，向客户王总解释项目延迟的原因，语气要诚恳并给出新的时间点。”
2. 技术试探 ：在Postman或Gradio界面中，用不同的Prompt格式（如直接指令、提供样例、分步骤指示）调用模型API，生成3-5个版本的邮件草稿。
3. 结果对比与标注 ：将生成的多个版本贴回Notion，并排展示。设计团队和算法团队一起标注：哪个版本在语气上最合适？哪个版本遗漏了关键信息（如新时间点）？哪个版本出现了事实性错误或不当表述？
4. 模式提炼与设计提问 ：基于对比，提炼出设计需要解决的问题。例如：“我们需要一个‘语气’选择器吗？（正式/诚恳/轻松）”、“当AI遗漏用户指令中的关键要素时，界面如何提示用户补充或如何让AI主动询问？”、“是否提供‘重写某一句’的细化控制？”

避坑指南 ：在这个阶段，最容易犯的错误是过早陷入UI细节（比如按钮放左边还是右边）。笔记本方法的核心是 推迟UI决策，优先探索交互逻辑和AI能力边界 。我们曾为一个内容摘要功能争论了很久摘要长度控制滑块的设计，后来用笔记本探索发现，用户更根本的需求是“按角色摘要”（给老板的摘要vs给技术团队的摘要），长度反而是次要的。这完全改变了我们的设计方向。

3.3 从探索到定义：产出物是什么？

经过几轮探索，你的“笔记本”不应该只是一堆杂乱无章的尝试记录。它应该产出以下几类关键设计定义：

1. 意图分类与响应模式库 ：明确系统支持哪些核心用户意图，以及每种意图下，AI可能有哪些典型的、有价值的响应模式（包括成功、模糊、失败的情况）。
2. Prompt设计规范 ：总结出针对不同意图和场景，前端应该如何构造发送给AI的指令（Prompt），包括系统角色设定、上下文组织、输出格式要求等。这是连接设计与技术的桥梁。
3. 交互模式假设 ：基于探索，提出具体的交互模式来解决不确定性。例如：“对于开放式创作请求，采用‘先生成多个选项，让用户选择并迭代’的模式；对于有明确标准的修改请求，采用‘单次生成，但提供精细的修正控件（如高亮修改处、解释原因）’的模式。”
4. 技术约束清单 ：明确记录下当前AI能力的限制，如不支持实时联网搜索、对某些专业领域知识掌握有限、生成长文本时可能前后矛盾等。这些约束将直接转化为设计上的“护栏”和“预期管理”措施。

4. 设计准则：18条人机交互指南的深度解读与应用

有了好的构思工具，我们还需要评价设计好坏的标准。微软的《人机交互指南》论文将二十多年的研究浓缩为18条具体、可操作的设计准则，这无疑是AI设计领域的宝贵财富。但如何理解并应用这些准则，需要结合具体场景。

4.1 准则的四大阶段与核心逻辑

这18条准则按交互阶段分为四组，其内在逻辑非常清晰：

• 初始阶段（准则1-4） ：核心是 建立正确的初始预期 。包括说明AI能做什么、不能做什么，解释其如何工作，设置初始信任度，以及告知用户其可能出错。
• 常规交互阶段（准则5-12） ：核心是 保持交互的效率和透明度 。包括提供有效反馈、基于情境提供信息、匹配社会规范、防止误操作、学习用户习惯、适时淡出、提供全局解释等。
• 出错时（准则13-16） ：核心是 优雅地处理失败，并支持用户纠正 。包括明确告知出错、说明原因、提供纠正方法，并从中学习。
• 随时间演变（准则17-18） ：核心是 管理系统的变化，并邀请用户参与改进 。包括通知用户重大更新，以及允许用户提供反馈来改进系统。

4.2 关键准则实战解析与权衡

在实际项目中，这些准则之间常常需要权衡。我以几个最常引发讨论的准则为例：

准则1 & 2：明确系统能力 & 解释系统如何工作 这是“预期管理”的起点。但解释到何种程度？全盘托出技术细节会让用户困惑。我们的实践是采用 分层解释 ：

• 表层（面向所有用户） ：用一句话或一个图标表示核心能力。如“基于您文档的内容提供写作建议”。
• 中层（用户有兴趣时） ：通过“了解更多”链接，用通俗类比解释。如“它通过分析您已写的内容和数百万篇类似文章，来寻找常见的表达模式和优化建议。”
• 深层（面向专业用户或出错时） ：提供技术细节入口。如“本次建议基于文本连贯性模型，置信度为85%。点击查看相关段落。”

准则6：基于情境提供相关信息 这是AI价值的关键。但“相关”的定义是什么？我们曾为一个知识库AI设计问答功能，初期它会把所有可能相关的文档片段都罗列出来，导致信息过载。后来我们引入了“相关性阈值”和“信息聚合”设计：

• 只有置信度高于某个阈值（如70%）的结果才会直接展示为“最佳答案”。
• 其余相关但置信度稍低的结果，被聚合在“其他可能相关的信息”折叠区，用户可以按需展开。
• 同时，系统会说明“之所以提供这个答案，是因为您在问题中提到了‘X’和‘Y’”，建立情境关联。

准则13 & 14：出错时支持有效纠正 & 从错误中学习 这是建立长期信任的关键。一个糟糕的设计是：AI出错后，只给一个红色的“错误”提示，然后让用户自己重头再来。一个好的设计应该：

1. 诊断与解释 ：尽可能说明哪里可能出了问题。例如：“抱歉，我可能误解了您的时间要求。您说的‘下周三’是指5月15日吗？我无法确定是因为您同时提到了‘下周’和‘15号’，而15号是周四。”
2. 提供修正路径 ：提供最便捷的修正方式。如上例，直接提供“是5月15日（周四）”和“是5月16日（下周三）”两个按钮让用户选择。
3. 隐性学习 ：如果用户通过上述按钮进行了纠正，系统应默默记录这个案例，用于优化未来的理解模型。并且，可以在后续合适时机告知用户：“根据您上次的纠正，我现在更清楚您的时间表达习惯了。”

4.3 如何利用准则进行设计评审？

我们团队已将这套准则制作成卡片，用于设计评审会。流程如下：

1. 会前准备 ：设计者陈述设计方案时，需预先对照18条准则，说明自己的设计重点考虑了哪些，在哪些准则上存在权衡或暂时未解决。
2. 集体评审 ：评审会上，参与者（包括设计师、产品、开发、算法）随机抽取3-5张准则卡片。
3. 针对性提问 ：持卡人从自己手中准则的角度，对设计方案提出具体问题。例如，持“准则8：防止误操作”卡片的人可能会问：“当AI自动生成一段文本并插入文档时，如何防止用户误触保存而覆盖了不想保留的内容？有没有提供一键撤销或预览确认？”
4. 记录与迭代 ：将讨论出的改进点记录在案，形成迭代任务。这种方法让评审会从主观的“我觉得不好看”转向客观的“这个设计在‘支持有效纠正’方面可能有所欠缺”，效率和质量都大幅提升。

5. 期望管理：如何让用户接纳不完美的AI？

即使遵循了所有设计准则，AI依然会出错。微软的第三篇论文《Will You Accept an Imperfect AI?》直击这个核心痛点： 用户接纳度不完全取决于准确率，更取决于对错误的预期和纠错成本 。论文研究了三种调整期望的模式：明确声明准确率、解释工作原理、提供性能控制。我们的实战经验与论文结论高度吻合，并有一些更落地的发现。

5.1 声明准确率：数字的游戏与陷阱

直接告诉用户“本功能准确率约85%”看似透明，但效果复杂。

• 对普通用户可能无效甚至反作用 ：大多数用户对百分比没有直观感受。“85%”是高是低？他们会用这个数字作为绝对标准，一旦遇到错误，就会归因为“那15%”，可能更沮丧。
• 对专业用户或高风险场景有效 ：在医疗、金融等领域，专业人士理解概率的意义。告知准确率有助于他们做出知情决策，决定在多大程度上依赖AI的输出作为参考。

我们的实践策略是情境化表达准确率 ：

• 不用抽象百分比，而用更直观的表述。例如，在邮件分类功能中，提示：“自动分类通常很准，但偶尔可能分错，建议您快速检查一下‘重要’文件夹。”
• 结合置信度进行差异化呈现。当AI对某个判断置信度很高时（>90%），可以自动执行并轻量提示（如一个小对勾）；置信度中等时（70%-90%），建议执行并请求确认（“建议归类为‘项目A’，对吗？”）；置信度低时（<70%），则只作为建议列出，不自动执行。

5.2 解释工作原理：构建合理的心理模型

比准确率数字更重要的，是帮助用户建立一个关于AI“如何工作”以及“为何会出错”的合理心理模型。论文中提到“解释如何工作”能提升接纳度，关键在于解释的 颗粒度和时机 。

• 避免过度技术化 ：不要说“本系统采用基于Transformer架构的预训练语言模型，通过注意力机制…”。用户不关心这个。
• 采用因果或类比解释 ：
  • 因果解释 ：“我推荐这家餐厅，是因为它符合您‘评分高’、‘意大利菜’和‘市中心’的要求。” 如果出错了，可以解释：“抱歉，我可能忽略了‘评分高’这个条件，因为这家店是新开的，评分数据还不多。”
  • 类比解释 ：“这个写作助手就像一个经验丰富的编辑，它会根据大量优秀文章的模式给您建议，但它不一定完全理解您独特的个人风格。”
• 在出错时提供解释 ：这是解释最有价值的时机。错误解释应与纠正行动紧密结合。例如，AI错误地合并了两个同名联系人，在提供合并撤销选项时，可以解释：“我将‘张三（销售部）’和‘张三（市场部）’合并了，因为他们姓名和公司相同。如果您需要分开，可以点击撤销。”

5.3 提供用户控制：赋予掌控感以换取包容度

这是提升用户接纳度最有效的手段之一。当用户感到自己对AI的行为有最终控制权和调整能力时，他们对错误的容忍度会显著提高。论文中提到的“允许用户控制AI性能”正是此意。

我们将其具体化为几种设计模式：

1. 灵敏度/严格度调节器 ：例如，在垃圾邮件过滤中，提供从“宽松”到“严格”的滑块。向用户说明：“调到‘严格’时，几乎不会有垃圾邮件漏进来，但偶尔可能误判正常邮件；调到‘宽松’时，确保不错过任何正常邮件，但垃圾邮件可能会多一些。” 让用户根据自己的风险偏好（怕错过重要邮件 vs. 讨厌垃圾邮件）进行权衡。
2. 偏好与规则设置 ：允许用户明确告诉AI自己的偏好或规则。例如，在智能日历调度中，用户可以设置“所有会议默认安排在工作时间”、“避免在午休时间安排会议”、“与客户A的会议至少预留1小时”。AI在这些明确规则内运作，即使其他方面有误差，用户也会觉得系统尊重了自己的意愿。
3. 输出粒度选择 ：对于生成式AI，提供不同详细程度或风格的选项。比如，摘要功能可以提供“仅要点”、“详细摘要”和“带关键引文”三种模式。用户选择了某种模式，就对输出的范围和形式有了预期。
4. 学习开关与反馈循环 ：明确告诉用户“您可以通过纠正我来帮助我学习”，并提供便捷的反馈入口（如“这个建议没用”、“这个分类错了”的按钮）。当用户看到自己的反馈确实让AI后续行为有所改善时，会获得强烈的参与感和掌控感。

5.4 错误成本设计：被忽视的关键因素

论文中一个非常深刻的发现是： 即使整体准确率相同，用户对避免“假阳性”错误和避免“假阴性”错误的AI，接纳度也不同 。这背后是“错误成本”的差异。

• 假阳性（False Positive） ：AI说“有”，但实际上“没有”。例如，安全系统误报警（把好人当坏人），邮件系统误判重要邮件为垃圾邮件。
• 假阴性（False Negative） ：AI说“没有”，但实际上“有”。例如，安全系统漏报威胁（把坏人当好人），疾病筛查漏诊。

通常， 假阳性的纠错成本（解除误报警、从垃圾箱找回邮件）往往低于假阴性带来的后果（安全漏洞、延误治疗） 。因此，在医疗、安防等领域，系统宁可多些误报（假阳性），也不能漏报（假阴性）。设计时必须考虑：

• 明确系统偏向 ：向用户说明系统的设计倾向。例如，“本安全监测系统偏向于敏感，可能会产生一些误报警报，以确保最大程度的安全。”
• 设计差异化的恢复流程 ：对于高成本的假阴性错误，恢复流程可能非常复杂甚至不可逆。因此，对于可能产生假阴性的场景，设计上要增加确认环节或二次验证。例如，在重要文件删除前，即使AI判断为“可删除”，也强制要求用户手动确认。

6. 贯穿全程的设计验证：如何测试动态的、会出错的系统？

传统的可用性测试方法在AI产品面前需要升级。我们不能再只关心“任务完成时间”和“错误点击次数”，而要关注用户的心理模型建立过程、信任度的变化以及对错误的反应。

6.1 测试重点的转移

1. 理解度测试 ：在用户首次接触AI功能后，通过访谈或问卷，测试他们是否理解了系统能做什么、不能做什么、以及大致如何工作。例如：“你觉得这个写作助手是根据什么来给你建议的？”
2. 信任校准测试 ：在用户使用一段时间后，观察他们对AI建议的采纳率。是盲目相信，还是完全不信，还是能合理地选择性采纳？这反映了用户心理模型是否准确。
3. 错误恢复测试 ：故意在测试场景中设置一些AI会出错的环节（当然，要符合伦理，事后向用户说明），观察用户如何发现错误、有何情绪反应、是否能利用你设计的机制（解释、纠正控件）顺利恢复。这是检验准则13-16设计效果的关键。
4. 长期体验研究 ：招募一批用户进行为期数周甚至数月的跟踪研究，记录他们使用频率、满意度、信任度的变化，以及当AI行为因更新而发生变化时用户的反应。这对于评估准则17-18至关重要。

6.2 原型保真度的选择

• 探索概念阶段（笔记本阶段） ：使用最低保真度的“笔记本”原型，重点测试用户意图和AI回应的匹配度，收集用户对多种可能输出的偏好。
• 验证交互模式阶段 ：制作可交互的中保真原型（例如在Figma中使用一些插件模拟AI响应），测试具体的UI控件和交互流程，如用户如何纠正AI、如何调整设置。
• 评估完整体验阶段 ：必须使用连接了真实或高度仿真AI后端的高保真原型或Beta版产品。只有真实的、带有不确定性的AI输出，才能引发用户真实的信任、困惑或挫折反应。

6.3 数据与定性研究的结合

定量数据（如准确率、采纳率、使用时长）很重要，但不足以理解“为什么”。必须结合深度的用户访谈、出声思考法和日记研究等定性方法。

• 为什么用户拒绝了一个正确的建议？ 可能是因为解释不够清晰，导致用户不信任。
• 为什么用户容忍了一个明显的错误？ 可能是因为纠正确实非常方便（一键撤销），或者用户当时有更紧迫的任务。

设计AI系统是一场持续的对话，不是在用户和界面之间，而是在用户的期望与系统的能力之间，在人类的直觉与机器的概率之间。作为设计师，我们的角色不再是创造完美的工具，而是搭建一座坚固而灵活的桥梁，管理好两端的落差，让协作得以顺畅进行。这个过程充满挑战，但也正是其魅力所在——它迫使我们将设计思考从界面表层，深入到认知、心理和关系的层面。