![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-2726701/a1a6cb5f179ef8252a1d364a7422df1b.png)
不知道你有没有过这种体验。

跟 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/ 目录|长期保存视觉信息|
|探索过程和试错|当前对话|用完就扔|

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-2726701/9f62737e6540dd3227c3301cf17702a3.png)
不是每个项目都得建全套。小项目一个 `AGENTS.md` 加一个 `STATUS.md` 就够了，复杂的再补 `HANDOFF.md` 和 `DECISIONS.md`。核心不是文件数量，是把长期有价值的信息从聊天记录搬进项目里。

规则和约定写进 `AGENTS.md`，Codex 会自动从当前目录往上找它，越近的优先级越高。别写太长，默认总大小限制 32KB，写得再细也装不下。

进度和决策写进 `STATUS.md`，每次换对话前更新，开新对话第一句就是"先读 STATUS.md"。

`HANDOFF.md` 就是这份交接笔记落成文件后的样子。它不追求完整，说清三件事就行：现在做到哪了、哪些路已经排除、下一步干什么。

```
#&nbsp;HANDOFF

##&nbsp;当前任务
修复&nbsp;xxx&nbsp;模块启动失败

##&nbsp;已完成
-&nbsp;定位到&nbsp;xxx，改了&nbsp;xxx.java

##&nbsp;已排除
-&nbsp;Redis&nbsp;正常
-&nbsp;不是超时问题，日志显示连接池耗尽

##&nbsp;重要决策
不要改&nbsp;xxx，其他模块依赖它

##&nbsp;下一步
1.&nbsp;检查&nbsp;xxx
2.&nbsp;跑测试验证
```
有了它，换上下文就顺了：存 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 突然变笨的？评论区聊聊，看看大家踩过哪些一样的坑。

跟 AI 写代码，前十几轮还挺顺的，改啥都一次到位。聊着聊着就不对劲了——刚才说过别动的文件又改了，刚排除的方案换个说法又冒出来，你纠正它道歉，下一轮照样错。

一个对话框能聊多久？上下文是租金，文件才是资产

上下文窗口越大不代表越好用，信息拥挤会导致AI“变笨”；有效做法是控制上下文长度、用文件保存长期信息、开新对话时用交接笔记。 摘要要提炼出这些核心内容，并且控制在150字以内。可以用比较简练的方式把这些问题和解决方案概括出来。</think>对话窗口越大不代表越好用，过长上下文会导致AI进入“愚蠢区”，信息拥挤造成质量下降。高效协作的关键是保持上下文干净：任务内聊，任务毕关

人工智能

开发工具

职业发展

和AI协作越聊越"笨"？别怪模型，是上下文被污染了。大窗口并非万能，中间信息易丢失，超10万token后质量就下滑。有效做法是：一个任务开一个对话，主动用HANDOFF.md交接笔记（目标、已完成、已排除、下一步），把决策和规则写入AGENTS.md和STATUS.md，图片存项目目录并配文字说明，用git看代码现状而非依赖聊天记录。保持上下文干净，效率远超硬撑长对话。

向量数据库

代码解释

数据库

服务器

容器

Redis

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

和AI协作越聊越"笨"？别怪模型，是上下文被污染了。大窗口并非万能，中间信息易丢失，超10万token后质量就下滑。有效做法是：一个任务开一个对话，主动用HANDOFF.md交接笔记（目标、已完成、已排除、下一步），把决策和规则写入AGENTS.md和STATUS.md，图片存项目目录并配文字说明，用git看代码现状而...

一个对话框能聊多久？上下文是租金，文件才是资产-腾讯云开发者社区-腾讯云

一个对话框能聊多久？上下文是租金，文件才是资产

一个对话框能聊多久？上下文是租金，文件才是资产

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐