核心：我发现开发过程中你的行为具备一定模式，压缩的效率会比你想象的高几倍。
直观收益：以往压缩一次开发半轮，现在压缩一次开发1.5轮。
模式是什么？
是我：提bug，加测试，pr，云端服务器更新版本。
压缩次数少了一大半，ai性能也显著提升！真实感受！。稍后我去研究一下具体的压缩机制，我目前对压缩机制的认知就是：ai去总结上下文。
1 个赞
啊？就是200K快到了，他必压缩啊。根据你上下文。所以要快点开放1M上下文，虽说上下文最大，越会漂，但是项目大了，可以让他在超过200K不压缩。
好比一个PPT，大于200K，他读一半就压缩，造成了上下文丢失，又重新再读了一次，浪费积分。
你的以往和现在只不过刚好上下文没到200K而已。
现在的模型很多都支持1M了，trae一直都没开放上下文，不能理解，难道就改一个上下文长度，工作量很大？
我去 虽然感觉我们说的不是一个东西
是的，你的压缩是让AI做总结了，你压缩的是决策损耗。
1 个赞
我感觉压缩可能是和前端显示也有关系，或者模型在跑的时候会自动把一些东西扔出上下文。有时候一个任务下来，界面上看不到压缩，但上下文占用率反倒下降了。
1 个赞
确实评论说的不是一个东西，200K 触发压缩是容量问题，但楼主说的其实是信息问题：压缩时真正丢失的不是代码，而是对话里的决策过程。固定节奏（bug → 测试 → PR → 部署）之所以有效，是因为每一步都把状态固化进了工程，压缩之后 AI 还能从测试和 PR 描述里把状态找回来。补充一个我自己的想法：把关键决策、包括被否决的方案，写进 PR 描述或规则文件里，相当于给 AI 留一份"决策快照"，压缩后恢复明显更快。我之前有几个项目有这么试过，蹲一个楼主对压缩机制的深入研究 
。
1 个赞