一个好 Prompt 由 5 个要素构成:角色(Role)、任务(Task)、上下文(Context)、约束(Constraints)、输出格式(Format)。前 4 个合称 RTCC(Day3 课堂口径),是 Prompt 的"骨架";Format 是工程级 Prompt 必备的"出口"。
表达的本质公式:表达 = 本意 + 文意 + 解意(说话人的本意 → 编码 → 文意 Prompt → 解码 → AI 的解意)。Prompt 就是这个编码过程——需要把本意(经验+词汇+知识)精准编码为文意。
五要素总览
| 要素 | 作用 | 缺失会怎样 |
|---|---|---|
| 角色(Role) | 告知 AI"你是谁",进入知识域+思维范式+表达风格 | 没有立场,回答泛泛而谈 |
| 任务(Task) | 用精确动词锁定"要做什么" | 目标不确定,AI 可能做一堆无关的事 |
| 上下文(Context) | 提供做决策所需的全部背景信息 | 信息不足,AI 只能瞎猜 |
| 约束(Constraints) | 明确禁区与必选项,构成边界护栏 | 无边界,回答可能有合规/安全风险 |
| 输出格式(Format) | 规定"答案长什么样",便于程序解析或用户阅读 | 格式混乱,程序难以解析,影响产品可用性 |
随着场景复杂度提升,每个要素都可以从一句话扩展到一张维度表(见下)。
一、角色(Role)
让模型进入某个知识域 + 思维范式 + 表达风格的"角色状态"。
模板:你是一位[年限]的[细分领域][身份],擅长[3个具体技能],思维风格偏向[风格描述],表达风格要求[风格描述],默认从[受众]的视角出发思考问题。
| 维度 | 说明 | 示例 |
|---|---|---|
| 身份定位 | 职业/岗位 | 高级产品经理、算法工程师、小学语文老师 |
| 资历年限 | 经验深度决定输出颗粒度 | 5 年经验、10 年经验、刚入行 |
| 专业领域 | 细分赛道 | 不是泛泛的"程序员",而是"高并发支付系统后端工程师" |
| 思维风格 | 思考方式与价值观 | 务实派/理想派、防御性/激进型、数据驱动/直觉驱动 |
| 表达风格 | 语言调性 | 严谨学术风、口语化科普风、互联网黑话风、公文风 |
| 受众视角 | 角色默认站在谁的角度说话 | 站在 CTO 角度做汇报、站在用户角度做解释 |
关键技巧:角色越具体越好——"儿科医生" > "医生" > "专家",越具体越容易教导 AI 专业知识。
二、任务(Task)
用精确动词锁定模型的动作类型。任务描述的质量直接决定输出是"可用交付物"还是"正确的废话"。
模板:请[动作动词][作用对象],目标是[目标结果],范围限定在[范围边界],执行步骤如下:1.[步骤1] 2.[步骤2] 3.[步骤3]
| 维度 | 说明 | 常用动词/示例 |
|---|---|---|
| 动作类型 | 对信息做何种加工 | 生成、分析、对比、评审、提取、转换、总结、诊断、优化、翻译、改写 |
| 作用对象 | 操作的具体内容 | 以下 PRD 文档、以下代码片段、以下用户反馈数据 |
| 目标结果 | 最终要得到什么 | 一份可评审的 PRD、3 个优化建议、一份风险清单 |
| 范围边界 | 做多大、做多深 | 只关注登录模块,不关注注册;只分析性能,不分析安全 |
| 步骤拆解 | 复杂任务的分阶段执行 | 第一步先…第二步再…第三步最后… |
三、上下文(Context)
提供模型做高质量决策所需的全部背景信息。上下文缺失时模型只能基于通用知识"猜"。
| 维度 | 说明 | 示例 |
|---|---|---|
| 业务背景 | 这是什么项目/产品 | 这是一个面向证券从业人员的合规培训 APP |
| 用户画像 | 最终使用者是谁 | 用户是 50 岁以上的一线柜员,对智能手机操作不熟悉 |
| 当前状况 | 现状与痛点 | 当前版本日活 2000,用户反馈"找不到课程入口"占比 35% |
| 历史信息 | 之前做过什么、为什么失败 | 上一版方案因接入第三方 SDK 致合规审查未通过 |
| 技术/资源约束 | 可用什么、不可用什么 | 技术栈限定 Vue3+TS,不可用任何付费第三方组件库 |
| 数据输入 | 本次任务基于什么材料 | 以下是一份近 30 天的客服工单记录… |
| 决策标准 | 好坏的判断依据是什么 | 评估标准优先级:安全性 > 性能 > 开发成本 |
| 关联系统 | 与哪些已有系统交互 | 需对接现有单一登录系统(CAS 协议),不可自建用户体系 |
四、约束(Constraints)
明确禁区(不能做)与必选项(必须做),构成输出的边界护栏。约束是最后的质量闸门。
结构模板:
【必须遵守】
1. [正向约束1]
2. [正向约束2]
【绝对禁止】
1. [负向约束1]
2. [负向约束2]
【冲突裁决】
当[情况A]与[情况B]冲突时,优先遵循[X]
| 维度 | 类型 | 说明 | 示例 |
|---|---|---|---|
| 内容禁区 | 负向 | 绝对不能出现的内容 | 不要出现"根据经验"等模糊表述;禁止使用 eval() |
| 内容必含 | 正向 | 必须出现的关键要素 | 必须包含 3 个具体案例;必须引用 2024 年后数据 |
| 范围边界 | 负向 | 不越界讨论 | 只讨论前端性能优化,不涉及后端数据库 |
| 逻辑规则 | 正向 | 推理或呈现的规则 | 每个结论必须紧跟依据;缺点必须成对出现 |
| 优先级规则 | 正向 | 冲突时的取舍标准 | 当安全性与便利性冲突时,优先安全性 |
| 验证规则 | 正向 | 输出前的自检要求 | 输出前请自检:是否所有数据都有来源? |
五、输出格式(Format)
规定答案的形态。这是 RTCC 之外、五要素独有的一环——尤其在工程化调用(解析 JSON、渲染 Markdown、抽取字段)场景下不可或缺。
常见形态:
- JSON:便于程序解析,字段名锁定、类型可校验
- Markdown 表格 / 列表:便于人读,结构清晰
- 三段式结论 / 五段式报告:固定段落骨架,避免漂移
- 自然语言 + 字数上限:限定篇幅,避免冗长
示例:
严格按以下 JSON 格式输出,不要多余文字:
{
"结论": "...",
"理由": "...",
"置信度": 0.0-1.0
}
实战 Prompt 模板(五要素整合)
#角色
你是一位资深的{专业领域}专家,擅长{核心能力}
#任务
请基于以下信息,{具体动作}:
{用户输入}
#背景
- 业务场景:{场景描述}
- 目标用户:{用户信息}
- 参考资料:{知识内容}
#规则
1. {必须做的}
2. {绝不能做的}
3. {边界情况怎么处理}
#输出
严格按以下JSON格式输出,不要多余文字:
{
"结论": "...",
"理由": "...",
"置信度": 0.0-1.0
}
常见错误 Prompt
- "帮我写一篇文章"(太模糊,缺 Task/Context)
- "用专业的方式分析"(太虚,缺 Role/Constraints)
- "越详细越好"(无边界,缺 Constraints)
- "不给任何格式要求"(难以解析,缺 Format)
进阶技巧
在五要素骨架之上,CoT、Few-Shot、XML 分层、自我检查等技巧可进一步提升 30%+ 效果,详见 提示词进阶技巧。
相关页面
→ 提示词进阶技巧 → 提示词工程四象限法则 → Few-Shot少样本提示 → Agent五要素技术定义 → POC验证 → 效果评测体系 → Prompt编写操作指南(可执行版) → AIPM课程 Day2 → AIPM课程 Day3 → 2026-05-07 互联网产研到AI产研的变化和区别