当 AI 编码智能体（AI coding agent）帮你工作时，大部分消耗并非用于思考，而是 I/O。比如为了回答一个方法相关的问题读取五个文件，或是生成与旁边二十个测试文件模式完全相同的测试文件，又或是会议后更新文档。成千上万的 token 被消耗，却几乎没有用到推理能力。真正让人头疼的不是席位许可费用，而是 token 开销，而你还在把所有这些工作都交给能力过剩的前沿模型处理。

AI 编程助手花在我身上的大部分精力不是思考，而是 I/O。

比如为了回答一个方法相关的问题去读五个文件；生成一份和旁边二十份测试文件模式完全一致的测试文件；开会后更新文档。成千上万的 token 就这样消耗掉了，实际推理却几乎为零。真正让人头疼的不是席位许可费，而是 token 成本。而且你还在把所有这些工作都交给能力过剩的前沿模型。如果能把这种体力活交给更便宜、同样能处理好的模型，把昂贵的模型留给真正需要它解决的问题，会怎么样？

这不只是我一个人的问题。到 2028 年，AI 编程成本预计会超过开发者的平均年薪。已经有四分之一的工程负责人每月在每个开发者身上花 200 到 500 美元的 token 费，有些甚至远超 2000 美元。工具本身能带来收益，前提是你别再让前沿模型去处理那些不需要它的工作。

事实证明，解决这个问题不需要平台团队，也不需要新的订阅，只需要两种模式。

两种模式，零代码

这正是 Spotify 的 Portal 中 AiKA Modes 的设计初衷。模式是一种声明式智能体，运行在临时运行时上——可以类比为 AWS Lambda，但是专为智能体设计。你只需要定义指令、选择模型、设置温度等参数，并挂载 MCP 工具，剩下的都由 Portal 处理。不需要管理基础设施、不需要 API 密钥、不需要常驻服务器。模式可以通过 Portal CLI 或 API 调用，可以是公开的（全公司共享），也可以是私有的。

为了让这个路由机制生效，我创建了两个模式。下面的示例中都使用 Gemini 2.5 Flash 作为工作模型，但模型字段支持你在 Portal 实例中配置的任何模型，你可以按需选择。

模式 1：bulk-reader

适用于 Claude 本来要读取多个大文件才能回答一个问题的情况。

``` name: bulk-reader

description: 用于代码分析的大文件批量读取器 - 从 Claude Code 接管 I/O 任务 instructions: 你是一名精准的代码分析员。读取提供的文件，简洁地回答问题。只输出结构化要点，不要问候语、不要散文、不要前言。每个要点以准确的名称、类型或行号开头。细节用嵌套要点呈现。跳过调用者没有询问的内容。

visibility: public

model: gemini-2.5-flash

resourceLimits: temperature: 0.2

tags: - coding - delegation ```

模式 2：code-writer

适用于测试、配置脚手架、类型桩代码，或者任何输出可以根据现有模式预测的场景。

``` name: code-writer

description: 样板代码生成器 - 从 Claude Code 接管输出密集型工作

instructions: 你根据规格说明和参考文件生成代码文件。精确匹配现有的模式、约定、命名和风格。只输出代码——不要解释，除非要求否则不要 markdown 围栏。如果规格说明有歧义，做出符合参考代码模式的合理选择。

visibility: public

model: gemini-2.5-flash

resourceLimits: temperature: 0.2

tags: - coding - delegation ```

“只输出代码”这个指令很重要。如果没有它，模型会把所有内容包裹在 markdown 围栏和解释性文字里，Claude 还得费力去解析。

路由机制

第一版是在 CLAUDE.md 里写了一段路由规则。勉强能用：Claude 会读指令然后自行路由到 Portal。但问题不少。规则只是建议性的，没有强制力，Claude 可以不听。而且每个项目都要单独放一份指令。

现在的版本是一个叫 shunt 的 Claude Code 插件。委托通过 Portal CLI 的操作注册表进行，所以插件可以对接任何启用了 AiKA 插件的 Portal 实例。

第一层：钩子

Claude Code 的钩子会在每次工具调用前触发。Shunt 注册了两个 PreToolUse 钩子：

check-file-size 在每次 Read 调用时触发。如果文件超过可配置的行数阈值（默认 350 行），钩子会阻止读取，并告诉 Claude 改用 /bulk-reader 技能。针对性读取可以正常通过——Claude 已经知道自己需要哪一部分。

check-bash-read 会拦截对大文件执行的 cat、head、tail、less 和 more 命令。管道命令（如 cat file | grep）可以正常通过，因为那些也是针对性读取。

阈值可以通过 SHUNTMINLINES 环境变量配置，在 shell 配置文件或 .claude/settings.json 中设置：

{ "env": { "SHUNT_MIN_LINES": "500" } }

第二层：脚本

我有两个 bash 脚本封装了 Portal CLI 调用。Claude 用命名参数调用脚本，脚本内部处理所有事情：构建请求、调用操作、解析错误，并把 token 使用情况报告到 stderr。

模式通过名称调用，由 Portal 解析：不区分大小写，优先匹配你自己的模式，然后是团队的模式，最后是公开模式。你只要把公开的 bulk-reader fork 成自定义版本，你的版本就会自动优先——不需要额外配置。

bulk-read 把每个文件包裹在 XML 标签中以明确边界，连同问题一起发送给 bulk-reader 模式。

``` bulk-read --question "这个服务是做什么的？" --paths src/Service.java src/Handler.java

追问：用相同的路径再次询问

bulk-read --question "哪些方法调用了数据库？" --paths src/Service.java src/Handler.java ```

每次委托都是一次性调用。调用是临时的（服务端不存储任何内容），追问时重新发送文件在关键地方是零成本的，因为语料库发给了工作模型，从未进入 Claude 的上下文。

code-write 把规格说明和参考文件发送给 code-writer 模式，去除输出中的 markdown 围栏，并可以直接写入磁盘。Claude 永远不会看到生成的代码。参考文件是必需的：如果没有可供匹配模式的文件，工作模型生成的代码就会脱离项目上下文，和任何现有代码都对不上。

``` code-write --spec "为 UserService 编写测试" --reference tests/OrderTest.java --target tests/UserTest.java

输出到标准输出

code-write --spec "生成一个配置桩" --reference config/existing.yaml ```

第三层：技能

两个技能文件告诉 Claude 何时以及如何使用这些脚本。技能是带有描述和使用示例的 markdown 文件。当钩子阻止一次读取时，阻止消息会指向 /bulk-reader 技能，里面给出了准确的调用语法。

这种分层设计让系统可以优雅降级。即使 Claude 没看技能描述，钩子仍然会阻止昂贵的读取。技能只是让重定向更顺畅而已。

基准测试

在一个 Java 单体仓库中测试了四个场景，对比 Claude 直接读取文件消耗的 token，和消耗 bulk-reader 的摘要或通过 code-writer 生成代码消耗的 token。批量读取的平均节省幅度达到了惊人的 90%。

代码生成场景的 token 节省更难量化，因为如果没有 shunt，Claude 既要读取参考文件，又会把生成输出算作昂贵的输出 token。有了 shunt，代码直接写入磁盘，Claude 根本看不到。

哪些场景不适用

不能委托编辑。 工作模型的摘要不包含可靠的行号。如果 Claude 需要根据分析做修改，它仍然必须直接读取具体段落。钩子允许针对性读取（带偏移量和限制），正是为了这个原因，所以委托可以在理解阶段节省 token。

不能委托推理。 工作模型能发现表层模式，但在我的测试里漏掉了一个微妙的线程安全 bug。Claude 在拿到正确上下文后几秒钟就发现了。路由机制明确排除了调试、架构决策和安全关键代码。

延迟会累积。 每次委托都是一次网络往返：Claude Code 到 Portal 后端，再到工作模型，再返回。响应通常需要 10 到 30 秒，Portal 把单次调用上限设为 30 秒，所以非常大的生成任务需要拆成多次小调用。对大文件读取来说可以接受，但对小任务反而得不偿失。行数阈值正是为此存在，低于阈值的任务，委托的开销会超过节省的 token。

Token 节省只是起点

这个插件是 Claude Code 的产物，但底层的思路是由 AiKA 模式驱动的模型路由。模式才是真正承重的部分：

• 可复用。 同样的 bulk-reader 和 code-writer 模式可以在所有项目和所有能调用 Portal CLI 的工具中使用。
• 可共享。 两个模式在 AiKA 中都是公开的，任何人今天就可以直接使用，不需要自己创建。
• 可组合。 你可以创建一个 doc-writer 模式处理文档，一个 reviewer 模式生成代码审查摘要，一个 translator 模式处理国际化。每个都只需要点几下。
• 解耦路由决策和执行者。 插件决定何时委托，模式决定如何响应。把 Gemini Flash 换成更便宜的模型、修改系统提示、添加 MCP 工具——插件都不需要改动。

这才是 AiKA 模式的真正威力：它们把模型路由从系统工程问题变成了配置问题。你不需要构建基础设施，只需要描述你想要什么，然后给它起个名字。

亲自试试

1. 从 spotify/portal-ai-plugins 市场安装两个插件：

   1. claude plugin marketplace add spotify/portal-ai-plugins
   2. claude plugin install portal@portal
   3. claude plugin install shunt@portal portal 插件提供 shunt 委托时使用的 Portal CLI。

2. 在新的 Claude Code 会话中，运行 /portal:setup 来设置 Portal CLI 并针对你的 Portal 实例进行认证。

3. 一切就绪，直接提出一个涉及多个文件的问题即可。

bulk-reader 和 code-writer 模式已经是公开的，所以不需要创建任何东西。如果你想自定义——换工作模型、改指令——在 Portal 里 fork 它们即可，你的版本会自动优先。

这些模式可以在项目间复用，也可以和团队共享。插件会强制执行路由，你不需要操心。了解更多关于模式的信息。

讨论整体偏向质疑该多模型分流方案的实际价值，多数用户认为其既未验证输出质量也未必真正降本，仅少数人认为用轻量模型承担辅助任务属于合理实践。

认为该方案只是常规多模型分工，并无突破性

• 有用户指出用强模型做规划、弱模型做实现是已有的常见架构，这次的方案没有本质创新，只是把既有思路包装成了新概念（较多人）
• 有观点将其类比为模型领域的离岸外包，认为本质是把不同难度的工作分配给不同能力的模型，属于常规操作（较多人） > 这本质上就是模型领域的离岸外包（@tetrisgm）

质疑方案未验证输出质量，降本效果存疑

• 不少用户指出原文仅强调 token 消耗下降，完全没有对比不同方案的实际代码准确率、任务完成质量，缺乏说服力，属于低信息量的内容（高赞）
• 有实践者表示，大模型在规划阶段已经读取了相关文件，若要拆分任务给小模型，还需要大模型额外做任务分配、结果审核，实际未必能节省 token（较多人） > 大模型规划时已经读了相关文件，拆分任务给小模型反而要额外消耗大模型做任务分配和审核，真的能省 token 吗？（@faangguyindia）
• 有用户提到厂商本身有动力让用户消耗更多 token，这类降本方案很难成为主流，除非大模型彻底 commoditize，用户开始真正在意成本，厂商才会针对性优化（较多人）

认同轻量模型可承担辅助任务，但仅限简单场景

• 部分用户认可可以用低能力模型做智能 grep、代码骨架索引等简单辅助工作，但强调复杂编码任务仍需要前沿模型的能力，用轻量模型写代码不可靠（高赞） > 我接受用笨模型当智能 grep 用，但用前沿模型的核心就是靠它们的智能处理编码这类难活（@jnwatson）
• 有用户提到直到特定版本的小模型能力才达到可用门槛，更早的版本做信息过滤、输出格式化时仍会频繁出错，实际落地效果不稳定（少数人）

认为已有更成熟的替代方案

• 有用户指出 CodeGraph 这类 MCP 工具已经能实现代码上下文索引、按需读取的需求，不需要额外引入第三方 API 和成本（较多人） > 这类需求不是已经被 CodeGraph 这类 MCP 解决了吗，还不用额外接第三方 API 增加成本（@fbn79）
• 另有用户提到可以结合 ripgrep 和 treesitter 给模型提供代码骨架索引，让模型按需读取目标代码块，同样是有效的 token 节省方案（少数人）

反感网站篡改滚动行为

• 多条评论集中吐槽相关网站强行劫持滚动操作，认为这是非常糟糕的用户体验，不理解浏览器为何允许这类行为，甚至调侃官方 Spotify 产出这类内容很离谱（高赞） > 天呐，连 Spotify 都不在乎发这种 AI 灌水的文章了，真的没救了（@avazhi）

有价值的补充

• 有用户调侃自己通过手写代码实现了 Claude Code token 用量 100% 的削减，讽刺模型编码未必比人工更高效
• 有观点提到当前这类降本方案效果参差不齐，核心原因是模型没有针对这类工具链做强化学习微调，和默认工具集的适配度不足