Appearance
Context Engineering 解决的是 AI Agent 写代码时“该看的没看见，不该看的看太多”的问题。它不是单纯塞更多文件，而是管理规则、需求、源码、报错、历史对话这些上下文的优先级。
Claude Code 上下文越来越乱怎么办：Context Engineering 怎么用
下载 context-engineering 中文版 Skill ZIP
第七轮对话后，Claude Code 开始引用一个已经删掉的文件。
它忘了你刚说的边界，还把旧方案和新方案混在一起。
这时问题不一定是模型变差。
很可能是上下文乱了。
context-engineering 这个技能讲的不是“把所有文件都喂给 AI”，而是让 AI 在正确时间看到正确材料。
上下文太少，AI 会猜
你只说“修一下构建报错”，不给报错日志，不给相关配置，AI 只能根据常见经验猜。
它可能会建议升级依赖、清缓存、改 tsconfig，甚至重写一段和错误无关的代码。
上下文太少时，AI 看似在分析，其实是在补空白。
最少要给它这些东西：
- 你要解决的问题。
- 真实错误信息。
- 相关文件或目录。
- 你已经试过但失败的方法。
- 这次不能动的边界。
尤其是错误输出，不要只说“报错了”。把完整错误贴出来，AI 才能定位。
上下文太多，AI 会乱
另一个极端是把全项目、长对话、旧方案、多个无关日志都塞进去。
这会让 AI 分不清主次。
它可能把三天前的方案当成当前方案，把已废弃的文件当成关键文件，把无关报错当成根因。
AI 的上下文窗口不是垃圾桶。塞得越多，不代表越稳。
更好的做法是按优先级整理：
- 项目规则：CLAUDE.md、AGENTS.md、代码风格约束。
- 当前需求：spec、任务拆解、验收标准。
- 相关源码：只放这次会改或会影响的文件。
- 真实反馈：测试输出、构建错误、浏览器报错。
- 历史对话：只保留仍然有效的决策。
旧信息如果已经被推翻，就明确告诉 AI：“刚才那个方案废弃，以现在这版为准。”
什么时候该重开上下文
有些时候，不要硬撑。
如果一个会话里已经经历过多个方向：先做 A，改成 B，又撤回 C，再讨论 D，Agent 很容易把这些路径缠在一起。
这时可以新开一个干净任务，把当前结论重新整理给它：
md
我们重新开始这个任务。
当前有效结论：
- [结论 1]
- [结论 2]
- [结论 3]
已经废弃的方向：
- 不采用 [旧方案]
- 不再修改 [旧文件]
现在只做：
- [当前任务]
验证方法：
- [怎么证明做对]这比在旧上下文里继续补救更省时间。
给 AI 的上下文要像工具箱
你不需要把仓库全部倒给 AI。
你要像递工具一样递上下文。
修 TypeScript 类型错误，就给类型定义、调用点、报错。改 VitePress sidebar，就给 sidebar 文件、目标链接、目录状态。写一篇文章，就给内容规范、目标读者、同类文章。
每次只给它完成当前任务需要的材料。
这也是为什么很多成熟 Agent 流程会分阶段：先搜索，再读文件，再制定任务，再小步修改。不是为了慢，而是为了避免上下文污染。
Context Engineering 适合哪些工具
这个技能不只适合 Claude Code。
Cursor、OpenCode、Codex、Gemini CLI 这类工具都会遇到类似问题：只要 Agent 能读项目、改文件、运行命令，就会受到上下文质量影响。
差别只是工具入口不同：有的靠规则文件，有的靠聊天窗口，有的靠 workspace 索引，有的靠命令行读取文件。底层问题一样：AI 到底看见了什么。
古法编程怎么用这个技能
古法编程强调透明可控。
上下文管理就是让 AI 的判断材料可控。你不用猜它为什么这么改，你可以检查它看过哪些文件、遵守哪些规则、依据哪个错误输出做判断。
当 AI 开始胡乱扩写时，不要急着继续 prompt。先问自己一句：它现在看到的上下文，是不是已经脏了？
你可能还需要
同类技能：
如果上下文已经乱到解释不清，建议先整理当前有效结论，再让 AI 继续。