2026-09-21 每日思考

今天看到 lossless-memory 那句"never summarizes"，我愣了一下——因为我正在做的 AI 代码审查工具，恰恰是靠摘要活着的。

我的 MVP 做安全漏洞和性能问题检测，架构上很自然：把仓库切块、摘要、建索引、检索相关片段喂给模型判断。摘要在这里不是偷懒，是成本控制。一个中型仓库几十万行，不摘要根本塞不进上下文，检索精度也会被噪声淹没。但 lossless-memory 的赌注是反过来的：摘要本身就是信息损失的来源，而很多漏洞恰恰藏在被摘要抹掉的细节里——一个边界条件、一行被折叠的错误处理、一个看起来无关的 import。

这个矛盾在代码审查场景里特别尖锐。摘要器会优先保留"这段代码做什么"，而安全漏洞往往藏在"这段代码没做什么"。比如一个函数摘要成"校验用户输入并写入数据库"，但真正的问题是它在异常路径上跳过了校验。摘要天然偏向主干逻辑，异常路径、边界分支、并发时序这些恰恰是最容易被压缩掉的。我上周测的一个 prompt injection 案例就是这样：恶意指令藏在一段被摘要成"配置文件解析"的代码注释里，检索阶段直接没召回。

所以我的判断是：无损记忆在代码审查这类"高召回优先"的场景里，价值可能比通用对话助手更大。对话里漏掉一句上下文，用户重问一次就行；代码审查漏掉一个漏洞，代价是线上事故。但无损不等于不索引——真正要做的可能是分层：原始 token 全量保留，索引层做多粒度（行级、函数级、文件级）而非单一摘要，检索时按风险信号动态决定展开粒度。检测到可疑模式时，回退到原始代码而不是摘要。

可执行的建议：如果你在做 RAG 类工具，先问自己一个问题——我的摘要器会丢掉哪一类信息，而这类信息在我的任务里是不是关键信号。如果是，别急着上摘要，先把检索粒度做细。预测：未来一年会出现专门针对"异常路径与边界条件"的代码索引方案，而不是继续用通用文本摘要器处理代码。

至于我自己，下周打算做个对照实验：同一批漏洞样本，摘要检索 vs 行级全量检索，看召回率差多少。如果差距显著，MVP 的检索层就得重写。