凌晨三点，你盯着终端，AI 编程助手刚把你要修的函数重写了一遍，却连带弄坏了三个模块。你往上翻聊天记录，发现它早就忘了四小时前你定下的架构约束——这不是它笨，而是它的上下文窗口有一半被浪费了。

上下文窗口不是越大越好，而是越用越少

AI 编程助手（如 GitHub Copilot、Cursor 等）依赖一个有限的上下文窗口来处理你的指令和项目信息。这个窗口就像一块白板，写满了就再也写不下新内容。当你连续对话数小时，早期的重要指令——比如“这个模块不要动”“遵循现有的错误处理模式”——会被后续的对话内容逐渐挤出窗口。

信号中提到的“数字痴呆”现象，正是这种上下文溢出的典型表现。AI 不是真的“忘记”，而是它的工作记忆里已经没有那些信息了。你可能会想：窗口不是很大吗？但实际可用空间远比你想象的小。模型需要同时容纳你的指令、代码片段、历史对话、以及它自己的中间推理，这些都会占用窗口。

更关键的是，上下文窗口的消耗是单向的——一旦信息被挤出，AI 就无法主动找回。你只能手动重新提供，或者接受它基于不完整信息做出的错误决策。

你的聊天记录里，一半是 AI 的‘自言自语’

打开一次长时间的 AI 编程会话，你会发现聊天记录里充斥着大量 AI 生成的中间推理、重复代码和无关输出。比如，它可能会在每次修改前先解释一遍自己的思路，或者输出一段完整的函数实现，即使你只要求改一行。这些内容看似无害，却实实在在地占用了上下文窗口。

信号中描述的场景——AI 自信地重写函数，却弄坏其他模块——往往就是因为这些“自言自语”挤掉了关键约束。AI 在生成过程中，会不断“思考”下一步，这些思考过程（在技术上称为“思维链”）也会被计入上下文。如果它反复尝试多种方案，这些尝试记录都会堆积起来。

结果就是，你的有效指令和项目上下文，可能只占窗口的一半，另一半全是 AI 自己的输出。当窗口接近饱和时，早期信息最先被丢弃，而 AI 却浑然不觉，继续基于残缺的记忆工作。

为什么 AI 会重写你不想动的代码？

当上下文丢失后，AI 对任务边界的理解会变得模糊。你让它“修复这个函数的 bug”，它可能理解为“重写这个函数”，因为它已经忘了你之前说过“保持其他模块兼容”或“只改参数校验部分”。

信号中的例子很典型：AI 重写了一个函数，结果破坏了三个模块。这不是它故意为之，而是它根本不知道那些模块依赖这个函数的现有行为。在它的“记忆”里，这个函数是孤立的，改动它不会影响其他部分。

这种破坏性修改，往往发生在会话后期，因为此时上下文窗口最拥挤，早期约束最容易被挤出。你可能会发现，AI 在会话开始时表现良好，但越到后面越“失控”。这正是上下文管理不善的代价。

精简上下文的三个实用技巧

要减少上下文浪费，最直接的方法是精简输入。以下是三个可立即上手的技巧：

第一，手动清理无关对话。 如果会话中讨论过与当前任务无关的话题（比如闲聊、探索性提问），可以主动删除这些消息，或开启新会话。很多工具允许你“压缩”或“清除”历史记录，别舍不得。

第二，用摘要压缩历史。 如果必须保留长对话，可以定期让 AI 总结之前的要点，然后用摘要替换完整历史。例如，在会话中途，你可以说：“请用三句话总结我们到目前为止的决策和约束。”然后把这段摘要作为后续对话的起点。这样既保留了关键信息，又大幅减少了上下文占用。

第三，将大任务拆分为小步骤。 不要一次性提出一个庞大的需求，比如“重构整个登录模块”。这会迫使 AI 在上下文中保留大量中间状态。相反，把它拆成“先修改数据库连接”“再更新接口定义”“最后调整前端调用”等小任务，每个任务单独发起会话或明确分段。这样每个步骤的上下文压力都会小很多。

让 AI 记住规则的‘外部记忆’方案

除了精简上下文，你还可以把关键规则“外置”，让 AI 不必依赖窗口内的临时信息。最有效的方式是利用项目文档、注释和外部文件。

例如，在项目根目录维护一个 AI_CONTEXT.md 文件，里面写明架构约束、编码规范、常用命令等。每次开始新会话时，让 AI 先读取这个文件。这样，即使上下文窗口被后续对话占满，这些规则也不会丢失，因为它们存储在文件系统中，而不是窗口里。

同样，在代码中写清晰的注释，也能帮助 AI 理解意图。比如在函数上方注明“此函数被三个模块调用，修改需谨慎”，AI 在生成代码时就会注意到这些提示。

外部记忆的核心思想是：不要依赖 AI 的“记忆”，而是把信息放在它随时可以查阅的地方。这就像给 AI 一本参考手册，而不是指望它记住你口头说过的话。

分步任务：把大需求拆成小指令，AI 才不会‘迷路’

分步任务不仅是精简上下文的技巧，更是提高 AI 准确性的根本方法。当任务过大时，AI 需要同时处理多个目标，容易顾此失彼。而拆分成小步骤后，每个步骤的目标单一，AI 可以集中精力，减少错误。

例如，你希望 AI 实现一个用户注册功能。如果一次性提出，它可能需要同时考虑表单验证、数据库写入、密码加密、错误处理等多个方面，上下文压力巨大。但如果你分步进行：先让它设计数据库表结构，再让它写后端接口，最后让它做前端表单——每一步都基于前一步的结果，但上下文窗口只需保留当前步骤的信息。

分步任务还有一个好处：你可以在每个步骤之间检查 AI 的输出，及时纠正错误，避免错误累积。如果 AI 在第一步就偏离了方向，你可以在进入下一步前修正，而不是等到最后才发现整个实现都错了。

上下文管理是 AI 编程的下一个核心竞争力

随着模型上下文窗口不断扩大（例如从 4K 到 128K 甚至更多），有人可能会认为上下文管理不再重要。但事实恰恰相反：窗口越大，无效信息填充的空间也越大，AI 更容易“迷失”在冗长的历史中。

未来的 AI 编程助手，比拼的将不只是模型能力，还有上下文管理效率。开发者需要学会如何与 AI 协作，就像管理一个健忘但能力强的同事——你需要把重要的事情写下来，把任务拆小，及时清理无关信息。

信号中提到的“数字痴呆”问题，本质上是一个工程问题，而非模型智商问题。通过合理的上下文管理，你可以显著提升 AI 编程助手的稳定性和可靠性。下一次当你发现 AI 又“失忆”时，不妨先检查一下它的上下文窗口——也许问题不在它，而在你喂给它的信息。

参考来源