聊天时说错一句话，重新打一遍就行。但表格不一样。如果 AI 把表格改错了，你的数据、格式、图表、各种对象，可能全都跟着变了。如果没有办法退回去，用户会打心眼里害怕让 AI 动手。
所以这套课程最后一课的主题是：可恢复、可追踪、可调试。它要回答的是两个问题------AI 做错了，用户怎么反悔？工具越来越多，开发者怎么不靠自然语言试错地调试？
两种快照，别再混了
前面第五课讲过一种回滚：代码执行工具内部，一次代码跑炸了，就恢复到这次代码执行之前。那是"工具级"的临时保护，生命周期很短，只盯单次高风险调用。
这一课讲的是更高一层的"会话级"恢复：用户发起一轮任务之前，先给工作簿存个档；AI 可能连着调好几个工具，要是用户发现方向不对，可以终止并退回到这轮任务开始之前；甚至还能从历史某条消息，分叉出一条新分支重新尝试。
两种快照存在不同的地方。临时快照放在内存里，最多留 10 个，给代码执行兜底用，页面刷新后不需要保留。会话级快照放在浏览器的 IndexedDB 里，最多 100 个，这才是支持终止还原、会话分支和历史恢复的主角。
要强调一点：这里的快照不是屏幕截图，而是 SpreadJS 工作簿的完整 JSON 状态。它要恢复的是数据、样式、对象这些真实的表格内容。
"停止生成"和"终止并还原"，根本不是一回事
很多产品都有个"停止"按钮，但通常它只是不让模型继续说话。如果前面已经执行过写入、格式化、插图表这些工具，工作簿早就被改了，光停止文字输出，表格还是脏的。
项目里的"终止对话并还原 SpreadJS"做的是两件事：第一，停掉当前 AI 回复；第二，把工作簿恢复到本轮用户消息发送之前的状态。
它怎么知道该恢复到哪个点？这里有一套精巧的绑定关系。用户每次发消息之前，系统会先生成一个快照编号，把当时的工作簿 JSON 存进 IndexedDB。但这时候用户消息还没真正进入消息列表，拿不到消息编号，所以先把快照编号暂存起来。等消息真正进列表了，再把这条消息的编号和快照编号绑定到一起。
这样一来，每条用户消息背后，都挂着一个"这条消息发出之前，表格长什么样"的存档。要终止还原时，系统找到当前这轮对应的最后一条用户消息，查它的快照，调 fromJSON 把表格整个倒回去。这就不是简单停止，而是连表格一起退回来。
从一句话，长出一棵决策树
更有想象力的功能是会话分支，它建立在快照能力之上。
比如用户尝试了两种报表方案。第一条路做了一堆图表，后来发现不对。这时他可以回到历史某条消息，复制出一个新分支，同时把工作簿也恢复到当时的存档，然后从那里换条路重新试。
分支在工程上是怎么做的？系统会把目标消息之前的历史切下来，作为一个新会话------注意是不包含这条消息本身，而是把它原文回填到输入框，让用户可以改一版再发。同时，只有新分支里还存在的那些消息，它们的快照映射才会被复制过去；已经不在新分支里的消息，快照关系也不该带过来。
这一步还贴心地处理了并发：如果 AI 正在回复，它不会立刻分叉，而是先弹个确认，用户点头了才停掉当前链路再分叉，避免旧会话还在偷偷往表格里写东西。
这个功能把 AI 对话从一根走到底的直线，变成了可以分叉、可以回溯、可以对照的实验工作流。
复杂任务，得让 AI 学会列清单
会话和快照解决的是"怎么退回去"，任务计划解决的是"复杂任务怎么往前走还不乱"。
复杂任务不是一口气做完的。整理数据、设样式、插图表、生成总结，模型会先把它拆成几步，每做完一步更新状态；下一轮请求时，模型还能看到当前进度。
任务计划存在一个专门的 store 里，保存的不只是一个清单，而是多个计划------最新的那个是当前在执行的，历史计划压成摘要保留下来，不至于把上下文塞爆。模型每完成一步，下一个待办会自动变成"进行中"，并把"下一步是什么、还剩几步"告诉模型。而这些进度，会在每次请求前被序列化成文本，和前面几课讲的工作簿上下文、变更记录一起发给模型。
任务计划平时存在内存里，但切换会话、刷新页面时不能丢，所以还有一套导入导出机制，把它和会话一起持久化。
开发者的秘密武器：跳过模型的调试台
工具攒到快 90 个，开发者如果每次验证都得靠自然语言让模型去试错，会疯掉。项目为此准备了一个调试台，能跳过大模型，直接选一个工具、填好参数、跑一遍处理流程。
它有五道关，和第五课提过的调试路径一脉相承：先拿参数结构校验输入，再确认工具在哪执行、能不能找到处理函数，接着检查工作簿准备好了没，然后真正执行，最后检查结果能不能正常序列化。
这个调试台的价值极大。新增一个工具时，你可以先在调试台里验证它的参数结构和处理逻辑对不对，再让模型去调用。否则你根本分不清：到底是模型没选对工具，还是工具本身写错了。它把"模型的问题"和"工程的问题"彻底隔离开。
七节课，一条完整的工程链路
到这里，七节课的主线就完整了。
第一课，跑通从一句话到真实表格操作的全链路；第二课，讲模型怎么通过上下文摘要看懂当前表格；第三课，讲为什么要把表格 API 封装成结构化工具；第四课，讲怎么用渐进式暴露，不让近百个工具淹没模型；第五课，讲 MCP 和代码执行怎么应对复杂场景，还配了回滚保护；第六课，讲破坏性操作检测和人工确认；第七课，讲快照、回滚、分支和调试台。
这套项目最值得带走的，不是某一个 API，而是它的工程分层：模型负责决策，工具负责约束，bridge 负责执行，上下文负责连接真实工作簿，安全机制负责把关，快照负责兜底，调试台负责可维护。
它从头到尾都没有假设模型永远正确。恰恰相反，它承认模型会误解、会误选、会失败，于是用上下文让它看清楚，用工具给它画边界，用确认机制把关键决定交还给人，用快照让一切都能反悔。真正可靠的 AI，不是那个从不出错的 AI，而是出了错也有办法兜住的 AI。
这或许才是这套课程想交付的真正价值。对使用者，它意味着你可以放手让 AI 替你干活，而不必时刻提心吊胆------可控、可恢复、可追踪，是 AI 真正走进业务系统的通行证。对建设者，它是一套可以搬走的工程范式：这个项目是一个表格智能体，你的业务肯定和它不完全一样，但思路是通用的。把这套分层和你的系统结合起来，最终能做到的，是把 AI 从"能聊天、能演示"，真正推进到"能在真实业务对象上可靠地工作"。