[{"data":1,"prerenderedAt":174},["ShallowReactive",2],{"blog-post-/zh/blogs/sonnet-effort-task-boundaries":3},{"id":4,"title":5,"body":6,"description":158,"extension":159,"meta":160,"navigation":169,"ogImage":162,"path":170,"seo":171,"stem":172,"__hash__":173},"zh/blogs/zh/38.sonnet-effort-task-boundaries.md","Sonnet 5.5：effort 不是越高越好",{"type":7,"value":8,"toc":149},"minimal",[9,13,23,26,31,43,46,49,52,59,65,68,71,75,78,81,84,90,95,98,104,107,111,114,117,120,123,127,130,133,136,140,143,146],[10,11,12],"p",{},"Sonnet 5.5 的发布说明里藏着一个值得注意的细节：在一项代码评测中，把 effort 调到 Max，得分反而低于 Xhigh。",[10,14,15,16],{},"Anthropic 在 9 月 28 日的发布说明中解释了原因。FrontierCode 判断的是代码改动能不能不经人工修改就合并。超出任务范围的改动，即使质量不错，也会扣分。Max 下，Sonnet 更常调用一个会分给多个子代理的代码审查技能。Cognition 检查的两个案例中，额外审查带来了超时或超出范围的修改。这是厂商对特定评测现象的说明，不能据此说 Max 普遍更差。",[17,18,22],"a",{"href":19,"rel":20},"https://www.anthropic.com/claude-sonnet-5-5",[21],"nofollow","官方发布说明，脚注 2",[10,24,25],{},"真正值得带回工作里的，是一个判断：AI 交回的结果不满意时，“让它再多想一会儿”只是一个选项。有时候，少的那条指令是做到哪里可以结束。",[27,28,30],"h2",{"id":29},"按钮修好了补丁却多出一个决定","按钮修好了，补丁却多出一个决定",[10,32,33,34,38,39,42],{},"看一个虚构的结账页面。按钮上的英文写成了 ",[35,36,37],"strong",{},"Pay securly","，任务是改成 ",[35,40,41],{},"Pay securely","，保持付款行为，其他设置不动。",[10,44,45],{},"为了说明这个问题，我们为本文做了两份补丁，并在本地运行检查。两份都是人为构造的示例，没有交给 Sonnet 生成。它们展示的是如何判断任务完成，不是 effort 设置的对比实验。",[10,47,48],{},"补丁 A 只修正按钮文字。补丁 B 修正了同一个错字，还顺手把页面背景改成紫色，把收据语气设置改得更亲切。紫色可能更好看，收据也可能值得改，但这些都需要另一个决定。",[10,50,51],{},"功能检查对两份补丁都放行：按钮文字正确，点击一次仍然只调用一次 48 美元的付款请求。任务检查只对 A 放行，因为 B 同时改了设置文件。原来那个有错字的版本，则没通过文字检查。",[10,53,54],{},[55,56],"img",{"alt":57,"src":58},"两份人为构造的补丁都保留了付款行为，只有限定范围的修复满足任务要求。","/blogs-img/2026-10-06-sonnet-effort-01-zh.webp",[10,60,61],{},[62,63,64],"em",{},"原创虚构案例，10 月 5 日在本地运行。没有模型对比，也没有真实付款。示例代码、完成条件和运行结果保留在制作源文件中。",[10,66,67],{},"这里不需要把 B 定性成坏代码。问题在于，现在得有人决定，新设置是否应该跟着这次修复一起上线。本来可以结束的小任务，多了一轮审阅。",[10,69,70],{},"如果完成报告只列成功项，这件事很容易被掩盖：修好了文字，保留了功能，还改善了页面。看一下改动文件列表，就会发现另一层意思：它要求负责人接受没有提出过的工作。",[27,72,74],{"id":73},"多一次审查也可能多出一批工作","多一次审查，也可能多出一批工作",[10,76,77],{},"代码审查当然可能发现真正的缺陷。它也可能提出一些可选改进：变量名更清楚、排版更好、附近代码顺便整理一下。单独看，每条建议都可能合理。",[10,79,80],{},"范围扩大的时刻，是“可以考虑”悄悄变成了“已经实施”。结果仍然能通过原来的功能检查，但整个补丁变得更难直接接受。再跑一次同样的功能检查，找不出这个区别，因为它已经通过了。",[10,82,83],{},"Sonnet 的脚注让这个机制值得认真看一眼。更多 effort 给了模型继续调查和审查的空间，但哪些发现必须立刻落实，仍然需要单独定义。审查可以交回建议，不必自动扩大修改范围。",[10,85,86],{},[55,87],{"alt":88,"src":89},"已完成的修复与可选建议放在不同的托盘里。","/blogs-img/2026-10-06-sonnet-effort-02.webp",[10,91,92],{},[62,93,94],{},"原创示意图。把可选改进保留为建议，等它们明确属于这次任务后再实施。",[10,96,97],{},"对这个按钮案例，一条够用的指令并不长：",[99,100,101],"blockquote",{},[10,102,103],{},"把按钮文字从“Pay securly”改成“Pay securely”。保持金额、币种和点击行为，现有设置不动。检查文字和付款行为，再核对改动，交回补丁。无关建议单独列出来。",[10,105,106],{},"这比笼统地要求“做得彻底一些”更容易执行：要交付什么、哪些东西不能变、什么证据说明完成，都写清楚了。",[27,108,110],{"id":109},"先看失败在哪再调-effort","先看失败在哪，再调 effort",[10,112,113],{},"如果 AI 没有偏离任务，却得出了错误答案，多一些推理可能有帮助。复杂的依赖、几种竞争的解释、不熟悉的算法，都可能值得继续调查。重点是下一次尝试有没有解决那个不确定的问题。",[10,115,116],{},"如果答案已经正确，补丁却带着无关修改，先补清楚边界。多想一会儿，并不能替负责人决定那些改动是否属于这次交付。把必要修复和可选建议分开，再用原来的要求核对改动。",[10,118,119],{},"如果任务已经说清楚，相关检查也做了，仍然解决不了，就重新看模型、工具和上下文。重复提高设置，未必比补上缺失的文件或一份正确的行为示例更有用。",[10,121,122],{},"这几类失败需要不同的处理。全部归因于“想得不够”，就把 effort 当成了一个能替我们决定所有事情的旋钮。",[27,124,126],{"id":125},"调查任务需要留出发现范围的空间","调查任务，需要留出发现范围的空间",[10,128,129],{},"这个错字案例故意选得很简单。“查清结账为什么偶尔失败”是另一种工作。问题可能出在付款处理、重试逻辑，也可能是配置。死守一个文件的限制，反而可能挡住调查。",[10,131,132],{},"这种任务可以允许广泛调查，同时说清楚怎么从调查进入修改：先复现，解释原因，指出必要改动，遇到影响较大的范围扩展时明确提出。让高 effort 去解决值得深入的问题，也给它与问题相配的完成条件。",[10,134,135],{},"即使是小小的错字任务，也有例外。如果修复必须带着一个依赖修改才能生效，AI 应该把原因说明白。停止规则要拦住随手扩张，也要让真正必要的发现能到达负责人。",[27,137,139],{"id":138},"选-effort-的时候也把终点选好","选 effort 的时候，也把终点选好",[10,141,142],{},"Sonnet 5.5 的发布，让 effort 更值得关注。它的脚注也提醒我们：得分对应的是一个有验收标准的任务。更多动作有没有用，要看它是否把结果推向那个标准。",[10,144,145],{},"日常修复，可以把完成状态写得很具体：要求的修改有效，需要保留的行为没变，实际改动属于约定的工作。调查任务，则要把还有哪些疑问、允许怎样扩展说清楚。",[10,147,148],{},"下次 AI 交回一份看起来很厉害、却仍然不能直接合并的补丁，先看它为什么不能接受，再要求更强的一轮尝试。可能需要更多推理，可能缺上下文；也可能它已经会解决问题，只缺一句更清楚的“到这里就可以停了”。",{"title":150,"searchDepth":151,"depth":151,"links":152},"",2,[153,154,155,156,157],{"id":29,"depth":151,"text":30},{"id":73,"depth":151,"text":74},{"id":109,"depth":151,"text":110},{"id":125,"depth":151,"text":126},{"id":138,"depth":151,"text":139},"Sonnet 5.5 的 effort 并不是越高越好。通过一个具体的结账修复案例，分清什么时候需要更多思考，什么时候需要更清晰的任务边界。","md",{"date":161,"image":162,"alt":163,"category":164,"tags":165,"published":169},"6th Oct 2026","/blogs-img/2026-10-06-sonnet-effort-cover.webp","陶瓷结账台旁多出紫色重刷和额外收据，用原创 3D 隐喻解释任务扩张。","ai-native-systems",[166,167,168],"Claude","思考强度","智能体",true,"/blogs/zh/sonnet-effort-task-boundaries",{"title":5,"description":158},"blogs/zh/38.sonnet-effort-task-boundaries","yDUeUCiNktSPDVczcKcbSDnBLWgLpwF3o-FZ1sR9_Es",1791381921832]