尧图网页设计 
generative-ai-for-beginners 第 12 课实战AI 应用的 UX 设计——从信任、透明到反馈闭环的完整工程方法【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners本课围绕「AI 应用的 UX 设计」展开是微软开源课程 generative-ai-for-beginners21 课生成式 AI 入门系列中的第 12 课。原文英文版、日文版聚焦一个核心命题如何构建用户既愿意使用、又敢于信任的生成式 AI 应用。读完本课你将掌握 AI 产品 UX 的四大支柱有用性、可靠性、可访问性、愉悦性学会通过**可解释性Explainability与用户控制Control建立信任并能在应用中设计反馈闭环Feedback Loop**与优雅的错误处理文中还会结合本仓库的真实代码输入校验、API 客户端封装、学习助手与菜谱生成示例给出可落地的实现思路。一、为什么 AI 应用的 UX 设计如此关键用户体验User ExperienceUX指用户如何与某个具体产品、服务交互并加以使用——无论它是系统、工具还是设计。用户在意的不仅是「功能能不能用」还有「好不好用、敢不敢用、愿不愿再用」。对 AI 应用而言开发者需要同时保证体验的有效性effective与伦理性ethicalAI 的产出由模型生成天然带有不确定性若 UI 设计不能管理好用户的预期一次错误的输出就可能摧毁长期建立的信任。本课以一家虚构的教育类创业公司为背景界定了两类核心用户——教师与学生并强调以用户为中心的设计user-centered design必须优先考虑用户确保产品对目标人群是相关且有益的。学习目标完成本课后你将能够理解如何构建满足用户需求的 AI 应用设计能够促进信任与协作的 AI 应用。二、UX 的四大支柱有用性、可靠性、可访问性、愉悦性一个能提供良好体验的 AI 应用需要同时具备四项特质有用Useful、可靠Reliable、可访问Accessible、愉悦Pleasant。2.1 有用性Usability「有用」意味着应用的功能与其预期目的匹配。例如一个自动批改作业的应用应能基于预定义标准对学生的作业进行准确、高效的评分一个生成复习闪卡的应用则应能基于其数据生成相关且多样的题目。仓库落地参考本仓库第 6 课就给出了一个「学习伙伴」示例 aoai-study-buddy.py它接收用户对 Python 语言的问题并通过提示词prompt约束输出固定结构——「概念Concept/ 示例代码Example code/ 讲解Explanation」三段式。这正是「功能匹配预期目的」的典型体现不是泛泛聊天而是围绕学习场景产出结构化答案。2.2 可靠性Reliability「可靠」意味着应用能够持续、无差错地执行任务。但 AI 和人一样不完美可能出错应用可能遇到需要人工介入或修正的错误与意外情况。关键在于如何处理错误——本课最后一节协作与反馈会专门展开。2.3 可访问性Accessibility「可访问」意味着把用户体验扩展到不同能力的用户包括残障人士确保没有人被排除在外。遵循无障碍指南与原则AI 解决方案才能更具包容性、更易用惠及所有用户。实操提示本课作业中特别强调——构建 Web 应用时要确保应用既能用鼠标也能用键盘完成全部导航与操作这是可访问性最基础的验收标准之一。2.4 愉悦性Pleasant「愉悦」意味着应用令人乐于使用。有吸引力的体验会对用户产生正向影响促使用户再次回到应用进而提升业务收益。愉悦感体现在细节是否在关键位置补充说明是否鼓励用户探索错误提示的措辞是否得体需要清醒认识到并非所有问题都能用 AI 解决。AI 的角色是增强augment用户体验——例如自动化手工任务、个性化用户体验——而不是包办一切。三、为信任与透明而设计可解释性与控制构建 AI 应用时建立信任至关重要。信任使用户确信应用能完成任务、结果稳定一致、产出符合需求。这个领域的两大风险是不信任mistrust与过度信任overtrust不信任用户对 AI 系统几乎或完全不信任导致直接拒绝使用应用过度信任用户高估 AI 系统的能力从而过度依赖。例如在自动批改系统中过度信任可能让教师跳过抽查部分试卷直接采信评分结果最终导致学生得到不公或不准确的成绩也错失反馈与改进的机会。把信任置于设计中心的两种手段可解释性与控制。3.1 可解释性Explainability当 AI 参与影响深远的决策例如向下一代传授知识时教师和家长必须理解 AI 是如何做决策的——这就是可解释性。可解释性设计包含明确标注 AI 身份让使用者清楚「输出来自 AI 而非人类」。例如与其说「现在开始与您的导师聊天吧」不如说「使用能适配您需求、按您节奏助您学习的 AI 导师」。下图展示了一个在落地页上清晰说明 AI 身份与能力的应用设计数据使用的透明例如带有「学生」人格persona的用户会受到相应限制——AI 可能不会直接给出题目答案但会引导用户思考如何自己解决问题简化解释学生与教师未必是 AI 专家因此关于「应用能做什么、不能做什么」的说明应当简洁、易懂3.2 控制Control生成式 AI 在 AI 与用户之间创造了协作关系用户可以通过修改提示词获得不同结果输出生成后用户还应能修改结果从而获得掌控感。以微软 Copilot前身为 Bing Chat为例用户可以根据格式、语气、长度定制提示词还可以在输出上进行修改与调整另一个控制手段是数据选择权允许用户对 AI 所使用的数据进行选择加入opt-in或选择退出opt-out。对校园应用而言学生可能希望将自己的笔记与教师资源一并作为复习资料设计要点设计 AI 应用时意图性intentionality是关键——要防止用户过度信任并对能力产生不切实际的预期。一种做法是在「提示词」与「结果」之间制造摩擦friction不断提醒用户这是 AI而不是一位人类同伴。四、为协作与反馈而设计反馈闭环与优雅的错误处理如前所述生成式 AI 创造了用户与 AI 之间的协作。大多数交互是「用户输入提示词 → AI 生成输出」。但如果输出错了怎么办应用如何处理错误是责备用户还是花时间解释错误AI 应用应当被设计为既能接收反馈、也能给出反馈这不仅能帮助 AI 系统改进还能与用户建立信任。设计应包含反馈闭环feedback loop——最简单的形式就是在输出上提供「赞 / 踩」thumbs up / down评价此外还要清晰传达系统的能力与边界。当用户请求超出 AI 能力范围时应用需要得体的处理方式。系统错误很常见例如用户需要 AI 知识范围之外的信息或应用对可生成的题目/科目数量设有限制。典型示例仅用历史与数学数据训练的 AI 应用可能无法处理地理问题。此时系统应给出类似回应「抱歉我们的产品仅基于以下科目训练……我无法回答您提出的问题。」——既不沉默、也不硬编而是透明地说明边界。AI 应用并不完美必然会犯错。因此设计应用时必须为「接收用户反馈」和「简单、可解释的错误处理」留出空间。五、从设计到代码本仓库中的落地佐证本课讲的是设计理念而本仓库恰好提供了大量可以验证这些理念的工程代码。以下是几处可直接对照的实现5.1 用输入校验落实「可靠性」与「信任边界」AI 应用在把用户输入送入大模型前必须先做校验与清洗。共享模块 shared/python/input_validation.py 提供了三层防护正是「可靠性」的代码化体现validate_number_input(value, min_val, max_val, field_name)将字符串转为整数并校验上下界默认 1–100防止越界参数导致异常validate_text_input(value, max_length, min_length, ...)校验文本长度与空值并做 trimsanitize_prompt_input(value, max_length, strict)面向 LLM 提示词的安全清洗——移除空字节与控制字符、剥离模板注入{{...}}、变量替换${...}、script标签与javascript:URLstrictTrue时仅保留字母数字与基础标点最终把连续空白归一化。这正是防止**提示注入prompt injection**的基础防线。这些行为都有对应的测试用例 tests/test_input_validation.py 逐一验证例如test_removes_template_injection断言{{system}}被剥离、test_removes_javascript_url断言javascript:被清除。设计上「告诉用户能做什么」之前先要在代码层「拒绝不该出现的输入」——这是信任与透明原则在工程侧的起点。5.2 用客户端封装落实「可访问性」与「开箱即用」共享模块 shared/python/api_utils.py 将 OpenAI / Azure OpenAI 客户端初始化收敛为两个函数create_openai_client(api_key)从OPENAI_API_KEY环境变量读取密钥缺省时抛出带安装指引的ImportError/ValueErrorcreate_azure_openai_client(endpoint, api_key)自动把 endpoint 拼成endpoint/openai/v1/的 Responses API 地址无需手写api_versionmake_safe_request(url, method, timeout, retries)为 HTTP 请求统一设置超时默认 30s与重试默认 3 次。这套封装让开发者可以几行代码接入模型见 tests/test_api_utils.py 的配套测试降低了上手门槛——正是「可访问性」在开发者体验DX层面的体现。5.3 用「输出可再加工」落实「控制感」「用户控制」不仅在 UI 层也体现在提示词工程中。第 6 课菜谱示例 oai-app-recipe.py 展示了经典的两段式协作先用较低温度temperature0.1生成菜谱再把菜谱结果作为上下文拼接进第二个提示词要求模型生成「不包含家中已有食材」的购物清单temperature0。用户输入的食材与过滤条件素食/纯素/无麸质被直接插值进提示词用户因此能持续调整输入来改变输出——这正是「协作 控制」的最小可行实现。同课的 JavaScript 版本 app.js 也采用相同的提示词拼接模式temperature: 1.0可对照阅读。5.4 用「人格化提示词」落实「可解释性」回到 3.1 的可解释性学习伙伴示例 aoai-study-buddy.py 在系统提示词中声明「你是 Python 语言专家」并强制输出「概念 → 示例代码 → 讲解」结构。从源码结构看这类显式声明角色与输出格式的做法本身就是让用户理解「模型以何种身份、按何种逻辑作答」的设计手段——应用通过提示词把决策过程透明化用户更容易判断结果是否可信。六、实践作业把四条检查清单落到你的应用取一个你已经构建的 AI 应用尝试逐项实现以下改进维度检查与行动项愉悦性Pleasant是否处处补充了说明是否鼓励用户探索错误提示的措辞是否得当有用性Usability若是 Web 应用确保鼠标与键盘均可完成全部导航与操作可访问性基础验收。信任与透明Trust Transparency不要完全信任 AI 及其输出——考虑在流程中引入「人」来核验输出同时思考并落实其他提升信任与透明的方式。控制Control让用户控制提供给应用的数据——实现 AI 应用中的数据采集 opt-in / opt-out 机制。上述清单可直接与本课的三大板块一一对应愉悦性与有用性对应「UX 四大支柱」信任与透明对应「可解释性 控制」控制项的 opt-in / opt-out 则是「协作与反馈」中用户掌控感的落地形式。七、继续学习本课为 AI 应用的 UX 设计打下基础。下一课第 13 课将围绕 AI 应用的安全展开主题是「保护生成式 AI 应用」——安全防线如数据完整性、防数据投毒、对抗性输入防护正是 UX 信任承诺的底层保障在 SECURITY_GUIDELINES.md 中还可以看到本项目对安全边界的进一步约定。建议结合本仓库第 6 课文本生成应用的完整示例继续实践把本课的 UX 原则落到真实可运行的应用代码中。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 generative-ai-for-beginners 第 12 课实战：AI 应用的 UX 设计——从信任、透明到反馈闭环的完整工程方法
generative-ai-for-beginners 第 12 课实战AI 应用的 UX 设计——从信任、透明到反馈闭环的完整工程方法【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners本课围绕「AI 应用的 UX 设计」展开是微软开源课程 generative-ai-for-beginners21 课生成式 AI 入门系列中的第 12 课。原文英文版、日文版聚焦一个核心命题如何构建用户既愿意使用、又敢于信任的生成式 AI 应用。读完本课你将掌握 AI 产品 UX 的四大支柱有用性、可靠性、可访问性、愉悦性学会通过**可解释性Explainability与用户控制Control建立信任并能在应用中设计反馈闭环Feedback Loop**与优雅的错误处理文中还会结合本仓库的真实代码输入校验、API 客户端封装、学习助手与菜谱生成示例给出可落地的实现思路。一、为什么 AI 应用的 UX 设计如此关键用户体验User ExperienceUX指用户如何与某个具体产品、服务交互并加以使用——无论它是系统、工具还是设计。用户在意的不仅是「功能能不能用」还有「好不好用、敢不敢用、愿不愿再用」。对 AI 应用而言开发者需要同时保证体验的有效性effective与伦理性ethicalAI 的产出由模型生成天然带有不确定性若 UI 设计不能管理好用户的预期一次错误的输出就可能摧毁长期建立的信任。本课以一家虚构的教育类创业公司为背景界定了两类核心用户——教师与学生并强调以用户为中心的设计user-centered design必须优先考虑用户确保产品对目标人群是相关且有益的。学习目标完成本课后你将能够理解如何构建满足用户需求的 AI 应用设计能够促进信任与协作的 AI 应用。二、UX 的四大支柱有用性、可靠性、可访问性、愉悦性一个能提供良好体验的 AI 应用需要同时具备四项特质有用Useful、可靠Reliable、可访问Accessible、愉悦Pleasant。2.1 有用性Usability「有用」意味着应用的功能与其预期目的匹配。例如一个自动批改作业的应用应能基于预定义标准对学生的作业进行准确、高效的评分一个生成复习闪卡的应用则应能基于其数据生成相关且多样的题目。仓库落地参考本仓库第 6 课就给出了一个「学习伙伴」示例 aoai-study-buddy.py它接收用户对 Python 语言的问题并通过提示词prompt约束输出固定结构——「概念Concept/ 示例代码Example code/ 讲解Explanation」三段式。这正是「功能匹配预期目的」的典型体现不是泛泛聊天而是围绕学习场景产出结构化答案。2.2 可靠性Reliability「可靠」意味着应用能够持续、无差错地执行任务。但 AI 和人一样不完美可能出错应用可能遇到需要人工介入或修正的错误与意外情况。关键在于如何处理错误——本课最后一节协作与反馈会专门展开。2.3 可访问性Accessibility「可访问」意味着把用户体验扩展到不同能力的用户包括残障人士确保没有人被排除在外。遵循无障碍指南与原则AI 解决方案才能更具包容性、更易用惠及所有用户。实操提示本课作业中特别强调——构建 Web 应用时要确保应用既能用鼠标也能用键盘完成全部导航与操作这是可访问性最基础的验收标准之一。2.4 愉悦性Pleasant「愉悦」意味着应用令人乐于使用。有吸引力的体验会对用户产生正向影响促使用户再次回到应用进而提升业务收益。愉悦感体现在细节是否在关键位置补充说明是否鼓励用户探索错误提示的措辞是否得体需要清醒认识到并非所有问题都能用 AI 解决。AI 的角色是增强augment用户体验——例如自动化手工任务、个性化用户体验——而不是包办一切。三、为信任与透明而设计可解释性与控制构建 AI 应用时建立信任至关重要。信任使用户确信应用能完成任务、结果稳定一致、产出符合需求。这个领域的两大风险是不信任mistrust与过度信任overtrust不信任用户对 AI 系统几乎或完全不信任导致直接拒绝使用应用过度信任用户高估 AI 系统的能力从而过度依赖。例如在自动批改系统中过度信任可能让教师跳过抽查部分试卷直接采信评分结果最终导致学生得到不公或不准确的成绩也错失反馈与改进的机会。把信任置于设计中心的两种手段可解释性与控制。3.1 可解释性Explainability当 AI 参与影响深远的决策例如向下一代传授知识时教师和家长必须理解 AI 是如何做决策的——这就是可解释性。可解释性设计包含明确标注 AI 身份让使用者清楚「输出来自 AI 而非人类」。例如与其说「现在开始与您的导师聊天吧」不如说「使用能适配您需求、按您节奏助您学习的 AI 导师」。下图展示了一个在落地页上清晰说明 AI 身份与能力的应用设计数据使用的透明例如带有「学生」人格persona的用户会受到相应限制——AI 可能不会直接给出题目答案但会引导用户思考如何自己解决问题简化解释学生与教师未必是 AI 专家因此关于「应用能做什么、不能做什么」的说明应当简洁、易懂3.2 控制Control生成式 AI 在 AI 与用户之间创造了协作关系用户可以通过修改提示词获得不同结果输出生成后用户还应能修改结果从而获得掌控感。以微软 Copilot前身为 Bing Chat为例用户可以根据格式、语气、长度定制提示词还可以在输出上进行修改与调整另一个控制手段是数据选择权允许用户对 AI 所使用的数据进行选择加入opt-in或选择退出opt-out。对校园应用而言学生可能希望将自己的笔记与教师资源一并作为复习资料设计要点设计 AI 应用时意图性intentionality是关键——要防止用户过度信任并对能力产生不切实际的预期。一种做法是在「提示词」与「结果」之间制造摩擦friction不断提醒用户这是 AI而不是一位人类同伴。四、为协作与反馈而设计反馈闭环与优雅的错误处理如前所述生成式 AI 创造了用户与 AI 之间的协作。大多数交互是「用户输入提示词 → AI 生成输出」。但如果输出错了怎么办应用如何处理错误是责备用户还是花时间解释错误AI 应用应当被设计为既能接收反馈、也能给出反馈这不仅能帮助 AI 系统改进还能与用户建立信任。设计应包含反馈闭环feedback loop——最简单的形式就是在输出上提供「赞 / 踩」thumbs up / down评价此外还要清晰传达系统的能力与边界。当用户请求超出 AI 能力范围时应用需要得体的处理方式。系统错误很常见例如用户需要 AI 知识范围之外的信息或应用对可生成的题目/科目数量设有限制。典型示例仅用历史与数学数据训练的 AI 应用可能无法处理地理问题。此时系统应给出类似回应「抱歉我们的产品仅基于以下科目训练……我无法回答您提出的问题。」——既不沉默、也不硬编而是透明地说明边界。AI 应用并不完美必然会犯错。因此设计应用时必须为「接收用户反馈」和「简单、可解释的错误处理」留出空间。五、从设计到代码本仓库中的落地佐证本课讲的是设计理念而本仓库恰好提供了大量可以验证这些理念的工程代码。以下是几处可直接对照的实现5.1 用输入校验落实「可靠性」与「信任边界」AI 应用在把用户输入送入大模型前必须先做校验与清洗。共享模块 shared/python/input_validation.py 提供了三层防护正是「可靠性」的代码化体现validate_number_input(value, min_val, max_val, field_name)将字符串转为整数并校验上下界默认 1–100防止越界参数导致异常validate_text_input(value, max_length, min_length, ...)校验文本长度与空值并做 trimsanitize_prompt_input(value, max_length, strict)面向 LLM 提示词的安全清洗——移除空字节与控制字符、剥离模板注入{{...}}、变量替换${...}、script标签与javascript:URLstrictTrue时仅保留字母数字与基础标点最终把连续空白归一化。这正是防止**提示注入prompt injection**的基础防线。这些行为都有对应的测试用例 tests/test_input_validation.py 逐一验证例如test_removes_template_injection断言{{system}}被剥离、test_removes_javascript_url断言javascript:被清除。设计上「告诉用户能做什么」之前先要在代码层「拒绝不该出现的输入」——这是信任与透明原则在工程侧的起点。5.2 用客户端封装落实「可访问性」与「开箱即用」共享模块 shared/python/api_utils.py 将 OpenAI / Azure OpenAI 客户端初始化收敛为两个函数create_openai_client(api_key)从OPENAI_API_KEY环境变量读取密钥缺省时抛出带安装指引的ImportError/ValueErrorcreate_azure_openai_client(endpoint, api_key)自动把 endpoint 拼成endpoint/openai/v1/的 Responses API 地址无需手写api_versionmake_safe_request(url, method, timeout, retries)为 HTTP 请求统一设置超时默认 30s与重试默认 3 次。这套封装让开发者可以几行代码接入模型见 tests/test_api_utils.py 的配套测试降低了上手门槛——正是「可访问性」在开发者体验DX层面的体现。5.3 用「输出可再加工」落实「控制感」「用户控制」不仅在 UI 层也体现在提示词工程中。第 6 课菜谱示例 oai-app-recipe.py 展示了经典的两段式协作先用较低温度temperature0.1生成菜谱再把菜谱结果作为上下文拼接进第二个提示词要求模型生成「不包含家中已有食材」的购物清单temperature0。用户输入的食材与过滤条件素食/纯素/无麸质被直接插值进提示词用户因此能持续调整输入来改变输出——这正是「协作 控制」的最小可行实现。同课的 JavaScript 版本 app.js 也采用相同的提示词拼接模式temperature: 1.0可对照阅读。5.4 用「人格化提示词」落实「可解释性」回到 3.1 的可解释性学习伙伴示例 aoai-study-buddy.py 在系统提示词中声明「你是 Python 语言专家」并强制输出「概念 → 示例代码 → 讲解」结构。从源码结构看这类显式声明角色与输出格式的做法本身就是让用户理解「模型以何种身份、按何种逻辑作答」的设计手段——应用通过提示词把决策过程透明化用户更容易判断结果是否可信。六、实践作业把四条检查清单落到你的应用取一个你已经构建的 AI 应用尝试逐项实现以下改进维度检查与行动项愉悦性Pleasant是否处处补充了说明是否鼓励用户探索错误提示的措辞是否得当有用性Usability若是 Web 应用确保鼠标与键盘均可完成全部导航与操作可访问性基础验收。信任与透明Trust Transparency不要完全信任 AI 及其输出——考虑在流程中引入「人」来核验输出同时思考并落实其他提升信任与透明的方式。控制Control让用户控制提供给应用的数据——实现 AI 应用中的数据采集 opt-in / opt-out 机制。上述清单可直接与本课的三大板块一一对应愉悦性与有用性对应「UX 四大支柱」信任与透明对应「可解释性 控制」控制项的 opt-in / opt-out 则是「协作与反馈」中用户掌控感的落地形式。七、继续学习本课为 AI 应用的 UX 设计打下基础。下一课第 13 课将围绕 AI 应用的安全展开主题是「保护生成式 AI 应用」——安全防线如数据完整性、防数据投毒、对抗性输入防护正是 UX 信任承诺的底层保障在 SECURITY_GUIDELINES.md 中还可以看到本项目对安全边界的进一步约定。建议结合本仓库第 6 课文本生成应用的完整示例继续实践把本课的 UX 原则落到真实可运行的应用代码中。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考