「一个好的提示词，就像一个好的需求文档——清晰、完整、可执行。」
开场：同样的需求，两个不同的结果
小维学了上一讲的提示词理论，今天要把它用在实战中。
他的任务：写一个 Redis 缓存模块，用于缓存用户的会话信息。
他用了新学的方法，写了这样的提示词：
你是一个 Node.js 后端工程师，专注于构建高性能的缓存系统。
任务：为我的 Express.js 应用创建一个 Redis 会话缓存模块
上下文：
- 应用使用 Express.js 5.0，TypeScript
- 已有 Redis 连接工具：src/lib/redis.ts，导出了一个 redis 实例
- 会话数据结构：{ userId: string, email: string, role: "user"|"admin", lastActive: Date }
- 会话 key 格式：session:{sessionId}
约束：
- 不使用 express-session 中间件（我们用自己的逻辑）
- 会话过期时间默认 30 分钟，可配置
- 必须处理 Redis 连接失败的情况（降级到内存缓存）
- 包含完整的 TypeScript 类型定义
- 包含 Jest 单元测试
需要实现的方法：
- createSession(userId, email, role): Promise<string> // 返回 sessionId
- getSession(sessionId): Promise<Session | null>
- updateSession(sessionId, updates): Promise<boolean>
- deleteSession(sessionId): Promise<boolean>
- extendSession(sessionId): Promise<boolean> // 重置过期时间
AI 给他了一个几乎完美的实现，只改了两个小地方就直接用了。
这个提示词里有一个清晰的"结构"——今天我们就来拆解这个结构。
全局视角：结构化提示词在哪里
graph LR
A["第07讲\n提示词为什么失败"] --> B["第08讲(本讲)\n结构化提示词公式"]
B --> C["第09讲\n上下文管理"]
B --> D["第12讲\n模板库构建"]
style B fill:#e8f4e8,stroke:#52c41a,stroke-width:2px
核心知识点：黄金公式——角色+任务+上下文+约束（RTCC）
这是本讲最核心的内容：一个可以立刻套用的结构化提示词公式。
[角色(Role)] + [任务(Task)] + [上下文(Context)] + [约束(Constraints)]
组件一：角色（Role）
目的：告诉 AI 以什么角色来回答问题
为什么有效：AI 在扮演特定角色时，会调用与该角色相关的知识和思维方式，生成更专业的回答。
常用角色模板：
| 场景 | 角色描述 |
|---|---|
| 后端开发 | 你是一个经验丰富的 Node.js/Python 后端工程师，擅长构建高可用、高性能的 API 服务 |
| 前端开发 | 你是一个前端工程师，专注于 React 生态，对性能优化和用户体验有深度经验 |
| 代码审查 | 你是一个资深代码审查员，对代码质量、安全性和可维护性有极高的标准 |
| 架构设计 | 你是一个系统架构师，擅长权衡技术方案的 trade-off，设计可扩展的系统 |
| 调试帮助 | 你是一个调试专家，擅长分析错误信息、找出根因并提供精准的修复方案 |
角色的精细化：角色越具体，结果越好
不好：你是一个程序员
好：你是一个专注于 Go 语言高并发编程的后端工程师，有大量 goroutine 和 channel 使用经验
组件二：任务（Task）
目的：明确、精确地描述你要 AI 做什么
有效的任务描述特征：
- 一个清晰的动词开头（实现、修复、优化、分析、生成……）
- 包含预期的输入和输出
- 指定具体的技术实现方式（如果有偏好）
任务描述模板：
实现 [功能名称]：
- 接口：[函数签名/API 路径/接口定义]
- 输入：[输入参数/请求体格式]
- 输出：[返回值/响应格式]
- 核心逻辑：[具体的处理逻辑]
组件三：上下文（Context）
目的：提供 AI 理解任务所需的背景信息
关键上下文类型：
graph TD
A["上下文信息"] --> B["技术栈上下文\n语言/框架/库版本"]
A --> C["代码库上下文\n已有的文件/接口/数据结构"]
A --> D["业务上下文\n用户是谁/应用场景/业务规则"]
A --> E["限制上下文\n性能要求/安全要求/合规要求"]
如何高效提供上下文：
技巧一：在 Cursor 里用 @文件名 引用已有文件
参考 @src/models/user.ts 的数据结构，帮我写一个...
技巧二：粘贴关键代码片段
已有的认证中间件如下，帮我在此基础上添加...
[粘贴代码]
技巧三：描述业务背景
这是一个 B2B SaaS 平台，用户分为三种角色：
- Owner（组织管理员）
- Admin（部门管理员）
- Member（普通成员）
在这个背景下，帮我实现权限检查中间件...
组件四：约束（Constraints）
目的：告诉 AI 什么不能做、必须满足什么条件
约束的类型：
| 类型 | 示例 |
|---|---|
| 技术约束 | 不使用 axios，用 fetch API；不引入新的 npm 包 |
| 性能约束 | 查询时间不超过 100ms；内存占用不超过 50MB |
| 代码风格 | 用 async/await 不用 Promise.then；函数名用驼峰命名 |
| 安全约束 | 所有输入必须做 SQL 注入检查；不在日志里打印密码 |
| 兼容性约束 | 必须兼容 Node.js 16+；使用 CommonJS 模块系统 |
| 范围约束 | 只修改这一个函数，不改动其他代码；不改变现有的接口签名 |
负向约束的重要性：
很多人只说"要做什么"，但不说"不要做什么"，导致 AI 引入了你不想要的东西。
常见的负向约束场景：
不要引入新的依赖包（AI 有时会为了简化代码引入额外库）不要修改现有的接口签名（AI 有时会"优化"接口，破坏向后兼容）不要添加我没要求的功能（AI 有时很"热心"，帮你加了很多额外功能）
深度拆解：公式的灵活运用
场景一：简单任务——只需要任务+上下文
对于简单的任务，不需要写完整的四个组件：
帮我把这个 JavaScript 函数用 TypeScript 重写，
保持函数逻辑不变，只是添加类型注解：
function calculateTotal(items) {
return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}
这里任务（重写函数）和上下文（原函数代码）就足够了。
场景二：代码审查——只需要角色+任务+代码
你是一个安全专家，对以下用户认证代码进行安全审查：
1. 找出潜在的安全漏洞（至少3个）
2. 对每个问题说明：问题是什么、风险级别（高/中/低）、修复方案
[粘贴代码]
场景三：调试任务——任务+错误信息+代码
帮我找出这段代码为什么抛出以下错误：
错误：TypeError: Cannot read properties of undefined (reading 'map')
Stack trace: at UserList.render (/src/components/UserList.tsx:23:18)
相关代码：
[粘贴代码]
可能的原因是什么？修复方案是什么？
场景四：架构设计——角色+任务+约束
你是一个分布式系统架构师。
我需要设计一个任务队列系统，满足以下需求：
- 每秒处理 1000+ 个任务
- 任务不能丢失（持久化存储）
- 支持任务优先级
- 支持失败重试（最多3次，指数退避）
- 支持任务状态查询
技术约束：
- 使用 Node.js 生态
- 不能引入需要额外运维的组件（不用 RabbitMQ、Kafka）
- 可以使用 Redis（已有 Redis 基础设施）
- 团队对 PostgreSQL 熟悉
请：
1. 给出 3 种可行的方案
2. 分析每种方案的优缺点和适用场景
3. 根据我的约束，推荐最合适的方案并说明理由
案例解析：三个真实提示词的优化前后对比
案例一：API 开发任务
优化前：
帮我写一个上传文件的接口
优化后：
你是一个 Express.js 后端工程师。
实现文件上传接口：POST /api/upload
- 支持图片文件（jpg, png, webp, gif）
- 最大文件大小：5MB
- 上传到本地 ./uploads 目录，文件名为：{timestamp}-{originalname}
- 返回：{ url: string, filename: string, size: number }
上下文：
- 使用 multer 库处理文件上传（已安装）
- Express.js 5.0，CommonJS 模块格式
约束：
- 对文件类型做严格验证（不只靠文件扩展名）
- 对文件大小做验证，超过限制返回 413 状态码和清晰的错误信息
- 返回的 url 是相对路径，如：/uploads/1234567890-image.jpg
效果对比：优化前需要 3-4 轮对话才能得到可用代码，优化后第一轮就能得到可以直接部署的代码。
案例二：代码重构任务
优化前：
帮我重构这段代码，让它更好
[粘贴了 200 行代码]
优化后：
你是一个代码质量专家。
请重构以下 Python 代码，目标是提高可维护性：
1. 将超过 50 行的函数拆分为多个小函数，每个函数只做一件事
2. 消除代码重复（DRY原则）
3. 改善变量命名（目前很多 x, y, temp 这类无意义命名）
约束：
- 保持函数的外部接口不变（调用方式不变）
- 不改变现有的日志逻辑
- 性能不能下降（测试对比再提交）
重构后请：
- 解释你做了哪些主要改动
- 标注哪些改动是"高影响"的（需要我重点关注）
[粘贴代码]
实操指南：提示词模板快速上手
收藏这 3 个万能模板，应对 80% 的常见场景：
模板一：功能开发
你是一个 [技术栈] 工程师。
实现 [功能名称]：
- 接口/函数：[签名]
- 输入：[格式]
- 输出：[格式]
- 逻辑：[步骤1]、[步骤2]...
上下文：
- 项目使用：[框架+版本]
- 相关文件：[文件路径和用途]
- 数据结构：[相关的 Model/Type]
约束：
- 不使用：[不想引入的库]
- 必须包含：[错误处理要求]
- 代码风格：[特定要求]
模板二：Bug 修复
帮我修复以下错误：
错误信息：
[粘贴错误信息]
出错代码：
[粘贴代码]
我期望的行为：[描述正确的行为]
实际发生的：[描述错误的行为]
注意：修复时不要改变函数的接口签名
模板三：代码优化
你是一个 [语言] 性能优化专家。
优化这段代码，目标是 [优化目标]：
- 当前性能：[当前表现，如执行时间/内存占用]
- 目标性能：[希望达到的水平]
- 数据规模：[需要处理的数据量级]
约束：
- 不改变输入/输出格式
- [其他约束]
[粘贴代码]
请：1) 分析性能瓶颈在哪里 2) 提供优化方案 3) 说明优化的预期效果
易错点与避坑指南
误区一：角色设定越夸张越好
你是世界上最厉害的程序员，能解决一切问题 这样的角色设定没有实际帮助。
有效的角色设定是具体的技术角色：你是专注于 React Native 性能优化的移动端工程师。
误区二：一定要写四个组件
不是每个提示词都需要全部四个组件。简单任务用两三个就够了。重要的是信息完整，而不是格式完整。
误区三：约束越多越好
约束过多有时会让 AI 在很多限制中挣扎，反而生成差劲的代码。只写真正重要的约束。
本讲小结
mindmap
root((结构化提示词RTCC))
角色Role
具体的技术角色
匹配任务领域
任务Task
清晰的动词开头
输入输出格式
上下文Context
技术栈信息
已有代码结构
业务背景
约束Constraints
正向约束-必须做什么
负向约束-不能做什么
代码风格约束
万能模板
功能开发模板
Bug修复模板
代码优化模板
思考题
-
找一个你最近写过的提示词，用 RTCC 公式分析它缺少了哪些组件？补充完整后，你认为结果会有什么不同？
-
"角色设定"在本质上是做什么的？为什么给 AI 设定角色会影响输出质量？
-
在约束里，"负向约束"（不能做什么）和"正向约束"（必须做什么）哪个更重要？你的判断是什么，为什么？
下一讲预告
我们有了结构化提示词的公式。但还有一个难题：
在一段长时间的对话中，如何让 AI 始终记得相关的上下文？
AI 有"遗忘"问题——对话太长之后，它会忘记早期的内容。
下一讲，我们专门讲上下文管理的技术和策略。
