generative-ai-for-beginners 第 12 课：AI 应用的用户体验（UX）设计——信任、透明与反馈的工程实践

本文基于 generative-ai-for-beginners 仓库中的第 12 课《Designing UX for AI Applications》（含仓库内的阿拉伯语版 translations/ar/12-designing-ux-for-ai-applications/README.md 与英文版 12-designing-ux-for-ai-applications/README.md）展开。课程以一个虚构的教育创业公司（用户为教师与学生）为主线，讲解如何从"有用、可靠、可访问、愉悦"四个维度评估 AI 应用，并通过可解释性、控制权与反馈闭环三大设计手段构建用户信任。读完本文，你能获得一套可落地到任何生成式 AI 应用的 UX 评估清单，以及"协作 + 反馈 + 错误处理"的设计范式，并可以对照仓库源码验证这些原则在真实示例代码中的体现。

1. 什么是 UX，以及 AI 应用为什么要专门讲 UX

用户体验（User Experience, UX）指用户与某个产品、系统、工具或设计进行交互和使用的方式。开发 AI 应用时，开发者不仅要保证体验"有效"（effective），还要保证它"合乎伦理"（ethical）。这正是本课程把它单列一课的原因：生成式 AI 的输出具有不确定性，传统的"点按钮出结果"的确定性交互假设不再成立，信任、透明与反馈必须被显式设计进产品。

本节课程覆盖三大领域（与原文档目录一致）：

• 用户体验导论与理解用户需求；
• 面向"信任与透明"设计 AI 应用；
• 面向"协作与反馈"设计 AI 应用。

学习目标是：理解如何构建满足用户需求的 AI 应用，并能够设计出促进信任与协作的 AI 应用。前置知识方面，原文档建议读者先了解"用户体验与设计思维"（user experience and design thinking）的公开资料，再进入本课程内容。

2. 理解用户需求：以教师与 students 两类用户为中心

课程设定的场景是一家虚构的教育类创业公司，其核心用户分为两类：教师与学生，两类用户各有独特需求。用户中心设计（user-centered design）的核心是确保产品对其目标人群"相关且有益"。

原文档给出了一条可直接用于自测的总原则：一个提供良好用户体验的应用应当是"有用的（Useful）、可靠的（Reliable）、可访问的（Accessible）、愉悦的（Pleasant）"。四个维度逐一拆解如下。

2.1 有用性（Usability / Useful）

"有用"指应用具备与其既定目标匹配的功能。课程给出的两个教育场景示例：

• 自动批改作业：应用应能基于预先定义的评分标准（rubric），准确且高效地给学生作业打分；
• 生成复习闪卡：应用应能基于已有数据生成相关且多样化的复习问题。

换言之，判断有用性的标准是"功能是否命中目标任务"，而不是功能数量多少。

2.2 可靠性（Reliability）

"可靠"指应用能持续、无错误地完成任务。但课程特别指出：AI 和人一样并不完美，天然存在出错倾向。应用会遇到错误或意外情况，可能需要人工介入或纠正。这引出一个设计问题——"错误发生时怎么办？"原文档把该问题留给最后一节（协作与反馈）回答，这提示我们：可靠性与反馈机制在设计上是一体的。

2.3 可访问性（Accessibility）

"可访问"指把用户体验扩展到不同能力水平（包括残障）的用户，确保没有人被排除在外。遵循可访问性指南与原则，能让 AI 方案更具包容性、更易用、对所有用户更有价值。课程在"任务"部分进一步给出了一条可执行的验收标准：网页应用必须同时能用鼠标和键盘完整导航。

2.4 愉悦性（Pleasant）

"愉悦"指应用用起来令人享受。有吸引力的用户体验能正向影响用户，促使他们回访应用，从而提升业务收益。愉悦性还包括错误信息的措辞方式——是责备用户，还是用建设性的语言引导用户。

需要强调原文档的一句边界声明：不是每个问题都适合用 AI 解决。AI 的角色是"增强"用户体验——自动化手工任务、个性化体验，而不是替用户做所有决策。

3. 面向信任与透明设计：可解释性与控制权

构建信任是 AI 应用设计的核心。信任确保用户相信应用能完成工作、持续交付结果，且结果正是用户需要的。原文档指出这一领域的两大风险：

• 不信任（Mistrust）：用户几乎不信任 AI 系统，直接导致用户放弃你的应用；
• 过度信任（Overtrust）：用户高估 AI 系统的能力，对系统给予过高信任。

课程给出的过度信任案例非常具体：在自动批改系统中，如果教师过度信任系统而不去复核部分试卷，可能导致学生得到不公平或不准确的分数，同时错失反馈与改进的机会。

把信任放在设计中心有两个抓手：可解释性（Explainability） 与 控制权（Control）。

3.1 可解释性：让用户看懂 AI 如何得出结果

当 AI 参与"知识传授给下一代"这类决策时，教师和家长必须理解 AI 的决策方式。可解释性的设计要点有三条：

1. 标注 AI 身份：受众必须意识到输出是 AI 生成的，而非人类生成的。原文档给出了一对可直接照抄的话术改写：不要写"Start chatting with your tutor now"（现在就与你的导师开始聊天），而要写"Use an AI tutor that adapts to your needs and helps you learn at your pace"（使用能适应你需求、按你的节奏帮你学习的 AI 导师）。差别在于后者显式声明了 AI 身份并说明其能力边界。
2. 按角色（persona）约束数据与行为：例如"学生"角色的用户会受到基于角色的限制——AI 可能不允许直接给出题目答案，但会引导用户自己思考解题路径。这解释了"AI 如何使用用户与个人数据"也是可解释性的一部分。
3. 简化解释：学生和教师都不一定是 AI 专家，因此对"应用能做什么、不能做什么"的解释必须简单易懂。

可参考 12 课的图片目录 之外的课程图示：可解释性落地页示意（explanability-in-ai.png）、按角色作答示意（solving-questions.png）与简化能力说明示意（simplified-explanations.png）。

3.2 控制权：让用户能改 Prompt、能改结果、能管数据

生成式 AI 天然形成 AI 与用户之间的协作关系，控制权体现在三个层面：

• 改 Prompt：用户可以调整指令（格式、语气、长度）以获得不同结果；
• 改结果：输出生成后，用户应能修改输出内容，从而获得掌控感；
• 管数据（opt-in / opt-out）：用户可以决定是否让自己的数据被 AI 使用。课程示例：学校应用中，学生可能希望自己的笔记加上教师资料一起作为复习材料，也可能明确不希望如此。

原文档引用了 Bing 的截图作为控制权的界面范例（bing1.png 展示按格式/语气/长度定制指令与编辑结果；bing2.png 展示数据使用开关）。

设计要点（原文档原话转述）：设计 AI 应用时，"意图性"（intentionality）是防止用户过度信任、避免形成不切实际能力预期的关键。一个可行做法是在"指令"与"结果"之间制造摩擦（friction），并不断提醒用户：这是 AI，不是另一个人。

4. 面向协作与反馈设计：反馈闭环与错误处理

生成式 AI 的交互范式是"用户输入 Prompt → AI 生成输出"。课程随即抛出三个必须回答的问题：如果输出错误怎么办？应用如何处理错误？AI 是责备用户，还是花时间解释错误？ 原文档给出的设计要求：

1. 应用必须内建"接收反馈 + 给出反馈"的双向能力。这不仅帮助 AI 系统改进，也持续积累用户信任。反馈闭环应被纳入设计本身，最简单的形态是输出旁的"点赞 / 点踩"（thumbs up / down）。
2. 清晰沟通系统的能力与边界。当用户提出超出 AI 能力范围的请求时，系统要有明确的应对方式（示意见 feedback-loops.png）。
3. 系统性错误要有标准化的降级话术。课程示例：一个只在"历史"和"数学"数据上训练的 AI 应用无法回答地理问题，此时系统应给出类似回复："抱歉，我们的产品仅在以下科目上接受训练：……，我无法回答你所提的问题。"这种回复同时做到了承认边界、说明原因、不指责用户。

结论与原文档一致：AI 应用注定会犯错，因此设计时必须预留用户反馈的入口，并以"简单且可解释"的方式处理错误。

5. 结合仓库源码：这些 UX 原则在示例代码里如何落地

课程本身是设计导向的，但仓库中的示例代码恰好为上述原则提供了可核对的实现证据，可以作为延伸阅读。

5.1 "简单且可解释"的错误信息

课程要求错误处理"简单、易于解释"。仓库的共享输入校验模块 shared/python/input_validation.py 是一个直接示范：

• validate_number_input 在越界时抛出带明确取值范围的 ValueError，例如 "number must be between 1 and 100, got X"，提示中同时包含字段名、合法区间与用户实际输入；
• validate_text_input 对超长输入返回 "input is too long. Maximum 500 characters allowed, got N" 这类可行动的提示，而不只是笼统的 "invalid"。

从源码结构看，这类"错误即解释"的写法正是第 4 节所说"错误处理要可解释"的工程化形式：错误信息本身承担了向用户说明系统边界（max_length、min_val/max_val 等默认参数）的职责。

5.2 系统 Prompt 与身份/能力声明

"可解释性"的第一条是让用户知道面对的是 AI 及其能力边界。聊天示例 07-building-chat-applications/typescript/chat-completions-app/src/main.ts 中，input 数组显式携带 role: "system" 的消息来声明 AI 的身份与行为约束，并用 max_output_tokens: 100 与 store: false 这类参数控制输出的长度与数据留存——后者与第 3.2 节"用户对数据使用的 opt-in/opt-out 控制权"在意图上相通：用参数把 AI 的行为约束显式写出来，而不是留给用户猜测。

5.3 友好的异常兜底

同一示例在 catch 分支输出 "The sample encountered an error: " 而非堆栈噪音，向量检索示例 08-building-search-applications/typescript/search-app/src/main.ts 也以 console.error("The sample encountered an error:", error) 作为统一兜底。从源码结构看，仓库的示例刻意保持了"捕获异常 → 输出人话"的最低限度反馈闭环，读者可以在自己的应用中把这一层扩展为面向终端用户的降级回复（即第 4 节的"系统能力边界话术"）。

6. 任务清单：把四个维度落到你自己的 AI 应用上

原文档的"任务"（Assignment）要求读者拿自己已构建的任意 AI 应用，逐项实施以下检查——这是一份可直接复用的 UX 审计清单：

• 愉悦性（Pleasant）：如何让应用更愉悦？是否在合适的位置加入了解释？是否鼓励用户探索？错误信息如何措辞？
• 有用性（Usability）：如果构建的是 Web 应用，确保应用可以仅用鼠标、也可以仅用键盘完成导航（可访问性验收标准）。
• 信任与透明：不要完全信任 AI 及其输出——考虑在流程中加入人工环节（human-in-the-loop）来核验结果，并实现其他信任/透明手段（如 AI 身份标注、能力边界说明）。
• 控制权（Control）：把数据控制权交给用户——实现用户可对数据采集进行 opt-in / opt-out 的机制。

7. 小结与后续

本课程的核心脉络可以浓缩为三句话：好 UX = 有用 + 可靠 + 可访问 + 愉悦；信任靠可解释性与控制权双轮驱动；可靠性靠反馈闭环与可解释的错误处理兜底。 仓库中的 shared/python/input_validation.py、07 课聊天示例 提供了这些原则在代码层面的印证。学完本课后，按原文档的指引应继续学习第 13 课，了解如何保护（securing）AI 应用——那是把本文"信任"话题从体验层推进到安全层的自然延伸。