企业官网建设流程全解析

generative-ai-for-beginners 第 12 课：为 AI 应用设计可信、透明且包容的用户体验

【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners

本篇技术指南围绕开源课程 generative-ai-for-beginners 的《Concevoir l'expérience utilisateur pour les applications d'IA》（Designing UX for AI Applications）一课展开，聚焦于如何为教育类生成式 AI 应用设计"实用、可靠、可访问、愉悦"的用户体验，并深入讲解信任与透明度（可解释性、用户控制）以及协作与反馈机制。读完本文，你将掌握一套可落地的 AI 应用 UX 设计清单，并能在本仓库示例代码与测试用例中找到对应的实现佐证。

引言：为什么 AI 应用必须认真设计用户体验

用户体验（User Experience, UX）指用户与某个具体产品、服务（无论是系统、工具还是设计）互动和使用的方式。在开发 AI 应用时，开发者不仅要确保体验高效，还要确保体验合乎伦理。对生成式 AI 而言，这个要求更高：模型的输出由概率生成、可能有幻觉或错误，界面如何呈现结果、如何解释决策、如何收集反馈，直接决定用户是否信任并愿意持续使用应用。

本课（12-designing-ux-for-ai-applications/README.md）覆盖三个领域：

• 用户体验入门与理解用户需求；
• 为信任与透明而设计 AI 应用；
• 为协作与反馈而设计 AI 应用。

课程依托一个虚构的教育初创公司场景，其核心用户是两类人：教师和学生。二者需求各异：教师需要自动化批改、生成教学材料；学生需要复习卡片、个性化辅导。以用户为中心的设计（user-centered design）要求产品对目标人群保持相关性与价值。

好体验的四根支柱：实用、可靠、可访问、愉悦

课程指出，一个提供良好用户体验的 AI 应用应当同时做到实用（useful）、可靠（reliable）、可访问（accessible）与愉悦（pleasant）。

实用（Usability）

实用意味着应用的功能与其预期目的匹配。例如：

• 自动化批改的应用，应当能基于预设标准准确且高效地为学生作业打分；
• 生成复习卡片的应用，应当能基于数据产出相关且多样的问题。

可靠（Reliability）

可靠意味着应用能一致地、无差错地完成任务。但 AI 和人类一样不完美，应用可能遇到需要人工干预或纠正的错误场景。错误如何处理，正是本课第三节"协作与反馈"讨论的核心：把容错与纠错路径设计进产品，本身就是可靠性的一部分。

可访问（Accessibility）

可访问意味着把体验扩展到拥有不同能力的用户（包括残障用户），确保没有人被排除在外。遵循可访问性指南与原则，AI 方案对所有人更包容、更好用。本仓库第 7 课 07-building-chat-applications/README.md 的无障碍小节给出了更细化的落地清单，可作为本节的实现扩展：

• 视觉障碍：高对比度主题、可缩放文字、屏幕阅读器兼容；
• 听觉障碍：文本转语音与语音转文本、音频通知的视觉提示；
• 运动障碍：键盘导航支持、语音命令；
• 认知障碍：简化语言选项。

其中"键盘导航支持"直接呼应本课练习中"网页应用必须同时可用鼠标和键盘导航"的要求。

愉悦（Pleasant）

愉悦意味着应用令人乐于使用。有吸引力的体验会对用户产生积极影响，促使用户回流，进而提升产品价值。

需要清醒认识的是：并非所有挑战都能靠 AI 解决。AI 的价值在于增强用户体验——无论是自动化重复的人工任务，还是个性化用户体验。设计时应当先识别"哪些环节真正需要 AI"，而不是为了用 AI 而用 AI。

为信任与透明设计：警惕"不信任"与"过度信任"

构建信任是设计 AI 应用的关键。信任确保用户确信应用能完成任务、稳定产出结果，且结果符合需求。但这一领域存在两类风险：

• 不信任（Mistrust）：用户对 AI 系统几乎没有信任，导致拒绝使用应用；
• 过度信任（Overtrust）：用户高估 AI 系统的能力，过度依赖。

课程给出了一个非常具体的过度信任案例：自动化批改系统若被教师过度信任，教师可能不再抽查部分试卷来验证系统工作是否正常，从而造成学生分数不公或不准确，也错失反馈与改进的机会。

确保信任居于设计中心有两条路径：可解释性（Explainability）与控制（Control）。

可解释性：让用户看懂 AI 如何决策

当 AI 参与重要决策（例如向下一代传授知识）时，教师和家长必须理解 AI 的决策过程——这就是可解释性：理解 AI 应用如何做出决策。为可解释性而设计包括：

1. 标明 AI 身份：受众必须意识到结果由 AI 生成而非真人。课程给出了措辞范例——与其说"现在开始与你的导师聊天"，不如说"使用能适应你的需求、按你的节奏帮助你学习的 AI 导师"。这种措辞让用户清楚对话对象是 AI 而非人类教师。
2. 说明数据与角色边界：AI 如何使用用户及个人数据应当透明。例如，学生角色可能受角色限制：AI 不能直接揭示问题答案，但可以引导用户思考如何解决问题。
3. 简化解释：学生和教师未必是 AI 专家，因此关于应用"能做什么、不能做什么"的解释必须简化、易于理解。

以下三张图分别对应上述三点在课程中的示意：

仓库中的人物角色（persona）式提示词是"角色边界"的一种工程化实现。例如 06-text-generation-apps/python/oai-history-bot.py 通过系统提示词限定模型扮演历史人物，并要求"不知道就说不知道"：

prompt = f""" You are going to play as a historical character {persona}. Whenever certain questions are asked, you need to remember facts about the timelines and incidents and respond the accurate answer only. Don't create content yourself. If you don't know something, tell that you don't remember. Provide answer for the question: {question} """

这段代码同时体现了"诚实表达能力边界"（拒绝编造）与"明确 AI 角色身份"两条可解释性原则，与本课的观点一一对应。类似地，06-text-generation-apps/python/oai-study-buddy.py 用固定输出格式（概念 → 示例代码 → 解释）约束模型，让回答对学生可预期、可理解。

控制：把修改权与数据决定权交给用户

生成式 AI 在 AI 与用户之间建立了协作关系：用户可以通过修改提示词获得不同结果；结果生成后，用户也应能修改输出，从而获得掌控感。

课程以 Microsoft Copilot（原 Bing Chat）为例说明了两种控制机制：

1. 调节提示：根据格式、语气和长度调整请求，并可对生成结果继续编辑修改；
2. 数据开关：用户可以自行选择启用或禁用AI 使用的数据。对学校应用而言，学生可能希望把个人笔记与教师资源一起作为复习材料——是否允许 AI 使用这些数据，应当由用户决定。

课程特别强调：设计 AI 应用时，刻意性（intentionality）是防止过度信任的关键——要在提示与结果之间制造"摩擦"，时刻提醒用户：这是 AI，不是人类同伴，从而避免用户对能力产生不切实际的期望。

仓库中的输入校验模块 shared/python/input_validation.py 是"把控制权落在工程实现上"的例证：sanitize_prompt_input()会剥离模板注入（{{...}}）、变量替换（${...}）、<script>标签与javascript:协议等危险模式，并支持strict模式仅保留安全字符；validate_text_input()可限定输入长度与最小长度。对应测试 tests/test_input_validation.py 逐一验证了这些行为（如test_removes_template_injection、test_removes_script_tags）。这类输入校验从源头上限制了用户能"喂"给模型的内容，正是本课"控制"原则在代码层的落实。

为协作与反馈设计：让用户参与纠错与改进

生成式 AI 的本质是用户与 AI 的协作。大多数交互是"用户输入提示 → AI 生成结果"，那么：如果结果不正确怎么办？应用如何处理错误？AI 是责备用户，还是花时间解释错误？

课程给出的答案有两层：

1. 内建反馈回路（Feedback Loop）：AI 应用应当被设计为既能接收反馈也能给出反馈。这不仅能帮助 AI 系统改进，还能建立用户信任。最简单的实现就是一个"点赞/点踩"按钮。

2. 清晰传达能力边界并优雅处理越界请求：当用户请求超出 AI 能力范围时，应用应有既定的处理方式。例如，只用历史和数学数据训练的应用无法回答地理问题，此时系统应给出类似回应："抱歉，我们的产品仅使用以下学科的数据训练……我无法回答你提出的问题。"

课程还提示了常见的系统错误场景：用户需要超出 AI 范围的信息帮助、应用对可生成摘要的问题/学科数量设限等。设计要点是：为反馈和错误处理留出空间，并以简单、易于理解的方式呈现——错误提示要可解释，而不是冷冰冰的失败。

值得注意的是，第 7 课 07-building-chat-applications/README.md 把这一思想延伸到了聊天应用的质量监控维度：课程列出 Uptime、响应时间、精确率（Precision）、召回率（Recall）、F1 分数、困惑度（Perplexity）、用户满意度指标、错误率、再训练周期与异常检测等可量化指标，并在责任 AI 六原则（公平、可靠与安全、隐私与安全、包容、透明、问责）框架下逐条给出了聊天开发者的实践建议。这与本课"反馈 → 改进 → 信任"的循环互为表里：反馈数据正是驱动上述指标评估与再训练周期的输入。

与责任 AI 课程衔接：UX 是风险缓解的最外层

本课在课程体系中并非孤立存在。第 3 课 03-using-generative-ai-responsibly/README.md 给出了生成式 AI 风险缓解的四层模型：模型层 → 安全系统层 → 元提示/接地层 →用户体验层，并明确指出"UX 层是用户通过界面直接与模型交互的最终一层"，设计 UI/UX 可以限制用户能发送给模型的输入类型以及展示给用户的文本与图像，同时部署 AI 应用时还必须对"应用能做什么、不能做什么"保持透明。该课也直接链接到本课作为完整参考。两课结合，可以看到一条完整的链路：可解释性措辞与能力边界声明（本课）正是风险缓解 UX 层的具体手法。

关于提示词修改与能力约束的更多工程手段，可进一步参考本仓库的 04-prompt-engineering-fundamentals/README.md；若需在提示词中注入动态信息以限定模型行为，11-integrating-with-function-calling/README.md 的函数调用机制提供了另一种结构化交互方式。

实战练习：把 UX 原则落地到你已有的 AI 应用

课程在结尾给出一套可操作的四步练习，建议你针对已经构建的任何 AI 应用逐项落实：

• 愉悦（Pleasant）：思考如何让应用更令人愉悦。是否在各个环节都提供了解释？是否鼓励用户探索？错误消息是如何措辞的？
• 实用（Usability）：如果是网页应用，确保应用既能用鼠标也能用键盘导航（对应前述无障碍清单中的键盘导航支持）。
• 信任与透明（Trust and Transparency）：不要完全信任 AI 及其输出。考虑如何在流程中引入"人在环上（human-in-the-loop）"来验证结果，同时思考并实现其他达成信任与透明的手段。
• 控制（Control）：把用户提供给应用的数据的控制权交还用户。实现一种让用户能启用/禁用 AI 应用数据收集的机制（对应 Copilot 的数据开关，以及仓库中输入校验模块对输入边界的约束）。

后续学习路径

本课在课程体系中属于第 12 课，与之强相关的进阶内容包括：

• 第 13 课 13-securing-ai-applications/README.md：在信任与透明之上，进一步保障 AI 应用的安全；
• 第 8 课 08-building-search-applications/README.md：通过检索增强生成（RAG）把模型限制在可信来源内，从内容供给端增强可靠性与可解释性；
• 第 18 课 18-fine-tuning/README.md：针对特定领域微调模型，提升专业场景下的准确性与用户体验。

小结：为 AI 应用做 UX 设计，本质上是回答三个问题——用户需要什么（实用与可访问）、用户凭什么信任（可解释性与控制）、用户出错了怎么办（反馈与容错）。把这三问落到界面、措辞与工程实现上，你的 AI 应用才真正"人们能用、也想用"。

【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners