上下文要满了，我让它把该记的写下来
跟模型聊到一定长度，它会提示上下文快满了。第一次遇到的时候我有点慌：这轮里讨论过的东西、定下来的方案、踩过的坑，难道就这么没了？
试了一次让它"把重要内容写下来"，结果很值。
写什么
不是写对话摘要——那种东西又长又没用。要写的是下一个接手的人（或下一个会话）真正需要知道的东西。
我让它往一份文档里写，反复迭代之后，内容固定成了这几块：
- 当前任务状态：做到哪一步了，哪些已完成、哪些没做
- 核心修复记录：改过什么、为什么改、当时的现象是什么
- 配置速查：关键配置项当前的值
- 服务清单：服务器上跑着哪些东西、端口、状态
- 备份与恢复点：备份放在哪，怎么恢复
- 常用运维命令：几条常用命令直接抄
- 已知遗留问题：哪些没修好，需要关注
- 关键凭据：只写"去哪找"，不写值
- 验证清单：新会话上手时按这个自测一遍
最后那条"凭据只记位置"是从一开始就定下的规矩。文档会在各种地方被读、被传，明文密码写进去等于到处撒。
为什么有效
会话会结束，但工作不会。 一个任务拆到几天里做，每次新会话都从零开始，模型不知道昨天定了什么、试过什么、哪些路已经排除了。
那份文档补的就是这个缺口。新会话第一件事是读它，读完就大致知道"现在在哪、下一步该干什么"。
我甚至把它当成跨会话的入口：新会话开口第一句经常是"读一下桌面上的交接文档"，读完再提具体需求。
一个具体的好处在"排除项"
文档里最有价值的不是"已完成"，而是试过但没用的方向。
比如某个问题我试了三种方案都不行，如果不记下来，下个会话很可能重新试一遍——因为看代码看不出来"这条路已经走过了"。而模型在没有上下文时会做出很合理的推断，然后走进同一个坑。
"什么已经试过、为什么不行"比"现在是什么状态"更难重建。
顺带说一句方法论
那份文档不是一次写成的，是一轮轮长出来的。每次"上下文快满"的时候，就补一轮。慢慢地它从一段笔记变成了一个有结构的文档，还被后来的人拿去当参考。
这件事本身也不复杂：让模型替你写备忘录。 它知道你刚才聊了什么，只要你说清楚"写给谁看、要包含什么"，它写出来的东西比事后自己回忆要准。