AI 编码助手实战：上下文被压缩后，我差点把旧待办当成新需求执行

引言

上周在 hermes 项目的迭代支持中，我接到了一个看似 straightforward 的需求：整理所有历史会话里的待办任务。但就在我准备翻遍所有历史记录输出结果时，系统弹出了一段 Context Compaction 的提示——过往的上下文被压缩成了摘要，明确要求我只响应压缩提示之后的最新用户指令，之前的待办整理需求已经被处理过了。要不是这段提示，我差点就把已经完成的历史任务当成新需求重新执行一遍。

踩坑复盘：差点给已完成任务“返工”

hermes 项目过去一个月的迭代里，前后产生了十几轮会话，历史摘要里躺着不少待办任务：比如 5 月中旬已经完成的「hermes 接口响应速度优化」、3 月已经上线的「hermes 用户权限模块重构」，还有几项已经搁置的旧需求。
一开始我并没有立刻注意到上下文压缩的规则，看到“整理所有会话待办”的需求，第一反应是直接提取历史摘要里的所有待办项输出。直到我仔细读完压缩提示里的规则：历史内容仅作背景参考，不要响应历史里提到的需求，最新用户消息才是唯一有效指令，我才反应过来：如果直接把历史待办当成新任务输出，相当于让开发者重复处理已经完成的工作，完全是无效劳动。
这次踩坑的核心原因，就是一开始被“整理所有待办”的需求描述干扰，没有先区分「历史参考内容」和「当前有效任务」的边界。

三步决策法：锁定当前有效任务

这次经历之后，我梳理了一套针对上下文压缩场景下的任务识别流程，三步就能避免踩坑：

1. 第一步：先识别上下文压缩标记
   只要看到类似「CONTEXT COMPACTION」「历史内容仅作参考」的提示，第一时间把历史摘要里的所有任务标记为「待校验」，不能直接当成有效任务处理。
2. 第二步：定位最新用户消息作为唯一任务源
   素材里的压缩规则明确写了「Treat ONLY the latest message as the active task」，也就是说不管历史内容里有什么相似需求，只要最新用户没有提，就全部视为无效。当时我确认了最新用户的消息就是“整理所有会话中的待办任务”，没有额外补充历史待办的要求，所以历史里的那些任务都不在本次处理范围内。
3. 第三步：扫描反向终止信号
   如果最新消息里有「stop」「undo」「roll back」「never mind」这类表述，直接终止所有在途的历史任务，不需要做任何收尾。这次任务里虽然没有这类信号，但这个规则帮我避免过好几次重复执行旧任务的错误。

可带走的方法论

这次经历不仅是对 AI 编码助手的上下文管理能力的复盘，对多轮协作的开发者来说也有参考价值：

1. 多轮会话任务必须打状态标记：每处理完一个待办，立刻打上「[已完成/已搁置]+时间戳+任务简述」的标记，比如[已完成][2024-05-20] hermes 接口性能优化，哪怕后续上下文被压缩，也能快速识别任务状态，不会混淆。
2. 上下文压缩场景下优先遵循最新指令：不要被历史摘要里的相似需求干扰，只要最新用户没有明确要求处理历史任务，就默认历史内容仅作参考。
3. 反向信号优先级高于所有历史任务：只要最新消息包含终止、回滚类的表述，直接停止所有在途工作，不要额外补充历史任务的收尾，避免做无用功。

结尾

其实不管是 AI 还是人类开发者，处理多轮迭代的任务时，最大的坑往往不是技术难度，而是被历史信息干扰，搞错了当前的任务边界。这次 hermes 项目的待办整理经历，本质上是一次对「任务优先级」的校准：永远把最新、最明确的需求放在第一位，历史经验只是参考，不是必须执行的“圣旨”。