切换深色模式
Genie Worksheets：把对话状态写成业务规则
对应 CS224V · 2026-11-02 · Minimizing hallucination in task-oriented agents。日期为校方课表日期，可能调整。核对官方课表。
资料状态
核对日期：2026-09-19。对应课程尚未开课；本文是基于公开课纲与文中原始资料的原创预习技术解读，不是课堂实录、讲义翻译或官方作业答案。本文于 2026-09-20 深度修订。示例为原创教学设计；离线实验与真实模型实验的边界分别说明，不以推演冒充模型实测。
课程助手找到了 C1，用户准备登记选课意向，却在对话中不断补充和修改：“先选这门”“它的项目是什么”“等等，改成另一学期”。如果系统只把聊天历史重新交给模型，旧确认和新条件很容易混在一起。
本讲用一份原创登记草稿说明：对话理解可以灵活，业务状态必须明确。登记仅为教学模拟，不连接真实选课系统。
把字段分为用户输入与派生结果
用户提供课程、学期与选择意图；程序计算时间冲突、先修满足和学分余额；文本模块判断实践偏好。不能让模型直接写入“资格已通过”，绕过实际检查。
text
用户字段：course_id、term
事实输入：已修课程、当前学分、已选时段
派生字段：先修状态、冲突状态、学分状态
提交前提：派生字段均通过，且确认绑定当前草稿版本Genie Worksheets 论文研究以声明式规格组织任务与知识交互。本文借其方向建立状态依赖，不将下面的伪代码当成官方 API。
对话更新应该是局部补丁
用户问“C1 的项目是什么”，只增加一个知识查询，不改变选择。用户说“改成春季”，则更新学期，并使依赖学期的开课实例、时间检查和确认状态失效。
如果每轮都让模型重新生成整个状态，未提及的字段可能被错误清空；如果只接受自由文本追加，又难以发现哪些旧结论已经失效。更可控的方式是解析本轮更新补丁，再由规则层决定影响范围。
text
输入补丁：term = spring
规则传播：offering 未确认 → time_check 未确认 → confirmation 失效
保留：用户已完成先修 A 的事实依赖图解释为什么某些字段需要重算、另一些可以保留，避免全量重置或全量继承两个极端。
确认不是一个永久布尔值
用户确认 C1 秋季草稿后，又改为 C2。若 confirmed=true 不变，系统可能把旧确认应用到新课程。应保存 confirmed_revision 或绑定草稿内容摘要；修改任何会改变外部动作的字段，就要求重新满足确认条件。
这里的确认与资格检查也不同：用户愿意选 C2，不代表它没有时间冲突。业务规则不能被自然语言“就这么办”自动覆盖，除非产品明确支持相应例外流程。
检查通过到提交之间仍有竞争窗口
在真实系统中，名额可能在检查后被占用。不能因为助手前一分钟看到可选，就保证提交成功。最终事务应在权威服务中重新检查必要条件并提交，返回明确结果。
如果响应丢失，进入结果未知，而不是重新创建新的选课意向。业务操作 ID 与幂等机制仍然必要。声明式对话状态并不替代数据库事务或外部服务的一致性设计。
一次状态更新应作为完整转换提交
假设草稿第 7 版选择 C1，用户刚把它改成 C2，后台针对 C1 的先修检查却在此时返回“通过”。如果系统只按字段名写回 prerequisite_ok=true，旧结果就污染了新草稿。
每项派生计算应携带它所读取的输入版本。写回时检查当前依赖仍相同；若不同，丢弃旧结果并重新计算。最简单实现是比较整个草稿 revision，更精细的实现比较相关字段指纹，避免无关的备注修改使所有检查失效。
状态更新还要保证“修改课程、使确认失效、使派生结果失效”作为一个完整转换提交。不能先写新课程，稍后再清确认，中间留下一段新课程继承旧确认的窗口。单进程原型可用纯函数计算新状态再替换，持久化系统则需要事务或版本条件更新。
这项规则可以写成不变量：凡是可提交的草稿，其确认与所有必要检查都必须对应当前动作输入。测试不只重放顺序对话，还应故意交换后台返回顺序，确保晚到的旧结果不会让不合格草稿变成可提交。
跟踪一段完整对话
开始选择 C1，状态检查通过；用户询问项目，选择保持；用户确认，草稿版本 1 获得确认；用户改为 C2，版本升为 2，时间检查发现冲突，旧确认失效；用户说“提交”，系统应解释当前冲突，而不是沿用版本 1 的通过结果。
再加一句“取消刚才的选择”，如果系统中既有草稿又有已提交记录，需要明确取消对象。关键词识别不足以决定删除哪一项状态。
这段回放可以逐轮检查状态，而不必等到最后一句答复才发现错误。
如何划分测试责任
语言理解测试检查“改成春季”是否形成正确补丁；状态测试检查依赖失效；工具测试检查最终服务返回；任务测试检查是否产生正确登记结果。某一层失败不应自动归因于模型能力。
规则形式化后更容易验证，但规则可能不完整，抽取也可能错误。它的价值是让这些问题有明确位置，而不是宣称对话系统因此不再出错。
下一讲从单个任务状态转向多条数据的分析，继续要求结论能回到可检查过程。阅读DataSTORM。