企业官网建设流程全解析

为 AI 应用设计用户体验：generative-ai-for-beginners 第 12 课实战指南

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

用户对 AI 应用的期望早已不止于"能用"。一个模型能力再强，如果界面令人困惑、输出让人无法信任、出错时无从申诉，用户依然会流失。在本仓库的 21 课课程体系中，前 11 课教你如何搭建、调用与编排大模型，而从本课开始，关注点转向"人"——如何把生成式 AI 能力封装成有用、可靠、无障碍且令人愉悦的产品体验。读完本课，你将掌握一套可落地的 UX 设计方法：如何用可解释性与用户控制建立信任，如何用反馈闭环与容错文案处理生成错误，以及如何把课程练习中的 AI 应用改造成更值得被使用的产品。

课程背景与学习目标

本课是全套课程中第一个完全围绕"用户体验"展开的章节（原课程文档 对应英文源文 12-designing-ux-for-ai-applications/README.md），它不引入新的模型 API，而是系统性地回答三个问题：

• 什么是用户体验，如何理解用户需求？
• 如何把"信任"与"透明"设计进 AI 应用？
• 如何为"协作与反馈"设计 AI 应用？

对应地，课程设定了两个学习目标：

• 理解如何构建满足用户需求的 AI 应用；
• 设计能够促进信任与协作的 AI 应用。

在进入具体内容前，课程建议你先了解用户体验与设计思维的基础概念——这是本课所有原则的出发点。

理解用户体验：从"能跑"到"好用"

用户体验（User Experience, UX）指用户如何与某个具体产品、服务或系统交互并加以使用。开发 AI 应用时，开发者不仅需要确保体验"有效"，还需要确保体验"合乎伦理"。本课程用一个虚构的教育科技创业公司作为贯穿案例：产品面向教师与学生两类核心用户，二者需求各不相同——教师需要自动批改作业、跟踪学情，学生需要个性化学习与复习工具。以用户为中心的设计（user-centered design）把用户放在第一位，确保产品对目标人群真正相关且有益。

为了让应用提供良好的用户体验，课程提出四大支柱：有用（Useful）、可靠（Reliable）、无障碍（Accessible）、愉悦（Pleasant）。

有用性（Usability）

有用意味着应用的功能与设计意图相匹配。例如：一个自动批改作业的应用，必须能依据预定义标准准确、高效地为学生作业评分；一个生成复习卡片的应用，必须能基于其数据产出相关且多样的问题。功能与目标错位，是"有用性"最大的失败。

可靠性（Reliability）

可靠意味着应用能稳定、无差错地执行任务。但课程明确提醒：AI 与人类一样并不完美，也可能出错。应用会遭遇意外情况，需要人工干预或纠正。如何优雅地处理错误？这正是本课第三节"协作与反馈"要解决的议题——可靠性不是"永不犯错"，而是"错误可被发现、可被纠正"。

无障碍（Accessibility）

无障碍意味着把用户体验扩展到各种能力水平的用户，包括残障人士，确保"不让任何人掉队"。遵循无障碍指南与原则（如键盘导航、屏幕阅读器支持、对比度与字号），AI 解决方案才能更包容、更普适。这也是课程练习中特别要求检查"应用能否同时用鼠标与键盘导航"的原因。

愉悦性（Pleasant）

愉悦意味着应用令人乐于使用。吸引人的体验会对用户产生积极影响，促使用户回头使用应用，进而带来业务收益。愉悦性不是花哨的视觉装饰，而是交互细节的整体质感。

以下图示（uxinai.png）直观总结了这四大 UX 支柱，它们像拼图一样共同构成完整的 AI 用户体验。

同时课程也给出一个重要提醒：并非所有挑战都能用 AI 解决。AI 的作用是增强用户体验——无论是自动化重复性手工任务，还是做个性化体验，都应服务于用户，而不是为了炫技而引入 AI。

为信任与透明设计 AI 应用

信任是 AI 应用设计的核心命题。信任让用户确信：应用能把事情做完、结果稳定可靠、输出恰好是用户需要的。然而信任存在两个方向的极端风险：

• 不信任（Mistrust）：用户对 AI 系统几乎不信任，直接拒绝使用你的应用；
• 过度信任（Overtrust）：用户高估 AI 系统的能力，对系统过分放心。

课程给出的过度信任示例很有警示性：如果教师过度信任自动批改系统，就可能不再抽查部分学生作业来验证评分质量，最终导致学生得到不公平或不准确的分数，也错失了反馈与改进的机会。要让信任真正处于设计中心，课程给出两条关键路径：可解释性（Explainability）与控制（Control）。

可解释性：让用户理解 AI 如何做决策

当 AI 参与影响重大的决策（例如向下一代传授知识）时，教师和家长必须理解 AI 的决策是如何做出的——这就是可解释性。为可解释性而设计，包含三个方面：

1. 标明 AI 身份：在文案中明确告知用户输出由 AI 生成而非真人。课程给出了一个非常具体的文案对比：与其说"立即开始与你的导师聊天"，不如说"使用能适应你需求、帮助你按自己节奏学习的 AI 导师"。下图（explanability-in-ai.png）展示了这两种文案在落地页上的差异。

2. 说明 AI 如何使用数据：可解释性也包含"AI 如何使用用户数据与个人数据"。例如，具有"学生"人设的用户可能受其角色限制——AI 不直接给出答案，而是引导用户思考如何自行解决问题。下图（solving-questions.png）对比了"直接给出 x²-4x+3=0 的答案"与"用求根公式 -b±√(b²-4ac)/2a 引导推导"两种回应方式。

3. 简化解释：学生和教师未必是 AI 专家，因此对"应用能做什么、不能做什么"的解释必须简化、易懂。下图（simplified-explanations.png）展示了把"我使用神经网络处理信息并生成回应"改写成"我是一个能回答问题、帮助你学习新东西的计算机程序，但我不是真人"的简化示范。

控制：把主动权交还给用户

生成式 AI 的本质是"AI 与用户的协作"：用户修改提示词以得到不同结果；而在输出生成后，用户也应该能够修改结果，从而获得掌控感。课程以 Bing（即后来的 Microsoft Copilot）为例说明两种控制手段：

• 可调制的提示词：用户可以根据格式（Format）、语气（Tone）与长度（Length）来调整自己的提示词，并在此基础上继续追问或修改草稿，如下图所示（bing1.png 与 bing2.png）。

• 数据收集的进出控制：用户可以主动选择加入（opt-in）或退出（opt-out）AI 所使用的数据。对学校应用而言，学生可能希望同时使用自己的笔记与教师的资源作为复习材料——这类"数据范围"的选择权应当交给用户。

课程在这里给出一个关键设计提示：设计 AI 应用时，"刻意性（intentionality）"至关重要——要确保用户不会过度信任、对能力产生不切实际的期待。一个具体做法是在提示词与结果之间制造"摩擦（friction）"：不断提醒用户"这是 AI，不是你的同类人类"。

为协作与反馈设计 AI 应用

生成式 AI 的多数交互模式是"用户输入提示词 → AI 生成输出"。但课程追问了一个被许多人忽略的问题：如果输出是错的怎么办？应用如何处理错误？AI 是把责任推给用户，还是花时间解释错误？

课程给出的答案是：AI 应用必须设计成既能接收反馈、也能给出反馈。这既帮助 AI 系统持续改进，也帮助建立用户信任。

内建反馈闭环（Feedback Loop）

最简单的反馈闭环示例，是在输出旁放置"👍 / 👎"按钮。这种轻量机制让用户以极低成本表达对结果的看法，为系统改进提供信号，也让用户感到"被倾听"。

清晰传达能力边界与容错文案

另一种做法是明确沟通系统的能力与限制。当用户提出超出 AI 能力范围的请求时，应用必须有一套应对机制。下图（feedback-loops.png）展示了"能力边界说明"与"点赞反馈"两种机制并存的界面设计。

课程给出了一个非常具体的容错回复模板。当用户询问超出训练数据范围的问题时，AI 可以这样回应：

"抱歉，我们的产品仅使用以下学科的数据进行训练……我无法回答你提出的问题。"

例如，一个只用历史与数学数据训练的教育 AI，无法处理地理类问题——此时正确的 UX 不是硬答或报错，而是坦诚说明边界。这类"范围外请求"和"系统级错误"（如摘要生成次数或学科数量的限制）都是常见场景，需要在设计阶段就准备好应对。

课程总结：AI 应用并不完美，必然犯错。设计应用时，必须为用户反馈与错误处理留出空间，并且处理方式要简单、易于理解。

将原则落到代码：从课程源码看 UX 设计的具体形态

第 12 课本身以设计方法论为主，但它所倡导的原则，在本仓库其他课程的示例代码中有着直观的落地形态。阅读这些代码，可以帮你把抽象原则转译成具体的工程实现。

用系统提示词落地"可解释性"与"能力边界"

本仓库第 6 课（文本生成应用）中的 aoai-history-bot.py 是一个角色扮演型历史问答机器人，它的系统提示词包含这样的约束：

persona = input("Tell me the historical character I want to be: ") question = input("Ask your question about the historical character: ") 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} """ response = client.responses.create(model=deployment, input=prompt, store=False) print(response.output_text)

注意其中两句："Don't create content yourself. If you don't know something, tell that you don't remember."（不要自行编造内容，如果不知道就明确说"不记得"）。这正是第 12 课"清晰传达能力边界"原则在提示工程层面的实现——用提示词约束模型，让模型在超出知识范围时诚实承认，而不是强行生成错误答案。这与课程中"承认训练数据范围"的容错模板异曲同工。

再看第 6 课的 aoai-study-buddy.py，它的系统提示词把输出格式固化为"概念 → 示例代码 → 解释"三段结构：

prompt = f""" You are an expert on the python language. Whenever certain questions are asked, you need to provide response in below format. - Concept - Example code showing the concept implementation - explanation of the example and how the concept is done for the user to understand better. Provide answer for the question: {question} """

固定输出结构本身就是一种 UX 设计：它让生成结果可预期、可理解，降低了用户解读输出的认知负担——这与课程强调的"简化解释"原则一脉相承。你可以把这类示例当作"原则 → 提示词"的翻译练习，进而设计出符合可解释性标准的系统提示词。

用输入校验落地"控制"与"容错"

本仓库的共享工具库 shared/python/input_validation.py 提供了面向 LLM 提示词的输入清洗函数sanitize_prompt_input，其核心能力包括：

• 去除空字节与控制字符；
• 清除模板注入（{{...}}）、变量替换（${...}）、<script>标签与javascript:协议等危险模式；
• 支持strict严格模式，只保留字母数字、空格与基础标点；
• 对长度与内容合法性做校验并抛出明确异常。

def sanitize_prompt_input(value: str, max_length: int = 1000, strict: bool = False) -> str: # 去除控制字符、注入模式后，再规范化空白并做长度校验 ...

配套测试 tests/test_input_validation.py 覆盖了模板注入、变量替换、脚本标签、JavaScript URL 等场景：

def test_removes_template_injection(self): result = sanitize_prompt_input("Hello {{system}} world") assert "{{" not in result assert "}}" not in result def test_removes_javascript_url(self): result = sanitize_prompt_input("click javascript:alert(1)") assert "javascript:" not in result.lower()

这类"在用户输入进入大模型之前先做清洗与校验"的做法，正是第 12 课"让用户获得控制权"原则在安全维度的体现：用户输入不再被无差别地透传给模型，而是经过一道可控的闸门——既保护了应用安全（防止提示注入），也保证传给模型的输入是干净、可预期的，从而间接提升输出的可靠性。同样地，validate_text_input对输入做最小/最大长度校验，本质上也是一种"预先管理用户期望、把错误拦截在源头"的容错设计。

课程练习：把 UX 原则应用到你已构建的 AI 应用

本课的作业（Assignment）不要求你新写代码，而是要求你回顾之前课程中构建过的任意 AI 应用，并落实以下四个维度的改进：

• 愉悦性（Pleasant）：思考如何让应用更令人愉悦。是否在每个环节都给出了解释？是否鼓励用户探索？错误提示文案是如何措辞的？
• 可用性（Usability）：如果是 Web 应用，确保既能用鼠标导航，也能用键盘导航（这是无障碍的基础要求之一）。
• 信任与透明（Trust & Transparency）：不要完全信任 AI 及其输出，考虑如何把"人"引入流程中验证输出；同时思考并落实其他达成信任与透明的手段。
• 控制（Control）：让用户对自己提供给应用的数据拥有控制权——为 AI 应用实现数据收集的"加入（opt-in）"与"退出（opt-out）"机制。

这四项练习正好与本课的四大支柱（有用/可靠/无障碍/愉悦）和两大设计路径（可解释性/控制）一一对应，是把本课知识转化为实际产品改进的落地清单。

小结

本课的核心结论可以浓缩为一条设计主线：AI 应用的价值不仅取决于模型能力，更取决于用户体验。一个值得被使用的 AI 应用，应当是有用的、可靠的、无障碍的、令人愉悦的；它通过可解释性（标明 AI 身份、说明数据使用、简化解释）与控制（可调提示词、可改结果、可进出数据收集）来建立信任；它通过反馈闭环（点赞机制）与清晰的容错文案（坦诚能力边界、说明训练数据范围）来承接错误、持续改进。

从本仓库的源码可以看出，这些原则并非停留在理论层：系统提示词里的"不知道就说不记得"是能力边界的产品化，固定输出结构是可预期性的实现手段，输入清洗与校验则是把控制权与安全性落到代码层面。下一课将进入"保护 AI 应用"的安全主题（见 13-securing-ai-applications/README.md），届时"用户的输入如何被安全地对待"会有更系统的答案——而本课的信任与透明原则，正是那片安全设计的土壤。

</｜DSML｜parameter> </｜DSML｜invoke> </｜DSML｜tool_calls>

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