最近在用各种 AI coding agent 干活的时候，我发现一个很反直觉的现象：给 AI 的上下文越多，结果不一定越好。
一开始我也觉得奇怪。按理说信息越充分，AI 应该做得越好才对。但实际体验下来，很多时候把一大堆代码、文档、报错日志全丢进去，AI 反而会迷路——改了不该改的地方，漏了真正的重点，甚至开始自己编逻辑。
后来我想明白了：重要的不是 token 的绝对数量，而是「有效 token」相对于「任务复杂度」的比例。
一个简单的思维模型
可以这样理解：AI 的工作质量，取决于你给它的有效信息够不够「覆盖」这个任务。
这里面有几个关键变量：
- Token 总量：你喂进去的所有内容，需求、代码、报错、约束条件等等。
- 上下文利用率：这些 token 里，有多少是经过整理的、结构清晰的、模型真正能用上的？如果信息乱七八糟，塞再多也没用。
- 注意力聚焦度：模型是不是能把注意力放在关键的地方？研究表明，模型对上下文开头和结尾的信息利用率更高，中间部分容易被忽视——这就是所谓的 "lost in the middle" 现象。
- 任务范围：你让 AI 干的事到底有多大？改一个按钮样式，和重构整个认证系统，完全是两个量级。
- 任务不确定性：需求清不清楚？边界明不明确？"把这个系统优化一下" 和 "把这个函数的返回值从 string 改成 number" ，对 AI 来说难度天差地别。
把这些因素放在一起看，核心结论就是：
有效 token 除以任务工程量，这个比值才是真正决定产出质量的东西。
而且这个提升是边际递减的。一开始加信息，质量蹭蹭往上涨；到了一定程度之后，再加 token 收益就越来越小了，因为模型能力本身有天花板。
所以实操层面怎么做？
想明白这个模型之后，操作建议就很清晰了。而且 2026 年的工具和方法论已经比一年前成熟太多了，下面是目前最新的实战经验：
1. 先规划，再动手。 别上来就让 AI 写代码。Google 的 Addy Osmani 分享过他的工作流：先和 AI 一起头脑风暴出一份详细的 spec，列清楚需求、架构、数据模型和测试策略，然后再拆成一步步的执行计划。OpenAI 的 Codex 现在也内置了 Plan 模式——让 AI 先收集上下文、问你问题、制定方案，然后再动手写。这个前期投入看起来慢，但后面能省掉大量返工。
2. 把任务切小，一次只干一件事。 这条没变，但 2026 年的实践更极端了。现在的共识是：每次只让 AI 做一个函数、修一个 bug、加一个功能。做完就测、测完就提交。Addy Osmani 管这叫「ultra-granular version control」——每完成一小步就 git commit，相当于游戏里的存档点。AI 跑偏了随时回滚，成本极低。
3. Context Engineering：喂最少但最精准的 token。 这是 2026 年最大的变化。Anthropic 在他们的 context engineering 指南里明确说了：好的上下文工程意味着「找到最小的、信号最强的 token 集合，来最大化预期结果的可能性」。不是把所有文件都丢进去，而是精心筛选。现在的工具链也在往这个方向进化——Claude Code 会按需动态加载文件而不是一开始全塞进去，OpenAI Codex 引入了 AGENTS.md 和 SKILL.md 来固化项目规则和可复用工作流。核心思想都一样：让每一个 token 都有用。
4. 把需求写到不能再清楚。 OpenAI Codex 的最新文档把好 prompt 拆成四个要素：Goal（你要干什么）、Context（哪些文件和文档相关）、Constraints（要遵守什么规范和限制）、Done when（怎么算完成）。这四个东西写清楚了，AI 的假设空间就被压到最小，产出质量直接拉满。
5. 让 AI 自己验证自己。 2026 年的 coding agent 已经不只是写代码了，它们可以自己跑测试、自己 debug。但前提是你得有测试。有强测试套件的项目，AI agent 跑起来如鱼得水；没测试的项目，AI 会默认一切正常然后闷头写 bug。投资测试不是为了你，是为了让 AI 更好用。
6. 用多个模型互相校验。 现在的前沿做法是让一个模型写代码，另一个模型 review。不同模型有不同的盲区，互相补位效果很好。
不同模型，效率也不同
最后补一点：不同模型在同样条件下的转化效率是不一样的。2026 年 2 月，Anthropic 发布了 Claude Opus 4.6——100 万 token 上下文窗口、最长 14.5 小时的持续任务执行能力，专为长时间 agentic coding 和大代码库设计。同月 OpenAI 推出 GPT-5.3-Codex，号称能做到「开发者在电脑上能做的几乎所有事」。Google 的 Gemini 在自然语言理解上表现强劲，很多开发者发现它在第一次就能理解意图。
这些差异可以理解为：同样的有效上下文，有些模型就是能榨出更多质量来。而且现在的前沿做法已经不是选一个模型了——而是根据任务特性选模型，甚至让多个模型协作。Anthropic 的 2026 Agentic Coding Trends Report 指出，工程师的角色正在从「写代码的人」变成「编排 AI agent 的人」。谁能更好地调度这些工具，谁就能在同样的时间里产出更多高质量成果。
一句话总结： 别迷信长上下文。Token 是弹药，但打不打得准，取决于你瞄没瞄好、目标有多大。把任务切小、把上下文整理好、把需求写清楚，比无脑加 token 有效得多。
附：形式化模型
上面说的这些直觉，可以压缩成一个公式。这不是某篇论文里的现成定律，而是我根据实际体验和上述研究构造的一个解释性模型：
各变量含义如下：
- — 工作质量。可以理解为代码正确性、完成度、可维护性、一次通过率等指标的综合抽象值。取值范围 。
- — 质量上限。当前模型、工具链、任务条件下理论上能达到的天花板。token 再多，质量也只会逼近这个上限，不会无限上升。
- — Token 总量。输入给模型的所有内容：需求说明、代码上下文、报错信息、约束条件、测试命令、历史决策等。
- — 上下文利用率。你给进去的 token 里，有多少真正被组织成了模型可有效调用的上下文。需求结构清晰、文件筛选精准时 高；上下文混乱、冗余、噪音多时 低。Anthropic 对 context engineering 的定义，本质就是在提高这个系数。
- — 注意力聚焦系数。模型是否能把注意力集中在关键约束和文件上。任务边界明确时 高；信息分散、重点埋在中部时 低。长上下文研究表明模型对开头和结尾的信息利用更好，中间容易被忽视，因此 不是常数。
- — 任务范围。这个任务牵涉多少模块、文件、逻辑路径和系统边界。修一个按钮样式， 很小；重构认证系统， 很大。「任务范围越小，同样 token 越有效」本质上就是 与效果成反比。
- — 任务不确定性。任务的歧义程度、隐藏依赖、需求未定义部分和决策自由度。明确了要改哪些文件、禁止改哪些部分、完成标准是什么， 就小；只说「优化一下」， 就大。OpenAI 反复强调的 clear structure 和 definition of done，本质就是在降低 。
- — Token 转化效率常数。描述单位「有效 token / 工程量比」能多快转化为质量提升。不同模型、不同 IDE agent、不同代码库条件下 不同。Anthropic 强调 Claude Opus 更擅长长时间 agentic coding、在大代码库中更稳定，这类差异可以体现在 或 的变化上。
公式的核心思想可以进一步压缩为一个中间量——有效 token 充足比：
于是主公式就变成：
读法很直观： 小的时候，token 相对于任务规模不够，模型只能做出零散、容易漂移的结果； 增大，质量快速上升； 已经很大时，再加 token 收益越来越小，质量逼近 。
如果要写成一段正式说明：
设 为 AI 在给定编程任务上的工作质量， 为输入 token 总量， 为上下文利用率， 为注意力聚焦系数， 为任务范围， 为任务不确定性，则可用模型 描述质量与上下文供给之间的关系。该模型表明：工作质量并不单纯取决于 token 的绝对数量，而主要取决于有效 token 相对于任务工程量的充足程度。随着 增加，质量通常上升，但由于存在边际递减，提升最终会趋于饱和；而当任务范围更小、边界更清晰、不确定性更低时，同样数量的 token 会更有效地转化为高质量产出。
信息来源：
- 长上下文研究中的 "Lost in the Middle" 现象（Liu et al., 2023）
Follow Me ｜ 关注我
- Blog:https://harryis.fish
- X(CN): @harry_is_fish
- X(EN): @harry_isfish
- 公众号
- 📺 Bilibili:海鱼Harry
- 🍠 小红书:海鱼Harry
- 🎵 抖音:海鱼Harry