技能介绍

问题从哪来

大上下文窗口并不能保证「记得住」：长对话里中间段信息召回会明显下降（Lost in the Middle），而多文件、多系统、跨会话的复杂任务还会在几十轮之后把窗口塞满。若把整段聊天记录塞进 progress 文件，6KB 上限很快触顶，真正该保留的 API 端点、schema、关键决策反而被噪声淹没。

本技能针对的是估计 ≥5 步、跨系统或跨会话的工程类任务；三五步改单文件、纯问答不必启用。

五段式上下文工程管线

核心不是随手记笔记，而是一套可恢复的流水线：

Identify：判断任务是否值得纳入跟踪（步数、系统数、会话跨度、步骤依赖）。
Classify：每条信息标成 Static Anchor（永久、原文保留）或 Dynamic Flow（可压缩）。
Compress：只对动态流做渐进折叠；静态锚点与用户 pin 的内容永不压缩。
Retrieve：恢复时先读工作区根目录 progress.md（Tier 1 任务注册表），再读 .progress/task-{id}.md（Tier 2 详情）。
Persist：每完成一个实质性步骤就双写 Tier 2 与 Tier 1，并受 4KB / 6KB 硬上限约束。

压缩顺序按「信息能量」从低到高：调试栈与中间输出最先丢，只留错误类型与结论；旧已完成步骤合并为一行摘要；当前步、下一步、Key Decisions、Static Anchors 以及 .progress/pinned.md 中的条目锁定不动。代码侧禁止改成自然语言概括：保留签名与控制流骨架，用 path:L42-58 引用代替整段粘贴。

适用边界与反模式

should_track() 为 false 时不要创建任何 progress 文件，日常日志即可。同一工作区避免两个会话并行写 progress，否则状态互相覆盖。Tier 1 只放总览表，细节进 Tier 2；不要把用户/助手原文对话抄进任务文件。任务完成后文件保留 7 天再归档，避免 .progress/ 堆积拖慢恢复扫描。