Lec 8 设计 AI 功能交互 II：超越聊天

本讲从“prompt → completion”的聊天模式推进到结构化、可验证且嵌入任务流程的 AI 交互。

学习目标

• 掌握设计 人-LLM 交互 的基本技巧：这样你能够在项目中加入 AI 功能
• 理解其中的障碍，以及克服这些障碍的设计模式
• 下节课：LLM 推理与提示词的技术实现方法：“我到底该如何实现这些功能？”

TL;DR

• 重复或高风险任务不应停留在开放聊天框中；结构化输入、字段化输出和渐进披露能降低用户组织提示与核验结果的成本。
• 生成和执行必须分离：草稿、候选比较、来源检索与失败可见性让错误停留在可编辑阶段，不直接污染真实业务状态。
• Agent 的本质是模型获得了环境观察、工具调用和多步行动能力；自动化程度应随风险、可逆性和权限连续调整。
• Agentic harness 中的上下文、输入输出结构和工具权限都是产品设计决定，必须显式定义批准、暂停、撤销与审计点。

回顾

Prompt + Completion 的问题告诉我们：AI 产品难点不只是“生成答案”，而是让用户和 AI 正确理解彼此；Prompt + Reasoning + Completion 则尝试通过“回答前先推理”提高复杂任务与错误检查能力，但它并不会自动解决 Context、Mental Model、Iteration 和 Alignment 等设计问题。

在 Chat 之上

从聊天到任务界面

聊天适合探索、问答和开放式表达，但它把输入格式、上下文组织、输出解释的负担都交给用户。对于重复或高风险任务，优先使用：

• 结构化输入：表单、选择器、文件和明确约束，降低提示词负担；
• 结构化输出：字段、候选项、差异标注，而不是只给一段文字；
• 渐进披露：先给可行动的摘要，再按需展示理由、来源和完整草稿；
• 人工确认：生成与执行分离，尤其是发送、发布、支付、修改数据等不可逆动作。

设计模式

1. 草稿伙伴：AI 先产出可编辑草稿，用户拥有编辑与提交权。
2. 比较而非裁决：并列多个候选及其取舍，让用户选择。
3. 检索/工具增强：让回答基于当前数据或可追溯来源，而不是只靠模型记忆。
4. 失败可见：无答案、低质量或工具调用失败时明确提示，并给出替代路径。

上下文与提示的具体策略

• zero-shot：只给指令，适合边界清楚的简单任务；
• few-shot：附上少量“输入—理想输出”示例，尤其应包括边界案例；
• 最小充分上下文：上下文越多不一定越好，可能稀释重点、增加延迟与成本；只提供模型完成当前任务必需、且用户预期会被使用的信息；
• 明确告知上下文：系统使用了哪些私人资料、资料是否会保存、为什么需要它们，都应向用户说明。隐藏上下文会侵蚀信任并造成隐私风险。

Agent 与混合主动权

Agent 不只是“能聊天的模型”，而是能观察环境、调用工具、规划多步并采取行动的系统。能力越高，越需要把控制权设计成连续谱，而非“全自动/全手动”二选一：低风险、可逆的步骤可自动做；涉及外部沟通、资金、权限或不可逆变更时应停下来询问。可干预点包括批准计划、修改目标/约束、查看进度、暂停、撤销和事后审计。

所谓 agentic harness，本质是为模型搭建的 上下文 + 结构化输入 + 结构化输出 + 工具权限。其中每一项都是产品设计，不应默认为模型“自己会处理”。

配套工作

本讲对应的 Prep 2（Gemini LLM API）、Recitation 5（Using an LLM API in Node）与 Assignment 3（AI-augmented Concept）整理在 lec9.md 文末，因为它们更偏向下一讲"LLM 代码架构"里讲的 API 调用与推理技术细节。