“这 AI 神了”和”这 AI 没用”之间的差距，几乎从来不是模型，而是你喂进去的上下文。少了，Agent 开始猜、编不存在的函数；多了，注意力被稀释，输出一堆忽略你一半约束的平庸代码。2026 年的麻烦在于：那个最顺手的办法——窗口现在这么大，多塞点上下文进去——反而帮倒忙。这篇给用 Claude Code / Cursor / ChatGPT / Codex 的开发者一份”喂什么、删什么、什么顺序喂”的清单，目标是产出能直接用的初稿，而不是和模型拉锯 40 分钟。
太长不看
- 上下文窗口已经不是瓶颈了。截至 2026 年 6 月，Claude Opus 4.7、Sonnet 4.6、Gemini 3.1 Pro 都是 100 万 token 的标准窗口；真正的瓶颈是模型在这个窗口里的注意力。
- “上下文腐烂”（context rot）是真实存在、且被测量出来的。Chroma 测了 18 个前沿模型，每一个都随输入变长而退化；标称 20 万 token 的窗口通常远没到就开始不可靠，需要语义匹配的任务准确率从 95%+ 掉到 60–70%。
- 喂得少、排得好。语言和框架版本在前，文件和约定其次，硬约束，目标放最后。
- 约定用示例展示（一个锚文件），别用散文描述。
- 用好工具自带的上下文控制：Cursor 的
@提及和.cursor/rules/*.mdc、Claude Code 的CLAUDE.md加/compact、以及用AGENTS.md写仓库级指令。
为什么更大的窗口没解决问题
2024 年有个看似合理的假设：等窗口够大了，上下文管理就不再是问题。结果恰恰相反。Chroma 在 2025 年的”context rot”研究里，让 18 个前沿模型（涵盖 Claude 4、GPT、Gemini 各家族）跑了比经典”大海捞针”更难的测试，得出一个一致的规律：每个模型都随输入变长而变差。当事实是原文照搬时能拿 95%+ 的模型，一旦任务要靠语义匹配、或要顶住似是而非的干扰项，就掉到 60–70%。反直觉的是：模型在打乱顺序的”草堆”上比在逻辑连贯的文档上表现更好——连贯的行文会制造更有迷惑性的干扰项，把注意力从相关行上拽走。
实操结论：100 万 token 的窗口是余量，不是请柬。你的活儿仍然是挑出那几千个会改变答案的 token，把其余的留在外面。（完整方法见 Chroma 的 context rot 研究。）
这篇适合谁看
任何用 Claude Code / Cursor / ChatGPT / Codex 写非琐碎代码的开发者——比改变量名、写一行正则更复杂的事都算。尤其在模型不熟的框架（小 DSL、内部库、比模型训练截止还新的框架版本）或者有强”未写约定”的代码库里。看函数签名就知道答案的真琐碎任务（重命名、简单正则、单行 formatter）跳过这套：粘进去直接问就行，精心准备 prompt 反而更费时间。
开始前准备
- 分清”标称窗口”和”有效窗口”。截至 2026 年 6 月，Opus 4.7 和 Sonnet 4.6 标称 100 万 token（标准价，2026 年 3 月正式可用以来没有长上下文加价），Gemini 3.1 Pro 与之持平。但质量远没到上限就开始下滑。注意：ChatGPT 的 Plus 档在应用内并不给你完整的 100 万——那是 200 美元 Pro 档专属，Plus 大约只有 320 页的工作上下文。
- 用能附文件的工具（Cursor、Claude Code）打开代码库，别全靠 copy-paste。附文件能保留结构，工具还能去重。
- 定好”锚示例”：一个能体现你要遵循约定的现有文件。
具体步骤
- 列上下文分类。 prompt 前列：语言 + 版本、框架 + 版本、要改的文件、要遵循的约定、硬约束（性能、安全、浏览器兼容）、成功标准、改动涉及的 API / 库。
- 逐类决断。 每类选：inline 写进 prompt、附文件、还是跳过。默认”跳过，除非它会改变答案”。
- 排顺序。 语言 / 框架在前 → 文件上下文 → 约定 → 约束 → 目标在最后。模型强锚在前面看到的；目标放最后留在工作记忆里。
- 砍填充。 不会改变答案的全删。1.2 万 token 里只有 2000 token 有用的 prompt，比 2500 token（2000 + 500 缓冲）效果更差——多出来的 9500 token，对注意力机制来说全是干扰面。
- 用文档填知识缺口。 模型不知道的特性（比训练截止还新的、任何内部库），把相关文档段落直接粘进来，或在 Cursor 里用
@Docs拉。不要指望它”记得”。 - 约定用示例展示。 附一个体现命名、错误处理、结构约定的现有文件。一个示例胜过五段”我们都怎么干、除了 X、除非 Y”。
- 首次回应后剪枝。 看模型用了哪段、忽略了哪段。砍掉被忽略的，剩下的存模板。
有效窗口 vs 标称窗口（2026 年 6 月）
如今各家的标称窗口都很大、且大致相当；对上下文管理真正有影响的，是完整窗口在你手里实际可用到哪、以及会话填满后每个工具怎么腾空间。
| 模型 / 工具 | 标称窗口 | 实际能用到的 |
|---|---|---|
| Claude Opus 4.7 / Sonnet 4.6（API） | 100 万 token，标准价 | 完整 100 万；远没到上限就开始退化 |
| Claude Code | 100 万（模型层面） | 用量接近 ~95% 时自动压缩（有时更早）；为工具输出预留 ~3.3 万 token 缓冲 |
| ChatGPT Plus（$20） | — | 应用内约 320 页工作上下文；完整 100 万只在 $200 Pro |
| Gemini 3.1 Pro / Google AI Pro（$19.99） | 100 万 token | 完整 100 万上下文 |
| Cursor（Pro $20） | 取决于所选模型 | 你用 @ 提及和代码库索引来控制喂入量 |
数据截至 2026 年 6 月；各家档位和限制变动频繁。
一份好 prompt 的结构
[CONTEXT - 放最前]
TypeScript 5.4, React 19, Next.js 15 App Router.
风格参考组件：附件 `Button.tsx`。
约定：所有组件 named export，不 default。
错误处理：从 `lib/errors.ts` 抛 typed error。
[CONSTRAINTS]
- 不加新依赖。
- 必须 server component（不 `use client`）。
- 只用 Tailwind，不用 CSS module。
[GOAL - 放最后]
建 `Card.tsx`，沿用 `Button.tsx` 的风格。
Props: title (string), body (ReactNode), variant ("default" | "muted")。用好每个工具自带的上下文控制
2026 年的工具都给了你比 copy-paste 更好的手段。把你最常用的那三个吃透。
- Cursor。 每个
@提及都精确钉住一样东西：@Files/@Folders钉确切代码，@Codebase在已索引项目里做语义检索，@Docs拉官方库文档，@Web实时联网搜。让工作区先把首次索引建完——@Codebase和 Agent 模式的全局感知都靠它。常驻约定用.cursor/rules/*.mdc文件（这套 MDC 格式已取代单个.cursorrules），它支持 glob 作用域，规则只在适用的文件上加载。 - Claude Code。 把长期项目规则写进仓库根目录的
CLAUDE.md——它会话开始就加载、且能熬过压缩，一次性 prompt 做不到这点。会话填满时，Claude Code 在用量接近 ~95% 时自动压缩（有时早到 64–75% 以避免压缩失败）；你也可以在开新子任务前手动跑/compact，让它按你的节奏总结，而不是在半途打断思路时压缩。Anthropic 的上下文窗口文档讲了缓冲的具体算法。 AGENTS.md。 现在是跨工具的仓库级 Agent 指令标准，Cursor、Codex 等都会读。嵌套的AGENTS.md会和上级合并，越具体的文件越优先——在 monorepo 里每个包有自己约定时特别好用。
完成后检查
- 模型用了你写的版本号吗？看
??（新 JS）vs||（ES5）这种迹象。 - 输出遵循了你附的示例文件的约定，还是模型自己的训练偏好？
- 引了不存在的函数 / import 吗？编出来的依赖是上下文不全最响的信号。
- 你需要在 follow-up 里补细节吗？下次把那些放进原 prompt——如果是常驻约定，就放进
CLAUDE.md或某个.cursor/rules文件。
两个具体配方
新 React 组件。 框架版本 + 一个现有组件作风格锚 + 目标。除非目标涉及样式，否则跳过整个 CSS module。在 Cursor 里就是 @Button.tsx 加目标，剩下交给索引。一轮拿到可用初稿。
数据库 migration。 migration 工具及版本 + 最相关的那条现有 migration + 仅涉及表的 schema。其他全跳——旧 migration 纯粹是干扰质量。一轮拿到可用初稿。
重复任务，把配方存成 .cursor/rules 文件或 CLAUDE.md 的一节，让整队共用同一种上下文形状。某段大到没法整个附时，用总结代替（“我们用 Tailwind + 这些自定义工具类：…”），别把整个文件粘进去。
容易踩的坑
- 整个文件全粘——其实只有一个函数有用。浪费上下文、稀释注意力。
- 用散文描述约定（“我们用 camelCase 除了常量是 SCREAMING_SNAKE_CASE 除了在 React 组件里…”）——一个示例文件 30 行就讲清楚了。
- 目标在头、代码在尾。反过来——目标该是模型生成前看到的最后一段。
- 没写版本号。ES2024 项目里出来 ES5 语法；hooks 项目里出来 class component。
- 附你根本不用的特性文档。模型会忠实地用它，你又得删。
- 没写成功标准。“让这个更快”没基准——会拿到”看着像优化”但根本测不出差距的改动。
进阶技巧
- 把”舒适工作窗”当成远比标称窗口小。哪怕窗口 100 万 token，代码重的会话也远没到上限就开始掉准确率，Chroma 的数据显示这是缓慢下滑、不是断崖。让实时上下文保持精简，靠
/compact或新开对话，而不是任它膨胀。 - 不熟的库：粘 README 相关段 + 你要用的精确函数签名（Cursor 里用
@Docs）。编出来的依赖断崖式减少。 - 用小快模型做上下文分流（“这 12 个文件哪些和任务相关？”），用更强的模型——最难的改动上 Opus 4.7——做实际代码生成。又省又常常更稳。截至 2026 年 6 月，Opus 4.7 在 SWE-bench Verified 上以 87.6% 领先，但拿它跑简单分流是浪费钱。
- monorepo 里，用嵌套
AGENTS.md或带 glob 作用域的.cursor/rules给约定划范围，让 Agent 永远只加载它正在改的那个包。
怎么验收输出
- 语言 / 框架版本明写。
- 已有代码附件或总结，不用散文描述。
- 约定用示例展示，不用散文。
- 约束逐条列出，附原因。
- 目标在所有上下文之后。
- 没有不会影响答案的填充。
FAQ
- 窗口都 100 万 token 了，为什么不全塞进去？: 因为窗口是余量，不是免费午餐。Chroma 的 18 模型研究显示准确率随输入变长而下降，连贯的多余代码还会成为很有迷惑性的干扰项。再大的窗口也不改这条规矩：只放会改变答案的。
- 多少上下文算多？: 模型开始忽略一部分时、延迟开始难受时、或工具提示快要压缩时，就过线了。最诚实的信号是行为上的——如果输出开始不再遵守你写明的某条约束，说明你的上下文太吵，而不是太短。
- 要附测试吗？: 目标是让某条测试 pass 就附那条。否则跳——测试撑爆上下文，且模型常去”修”错的地方。
- inline 代码还是附件？: 30 行以上一律附件（Cursor 里用
@Files）。工具处理附件比长粘贴块更好，因为 tokenization 更干净、还能去重。 - 附 README 吗？: 只附相关那段。500 行 README 全粘浪费上下文；一段你要遵循的约定恰好。
- 历史对话呢？: 长历史悄悄吃上下文、还会腐烂质量。换任务就开新对话，或在开新子任务前于 Claude Code 里跑
/compact，别让上一轮污染当前任务。 - prompt 顺序真这么关键？: 真的，可测量的差别。模型把前面的当背景事实、后面的当当前任务。反过来质量就掉。