generative-ai-for-beginners 第 12 课深度解析：为 AI 应用设计可信、透明且可协作的用户体验

本文以 generative-ai-for-beginners 课程第 12 课（仓库中 保加利亚语版翻译，英文原版）为主体，系统讲解生成式 AI 应用的用户体验（UX）设计方法：从“有用、可靠、可访问、愉悦”四大特性出发，掌握信任与透明（可解释性、控制力）、协作与反馈循环的设计要点，并能结合本仓库的共享工具代码将“友好错误处理”落地到工程实现。

课程定位与前置知识

本课在课程体系中是一门 Learn（概念学习）类型的课程，位于第 11 课“函数调用集成”（11-integrating-with-function-calling/README.md）与第 13 课“AI 应用安全”（13-securing-ai-applications/README.md）之间。课程总览表中对本课的定位是：“学习如何在开发生成式 AI 应用时应用 UX 设计原则”（见 README.md 的 Lessons 表格第 12 行）。

用户体验（User Experience）指用户与某个产品、系统、工具或设计交互和使用的方式。原文档指出：开发 AI 应用时，开发者不仅要关注用户体验是否有效，还必须关注其是否合乎伦理。课前建议读者先花时间阅读关于用户体验与设计思维（design thinking）的资料，再进入本课内容。

课程覆盖三大领域：

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

学完本课后的目标能力是：理解如何构建满足用户需求的 AI 应用，并设计出能够促进信任与协作的 AI 应用。

理解用户需求：良好用户体验的四大特性

课程以一个虚构的教育类创业公司为场景，其中有两类核心用户——教师与学生，每类用户都有独特需求。以用户为中心的设计（user-centered design）始终把用户放在首位，确保产品对目标人群是相关且有益的。原文档给出的核心论断是：

应用必须有用（useful）、可靠（reliable）、可访问（accessible）且愉悦（pleasant），才能提供良好的用户体验。

有用性（Usability）

“有用”意味着应用具备与其设计目的相匹配的功能。原文档举了两个例子：

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

这两类场景都要求功能边界清晰：应用承诺做什么，就必须稳定地做到。

可靠性（Reliability）

“可靠”意味着应用能够持续、无错误地完成任务。但 AI 和人一样并不完美，天然易错，应用可能遇到需要人工介入或纠正的错误与意外情况。原文档在此埋下伏笔：如何处理错误，将在课程最后一节“面向协作与反馈的设计”中回答。

这一点在本仓库的代码结构中可以得到印证。课程为各课练习代码抽出了共享工具模块 shared/python/api_utils.py，其中的 make_safe_request 函数（shared/python/api_utils.py#L15-L53）封装了带超时与重试的 HTTP 请求：默认 timeout=30 秒、retries=3 次，请求失败时捕获 RequestException 并按次数重试，全部失败后才向上抛出。从源码结构看，这正是“可靠性”原则在工程层面的具体体现——对 AI 服务调用等易失败的外部依赖，通过超时与重试保证应用行为的连续性，而不是把瞬时故障直接暴露给用户。

可访问性（Accessibility）

“可访问”意味着把用户体验扩展到拥有不同能力的用户群体，包括残障人士，确保没有人被排除在外。原文档强调：遵循可访问性指南与原则，能让 AI 解决方案对所有用户更具包容性、更易用、更有益。

愉悦性（Pleasant）

“愉悦”意味着应用用起来令人愉快。有吸引力的用户体验会对用户产生积极影响，鼓励用户回访，进而提升业务收益。

需要强调的是：并非每个挑战都能用 AI 解决。AI 的作用是增强用户体验——无论是自动化工 manual 任务，还是个性化用户经历。

面向信任与透明设计 AI 应用

构建信任是 AI 应用设计的关键。信任确保用户相信应用能够完成工作、持续交付结果，且结果符合用户所需。原文档指出这一领域存在两种风险：不信任（mistrust）与过度信任（overtrust）。

• 不信任：用户对 AI 系统几乎没有信任，直接导致用户拒绝你的应用；
• 过度信任：用户高估了 AI 系统的能力，对其过度依赖。

原文档给出的例子极具代表性：一个自动评分系统若遭遇过度信任，教师可能不再逐份检查作业以确认评分系统工作正常，这会导致学生得到不公平或不准确的分数，或错失反馈与改进的机会。

确保信任处于设计中心的两条路径是：可解释性（explainability）与控制力（control）。

可解释性（Explainability）

当 AI 辅助做出影响深远的决策（例如向下一代传授知识）时，教师和家长必须理解 AI 是如何做出决策的——这就是可解释性：理解 AI 应用如何做决策。为可解释性设计包括添加凸显“AI 如何得出该输出”的细节，并且必须让受众意识到输出是由 AI 而非人类生成的。原文档给出了文案改写示例：

• 不推荐：“Start chatting with your tutor now”（现在开始与你的导师聊天）；
• 推荐：“Use AI tutor that adapts to your needs and helps you learn at your pace”（使用能根据你的需求自适应、帮助你按自己节奏学习的 AI 导师）。

可解释性的另一个维度是AI 如何使用用户数据与个人数据。原文档举例：具有“学生”角色（persona）的用户可能受角色限制——AI 不能直接透露问题的答案，但可以引导用户思考如何自行解决问题。这种“引导而非代答”的边界本身就是通过透明沟通传达给用户的重要信息。

可解释性的最后一块关键拼图是简化解释：学生和老师未必是 AI 专家，因此关于应用能做什么、不能做什么的解释应当简洁、易懂。

控制力（Control）

生成式 AI 在 AI 与用户之间创造了一种协作关系：用户例如可以修改提示词（prompt）以获得不同结果；而在输出生成之后，用户应当能够修改结果，从而获得掌控感。原文档以 Microsoft Copilot（原 Bing Chat）为例，说明用户可以根据**格式（format）、语气（tone）和长度（length）**定制提示词，并直接对输出进行追加修改。

另一个赋予用户控制力的机制是数据的 opt-in / opt-out：用户可以决定是否允许 AI 使用自己的数据。原文档举出的场景是：在一款学校应用中，学生可能希望把自己的笔记以及教师资源一并作为复习资料供 AI 使用——用户应当拥有选择权。

原文档在此给出一段值得记入设计原则的提示：

在设计 AI 应用时，“有意为之”（intentionality）是确保用户不过度信任、不对其能力抱有不切实际期望的关键。一种做法是在提示与结果之间制造摩擦（friction）——提醒用户，这是 AI，而不是一个真实的人。

面向协作与反馈设计 AI 应用

如前所述，生成式 AI 在用户与 AI 之间创造协作。大多数交互是“用户输入提示、AI 生成输出”。原文档提出三个值得每个设计者自问的问题：

• 如果输出是错误的，会发生什么？
• 出现错误时，应用如何处理？
• AI 是责怪用户，还是花时间解释这个错误？

由此导出两条设计要求：

1. 应用必须能够接收和给出反馈。这既帮助 AI 系统改进，也建立与用户的信任。设计上应内置反馈循环，最典型的例子就是在输出旁放置简单的“点赞/点踩”按钮。
2. 清晰沟通系统的能力与边界。当用户提出超出 AI 能力范围的请求时，系统应当有明确的处理方式，而不是含糊其辞或直接崩溃。

原文档还讨论了系统级错误：应用中的用户可能需要 AI 范围之外的信息，或应用对可生成摘要的问题数/科目数有上限。例如，一个仅用“历史”和“数学”两科数据训练的应用，可能无法回答地理问题。原文档给出的应对话术是：

“Sorry, our product has been trained with data in the following subjects……, I cannot be able to respond to the question you asked.” （抱歉，我们的产品使用以下科目的数据训练……，我无法回答你提出的问题。）

这条“明示训练边界”的错误处理原则，在本仓库的共享工具模块中能找到工程化的对应实现。shared/python/input_validation.py 提供了一组面向用户输入的校验与净化函数，其错误消息全部采用“说明期望 + 给出范围”的可理解格式，例如：

• validate_number_input（shared/python/input_validation.py#L11-L43）在校验失败时抛出 Please enter a valid {field_name} between {min_val} and {max_val}——不指责用户，而是明确告诉用户合法区间；
• validate_text_input（shared/python/input_validation.py#L46-L93）区分“太长（Maximum N characters allowed, got M）”与“太短”两种失败原因，错误信息携带具体数值；
• sanitize_prompt_input（shared/python/input_validation.py#L96-L151）则净化用于 LLM 提示的输入，剥离模板注入（{{...}}）、变量替换（${...}）、脚本标签等潜在注入模式——这正是“透明沟通能力边界”在输入侧的防线，也与第 13 课的输入安全主题一脉相承。

原文档的结论是：AI 应用并不完美，犯错是必然的；在设计应用时，应当为用户反馈和简单、易于解释的错误处理留出空间。

实战作业：给你的 AI 应用做一次 UX 体检

原文档的 Assignment 要求读者取一个已经构建过的 AI 应用，按以下四个维度逐条检视与改造：

• 愉悦（Pleasant）：如何让应用更令人愉快？是否在处处提供解释？是否鼓励用户探索？错误消息的措辞是什么？
• 可用性（Usability）：若构建的是 Web 应用，确保应用既能用鼠标也能用键盘导航。
• 信任与透明（Trust and transparency）：不要完全信任 AI 及其输出，思考如何把“人”加入流程以核验输出；同时考虑并落地其他实现信任与透明度的方式。
• 控制（Control）：把用户提供给应用的数据控制权交还给用户——实现让用户可以 opt-in / opt-out 数据收集的机制。

结合本仓库代码，这份检查清单可以直接映射为工程动作：错误消息是否像 shared/python/input_validation.py 那样“说明期望而非指责用户”、外部调用是否像 shared/python/api_utils.py 的 make_safe_request 那样带超时与重试、输入侧是否做了注入净化，这些都可以作为“可靠 + 愉悦 + 信任”维度的可验证落地项。

小结

第 12 课把 UX 设计从“锦上添花”提升为 AI 应用的一级需求：以有用、可靠、可访问、愉悦为功能基线，用可解释性与控制力把信任锚定在设计的中心，再用反馈循环与清晰的错误处理承接 AI 必然出现的失误。读完本课并对照仓库中 shared/python 下的输入校验与安全请求实现后，读者应能把这些设计原则转化为可检查、可验证的工程实践，并带着这份 UX 视角进入第 13 课（13-securing-ai-applications/README.md）——在那里将讨论 AI 系统面临的威胁、风险与防护手段，与本课的“透明沟通边界、输入净化”形成直接呼应。