第 2 章上下文管理——让 AI 记住重点忘掉噪音上一章我们搭建了环境这一章解决 Vibe Coding 中最常见的痛点对话越聊越长AI 开始「遗忘」甚至「幻觉」。本章将系统讲解上下文窗口的机制、/compact压缩命令的原理与使用时机、自动压缩与主动压缩的区别以及四大减少上下文消耗的实战技巧。2.1 上下文窗口机制2.1.1 什么是上下文窗口上下文窗口Context Window是 AI 模型在单次对话中能够「看到」的历史消息总量的上限。它以词元Token为单位计量——在英文中1 个词元大约对应 4 个字符或 0.75 个单词在中文中1 个词元大约对应 1.5-2 个汉字。你可以把上下文窗口想象成 AI 的「短期记忆工作台」桌面上能摊开的纸张数量是有限的新的对话内容不断放上来旧的内容要么被压缩、要么被丢弃。当桌面堆满时AI 就开始「记不住」早期说过的话。2.1.2 Claude Code 的上下文窗口大小根据 Anthropic 官方文档截至 2026 年 8 月不同模型的上下文窗口大小如下模型上下文窗口说明Claude Opus 4.7 / 4.6200K默认/ 1M可选旗舰模型支持超长上下文选项Claude Sonnet 4.6200K默认/ 1M可选主力模型平衡性能与成本Claude Sonnet 4.5200K上一代主力模型仅支持 200KClaude Haiku 4.5200K轻量模型快速响应关键结论Claude Code 的默认上下文窗口是20 万词元200K Tokens约合 30-40 万汉字。部分新模型Opus 4.6、Sonnet 4.6支持 100 万词元1M的长上下文选项但需要显式配置启用。修正说明有些资料或早期版本提到「1M 上下文」这是特定模型的可选配置不是默认值。在日常开发中绝大多数用户使用的是 200K 默认窗口。本章的所有建议均基于 200K 窗口1M 窗口下可以适当放宽压缩频率。2.1.3 上下文是怎么被消耗的一轮对话的 Token 消耗由以下部分组成单轮 Token 消耗 ≈ 系统提示词 历史消息你的提问 AI 的回答 工具调用结果 当前输入内容类型单次估算 Token说明系统提示词含 CLAUDE.md2,000-5,000每次会话固定消耗CLAUDE.md 越短越好你的需求描述100-500取决于描述的详细程度AI 生成的代码500-5,000取决于代码量一次生成多个文件可能上万命令行编译输出500-5,000npm install、构建日志可能很长错误堆栈信息200-2,000取决于错误深度文件读取结果500-10,000读取大文件消耗巨大按平均每轮消耗 3,000-5,000 Token 计算200K 窗口大约能支撑40-60 轮对话。但如果某一轮 AI 生成了大量代码或读取了大文件窗口会被快速吃掉。2.1.4 上下文过长的三大问题当上下文接近上限时会出现三个递进的问题问题一响应变慢上下文越长模型需要处理的内容越多每轮响应的等待时间会显著增加。从体感上前 10 轮可能秒回到 40 轮以后可能要等十几秒。问题二注意力稀释模型的注意力是有限的。上下文越长它对早期关键信息的关注度越低。你在第 2 轮说的「这个项目禁止使用 any 类型」到第 40 轮时 AI 可能已经「忘了」又开始写any。问题三幻觉Hallucination这是最严重的问题。当上下文拥挤到一定程度AI 可能会把已经删除的代码又写回来虚构不存在的函数或文件混淆不同模块的逻辑重复已经做过的工作幻觉的本质是模型在有限的注意力下开始「猜测」而不是「回忆」猜测的内容往往是错的。2.2 /compact 命令详解2.2.1 什么是 /compact/compact是 Claude Code 中最重要的上下文管理命令。它的作用是让 Claude 读取完整的对话历史生成一份结构化摘要然后用摘要替换掉早期的完整对话从而释放大量上下文空间。压缩后早期的对话细节命令行输出、AI 逐行解释代码的内容、已经解决的报错会被丢弃只保留结论性信息已完成的任务、做出的决策、修改过的文件、关键事实。2.2.2 /compact 的工作原理压缩前的上下文 [系统提示词] [第1轮完整对话] [第2轮完整对话] ... [第40轮完整对话] ↑ 总计约 180K Token接近上限 执行 /compact 后 [系统提示词] [压缩摘要约2-5K Token] [最近3-5轮完整对话] ↑ 总计约 20-30K Token释放了大量空间压缩摘要通常包含已完成的任务做了什么功能、修了什么 bug已做的决策技术选型、架构决定、规范约定修改过的文件哪些文件被改动了改动的核心内容关键事实项目状态、未解决的问题、下一步计划当前进度处于什么阶段接下来要做什么2.2.3 使用时机什么时候该执行/compact参考以下信号信号说明建议操作对话达到 30-50 轮经验阈值200K 窗口下的安全区间主动压缩完成一个大功能模块后自然的压缩节点过程性噪音最多主动压缩开始新任务前新任务不需要旧任务的过程细节主动压缩响应明显变慢上下文拥挤的早期信号主动压缩AI 开始忽略早期指令注意力稀释的信号立即压缩AI 把已删代码又写回来幻觉的明确信号立即压缩 手动补充关键信息核心原则主动压缩优于被动等待。不要等 AI 开始「遗忘」或「幻觉」了才压缩在 30-50 轮或完成大模块后主动压缩效果最好。2.2.4 注意事项注意一压缩是不可逆的而且是有损耗的压缩后被丢弃的原始对话无法恢复。如果早期对话中有你需要保留的细节如某个错误的完整堆栈、某段讨论的完整过程在压缩前先手动保存到项目文档中。注意二 压缩本身有损耗频繁压缩会导致信息累积损耗每次/compact压缩AI 生成的摘要不可能 100% 保留所有重要信息——摘要本质是「提炼」提炼就意味着舍弃细节如果压缩过于频繁比如每 10 轮就压缩一次每次压缩都有信息损耗多次压缩后累积损耗可能很大极端情况下压缩太多次后AI 可能完全忘记了早期的某些关键决策比如「我们决定用 PostgreSQL 而不是 MySQL」因为每次摘要都可能把这个信息「精简掉」这也是为什么不能「为了省 Token 而过度压缩」——压缩频率要适中在「上下文拥挤」和「压缩损耗」之间找平衡应对策略压缩前主动告诉 AI「请特别注意保留以下关键信息」压缩后验证关键信息是否保留重要决策同时写入项目文档不依赖压缩摘要保留注意三压缩质量取决于对话结构如果你的对话混乱频繁切换话题、需求反复变更、没有明确的任务边界压缩摘要可能会遗漏重要信息。保持对话结构清晰一个对话聚焦一个任务、需求描述明确压缩质量会更高。注意四压缩前可以手动总结关键点如果你担心 AI 压缩时遗漏重要信息可以在压缩前主动告诉 Claude在压缩之前请特别注意保留以下关键信息 1. 我们决定使用 PostgreSQL 而不是 MySQL 2. 用户认证模块的表结构在 docs/schema.md 中 3. 下一步要做权限管理RBAC这样压缩后的摘要更有可能包含这些信息。注意五压缩后验证关键信息压缩完成后建议问一个验证问题请简要复述当前项目的进度、已完成的功能和接下来的计划。如果 AI 能准确复述说明压缩成功如果遗漏了重要信息手动补充补充一点我们之前还决定了 API 返回格式统一为 { code, data, message }不要忘了。2.3 自动压缩Auto-Compactvs 主动压缩2.3.1 什么是自动压缩Claude Code 内置了自动压缩Auto-Compact机制。当上下文接近上限时通常在 80%-90% 左右Claude Code 会自动触发压缩你会在界面看到提示。从版本 2.0.642026 年 2 月开始压缩过程变得几乎是即时的不再需要长时间等待。2.3.2 为什么主动压缩更好虽然自动压缩很方便但依赖它有以下问题问题说明触发时机太晚自动压缩在「快满」的时候才触发此时 AI 可能已经因为上下文拥挤而表现下降遗忘、幻觉压缩质量不可控自动压缩是 AI 自发行为你无法提前指定要保留哪些信息打断工作流自动压缩可能在你正在描述复杂需求时触发打断思路可能丢失关键信息在上下文极度拥挤时压缩AI 的注意力本身就不足摘要质量可能下降主动压缩的优势在 AI 状态良好时压缩摘要质量更高可以提前指定要保留的关键信息在任务边界压缩不打断工作流避免上下文拥挤导致的性能下降建议把自动压缩当作「安全网」而不是「主要手段」。养成主动压缩的习惯自动压缩只在你忘记主动压缩时兜底。2.4 减少上下文消耗的四大技巧压缩是「事后清理」更高效的做法是「事前控制」——从源头上减少不必要的上下文消耗。2.4.1 技巧一精准提问控制输出量问题开放式问题会让 AI 生成大量不必要的输出。❌ 帮我看看这个项目有什么问题 → AI 可能输出几千字的泛泛而谈大部分是噪音 ✅ 请检查 src/auth/login.js 中的密码验证逻辑重点看是否有 SQL 注入风险 → AI 聚焦具体文件和具体问题输出精简且有价值具体做法明确指定要检查的文件和行范围如src/auth/login.js:40-80明确指定关注的问题类型如「只看安全问题」「只看性能问题」要求 AI 输出结构化的结果如「按 Critical/High/Medium 分级输出」避免让 AI 「全面分析」「随便看看」这类模糊指令2.4.2 技巧二文件读取策略——不要一次性读大文件问题让 AI 读取一个 2000 行的大文件一次性消耗上万 Token但你可能只关心其中的某个函数。❌ 查看 src/utils/request.ts 的内容 → 读取整个文件可能消耗 5,000 Token ✅ 查看 src/utils/request.ts 中 request 函数的定义大约在第 40-80 行 → 只读取指定行范围消耗几百 Token具体做法先用搜索定位函数位置如「request 函数在第几行」再读取指定行范围对于配置文件只读取相关的配置块而不是整个文件不要用cat/head/tail等 Shell 命令查看文件直接让 Claude 用 Read 工具读取——Read 工具支持行范围参数更高效如果确实需要读取整个文件先确认文件大小大文件考虑拆分或只读取关键部分2.4.3 技巧三CLAUDE.md 精简问题CLAUDE.md在每次会话启动时全量加载到上下文中。如果写得太长比如把整个 README 复制进去每次会话都白白消耗大量 Token。建议保持CLAUDE.md在50-100 行约 2K Token 以内信息密度高只写「约定」而不是「文档」。# ✅ 好的 CLAUDE.md精简版约 60 行 ## 技术栈 React 18 TypeScript Vite Express PostgreSQL ## 常用命令 pnpm dev # 启动前后端 pnpm test # 运行测试 pnpm build # 生产构建 ## 编码规范 - 严格 TypeScript禁止 any - 组件用函数式 Hooks - API 请求统一走 src/api/client.ts - 样式用 Tailwind不写 CSS 文件 ## 重要约定 - 不要修改 src/generated/自动生成 - 环境变量通过 .env.example 声明 - PR 前必须运行 pnpm lint pnpm test# ❌ 差的 CLAUDE.md冗余版可能 300 行 把整个 README 复制进来包含项目背景介绍、详细的安装步骤、 每个目录的详细说明、所有依赖的版本号列表……具体做法只写 AI 需要知道但无法从代码中自动推断的信息详细文档放在docs/目录中需要时 AI 可以按需读取定期审查CLAUDE.md移除过时或冗余的内容第 3 章会详细讲解CLAUDE.md的最佳实践2.4.4 技巧四善用 .gitignore 风格的上下文过滤原理Claude Code 会自动忽略.gitignore中列出的文件和二进制文件不会将它们加载到上下文中。具体做法确保.gitignore配置完善排除node_modules/、dist/、build/、.env等不需要 AI 查看的文件对于 AI 不应该查看的大型数据文件、日志文件、模型权重文件加入.gitignore这样不仅保护了 Git 仓库的整洁也减少了 AI 上下文的噪音2.5 上下文状态自查在对话过程中你可以通过以下方式判断当前上下文的使用情况2.5.1 三种自查信号信号观察方法判断标准Token 使用统计部分版本在每次响应后显示 Token 用量接近 180K200K 窗口的 90%时需要压缩响应速度主观感受明显比前几轮慢 → 可能需要压缩遗忘迹象AI 的回答内容开始忽略本轮对话中你说过的重要信息 → 上下文可能已经滚动或压缩过2.5.2 推荐的自查节奏每 10 轮对话 → 感受一下响应速度是否变慢 → 回想一下 AI 是否有「遗忘」迹象 每 30 轮对话 → 主动执行 /compact → 压缩后验证关键信息是否保留 完成一个大功能模块后 → 主动执行 /compact → 把模块的关键决策写入项目文档2.6 实战示例20 轮对话的压缩前后对比2.6.1 压缩前的上下文部分摘要假设你正在开发一个用户管理系统对话进行了 25 轮第1轮你说帮我创建用户登录接口 第2轮AI 生成 auth.js包含 login 函数约 80 行代码 第3轮你说密码要加密存储 第4轮AI 修改代码引入 bcrypt解释 bcrypt 的工作原理约 300 字 第5轮编译报错 bcrypt not found输出 50 行错误堆栈 第6轮AI 说需要 npm install bcrypt解释 npm install 的用法 第7轮你执行了 npm install输出 200 行安装日志 第8轮编译通过但登录返回 500输出 30 行错误堆栈 第9轮AI 排查发现是数据库连接配置错误解释连接池的原理 第10轮修复后登录成功 第11-20轮开发用户注册功能类似的过程代码生成、编译报错、排查、修复 第21-25轮开始讨论权限管理AI 提出 RBAC 方案...此时上下文已经消耗了约 150K Token接近 200K 上限的 75%。其中大量内容是「过程性噪音」编译输出、安装日志、AI 解释基础概念的内容、已经解决的错误堆栈。2.6.2 执行 /compact 后的摘要【压缩摘要】 项目用户管理系统 当前进度登录和注册功能已完成并验证通过正在设计权限管理。 已完成 - 用户登录接口src/auth/login.js密码使用 bcrypt 加密 - 用户注册接口src/auth/register.js含邮箱验证 - 数据库连接配置已修复config/database.js使用连接池 技术决策 - 后端 Express PostgreSQL - 密码加密统一使用 bcryptsalt rounds 10 - API 返回格式统一为 { code, data, message } - 数据库使用 Sequelize ORM 待完成 - 权限管理RBAC用户表 角色表 用户角色关联表 - 角色权限中间件 已知问题 - 无压缩后上下文从约 150K 降到约 20K摘要 最近几轮对话释放了约 130K Token 空间。AI 接下来开发权限管理时只需要知道这些结论就够了不需要知道「第 5 轮的编译报错是什么」「第 7 轮 npm install 输出了什么」。2.7 本章小结本章系统讲解了上下文管理核心知识点上下文窗口机制默认 200K TokenOpus 4.6/Sonnet 4.6 可选 1M约支撑 40-60 轮对话。上下文过长会导致响应变慢、注意力稀释、幻觉三大问题。/compact 命令让 AI 生成结构化摘要替换早期对话保留结论性信息、丢弃过程性噪音。在 30-50 轮或完成大模块后主动压缩压缩不可逆压缩后需验证关键信息。自动压缩 vs 主动压缩自动压缩是安全网触发太晚且质量不可控主动压缩效果更好应作为主要手段。四大减耗技巧精准提问控制输出量、文件读取指定行范围、CLAUDE.md 精简到 2K Token 以内、善用 .gitignore 过滤无关文件。上下文自查通过 Token 统计、响应速度、遗忘迹象三种信号判断是否需要压缩推荐每 30 轮主动压缩一次。上下文管理是 Vibe Coding 中「最关键的技能」——没有之一。掌握了上下文管理你的 AI 对话就不会「越聊越笨」而是始终保持高效和准确。下一章我们将讲解三层记忆体系学习如何让 AI 跨会话记住你的项目规范和个人偏好。课后思考第 2 章课后思考参考答案1. Claude Code 的默认上下文窗口是多大什么情况下可以使用 1M 窗口上下文过长会导致哪三个递进的问题默认上下文窗口Claude Code 的默认上下文窗口是20 万词元200K Tokens约合 30-40 万汉字。按平均每轮消耗 3,000-5,000 Token 计算大约能支撑40-60 轮对话。什么情况下可以使用 1M 窗口使用Claude Opus 4.6 或 Sonnet 4.6 模型时可以显式配置启用 100 万词元1M的长上下文选项。适用场景包括需要一次性加载大型代码库的多个文件进行全局分析超长文档的阅读理解和跨章节推理大型重构任务需要同时理解多个模块的依赖关系注意1M 是特定模型的可选配置不是默认值。日常开发中绝大多数用户使用的是 200K 默认窗口。上下文过长的三个递进问题从轻度到严重递进层次问题表现第一层响应变慢上下文越长模型需要处理的内容越多每轮响应等待时间显著增加前 10 轮可能秒回到 40 轮以后可能要等十几秒第二层注意力稀释模型注意力有限上下文越长对早期关键信息的关注度越低你在第 2 轮说的「禁止使用 any 类型」到第 40 轮时 AI 可能已经「忘了」又开始写any第三层幻觉Hallucination上下文拥挤到一定程度模型开始「猜测」而不是「回忆」猜测内容往往是错的把已经删除的代码又写回来、虚构不存在的函数或文件、混淆不同模块的逻辑、重复已经做过的工作三个问题是递进关系先变慢再注意力下降最后出现幻觉。出现幻觉是最严重的信号说明上下文已经严重超载。2.基础题/compact的工作原理是什么压缩后保留了什么、丢弃了什么为什么说压缩是「不可逆」的工作原理/compact让 Claude 读取完整的对话历史生成一份结构化摘要然后用摘要替换掉早期的完整对话从而释放大量上下文空间。压缩前 [系统提示词] [第1轮完整对话] [第2轮完整对话] ... [第40轮完整对话] ↑ 总计约 180K Token 压缩后 [系统提示词] [压缩摘要约2-5K Token] [最近3-5轮完整对话] ↑ 总计约 20-30K Token压缩后保留了什么结论性信息保留内容说明已完成的任务做了什么功能、修了什么 bug已做的决策技术选型、架构决定、规范约定修改过的文件哪些文件被改动了改动的核心内容关键事实项目状态、未解决的问题、下一步计划当前进度处于什么阶段接下来要做什么压缩后丢弃了什么过程性噪音丢弃内容说明命令行编译输出npm install 日志、构建日志、错误堆栈的完整输出AI 逐行解释代码的内容AI 对每段代码的详细解释结论已保留已经解决的报错已经修复的错误的完整讨论过程中间尝试过程多次试错的过程最终方案已保留冗余的重复讨论反复确认同一问题的对话为什么说压缩是「不可逆」的压缩后被丢弃的原始对话无法恢复。摘要只保留了结论性信息过程性细节如某个错误的完整堆栈、某段讨论的完整过程、AI 最初给出的多个方案对比被永久丢弃了。如果早期对话中有你需要保留的细节必须在压缩前手动保存到项目文档中。压缩后再想找原始细节就找不到了。这也是为什么建议在压缩前主动告诉 Claude「请特别注意保留以下关键信息」以及压缩后验证关键信息是否保留。你补充的这个点非常有价值——压缩是有损耗的频繁压缩会导致信息累积损耗。课程知识点确实没提到但作为进阶思考很有意义。下面是补充后的完整参考答案。3.进阶题主动压缩和自动压缩有什么区别为什么推荐主动压缩而不是依赖自动压缩在什么时机主动压缩效果最好提示从触发时机、压缩质量、工作流打断三个维度对比。主动压缩和自动压缩的区别维度主动压缩/compact自动压缩Auto-Compact触发时机用户主动执行/compact命令上下文接近上限时通常 80%-90%自动触发压缩质量高——在 AI 状态良好时压缩摘要更准确较低——在上下文极度拥挤时压缩AI 注意力本身不足摘要质量可能下降可控性高——可以提前指定要保留的关键信息低——AI 自发行为无法提前指定保留内容工作流打断低——在任务边界如完成一个功能后主动压缩不打断思路高——可能在你正在描述复杂需求时触发打断思路性能影响无——主动压缩时 AI 还没出现性能下降有——自动压缩触发时 AI 可能已经因为上下文拥挤而响应变慢为什么推荐主动压缩而不是依赖自动压缩触发时机太晚自动压缩在「快满」的时候才触发此时 AI 可能已经因为上下文拥挤而表现下降遗忘、幻觉你已经承受了性能下降的代价压缩质量不可控自动压缩是 AI 自发行为你无法提前指定要保留哪些信息可能遗漏关键决策打断工作流自动压缩可能在你正在描述复杂需求时触发打断思路可能丢失关键信息在上下文极度拥挤时压缩AI 的注意力本身就不足摘要质量可能下降关键信息可能被遗漏压缩本身有损耗频繁压缩会导致信息累积损耗每次/compact压缩AI 生成的摘要不可能 100% 保留所有重要信息——摘要本质是「提炼」提炼就意味着舍弃细节如果压缩过于频繁比如每 10 轮就压缩一次每次压缩都有信息损耗多次压缩后累积损耗可能很大极端情况下压缩太多次后AI 可能完全忘记了早期的某些关键决策比如「我们决定用 PostgreSQL 而不是 MySQL」因为每次摘要都可能把这个信息「精简掉」这也是为什么不能「为了省 Token 而过度压缩」——压缩频率要适中在「上下文拥挤」和「压缩损耗」之间找平衡应对策略压缩前主动告诉 AI「请特别注意保留以下关键信息」压缩后验证关键信息是否保留重要决策同时写入项目文档不依赖压缩摘要保留核心原则把自动压缩当作「安全网」而不是「主要手段」。养成主动压缩的习惯自动压缩只在你忘记主动压缩时兜底。同时注意压缩频率——不要等到上下文快满了才压缩此时质量下降也不要过于频繁压缩导致累积损耗在任务边界完成一个功能模块后主动压缩是最佳平衡点。主动压缩的最佳时机信号/时机说明建议操作对话达到 30-50 轮经验阈值200K 窗口下的安全区间主动压缩完成一个大功能模块后自然的压缩节点过程性噪音最多主动压缩开始新任务前新任务不需要旧任务的过程细节主动压缩响应明显变慢上下文拥挤的早期信号主动压缩AI 开始忽略早期指令注意力稀释的信号立即压缩AI 把已删代码又写回来幻觉的明确信号立即压缩 手动补充关键信息补充注意不要在「对话还很短比如只有 5-10 轮」时就压缩——此时上下文还很清爽压缩没有必要反而会引入不必要的信息损耗。压缩的最佳时机是「完成了一个阶段性任务且对话已经有一定长度20 轮」时。4.开放题有人说「上下文窗口越来越大从 200K 到 1M 到未来的 10M上下文压缩和管理就不重要了」。你同意这个观点吗为什么四大减少上下文消耗的技巧技巧核心做法效果技巧一精准提问控制输出量明确指定文件和行范围、明确关注的问题类型、要求结构化输出避免开放式问题减少 AI 不必要的长篇大论技巧二文件读取策略——指定行范围先用搜索定位函数位置再读取指定行范围不要一次性读大文件从读取整个文件5000 Token降到读取指定行几百 Token技巧三CLAUDE.md 精简保持 CLAUDE.md 在 50-100 行约 2K Token 以内只写「约定」不写「文档」详细文档放 docs/ 按需读取每次会话启动时减少固定消耗技巧四善用 .gitignore 风格的上下文过滤确保 .gitignore 排除 node_modules/、dist/、大型数据文件等Claude Code 自动忽略这些文件减少 AI 上下文的噪音避免 AI 误读无关文件大型项目中的组合使用策略假设你在一个有 200 个代码文件的大型项目中工作每次让 AI 查看代码都消耗大量 Token。组合使用策略如下第一步CLAUDE.md 精简事前控制每次会话生效CLAUDE.md 只写项目级约定技术栈、编码规范、构建命令、目录结构概要控制在 100 行以内详细的模块文档、API 文档、架构设计文档放在docs/目录中AI 需要时再按需读取这样每次会话启动时只消耗约 2K Token 加载 CLAUDE.md而不是把整个文档都加载进来第二步.gitignore 完善事前控制自动生效确保.gitignore排除node_modules/、dist/、build/、.env、大型日志文件、模型权重文件、测试数据文件Claude Code 自动忽略这些文件不会将它们加载到上下文中也不会在搜索时返回这些文件这一步是「免费」的优化配置一次永久生效第三步精准提问 指定行范围事中控制每次交互生效当你需要 AI 查看代码时❌ 低效做法消耗大量 Token 帮我看看用户认证模块有什么问题 → AI 可能读取整个 auth 目录的十几个文件消耗上万 Token ✅ 高效做法消耗少量 Token 1. 先搜索定位src/auth/ 目录下哪个文件处理登录逻辑 2. 再精确读取请查看 src/auth/login.ts:40-80 的密码验证函数 3. 明确问题类型重点检查是否有 SQL 注入风险和空值处理 4. 要求结构化输出按 Critical/High/Medium 分级输出问题这样 AI 只读取指定文件的指定行范围几百 Token而不是读取整个目录上万 Token且输出聚焦在你关心的问题上不会泛泛而谈。第四步定期压缩事后清理周期性生效每完成一个子任务或每 15-20 轮对话执行/compact压缩压缩前把关键决策技术选型、架构决定、待办事项保存到项目文档中压缩后验证关键信息是否保留组合效果CLAUDE.md 精简每次会话节省约 3-5K Token从加载完整文档降到只加载约定.gitignore 过滤避免 AI 误读 node_modules 等无关文件节省不可预估的 Token精准提问 指定行范围每次代码查看从 5000 Token 降到 500 Token 左右节省 90%定期压缩防止上下文累积保持 AI 注意力集中四者配合大型项目中的 Token 消耗可以降低 70%-90%同时 AI 的输出质量反而更高因为上下文更聚焦、噪音更少。5. 上下文窗口越来越大上下文压缩和管理还重要吗开放题参考答案不同意这个观点上下文压缩和管理在可预见的未来仍然重要。理由分析从多个维度而不只是「容量」1. 成本维度窗口越大单次调用成本越高AI API 的费用是按 Token 计费的输入 Token 越多每次调用成本越高1M 窗口的单次调用成本是 200K 窗口的 5 倍输入部分即使窗口能装下整个项目每次对话都把整个项目加载进来也是巨大的浪费——你这次只改一个文件为什么要让 AI 读取整个项目的 200 个文件上下文压缩的本质是「只保留相关信息丢弃无关噪音」这和窗口大小无关——无论窗口多大只加载相关信息都是最经济的2. 延迟维度窗口越大响应越慢模型需要处理的 Token 越多每轮响应的等待时间越长1M 窗口的响应延迟可能是 200K 窗口的数倍上下文压缩通过减少每次调用需要处理的 Token 量直接降低延迟即使窗口无限大你也不会希望每次问一个简单问题都要等几十秒3. 注意力稀释维度窗口越大「大海捞针」效应越严重这是最核心的原因。Transformer 模型的注意力机制是有限的——上下文越长模型对每个具体位置的关注度越低研究表明即使模型有 1M 上下文窗口它对位于上下文中间位置的信息的「召回率」会显著下降「中间迷失」效应Lost in the Middle把整个项目塞进上下文模型可能「看到了」但「没注意到」关键信息——就像你把一本书摊开放在桌上你能看到所有页面但很难同时注意到每一页的细节上下文压缩的价值在于「把书的目录和关键章节放在桌上其他章节放在书架上需要时再取」——这样模型的注意力能集中在关键信息上4. 信息密度维度窗口越大噪音比例越高任何项目的代码中都有大量「噪音」注释、空行、格式化代码、已废弃的函数、调试代码、自动生成的文件窗口越大你越倾向于「全塞进去再说」噪音比例越高高噪音比例会降低 AI 输出的信噪比——AI 可能被无关信息干扰给出不准确的回答上下文管理包括 .gitignore 过滤、指定文件读取、CLAUDE.md 精简的核心就是「提高信息密度」这和窗口大小无关5. 成本-收益的边际递减从 4K 到 32K质变——能装下单个文件大幅提升能力从 32K 到 200K显著提升——能装下多个文件和小型项目从 200K 到 1M边际递减——能装下大型项目但注意力稀释和成本问题开始凸显从 1M 到 10M边际收益更低——大部分场景用不到这么大的窗口且注意力稀释和延迟问题会更严重结论上下文窗口变大解决的是「能不能装下」的问题但没有解决「装下了能不能有效利用」的问题。注意力稀释、成本、延迟、信息密度这些问题不会因为窗口变大而消失反而可能因为「什么都往里塞」而恶化。上下文压缩和管理的本质是信息筛选和注意力管理——只把相关的、高密度的信息放在 AI 的「工作台」上其他信息放在「书架」上需要时再取。这个方法论无论窗口多大都是有效的而且窗口越大「什么都往里塞」的诱惑越大主动管理上下文就越重要。注这是开放题也可以部分同意如「对于小型项目窗口足够大时压缩的必要性降低」但完全同意「窗口大了就不需要管理」是错误的。