Lec 6 人机 AI 交互基础

AI 能力进步不等于 AI 产品成功；关键在于人是否形成正确心智模型、能否校验输出并保有控制权。

学习目标

• 理解人-AI 交互的基础
• 后续 3 个 Lec 会集成 AI-powered 特性到你项目中（chat、agents 等）
• 后续使用 AI 写代码

TL;DR

• AI 能力进步不等于产品成功；设计者必须让用户理解系统能做什么、依据什么行动，以及出错后如何纠正或退出。
• 生成式 AI 更适合允许多个可接受答案的“钝边”任务；面对高风险的“锐边”任务，应把生成与执行分开，并保留核验、确认和撤销机制。
• 人机协作的主要风险常出现在交接缝：输出类型、未完成项、不确定性和下一步必须在界面中显式呈现。
• Prompt 原型可在完整开发前验证核心能力，但真正的产品价值来自增强人的判断，而不是仅以自动化替代人。

AI 产品：技术进步 ≠ 产品成功

AI 能力快速进步，也催生了大量 AI 产品和服务，但真正成功、长期创造用户价值的产品增长远慢于前两者。

What separates the successes from the failures? 是什么区分了成功与失败的 AI 产品？

也就是说，拥有先进 AI 技术本身并不足以形成成功产品。接下来关注的重点会从“AI 能做到什么”转向“如何把 AI 能力设计成真正有效的产品”。

什么是人工智能

这里课程先统一两个基础概念：

• 人工智能（Artificial Intelligence，AI）：让机器自动完成那些我们通常认为需要人类认知能力才能完成的任务，例如识别图像、理解语言、在复杂环境中规划行动。
• 深度学习（Deep Learning）：过去十多年推动 AI 能力大幅进步的一类模型。所谓 “deep”，主要指神经网络具有许多层。

在过去的 10 年里， Deep Learning 快速进步 → AI 能力快速进步。

深度学习基本训练过程可以简化为：

1. 收集海量数据
2. 训练模型预测序列中下一个最可能出现的 Token。

通过不断进行这种预测，模型逐渐学习到语言的结构，同时也从文本中获得大量关于世界的统计性知识。但只会预测下一个 Token，并不等于会按照用户要求回答问题。所以需要第 3 步

3. 训练模型遵从指令

因此还需要进一步训练模型遵循指令，让模型从单纯的“续写文本”变成能够根据 Prompt 完成任务的系统。

经过预训练和指令训练后，大语言模型（large language models，LLMs）可以作为通用能力直接使用。

LLM 经过预训练 + 指令训练后，已经成为一个通用模型。你不一定需要针对每个任务重新训练模型，只需要给它 Prompt，就可以直接让它完成很多不同任务。

微调

如果希望进一步塑造模型，使它更适合某个特定任务，则可以使用微调 （Fine-tuning）：提供大量特定任务的输入，以及每个输入对应的期望输出，让模型进一步学习应该怎样回应。

两者可以这样区分：

Prompt
→ 告诉已有模型“这一次要怎么做”

Fine-tuning
→ 进一步塑造模型“通常应该怎么做”

因此，产品并不一定一开始就需要 Fine-tuning。如果通用模型配合 Prompt 已经能够完成任务，就可以直接利用现有能力。

传统的 GPT-4 一类模型，在生成答案时，本质上是按照前面的逻辑，不断预测下一个最有可能出现的 token；但是最近的模型会先花时间来产生一个规划、推理和自我检查，再进行输出。 这比之前思考地更加深刻。

你需要作出的决策

• 使用付费 API，还是自己托管模型？
  • API（例如 OpenAI）：使用简单，但你发送的请求需要传给外部服务提供商。
  • 自托管：需要昂贵的服务器和运维成本，但数据可以完全保留在内部。
• 直接使用模型，还是进行微调？
  • 开箱即用：通过 Prompt 来完成所需的定制。
  • 微调：当仅靠 Prompt 无法让模型在特定任务上达到足够好的表现时，可以进一步训练模型。
• 如何整合组织内部的私有数据？
  • 也就是：如何让 AI 能利用公司自己的文档、数据库、知识库等内部信息，同时考虑数据隐私和访问控制。

AI 现在无法做什么？

课件把现代生成式 AI 概括为三个层次：先在海量数据上学习预测下一个 token（词或子词），再训练它遵循指令；产品则把 输入与 prompt → 预训练模型 → 响应 包装成用户能用的功能。这个过程解释了两件事：

• 输出连贯不等于它经过了事实检索或逻辑证明；模型是逐 token 生成，不能默认拥有长期规划。
• 较新的推理模型可在输出前花更多计算进行计划和自我检查，但这会改变成本、延迟和交互体验，不能免除验证。

模型能力也不是唯一选择：可以直接使用 API 并通过 prompt 定制；若 prompt 不足以稳定完成明确任务，才考虑用大量带标签样本微调（fine-tuning）。还要决定私有组织数据如何提供给模型，以及是否能接受 API 提供商看到请求；自行托管可加强数据控制，却需要昂贵的计算基础设施。

对用户而言，交互应该回答四个问题：系统能做什么？现在正在做什么？依据是什么？出错后我如何纠正或退出？这比解释模型内部细节更重要。

常见风险与设计回应

风险	用户体验后果	设计回应
幻觉/不确定性	自信的错误被当成事实	引用来源、显示置信/未知、提供核验入口
心智模型不匹配	用户把建议误作决定或承诺	明确 AI 的角色、权限与限制
自动化偏差	用户停止审查关键决定	保留人工确认，突出高风险字段
不可逆行动	错误被放大	预览、撤销、审批与审计记录

与概念设计的连接

将 AI 视为一个能力受限的参与者，而非“魔法函数”。先定义用户目标、输入/输出、允许的行动与失败时的降级路径，再决定是否调用模型。AI 产生建议的概念，应与“执行真实世界动作”的概念分离；二者之间以显式确认或 sync 连接。

锐边问题与钝边问题

课件区分两类任务：**锐边（sharp-edged）**任务只有完全正确才有价值，错误会造成严重后果；**钝边（rough-edged）**任务有许多可接受答案，即使 80% 完成度也仍能帮助用户。

类型	例子	为什么 AI 风险不同
钝边	写作、绘图、游戏、代码草稿	用户可以编辑、筛选或把结果当灵感；部分正确仍有价值。
锐边	高影响预测/决策、一次性完整交付、强自主的工具操作	容错率很低；80% 正确仍可能是不可接受的错误。

这里不是说 AI 天生只能做钝边问题，而是人对错误的容忍度不同。能力会进步：今天边缘的钝边成功将来可能成为可靠的锐边成功；但在当前，应先把锐边任务改造成钝边的人机协作。

例：与其让“再入院风险预测”替代临床决定，不如让它先整理风险因素报告，由临床人员判断；与其让 AI 一次性生成整个应用，不如让它生成局部草稿并由工程师完成。

把锐边任务改造成钝边任务

常用的改造方式是把“替人下结论/执行”改为“为人补足信息或候选方案”：生成摘要、指出风险、列出备选、起草内容、标出需复核处。这样错误变成可发现、可编辑的输入，而不是直接造成不可逆结果。

人和 AI 的失败经常发生在交接缝（seam）而非任一方单独工作时：AI 不知道人会如何接手，人也误以为 AI 已处理了例外。因此界面要交代交接物、未完成项、置信与下一步。一个很实用的警句是：不要让 UI 开出 AI 无法兑现的支票——承诺“自动完成”前，先设计失败、歧义和人工接管。

交接缝的设计问题

为每一个“AI 做完后交给人”的节点明确回答：

1. 人接到的具体产物是什么：答案、草稿、风险提示、候选列表，还是已经执行的结果？
2. 哪些部分是模型推测、缺少资料或尚未验证的？
3. 人可以编辑、拒绝、要求重做、撤销或升级给谁？
4. 如果模型没有结果、结果冲突或服务不可用，流程怎样继续？

真正的 UI 责任不是掩盖黑箱，而是让用户能在不完全理解模型内部机制的情况下，仍然正确地使用、质疑和接管系统。

增强而非替代

课件把目标称为 intelligence augmentation（智能增强）：不是用人工智能替换人的智能，而是使人做得更好。它也提醒：human + AI 并不自动优于最好的单独一方；一项覆盖 106 项研究、370 个效应量的分析发现，人机组合平均甚至可能低于最佳的人或最佳的 AI，决策任务尤其容易亏损，内容创作任务更容易获益。

两个相反的失败模式需要同时防范：

• 过度依赖（overreliance）：AI 给出建议会锚定用户；即使解释推理，如果验证解释本身很费力，人仍容易盲从。
• 算法厌恶（algorithm aversion）：用户看到 AI 犯一次错后，可能即使它整体更准也拒绝再使用。

因此目标不是让用户“完全信任”或“完全不信”，而是信任程度与实际能力相匹配。好的增强式设计让 AI 负责搜索、归纳、草拟、提示与重复劳动，让人负责目标、价值取舍、异常判断和最终责任。

寻找值得增强的缺口

从用户已经强烈感到的信息、知识或执行缺口出发，例如：

• “这个群体可能怎样理解我准备发送的信息？”
• “把项目当前状态压缩成一段准确摘要。”
• “这个局面正在恶化；如果我采取某行动，可能发生什么？”

若填补这个缺口能让用户更有效地完成原本的工作，AI 就是在增强而非替代。衡量也要匹配目标：替代通常看节省成本；增强则可能看更高质量、更少错误、更好的决策，而不只是减少人力。

快速验证：Prompt Prototyping

课件建议在写完整系统前做 prompt 原型：拿一个真实输入样本，直接告诉通用聊天模型希望它完成的任务，观察它是否已经能“大致做对”。若接近目标，说明值得继续设计界面、上下文和验证机制；若连核心转换都做不到，应先缩小任务、改变目标或评估是否需要微调，而不是立刻投入大量工程实现。

配套工作

本讲对应的 Recitation 4（User journeys and UI sketching）与 Assignment 2（Functional Design）整理在 lec7.md 文末，因为它们更直接呼应下一讲"设计 AI 功能交互"里对用户旅程和界面草图的讨论。