加班解决不了方向，这条界线最重要

（以下是对 Thariq 一文的转述与整理，实验细节以原文为准。）一篇关于 Claude Code effort 旋钮的长文，开篇就把大多数人按错了的地方挑明：effort 不是模型的智商档位，是你允许它加班多久。

同一台模型、同一套知识；拧低，它尽快交一个能用的版本、把你留在循环里一起改；拧高，它自己多验证、多挖边角案例、自己做判断，少等你点头。作者的类比很准：别人给你 1 小时，你交个能交差的版本，心里已准备好下一轮改；给你 12 小时，你会默认他们要的是成品——自己补测试、补边界、补那些"你觉得该有但没写清的"。effort 就是在替你对 Claude 说这句话。

工程上最被低估的一点是：调 effort 不会打爆 prompt cache，上下文照样复用——同一段会话里可以先低档写、再高档验，不必重开、不必把前面几万 token 再付一遍；会话中途敲 /effort 即可切换。

这把今晚"省钱"的账本又加了一行：档位、假依赖、字节码、蒸馏之外，会话内的投入调节也进了免重付区——速度与力度第一次可以在同一场对话里各来一遍。

文章明确给 effort 划了管辖范围：它控的是投入，不是知识上限。模型选的是能力档，effort 选的是这档能力愿意花多少力气；实际改变三件事——验证做多少（低档写完测一两个例子就停，高档对参考实现、跑官方测试套、自己写随机 fuzzer）、边角案例挖多深（安全、硬件、老代码的坑都藏在你没想到的那条路径上）、自己替你做多少决定（需求含糊时低档给你简陋起点等你改，高档会自己补功能、定交互、简化设计——所以高档不一定更听话，有时更自作主张）。

最有教学价值的是那条失败分界线：漏边角的问题，加 effort 能明显减少；路子走错了的，加 effort 救不回来——方向错了，加班只是把错的方案打磨得更精致。这句话值得裱起来：需求写错、架构选错，把旋钮拧到 max 也不会自动纠正。今晚"机器铺量、人守门"的纪律在这里获得了一个量化注脚：门内可以交给旋钮，门外必须站着人。

三个实验是全文的骨架：同一类任务、只改变"你给它多少规格"，做三组对照——第一组需求很糊（只说做个健身打卡类的原型），后面几组逐步把规格补全，观察 effort 在不同规格水平下的收益差异（完整数据见原文）。

可以想见的结论方向与今晚所有线索一致：规格越糊，effort 的红利越薄、高档的自作主张越危险；规格越清，高档的验证与边角挖掘才真正兑现成质量。effort 是放大器，不是救生圈——它放大的是你已经写清楚的东西。

对"没有这个旋钮会怎样"，文章也给了反面画像：模型要么永远快但漏坑，要么永远慢且爱自作主张——把速度与验证力度从"模型智商"里拆出来交给使用者，正是新一代工具在交互上最实在的进步之一。这与今晚档位分流、effort 对调是一套完整的旋钮哲学：能力属于模型，投入属于你。

给要用的人一句落地的：按三档定用途——低档用于头脑风暴与你就在旁边改的草稿；中档用于日常实现；高档只给三类任务（安全敏感、老代码修 bug、需要对齐参考实现的复现），并且先把方向写死再拧。

拧之前问一句：这是"漏边角"的问题，还是"路走错"的问题？前者交给你旋钮，后者交给你自己——加班解决不了方向，这条界线比任何档位都重要。

顺带补一句实践细节：高档的"自作主张"其实是双刃的另一面——它省掉了你来回补需求的轮次，却也把"你到底想要什么"的举证责任推回给了你。所以真正配得上高档的任务，往往自带一份已经写清的验收标准；旋钮调的是投入，标准写的才是意图——两者对齐时，那一晚的加班才物有所值。