AI编码助手踩坑实录:上下文压缩时整理待办任务,我差点做了重复开发
引言
上周在hermes项目的v2.3迭代收尾阶段,我让AI编码助手整理所有历史会话里的待办任务,本来以为是个简单的检索工作,结果差点闹出重复开发的笑话——AI把3个月前已经完成的「日志上报模块性能优化」任务又列进了待办清单,对应的PR早就合并到了主分支,如果当时没注意到这个时间异常的条目,至少会浪费3-4人天的工作量,还会和已经落地的代码逻辑冲突。
事后复盘才发现,问题出在AI编码助手的上下文压缩机制上:当会话历史过长时,系统会把早期内容压缩成摘要保留,同时附带「仅处理最新指令,忽略压缩上下文里的历史任务」的默认提示,但如果没有明确给AI划清边界,它很容易把压缩摘要里的历史待办也当成当前需要处理的内容。这次踩坑也让我总结出了一套处理跨会话待办任务的可行方案。
踩坑现场:上下文压缩导致的待办混淆
当时的需求很简单:整理hermes项目所有会话中尚未完成的待办任务,统一输出到项目Wiki里。AI刚开始执行的时候还一切正常,直到它输出的待办列表里出现了一条标注时间为「2024-02-15」的任务,而这个任务我在3个月的迭代复盘里已经明确标记为「已完成」,对应的代码也早就合并到了主分支。
翻看AI的返回内容才发现,它触发了上下文压缩机制:早期的会话历史被压缩成了摘要,里面包含了当时遗留的待办任务,而AI没有正确区分「压缩摘要里的历史参考内容」和「当前需要处理的有效待办」,直接把所有历史待办都列了出来,甚至没有标注任务的状态和来源会话。后来才注意到返回内容里带了系统默认的CONTEXT COMPACTION提示,说明AI已经收到了「不要处理历史任务」的规则,但没有正确识别哪些内容属于需要忽略的历史范畴。
解决方案:加一层过滤逻辑,把无效待办拦在门外
发现问题后,我第一时间叫停了AI的任务整理,明确了两个核心规则:
- 仅处理最近30天、活跃会话里的待办,所有超过30天、已关闭会话的任务一律视为历史参考,不得纳入当前待办清单
- 所有输出的待办必须标注「来源会话ID、最后更新时间、当前状态」三个字段,无法标注的直接过滤
为了落地这个规则,我让AI写了一个简单的待办过滤函数,直接对接项目当前的TODO数据库,自动过滤无效任务:
from datetime import datetime
from typing import List, Dict
def filter_valid_todos(todos: List[Dict], active_sessions: List[str]) -> List[Dict]:
"""过滤有效待办:仅保留活跃会话、30天内更新、未标记完成的任务"""
valid = []
for todo in todos:
# 跳过已完成任务
if todo.get("status") == "completed":
continue
# 跳过非活跃会话的任务
if todo.get("session_id") not in active_sessions:
continue
# 跳过超过30天的 stale 任务
if (datetime.now() - todo["updated_at"]).days > 30:
todo["note"] = "历史参考,无需处理"
continue
valid.append(todo)
return valid
之后AI输出的待办清单就完全符合预期了,所有过时任务都被自动过滤,剩下的待办都标注了来源和更新时间,直接同步到Wiki即可,没有再出现历史任务混入的问题。
落地经验:AI协作时处理上下文压缩的3个原则
这次踩坑也让我总结出了3个和AI协作时处理上下文压缩的通用原则,之后用AI整理跨会话任务再也没有出过问题:
- 最新指令优先,压缩上下文仅作参考:下指令时 explicitly 说明「压缩上下文里的历史任务仅作背景参考,不得作为当前任务的输入来源」,避免AI把历史冗余内容当成有效信息
- 所有输出必须带校验维度:要求AI输出的任何跨会话内容(待办、问题列表、代码片段等)都必须标注来源、时间、状态等校验信息,没有标注的直接打回
- 关键结果必须二次确认:AI整理完待办、问题列表这类会影响后续开发的内容后,一定要先人工过一遍,和当前项目的迭代计划、TODO文档对齐,确认没有重复/过时内容再推进执行
结尾
AI编码助手能大幅提升开发效率,但上下文压缩带来的历史信息混淆是很多开发者都会遇到的隐性坑。这次在hermes项目的踩坑经历让我意识到:和AI协作时,明确的边界规则比模糊的需求描述更重要,加上一层简单的校验过滤,就能避免90%以上的重复劳动。
如果下次你也需要让AI整理跨会话的任务、问题或者历史文档,不妨先试试上面3个原则,至少能少走很多弯路。

浙公网安备 33010602011771号