Spotify 的 Portal 让我 Claude Code 的 token 使用量减少了 90%

原文 ↗ Hacker News 讨论 ↗

Spotify 的工程博客介绍了“Portal”，一个把代码搜索和样板代码生成路由到更便宜语言模型的系统，用来减少 Claude Code 的 token 使用——号称文件读取 token 最多可节省 90%——同时把更昂贵的模型留给更困难的推理。评论者指出，这本质上就是标准的多模型编排或 subagent 用法，Claude Code、GitHub Copilot、Cursor 等工具里早已存在，并质疑输入 token 的减少是否真能在没有准确率基准的情况下转化为实际成本或质量收益。很多人怀疑把有意义的编码工作委派给更弱的模型是否合理，同时也批评这篇文章像是 AI 生成的营销废话，发布在一个会劫持滚动的页面上。

多模型委派概念

  • Portal / “shunt” 被理解为把大量文件读取和部分代码编写委派给更便宜的模型，然后把摘要或文件范围交给 Claude。
  • 一些评论者表示，这本质上就是标准的 subagent / 多模型模式，并不是什么新想法。
  • 也有人把它比作“LLM Bloom filter”：便宜模型先缩小要读取的文件/行范围；昂贵模型再对这部分内容进行真正的推理。

有效性、准确性与成本取舍

  • 很多人持怀疑态度，因为这篇文章强调的是 token 节省，而不是正确性或任务成功率。
  • 提到的一个测试是：worker 模型漏掉了一个微妙的线程安全 bug，而在得到合适上下文后，Claude 抓到了它，这说明存在质量风险。
  • 批评者指出：
    • 仅按模型大小路由，并不对应代码复杂度。
    • 输入 token 更便宜；大多数成本来自输出和重跑。
    • 节省 90% 的读取 token，并不等于总成本减少 90%。
  • 也有人报告，通过把大型规划器与较小执行器结合，确实能在真实工作中节省不少费用，但他们强调衡量的是美元，而不是 token。

现有工具与替代方法

  • 已经有多个工具在做类似的上下文压缩：Claude Code 内置的“explore”/subagents、GitHub Copilot、Cursor、OpenCode 等。
  • 其他方法包括：repo maps、基于 treesitter 的索引、代码图，以及 Repoprompt、Aider 和类似的“smart grep”或 repo-index 工具。
  • 有人分享了一个 Cursor 专用的“shunt”，不依赖外部 API，作为更轻量的替代方案。

工作流技巧与 subagent 配置

  • 一些人描述了“stage-gated”或多阶段工作流：用大模型做规划/策略，用便宜模型做侦察/总结，然后再用大模型做最终审查。
  • 建议包括：
    • 约束便宜模型只定位文件/行范围，不做决策。
    • 在 agent profiles / developer instructions 中编码 subagent 的使用和模型选择。
    • 专门用更便宜的模型来查找相关代码引用，而不是用于核心设计。

对文章和网站的批评

  • 对网站的 scrolljacking 和强烈的平滑滚动反弹很大；有些读者甚至没读完就离开了。
  • 很多人觉得文章本身就是“AI slop”：过长，充满典型的“AI-isms”和营销式语气。
  • 也有人质疑，为什么这样一个很基础的想法值得写成一篇冗长、难读的“thought leadership”文章。

关于 AI 编码和 Spotify 的更广泛看法

  • 对把严肃编码工作委派给更弱或更老模型的看法不一；有人认为这是小钱省了、大钱亏了。
  • 也有人对使用更新的廉价模型进行成本优化很兴奋，尤其是那些表现接近高级模型的模型。
  • 一个反复出现的笑话是：通过手写代码或使用本地模型，把 Claude 的 token 使用量减少 100%。
  • 还有不少评论者把这和对 Spotify 产品质量、AI 使用方式以及商业激励的不满联系起来。