关于 context-engineering
context-engineering 是一项用于管理 AI 编码会话上下文的技能。它围绕持久记录、精准检索、压缩上下文和隔离任务来组织工作。
主要功能
- 01将工作状态持久化到上下文外
- 02通过定向搜索检索信息
- 03保留关键信息并压缩上下文
- 04通过子 Agent 和会话隔离工作
- 05按任务阶段规划上下文预算
适用场景
- 01压缩上下文后恢复任务状态
- 02查找特定代码而不读取整个文件
- 03大型搜索后缩减上下文
- 04委派测试或代码探索给子 Agent
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ rohitg00/ pro-workflow --skill context-engineering安装后在 Claude Code 中输入/context-engineering确认已加载。
详细介绍
上下文工程
四种操作控制着 AI 编码会话中上下文流转的方方面面。掌握这些操作,就能掌控每次响应的质量。
四种操作
1. 写入 — 将信息保存到上下文之外
将信息从上下文窗口移至持久存储,让它在上下文压缩和会话切换后仍能保留。
写入位置:
| 目标 | 适用场景 | 示例 |
|---|---|---|
| CLAUDE.md | 永久项目规则 | “始终使用 pnpm,绝不使用 npm” |
| NOTES.md / scratchpad | 当前任务的工作状态 | 架构决策、待解决问题 |
.claude/memory/ | 经验和模式 | 根据修正总结出的 [LEARN] 规则 |
| 外部文件 | 超出上下文容量的数据 | 测试计划、迁移检查清单 |
模式 — 临时笔记工作流:
1. Start complex task → create NOTES.md with goals and constraints
2. After research → write findings to NOTES.md
3. After compaction → NOTES.md survives, context does not
4. Resume → read NOTES.md to recover full state
2. 选择 — 检索相关信息
在恰当的时机将合适的信息引入上下文。精准比数量更重要。
按精准度排序的方法:
@file引用 — 精确注入文件grep/Glob— 针对性搜索模式- 子 Agent 探索 — 委派深度搜索
- RAG / embeddings — 为大型代码库进行语义检索
核心原则:聚焦的 300 个 token > 不聚焦的 113K 个 token。
精准返回目标函数签名的精简 grep 结果,胜过将整个模块倾倒进上下文。每个无关 token 都会分散注意力。
模式 — 渐进式检索:
1. Start with file names (Glob)
2. Narrow to specific functions (Grep)
3. Read only the relevant lines (Read with offset+limit)
4. Never read entire large files when you need one function
3. 压缩 — 减少 token,保留关键信息
缩减上下文,同时不丢失重要信息。
压缩策略:
| 策略 | 方法 | 适用场景 |
|---|---|---|
带重点的 /compact | /compact focus: auth module changes | 任务边界 |
| 微压缩 | 让 Claude 在行内总结工具输出 | 大量读取或搜索后 |
| 首尾截取 | 读取大型输出的前 20 行和后 20 行 | 日志分析、测试结果 |
| 清除工具结果 | 子 Agent 报告后自动清除其结果 | 大量探索 |
| 语义筛选 | 总结发现并丢弃原始数据 | 研究阶段 |
触发压缩的时机:
- 规划完成后、开始实现前
- 完成一项功能或里程碑后
- 上下文超过 50% 时(设置
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=50) - 切换任务领域前
- 大量搜索或读取操作后
PostCompact 钩子 — 重新注入关键上下文:
{
"type": "PostCompact",
"command": "cat .claude/critical-context.md"
}
使用此方法可确保项目规则、当前任务状态或架构约束在每次压缩后仍能保留。
4. 隔离 — 在不同执行空间中划分任务
不要把所有内容都加载到同一个上下文中。将工作拆分到彼此独立的执行空间中。
| 方法 | 隔离级别 | 适用场景 |
|---|---|---|
| 子 Agent | 分叉的上下文 | 大量探索、测试运行、文档生成 |
Worktrees(claude -w) | 完整仓库副本 | 并行开发功能、比较不同方案 |
/btw(Claude Code 内置) | 临时覆盖层 | 无需进入对话历史的快速提问 |
| Agent 团队 | 独立会话 | 跨层变更、并行审查 |
全新会话(/resume) | 全新状态 | 不相关的工作、上下文质量下降 |
模式 — 委派给子 Agent:
Main session: planning, coordination, commits
Subagent 1: explore auth module, report findings
Subagent 2: run test suite, report failures
Subagent 3: generate migration script
主上下文保持干净。子 Agent 负责处理大量内容。
上下文预算规划
基线示例(使用 /context 校准):200K 窗口(Haiku 4.5;Fable 5.1、Opus 5.5 和 Sonnet 5 支持 1M),扣除约 20K 开销(CLAUDE.md、工具定义、MCP 架构)后,剩余 约 180K 可用空间。随着上下文填满,质量仍会下降,因此在 1M 级别也要保持同样的纪律。实际预算因模型和配置而异。
| 分配 | 预算 | 内容 |
|---|---|---|
| 静态上下文 | 20-30K | CLAUDE.md、工具架构、MCP 定义 |
| 动态上下文 | 150-180K | 代码、对话、工具结果 |
将静态上下文放在最前面。 CLAUDE.md 和工具定义会在对话之前加载。保持它们稳定可最大限度地提高提示词缓存命中率,从而节省成本并降低延迟。
| 阶段 | 目标用量 | 超出时的操作 |
|---|---|---|
| 规划 | < 20% | 保持计划简洁,写入临时笔记 |
| 实现 | < 50% | 在处理文件之间压缩上下文,委派读取任务 |
| 测试 | < 70% | 将测试运行委派给子 Agent |
| 审查 | < 85% | 如果性能下降,开启新会话 |
何时使用 /clear、/compact 或子 Agent
| 情况 | 操作 |
|---|---|
| 任务边界,希望保留经验 | 使用 /compact 并指定重点 |
| 上下文质量下降,Claude 开始重复自己 | 使用 /compact,如果仍然不佳,再使用 /resume |
| 开始无关的工作 | 使用 /clear 或开启新会话 |
| 大量读取/搜索操作 | 委派给子 Agent |
| 快速询问旁支问题 | 使用 /btw(不会污染主上下文) |
| 探索多种方案 | 使用工作树或 Agent 团队 |
反模式
- 需要一个函数时却加载整个文件
- 提取所需内容后,仍将 MCP 工具结果保留在上下文中
- 运行 15 个以上的 MCP(每个都会为每次请求增加工具架构开销)
- 使用含糊的提示词,迫使 Claude 大范围搜索(“修复代码”)
- 从不压缩上下文,直到自动压缩在 95% 时触发
添加到 CLAUDE.md
## Context Engineering
Write to NOTES.md for working state that must survive compaction.
Select with precision — grep first, read specific lines, never dump whole files.
Compact at 50% or task boundaries. Set CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=50.
Isolate heavy work to subagents. Main session stays for coordination and commits.