第6章 上下文工程：让 AI 真正理解你
开场：从"提示词工程"到"上下文工程"
你可能听说过"提示词工程"（Prompt Engineering）这个词。
2024年，这个词火遍全球。大家都在研究：怎么写prompt才能让AI更听话？
但到了2025年，行业有了一个新的共识：
"问题不在于你怎么问，而在于AI知道多少。"
这就是"上下文工程"（Context Engineering）。
你会学到什么
- 什么是上下文工程，它与提示词工程的区别
- "给新员工布置任务"的类比
- 如何写CLAUDE.md/.cursorrules文件
- 上下文的三个层次
第一节：一个类比——给新员工布置任务
想象你招了一个新员工小李。
小李很聪明，学习能力也很强。但他对公司一无所知。
提示词工程就像是：你给小李一个任务，只说一句话："去做那个项目。"
小李会困惑：
- 哪个项目？
- 用什么技术？
- 有什么规范？
- 谁能帮忙？
上下文工程像是：你给小李一份完整的入职材料。
- 这是公司简介，我们做什么业务
- 这是项目背景，为什么要做这个
- 这是技术规范，我们用什么框架
- 这是之前类似的案例，可以参考
然后你再说："现在去做这个。"
小李就能做得很好，因为他有足够的背景信息。
AI编程也是一样。
第二节：上下文的三个层次
我按"从少到多"把上下文分成三个层次。
层次一：单句上下文
"给我写一个登录页面"
AI只知道：
- 你要一个登录页面
- 其他？不知道
所以它只能猜测：什么样式？哪些字段？要不要验证？
层次二：对话上下文
你：我要做一个React项目
AI：好的，创建中...
你：现在需要一个登录页面
AI：正在生成登录页面...
AI记住了你用React，所以生成的代码会匹配React。
但它的"记忆"是有限的。对话多了，它可能忘记前面的内容。
层次三：项目上下文
你在项目根目录放一个CLAUDE.md文件，内容如下：
# 个人博客项目
## 项目概述
一个简洁的个人博客，用于分享技术文章。
## 技术栈
- 前端：React + Tailwind CSS
- 后端：Next.js API Routes
- 数据库：SQLite
## 设计规范
- 颜色：主色#3B82F6（蓝色）
- 字体：正文用Inter，标题用Poppins
- 组件：使用shadcn/ui组件库
## 代码规范
- 函数名用camelCase
- 组件文件名用PascalCase
现在，不管你什么时候问AI，它都知道这个项目的背景了。
[图 6-1] 三种上下文层次对比
图表说明：三个并排的圆圈。左边最小的是"单句"，中间是"对话"，右边最大的是"项目上下文"。显示信息量递增。
SVG生成提示词： "Three circles side by side. Left smallest circle labeled '单句上下文'. Middle circle labeled '对话上下文'. Right largest circle labeled '项目上下文'. Below each circle show relative info size: single line, conversation bubbles, file icon."
第三节：CLAUDE.md 和 .cursorrules
不同的工具有不同的文件名，但作用是一样的。请见表6-1。
表6-1 不同工具的上下文文件
| 工具 | 文件名 | 用途 |
|---|---|---|
| Claude Code | CLAUDE.md | 项目说明和规范 |
| Cursor | .cursorrules | AI编码规则 |
| Windsurf | .windsurfrules | Windsurf专用规则 |
它们的作用都是：给AI的"入职手册"。
CLAUDE.md 完整示例
# 团队周报系统
## 项目概述
帮助团队收集和整理每周工作进展的工具。
## 目标用户
* 5-20人的团队
* 需要每周同步进度
* 可能远程工作
## 功能需求
1. 团队成员可以提交周报
2. 管理员可以查看所有周报
3. 支持按日期和人员筛选
4. 可以导出PDF
## 技术栈
* 前端：React + Vite
* 样式：Tailwind CSS
* 数据存储：localStorage（无需后端）
## 设计规范
* 主色：#3B82F6（蓝色）
* 成功色：#10B981（绿色）
* 错误色：#EF4444（红色）
* 简洁布局，卡片式设计
## 约束
* 单用户版本（暂时不支持多租户）
* 数据存储在浏览器本地
* 不需要用户登录（假设信任环境）
.cursorrules 示例
# AI编码规则
## 技术选择
我们优先使用：
* React hooks（不用类组件）
* Zustand（不用Redux）
* Tailwind CSS（不用CSS-in-JS）
## 代码风格
* 组件保持简洁，超过80行考虑拆分
* 函数名用camelCase
* 组件文件名用PascalCase
* 命名要语义化，不要用缩写
## 约束
* 不要引入大型依赖库
* 优先使用浏览器原生API
* 注意性能，避免不必要的重渲染
第四节：上下文的"黄金比例"
上下文给多少合适？太少→AI理解不够，太多→AI信息过载。
我建议的"黄金比例"请见表6-2。
表6-2 上下文内容分配建议
| 内容部分 | 比例 | 示例 |
|---|---|---|
| 项目背景 | 20% | 这是做什么的，给谁用 |
| 技术栈 | 20% | 用什么框架、库 |
| 功能需求 | 30% | 具体要实现什么 |
| 设计规范 | 15% | 样式、交互 |
| 约束条件 | 15% | 不能做什么 |
一个200到400字的CLAUDE.md通常就足够了。
第五节：如何维护上下文？
上下文不是写一次就完事的。随着项目演进，你需要更新它。
项目初期：
# 项目说明
这是一个简单的待办清单。
项目发展后：
# 项目说明
这是一个团队协作的待办清单，支持：
* 多用户
* 任务分配
* 截止日期提醒
什么时候更新上下文？
- 添加了新功能
- 更换了技术栈
- 发现AI老是犯同样的错误
- 团队规范发生变化
第六节：上下文工程 vs 提示词工程
请见表6-3的对比。
表6-3 上下文工程与提示词工程对比
| 提示词工程 | 上下文工程 |
|---|---|
| 关注"怎么问" | 关注"AI知道什么" |
| 优化单句表达 | 准备项目背景 |
| 像学"话术" | 像准备"文档" |
| 适合单次任务 | 适合长期项目 |
两者都重要，但对于AI编程来说，上下文工程更重要。
为什么？
- 项目会持续很久，上下文一直有用
- prompt可以不断调整，但上下文是一次准备长期受益
- 好的上下文能让prompt更简单
本章小结
这一章，我们学习了"上下文工程"——让AI真正理解你的项目。
我们用"给新员工布置任务"的类比来解释上下文的重要性。
我们介绍了三个上下文层次：单句、对话、项目上下文。
我们还展示了CLAUDE.md和.cursorrules的实际示例。
最后，我们对比了上下文工程和提示词工程：对于AI编程来说，上下文工程更重要。
在下一章，我们会学习"验证"——不懂代码也能检查AI的作业。
记住：
好的上下文比完美的prompt更重要。
先把上下文准备好，prompt会简单很多。