上下文因果关系
查看 AI 在修改某处之前读取了什么——为每处修改列出可能的源引用，每条都带一个置信度分数，全部在你的机器上计算完成。
当 AI 编辑一个文件时，最有意思的问题通常是“它看了什么才做出这个决定？”上下文因果关系正是回答这个问题：它把每次 Write/Edit 回溯到此前发生的读取操作（Read、Grep、Glob……），并按每次读取实际影响该修改的可能性进行排序。这是一个本地结构性启发式方法——即 server/causality.js 中的 analyzeCausality()，全程没有任何 LLM 参与——因此它离线运行、瞬时完成，并且永远不会把你的代码送出本机。这是一个有意的权衡：它推理的是文件之间的关系和先后顺序，而不是语义，而且它会如实标注置信度，而不是瞎猜。
⛓ 徽标
在 Playback（回放）中，任何拥有候选来源的修改消息都会在其头部得到一个显示来源数量的 ⛓ 徽标。点击它会打开一个标题为*“What likely drove this change”*（可能促成这次修改的因素）的面板。每一行代表一次源读取，显示：
- 一个置信度条和百分比，
- AI 读取的工具与文件（或它运行的搜索模式），
- 一段简短的、用大白话写的原因。
点击任意来源行可跳转到该消息在记录中的位置，这样你就能读到 AI 究竟看到了什么。
读取是如何匹配到修改的
对于每一处修改，Chronicle 只查看那些在会话中更早发生（序列号更小）的读取，然后根据每次读取与被修改文件之间的结构性关系为其打分。最强的关系胜出：
| 置信度 | 关系 | 显示的原因 |
|---|---|---|
| 0.95 | 读取了它随后修改的那个确切文件 | "read this exact file before changing it" |
| 0.55 | 读取了同一目录下的同级文件 | "read a sibling file in the same directory" |
| 0.50 | 读取了另一个同名（基础名相同）的文件 | "read a file with the same base name" |
| 0.45 | 运行了一次搜索，其模式匹配了被修改的文件 | "searched for '…'" |
| 0.20 | 在修改前不久读取，但没有结构性关联 | "read shortly before this change (background context)" |
0.20 这一档只适用于处在较短时间窗口内的读取（修改前的最后几次读取），这也是为什么“read shortly before”属于背景上下文，而非直接证据。来源会按每次读取去重、按从强到弱排序，并截取最靠前的少数几条——因此面板会以确切文件匹配（如果存在的话）打头，然后逐渐过渡到较弱的上下文关联。
在面板中，高置信度的来源（高于 0.8）会被标注为 direct（直接），低置信度的（低于 0.3）则标注为 background（背景），因此一眼就能看出 AI 是从它所编辑的那个文件出发，还是从更宽泛的周边上下文出发。
为什么用启发式方法而非模型
Chronicle 在任何地方都不做 LLM 调用——这是它离线、本地优先的保证。因果关系分析若配上一个能读取实际内容的模型会更精准，但那意味着要把你的代码送到某个 API，而 Chronicle 绝不这样做。它所使用的结构性信号（同一文件、同一目录、相同基础名、匹配的搜索、时间上的邻近）实际上能解释大多数真实的编辑，而各个置信度档位则让这个工具在关联仅属旁证时不至于夸大其词。请把它当作一个快速、私密的“这是从哪儿来的？”指针——而不是先知。
相关内容
- 时间旅行 — Playback 模式，⛓ 徽标就与每条消息的 Git 快照一同呈现在这里。
- 安全、实时与回放内幕 —
server/causality.js的内部实现，以及 Chronicle 的其他本地启发式方法。