Prompt工程02：上下文组织
从背景资料、代码片段、日志、约束条件的优先级，理解如何组织有效的上下文给大模型。
上下文是大模型理解任务的基础，好的上下文组织能让模型更准确地理解你的需求。理解如何组织上下文，是提升 Prompt 效果的关键。
上下文的重要性
模型的输出质量很大程度上取决于提供的上下文质量。
缺少上下文 vs 充足上下文
缺少上下文：
帮我写一个登录接口。充足上下文：
背景：我们正在开发一个电商平台，需要实现用户登录功能
技术栈：Java 21 + Spring Boot 3.2 + MySQL
现有代码：
- 用户实体类：User.java
- 用户服务：UserService.java
- 数据库表：users (id, username, password_hash, email, created_at)
约束：
- 密码使用 BCrypt 加密
- 返回 JWT token
- 支持邮箱和用户名登录上下文对输出的影响
| 维度 | 缺少上下文 | 充足上下文 |
|---|---|---|
| 相关性 | 低 | 高 |
| 准确性 | 低 | 高 |
| 一致性 | 低 | 高 |
| 修改次数 | 多 | 少 |
上下文的类型
根据任务类型，需要提供不同类型的上下文。
背景资料
提供任务的背景信息：
| 类型 | 示例 | 适用场景 |
|---|---|---|
| 业务背景 | ”我们正在开发一个电商平台” | 所有任务 |
| 技术背景 | ”使用 Java 21 和 Spring Boot” | 技术任务 |
| 历史背景 | ”之前尝试过方案 A，但遇到了问题” | 复杂任务 |
| 目标背景 | ”这个功能需要在下个月上线” | 项目任务 |
代码片段
提供相关的代码：
| 类型 | 示例 | 适用场景 |
|---|---|---|
| 实体类 | User.java | 代码生成 |
| 服务类 | UserService.java | 代码修改 |
| 配置文件 | application.yml | 配置相关 |
| 接口定义 | API 文档 | 接口开发 |
日志信息
提供相关的日志：
| 类型 | 示例 | 适用场景 |
|---|---|---|
| 错误日志 | Stack Trace | 问题排查 |
| 运行日志 | 应用日志 | 性能分析 |
| 测试日志 | 测试输出 | 测试问题 |
约束条件
提供任务的约束：
| 类型 | 示例 | 适用场景 |
|---|---|---|
| 技术约束 | ”使用 Java 21” | 技术任务 |
| 时间约束 | ”代码需要在 1 秒内执行” | 性能任务 |
| 安全约束 | ”不要暴露敏感信息” | 安全任务 |
| 业务约束 | ”符合公司的编码规范” | 规范任务 |
参考资料
提供相关的参考资料：
| 类型 | 示例 | 适用场景 |
|---|---|---|
| API 文档 | 第三方 API 文档 | 集成任务 |
| 技术文档 | 技术方案文档 | 方案设计 |
| 设计文档 | UI 设计文档 | 前端任务 |
上下文组织的原则
1. 相关性原则
只提供与任务相关的上下文：
不好：
这里有很多代码，帮我看看哪里有问题。
[粘贴了整个项目的代码]好：
我遇到了一个问题，下面是相关的代码：
- UserService.java（用户服务类）
- LoginController.java（登录控制器）
- 错误日志：[粘贴错误日志]2. 结构化原则
使用结构化的方式组织上下文：
不好：
用户实体类有 id、name、email，数据库表也是这些字段，密码需要加密，返回 JWT。好：
【用户实体类】
User.java：
- id (Long)
- name (String)
- email (String)
- passwordHash (String)
【数据库表】
users 表：
- id BIGINT PRIMARY KEY
- name VARCHAR(100)
- email VARCHAR(200) UNIQUE
- password_hash VARCHAR(255)
【安全要求】
- 密码使用 BCrypt 加密
- 返回 JWT token3. 优先级原则
把重要的上下文放在前面：
【核心需求】（最重要）
实现用户登录接口，支持用户名和邮箱登录
【技术栈】
Java 21 + Spring Boot 3.2 + MySQL
【现有代码】
[相关代码]
【约束条件】
[约束条件]4. 简洁性原则
避免提供过多的上下文：
不好：
[粘贴了 1000 行代码]
帮我优化这段代码。好：
我需要优化以下代码的性能，请重点关注 getUserList 方法：
[粘贴 getUserList 方法的代码，约 50 行]上下文组织的技巧
使用分隔符
使用分隔符区分不同类型的上下文：
=== 背景资料 ===
我们正在开发一个电商平台...
=== 现有代码 ===
[代码片段]
=== 约束条件 ===
- 使用 Java 21
- 返回 JWT token使用标题
使用标题组织上下文：
# 任务背景
我们正在开发一个电商平台...
# 技术栈
- Java 21
- Spring Boot 3.2
- MySQL
# 现有代码
## 用户实体类
[代码]
## 用户服务类
[代码]使用代码块
使用代码块包裹代码：
用户实体类：
```java
public class User {
private Long id;
private String username;
private String passwordHash;
}数据库表：
CREATE TABLE users (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(100) UNIQUE,
password_hash VARCHAR(255)
);
### 使用列表
使用列表组织信息：
需求：
- 实现用户登录接口
- 支持用户名和邮箱登录
- 密码使用 BCrypt 加密
- 返回 JWT token
约束：
- 使用 Java 21
- 使用 Spring Boot 3.2
- 返回 JSON 格式
## 上下文组织的常见问题
### 问题1：上下文太多
**表现**：模型被大量无关信息淹没
**示例**：[粘贴了整个项目的代码] 帮我写一个登录接口。
**解决**：我需要实现一个登录接口，请参考以下相关代码： [只粘贴相关的代码片段]
### 问题2：上下文太少
**表现**：模型缺少必要的信息
**示例**：帮我写一个登录接口。
**解决**：背景：我们正在开发一个电商平台 技术栈：Java 21 + Spring Boot 3.2 现有代码：[相关代码] 约束：[约束条件]
### 问题3：上下文混乱
**表现**：上下文组织无序，模型难以理解
**示例**：用户实体类有 id、name、email，密码需要加密，使用 Java 21，返回 JWT，数据库表有 id、username、password_hash…
**解决**：【技术栈】 Java 21 + Spring Boot 3.2
【现有代码】 用户实体类：[代码] 数据库表：[SQL]
【约束条件】
- 密码使用 BCrypt 加密
- 返回 JWT token
### 问题4：上下文过时
**表现**：提供的上下文与当前情况不符
**示例**：用户实体类： [旧版本代码] 帮我实现登录接口。
**解决**：用户实体类（最新版本）： [最新代码] 帮我实现登录接口。
## 上下文长度的管理
上下文长度受模型窗口限制，需要合理管理。
### 上下文长度策略
| 策略 | 描述 | 适用场景 |
|------|------|---------|
| 完整上下文 | 提供所有相关上下文 | 短任务 |
| 精简上下文 | 只提供核心上下文 | 中等任务 |
| 分层上下文 | 先提供高层上下文，需要时再补充 | 复杂任务 |
| 外部检索 | 使用 RAG 检索外部知识 | 需要大量知识 |
### 上下文压缩技巧
| 技巧 | 描述 | 效果 |
|------|------|------|
| 摘要压缩 | 对长文本进行摘要 | 减少长度 |
| 代码压缩 | 只保留关键代码 | 减少长度 |
| 分层提供 | 分多次提供上下文 | 避免超限 |
| 优先级排序 | 只提供最重要的上下文 | 减少长度 |
## 项目判断清单
- 模型输出不相关 → 检查上下文是否相关
- 模型输出不准确 → 检查上下文是否充足
- 模型输出混乱 → 检查上下文是否结构化
- 上下文过长 → 使用压缩技巧或分层提供
- 上下文过短 → 补充必要的上下文
- 上下文过时 → 更新上下文为最新版本