文章目录一个对话框能聊多久上下文是租金文件才是资产大上下文是个骗局别一条道聊到底文件才是长期记忆图片别只存在聊天里Git 会告诉你代码现在什么样别反复让 AI 总结聊天提问不是越长越好发现 AI失忆了怎么办一个对话框能聊多久上下文是租金文件才是资产不知道你有没有过这种体验。跟 AI 写代码前十几轮还挺顺的改啥都一次到位。聊着聊着就不对劲了——刚才说过别动的文件又改了刚排除的方案换个说法又冒出来你纠正它道歉下一轮照样错。这时候很多人的第一反应是模型不行或者我得把指令写得更清楚。其实大概率不是模型的问题也不是你指令写得不够细。是上下文满了。AI 进入了“愚蠢区”。大上下文是个骗局厂商宣传 100 万 token、200 万 token听着很厉害好像什么都能塞进去。真实情况是窗口越大不代表越好用。先说一个 2023 年提出的现象——“lost-in-the-middle”模型对上下文开头和结尾的信息记得最清楚中间部分最容易丢准确率能掉 30% 以上。后来向量数据库公司 Chroma 也做了类似测试覆盖 18 个主流大模型包括 GPT-4.1、Claude Opus 4、Gemini 2.5 Pro结论一致上下文变长之后所有模型的质量都在下降没有例外。你的窗口是 20 万还是 200 万不改变这个规律。中间就是信息的坟场。一个扎心的数字很多天天用 AI 写代码的人实际只用到标称容量的 10% 到 25%。有人明明有 100 万 token 的窗口却故意控制在 10 万以内因为超过就开始出幺蛾子。上下文消耗得比你想的快得多因为 Agent 吃进去的不只是你说的话。让它排查一个启动问题它会先 git status再 find 和 grep读几个文件跑一次测试翻报错日志改代码再测一遍——每一步的输出都留在窗口里。读一个文件几千 token跑一次测试输出几千 token失败的补丁、工具调用的日志、你纠正它的话每一轮都在往里堆。一个专注的调试会话1 到 2 小时就能突破 10 万 token。所以你感觉聊着聊着就变蠢了不是错觉。是上下文里的噪音超过了模型能稳定处理的范围。上下文窗口不是越大越好。是越干净越好。别一条道聊到底最朴素也最有效的办法一个任务一个对话。修 bug 开一个对话写新功能开另一个调样式再开一个。别把所有事情都塞在同一个窗口里。前面任务的搜索结果、失败尝试、报错日志对后面的任务来说全是噪音。判断标准不看聊了多少轮看它的行为。出现下面这些情况就是信号重复问你回答过的问题又把已经排除的方案拿回来试动了你说过不能改的文件分析越来越绕开始做无关操作你纠正一次下一轮照犯然后道歉这时候别再纠正了直接开新对话。因为上下文已经被污染里面全是错误假设、失败尝试和你俩来回拉扯的内容。继续在这个基础上聊每一轮都是在垃圾上堆垃圾。开新对话不是从头再来。你带着一份压缩好的交接笔记过去比带着 50 轮原始聊天记录靠谱得多。交接笔记怎么写目标要解决什么问题验收标准是什么已完成改了哪些文件改了什么确认过的决策选了什么方案为什么什么不能改踩过的坑试过什么为什么不行有证据下一步接着该干什么这份笔记不用长三五段话就行。关键是你自己过一遍——AI 自动压缩的摘要可能会漏细节你检查一遍再拿去开新对话质量完全不一样。最好直接把它落成项目里的一个文件下一节会说。这也是很多资深玩家的做法不等 AI 自动压缩自己主动压。自动压缩是到 95% 才触发那时候损伤已经造成了有人把阈值调到 70% 就开始压一致性明显更好。文件才是长期记忆对话窗口是临时工作台文件才是你的项目资产。这个区分想清楚了很多问题就有答案。项目里值得长期留下的东西按职责分开存内容放哪儿回答什么问题项目规则和约定AGENTS.md这个项目该怎么干活当前进展STATUS.md现在做到哪了任务交接HANDOFF.md换对话后怎么接上重要决策DECISIONS.md当初为什么这么定源代码、文档、日志项目目录需要时按需读取截图、流程图assets/ 目录长期保存视觉信息探索过程和试错当前对话用完就扔不是每个项目都得建全套。小项目一个AGENTS.md加一个STATUS.md就够了复杂的再补HANDOFF.md和DECISIONS.md。核心不是文件数量是把长期有价值的信息从聊天记录搬进项目里。规则和约定写进AGENTS.mdCodex 会自动从当前目录往上找它越近的优先级越高。别写太长默认总大小限制 32KB写得再细也装不下。进度和决策写进STATUS.md每次换对话前更新开新对话第一句就是先读 STATUS.md。HANDOFF.md就是这份交接笔记落成文件后的样子。它不追求完整说清三件事就行现在做到哪了、哪些路已经排除、下一步干什么。# HANDOFF ## 当前任务 修复 xxx 模块启动失败 ## 已完成 - 定位到 xxx改了 xxx.java ## 已排除 - Redis 正常 - 不是超时问题日志显示连接池耗尽 ## 重要决策 不要改 xxx其他模块依赖它 ## 下一步 1. 检查 xxx 2. 跑测试验证有了它换上下文就顺了存 HANDOFF关掉对话开个新的读 AGENTS.md 和 STATUS.md读 HANDOFF接着干。图片别只存在聊天里图片是最容易让人产生错觉的东西。你刚发的时候清清楚楚AI 也分析得头头是道。过了二十轮再问它那张图上画了什么它可能已经不记得了。上下文压缩的时候图片是最早被文字化的——从清晰的像素变成一句用户曾发送过一张关于 XX 的图片。两个动作搞定第一重要的图存到项目里。用能看懂的名字比如login-error-2026-09-01.png别叫image_3.png。过两周你自己都记不住 image_3 是什么。第二在旁边写个文字说明。比如配个architecture-v2.md写清楚图里有几个模块、箭头是什么意思、哪些决策是确认过的。下次 AI 先读文字需要看布局细节的时候再打开图片。大文件也一个道理。几十 MB 的日志别贴到聊天里告诉 AI 文件路径和要看的范围让它自己去翻。一句话总结聊天窗口不是硬盘。Git 会告诉你代码现在什么样还有个东西别忘了git。聊天记录说的是我们讨论过什么git 说的是代码现在到底是什么样。开新对话时让 Agent 先跑一遍git status和git diff比让它读聊天记录靠谱得多。代码和 git 是事实聊天记录只是过程。别反复让 AI 总结聊天上下文快满的时候很多人会让 AI总结一下我们前面聊了什么然后接着聊聊一会儿再总结一次。这招不是没用主动压也比等着它 95% 自动触发要好。但压缩终究是补救不是沉淀那次调用的输入是当前的全部上下文本身就是会话里最贵的一次调用而且摘要里漏掉的细节基本找不回来。更根本的问题是这两种做法回答的不是同一个问题总结聊天回答的是我们刚才聊了什么保存状态回答的是继续这个任务最需要知道什么后者信息密度高得多也不会把试错的废话一起带到下一个对话里。提问不是越长越好很多人跟 AI 合作效率低不是因为说少了是因为说乱了。一上来就帮我写个 XX 功能AI 猜着做你来回纠正五轮才对齐。这五轮对话全是浪费的 token还污染上下文。更高效的方式是先对齐再动手。要说的事和交接笔记是同一套——目标、现状、约束、踩过的坑——只是把时间点提前到开工之前。这套里最容易漏掉、也最值钱的是约束和踩过的坑你说一句不用 MyBatis-Plus用原生 MyBatis就省了 AI 给你生成一堆 MyBatis-Plus 代码再被你否掉的来回。你说一句加长超时时间没用日志显示是连接池耗尽就省了它再去试一遍这个废方案。一段话能说清的事别拆成五轮背景Spring Boot 3.4.3 项目启动报 BeanCreationException 目标找到根因并修好编译和测试都要过 约束不能降版本不能改数据库结构 我的判断怀疑是 Jakarta 迁移引起的 先做什么搜索项目代码验证这个判断先别改 不要做别顺手升级其他依赖别做无关重构比帮我解决这个报错长一点省掉的却是它猜错方向后的五轮返工。还有个小习惯特别管用先让 AI 复述一遍它理解的任务。“你先说一下你理解的任务和计划我们确认了再开始。”多花一轮对齐省后面五轮返工。这笔账怎么算都划算。发现 AI失忆了怎么办按这个顺序排查一般能找到原因。1. 它真的读到文件了吗让它列一下本轮读了哪些文件、得出什么结论、还有什么文件没读到。很多时候是路径错了或者文件不存在。2. 规则文件位置对吗Codex 从当前目录往上找 AGENTS.md不在正确的层级就读不到。3. 状态文件更新了吗STATUS.md 里的内容是不是还停留在上一个阶段4. 上下文是不是被噪音塞满了看看 /status 里的 token 用量。太多日志、重复截图、无关输出该清就清该开新对话就开。5. 路径在当前环境可见吗本地路径、远程服务器、容器里的路径不是一回事。6. 代码现在到底是什么样聊天记录说的是过程git status和git diff说的才是事实。开新对话先让它看一眼。回到开头那个问题一个对话框能聊多久答案不是固定轮数。是看上下文还清不清醒。任务还在同一条线上就继续聊开始跑偏、道歉、反复纠正了就别硬撑开新的。把决策和进度写进文件让对话只承载当前这一轮的思考。上下文是租金付了就没了。文件是资产留下来还能复用。这个账算明白了跟 AI 协作的节奏会顺很多。你是在哪个瞬间发现 AI 突然变笨的评论区聊聊看看大家踩过哪些一样的坑。