通过在 Jinja 模板化技能中使用 Jev 来节省 token 和成本

我一直在 Claude Code 会话中测试 Jev/Decision 模型。对于某些任务，如果需要快速遍历大量对象，得到一个简单的非确定性答案，它的表现相当不错。最初想到的做法是让 Opus 把它当作工具来调用，但这基本没什么用。Jev 能在一秒内给出答案，但很难在保持灵活性的同时，避免 Opus 花时间编写每个请求，并把文件读入自己的上下文。因此，这套方案需要满足以下条件：在会话需要请求之前，就将请求写好。文件内容直接传给决策模型，完全不经过 Opus 的上下文。我决定把 Jev 的请求定义放进一个使用 Jinja 模板的 Skill 中，并做了一些基准测试，对比单独使用 Opus 的常规会话、Opus + Haiku，以及通过 Jinja Skill 使用 Opus + Jev。当你有大量条目（文件），需要做出简单的（非确定性）判断，而不是按规则处理时，它能取得相当不错的结果（这类判断无法通过 Opus 在处理确定性任务时常写的临时 Python 脚本来实现）。它节省了 70% 的 Claude 上下文用量和成本，处理速度是单个 Claude 会话中使用 Opus 完成相同工作的 4 到 5 倍（基准测试附在评论中）。它的不足之处是：针对单个小条目的一次性请求。在这种情况下，在运行框架的运行时中启动 Jinja Skill 的开销，可能比直接把条目交给 Haiku 更高。为了在 Claude 运行时中执行使用 Jinja 模板的 Skill，我使用了一个能将其他 Skill 作为 Jinja 模板运行的 Skill（LLAJinja）。