假设你在左侧表格里手动选中了一块区域 B2 到 C4，然后问右侧的 AI："我现在选了哪里？"它居然答对了。
再假设你直接在 A1 里手敲了一个数字，没有告诉 AI，转头又问它："我刚才改了表格，帮我总结一下现在的状态。"它照样知道你动了 A1。
这看起来有点神奇------AI 又没有一双盯着屏幕的眼睛，它是怎么"看见"表格的？
答案藏在第二课的核心主题里：上下文。一个能干活的表格智能体，必须先解决一个最基本的问题，否则一切都无从谈起。
一个绕不开的矛盾
第一课我们讲过一条铁律：服务端做决策，浏览器执行真实操作。这条铁律背后藏着一个很硬的矛盾------SpreadJS 的工作簿是一个活在大模型浏览器内存里的大型对象，它依赖 DOM、Canvas、事件系统，根本没法被网络请求原样搬运。而模型的推理，偏偏发生在服务端。
服务端够不到浏览器里的工作簿，但模型每次做决策又必须知道当前表格长什么样。这是一对直接冲突的需求。
项目没有选择"硬把整个工作簿塞给模型"这条路，原因很现实：工作簿太大了，里面装着所有工作表的数据、样式、公式、图表、对象，全量传递既浪费又会让模型淹没在细节里。于是它采用了两条并行的路线。
第一条路线：所有真实的读写操作，都在浏览器里的工作簿上进行。模型不会自己维护一份表格副本，它操作的、用户看到的，是同一个真实工作簿。
第二条路线：每次发请求前，从工作簿里提取一份轻量的"上下文摘要"，随请求一起发给模型，帮它判断下一步该干什么。
这一课，就把这两条路线讲透。
三件随请求打包的"行李"
每次 AI 请求前，前端会组装一个请求体，里面除了聊天消息，还会打包三样东西：
Plaintext
workbookContext ------ 工作簿地图（有哪些表、活动表是谁、数据范围、当前选区）
taskContext ------ 任务计划走到哪一步了
dirtyContext ------ 上次请求之后，表格发生了哪些变化这三样，构成了模型理解"当前环境"的全部依据。
先说工作簿地图。系统会遍历工作簿里的所有工作表，记录工作表数量、当前活动的是哪张、每张表的数据用到哪个范围。这里有个细节很贴心：它会把内部的行列数字索引，转换成 A1 这种人类习惯的地址表示法，比如列索引 0 变成 A，行索引 0 显示成第 1 行。这样模型看到的上下文，和用户嘴里的"A1""B2:C4"对得上号。
更关键的是，它还会判断用户当前聚焦的是什么。如果选中的是图表、形状、图片这类对象，它就告诉模型"当前聚焦的是某个图表"；如果选的是普通单元格，它就输出选区范围。为什么这点重要？因为用户经常说"把这个图表改一下""给当前选区加个格式"。如果上下文里压根没有选区或选中对象的信息，模型只能瞎猜"这个"到底指什么。
但要强调一点：这份地图是导航信息，不是完整数据。如果模型需要知道某个单元格里具体的值，它仍然得老老实实调用读取工具。地图告诉你哪儿有东西，但不替你把东西搬出来。
用户手改了表格，AI 怎么知道
光有地图还不够。用户不一定只通过 AI 改表格，他随时可能直接在左侧的设计器里动手。如果用户手动改完，转头继续和 AI 聊天，而 AI 对刚才的变化一无所知，上下文就错乱了。
这正是 dirty tracker（变更追踪器）要解决的问题。
它绑定了 SpreadJS 的一组事件：单元格值变化、行列变化、工作表改名等等。每当这些事件触发，它就记一笔------A1 变了、第 3 行动了、某张表从"Sheet1"改名成了"销售数据"。所有变化都会被收集起来。
精妙的地方在于它的"消费"时机。每次组装请求体时，它会把这些积攒下来的变化序列化成一段文本发给模型，然后立刻清空记录。这意味着变更追踪天然以"一次网络请求"为粒度：上次请求之后发生了什么，这次请求就如实告诉模型什么；说完了就清零，下次重新攒。
这比每次都把整张表的数据塞给模型轻巧得多，也更贴合智能体的工作方式------模型大多数时候只需要知道"发生了什么变化"，真不确定的时候再调工具去查具体数据。
一个容易被忽略的前端工程细节
存这个工作簿对象，项目里有一个值得说的设计选择：它没有把工作簿放进普通的 React state，而是用了 ref。
为什么？因为工作簿是一个又大又爱变的对象。SpreadJS 内部自己管着一大堆状态------单元格、样式、选区、对象、事件。如果把它当 React state 频繁更新，既没必要，还可能带来额外的渲染开销和引用混乱。所以项目只用一个轻量的 state 保存"工作簿准备好没有"这个布尔标志，而把真实的工作簿实例稳稳地放在 ref 里，读取时再拿最新的那一个。
这其实是个挺通用的经验：在集成这种大型第三方 UI 组件时，React state 不一定是保存实例对象的最佳位置。对于"可变、由外部管理、需要稳定引用"的对象，ref 往往更合适。
一句话总结这套机制
这套上下文机制可以用一句话概括：真实状态留在浏览器，决策上下文随请求发送，真实操作通过工具回到浏览器执行。
模型自始至终没有真正"拿到"工作簿对象。它手里拿着的，是一张会随每次请求更新的工作簿地图、一份任务进度、一段近期变更。靠着这些导航信息，加上按需调用的读取工具，它就能对当前表格做出靠谱的判断。
这个设计的巧妙之处在于，它没有去硬解那个"服务端够不着浏览器"的死结，而是绕开了它------我不需要把整个工作簿搬过来，我只需要在每次需要决策的时刻，给模型一份恰到好处的环境快照。
这套思路，能搬到哪里
换个角度看，这套"上下文"思路远不止服务于表格。
任何"业务对象活在浏览器、决策发生在服务端"的智能体，都会遇到同样的问题：模型怎么知道当前画布上有什么、用户正盯着哪个组件、上一次操作之后环境变了什么。文档编辑器要告诉模型当前光标在哪、选了哪段；低代码平台要告诉模型画布上摆了哪些组件、哪个被选中了；设计工具要告诉模型当前图层结构。
做法都是同一个套路：不要硬传整个庞杂的运行时对象，而是提炼一份轻量、可导航、可增量更新的环境摘要，随每次请求送达，再用工具按需读取细节。
上下文质量，是被低估的竞争力
有意思的是，同样是接了大模型，有的智能体像个瞎子，问它当前选了哪里它只能瞎猜；有的却能精准感知你的选区和最近一次手改。这种差别，往往不出在模型身上，而出在有没有认真做这层"环境感知"。上下文质量，是区分一个"能演示"的 AI 和一个"真能用"的 AI 的隐形分水岭，却很少出现在产品宣传里。
这也是为什么这套机制值得细看：它让服务端的模型，始终对浏览器里那个庞杂的工作簿保持知情------靠的不是硬搬整个对象，而是一份"地图 + 变更 + 按需读取"的组合。
到这里，模型已经能"看见"表格了。但光看见还不够，它还得能动手。下一篇的问题来了：模型要改表格时，为什么不能让它直接写表格代码，而要绕一大圈，把操作封装成一个个结构化的"工具"？