一个开源作者亲手推翻自己的91.5%数据|context|token|上下文|代码|用例|编程|自然语言

上周还在README上挂着"省91.5% token"的亮眼数字，一周后作者自己把数字改成了88%，还写了篇长文解释为什么之前的算法"在技术上成立，在实际上错误"。这种自我纠错在benchmark乱象里反而更值得看。

那个数字是怎么来的

context-router的作者在v4.4.3版本发布时，README写着"比code-review-graph少91.5% token"。这个数字来自两组独立运行的测试：context-router跑在gin、actix-web、django、gson、requests、zod六个仓库上，code-review-graph跑在另一批仓库上，然后取平均值相除。

问题很明显：两个工具面对的代码库不同、任务不同、输入不同。context-router可能恰好跑在结构简单的仓库，code-review-graph可能恰好遇到需要输出更多样板代码的场景。91.5%这个百分比，粘合的是两个完全不可比的测量结果。

有人指出了这一点。作者承认错误，撤下了声明，用v4.4.4重新跑了一套测试。

workload-matching：公平比较的底线

新测试的核心规则只有一句话：两个工具必须看到相同的提交哈希（SHA）和相同的代码差异（diff）。

具体执行上，作者选了kubernetes仓库的三个单文件bug修复提交：kubelet/status_manager、client-go/clientcmd loader、kube-proxy/winkernel proxier。这些SHA被固定在benchmark/holdout/kubernetes/tasks.yaml里，任何人都可以复现。

每个测试用例的输入完全一致：父提交状态的代码树，加上父提交到修复提交的diff。两个工具都不能在工作目录里"偷看"答案。

context-router的执行命令：pack --mode review --pre-fix

code-review-graph的执行命令：detect-changes --base ^

两者消费的diff都是git diff ^..，字节级相同。

然后记录：每个工具的前3预测里有没有命中最终修改的文件、第1名预测是什么、输出了多少token。

修正后的数字与更诚实的细节

新结果：token减少88.3%，3个测试用例中2个命中第1名，code-review-graph则是0/3。

作者特意强调这是"我会为之辩护的数字"——不是因为它更好看，而是因为测试设计经得起质疑。88.3%比91.5%低，但建立在可比的基础上。

几个值得注意的细节：测试集只有3个提交，规模很小；全部来自kubernetes，场景单一；都是单文件修复，复杂度有限。作者没有回避这些局限，反而主动列出。这种诚实比数字本身更少见。

context-router到底在解决什么问题

这个工具的定位很具体：帮AI编程代理（AI coding agents）找到"最小有效上下文"。

用法是：指向代码仓库，指定任务类型（review审查/debug调试/implement实现/handover交接），返回一个按优先级排序的文件和代码片段包，大小控制在token预算内。