上下文最佳实践：写给非技术大佬看的上下文管理

前几天，小七的同事给小七发了一张图（下图）并告知，他被 ChatGPT 限制访问了：

后面我们交流了下，发现他和 ChatGPT 的交流几乎都挤在同一个 Chat 里，而且这个窗口断断续续用了两、三个月。聊天越来越长之后，他也明显感觉到 G 老师给反馈花的时间变久了。

所以，想借着这篇文章和各位非技术人士聊聊：平时该怎么和 ChatGPT 这类 AI 工具打交道，才能让它干活轻松一点，少背点历史包袱，别聊着聊着就把自己“累崩了”。

这就要说到本文的主角——上下文（Context）。

如果你是技术大佬，为了你的节约时间，这篇可以先跳过；但很适合转给身边的非技术朋友，帮他们少踩一点坑，把 AI 工具用顺手一点。(⁎⁍̴̛ᴗ⁍̴̛⁎)

上下文是什么

在周四的 Agent 小知识部分，我们讲述过上下文是什么。在这里还是要和新读者重新科普下，上下文是什么？

上下文，就是 AI 在回答你这一刻，手边能看到、能拿来参考的信息。

你可以把它想象成一张工作桌。你刚刚问的问题，是桌上的任务单；你上传的文件，是参考资料；前面确认过的要求和结论，也是桌上放着的纸张。AI 每次回答问题，都会根据这些信息判断你现在想做什么、前面聊到了哪里、接下来该怎么回答。

乍看这么一张桌子会有什么问题呢？问题出在这张桌子的空间有限。

如果一个聊天窗口用了很久，桌上可能同时堆着旧需求、新需求、几版不同的稿子、临时讨论和各种文件。东西越来越多以后，AI 要从里面找到当前真正有用的信息，也会变得困难。比如你前面说“用 A 方案”，聊了几十轮后又改成“用 B 方案”。如果 A、B 两套信息都还混在长长的聊天记录里，AI 后面就可能拿错。

所以，管理上下文，可以理解成定期收拾 AI 的工作桌：当前要用的放在手边，过期的及时收走，重要的信息摆清楚。

下面，小七为你整理了一些拿来即用的实践。这些做法不需要理解 Token、RAG、向量数据库，也不用懂模型原理。打开任意你的 AI 工具就能用。

懒人图解版

材料输入

长材料优先传文件

需要让 AI 阅读 PDF、Word、Markdown、代码文件或一篇很长的文章时，优先使用 AI 产品提供的文件上传能力。

少做：

我把 2 万字报告全文贴到聊天框里，你先看一下……

可以改成：

我上传了 report.pdf，后面的问题都以这个文件为资料来源。

这样做，还有一个附带好处。后面再次引用资料时，可以通过文件名定位，不需要重复粘贴全文。这也提醒我们，如果你这个文件后面要复用的话，就不要叫 111.pdf、新建文档.docx 了，好好命名文件方便后续重复利用。

局部问题只给局部材料

只想修改一段开场，没有必要每一轮都附上全文。

可以给：

这是上一段和需要修改的这一段。只调整第二段，让它和上一段衔接自然。

需要检查全文结构时，再把完整稿件交给 AI。

上下文里留下当前任务需要的信息就够了，材料堆得太多，也可能增加干扰。

已给过的信息用定位代替复制

如果材料还在当前会话里，可以说：

继续参考刚才上传的 report.pdf。

看 draft.md 的第三节。

按上一条确认的四个原则修改。

能定位的信息，就没有必要每次完整复制一遍。

版本管理

新版本出现时宣布旧版本失效

一份稿子来回改了五次之后，聊天记录里其实同时存在五个版本。AI 后续回答时，仍有可能引用前面的版本。

新版本确定后，可以加一句：

上一版作废，后续只以这版为准。

如果改动很大：

前面所有稿件版本都停止参考，下面这份是当前版本。

相当于主动告诉 AI：哪些信息还有效，哪些信息可以从当前判断里排除。

定稿内容明确锁定

某些部分确认后，也可以主动告诉 AI：

这三个小标题定稿，后面不再调整。

版本号确认是 v0.7.2，后续所有内容都使用这个数字。

这一段的技术结论已确认，后面只允许调整措辞。

随着任务推进，把确定下来的内容标出来，AI 就不用每一轮重新猜哪些内容还处于讨论状态。

多个候选及时淘汰

讨论标题时，很容易留下十几个候选。

等范围缩小以后，可以说：

前面的标题方案全部排除，现在只比较下面两个。

同样的方法也适用于方案、结构、文案和设计方向。

已经放弃的选项如果一直混在聊天记录里，后面仍可能被重新拿出来。及时标记“淘汰”，可以减少这类干扰。

大改后重新提交当前完整版本

一篇稿子经过几十轮局部修改以后，“完整最新版”可能散落在十几条消息中。

这时可以重新上传或粘贴一次当前完整稿：

这是合并所有修改后的最新版。后续以这份内容为准。

让 AI 有一个明确的当前版本，比让它从前面的聊天记录里自己拼出最新版稳妥很多。

信息更新

条件变化时说明旧条件失效

比如前面一直要求面向普通用户，聊到中途又决定改成开发者。

少说：

现在换开发者读者。

可以说：

目标读者从普通用户改为开发者，之前的读者要求失效，其他要求保持不变。

这样相当于把上下文中的一条旧信息替换掉，而不是继续叠加一条新信息。

纠错时把旧信息一起替换掉

发现 AI 用错版本号时，只说：

版本号不对。

聊天里那个错误版本依然存在。

可以说：

版本号应为 v0.7.2，前面出现的 v0.7.1 作废，后续统一使用 v0.7.2。

一次把“旧信息失效”和“新信息生效”都说清楚。

临时信息标明有效期

有些要求只在当前一轮有用，也可以提前告诉 AI：

下面这个要求只对这一轮修改生效，后面不用继续参考。

或者：

这个结论只适用于当前版本，换新版后重新判断。

这样可以避免某个临时要求在聊了很多轮以后，又被当成长期有效的信息拿出来使用。

长对话整理

阶段结束时做一次上下文摘要

研究资料、定结构、改稿，其实是几个不同阶段。

一个阶段结束后，可以让 AI 做一次整理：

总结目前的工作状态，只保留：

1. 已确认事实

2. 已确定方案

3. 仍然有效的要求

4. 尚未解决的问题 删除废弃方案和讨论过程。

这个摘要可以作为下一阶段的起点。

这里有一个小原则：总结结论，少总结讨论过程。

“我们讨论过 A、B、C 三种方案”价值有限。

“最终采用 B；A 和 C 已排除”才是下一阶段真正需要的信息。

任务换阶段时可以开新对话

如果前面一直在分析论文，接下来准备基于结论写一篇完整文章，可以考虑开启一个新的会话。

新对话只带过去这些东西：

• 当前目标

• 最终确认的事实

• 固定要求

• 当前文件

• 下一步任务

旧对话里大量试错、废案和临时讨论，就不用继续带到新的工作环境里。

新开对话也不等于从头再来。把上一阶段真正有价值的信息带过去即可。

很久没聊的旧 Chat，先确认当前状态

一个 Chat 放了半个月甚至几个月，再回来时，不建议上来就说：

接着上次继续。

可以先问：

先别继续执行。告诉我你现在认为这个任务的当前版本、已确认结论和仍然有效的要求分别是什么。

先看看 AI 此刻认为“有效”的上下文，和你自己理解的是不是同一套。确认没问题，再继续往下做。

跑偏时先整理上下文

当 Chatbot 开始反复引用旧信息、忘记最新要求，继续追加“我前面说过了”“这个又错了”，聊天记录只会继续增长。

可以先暂停任务：

先停止修改。重新整理当前任务，只保留下面这些信息：

• 当前目标……

• 当前版本……

• 已确认结论……

• 本轮限制……

前面与这些内容冲突的信息全部忽略。

先把当前有效的信息重新整理出来，再继续做事。

别一直给错误上下文打补丁

有一种情况很常见：

不对，是 B。

过两轮：

刚才那个也不对，结构还是用 A。

再过两轮：

数字用新版，标题还是第三版……

这种“补丁式纠错”进行多轮之后，聊天记录里会同时留下旧信息、新信息以及一堆修正说明。

如果你发现自己开始不停打补丁，可以停下来重新给一份当前状态：

前面的修正先停止参考。下面我重新整理一份当前有效版本，后续只以这份内容为准。

上下文太乱的时候，重新整理一次，比继续往后补更省事。

日常使用

主任务对话少混入无关内容

正在一个对话里连续修改项目文章，中间突然问餐厅推荐、翻译菜单、规划旅行，这些内容和当前稿件没有关系。

这些问题可以单独开一个 Chat。

尤其是需要持续几天、反复修改几十轮的任务，让一个会话尽量围绕同一件事展开，可以少积累很多无关信息。

一条可以反复使用的指令

如果只记住一个方法，可以保存下面这段话。

当一个 Chatbot 对话越来越长、版本越来越多、回答开始混乱时，把它发出去：

先不要继续执行任务。请整理当前上下文，只保留最终确认的事实、当前有效版本、仍然生效的要求和待解决问题。前面已经废弃的版本、方案和讨论过程全部排除。整理完成后，后续任务都以这份最新状态为依据。

所谓上下文管理，其实就是持续处理几件事：哪些信息应该进入，哪些仍然有效，哪些该淘汰，什么时候需要压缩，什么时候应该换一个新的 Chat。

不需要写复杂 Prompt，也不用懂模型架构。

把 Chatbot 当成一张有限的工作桌：当前要用的资料摆上来，用完的收走，旧版本及时撤掉，桌面太乱就重新整理一次。

这样，AI 每次低头干活时，手边留下的就是当前任务真正需要的信息。