提示与上下文
Context 窗口管理。
30 分钟
提示与上下文
这一课你将能做到
- 写出结构化的提示词（角色+任务+约束+输出格式）
- 用「上下文切片」技巧，只给 AI 需要的最小信息量
- 区分「一次性提示」和「多轮迭代」的适用场景
为什么要学
同样的 AI 工具，同样的模型，不同人得到的输出质量天差地别。差别不在模型，在输入。提示词是你在 Vibe Coding 时代的核心技能——它不是「说话好听」，是工程化的信息传递。
人话：AI 是个绝顶聪明但完全不了解你处境的远程同事。你给它一封含糊的邮件，它回一份含糊的方案；你给它结构化的需求文档，它回结构化的代码。提示词工程就是把「我想要什么」翻译成「AI 能精确执行什么」。
真实开发中，80% 的「AI 不听话」问题，根源是上下文给得不对——给少了它瞎猜，给多了它抓不住重点，给乱了它自相矛盾。
先建立图像
差的提示词 → 差的输出 → 返工
↑_________________________|
好的提示词 → 好的输出 → 直接可用
↑_________________________|
结构化提示词四要素：
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 角色 │ │ 任务 │ │ 约束 │ │ 输出格式 │
│你是谁？ │ │做什么？ │ │不能做什么│ │给我什么？ │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
跟着做
步骤 1：写一个反面教材
先体验「差的提示词」的威力：
帮我写个文章列表接口
AI 会给你一个「能跑但没法用」的东西——返回结构不统一、没有分页、没有异常处理、用的框架可能都不是你项目里的。
步骤 2：用四要素重写
角色：你是资深 Java 后端工程师，熟悉 Spring Boot 3 和 MyBatis-Plus。
任务：为文章模块实现分页列表查询接口。
约束：
- 用 MyBatis-Plus 的 Page 和 QueryWrapper，不要手写 SQL
- 返回统一用 Result<Page<ArticleVO>> 包装
- 支持按标签 id（可选）和关键词（可选）筛选
- 默认按创建时间倒序
- 不要引入新依赖
输出格式：
1. ArticleController 的 list 方法
2. ArticleService 的 list 方法
3. ArticleVO 类
4. 对应的单元测试
对比两个输出，你会直观感受到四要素的价值。
步骤 3：掌握「上下文切片」
AI 的上下文窗口有限（虽然越来越大），塞太多无关信息它会「注意力涣散」。正确做法是只给当前任务需要的最小切片：
差：把整个 ArticleService.java（300 行）贴给 AI，说「改第 87 行的分页逻辑」
好：只贴相关片段
---
public Page<Article> list(int page, int size) {
// 现有实现：内存分页，数据量大时 OOM
List<Article> all = articleMapper.selectList(null);
int start = (page - 1) * size;
return new Page<Article>().setRecords(
all.subList(start, Math.min(start + size, all.size()))
);
}
---
任务：把内存分页改成数据库分页，用 MyBatis-Plus 的 Page
步骤 4：用「多轮迭代」代替「一次性完美」
不要试图写出一个「完美提示词」让 AI 一次到位。真实高效的做法是：
第 1 轮：给骨架需求，让 AI 出方案（不要代码）
→ 你确认方案方向
第 2 轮：给详细约束，让 AI 出代码
→ 你审查，标记问题
第 3 轮：针对问题局部修正
→ 「第 42 行的空指针处理不对，应该用 Optional」
第 4 轮：让 AI 自己跑测试验证
→ 「跑一下测试，失败了修复」
每一轮你的角色是「验收员+纠偏员」，不是「一次性把话说完」。
步骤 5：建立你的提示词模板库
把高频场景的提示词存成模板，复用：
## 代码生成模板
角色：你是 [语言/框架] 资深工程师
任务：[一句话说清楚要做什么]
约束：
- [技术约束：用什么框架/库]
- [风格约束：返回格式、命名、注释]
- [范围约束：只做 X，不要做 Y]
- [依赖约束：不引入新依赖]
输出格式：[文件清单 / 代码 / 测试 / 文档]
## Bug 修复模板
现象：[错误信息/异常堆栈]
复现步骤：[最小可复现路径]
相关代码：[贴最小相关片段]
预期行为：[应该什么样]
实际行为：[现在什么样]