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 帮你重构一个核心模块典型的探索流程是这样的定位目标文件读取内容找出所有 import 了它的文件递归追踪调用链可能涉及 20 到 50 个文件读取相关类型定义、配置文件、测试文件汇总成一份改动影响面报告这一套下来塞进上下文的原始代码轻松超过 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 parseExpressionOtoto 会做这几件事读取目标文件提取parseExpression的签名扫描全项目找出所有引用该符号的位置对每个引用点向上追溯一层调用方收集相关类型定义和测试文件生成结构化简报缓存结果输出的简报大概是这样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 探索结果不准怎么办最常见的抱怨是小模型漏掉了某些引用。排查顺序先确认 ignore 配置是不是把相关目录排除了检查动态引用字符串拼接、反射调用这类静态探索天然抓不到需要人工补充看 maxDepth间接依赖超过深度限制会被截断验证小模型能力换一个稍大的模型试试如果结果变准说明是模型能力问题我的经验动态引用是静态探索的天敌。Ototo 会标记 risk flags但最终还得靠人判断。别完全信任自动化结果。5.2 缓存导致结果过期症状是明明改了代码探索结果还是旧的。原因通常是缓存失效策略没配好。解决确认缓存基于内容哈希手动清缓存ototo cache clear检查是否有文件监听没生效5.3 小模型响应慢或超时小模型不一定都快尤其是本地部署在资源受限的机器上。排查现象可能原因解决首次调用慢模型加载预热或常驻进程批量探索慢并发不足调高并发数频繁超时单次输入太大降低 maxFiles内存飙升上下文累积分批处理5.4 简报太长没省下 token这是卸载失败的典型症状。如果小模型输出的简报跟原始代码差不多长那这次卸载就是负收益。优化方向让简报只保留签名和位置不保留函数体用结构化格式JSON/YAML而非自然语言对重复模式做去重我个人的判断标准是简报长度应该控制在原始相关代码的 10% 以内。超过这个比例就得回头优化压缩逻辑。6. 这套思路还能怎么扩展Ototo 解决的是代码探索这一个环节但这套大小模型协同的架构可以复制到很多地方。我自己试过几个变体测试生成小模型负责找出需要测试的分支大模型负责写测试用例文档同步小模型扫描代码变更大模型生成文档更新代码审查预筛小模型先过一遍 diff标记可疑点大模型重点审核心逻辑都一样把信息收集和决策判断分开让便宜的干粗活让贵的干细活。这个思路在成本敏感的场景下几乎是必然选择。最后分享一个我踩过的坑一开始我图省事让小模型直接输出自然语言描述结果大模型消费起来经常误解。后来改成严格的结构化格式问题就没了。接口格式的严谨程度直接决定这套流水线能不能稳定跑起来。如果你也在搭类似的系统这一点务必重视。