代码地图能否省钱？十次任务回放未见成效

给 AI 编程助手配一张代码地图，能不能省钱、提速？Trail-code 的 README 宣称成本降低 32%、耗时减少 60%，作者却在自己的仓库里得到了不同结果：用 Opus 5.5 重做 10 个已合并 PR，地图几乎没被使用，两种接入方式都没证明收益。

这次测试更有价值的部分，是一套可以复用的评估方法：拿真实任务回放，盲审交付质量，再测模型自身的成本波动。对正在给 Claude Code 加 MCP、加 hooks 的团队来说，它回答了一个实际问题：账单便宜了一点，到底是不是工具的功劳？

地图建好了，Agent 为什么不查

Trail-code 原名 graft，面向 Claude Code、Cursor 和 Codex，包含代码地图和 Learnings 两部分。

代码地图用 tree-sitter 解析仓库，把文件、函数和调用关系组织成图，让 Agent 可以查询「代码在哪里」「谁调用了这个函数」。建图不需要模型，也不访问网络。作者的 Seed 仓库有 885 个文件，处理耗时约 23 秒。

Learnings 则让 Agent 把对话中获得的经验写进仓库，供后续会话使用。作者没有测试它：他们团队要求，决策必须经作者批准才能进入书面规则，Agent 自行保存笔记不符合现有流程。因此，这次结果只能评价代码地图，不能代表 Trail-code 的全部能力。

第一轮测试采用「pull」模式：把地图作为 MCP 工具交给 Agent，由它主动调用，包括 trail_find_code 和 trail_trace_calls。作者还在任务说明里明确加了一句：先用地图，再用 grep。

结果是，10 个任务总共只有 7 次地图调用，其余查找依然通过 Bash 执行 grep、sed。工具可用了，提示也给了，Agent 仍沿用原来的工作方式。

这不一定说明地图没有价值。对已经能熟练搜索仓库的模型，新增查询工具要先证明自己比现有路径方便。作者使用 Opus 5.5，仓库还有详细的 AGENTS.md；定位文件可能原本就不是主要开销。

自动推送代码，为什么大多没有推到

Trail-code 自己的基准测试中，「push」模式收益更大：不等 Agent 查询，工具直接把匹配代码送进上下文。

在 Claude Code 中，这依赖会话启动、每次输入以及每次编辑后运行的 hooks，再配合一个要求使用 trail 的 skill。作者从真实的 trail init 提取配置，通过每轮独立的 settings 文件加载。第二轮任务说明不再额外提醒使用地图，考察的是产品自身能否完成接入。

这一轮，Agent 的地图调用次数是 0。但主动调用为零，还不能判断自动推送是否生效，作者继续检查了 hooks 实际发送的内容：

• 会话启动时，发送约 3 KB 的 trail 使用说明。
• 收到任务说明时，10 个任务中有 8 个返回「no strong match for this prompt」。
• 编辑和搜索之后，没有发送内容。

问题落在匹配环节。作者手动提交一条重构任务的原始 issue，即使其中写出了准确文件名和常量名，依然没有匹配。再试 7 条简短问题，只有 2 条返回正确文件。

「Where is the IPv6 sign-up rate limit?」能够命中；「Which file defines JOB_AGGREGATE_ID?」却没有结果。

作者据此判断，匹配机制更适合短聊天输入，难以适配他们使用的完整 issue 任务说明。这是有测试支持的观察，但原文没有解释匹配算法，也没有提供更多仓库的验证结果，不能扩展成「长输入一定匹配失败」。

对使用者更直接的提醒是：安装成功、hook 执行成功、代码真正进入上下文，是三件需要分别确认的事。

成本降了 10.5%，为什么仍不能算赢

作者没有比较安装工具前后的两周账单，因为每周任务不同，成本差异很难归因。

他从 SaaS starter 项目 Seed 中挑出 10 个已合并 PR，覆盖认证、计费、重构、基础设施、缓存、结构化数据和测试。每个任务都从 PR 之前的提交创建全新浅克隆，只保留一层提交历史，避免答案藏在 Git 历史里。

Opus 5.5 根据原始 issue 实现需求，有地图和无地图的运行并行进行，以尽量保持机器负载条件一致。独立 reviewer 在干净副本上盲审，结果用随机字母标记，并以已合并 PR 为参考答案。作者事后还检查所有工具调用，确认 Agent 没有偷看真实仓库或真实 PR。

结果需要连着质量一起看：

模式	可比任务数	总成本变化	其他结果
pull	9	降低 3.9%	单任务从便宜 18% 到贵 26%
push	10	降低 10.5%	耗时减少 8%，通过数从 8/10 降至 6/10

pull 少算一个认证任务，是因为无地图组认为必须先发布共享库新版本，于是停止；有地图组查到相关选项已经发布，完成了任务。但作者检查后发现，它的那次地图调用与这个判断无关，不能把成功归功于地图。

push 中真正收到代码的两个任务，一个贵了 11%，另一个便宜了 15%，也没有呈现一致方向。

关键还在于重复运行的波动。作者对前 4 个任务重复执行基线，其中两次都完成的 3 个任务，成本相差 7%–12%。两轮对比中，任务间成本变化的离散程度都约为 13%。

模型自己就会产生的成本波动，必须先于工具收益测量。

作者给出的任务数估算式如下，用于按噪声和预期节省幅度规划样本量：

n = ⌈(2.8 × noise ÷ saving)² + 2⌉, never below 3.

要留意 noise ÷ saving：噪声越大、希望识别的收益越小，需要的任务越多。原文给定的条件是 95% confidence 和 80% power，任务数最低为 3。

按作者的估算，约 13% 的噪声配合 10 个任务，只能识别约 13% 或更大的节省。3.9% 和 10.5% 都不足以证明收益，更何况 push 的审查通过率还下降了。

我的判断

这篇最扎实的结论是：在作者这套工作流中，地图利用率很低，测得的成本下降不足以证明工具有效。作者没有把账单上的每一点改善都算成工具贡献，这种克制值得保留。

但「8 个任务没收到代码，所以节省不可能来自工具」仍说得偏满。启动时约 3 KB 的说明也是上下文输入，可能影响行为，只是原文没有证明这种影响。更准确的表达应当是：现有记录无法把节省归因于代码地图。

同样，13% 不能当成通用门槛。重复基线中，真正可比较的只有 3 个任务；任务间收益差异也未必全是随机噪声，可能包含不同任务对地图的需求差异。公式适合帮助规划测试，原文并未给出完整统计推导。

厂商结果与作者结果也并非同一道题。厂商用 Sonnet 5 回答代码问题，作者用 Opus 5.5 完成实现、测试和检查；厂商从缺少仓库上下文的状态开始，作者有详细 AGENTS.md；短问题和完整 issue 的匹配条件又不同。

因此，这不是 grep 全面胜过代码地图的证据。更像是一次提醒：如果现有搜索已经够便宜，优化导航的收益就可能很有限。至于陌生大型仓库、Cursor 短问答是否更受益，作者只是提出可能，尚无这次实验的对照数据支持。

能拿来做什么

• 给 Claude Code 增加检索 MCP 或 hooks 前，先选一组已合并 PR，从修改前的提交回放；前端、Node 仓库都可以沿用这套方法，并覆盖不同任务类型。
• 验证工具时，同时记录调用次数、hook 匹配结果和实际注入内容。尤其要拿团队日常使用的完整 issue 测试，不能只看简短演示问题。
• 先重复运行无工具基线，再判断节省幅度，并把盲审通过率与成本一起记录。作者完成 34 次实现运行、33 次盲审，按 API 标价约花费 $101，这可以作为一次评估的投入参考。
• 如果 Agent 已经能依靠 AGENTS.md 和 grep 快速定位，就先确认定位是否占据主要成本，再决定是否引入地图；如果主要耗时在实现、测试和返工，地图未必解决当前最贵的问题。