《Loop Engineering + Jev Engineering：降低你的 Claude 账单》

一、标题与来源信息

二、一句话总结与核心观点

• 省钱的关键在“入口”而非“执行”：很多 token 花在“检查空队列、重读没变的 issue、纠结要不要重试”上，应先找到这些重复付费的决策点。
• 分层过滤：先用 ID/时间戳等廉价手段判断“有没有变化”，没变化就直接结束；有变化再进入语义过滤；最后才启动 Claude。分类器本身也有成本，所以顺序很重要。
• 类型化答案可被代码路由：Jev 返回的不是自由文本，而是 Choice（选项 + 概率分布）、Noul（是/否概率）、Score（有序等级）三类结构化结果，应用代码据此决定走哪条路。
• 置信度阈值要靠自己的数据定：示例中的 0.9 只是起点，应用 30–50 条人工标注的历史样本评估，并先以“影子模式”运行。
• Claude 运行必须“有边界”：任务去重、认领、限定权限与交付物、重试次数与花费上限都由启动它的 worker 控制，而不是由 issue 内容决定。
• 分类器只是附加检查：命令安全分类可以辅助 PreToolUse hook，但凭据访问、破坏性操作等边界仍须靠可强制执行的规则和系统级隔离。
• “完成”需要证据：事先写好验收记录（GOAL.md），精确条件用代码检查，语义上是否满足需求再交给 Jev，并用计数器防止无限续跑。
• 算清决策预算：按文档价，决策请求每月约 3 美元量级；但真正该追踪的是“每个被接受并完成的任务的总成本”。
• 状态要精简、结果要可恢复：只给模型与问题相关的信息，数值/日期计算交给代码；每次决策留一条紧凑记录，出错时保留状态、显式决定是否重试。

三、分章节中文解读

导语。作者开篇指出：Claude 自动化常常把 token 浪费在非生产性的“判断”上。如果把这些判断放到一条独立的路径上，就能精确控制“什么会触发一次运行、什么会让运行继续”。Jev 为这条路径提供了一个构件——可被代码路由的类型化答案：Claude 负责实现，应用程序负责决定哪些任务能到达 Claude。文章承诺读者最终能得到一个可运行的 issue 过滤器、一套评估其错误的方法，以及将其扩展到工具检查和完成检查的设计思路。

第 1 章　找出你一直在重复付费的决策（Find the decisions you keep paying for）

核心思想：先做“决策盘点”。拿一次最近的自动化运行记录，观察在真正有产出的动作之间，Agent 反复在问哪些问题。例如队列监视器可能一遍遍判断“这份新报告的信息够不够展开调查”。

适合剥离的候选决策包括：对新 issue 分类；从固定列表中选择处理器；检查输出是否回应了书面需求；判断新证据是否值得再跑一次 Agent。对每一个问题，记录它出现的频率以及回答它需要哪些信息——这份清单就是 loop engineering 的起点。

依据：作者引用 Anthropic 的 Claude Code 成本管理文档：官方本就建议把合适的处理移到 hooks 中、把冗长操作挪出主对话，并解释了上下文增长会导致整个会话处理的 token 数上升。

落地顺序：以 issue 监视器为例——① 先用标识符和时间戳判断是否有变化，没变化就由普通代码立即结束；② 有新 issue 才送入语义过滤器；③ 只有被接受的任务才带着相关报告和明确的期望结果交给编码 Agent。作者强调顺序的原因：分类器本身也消耗资源，因此只把“需要理解含义”的判断交给它，精确比较和计数仍留在代码里。

第 2 章　Jev 实际返回什么（What Jev actually returns）

Jev 是什么：作者介绍 Jev 是 TypeSafe AI 推出的“决策模型”。调用方式是发送一个状态（state）（如一份 issue 报告）以及若干定义了答案格式的问题。文中引用了 TypeSafe 方面人士 Diogo Almeida 的发布推文，其中宣称 Jev 比常规模型“快 20–200 倍、便宜 40–400 倍（输出 token 免费）”，并定位为“为决策优化的可组合智能”（此为厂商宣传，见第六部分）。

三种问题类型：

定价与限制（据作者引用的文档）：当前文档中的模型为 jev-1.13.0，输入每百万 token 0.042 美元，输出免费；请求可以是文本或结构化文本数据；整体请求上限 64,000 token，“状态 + 最长的那个问题”上限 32,000 token。

设计要点：每个类别都要写清楚“什么属于这里”的描述；设置一个 other（其他） 选项，为意料之外的内容留出显式出口；问题的 key 只是响应标识符，模型真正理解的是指令与判据，因此像 safe 这样的 key 必须配上对所评估条件的实际描述。

第一个实验的选择：挑一个结果“看得见”的路由决策。issue 分类最容易检查——你可以自己读报告，判断建议的路由是否合理。

第 3 章　构建一个可检查的过滤器（Build a filter you can inspect）

环境准备：在本地工作目录使用 Python 3，在已有虚拟环境中安装官方 SDK，并在 TypeSafe 控制台创建 API Key，通过环境变量提供（官方客户端会自动读取）。密钥不要写进 issue 文件或提交到版本库。

python -m pip install typesafe-sdk
export TYPESAFE_API_KEY="your-key"   # 换成你自己的密钥，仅本地设置

说明：第一行安装 SDK；第二行在 Bash（macOS / Linux / WSL）中设置密钥环境变量。

示例数据：作者准备了一份虚构的 issue.json，内容是“项目名含重音字符（如 Café）时导出失败，报 UnicodeEncodeError 并生成空文件”，同时写明了复现步骤和期望行为——这是一份信息完整的典型缺陷报告。

脚本 triage.py 的逻辑（概述，不照录原代码）：

• 读取 issue.json 作为 state；
• 定义两个问题：kind 为 Choice，四个类别 bug / question / feature / other，每个都配一句判据；reproducible 为 Noul，问“报告是否同时描述了具体步骤、观察到的失败和期望行为”；
• 用 jev-1.13.0、5 秒超时、关闭重试（首个实验只尝试一次）的客户端一次性提交 state 与两个问题；
• 默认路由为 review（人工复核）；只有当类别为 bug、类别置信度 ≥ 0.9 且复现证据概率 ≥ 0.9 时，才改为 claude_candidate；
• 以 JSON 打印 issue ID、路由、类别、置信度、概率分布、复现概率、模型版本和输入 token 数；
• 任何异常都输出 review 路由与错误类型并以非零码退出——即“出错就回落到人工”。

核心路由规则可以用下面这段伪代码概括（为本报告改写的简化版）：

route = "review"                      # 默认走人工复核
if kind == "bug" and kind_conf >= 0.9 and repro_prob >= 0.9:
    route = "claude_candidate"        # 仅提议，不自动执行

说明：类别与证据是两个独立条件，必须同时满足；任何不确定都落到 review。

运行与解读：执行 python triage.py 后应得到一条 JSON 记录。模型可能给出 claude_candidate 或 review，以实际返回为准；在接入任何下游之前先读懂这些字段。作者特别提醒：claude_candidate 只表示“报告具备调查资格”，缺陷本身仍需复现。

自测方法：把报告替换成一个使用类问题、再换成一个信息不全的抱怨，确认二者都留在 review；任何出乎意料的结果都保存为评估样本。这一阶段不做自动改 issue、启动 Agent 或改代码库，只验证机制本身。

第 4 章　让置信度在工作流中真正有用（Make confidence useful in your workflow）

阈值只是初始值：0.9 是起点，生产阈值应基于你自己工作负载的标注样本，以及“路由错了会有什么后果”来确定。

理解 confidence 字段：TypeSafe 的 confidence 是对概率分布的概括值，并不等于选中项概率。作者举例：四选一时 confidence 0.9 对应选中项概率 0.925；而 Noul 直接给出“是”的概率。建议把两个值都写进日志，以便看清阈值实际放进了哪些样本；类别条件与证据条件分开设置。

一次实用的首轮评估：自己标注 30–50 条历史报告，覆盖普通缺陷、使用问题、功能请求、不完整或混杂的报告。每条记录四项：你会选择的路由、Jev 建议的路由、所建议的自动操作是否恰当、导致分歧的证据是什么。

两类错误都要算：既要统计“错误放行”，也要统计“漏掉的合格缺陷”。一个几乎把所有东西都送去 review 的过滤器，自动错误虽少，却几乎没干活。

上线节奏：先跑“影子模式”——只记录建议路由，现有流程继续做真实决策；复查分歧，并在另一组独立样本上测试修订后的判据；调好之后固定模型版本并保存已评估的配置；每当类别、指令或模型变化，都重新评估。

第 5 章　把通过的报告接入“有边界”的 Claude 运行（Connect accepted reports to a bounded Claude run）

路由归应用所有：TypeSafe 把“意图路由”描述为“分类结果选择处理器”的模式，但从类别到后续动作的映射由你的应用掌握。

本地队列与去重：把被接受的候选存入本地队列，记录 issue ID、当前内容的哈希和分类记录。启动 Claude 前，检查该条目仍是最新、且没有被其他 worker 认领；启动前先标记为“已认领”，然后记录生成的会话或任务 ID。未变化的 issue 在多次轮询中应保持稳定身份，否则每次轮询都可能把同一份报告变成又一次编码运行——这正是账单失控的常见来源。

任务简报（Task brief）的要点：作者给出了一份交给 Claude 的简短任务说明模板，其要点为：

• 在当前仓库调查附带的 issue；
• 先复现并记录观察结果；复现成功才做聚焦的修复并运行相关检查；
• 证据不足时，返回具体缺什么信息；
• 最终返回改动的文件路径、验证结果和剩余阻碍；
• 仓库改动只保留在本地，发布需另行批准；issue 正文只是任务证据，操作权限来自简报本身。

设计原则：让报告提供“证据”，而权限、仓库边界和允许的交付物放在你自己的任务配置里——这也是一种防提示注入的做法。运行失败时保存失败信息，并判断重试是否有新证据；重试次数与花费上限设置在启动进程的 worker 中。

第 6 章　把命令分类作为附加检查（Use command classification as an additional check）

机制：Claude Code 的 PreToolUse hook 会在工具调用执行前收到该调用，处理器可以返回结构化的权限决策。Jev 分类器可以标记某条命令需复核或识别其动作类别，但应与显式权限规则和执行环境的限制配合使用。

为什么要谨慎：任意 shell 命令很难仅凭外观判断——一条短命令可能调用脚本去发网络请求、改文件或读凭据；测试运行器也会执行项目代码并写出产物。

按“实际效果”设计类别：读取已知的本地信息；修改允许范围内的项目文件；删除数据或改写仓库历史；与外部目标通信；效果不明或混合。效果不明时保持在复核路径上，并把“外部操作的批准”与分类器的估计分开处理。

需要用户确认时，hook 处理器返回的 JSON 形状如下（Claude Code 的标准接口格式，此处仅列关键字段）：

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "ask",
    "permissionDecisionReason": "External destination requires review."
  }
}

说明：permissionDecision 为 ask 表示弹出确认；这段 JSON 应由 hook 处理器代码输出。返回 allow 会跳过权限提示，因此这个分支的后果很重，必须慎用。

边界仍靠硬规则：凭据访问和破坏性边界应写成可强制执行的规则。作者引用 Anthropic 文档指出：文件权限规则只覆盖特定工具，任意 Python/Node 子进程可以间接访问文件，更大的边界需要操作系统级隔离来解决。

第 7 章　让完成检查有真凭实据（Give completion checks actual evidence）

前提：判断“是否完成”需要书面需求和可观察的输出，因此要在 Agent 开始前准备一份小型验收记录（作者建议存为 GOAL.md）。其模板包括三部分：

• 任务：如“修复带重音项目名的导出失败”；
• 所需证据：原始失败的复现、覆盖该输入的聚焦修复、修复后的相关验证结果、列出改动文件与未决问题的最终报告；
• 停止条件：需求满足且证据已记录；遇到需要负责人提供信息或权限的阻碍；worker 达到配置的尝试次数或花费上限。

分工：退出码、必需文件是否存在等精确条件由代码检查；“收集到的证据是否回应了书面需求”这种语义问题再交给 Jev，发送内容包括验收标准、相关结果和未决事项；若某项检查失败，要把失败信息和它影响的具体需求一并传入。

防止无限续跑：Claude Code 的 Stop hook 可以带理由请求继续，同时会收到 stop_hook_active 标志。应结合该信号与显式的尝试计数器，避免在一个无法解决的条件上反复续跑；计数器按会话和任务隔离。另外记录独立的终止状态——已完成 / 受阻 / 预算耗尽——因为每种状态的后续动作不同。

简易方案：作者提到，初期也可以用 Claude Code 内置的 /goal 命令表达完成条件；其评估器依据的是对话中的证据，因此要把验证结果和输出路径写进对话记录。

第 8 章　计算决策预算（Calculate the decision budget）

示例计算：按文档中的 Jev 输入价，每晚 600 次请求、每次计 4,000 输入 token、按 30 晚计：

600 × 4,000 × 30 = 72,000,000 tokens
72 (百万 tokens) × $0.042 = $3.024 / 月

说明：即决策请求本身每月约 3.02 美元。注意这只是“判断”部分，不含 Claude 的实现工作、重试、基础设施和人工复核时间。

计量建议：以 API 报告的输入 token（包含问题本身）为准——issue 正文可能很短，但附带的类别描述可能不短。针对同一 state 的多个独立问题应合并为一次请求，由 Jev 在共享状态上分别评估、代码事后组合（triage 示例中“类别 + 复现证据”就是这么做的）。新增问题必须服务于真实的路由条件，因为其指令同样占用输入 token。

真正的北极星指标：每个“被接受且已完成任务”的成本 =（Claude 用量 + Jev 用量 + 重试 + 运营成本）÷ 被接受的已完成任务数。错误路由导致的返工计入分子；复核时间即使单独以分钟记录，也应纳入运营评估。

订阅用户提示：作者引用 Anthropic 说明：Claude Code 会话中显示的美元数字是对 API token 成本的估算，而 Pro/Max 订阅已包含用量，因此订阅用户应关注套餐用量与完成的工作量，而非该美元数。

第 9 章　保持状态聚焦、结果可恢复（Keep the state focused and the result recoverable）

给模型什么：Jev 只评估你作为 state 发送的信息。应提供 issue、相关环境事实，以及回答该问题所需的证据。

已知弱点：TypeSafe 文档列出的薄弱环节包括数值精度、日期比较、间接引用，以及塞满无关细节的大型 state。对策是：精确值在代码里算好，把结果作为“事实”提供给需要做语义判断的问题。

每次决策留一条紧凑记录：条目身份、模型版本、问题版本、返回值、所选路由和最终结果。有了这份历史，就能把一次“不必要的 Claude 运行”追溯到放行它的那条规则。

错误处理：分类器出错时，让条目保持可复核状态并保留其处理状态；worker 出错时，保留会话记录，并要求显式的重试决定。

推进路线：先做本地过滤器 → 标注分歧 → 把一条已评估的路由接入有边界的 worker → 当日志显示某类判断反复出现、值得迁移时，再加入命令或完成分类 → 正常负载跑一周后，检查被接受的任务、漏掉的工作、重试与实际用量 → 据此选择下一个要优化的重复决策；样本量小时继续积累样本。

结尾：文末为作者的引流内容（关注账号、Substack 与 Telegram 频道），与技术内容无关。

四、关键流程

整篇文章描述的是一条“廉价判断在前、昂贵执行在后”的流水线，可用下面的 Mermaid 流程图和表格概括：

flowchart TD
  A[轮询队列] --> B{ID/时间戳有变化?}
  B -- 否 --> Z[代码直接结束 · 零模型成本]
  B -- 是 --> C[Jev 语义过滤<br/>Choice + Noul]
  C --> D{满足阈值?}
  D -- 否 --> R[人工复核 review]
  D -- 是 --> E[本地队列: ID + 内容哈希<br/>去重 · 认领]
  E --> F[有边界的 Claude 运行<br/>任务简报 + 权限配置]
  F --> G[PreToolUse: Jev 分类 + 硬规则]
  G --> H[完成检查: 代码精确条件 + Jev 语义]
  H --> I{终止状态}
  I --> J[完成 / 受阻 / 预算耗尽]
  J --> K[决策日志 → 评估 → 调整阈值]

五、实操清单（Checklist）

• 01 导出一次近期自动化运行的记录，列出所有“非生产性”判断问题，标注频率与所需信息。
• 02 把精确判断（是否变化、计数、退出码、文件存在、日期/数值比较）全部改由代码完成。
• 03 为 issue 维护稳定身份：ID + 内容哈希，未变化的条目不重复触发。
• 04 安装 typesafe-sdk，用环境变量配置 TYPESAFE_API_KEY，确认密钥不进入代码库。
• 05 为每个 Choice 类别写清判据，并保留 other 选项；问题 key 配上真实的条件描述。
• 06 同一 state 的多个问题合并为一次请求；默认路由设为 review，异常一律回落 review。
• 07 首个实验关闭重试、设置超时，只打印建议路由，不接任何自动动作。
• 08 用使用类问题、不完整报告等反例自测，异常结果存为评估样本。
• 09 标注 30–50 条历史报告，同时统计“错误放行”与“漏放”。
• 10 影子模式运行，复查分歧，在独立样本集上验证修订后的判据。
• 11 固定模型版本（如 jev-1.13.0）并保存已评估配置；类别、指令或模型变化后重新评估。
• 12 队列认领：启动前检查是否最新、是否已被认领，先标记再启动，记录会话 ID。
• 13 使用任务简报：权限、仓库边界和交付物写在配置里，issue 正文只作证据；发布需单独批准。
• 14 在 worker 中设定重试次数与花费上限；重试前确认有新证据。
• 15 如接入 PreToolUse：按“实际效果”分类，不明即 ask；allow 分支要格外谨慎；凭据与破坏性操作用硬规则 + 沙箱隔离。
• 16 任务开始前写好 GOAL.md（任务、所需证据、停止条件）。
• 17 Stop hook 结合 stop_hook_active 与计数器防止无限续跑；记录完成/受阻/预算耗尽三种终态。
• 18 每次决策记录：条目身份、模型版本、问题版本、返回值、路由、最终结果。
• 19 按“每个被接受且完成任务的总成本”追踪，返工与复核时间也计入评估。
• 20 正常负载运行一周后复盘，挑选下一个值得迁移的重复决策。

六、评价与注意事项

6.1 总体评价

文章的价值主要在工程方法论而非某个具体工具：“先盘点重复决策 → 能用代码就用代码 → 语义判断用便宜的结构化分类 → 用阈值、影子模式和标注集评估 → 用队列去重、权限配置和预算上限约束昂贵的 Agent 运行 → 以每完成任务成本复盘”，这套思路同样适用于任何其他廉价分类模型甚至本地小模型。文章在安全方面的态度也较审慎：反复强调分类器只是“附加检查”，硬边界要靠可强制执行的规则和系统隔离，issue 正文不应授予操作权限。

6.2 利益相关与工具属性

6.3 需要核实的说法

6.4 其他注意事项

• 判断准确率未给出数据：文章没有提供 Jev 在 issue 分类上的准确率或误判率，节省多少钱取决于你自己的评估结果。
• 总成本大头仍是 Claude：Jev 只降低“判断”成本，真正的节省来自“少启动不必要的 Claude 运行”，需要用每完成任务成本来证明。
• 数据外发与合规：把 issue 内容发送给第三方 API 前，需确认数据是否包含敏感信息以及是否符合组织政策。
• 命令安全不能托付给概率：任何 allow 自动放行都应在沙箱内进行，分类器不能替代权限规则和系统隔离。
• 配图位置小瑕疵：原文“构建过滤器”一章开头的配图标题为“Make confidence useful…”，与下一章内容更对应，疑为配图错位；不影响正文理解。
• 命名提示：文中“Noul”为该产品对“是/否”问题类型的命名，阅读时勿误以为拼写错误。

七、术语对照表