提示与上下文

这一课你将能做到

1. 写出结构化的提示词（角色+任务+约束+输出格式）
2. 用「上下文切片」技巧，只给 AI 需要的最小信息量
3. 区分「一次性提示」和「多轮迭代」的适用场景

为什么要学

同样的 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 修复模板
现象：[错误信息/异常堆栈]
复现步骤：[最小可复现路径]
相关代码：[贴最小相关片段]
预期行为：[应该什么样]
实际行为：[现在什么样]

讲清楚要点

1. 提示词是工程文档，不是聊天：用写需求文档的严谨度写提示词，输出质量立竿见影。
2. 上下文切片是核心技能：给 AI 的信息要像手术刀一样精准——只给当前任务需要的最小片段，不多不少。
3. 约束比需求更重要：「不做什么」比「做什么」更能防止 AI 跑偏。不写「不要做权限」，AI 就会给你加权限。
4. 输出格式定义验收标准：明确说「给我 4 个文件：Controller/Service/VO/Test」，AI 就不会漏掉测试。
5. 多轮迭代优于一次性完美：先方案后代码，先骨架后细节，每轮你验收纠偏，比试图写一个完美提示词高效得多。

你可能会懵的地方

• 提示词要写多长？ 没有固定长度，标准是「AI 不会问出你不确定的细节」。一个 CRUD 接口可能 100 字够了；一个复杂业务逻辑可能需要 500 字。判断标准：如果 AI 的输出和你预期差距大，多半是提示词里缺了关键约束。

• 为什么 AI 有时候会「忘记」我前面说的要求？ 上下文窗口有限，对话太长时早期的约束会被挤出窗口。对策：重要约束写进规则文件（自动注入），或在新会话里重复关键约束。

• 「思维链」（Chain of Thought）有用吗？ 对复杂推理任务有用。加一句「先分析思路，再给出代码」，AI 会先输出推理过程，你可以从中发现逻辑错误。但对简单 CRUD 是浪费 token。

• 怎么让 AI 生成「我看得懂」的代码？ 在约束里写「代码要有中文注释解释关键逻辑」或「每个方法不超过 30 行」。AI 默认会写「能跑但难读」的代码，明确要求可读性它就会调整。

• 提示词模板会不会限制 AI 的创造力？ 会，但这正是你要的。Vibe Coding 里你要的是「可控的输出」，不是「惊艳的创意」。创造力留给设计阶段，实现阶段要的是确定性。

错法对照

错法	问题	正解
「帮我写个文章接口」	需求全留给 AI 脑补	四要素结构化描述
贴 500 行代码让 AI 找 bug	注意力涣散，抓不住重点	只贴最小相关片段
不写约束	AI 自由发挥，过度设计	明确「不做什么」和「用什么」
一次性要完美输出	提示词越写越长，AI 抓不住重点	多轮迭代，逐步细化
不定义输出格式	AI 漏掉测试或文档	明确说「给我哪几个文件」

卡点急救

1. AI 输出和你预期差距大：不要继续追问，回到提示词本身。把提示词和预期写成两栏对比，缺什么补什么。
2. 对话太长 AI 开始「忘事」：开新会话，把关键约束和当前进度重新贴一遍。旧会话的上下文污染比新会话的重复成本更高。
3. AI 生成的代码风格和你项目不一致：把项目里一个「样板文件」贴给 AI 作为参考（「参照这个风格」），比口头描述风格有效。

面试常问

• 你怎么写提示词让 AI 生成高质量代码？ 高分回答：结构化四要素（角色/任务/约束/输出格式）；上下文切片只给最小相关信息；约束里明确「不做什么」；多轮迭代先方案后代码；把高频场景沉淀为团队共享的提示词模板。

• 提示词工程和传统编程的边界在哪？ 提示词工程是「精确描述意图」的能力，传统编程是「精确实现逻辑」的能力。AI 时代两者融合：用自然语言描述意图，用代码验证实现。工程师的核心竞争力从「写代码」转向「描述问题+验证答案」。

• 如何避免 AI 生成代码的「幻觉」？ 约束里写死技术栈和版本号；要求 AI 引用项目里已有的文件作为参考；生成后人工审查 import 和 API 调用是否真实存在；CI 里跑编译和测试兜底。

自测三问

1. 结构化提示词的四要素是什么？
2. 什么是「上下文切片」？为什么它比「把整个文件贴给 AI」更有效？
3. 为什么「多轮迭代」比「一次性完美提示词」更高效？

小结一句话

提示词是你在 AI 时代的编程语言——结构化、有约束、可迭代，才能让 AI 从「随机生成器」变成「可靠执行者」。

延伸

• Anthropic 提示工程指南
• OpenAI 提示工程最佳实践
• 下一课：调试——AI 辅助下的系统化调试工作流。