pakco77 context-fold
VibeSucceed 的核心机制。把当前项目开工要读的一大堆契约/进度文档(PROJECT / HANDOFF / DECISIONS / MOMENTUM / LOG 之类)折成"一个热区 + 一堆冷档",让开工只读热区。
为什么
开工协议每次全读 N 份文档 = 每次开工没干活先烧掉上万 token。热区把它压到几百 token。append-only ≠ append-into-context:历史照留磁盘,只是别每次拖进上下文。
什么时候用
- 项目开工要读多份文档、每次开工 token 很贵。
- 契约/进度文档只增不减,越堆越大。
动作(一次 setup)
- 找出项目里开工会被读的全部契约/进度文档。
- 从它们提炼出热区
NOW.md(目标 ≤ 500 token),只含:一句定位、现在在做、上次到哪(最近一条)、本轮下一步、当前在用的 2–3 条决策、冷档索引。 - 其余文档标为冷档——不删,但开工不读。
- 改写项目开工入口(
CLAUDE.md/AGENTS.md/AGENT_INDEX.md等):把"按顺序读 N 份"改成"只读NOW.md,冷档按需取"。 - 改写收工协议:每轮只刷新
NOW.md+ 往冷档 append 一行,不把细节回写热区。
铁律
NOW.md是唯一开工必读,保持几百 token;超了就把细节沉到冷档。- 不删任何历史文档,只改"开工读什么"。
- 折叠是总结,别写解析脚本。
- 改完提醒用户用
npx ccusage量开工 token 前后降幅。
自检
setup 完,新开一轮工作应当只需读 NOW.md 就能复述"在做什么/上次到哪/下一步";若还得翻冷档才说得清,说明热区漏了东西,补进 NOW.md。