StarmoAI
日记

日记

AI

AI 上下文压缩的困惑与经验总结

当 AI 在长对话里逐渐‘失忆’，一个零基础开发者如何在反复报错、约束与取舍中重新理解项目协作。

6 分钟更新于 2026-08-28

曾经有段时间，我因为 AI 的上下文压缩而导致的、类似“失忆”的问题，被困在原地很久。

我逐渐发现，想要真正落地一个完整、可持续迭代的项目，会遇到很多超出自己能力范围的技术问题。

从模型问题，到上下文问题

一开始，我把这个问题归结为某个模型或者应用的问题。后来经过多轮测试和不同大模型的能力对比，我发现：虽然不同的大模型有不同的表现，但不管是什么模型，在对话经历几轮压缩之后，输出都会缩水，严重的时候甚至会出现幻觉。

这也是我一直很担心、却始终没有解决掉的事情。

我看到它的错误率在上下文被压缩以后开始呈现指数级飙升：从刚开始每次写完代码后都是验证通过的全绿界面，到后来频繁出现大面积报错。然后删掉、重改，再删掉、再重来。

就这样看着它反反复复地报错、找错、分析、纠错，看着它在一个循环里死死挣扎。

这让我意识到一个非常棘手而现实的问题：

一个对话窗口，根本无法独自承载一个从想法到落地、还要持续迭代的完整项目闭环。

一个项目一定会经历多次升级、纠错和调试，但在这个过程中，上下文会越堆越长。

规则越多，不一定越可靠

后来我想，不行就把规则强行加给它。每当感觉它开始出问题，就直接开一个新的窗口，把规矩再发一遍。

但后来我发现，它还是会出错。只要稍微有一个放松、懈怠的地方，就可能出现问题。

于是我开始撰写一套完整的参数约束，并要求它在每一次调试以后都写报告，告诉我：改了什么，为什么改。

可是，条款限制也会因为内容过长，导致注意力分散。因此我只能做一个取舍：保留最高价值的限制提醒，让整个过程停留在一个相对可控的阈值里。

再后来，我开始尝试不给它过多的限制框架，只说清楚自己真正想要的是什么，然后观察这样的方式能不能减小出错概率。

原来，我已经走了这么远

当我在思考这些问题时，突然意识到：原来自己这个最初连域名都不知道的人，已经靠着打不倒的小强一样的意志力，默默走了这么远。

那是一条极其孤独且漫长的路。

没有技术背景，没有资金来源，还要面对父母的压力，手里只有一台经常卡死机的办公款笔记本电脑。

但我并没有觉得这是一种不幸，反而觉得是一种成长。因为在这个过程中，我能不断学习新的知识和技能，这让我觉得特别过瘾，甚至有点期待它会报错——这样，我就能让以后的自己少踩一点坑。

创造力和可控性，只能二选一吗？

话说回来，用在 AI 上也一样：前期很多问题没有考虑到，后期再调整会是一个非常大的麻烦；但过多的硬性要求，也会扼杀它的创造力和想象力，最终变得僵化。

对于有开发经验的人来说，可控是一件好事，因为它能让整个项目的风险降低。但对于一个新手来说，这种取舍很残酷。

我只能二选一，而我选择了最稳妥的方式。

因为新手不会写代码，出了问题只能找 AI。但是当 AI 在同一个对话窗口里经历上下文压缩之后，它会遗忘很多事情，效率非常低，也容易继续报错。此时，这个窗口已经不再适合继续进行深度讨论。

我们只能再开一个新的窗口，重新整理背景、目标和规范。可是，这样又非常麻烦。

真正重要的，是提前想清楚

后来，我开始寻找一些更加高效、真正可以落地的协作方式，而不是空谈概念。

不管我们写的是 Markdown 文档、Skill，还是自然语言提示词，都无法彻底阻止 AI 在项目后期出现不可控的问题。

因此，我们必须提前规划好：

  • 自己到底想要什么
  • 每一步想达到什么效果
  • 任务应该怎样进行
  • 后续怎样更新和迭代
  • 哪些规矩必须始终遵守

这些前期决定，会直接影响一个项目最终能不能完整做完。

如果不提前建立约束和规范，到了后期再进行大批量修改，会变得非常困难，甚至可能推倒重来。这样不仅会花费大量费用，也会让整个项目的时间线被不断拉长。

我现在仍然没有一个能解决所有上下文问题的答案。但至少，我开始明白：与 AI 一起完成长期项目，真正重要的并不是写出一份无限长的提示词，而是知道什么必须留下、什么可以舍弃，以及什么时候应该停下来，重新开始。