上下文预算
该给什么、不该给什么，比给得多重要。
把上下文当成有限的预算来分配。多给一份无关内容，就少一分对关键内容的注意力。模型的输入窗口不是无限仓库，而是有限注意力——围绕这个认知做取舍，是写好提示词、用好 AI 编程工具的基础。claude-code-best-practices
你会遇到的现象：
- 把整个项目丢给它之后，回答反而变含糊了
- 聊得越久，它越容易违反前面定好的规则
- 贴了一大段报错日志，它抓错了重点
该给什么
| 给什么 | 占比 | 说明 |
|---|---|---|
| 项目约束 | 少量 | 精简的规矩，长期有效。放在最前面 |
| 当前模块的规格 | 少量 | 数据结构、状态、边界。这一块最值得占位置 |
| 直接相关的文件 | 中等 | 指名要改的那两三个，加上它们依赖的接口定义 |
| 这一次的指令 | 少量 | 放在最后。关键约束在这里重申一遍 |
| 留白 | 三成左右 | 给它推理和输出用。填满了它就没有余地了 |
关键约束值得说两遍：一遍在开头的项目规则里，一遍在这一条指令里。这是针对「中间容易被忽略」的直接对策。
判断「直接相关」也有个简单标准：这一轮要让 AI 改哪几个文件，就把哪几个文件连同它们依赖的接口定义给全——边界划在「会被这次改动影响的」以内，超出就是噪音。
不该给什么
- **整个仓库。**让它自己翻遍所有文件，看起来省事，实际是把噪音塞满了窗口。指名要改哪几个。
- **完整的报错日志。**先自己扫一眼，把关键的那几行贴过去。几百行栈信息里有用的通常不到十行。
- **上一个话题的全部历史。**做完一件事就换个会话，别把上一件事的讨论一路带着走。
- **大段的示例数据。**给两三条代表性的就够，包括一条边界情况。
- **已经定过又反复推导的东西。**写进文件，让它去读，别让它每次重新想一遍。
有个简单的自查：如果你自己都不确定某段内容这次用不用得上，那多半就不该给。
什么时候清空重来
| 信号 | 该做什么 |
|---|---|
| 开始违反前面定好的规则 | 把关键决定写进文件，然后开新会话 |
| 它开始重复之前说过的话 | 说明有效信息被稀释了，重开 |
| 换了一个不相关的任务 | 直接开新会话，不要接着聊 |
| 连续三轮都没改对 | 停下。多半是描述有问题，重新写清楚再开一轮 |
重开会话之前，先让它把这一轮的结论总结成一份可以粘进文件的文字。这样重开就不等于从零开始。
还有一个结构层面的做法：按功能组织代码目录。做登录相关的改动只需要读 auth 一个目录，比从每一层各读几个文件省下大量上下文。这个选择在项目开始时几乎不花成本，后期改起来很贵。
**怎么检查上下文给得对不对。**观察一次完整会话：如果 AI 在第三轮之后开始问你已经给过的信息，说明前面的关键内容被稀释了——把该沉淀的写进文件，然后重开。如果它每一轮都能直接回答、不用反复确认，说明预算用对了。