课前：先自学，再做 15 道题
上课前，先花点时间自己看一页材料，就三样：
- 弄懂 3 个词：业务状态（这条任务到哪一步、还缺什么——一张短表）、状态机（收集→待确认→执行→完成/失败/转人工）、追问 / 修正 / 转人工。
- 记住 1 个比方：工单表——状态要落地，不能只靠聊天记录。
- 记住 1 条红线：别什么都记；身份证号、家庭住址、病情这些任务用不上的，不收集。
看完做 15 道自测题。哪几道大家错得多，直播时老师就重点讲哪几道。
直播 0–30｜把核心快速过一遍
- 聊天记录 ≠ 业务状态。 前者是"说过的话"，后者是"这条工单到哪一步、还缺什么"，应该是一张短表。
- 状态机六个状态就够用。 收集信息 → 待确认 → 执行中 → 完成 / 失败 / 转人工。
- 三件事必须支持。 改（覆盖旧值，不追加）、退（中途离开接着上次）、转（风险高就转人工，并把已收集的信息带过去）。
直播 30–75｜挑大家做错的题讲
- 把聊天历史当状态，聊到第 20 轮就开始忘前面，状态得落地。
- 一次问三个问题，用户往往只答一个，剩下两个就丢了。
- 用户改口没覆盖，旧值还留在那，后面全错。
直播 75–120｜拆一个真实案例：银行信用卡客服，多轮槽位
一家银行的信用卡客服（社媒/企业微信渠道），要多轮对话，记住用户已经给过的信息、认出还缺哪些槽位。材料是一段对话（"我要办卡 → 学生 → 首卡"），加一张槽位表 {卡种, 是否首卡, 期望额度, 缺失:[...]}。
这里埋了 3 个坑：把聊天历史当状态，聊到第 20 轮就忘了前面；一次问三个问题，用户只答一个；用户改口"刚才说错了是金卡"却没覆盖，后面全错。课堂上两人一组，一人演用户、一人演系统（一次只问一个槽位），记下问几下才问全，再换 AI 来对比。
这一讲想让你记住的就一句：状态要落地，别只靠聊天记录；MemU 发现"记忆没有统一标品"，企业接入要围绕自己的场景去定制。
当堂练一个（8 分钟）：给 AI 派一件要收集好几样信息的日常小事（比如"帮我组织一次班级聚餐"），你分三次、每次只给一样（先给时间，再给人数，最后给预算和忌口），中间故意改一次口（"刚才说 10 人，改成 12 人"）。看它：①有没有一次只问一个、不重复追问你已经给过的；②改口之后是不是用 12 覆盖了 10；③最后能不能把三样信息一次复述全。
判断标准：不重复问已给过的、改口后旧值被覆盖、能一次复述全——三样都做到才算过关；只要它把你改过的"10 人"还当成准数，就是失败。
课后：答疑 + 陪跑，交一份作业
本讲必过：记忆。 列 4–6 个必收集字段 + 画 6 状态 + 状态落表 + 实现追问/修正/转人工；测 4 条（一次说全 / 分三次 / 中途改口 / 退出再回）。
这节课你该会的：
- 分 3 次给信息，它能拼成一份完整记录；
- 说"刚才说错了"，旧值被覆盖、状态跟着改；
- 中途退出再回来，能接着上次、不从头问。
三个翻车：
- 把聊天历史当状态——聊到第 20 轮就开始忘前面，状态得落地；
- 一次问三个问题——用户只答一个，剩下两个就丢了；
- 用户改口没覆盖——旧值还留着，后面全错。
延伸自读：《原理讲义》§6
展开查看
一句话定义：记忆不是把说过的话都存下来，而是把"这件事走到哪一步、还缺什么、已经确定了什么"收成一张随时能读、能改、能交接的状态表——对话负责收集，状态负责记住。
核心原理
1. 状态机：用有限的状态，换取可预期。 一个业务任务在任意时刻只可能处在少数几个阶段之一：收集信息 → 待确认 → 执行中 → 完成 / 失败 / 转人工。为什么要先画状态机？因为模型不会"自己知道下一步该做什么"——它每轮都是重新读输入，若不把阶段显式写出来，它只会临场发挥，问得时多时少、时对时错。把阶段定死，等于给了模型一张地图：它看一眼状态就知道当前该问、该确认，还是该交人。某零售企业的设备报修助手，把工单切成"收齐字段 → 待确认 → 派单 → 完成 / 转人工"，字段收齐前绝不派单；没了这条约束，模型会在"型号还没问"时就把单派出去。
2. 追问 / 修正 / 转人工：三件必须支持的事。 缺字段就追问，且一次只问一个——一次问三个，用户往往只答一个，其余全丢。用户改口要覆盖旧值而非追加：先说了"笔记本"、后改口"一体机"，表里只能留一个当前值；追加会留下两个互相矛盾的答案，后面全错。风险高要转人工并带上下文：不是把人叫进来重讲一遍，而是把已收集字段原样交接，人接手时看到的是状态表而非几十轮聊天记录。这三件事的共同前提是"状态可写"——没有落地的状态，追问不知问什么、修正无处覆盖、转人工没东西可交。
3. 状态落地：聊天记录 ≠ 状态。 聊天记录是"说过的话"，是流水账；状态是"已确定的事实 + 还缺的事实"，是一张短表。为什么不能靠聊天记录硬撑？因为对话是线性的、会遗忘、会重复、会自相矛盾；把二十轮对话全塞回模型，既耗上下文，又会把早期的过时说法当真。正确做法是每轮把状态表的"当前行"作为输入的一部分，模型更新后写回，下一轮再用。抽象地看，这就是"半自动状态落地"——模型不负责记忆，只负责在既定的表上读一行、写一行。
常见误区 / 边界
- 别把历史当状态：靠翻聊天记录硬撑，第 20 轮必忘前面，且改口不覆盖。
- 别一次问多个：追问一次只补一个缺失字段。
- 别什么都记：只记任务需要的字段。身份证号、家庭住址、病情若与任务无关就不收集——记忆是有成本的风险敞口，不是越多越好。
- 别把主观当客观：紧急度不该问"你急不急"，而应由客观影响范围（个人 / 多人 / 全员）决定。
- 别混同"记忆"与"状态"：长期记忆（用户偏好、项目习惯）要围绕具体场景定制，不能拿一套通用记忆硬套所有 Agent。
一句可带走的话：让模型负责对话，让一张状态表负责记忆——缺就追问、改就覆盖、险就交人。
案例包 · 15 题自测
展开查看
看完做 15 道自测题。分三块，每块约 5 道：①聊天记录不等于业务状态；②状态机只有六个状态够用；③改 / 退 / 转三件事都得支持。
每题都有解析，容易错的地方标了出来。哪几道大家错得多，直播时老师就重点讲哪几道。
第 1 块｜聊天记录 ≠ 业务状态（Q1–Q5）
- （单选）多轮对话里，"业务状态"指的是什么？
- A. 从第 1 轮到现在的全部聊天记录
- B. 这条任务走到哪一步、还缺什么的一张短表
- C. 模型的上下文窗口大小
- D. 用户的身份与画像
答案：B ｜ 解析：状态是"到哪一步、还缺什么"，不是"说过的话"。 容易错：很多人会选 A，把聊天历史当状态。
- （判断）只要上下文窗口足够长，聊天记录就能完整承担业务状态的角色。
答案：错 ｜ 解析：聊到第 20 轮模型会开始忘前面；状态必须落地成一张短表，每轮只读当前行。
- （单选）工单处理到第 15 轮，模型忘了用户第 2 轮说的"我是笔记本"。最可能的根因是？
- A. 模型能力不足
- B. 状态没落表，只靠聊天记录硬撑
- C. 用户没说清楚
- D. 网络延迟
答案：B ｜ 解析：不是模型不行，是没把状态沉淀下来。
- （单选）一张"业务状态短表"最少应该包含哪两项？
- A. 全文对话 + 用户昵称
- B. 当前状态 + 已收集 / 缺失字段
- C. 时间戳 + IP 地址
- D. 情绪 + 语气
答案：B ｜ 解析：状态表 = "到哪一步（状态）+ 还缺什么（字段）"。
- （判断）业务状态应该是一张短表，而不是把全部聊天记录原样存下来。
答案：对 ｜ 解析：短表才能被程序读取、校验、续接；聊天记录只能回看。
第 2 块｜状态机只有六个状态够用（Q6–Q10）
- （单选）本讲的标准状态机是？
- A. 新建 → 处理中 → 已完成 → 已关闭
- B. 收集信息 → 待确认 → 执行中 → 完成 / 失败 / 转人工
- C. 提问 → 回答 → 追问 → 结束
- D. 开始 → 暂停 → 恢复 → 终止
答案：B ｜ 解析：六个状态覆盖"收信息、确认、干活、三种收尾"。
- （单选）"缺什么问什么"发生在哪个状态？
- A. 执行中
- B. 完成
- C. 收集信息
- D. 转人工
答案：C ｜ 解析：收集信息阶段就是逐项补齐必收集字段。
- （判断）状态越多越精细越好，最好每种情况都设一个状态。
答案：错 ｜ 解析：六个就够；状态一多，判断和流转就变复杂，反而更容易跑错。
- （单选）字段收集齐了、等用户点头确认，应切到哪个状态？
- A. 收集信息
- B. 待确认
- C. 执行中
- D. 完成
答案：B ｜ 解析：收集完先给用户确认，确认过才执行。
- （判断）"失败"和"转人工"含义相同，都是"机器做不了"。
答案：错 ｜ 解析：失败是机器多次尝试仍做不成；转人工是风险高 / 超出能力，交给真人。两者是不同的终态。
第 3 块｜改 / 退 / 转三件事都得支持（Q11–Q15）
- （单选）用户先说"笔记本"，后来改口"其实是一体机"。正确做法是？
- A. 新增一条，两个都保留
- B. 用"一体机"覆盖"笔记本"
- C. 反问用户到底哪个对
- D. 忽略改口，按先说的来
答案：B ｜ 解析：改口必须覆盖旧值，不能追加。 容易错：很多人会选 A，把"保留历史"当成"保留两个值"。
- （判断）用户中途离开、第二天回来继续，系统应该从头重新问一遍。
答案：错 ｜ 解析：要支持"退"——从当前状态和已收集字段继续，不重问。
- （单选）"转人工"时，应该把什么交给人工？
- A. 什么都不给，让人工自己重新问
- B. 已收集到的字段（上下文）一起带过去
- C. 只给一句"用户有点急"
- D. 只给用户昵称
答案：B ｜ 解析：转人工要带上下文，否则人工又从头问一遍。 容易错：很多人会选 A，转人工时把已收集的信息丢了。
- （判断）"覆盖旧值"意味着用户每改一次口就新增一条记录，保留全部历史便于审计。
答案：错 ｜ 解析：覆盖旧值 = 不追加；旧值要被新值替换，否则后面全按旧值算错。
- （单选）追问缺失信息时，一次问几个问题最稳？
- A. 一次问 3–4 个，效率最高
- B. 一次只问 1 个
- C. 一次问 5 个以上，一次问全
- D. 不追问，让用户自己一次性补齐
答案：B ｜ 解析：一次问多个，用户往往只答一个，其余全丢。 容易错：很多人会选 A，觉得一次问多个更省事。
案例包 · 案例拆解素材
对应第 6 讲「记忆、多轮与业务状态」
课堂用时：案例拆解 45 分钟（直播 75–120）
材料与提示词思路：全部写在这个文件里
1. 客户和场景
一家银行的信用卡客服，接在社媒、企业微信这些渠道上，要准确回答信用卡产品与权益的问题，还得支持多轮对话。
这里有个坑：用户一句话说不全（"我办卡要多久""额度多少""怎么还款"），系统得记住已经给了什么、看出还缺什么、主动追问补全，而不是每轮从头问。
2. 为什么拿这个案例来讲
- 多轮不是"把聊天记录越存越长"，而是"把状态落成一张短表"。
- 记忆没有统一的标准品：陪伴 Agent 记偏好和关系，Coding Agent 记代码风格和项目决策，企业接入要围着场景来定制（这是 MemU 的真实结论）。
- 真实数字：银行信用卡客服从约 70% 提到 95%，靠的是长期的数据、评测和业务规则建设，不是调一次提示词。
3. 原始材料（真实多轮要点）
多轮场景要认出三件事：
| 要识别 | 例子 |
|---|---|
| 当前意图 | 用户在问"额度"还是"还款"还是"办卡" |
| 已提供信息 | 已经说过"学生卡""无收入" |
| 缺失槽位 | 还缺"办卡类型 / 是否首卡 / 期望额度" |
4. 故意埋的三个坑
坑 1：把聊天历史当状态
聊到第 20 轮，模型开始忘前面。状态应该落成一张短表（{卡种, 是否首卡, 期望额度, 缺失:[...]}），而不是把 20 轮聊天全文一直塞进上下文。
坑 2：一次问三个问题
用户只答一个，剩下两个丢了。对的做法：一次只问一个槽位。
坑 3：用户改口没覆盖
用户说"刚才说错了，是金卡不是普卡"，系统没覆盖旧值，后面全错。对的做法：覆盖旧值，不追加。
5. 两版提示词思路（内联）
- v1（故意有缺陷）：只靠对话历史追问，不落状态、不改口覆盖。
- v2（修复后）：每轮先读状态表 → 识别缺失槽位 → 一次问一个 → 改口覆盖旧值 → 信息够了转人工带上下文。
6. 验收样例（3 条）
| # | 对话 | 期望 | 判定 |
|---|---|---|---|
| 1 | "我要办卡" → "学生" → "首卡" | 三轮拼全，不重复问 | 通过 |
| 2 | "刚才说错了，是金卡不是普卡" | 覆盖旧值 | 通过 |
| 3 | "算了不办了" → 下次回来 | 不从头问，接着上次 | 通过 |
7. 案例拆解 45 分钟怎么走
| 分钟 | 做什么 |
|---|---|
| 0–5 | 抛"电脑坏了问三遍"式的翻车：它每轮都从头开始 |
| 5–15 | 找坑：把聊天历史当状态 / 一次问三个 / 改口不覆盖 |
| 15–30 | 判对错：用 v1 跑三段多轮对话，看它怎么重复问、怎么不覆盖 |
| 30–40 | 给修复：换 v2 + 状态落表 + 改口覆盖，重跑 |
| 40–45 | 收口：状态要落地，不要只靠聊天记录 |
8. 一句话总结
聊天记录是"说过的话"，业务状态是"这条任务到哪一步、还缺什么"——状态落地成一张短表，多轮才不乱。
案例包 · 课后操作单
目标：让助手记住已经给过的信息、看出还缺哪个槽位、一次只问一个、改口就覆盖。
时间：课后 60 分钟。
你要交的东西
- 一张槽位表（4–6 个必收集字段）；
- 一张状态图（6 个状态）；
- 4 条多轮测试（一次说全 / 分三次 / 中途改口 / 退出再回）。
怎么做
第 1 步：列字段（10 分钟）
列出这个任务必须收集的 4–6 个字段（少比多好），画出 6 个状态（收集 → 待确认 → 执行 → 完成/失败/转人工）。
第 2 步：状态落表（15 分钟）
把状态存进智能表格，让模型每轮先读当前行、再写回，不靠聊天记录。
第 3 步：实现三件事（20 分钟）
追问缺失的、接受修正（覆盖旧值）、转人工（带已收集信息）。
第 4 步：测 4 条（15 分钟）
一次说全 / 分三次 / 中途改口 / 退出再回，逐条记下来。
课后作业
- 找 1 个真人完整用一次，记录对话、状态变化、卡点。
- 修掉一个"重复追问"或"状态没更新"的问题。
- 写 100 字：为什么不能只靠聊天记录？
达标标准（这节课你该会的）
- 分 3 次给信息，它能拼成一份完整记录；
- 说"刚才说错了"，旧值被覆盖、状态跟着改；
- 中途退出再回来，能接着上次、不从头问。
容易踩的坑
- 把聊天历史当状态。
- 一次问三个问题。
- 用户改口没覆盖，旧值还在。
- 转人工不带已收集字段。
案例包 · 教师脚本（教师用）
展开查看
课前准备
- 把银行信用卡客服多轮对话场景 + 槽位表准备好（见 case_card.md），投屏。
- 自己先跑 v1，确认它会：把聊天历史当状态、一次问三个、改口不覆盖。
- 开课前看一眼 quiz 错误率，圈出错误率最高的 3–5 题。
0–30｜把核心快速过一遍（3 个点）
- 聊天记录 ≠ 业务状态（10 分钟）— 前者是"说过的话"，后者是"这条任务到哪一步、还缺什么"，应该是一张短表。打个比方：工单表。
- 状态机只有六个状态够用（10 分钟）— 收集信息 → 待确认 → 执行中 → 完成 / 失败 / 转人工。
- 三件事必须支持（10 分钟）— 改（覆盖旧值，不追加）、退（中途离开接着上次）、转（风险高转人工并带已收集信息）。
30–75｜挑大家做错的题讲
按 quiz 里错得多的题，每道讲清"错在哪一层 + 对的做法"：
- 把聊天历史当状态 → 聊到第 20 轮忘前面，状态要落地成短表。
- 一次问三个问题 → 用户只答一个，其余丢，一次只问一个槽位。
- 用户改口没覆盖 → 旧值还在，后面全错，改口必须覆盖。
- 转人工不带上下文 → 人工又从头问。
75–120｜拆案例：银行信用卡客服多轮槽位
发材料（5 分钟）：贴出一段多轮对话（"我要办卡 → 学生 → 首卡"），问"现在能判断该给他办什么卡吗？还缺什么槽位？"引导大家看出还缺"办卡类型/期望额度"。
找坑（10 分钟）：两人一组，一人演用户、一人演系统，规则是"一次只能问一个槽位"，记下问几下才问全。再换 AI 问，对比谁问得全、谁更啰嗦。
判对错（15 分钟）：用 v1（只靠对话历史追问）跑三段多轮，看它怎么重复问、怎么不覆盖"刚才说错了是金卡"。
给修复（12 分钟）：上 v2（每轮先读状态表 → 识别缺失槽位 → 一次一问 → 改口覆盖旧值 → 转人工带上下文），重跑对比。
收口（3 分钟）：状态要落地，不要只靠聊天记录。提一句真实背景：银行信用卡客服从约 70% 提到 95%，靠的是长期数据、评测和业务规则建设；MemU 发现"记忆没有统一标品"，企业接入要围绕场景定制。
标准答案
- 状态表：
{卡种, 是否首卡, 期望额度, 缺失:[...]}。 - 坑 1：聊天记录 ≠ 状态，状态落成短表。
- 坑 2：一次只问一个缺失槽位。
- 坑 3：用户改口（"金卡不是普卡"）→ 覆盖旧值，不追加。
学生会错在哪
- 把聊天记录当状态，聊到后面开始忘。
- 一次问三个问题，用户只答一个。
- 用户改口不覆盖，旧值还在。
- 转人工不带已收集字段，让人工重问。
- 过度收集：顺手要身份证号、家庭住址等与办卡无关的信息。
评分点（每条 1 分，共 5 分）
- [ ] 状态落表：产出槽位表，不把聊天记录当状态；
- [ ] 一次一问：追问时一次只问一个缺失槽位；
- [ ] 覆盖旧值：用户改口后表中只剩新值；
- [ ] 转人工带上下文：高风险时转人工并带已收集字段；
- [ ] 三件事（改/退/转）都测过。
如果学生问"能不能让 AI 把整段聊天都记下来，省得落表"
回答：不能只靠聊天记录。聊天记录是"说过的话"，状态是"到哪一步、还缺什么"。聊到第 20 轮模型会忘前面，而且程序没法从一段话里读字段。状态要落地成一张短表，每轮只读当前行。