正在打开每日关注
正在打开每日关注
Thariq 实测发现调高 effort 主要换来更多验证与边界测试,据此提出 builder 低努力构建、verifier 高努力验证的双子代理工作流。
Thariq from Anthropic's Claude Code team just published his tests on effort: turning effort up mostly buys 𝗺𝗼𝗿𝗲 𝘃𝗲𝗿𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗲𝗱𝗴𝗲-𝗰𝗮𝘀𝗲 𝘁𝗲𝘀𝘁𝗶𝗻𝗴. You can turn his approach into 𝘁𝘄𝗼 𝘀𝘂𝗯𝗮𝗴𝗲𝗻𝘁𝘀 and have Claude Code follow it. For new features, he works in four steps: → Have Claude ask you questions first and fill in what the spec is missing → Build it on low. It's fast, and you can step in anytime → Look it over, and if it needs changes, stay on low → Switch to high at the end to verify and test If you want to try it, send this image and the prompt below to Claude Code 👇 "Set up the workflow in this image in my Claude Code: 1. Create two subagents in ~/.claude/agents: - builder: writes the code. model: opus, effort: low. It implements the spec I've approved and stops when it's done. - verifier: checks the work. model: opus, effort: high. It runs the feature first to see what it actually does, then adds tests, focusing on edge cases. It reports problems to me and doesn't change the code itself. 2. Add a rule to ~/.claude/CLAUDE.md: when I ask for a new feature, first ask me what the spec is missing; after I confirm, hand it to builder; after I've reviewed the result, hand it to verifier. 3. Check whether the environment variable CLAUDE_CODE_EFFORT_LEVEL is set. If it is, the effort settings on both subagents won't take effect. Just tell me; don't change it. Show me the contents of the files you'll create or change, then explain the whole workflow in words a 10-year-old could follow. Don't write anything until I confirm."
What is effort really? When do you change it it and why not just use max effort for everything? I dove deep into this problem, looking into evals and doing my own tests and I was quite surprised by the results. https://t.co/KO2D51j34H
是什么 Claude Code 团队的 Thariq 发布了对 effort 参数的实测分析,@Voxyz_ai 转述并把它封装成可直接落地的双子代理工作流。核心结论:调高 effort 并不会让模型「更聪明地写代码」,而主要是买到更多验证行为和边界用例测试。
核心设计 据此把新功能开发拆成四步:先让 Claude 提问补全 spec 缺口;在低 effort 档快速构建,成本低且可随时人工介入;有问题继续留在低档迭代;最后切到高档做验证与测试。落地方案是两个子代理——builder(Opus、低 effort,只实现已确认的 spec)与 verifier(Opus、高 effort,先运行功能看实际行为再补边界测试,只报告不改代码),并在 CLAUDE.md 写入流程编排规则。
关键洞察 这是对「推理预算该花在哪」的工程化回答:生成阶段低 effort 足够,验证阶段才值得花高 effort,本质是用角色分离 + effort 分档实现性价比最优的人机协作流水线。verifier「先跑再说、只报不改」的约束也很值得借鉴,避免验证者越权引入新变更。
边界与风险 结论基于其 eval 与自测场景,未必泛化到所有任务类型;若环境变量 CLAUDE_CODE_EFFORT_LEVEL 已设置,子代理上的 effort 配置不会生效,这是常见的静默失效点。整套流程依赖用户确认节点,自动化程度有限。