现在压缩处理肯定有bug，把压缩前在执行的任务当成新的用户请求了，应该在压缩前做好标记压缩后恢复。
要求模型在项目规则中增加约束：任务执行过程中不断在文档中记录进展，压缩后从文档中读取压缩前的状态，在对话初期管用，随着对话轮次增加，3-5轮之后这个约束会被忽略，新开会话这个约束也不会生效。
2 个赞
看到截图啦，确实是个让人头疼的问题 
压缩上下文后，AI 把之前的任务当成了新请求，导致状态断层了。
你尝试用项目规则让它把进度写进文档，这个思路非常棒！但就像你说的，随着轮次增加，模型对规则的注意力会下降，确实没法彻底解决这个问题。
目前的上下文压缩机制在状态继承上确实还有优化空间，没能完美做到“无缝衔接”。作为一个目前的临时缓解方案，建议在看到上下文快满（即将触发压缩）时，先手动让 AI**「总结当前的最新进展、已修改的代码和下一步计划」，然后带着这份总结去新开一个对话**继续。这样比依赖当前的压缩机制能更稳定地保持上下文。
你发在论坛非常合适，这个深度的反馈对我们优化产品很有帮助，非常感谢！
2 个赞
内置模型不可用指的是什么？
压缩后任务状态丢失问题分析
你提出的问题非常关键。上下文压缩后，压缩前正在执行的任务状态确实可能丢失，导致 AI 将之前的任务误判为新请求。
当前可行的缓解方案
-
任务进度文件法（你已提到，确实有效）：
- 在项目规则中添加：
执行任务时，每完成一个步骤就更新 PROGRESS.md 文件，记录当前进度和下一步计划 - 压缩后 AI 会读取该文件恢复状态
- 在项目规则中添加：
-
检查点机制：
- 在规则中要求 AI 在关键节点写入检查点文件
- 格式建议：
{"current_task": "...", "completed_steps": [...], "next_step": "..."}
-
缩短单次对话长度：
- 将大任务拆分为多个短对话，减少触发压缩的概率
关于你提到的 Bug
“把压缩前在执行的任务当成新的用户请求”——这确实是压缩逻辑的缺陷，理想行为应该是压缩后保持任务状态标记。建议将此问题提交至官方反馈渠道，附上具体日志。