11:05AI LABS
Log in to leave a comment
No posts yet
在使用 AI 协作的过程中,你可能会观察到一个奇怪的现象。项目初期表现得像个天才的 AI,随着代码库的增大,会变得越来越笨。它会忘记刚定的规则,导入错误的库,最后甚至会抛出代码太长无法处理的“投降”宣言。
这一现象的罪魁祸首是上下文膨胀 (Context Bloating)。即使是像 Claude 3.7 或 GPT-5 这样的高性能模型,在面对杂乱的信息噪音时,其推理能力也会崩溃。在 2026 年的今天,决定大规模项目中 AI 性能的关键不再是模型的智能程度,而是注入数据的方式。我整理了一套基于 Cursor 的实务策略,旨在减少 Token 浪费并大幅提升回答准确度。
在进行深度优化之前,你需要诊断你的智能体是否处于信息过载状态。如果出现以下征兆,请立即修改管理策略。
.cursorrules 中定义的命名规范,或者重新引入了已经修复的 Bug。传统的智能体直接在聊天窗口展示终端输出或 API 响应。当 100 行错误日志覆盖聊天窗口时,AI 的工作记忆瞬间就会被污染。
高效的开发者会将超过 50 行的响应保存到独立文件夹中,仅让 AI 引用路径。请在项目根目录设计 .context/mcp_responses/ 结构。当所有 MCP 及终端响应过长时,将其保存为文件,只给智能体传递文件路径和前 5 行的摘要。
这种技巧将上下文窗口分离为工作记忆,而将本地系统作为长期记忆。结果是模型的推理密度得到了极大提升。
对话变长后,AI 会对之前的内容进行摘要。在这个过程中,核心的设计依据往往会丢失,从而导致幻觉现象。
Cursor 的独特之处在于它会永久保存整个对话记录,但仅在需要时通过语义搜索 (Semantic Search) 加载过去的上下文。这就是为什么在数千行前的对话中,它依然能准确找到“为什么这个函数要处理成异步”的答案。不要把所有对话记录都喂给模型,将其存档以便搜索才是更聪明的方法。
一次性注入所有规则是最糟糕的策略。2026 年的标准遵循“按需展示”的阶段性方式。
| 加载阶段 | 加载时机 | 包含内容 | 预计 Token 消耗 |
|---|---|---|---|
| 第 1 阶段:发现 | 智能体启动时 | 技能名称及简要说明 | 每个技能 30-50 |
| 第 2 阶段:激活 | 任务匹配时 | 具体指令 (SKILL.md) | 1K - 5K |
| 第 3 阶段:执行 | 执行时 | 实际代码及参考文档 | 运行时决定 |
通过这种结构,即使拥有数百个专业化技能,也能将基础上下文消耗锁定在几百个 Token 以内。
随着模型上下文协议 (MCP) 服务器的增多,JSON Schema 规范会占据大量上下文。根据实际基准测试,不常态化注入所有工具规范,而是仅显示工具列表,并在智能体选择特定工具时才加载详细 Schema,这样做可以节省 46.9% 的 Token 使用量。
这种效率可以用公式简单表达:
这里的 代表消耗的 Token 量。仅通过精简不必要的规范,AI 的运算速度就能得到飞跃式提升。
不要直接复制粘贴复杂的错误日志。这样很容易遗漏信息,且格式经常混乱。
请构建一个将终端日志实时流式保存到 .context/terminal/ 的环境。当智能体分析测试失败原因时,让它直接访问日志文件,通过 tail 或 grep 仅提取必要部分。这在数据量巨大的服务器日志环境下,是保证智能体不疲劳并准确分析问题的强大基础。
与上下文优化同等重要程度的是设计依据的保存。为了让 AI 在上下文重置后依然记得项目的历史,必须运行 Decision Log。
DECISIONS.md 中记录原因。Cursor 式的动态上下文管理不仅仅是省钱的技术。它是从“喂给 AI 所有信息”到“让 AI 学会自主导航寻找信息”的范式转变。系统设计得越精巧,你的 AI 智能体就越能成为一个既无幻觉又具备无限扩展能力的强大队友。现在就去创建 .context/ 文件夹并更新你的系统提示词吧。