12.9K Star!这个工具让AI编程助手瘦身98%,微软团队都在用

用Cursor或Claude Code改代码，想让AI先看看项目结构，于是随手敲了句：”帮我看下当前目录都有啥”。AI立马执行ls -la，然后你的屏幕开始疯狂滚动——几百行的node_modules清单、隐藏的.git文件、各种.tmp缓存像洪水一样涌出来。等它终于消停下来，你让它继续改刚才那个组件，它却突然”失忆”了，开始问你：”咱们刚才要改哪个文件来着？”

这不是AI变笨了，而是你的上下文窗口被这些垃圾信息塞爆了。

现在的AI编程助手（比如Cursor、Claude Code、Codex）都有一个隐形的瓶颈：上下文窗口就那么大， typically 200K tokens。看起来很多对吧？但随便一个npm install的输出就能吃掉几万token，一次docker build的日志能占十几万token。等工具输出把这些宝贵空间占满，留给实际代码和业务逻辑的地方就没了。AI就像个塞爆的行李箱，你再想往里塞件外套，得先扔条裤子出去。

今天聊的context-mode，就是专门来解决这个问题的。它在GitHub上已经拿了12,971个Star，今天一天就涨了344个，还冲上了Hacker News榜首。微软的团队都在用。说白了，它能让你的AI编程助手”瘦身”98%，把工具输出的垃圾信息过滤掉，只留精华。

● ● ●

第一节：当AI开始”失忆”，问题到底出在哪？

咱们得先理解AI编程助手是怎么工作的。当你让AI”运行测试”时，它其实调用了本地的shell工具。这些工具会返回完整的stdout输出——包括进度条、debug日志、 deprecation warnings、成功提示，等等等等。

举个例子。假设你在一个中型前端项目里，让AI跑npm run build。控制台输出可能是这样的：

> project@1.0.0 build
> vite build

vite v5.0.0 building for production...
transforming (1) src/main.ts
transforming (42) src/components/Button.tsx
transforming (128) node_modules/lodash-es/...
...（此处省略500行transforming日志）
✓ 823 modules transformed.
dist/assets/index-1234.js      142.35 kB │ gzip: 45.23 kB
dist/assets/vendor-5678.js     523.12 kB │ gzip: 156.78 kB
dist/index.html                0.46 kB
✓ built in 4.85s

这段输出在终端看着挺爽，充满成就感。但对AI来说，中间那500行”transforming”日志全是噪音——它只需要知道构建成功了，以及最终文件大小。这些无意义的日志可能吃掉3-4万token的上下文空间。

更恐怖的是find . -name "*.ts"或者cat一个大日志文件。我见过有同学让AI查看error.log，结果日志文件有10MB，AI直接把上下文窗口占满，导致后续的对话完全无法继续。就像你跟朋友聊天，刚说完正事，他突然给你朗诵了整本电话黄页，然后问你刚才说到哪了——你当然一脸懵逼。

这就是context-mode要解决的核心问题：工具输出（Tool Output）的泛滥。

● ● ●

第二节：context-mode不是压缩，是”沙盒隔离”

你可能会想：这不就是简单截断吗？把长输出掐头去尾不就行了？

没那么简单。粗暴截断会导致关键信息丢失——比如构建失败的错误堆栈通常在最后几行，你要是只保留前100行，正好把错误信息扔了。那AI看到”构建成功”的前半段，就会误以为一切正常，继续往下走，结果越错越远。

context-mode的做法更聪明：它给工具输出建了个”沙盒”。

它的核心机制是三层过滤：

第一层是智能摘要。对于结构化输出（比如JSON、表格、列表），它会提取关键统计信息而不是保留完整内容。比如ls -la不再返回每个文件的详情，而是返回”当前目录包含23个文件，总大小15MB，其中3个是TypeScript文件”。

第二层是错误优先级。任何包含stderr、非零退出码、或者关键词如”Error”、”Failed”、”Traceback”的内容，会被完整保留。这样AI既能节省空间，又不会错过关键错误。

第三层是平台适配。不同的AI客户端（VS Code、Vim、Emacs、Warp、 various Claude Desktop integrations）有不同的上下文限制，context-mode会动态调整压缩策略。

官方给的数据是98% reduction。也就是说，原来要占100个token的信息，现在只占2个。这意味着你的200K上下文窗口，实际能当10MB用（换算过来差不多）。

● ● ●

第三节：上手试试，效果立竿见影

这个项目是用TypeScript写的，安装很简单：

npm install -g context-mode
# 或者
npx context-mode

它支持14个平台，包括VS Code、Vim、Neovim、Emacs、Cursor、Windsurf、 various MCP (Model Context Protocol) servers等。咱们以最常见的VS Code + Claude Dev为例。

配置前，你的settings.json可能是这样让AI直接调用shell：

{
  "mcpServers": {
    "shell": {
      "command": "node",
      "args": ["shell-server.js"]
    }
  }
}

接入context-mode后，改成：

{
  "mcpServers": {
    "shell": {
      "command": "npx",
      "args": ["context-mode", "--sandbox", "node", "shell-server.js"]
    }
  }
}

就这么简单，加了一层wrapper。

来看看实际效果对比。假设你在一个机器学习项目里，让AI查看训练日志：

改造前（AI实际收到的）：

Epoch 1/100
32/32 [==============================] - 5s 156ms/step - loss: 0.8934 - accuracy: 0.6234 - val_loss: 0.8234 - val_accuracy: 0.6543
Epoch 2/100
32/32 [==============================] - 4s 125ms/step - loss: 0.8234 - accuracy: 0.6543 - val_loss: 0.7654 - val_accuracy: 0.6789
...（重复98次，直到Epoch 100）
Epoch 100/100
32/32 [==============================] - 4s 122ms/step - loss: 0.1234 - accuracy: 0.9567 - val_loss: 0.1456 - val_accuracy: 0.9432

这要是100个epoch，每个epoch一行，加上各种进度条渲染，可能吃掉5000+ token。

改造后（AI收到的）：

[Tool Output Sandboxed]
Command: training_script.py
Duration: ~500s
Epochs: 100/100 completed
Final metrics - loss: 0.1234 (↓85%), accuracy: 95.67% (↑53%)
Status: ✓ Success

AI一眼就看到了关键信息：训练成功，loss下降了85%，准确率提升到了95.67%。原来需要5000token的内容，现在不到100token。而且如果中间有Epoch failed或者GPU OOM，这些错误信息会被完整保留，不会被”优化”掉。

● ● ●

第四节：不只是省空间，更是省脑子

刚开始我也觉得，这东西就是个”压缩工具”，省点token而已。但用了一周后发现，它改变的是你跟AI协作的交互模式。

以前用AI编程助手，你得小心翼翼：不敢让它看大日志，不敢让它执行会输出海量内容的命令，甚至不敢让它cat package.json（有些项目的依赖列表长得吓人）。你得像个精打细算的会计，时刻盘算着”上下文还够不够”。

有了context-mode后，这种焦虑没了。你可以直接说：”帮我看看过去一小时的系统日志，找出所有404错误。”换作以前，这么做可能会把几千行日志全塞进上下文，导致AI失忆。现在context-mode会自动过滤，只把包含”404″的那几行 relevant entries 传给AI。

更妙的是它的平台泛化能力。它支持14个不同的编辑器和AI客户端，从老派的Vim到最新的各种MCP-based tools。这意味着无论你用啥工具链，都能享受这个”上下文保护罩”。

而且它是TypeScript写的，如果你对它默认的过滤策略不满意，可以直接改源码或者写插件。比如你们团队有特殊的日志格式，你可以告诉context-mode：”看到包含'[DEBUG]’的行直接扔掉，但保留包含'[CRITICAL]’的完整堆栈。”

● ● ●

第五节：为什么叫它”问题的另一半”？

项目的README里有一句话：“The other half of the context problem.”（上下文问题的另一半）。

这话挺有意思。过去一两年，大家都在解决”输入上下文”的问题——RAG（检索增强生成）、代码索引、向量化搜索，都是为了让AI能在不塞满上下文的情况下获取外部知识。这是”左半边”问题。

但”右半边”——工具输出的管理——一直被忽视。大家默认”工具输出多少，AI就看多少”，结果导致AI在实际行动环节（Agentic Coding）快速耗尽上下文。

context-mode补上了这缺失的另一半。它让AI从”复读机”变成了”带着降噪耳机工作的高手”——环境再嘈杂（日志再多），它也能听到关键的对话。

现在这个项目在GitHub上已经拿到12,971个Star，而且今天一天就新增了344个星标，还登上了Hacker News榜首。微软的团队也在用，说明它确实解决了真实的大规模开发痛点。

如果你也在用Cursor、Claude Code、Codex或者其他AI编程助手，强烈建议试试这个工具。它不会改变你的工作流，只是默默帮你省掉那98%的噪音。

项目地址：https://github.com/mksglu/context-mode

觉得有用的话，去GitHub点个Star支持一下作者。毕竟，让AI编程助手不再”失忆”，对我们每个开发者来说都是实打实的效率提升。