动态上下文注入：Contexts 的使用
学完你能做什么
学会动态上下文注入后，你可以：
- 根据当前工作模式切换 AI 的行为策略（开发、审查、研究）
- 让 Claude 在不同场景下遵循不同的优先级和工具偏好
- 避免在同一会话中混淆工作目标，提升专注度
- 优化不同阶段的工作效率（快速实现 vs 深度审查）
你现在的困境
你在开发过程中遇到过这些问题吗？
- 想快速开发时，Claude 总是过度分析、给出过多建议，拖慢进度
- 代码审查时，Claude 急于改代码，而不是仔细阅读和发现问题
- 研究新问题时，Claude 没读明白就要动手写，导致方向错误
- 同一个会话里，一会儿在开发，一会儿在审查，Claude 的行为模式混乱
这些问题的根源在于：Claude 没有明确的"工作模式"信号，它不知道当前应该优先做什么。
什么时候用这一招
- 开发阶段：让 AI 优先实现功能，后讨论细节
- 代码审查：让 AI 先充分理解，再提出改进建议
- 技术研究：让 AI 先探索学习，再给出结论
- 工作模式切换时：明确告诉 AI 现在的目标是什么
核心思路
动态上下文注入的核心是让 AI 在不同工作模式下有不同的行为策略。
三种工作模式
Everything Claude Code 提供三种预定义的上下文：
| 模式 | 文件 | 关注点 | 优先级 | 适用场景 |
|---|---|---|---|---|
| dev | contexts/dev.md | 实现功能、快速迭代 | 先跑起来，再完善 | 日常开发、新功能实现 |
| review | contexts/review.md | 代码质量、安全性、可维护性 | 先发现问题，再建议修复 | Code Review、PR 审查 |
| research | contexts/research.md | 理解问题、探索方案 | 先理解，再动手 | 技术调研、Bug 分析、架构设计 |
为什么需要动态上下文？
上下文 vs 系统提示
系统提示是 Claude Code 启动时加载的固定指令（如 agents/、rules/ 目录中的内容），它定义了 AI 的基础行为。
上下文是你根据当前工作模式动态注入的临时指令，它覆盖或补充系统提示，让 AI 在特定场景下改变行为。
系统提示是"全局默认"，上下文是"场景覆盖"。
工作模式对比
同一个任务，在不同模式下 AI 的表现差异：
### 任务：修复一个导致登录失败的 Bug
#### dev 模式（快速修复）
- 快速定位问题
- 直接修改代码
- 运行测试验证
- 先跑起来，再优化
### review 模式（深度分析）
- 充分阅读相关代码
- 检查边界条件和错误处理
- 评估修复方案的影响
- 先发现问题，再建议修复
### research 模式（彻底调查）
- 探索所有可能的原因
- 分析日志和错误信息
- 验证假设
- 先理解根因，再给出方案🎒 开始前的准备
跟我做：使用动态上下文
第 1 步：理解三种上下文的工作方式
先了解每种上下文的定义：
dev.md - 开发模式
目标：快速实现功能，先跑起来再完善
优先级：
- Get it working（让它工作）
- Get it right（让它正确）
- Get it clean（让它整洁）
行为策略：
- Write code first, explain after（先写代码，后解释）
- Prefer working solutions over perfect solutions（偏好可用方案胜过完美方案）
- Run tests after changes（改动后运行测试）
- Keep commits atomic（保持提交原子性）
工具偏好：Edit、Write（代码修改）、Bash（运行测试/构建）、Grep/Glob（查找代码）
review.md - 审查模式
目标：发现代码质量问题、安全漏洞和可维护性问题
优先级：Critical（关键） > High（高） > Medium（中） > Low（低）
行为策略：
- Read thoroughly before commenting（先充分阅读，再评论）
- Prioritize issues by severity（按严重程度排序问题）
- Suggest fixes, don't just point out problems（建议修复方案，而不只是指出问题）
- Check for security vulnerabilities（检查安全漏洞）
审查清单：
- [ ] Logic errors（逻辑错误）
- [ ] Edge cases（边界条件）
- [ ] Error handling（错误处理）
- [ ] Security（injection, auth, secrets）（安全问题）
- [ ] Performance（性能）
- [ ] Readability（可读性）
- [ ] Test coverage（测试覆盖率）
输出格式：按文件分组，严重程度优先
research.md - 研究模式
目标：深入理解问题，探索可能的解决方案
研究流程：
- Understand the question（理解问题）
- Explore relevant code/docs（探索相关代码/文档）
- Form hypothesis（提出假设）
- Verify with evidence（用证据验证）
- Summarize findings（总结发现）
行为策略：
- Read widely before concluding（先广泛阅读，再下结论）
- Ask clarifying questions（提出澄清问题）
- Document findings as you go（边探索边记录）
- Don't write code until understanding is clear（理解清楚前不写代码）
工具偏好：Read（理解代码）、Grep/Glob（查找模式）、WebSearch/WebFetch（外部文档）、Task with Explore agent（代码库问题）
输出格式：先发现，后建议
第 2 步：选择并应用上下文
根据当前工作场景，选择合适的上下文。
场景 1：实现新功能
适用上下文：dev.md
应用方式：
@contexts/dev.md
请帮我实现用户认证功能：
1. 支持邮箱密码登录
2. 生成 JWT token
3. 实现中间件保护路由Claude 会怎样表现：
- 快速实现核心功能
- 不过度设计
- 实现后运行测试验证
- 保持提交原子性（每个提交完成一个小功能）
你应该看到：
- 快速获得可运行的代码
- 测试通过
- 功能可用，可能不够优雅
场景 2：审查同事的 PR
适用上下文：review.md
应用方式：
@contexts/review.md
请审查这个 PR：https://github.com/your-repo/pull/123
重点检查：
- 安全性（SQL 注入、XSS、认证）
- 错误处理
- 性能问题Claude 会怎样表现：
- 先充分阅读所有相关代码
- 按严重程度排序问题
- 为每个问题提供修复建议
- 不直接改代码，只提建议
你应该看到：
- 结构化的审查报告（按文件、按严重程度）
- 每个问题都有具体位置和修复建议
- Critical 级别问题优先标注
场景 3：调研一个新技术的集成方案
适用上下文：research.md
应用方式：
@contexts/research.md
我想在项目中集成 ClickHouse 作为分析数据库，请帮我调研：
1. ClickHouse 的优势和劣势
2. 与我们现有的 PostgreSQL 架构如何配合
3. 迁移策略和风险
4. 性能基准测试结果
不要写代码，先调研清楚方案。Claude 会怎样表现：
- 先搜索 ClickHouse 官方文档和最佳实践
- 阅读相关的迁移案例
- 分析与现有架构的兼容性
- 边探索边记录发现
- 最后给出综合建议
你应该看到：
- 详细的技术对比分析
- 风险评估和迁移建议
- 没有代码，只有方案和结论
第 3 步：在同一会话中切换上下文
你可以在同一会话中动态切换上下文，适应不同的工作阶段。
示例：开发 + 审查工作流
#### 第 1 步：实现功能（dev 模式）
@contexts/dev.md
请实现用户登录功能，支持邮箱密码认证。
...
#### Claude 快速实现功能
#### 第 2 步：自我审查（review 模式）
@contexts/review.md
请审查刚才实现的登录功能代码：
...
#### Claude 切换到审查模式，深入分析代码质量
#### 按严重程度列出问题和改进建议
#### 第 3 步：根据审查结果改进（dev 模式）
@contexts/dev.md
根据上面的审查意见，修复 Critical 和 High 级别的问题。
...
#### Claude 快速修复问题
#### 第 4 步：再次审查（review 模式）
@contexts/review.md
再次审查修复后的代码。
...
#### Claude 验证问题是否解决你应该看到：
- 不同阶段有明确的工作重点
- 开发阶段快速迭代
- 审查阶段深度分析
- 避免在同一模式下的行为冲突
第 4 步：创建自定义上下文（可选）
如果预定义的三种模式不能满足你的需求，可以创建自定义上下文。
上下文文件格式：
#### My Custom Context
Mode: [模式名称]
Focus: [关注点]
## Behavior
- 行为规则 1
- 行为规则 2
## Priorities
1. 优先级 1
2. 优先级 2
## Tools to favor
- 推荐使用的工具示例：debug.md - 调试模式
#### Debug Context
Mode: Debugging and troubleshooting
Focus: Root cause analysis and fix
## Behavior
- Start by gathering evidence (logs, error messages, stack traces)
- Form hypothesis before proposing fixes
- Test fixes systematically (control variables)
- Document findings for future reference
## Debug Process
1. Reproduce the issue consistently
2. Gather diagnostic information
3. Narrow down potential causes
4. Test hypotheses
5. Verify the fix works
## Tools to favor
- Read for code inspection
- Bash for running tests and checking logs
- Grep for searching error patterns使用自定义上下文：
@contexts/debug.md
我在生产环境遇到这个问题：
[错误信息]
[相关日志]
请帮我调试。检查点 ✅
完成以上步骤后，你应该：
- [ ] 理解三种预定义上下文的工作方式和适用场景
- [ ] 能够根据工作场景选择合适的上下文
- [ ] 会在会话中动态切换上下文
- [ ] 知道如何创建自定义上下文
- [ ] 体验到不同上下文下 AI 行为的明显差异
踩坑提醒
❌ 错误 1：不切换上下文，期望 AI 自动适应
问题：同一会话中，一会儿开发一会儿审查，却不告诉 AI 当前目标。
表现：Claude 行为混乱，有时候过度分析，有时候又匆忙改代码。
正确做法：
- 明确切换上下文：
@contexts/dev.md或@contexts/review.md - 在每个阶段开始时声明当前目标
- 用
## 第 X 步：[目标]明确阶段
❌ 错误 2：用 research 模式做快速开发
问题：需要在 30 分钟内快速实现一个功能，却用了 @contexts/research.md。
表现：Claude 花大量时间调研、讨论、分析，迟迟不动手写代码。
正确做法：
- 快速开发用
dev模式 - 深度调研用
research模式 - 根据时间压力和任务复杂度选择模式
❌ 错误 3：用 dev 模式审查关键代码
问题：审查涉及安全、金钱、隐私的关键代码，却用了 @contexts/dev.md。
表现：Claude 快速扫一遍，可能漏掉严重的安全漏洞。
正确做法：
- 关键代码审查必须用
review模式 - 普通 PR 审查用
review模式 - 只在自我快速迭代时用
dev模式
本课小结
动态上下文注入通过明确当前工作模式，让 AI 在不同场景下优化行为策略：
三种预定义模式：
- dev：快速实现，先跑起来再完善
- review：深度审查，发现问题并建议修复
- research：充分调研，理解后再下结论
使用要点：
- 根据工作阶段切换上下文
- 用
@contexts/xxx.md明确加载上下文 - 同一会话可以多次切换
- 可以创建自定义上下文满足特定需求
核心价值：避免 AI 行为混乱，提升不同阶段的专注度和效率。
下一课预告
下一课我们学习 配置文件详解：settings.json 完整参考。
你会学到：
- settings.json 的完整配置选项
- 如何自定义 Hooks 配置
- MCP 服务器的启用和禁用策略
- 项目级和全局级配置的优先级
附录：源码参考
点击展开查看源码位置
更新时间：2026-01-25
| 功能 | 文件路径 | 行号 |
|---|---|---|
| dev 上下文定义 | contexts/dev.md | 1-21 |
| review 上下文定义 | contexts/review.md | 1-23 |
| research 上下文定义 | contexts/research.md | 1-27 |
关键上下文文件：
dev.md：开发模式上下文，优先快速实现功能review.md：审查模式上下文，优先发现代码质量问题research.md：研究模式上下文，优先深入理解问题