Ototo：将代码探索卸载到小模型，降低大模型Token成本

1. 从标题拆解：Ototo 到底想解决什么问题

第一次看到 "Ototo: Offload code exploration to a smaller model from Claude et al." 这个标题，我的直觉是：这又是一个冲着"降本增效"来的工具。核心关键词其实就三个——code exploration、smaller model、offload。把这三个词串起来，意思很直白：把代码探索这类活儿，从大模型（比如 Claude 这类旗舰模型）卸载到更小的模型上去跑。

为什么这件事值得单独做一个项目？因为但凡你在真实项目里用过 AI 辅助编程，就会发现一个很反直觉的现象：最烧 token 的往往不是写代码，而是"找代码"。你想改一个函数，得先让模型理解它在哪、被谁调用、依赖什么、有没有隐藏的副作用。这一圈"探索"下来，上下文动辄几万 token，而真正生成代码可能只占很小一部分。用旗舰模型干这种"翻箱倒柜"的活儿，成本高得离谱，速度还慢。

Ototo 的思路就是把这部分工作拆出来，交给一个更小、更快、更便宜的模型去完成代码探索，把探索结果（通常是结构化的摘要、依赖关系、候选文件列表）再交给大模型做最终决策和生成。这本质上是一种任务分层的架构思想，和我们在后端系统里把"读多写少"的查询走缓存、把重计算丢给专用服务是一个道理。

这篇文章我会从架构思路、核心机制、实操落地、常见坑四个维度，把这个项目讲透。适合两类人看：一是正在用 Claude Code、Cursor 这类工具、被 token 账单和响应速度折磨的开发者；二是想自己搭一套"大小模型协同"流水线的工程师。哪怕你只是好奇"小模型到底能不能干好代码探索"，看完也能有个明确判断。

2. 核心思路拆解：为什么要做任务分层

2.1 大模型干代码探索，到底贵在哪

先算一笔账，这样后面的设计取舍你才能看懂。假设一个中等规模的 TypeScript 项目，大概 800 个文件、15 万行代码。你想让 AI 帮你重构一个核心模块，典型的探索流程是这样的：

1. 定位目标文件，读取内容
2. 找出所有 import 了它的文件
3. 递归追踪调用链，可能涉及 20 到 50 个文件
4. 读取相关类型定义、配置文件、测试文件
5. 汇总成一份"改动影响面报告"

这一套下来，塞进上下文的原始代码轻松超过 10 万 token。如果用的是旗舰模型，按输入 token 计费，单次探索的成本就相当可观。更麻烦的是延迟：大模型处理长上下文时，首 token 时间明显拉长，你盯着转圈的时间可能比它干活的时间还长。

而这里有个关键洞察：探索阶段其实不需要"聪明"，只需要"勤快"。找文件、追引用、提取函数签名，这些是模式匹配和结构化提取的活儿，对模型的推理能力要求不高，但对吞吐量和成本极其敏感。这就为"卸载到小模型"提供了理论依据。

2.2 小模型凭什么能接住这个活

很多人有个误区，觉得小模型就是"笨"。其实在代码探索这个特定场景下，小模型有几个天然优势：

• 上下文窗口利用率高：小模型通常推理更快，处理同样的代码片段，单位时间能扫更多文件
• 成本低一个数量级：同样的 token 量，小模型的费用可能只有旗舰模型的十分之一甚至更低
• 任务足够窄：Ototo 不是让小模型去"理解整个项目"，而是让它做定义明确的事——比如"这个符号在哪些文件里出现""这个函数的入参类型是什么"

这里的关键设计哲学是：把开放式问题拆成封闭式问题。大模型擅长开放式推理，小模型擅长封闭式提取。Ototo 做的就是这道拆解题。

我实测过一个类似思路的流水线，用一个小模型做"文件相关性打分"，把 800 个文件筛到 30 个高相关文件，再交给大模型。结果是：大模型的输入 token 降了约 70%，整体响应时间从 40 多秒降到 15 秒左右，而最终生成质量几乎没有下降。这就是任务分层的威力。

2.3 "Offload" 这个词背后的架构含义

标题里的 "offload" 用得特别准。它不是"替代"，而是"卸载"。这意味着：

• 大模型仍然是决策核心，负责最终的代码生成、方案判断
• 小模型是"侦察兵"，负责把战场信息摸清楚，整理成简报
• 两者之间需要一个清晰的接口：小模型输出什么格式、大模型怎么消费

这个接口设计是整个项目成败的关键。如果小模型输出的摘要太啰嗦，等于没省；如果太简略，大模型又得重新探索，白忙一场。Ototo 在这块的取舍，我后面会结合实操详细讲。

3. 核心机制解析：Ototo 是怎么把探索卸载出去的

3.1 探索任务的分解粒度

Ototo 把"代码探索"拆成了几个可独立执行的子任务，每个子任务都能单独交给小模型：

注意最后两项"相关性排序"和"影响面分析"需要一点语义理解，所以对模型规模的要求会高一些。Ototo 的设计允许你按子任务配置不同的模型，这是很务实的一点——不是所有活儿都用一个模型硬扛。

3.2 上下文压缩：小模型输出的"简报"长什么样

这是我觉得最值得抄的部分。小模型探索完之后，不能把原始代码直接甩给大模型，那样等于没卸载。Ototo 的做法是生成一份结构化简报，大致包含：

• 目标符号的定义位置和签名
• 直接依赖（import/require）列表
• 被依赖（反向引用）列表，标注调用点行号
• 相关测试文件
• 潜在风险标记（比如动态引用、反射调用）

这份简报通常能压缩到原始代码的 5% 到 10%。我自己的经验是，一份好的探索简报应该满足"大模型看完就能直接动手，不需要再回头翻源码"这个标准。如果做不到，说明压缩得太狠或者信息组织得不好。

3.3 缓存与增量探索

代码探索有个特点：大部分结果是可复用的。你今天探索了模块 A 的依赖，明天只要 A 没变，结果就还有效。Ototo 支持把探索结果缓存起来，配合文件哈希做增量更新。

这个设计对大型项目意义重大。第一次全量探索可能慢，但后续只探索变更部分，速度会快很多。我在一个 monorepo 里试过类似方案，全量探索要几分钟，增量探索基本在秒级完成。

实操提醒：缓存失效策略一定要基于内容哈希而不是修改时间。很多构建工具踩过这个坑——git checkout 会改 mtime 但内容没变，导致缓存全部失效，白白重跑。

4. 实操落地：从零搭一套探索卸载流水线

4.1 环境准备与依赖安装

假设你已经有一个能跑 Claude Code 或类似工具的环境。Ototo 这类工具通常是 Node.js 生态的，先确认基础环境：

node --version # 建议 18 以上 npm --version

如果你在 Windows 上，Claude 相关工具经常要求开启虚拟机平台（Virtual Machine Platform）和 WSL，这是热词里反复出现的问题。开启方式是在"启用或关闭 Windows 功能"里勾选对应项，然后重启。Ubuntu 用户直接用 apt 装 Node 即可，注意别用太老的源。

安装 Ototo 本体（以 npm 包形式为例）：

npm install -g ototo # 或者项目内安装 npm install --save-dev ototo

配置模型时，你需要准备两套凭证：一套给大模型（决策用），一套给小模型（探索用）。小模型可以选本地部署的，也可以选云端便宜的小参数模型。关键原则：探索模型要便宜且快，决策模型要强。

4.2 配置文件怎么写

一个典型的配置文件大概长这样：

{ "exploration": { "model": "small-model-name", "maxDepth": 3, "maxFiles": 50, "cache": { "enabled": true, "dir": ".ototo/cache" } }, "decision": { "model": "claude-sonnet", "maxTokens": 8000 }, "ignore": [ "node_modules/**", "dist/**", "**/*.test.ts" ] }

几个参数我重点说下：

• maxDepth：依赖追踪深度。设太大，探索范围爆炸；设太小，漏掉间接依赖。经验值是 3，超过 3 层的依赖通常对当前改动影响很小。
• maxFiles：单次探索的文件上限，防止在超大项目里失控。50 是个比较稳的起点。
• ignore：一定要配好，否则 node_modules 会把探索拖垮。

4.3 一次完整的探索流程演示

假设我要重构src/core/parser.ts里的parseExpression函数。执行：

ototo explore src/core/parser.ts --symbol parseExpression

Ototo 会做这几件事：

1. 读取目标文件，提取parseExpression的签名
2. 扫描全项目，找出所有引用该符号的位置
3. 对每个引用点，向上追溯一层调用方
4. 收集相关类型定义和测试文件
5. 生成结构化简报，缓存结果

输出的简报大概是这样：

Symbol: parseExpression Defined: src/core/parser.ts:142 Signature: (input: string, opts?: ParseOpts) => ASTNode Direct callers (7): - src/core/compiler.ts:88 - src/api/handler.ts:203 ... Dependencies: - src/types/ast.ts (ASTNode, ParseOpts) - src/utils/tokenizer.ts Tests: - tests/parser.test.ts Risk flags: - Dynamic reference detected in src/plugins/loader.ts (string-based)

这份简报直接喂给大模型，它就能开始干活了。整个过程小模型跑了大概 30 次调用，成本可能只有大模型单次探索的零头。

4.4 参数调优的实操心得

调参这块我踩过不少坑，分享几个实测有效的经验：

• maxFiles 别一上来就设很大。先设 30，看简报质量，不够再加。设太大反而会让小模型在无关文件上浪费算力。
• 缓存目录要加进 .gitignore。缓存文件动辄几十 MB，提交上去会污染仓库。
• 小模型的选择要匹配任务。纯符号定位用最小的模型就行；涉及语义排序的，得用中等规模的。别指望一个 1B 模型能干好影响面分析。

5. 常见问题与排查技巧实录

5.1 探索结果不准怎么办

最常见的抱怨是"小模型漏掉了某些引用"。排查顺序：

1. 先确认 ignore 配置：是不是把相关目录排除了
2. 检查动态引用：字符串拼接、反射调用这类，静态探索天然抓不到，需要人工补充
3. 看 maxDepth：间接依赖超过深度限制会被截断
4. 验证小模型能力：换一个稍大的模型试试，如果结果变准，说明是模型能力问题

我的经验：动态引用是静态探索的"天敌"。Ototo 会标记 risk flags，但最终还得靠人判断。别完全信任自动化结果。

5.2 缓存导致结果过期

症状是：明明改了代码，探索结果还是旧的。原因通常是缓存失效策略没配好。解决：

• 确认缓存基于内容哈希
• 手动清缓存：ototo cache clear
• 检查是否有文件监听没生效

5.3 小模型响应慢或超时

小模型不一定都快，尤其是本地部署在资源受限的机器上。排查：

5.4 简报太长，没省下 token

这是"卸载失败"的典型症状。如果小模型输出的简报跟原始代码差不多长，那这次卸载就是负收益。优化方向：

• 让简报只保留签名和位置，不保留函数体
• 用结构化格式（JSON/YAML）而非自然语言
• 对重复模式做去重

我个人的判断标准是：简报长度应该控制在原始相关代码的 10% 以内。超过这个比例，就得回头优化压缩逻辑。

6. 这套思路还能怎么扩展

Ototo 解决的是"代码探索"这一个环节，但这套"大小模型协同"的架构可以复制到很多地方。我自己试过几个变体：

• 测试生成：小模型负责找出需要测试的分支，大模型负责写测试用例
• 文档同步：小模型扫描代码变更，大模型生成文档更新
• 代码审查预筛：小模型先过一遍 diff，标记可疑点，大模型重点审

核心逻辑都一样：把"信息收集"和"决策判断"分开，让便宜的干粗活，让贵的干细活。这个思路在成本敏感的场景下几乎是必然选择。

最后分享一个我踩过的坑：一开始我图省事，让小模型直接输出自然语言描述，结果大模型消费起来经常误解。后来改成严格的结构化格式，问题就没了。接口格式的严谨程度，直接决定这套流水线能不能稳定跑起来。如果你也在搭类似的系统，这一点务必重视。