“这 AI 神了”和”这 AI 没用”之间的差距，几乎从来不是模型——是你喂进去的上下文。少了，Agent 开始猜、编不存在的函数；多了，注意力被稀释，输出一堆忽略你一半约束的平庸代码。这篇给用 Claude / ChatGPT / Cursor / Claude Code 的开发者一份”喂什么、删什么、什么顺序喂”的清单，目标是产出能直接用的初稿，而不是和模型拉锯 40 分钟。
这篇主要解决什么问题
“AI 帮我写 X” 结果差，多半是上下文问题，不是能力问题。真本事是知道哪些上下文类别对当前任务重要、按什么顺序放、砍掉什么。喂对了首稿 80% 能用；喂错了你修 AI 代码的时间，比自己写还长。
这篇适合谁看
任何用 Claude / ChatGPT / Cursor / Claude Code / Codex 写非琐碎代码的开发者——比改变量名 / 一行正则更复杂的事都算。尤其在模型不熟的框架（小 DSL、内部库、刚发布的新版）或者有强”未写约定”的代码库里。
什么时候适合用
任何超过两句话的 prompt，尤其在模型不熟的框架 / 代码库里。AI 一直在给”接近但不对”的输出——病因通常是上下文缺失或顺序乱，不是模型蠢。
什么时候不建议用
看函数签名就知道答案的真琐碎任务（重命名、简单正则、单行 formatter）——粘进去直接问就行，精心准备 prompt 反而更费时间。
开始前准备
- 知道你模型的”有效上下文窗”。Claude 标称 200k 但远没到上限就开始降质；GPT、Gemini 类似。
- 用能附文件的工具（Cursor、Claude Code、Continue）打开代码库，别全靠 copy-paste。附文件比粘代码块更能保留结构。
- 定好”锚示例”：代码库里一个真实文件，能体现你要遵循的约定。
具体步骤
- 列上下文分类。 prompt 前列：语言 + 版本、框架 + 版本、要改的文件、要遵循的约定、硬约束（性能、安全、浏览器兼容）、成功标准、改动涉及的 API / 库。
- 逐类决断。 每类选：inline 写进 prompt、附文件、还是跳过。默认”跳过，除非它会改变答案”。
- 排顺序。 语言 / 框架在前 → 文件上下文 → 约定 → 约束 → 目标在最后。模型强锚在前面看到的；目标放最后留在工作记忆里。
- 砍填充。 不会改变答案的全删。1.2 万 token 里只有 2000 token 有用的 prompt，比 2500 token（2000 + 500 缓冲）效果更差。
- 用文档填知识缺口。 模型不知道的特性（半年内发布的、任何内部库），把相关文档页直接粘进来。不要指望它”记得”。
- 约定用示例展示。 附一个体现命名、错误处理、结构约定的现有文件。一个示例胜过五段”我们都怎么干、除了 X、除非 Y”。
- 首次回应后剪枝。 看模型用了哪段、忽略了哪段。砍掉被忽略的，剩下的存模板。
一份好 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")。第一次实操怎么跑
- 拿一个上周你手写 prompt 干得不错的任务。
- 按”上下文在前、目标在后”的顺序重写 prompt。
- 同模型跑两版。看哪个首稿你会直接用。
- 记下第二版里哪些上下文真被用、哪些被忽略，下次砍掉。
完成后检查
- 模型用了你写的版本号吗？看
??（新 JS）vs||（ES5）这种迹象。 - 输出遵循了你附的示例文件的约定，还是模型自己的训练偏好？
- 引了不存在的函数 / import 吗？编出来的依赖是上下文不全最响的信号。
- 你需要在 follow-up 里补细节吗？下次把那些放进原 prompt。
怎么复用这套流程
- 给每类重复任务建上下文模板：
[FRAMEWORK_BLOCK] [FILE_BLOCK] [CONVENTIONS_BLOCK] [GOAL]。填变量。 - 最佳 prompt 存在仓库
.ai/prompts/里，让整队共用同一份上下文配方。 - 上下文超出舒适窗时，次要部分用总结代替整个文件（比如”我们用 Tailwind + 这些自定义工具类：…”）。
建议的操作流程
加新 React 组件：框架版本 + 一个现有组件（作为风格示例）+ 目标。除非目标涉及样式，否则跳过整个 CSS module。一轮拿到可用初稿。加数据库 migration：migration 工具版本 + 相关现有 migration + 涉及表的 schema，其他全跳。一轮拿到可用初稿。
容易踩的坑
- 整个文件全粘——其实只有一个函数有用。浪费上下文、稀释注意力。
- 用散文描述约定（“我们用 camelCase 除了常量是 SCREAMING_SNAKE_CASE 除了在 React 组件里…”）——一个示例文件 30 行就讲清楚了。
- 目标在头、代码在尾。反过来——目标该是模型生成前看到的最后一段。
- 没写版本号。ES2024 项目里出来 ES5 语法；hooks 项目里出来 class component。
- 附你根本不用的特性文档。模型会忠实地用它，你又得删。
- 没写成功标准。“让这个更快”没基准——会拿到”看着像优化”但根本测不出差距的改动。
进阶技巧
- 重复任务：建上下文模板存
.ai/templates/。新人 onboarding 更快。 - 超出舒适窗（多数模型大约 5 万 token 代码）时，次要部分用总结代替整文件。
- 不熟的库：粘 README + 你要用的精确函数签名。幻觉断崖式减少。
- 用小快模型做上下文分流（“这 12 个文件哪些和任务相关？”），用大模型做实际代码生成。又省又稳。
怎么验收输出
- 语言 / 框架版本明写。
- 已有代码附件或总结，不用散文描述。
- 约定用示例展示，不用散文。
- 约束逐条列出，附原因。
- 目标在所有上下文之后。
- 没有不会影响答案的填充。
FAQ
- 多少上下文算多？: 模型开始忽略一部分时、或延迟开始难受时，就过线了。Claude 和 GPT 上代码重的 prompt，超过约 5 万 token 后开始降质。少通常更多。
- 要附测试吗？: 目标是让某条测试 pass 就附那条。否则跳——测试撑爆上下文，且模型常去”修”错的地方。
- inline 代码还是附件？: 30 行以上一律附件。模型处理附件比长粘贴块更好，因为 tokenization 更干净。
- 附 README 吗？: 只附相关那段。500 行 README 全粘浪费上下文；一段你要遵循的约定恰好。
- 历史对话呢？: 长历史悄悄吃上下文。换任务就开新对话，别让上一轮污染当前任务。
- prompt 顺序真这么关键？: 真的，可测量的差别。模型把前面的当背景事实、后面的当当前任务。反过来质量就掉。