AI coding 真正的瓶颈不是上下文不够长，而是信息太脏

mksglu/context-mode 在 GitHub 趋势上一天获得约 306 星标，声称能将工具输出减少 98%，支持 14 个平台。

大多数人以为这是在解决 context window 容量不够的问题。

但真正被解决的是信息污染。

当 AI agent 调用外部工具时，返回的日志、堆栈信息、进度条——这些对人类有用的调试信息，对模型来说全是噪音。

它们占用 token，更重要的是污染注意力。

就像你在嘈杂的咖啡馆里谈判，不是听不到对方在说什么，而是很难集中精力。

context-mode 做的事情很简单：把工具输出扔到一个独立的沙盒里，只有当真正需要时才选择性引入。

这不是压缩，这是过滤。

长期以来，AI coding 领域有个隐含假设：上下文越长越好，模型看到的越多越准。

这个假设在信息干净时成立，但当信息来源是外部工具时，它就失效了。

你给模型 10000 行日志，它可能比只看到 10 行关键错误信息判断得更差。

这不是容量问题，这是信噪比问题。

为什么这个区分很重要？

因为它决定了你接下来该做什么。

如果你以为这是容量问题，你会去想怎么更大、更便宜、更高效的上下文。

但如果你意识到这是污染问题，你会开始思考：哪些信息是真正必要的？

什么时候该引入？什么时候该隔离？

这就是从"尽可能多"到"尽可能准"的转变。

前者是工程问题，后者是设计问题。

工程问题可以用更快的 GPU 和更聪明的压缩来解决，设计问题需要你重新思考人机协作的本质。

这不仅仅是技术优化，这是认知框架的升级。

它承认了一个反直觉的事实：有时候少即是多，但前提是你知道该少什么。

context-mode 的价值不在于它让 128k context 感觉像 1M，而在于它强迫开发者思考：我到底需要模型看到什么？

这个问题比容量问题更根本。

当然，这套思路有边界。

如果你的场景是静态代码分析、文档理解，信息源本身就是干净的，那 context-mode 带来的收益有限。

它真正发光的地方是高频调用外部工具、日志爆炸、调试信息冗余的场景。

代价也很直接：你需要多一层抽象，多一个沙盒管理，多一次"什么时候该引入"的判断。

但这是值得的代价。

因为 AI coding 的下一阶段，不是比谁的上下文更长，而是比谁的上下文更干净。

你现在还觉得上下文不够长吗？

还是说，你只是不知道该把什么东西挡在外面？