PR 声称检查通过，需要关联到提交代码的证据

Cassandra Chin 开发 Tracetoon，目的是改善即使底层工作有价值、描述却可能不准确的拉取请求。她与 Stephen Chin 介绍了工具如何收集编程智能体上下文、审查说法，并可选生成漫画。

讲者用虚构的 token 工厂说明一个真实的审查问题：反复起草和审查可能消耗大量 token，但审阅者仍然看不到从代码修改到原因和检查的清晰证据链。

被要求撰写 PR 的编程智能体可能依赖当前会话，而会话上下文可能被压缩。Tracetoon 转而查看与分支相关的多个会话，重建其中的决定和工作。

Cassandra 将这一想法追溯到一个教育项目：项目需要了解提交程序背后的工作。她把同样的方法用于拉取请求，因为最终 diff 本身不能解释此前的决定或命令上下文。

最初的 Tracetoon 流程研究轨迹、起草描述，并请独立审阅者提出纠正。循环可以补充缺失上下文，但 Cassandra 说修订过程中仍可能引入错误。

他们举例说，一次通过检查的说法没有得到记录顺序的支持：需要依次运行的命令似乎同时运行。流畅的 PR 描述不能证明提交的修改实际经过了测试。

在他们的测试中，仅仅换成更便宜的写作模型降低了质量。讲者因此保留能力更强的写作模型，转而寻找为写作和审查提供更好证据、同时避免反复昂贵搜索的方法。

他们介绍了用 Rust 编写的嵌入式图数据库 Relate。它保存修改、原因和检查之间的关系，使系统能够在智能体起草 PR 之前组装包含来源的关联证据包。

有了这份简报，审阅者可以用同一组证据检查具体说法。团队用较便宜的审阅模型处理更机械的交叉核对，同时保留较强模型负责写作。这是他们在自己任务中认为有效的组合。

生成的示例解释了为何记录工作目录、有哪些例外，以及哪些检查针对提交的内容运行。关键是让每项说法与相关版本的证据相连。

讲者介绍了使用自建 PR Bench 的比较，结合智能体轨迹、代码、模型评判和人工审查。他们报告质量有所提升，token 用量约减半；这些是该项目比较中的结果，并非普遍保证。

他们总结说，来源和关系应保存在单次模型对话之外。Tracetoon 与 Relate 被介绍为让撰写者和审阅者共享可检查 PR 依据的工具。