企业官网建设流程全解析

我们用 Claude Code、Codex 这类 Coding Agent 时，会遇到两个设置：Model 和 Effort。它俩都能让我们的交付成品变好：Model 往上调，采用更聪明、智能的模型；Effort 往上调，让模型更充分地思考。

虽然在结果上，Model 和 Effort 殊途同归，但它俩管的事情并不相同。如果说 Model 是在问“这次任务交给谁来做？”，那么 Effort 就在解决“这个 Agent 愿意为这件事花多少工夫？”

考虑到成本开销，我们不能简单粗暴地把模型切换成最强模型，再把 Effort 拉满。毕竟这样不划算。对账单友好的方式是先判断交付结果不佳，是能力不行还是任务拆解不够细。

模型选择的原理

我们先从你在 Claude Code 里按下回车开始。Claude Code 会把你的消息、system prompt、工具定义、CLAUDE.md、对话历史，以及已经放进上下文的文件，一起打包成一次 API 请求。

这些请求信息到了服务端，文本会先经过 Tokenizer，被切分成 token，并映射成一串 token ID。const会被映射成一个数字，await也会被映射成另一个数字。从这一步开始，你的 prompt 就变成了一串整数。

接下来，模型就能基于当前这串 token，预测下一个 token 最可能是什么。

一个充分训练的模型，会把下一个可能 token 是fetch的概率排得比较高，而把banana这种无关 token 的概率排得接近 0。

而把输入 token 变成这些概率的背后机制是模型权重。模型权重是模型训练后固定下来的经验。它们是组织在矩阵里的大量数字。模型每预测一个 token，都要把输入经过这些权重，最后得到下一个 token 的概率分布。

值得一提的是，一旦训练结束，模型权重就是固定的。你的 prompt、CLAUDE.md、上下文文件，都会影响这一次模型怎么回答，但不会改变模型权重。

因此，你把真实代码放进上下文，能很好地引导本次任务完成。但只是在当前请求里引导它，模型本身并没有在本次任务中写入新知识。

如果开发用到的某个库在模型训练时还不存在，你可以把文档放进上下文，Claude 就能根据文档使用该库。但这种方式更像一次性的知识补充，模型并没有真正学会这个库，也不会把这些信息写入自己的参数。

所以，当 Claude 自信地调用一个不存在的 API 时，通常是模型根据已有训练模式，生成了一段看起来合理的结果。此时，继续补充上下文可以帮助 Claude 理解当前任务，但并不会改变模型本身的能力。

如果希望改变模型处理问题的能力范围，就需要切换 Model。本质上，切换 Model 就是在换一组不同的模型权重，重新处理同一个请求。

模型生成 token 的方式

模型并不会一次性生成完整答案。它会先预测一个 token，把这个 token 接到序列后面，再继续预测下一个 token。一个 200 token 的回复，这个过程要重复 200 次。

这也是输出成本和等待时间的重要来源之一。

模型设置决定了哪一组权重处理请求，也决定了每个输出 token 的成本。但模型本身不会去决定最终生成多少 token。同一个 prompt 下，模型生成多少 token，取决于它决定为这次任务做多少工作。

也就是接下来要说的 Effort。

Effort 的作用

Coding Agent 在处理任务时，生成出来的 token 大致可以分成这三类：第一类是 thinking，就是你看到的中间思考；第二类是 tool call，比如调用 Read、Edit 这类工具，以及对应的参数；第三类是 text to you，比如计划、进度更新、最后总结。

这些本质上都是同一个生成循环产生的 token。thinking 是 token，工具调用也是 token，最后写给你的文字也是 token。它们的区别在于 token 内容不同，Claude Code 会把工具调用解析出来并执行。

Effort 决定了 Claude 在这个过程中投入多少工作。

Effort 会和你的 prompt 一起作为请求的一部分发送给模型。模型在训练中已经学会了不同 effort level 下应该如何行动，这种行为模式也存在固定权重里。

当请求来到时，Effort 就像 prompt 里的其他信息一样，会影响 Claude 的行为。Effort 越高，Claude 对“任务完成”的要求就会越高。它会更倾向于多做检查、多读文件、多验证结果，也更可能在多步骤任务里推进得更远。

Claude 团队给了一个示意案例，同样是修一个失败测试，低 Effort 可能只读测试文件、做修改，再给出一个简单结果；高 Effort 可能会读测试文件、读源码、读配置、思考、修改源码、跑测试，再重新读取文件确认。

图注：低 effort 大约 400 tokens，高 effort 大约 2,800 tokens。

不过，高 Effort 并不代表 Claude 会故意把简单任务做复杂。如果一个三假设调试计划里，第一个检查已经找到 bug，后两个检查可能就没有必要继续。Claude 通常会更新任务列表，并说明为什么跳过剩余检查。

所以 Effort 更像是一个“工作投入倾向”，它会让 Claude 更愿意多检查、多验证，但不会把每个简单任务都强行拖长。

如何选择 Effort

对大多数任务，先使用模型默认的 Effort 即可。默认值兼顾了任务完成度、token 消耗和响应速度。只有当工作流对速度或验证程度有明确要求时，再主动调整 Effort。

Anthropic 也建议把 Effort 看作一种长期使用偏好，无需为每个小任务反复切换。

你可以把 Effort 当成一个手动覆盖项。当你对速度或彻底程度有明确偏好时，再去调整它。如果当前工作流非常看重验证，那你可以用更高 Effort。如果你只是想要快速响应，那可以偏向低 Effort。

模型出错该调整什么

当 Claude Code 出错时，第一反应应该检查你给它的上下文，而不是调设置。可以根据下面顺序进行检查：

• 你的 prompt 是否太模糊？
• Claude 是否连上了正确的工具？
• 它是否具备正确的 Skills？
• CLAUDE.md、上下文、任务范围是不是有问题？

如果一个任务本来不用提高 Effort，却要靠更高 Effort 才能完成，那问题往往在上游：上下文、CLAUDE.md，或者任务范围本身。

当你确认上下文已经足够清楚，Claude 还是做错了，再问一个关键问题：它是没有足够努力，还是没有足够能力？

怎么选换 Model 还是 Effort

如果问题本身确实很难，就应该考虑更大的模型。这里的典型情况包括：隐蔽 bug、不熟悉领域、架构决策。

如果 Claude 已经拿到了相关上下文，也明显尝试过，最后仍然自信地做错，这就是换更大模型的信号。更大的模型往往更擅长处理模糊问题。相对来说，小模型更适合明确指令和清晰执行路径。

日常任务就没有必要总用大模型。对于要求明确的小改动、重复性较强的机械修改，以及基于现有代码的简单问答，较小模型通常已经够用。任务不需要那部分能力时，我们没必要为它付费。

如果 Claude 做错，是因为它没有读某个文件、没有跑测试、没有 double-check，那就更像是 Effort 问题。

这时候，你可以提高 Effort。尤其是你本来就选了低于默认值的 Effort，结果它跳过了关键检查，那么提高 Effort 会更合理。

在 Claude 中，Model 和 Effort 的组合可以参考以下内容：

• Fable 像一位专家型人才，适合处理那些其他人都解决不了的问题；
• Opus 像一位资深专家，拥有更丰富的经验；
• Sonnet 像一位能力很强的通才，适合大量日常开发任务；
• Effort 决定的是：他们愿意在你的任务上投入多少时间；
• 低 Effort 的 Opus，就像只给一位资深专家 5 分钟。他经验丰富，能够迅速发现一些关键问题，但不会仔细读完所有文件。
• 高 Effort 的 Sonnet，就像给一位能力很强的通才一整个下午。他会文件、运行程序、反复检查，最终更充分地理解你的代码。
• Fable 更适合留给那些真正需要专家型能力的任务。它的成本最高，也更应该用在确实需要它的地方。

这里没有一个设置永远更好。Model 大致决定能力，Effort 大致决定彻底程度。真实任务通常需要两者配合。

Token 成本变化

Model、Effort 和 token 消耗之间的关系，要看任务难度。

在简单任务上，大模型和小模型通常都能很快达到质量线。继续花更多 token，买到的主要是额外检查，而不是显著质量提升。

这就是为什么简单任务可以用较小模型。质量不一定受影响，速度和成本通常会更友好。

一般来说，较小模型需要更多轮尝试，才能逐渐逼近较大模型用小步骤达到的质量。

虽然大模型单个 token 的价格更高，但面对真正逼近小模型能力上限的复杂任务，它往往能用更少的步骤完成，因此整体成本未必更高。更关键的是，有些任务即使把小模型的 Effort 调到最高，它依然无法完成，而大模型可以。

这一点在 Fable 上尤其明显。它在长程、多步骤任务里优势更大，也最贵，所以更适合留给真正需要的任务。

这里最重要的理解是：Model 选择的是哪条能力曲线；Effort 选择的是 Claude 愿意沿着这条曲线走多远。

但 Effort 并不是一个 token 上限。真正的硬限制是 max_tokens，它有点像 API 开发里的硬截断。对日常使用来说，让 Claude 控制预算、保持简短，通常比硬截断更有用。

小结

Model 决定 Claude 的能力边界，Effort 决定它愿意为任务投入多少工作。

当结果出错时，先检查 prompt、上下文、工具和任务范围。上下文充足、已经认真尝试却仍然判断错误，就换更大的 Model；漏读文件、没跑测试、缺少验证，就提高 Effort。