微软生成式 AI 入门课第 12 课的应用 UX：哪些交互问题是必答题

12-designing-ux-for-ai-applications/ 这一课在 generative-ai-for-beginners 里是个异类：目录下只有 README.md 和 images/，没有 python/，没有 .ipynb，没有作业代码。翻到这里的人十有八九会扫两眼小标题就跳到第 13 课去。

但这一课提的问题其实全都要在代码里回答。下面用一个具体场景把它串起来：用户在你的学习助手里问了一个应用答不上来的问题，从他敲下回车到看见那句话，中间有几层是你能改的？ 沿着仓库里真实存在的文件走一遍，你会发现第 12 课列的原则每一条都有落点，只是落点不在这一课的目录里。

第 12 课自己划的范围

12-designing-ux-for-ai-applications/README.md 把可用性拆成四个词：useful、reliable、accessible、pleasant。这四个词后面各跟一小节，其中 reliability 那节直接把球踢给了后文——它写明 AI 和人一样并不完美，会遇到需要人来介入或纠正的情况，然后说错误处理放在本课最后一节讲。

接下来是信任那一节，这节给了两个对称的失败方向：mistrust（用户完全不信，于是不用你的产品）和 overtrust（用户高估了系统，于是不再核验）。课程举的 overtrust 例子是自动批改：老师因为太信任评分系统而不再抽查试卷。围绕信任，课程只给了两个抓手——explainability（可解释）与 control（控制权），加上最后一节的 feedback（反馈与错误处理）。整篇 README 的骨架就这三样。

可解释那节里有一条最容易被读者滑过去，因为它是一条纯文案建议：课程写明界面用词要让人知道输出来自 AI 而不是人，并给了一组逐字对照——不要写 “Start chatting with your tutor now”，改写成 “Use AI tutor that adapts to your needs and helps you learn at your pace.”（引自该课 README）。这条建议不需要任何工程改动，改的是一句标题文案，但它决定了用户带着什么预期进来。

persona 限制这条，代码在第 6 课

第 12 课举了另一个可解释性的例子：学生这个 persona 可能被限制，AI 不直接给答案，而是引导他自己想。这句话在第 12 课只有一句带过、后面跟一张示意图，但它对应的写法在 06-text-generation-apps/python/ 下是有实物的。

oai-history-bot.py 里的 prompt 原样是这样构造的：

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}
"""

注意最后那句 If you don't know something, tell that you don't remember.——第 12 课最后一节要求的”能力之外要有说法”，在这里是写在 prompt 里的一句话，不是界面上的一个组件。同目录的 oai-study-buddy.py 则把输出格式钉死成 Concept / Example code / explanation 三段。这两个文件都属于 OpenAI 直连那条路线（文件名 oai- 前缀），Azure OpenAI 版本是同目录的 aoai- 前缀那几个，配置项不同，别混着读。

把这两处放在一起看，能得到一个对界面设计有用的结论：课程里所谓”AI 的能力边界”，第一道实现其实是 prompt 里的一行英文，而不是前端的 try/catch。你在界面上写”本助手不回答与本课程无关的问题”，如果 prompt 里没有对应的约束，那句话只是装饰。

错误文案的另一半在 shared/python

用户输入进来之后、请求发出去之前还有一层，仓库把它抽在了 shared/python/ 下。shared/python/input_validation.py 里除了邮箱与 URL 的格式校验，跟用户输入直接相关的是 validate_number_input、validate_text_input、sanitize_prompt_input 这三个——shared/python/__init__.py 也正是把这三个从该模块导入，并和 env_utils 的 get_required_env、api_utils 的 create_openai_client 一起写进 __all__。

这几个函数值得单独看的地方是它们抛出的错误消息本身就是写给用户看的。validate_text_input 超长时抛的是这一句：

raise ValueError(
    f"{field_name} is too long. Maximum {max_length} characters allowed, "
    f"got {len(trimmed)}"
)

field_name 是这个函数的一个参数（默认 "input"，这是仓库当前代码里的默认值，随版本可能变动），存在的意义就是让错误里能指名道姓说哪个字段错了；后半句把上限和实际值一起报出来，用户不用猜。validate_number_input 同理，越界时报的是 must be between {min_val} and {max_val}, got {num} 这种形式。这就是第 12 课说的”错误消息怎么措辞”落到代码里的样子——不是加一个红色感叹号图标，是让异常自己带上可执行的信息。

sanitize_prompt_input 是另一种情况，它不报错，它删。函数内部用 re.sub 依次清掉控制字符，以及 dangerous_patterns 列表里的模板注入、变量替换、<script> 标签、javascript: 这几类模式；strict=True 时再进一步只保留一小撮安全字符。这里出现了一个值得停下来看的关系：这个函数把用户输入的一部分静默移除后返回，而第 12 课要求应用把限制和错误清楚告诉用户。两处都是仓库白纸黑字，但中间没人接——如果你在界面上直接用这个函数的返回值去调模型，用户会看到一个和自己输入不一样的结果，却拿不到任何解释。要不要在 UI 上提示”你的输入中有部分内容已被过滤”，仓库里没有给出对应实现，这一层得你自己补。

对应的行为约束在 tests/test_input_validation.py 里能看到，比如 test_removes_template_injection、test_removes_script_tags 断言的是处理后字符串里不再包含那些片段。要确认某个版本的实际行为，读这个测试文件比读文档快。

上面这几处涉及输入过滤与密钥，安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。

“给用户一个温度滑块”这条老做法要重写

第 12 课的 control 那节举的例子是让用户调整格式、语气、长度，很多人下意识就会把它翻译成”界面上放采样参数”。这里有个必须交代的变化。

06-text-generation-apps/README.md 写明：当前 Microsoft Foundry 上未废弃的模型是 reasoning 模型（GPT-5 家族、o 系列），它们不支持 temperature 和 top_p，也不支持 max_tokens（改用 max_output_tokens），给 gpt-5-mini 传 temperature 会拿到 “parameter not supported” 错误。该 README 同时说明，temperature / top_p 在 Llama、Mistral、Phi 以及 GPT-4.x 家族上仍然有效（并注明 GPT-4.x 正在弃用中），课程里要试温度示例的话，建议改指一个仍支持采样控制的开放模型。

所以”把控制权交给用户”这件事，在这类模型上得换个交付方式：能给的是 prompt 层的选项（语气、篇幅、格式的措辞模板）和 reasoning 相关的控制，不是一个 0 到 1 的滑块。界面上留着一个传下去就报错的控件，是比没有控件更糟的体验。

顺带说清 provider 路线，因为第 12 课的示例读起来是产品截图，但你自己动手时绕不开这层。00-course-setup/03-providers.md 讨论的 provider 不止三家（还写了 Hugging Face，以及完全离线的 Foundry Local / Ollama），但落到作业文件名上的标记只有三种：oai（OpenAI 直连）、aoai（Azure OpenAI）、githubmodels。该文件对第三种标记的说明逐字写的是「requires Microsoft Foundry Models endpoint, key」，也就是 Microsoft Foundry Models（原 GitHub Models 路线）。第三条要格外注意——仓库里那些 githubmodels- 前缀的文件名已经和实际接入目标脱节了：00-course-setup/03-providers.md 与 06-text-generation-apps/python/githubmodels-app.py 的注释都写明 GitHub Models 已于 2026 年 7 月底退役、由 Microsoft Foundry Models 接替，而今天这个时间点已经过去。该文件里实际读取的环境变量是 AZURE_INFERENCE_CREDENTIAL 和 AZURE_INFERENCE_ENDPOINT，不是 GITHUB_TOKEN。看到文件名别顺手去配旧变量。

第 7 课把原则改写成了自查问句

如果你觉得第 12 课偏抽象，07-building-chat-applications/README.md 的 “User Experience (UX)” 小节是它的工程版续集，那里列的三条更像是排期清单：给用户一个要求澄清的机制（应对模型给出含糊回答）、上下文保留（并写明要考虑保留多久、是否引入 retention policy 来平衡上下文与隐私）、个性化（用户画像）。

同一篇 README 后面还有一张负责任 AI 六原则表，每行第三列是 “Considerations for Chat Developer”，比如 Transparency 那行给的是为 AI 回答提供清晰的文档与理由，Inclusiveness 那行给的是设计对多样人群可用的 UI/UX。第 12 课讲的是”为什么”，这张表给的是”那我这周该做什么”。

回到第 12 课自己的 Assignment，它把整课收成四个动作：措辞（错误消息怎么写、有没有到处加解释）、可用性（web 应用要能用鼠标也能用键盘走完）、信任与透明（引入人来核验输出）、控制权（让用户能选择加入或退出数据收集）。这四条不需要任何 SDK，是你今天就能在自己项目上勾一遍的清单。第二条尤其常被漏掉——键盘可达性和模型没有半点关系，但它在这一课里和信任被并列写在了一起。

以上代码片段均原样取自仓库文件，未经实测，以仓库最新代码为准。该课程持续更新，文中涉及的文件路径与接口写法可能变动。

---

本文依据 github.com/microsoft/generative-ai-for-beginners 仓库于 2026-08-18 的公开内容整理， 事实来自仓库内的课程正文与代码示例。我们没有跑过文中涉及的代码， 因此不涉及运行结果、耗时与生成质量的任何描述。 该课程持续更新，文中涉及的文件路径、依赖与接口写法随版本变动，请以仓库最新内容为准。 文中涉及的云端服务调用会产生费用并可能上传数据，请自行评估密钥与数据边界。