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

简介: 本文面向非技术用户,通俗讲解如何科学管理AI对话的“上下文”——即AI当前能参考的信息。通过整理工作桌的比喻,提供实用技巧:传文件代替粘全文、及时作废旧版本、精简材料、分阶段新开对话等,帮AI轻装上阵,避免因信息过载而“累崩”。

前几天,小七的同事给小七发了一张图(下图)并告知,他被 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 每次低头干活时,手边留下的就是当前任务真正需要的信息。

相关文章
|
1月前
|
存储 Shell 数据库
Agent 小知识|长任务不重来:Agent 状态保存的工程设计
本文详解Agent状态的核心概念与工程实践:它不是简单记忆,而是任务执行的实时快照,涵盖进度、环境、内部判断与资源约束。通过结构化Schema、分层检查点和状态栏机制,实现可靠暂停恢复、高效决策与长程连贯性。
142 0
Agent 小知识|长任务不重来:Agent 状态保存的工程设计
|
9天前
|
存储 Shell API
拆解 dsh 系列:从源码和版本变化看 DeepSeek Harness 的设计取舍
DeepSeek Harness(dsh)发布仅两周,实则历经两个月内部打磨。本文基于Git历史与npm发布数据,梳理其从0.0.1-rc.1到0.1.1-rc.2的演进:命名重构、定位升维(Coding Agent→Agent Harness)、核心与扩展边界持续厘清,展现一个开源智能体运行时如何审慎定义自身能力疆界。
132 1
拆解 dsh 系列:从源码和版本变化看 DeepSeek Harness 的设计取舍
|
16天前
|
存储 JavaScript 安全
dsh 拆解系列 Vol.01:没有特权内核的 Agent 运行时
DeepSeek Harness(dsh)是DeepSeek开源的Agent运行时框架,秉持“一切皆插件”理念,将模型适配器、工具、会话、主循环等全部解耦为可配置、可替换、可卸载的插件,基于Cordis元框架实现时空可组合性。当前v0.1.0-rc.7为开发者预览版,MIT协议,强调工程可扩展性而非仅功能堆砌。
165 2
dsh 拆解系列 Vol.01:没有特权内核的 Agent 运行时
|
9天前
|
人工智能 安全 前端开发
实测推荐 3 个 Skill,轻松上手 Codex 网页设计与交付流程
小七实测3个前端Skill:`design-taste-frontend`强化设计规范与双主题支持,`humanizer`去除AI腔、优化文案自然度,`better-interface`完成可访问性等交付级审查。结果表明——当Agent基础能力已强,Skill核心价值转向固化专业标准、流程与质量门禁。
105 0
|
10天前
|
安全 前端开发 数据挖掘
Agent 小知识 | Skill 的设计与生命周期:从工具接口到能力模块
本文探讨Agent的“Skill”概念:当Agent拥有工具与环境后,仍需可复用的任务方法论。Skill是面向特定任务的能力模块,包含流程、原则、约束与资源,支持发现、加载、组合与复用,使Agent行动更稳定、一致、可扩展。
Agent 小知识 | Skill 的设计与生命周期:从工具接口到能力模块
|
17天前
|
传感器 JavaScript 机器人
Agent 小知识|Agent 环境工程:部分可观测性、状态转移与执行隔离
Agent环境是其执行动作的外部世界,涵盖代码仓库、数据库、网页等动态对象。它决定Agent能观察什么、改变什么,并需持续验证状态变化是否符合预期,是任务落地的关键支撑。
|
21天前
|
缓存 前端开发 测试技术
Xiuno BBS 审计之问题:全局变量滥用,状态混乱
本文揭示Xiuno BBS 4.0.4中131处global变量滥用问题:状态共享混乱、函数副作用不可控、单元测试难、并发易串态、重构成本高。XIUNOX版已通过依赖注入与单例封装优化修复,供二次开发参考。(239字)
118 2
|
20天前
|
SQL Serverless 数据库连接
Serverless 数据库最怕什么?不是没连接,而是连接“太多了”
Serverless 数据库最怕什么?不是没连接,而是连接“太多了”
52 1
|
21天前
|
SQL JSON 分布式计算
一个 SQL 字段到底是怎么算出来的?我做了一个能给出“证据”的血缘工具
Scope Lineage 是一款面向 Spark/Hive 的开源 SQL 字段血缘分析工具,专注回答“字段怎么算出来”:不仅追踪物理来源,更识别常量生成、保留完整表达式与加工步骤,并明确标注证据边界(Verifiable Lineage),支持复杂 CTE/UNION/聚合场景。
86 1
|
24天前
|
人工智能 弹性计算 运维
技术复盘|缺失基础FAQ内容体系,是通义千问无法调取企业内容应答的核心短板
阿里云通义千问落地中,企业常陷“收录无应答”困局:虽完成OSS部署、ECS配置等基建,但因缺失标准化FAQ体系,大模型无法精准调取专属内容。实操表明,结构化FAQ才是适配意图识别、提升问答匹配度与品牌曝光的核心载体。
148 0