先撂一句：你对“对话上下文”的心智模型，八成是错的。我自己错了好多年。
我一直把上下文想成一条聊天记录。你一句我一句，往下滚，卷轴。聊天界面也一直这么给我看，所以这个错觉从没被戳破过。直到最近玩一个叫 ThoughtDAG 的开源工具，玩到一半我停住了——它把上下文画成图。我盯着那张图看了半天，咔哒一下：上下文从来就不是一条线。
画张图。我以为的样子：
你 ──► 模型 ───► 你 ──► 模型 ───► 你 ──► 模型 …（往下滚）
实际的样子：
┌── 分支 A ──┐
根 ──┤ ├── 合并回主线
└── 分支 B ──┘
└── 剪掉的子图（不再进上下文）
每次对话是个节点，节点之间有边。你问模型的时候，它沿入边往回走，把相关祖先节点排个序，拼成一条消息序列发出去。也就是说——图才是上下文，你看到的那条聊天记录，只是这张图的一种走法。
这句话我建议再读一遍。一旦接受了这个设定，一堆“玄学现象”当场变工程问题。
最经典那个：“AI 被前面带偏了怎么办”。卷轴模型里你只能重开对话，或者贴一大段“请忽略上面”。全是绕。图模型里这就是个剪枝——找到把模型带歪的那个节点，剪掉，重新生成。病灶在哪一刀的事。
它给了个实验数据，我看到的时候坐直了：4 个模型、540 次运行的“上下文修复”试点。只删错误来源那个节点，72 次里修好 68 次；删了之后重算下游，71 次；把整个相关子图端掉，72/72。
72/72。全修好了。
我盯着这个数字看了挺久。我们平时处理“上下文被污染”的方式是什么？重开窗口、换模型、改 prompt 绕着走。而这里的思路是直接进上下文动手术。（老实讲，72 这个分母不算大，场景细节我也不清楚，数字先当方向看，别当定论。但方向本身够有意思了。）
还有个例子小到离谱，我特别喜欢：删掉一条“晚餐分支”的边，请求 token 少了 47 个，同样的提示词重新生成，回答里那段莫名其妙的晚餐建议就没了。47 个 token。平时你得重开对话，或者解释半天“别提晚餐”——这里就是删条边。
等等等等，先别急，还有个我特别买账的：它在生成前让你预览。这次请求模型会读到哪些节点、什么顺序、多少 token。这个太对了。我之前画 context window 那张桌子的时候就犯嘀咕——桌上到底摊了什么，平时完全是黑箱，你以为模型在读你以为的东西，实际上中间可能早被挤下桌了。能预览，黑箱就开了一条缝。
打个比方。普通画布类工具像整理办公桌：东西摆得再整齐，模型读什么还是它自己那套逻辑说了算。ThoughtDAG 是直接拿着记事本进去改——哪些内容进、哪些出，下一次请求。这两件事听起来像，其实是两个物种：前者整理信息给人看，后者编辑上下文给模型看。
这个比喻漏风的地方我得标出来。它不只是“编辑”，编辑完还得干重活——把图遍历成合法的消息序列。这个“图→序列”的编译步骤才是真正的核心，记事本比喻把这步整个吞掉了。为什么剪掉一个节点、下游不一定跟着变？为什么有时得重算下游才修得好（68 和 71 那两档差别就在这）？因为图是结构，序列是投影，动结构不等于投影自动干净。这格比喻盖不住，得回到真实机制看。
其他细节快速过：MIT 协议，local-first，支持 Ollama 和 OpenAI 兼容接口，桌面版自带引擎，不用装 Node 不用开终端。现在 v0.3.24，macOS 那边签了名公证过，Windows 还没签，SmartScreen 会拦一下，点“更多信息”继续就行。还能从选中段落直接提问、把段落转成带源链接的节点保住出处。这些都顺手，但不是重点。
重点是那个心智模型的替换。我之前画那张桌子的时候，桌上摊的还是“一段一段的对话”，还是线性的。这次得在桌上再画一层：摊上去的东西之间有结构，有分支有剪枝，谁上桌谁下桌是可以动手改的。
第一版我以为上下文是卷轴，动手玩了一圈才知道是图。不是工具厉害我才写这篇——是“上下文是图”这个认知本身，一旦扣上就退不回去了。现在再打开任何一个聊天框，那条往下滚的记录看着都有点……装出来的整齐。
这玩意儿真的太酷了。
下期我想画“上下文编译”这一格——图怎么变成模型真正读到的序列，中间那步排序的水比我想的深。你要是也玩了 ThoughtDAG，卡在哪一格告诉我，多半那里我也还没画明白。