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