AI 智能体实操用例库

真人真做过的 AI 智能体案例:做法、提示词结构、成本、结果状态,全部链回一手出处。

编程搭建 · 评分 90 · 状态:已实现(作者自测基准;美元数为 Claude Code 客户端按价目估算的会话成本,订阅用户实付为套餐费,不是这个数)

让智能体便宜档跑满分:5 档 Claude Code 预设 60 次实测,轻档单次 $0.63,Opus 最高档贵 12 倍却没更好

作者/出处:Oleg Ivanchenko
原文:https://medium.com/@oleg.a.ivanchenko/i-benchmarked-my-claude-code-presets-the-cheap-ones-passed-every-check-57fa8ec2e174
日期:2026-10-23(约,原文未印固定发布日;实验用 Claude Code 2.1.303) · 工具:Claude Code、 bench.py(标准库 Python)、 git worktree
成本:本次实验 60 次共 $230.93 智能体用量 + $14.96 评委费(这是测 60 次的成本,不是日常成本);日常按轻档单次 $0.63–$0.75 计,另需 Claude Code 付费计划(原文未给订阅价,>$50/月档须自行核对) · 耗时:照搬 5 档启动器约半小时;跑一次自己的 4 类任务基准约半天

速览卡

一句话

别凭感觉选模型档位:作者把每天用的 5 档 Claude Code 预设拉进同一套基准跑 60 次,结果是便宜的轻档四类任务全过检查,最贵的 Opus 最高档单次贵 12 倍、质量中位却没超过中等档——贵档买到的主要是心理安慰。

原作者怎么做的

  1. 先定 5 档预设(每档一个 shell 启动器,固定 --model / --effort,子智能体模型用 CLAUDE_CODE_SUBAGENT_MODEL / _FORCE 控制):

- high:Opus 5.5、xhigh 努力度、Fable 顾问、Sonnet 子智能体;

- normal-max:Opus 5.5、max 努力度、无顾问、默认子智能体;

- normal:Opus 5.5、medium 努力度、无顾问、默认子智能体;

- light:Sonnet 5.5、medium、Opus 顾问、Haiku 子智能体(默认);

- light-force:同 light,但强制全部子智能体跑 Haiku。

- 配对设计:normal 与 normal-max 只差努力度,light 与 light-force 只差是否强制 Haiku;起因是 X 上一则“Sonnet 写、Haiku 探、Opus 审”的帖子——作者核查发现它推荐的 --subagents 参数根本不存在,真正起作用的是环境变量,且默认 Haiku 只接管部分子智能体(frontmatter 定了 model 的、inherit 的都不跟),所以才有 light-force 这一档。

  1. 写 bench.py(单文件标准库 Python):每次运行先把任务工作区拷到全新临时目录并提交为 base(真实仓库任务则用固定提交建 git worktree)→ 无头跑预设(-p 提示词 --output-format json --no-session-persistence --max-turns N --max-budget-usd X)→ 从 JSON 结果取耗时与分模型成本 → 跑确定性 check.sh(过为 0 退出码,部分分取末行 0–1 数字)→ 无工具评委(Opus 高努力度,只读 rubric、提示词、最终消息、diff 与检查结论)打 0–10 分 → 一行追加进 results/runs.csv,原始 JSON、消息、diff、评委输出进 gitignored 的 results/raw/。
  2. 定 4 类任务(故意形状不同,防一招鲜):修 lazygit 真实 bug(按上游修复前提交,容器内 8 个隐藏集成测试 + 另 512 个测试把关);审 600 行 PR(10 个埋入问题 + 5 个看起来错实则对的诱饵,满分公式为(找到 − 误报)/10,0.60 及格);写架构决策记录(简报 + 7 份团队笔记 + 代码,只有一个存储方案满足全部约束,简报还故意偏向错误方案);从零写 10×10 逻辑游戏 meowdoku(Go + htmx 4——2026 年 8 月才发布,超出模型训练数据,20 个隐藏验收测试 + 独立求解器作裁判)。
  3. 跑前定死胜出规则(防事后挑数字):按检查通过数排序,保留与最佳评委分差 1 分以内的档,取其中最便宜的;只有便宜 25% 以上才算 outright 胜出,否则算平手。
  4. 做公平控制(这部分占了大部分工程量):每轮全新工作区;清掉会偷偷改写预设的环境变量(连自己会话的 token 与 socket 都隔离);每轮只给一个无头浏览器 MCP + 任务声明的插件,不让智能体摸到作者自己的 Chrome 与 MCP;每任务先各档试跑一次定 turn/预算/时间上限(上限过紧会冤枉慢档);运行顺序交错(A、B、C、A、B、C),不让某段时间的 API 延迟或缓存热度只落在一档上;每个检查都有自测(从完美答案到“改了不该改的文件”的反例都测),改动先过自动代码评审再合并。

结果

提示词结构

(按原文做法还原的基准骨架,非原文逐字提示词)

```

给每个常用档位写一个启动器:[oclaude-档名] 固定 [主模型] + [努力度] + [顾问模型] + [子智能体模型/是否强制],不继承任何默认值。

跑基准前先定死胜出规则:[按检查通过数排序] + [评委分差 1 分以内才算候选] + [取最便宜] + [便宜 25% 以上才算 outright 胜出]。

每个任务配两种评分:[确定性 check.sh:隐藏测试/埋入问题/诱饵] + [无工具评委:只读 rubric、提示词、最终消息、diff 与检查结论]。

公平控制四件套:[每轮全新工作区或固定提交 worktree] + [清掉改写预设的环境变量] + [只给任务声明的插件与无头浏览器] + [交错运行顺序]。

先校准再定上限:[每任务每档试跑一次] 定 [turn/预算/时间上限],上限过紧会冤枉慢档。

```

中国读者怎么迁移

国内用 Claude Code / Cursor / Codex 的读者都能搬:先把自己每天在用的 2–3 档(比如“便宜主力 + 贵档兜底”)写成固定启动器,再挑 4 类自己真实会遇到的任务(修 bug、审 PR、写文档、从零写小功能),每类配一个“能自动判对错”的检查(隐藏测试、埋入问题、验收清单),跑 3 遍取均值。别只看一次手感——作者的教训是,贵档在单次小任务上看着只贵一点,是因为上下文成本把差距抹平了;按检查通过数 + 评委分 + 单次成本三列排,才看得出哪档真值。

风险与限制

原文链接

https://medium.com/@oleg.a.ivanchenko/i-benchmarked-my-claude-code-presets-the-cheap-ones-passed-every-check-57fa8ec2e174