跳转至

提示词的核心要素

提示词不是"想到什么写什么"，好的提示词都是结构化的。本篇拆解一个完整提示词由哪些要素组成、每个要素的作用、什么时候必须有、什么时候可以省。

1. 七大核心要素

一个高质量提示词通常由以下要素构成：

┌─────────────────────────────┐
│ 1. 角色（Role）              │
│ 2. 任务（Task）              │
│ 3. 上下文（Context）         │
│ 4. 输入（Input）             │
│ 5. 约束（Constraints）       │
│ 6. 输出格式（Format）        │
│ 7. 示例（Example）           │
└─────────────────────────────┘

不是每个提示词都需要全部。简单任务 2-3 个要素够用；复杂任务可能需要全部。

2. 角色（Role）

作用

给模型设定一个身份，激活它训练数据中相关的知识和风格。

写法

你是一名{资深/某领域}的{角色}，{专长 + 偏好}。

例子

你是一名有 15 年经验的安全工程师，专注于 Web 应用渗透测试，
偏好 OWASP 风格的报告。

注意

❌ 不要写得空洞："你是世界上最好的程序员" → 没用

✅ 写具体身份："你是熟悉 PostgreSQL 内核的 DBA" → 有用

什么时候必须有

  • 输出风格、口吻有要求时
  • 需要专业知识时
  • 多角色对话场景

什么时候可以省

  • 简单的提取、翻译、计算任务

3. 任务（Task）

作用

明确你要模型做什么。是整个提示词的"动词"。

写法

请{动词} {对象}，{动作的目的或形式}。

例子

请审查下面这段代码，重点关注安全漏洞。

注意

任务必须是单一的。如果有多个任务，要么拆成多次提示，要么明确编号：

❌ 一段话里夹了 3 件事："总结一下，再翻译，再生成 PPT"

✅ 编号： 

请按顺序完成：
1. 总结主要观点（200 字）
2. 把总结翻译成英文
3. 用总结写出 5 张 PPT 的标题

什么时候必须有

永远必须有。没有任务的提示词是无效的。

4. 上下文（Context）

作用

提供模型回答这个任务所需要的背景：项目情况、领域知识、约束条件。

写法

背景：
- {关键事实 1}
- {关键事实 2}
- {关键事实 3}

例子

背景：
- 这是一个面向小学生的英语学习 App
- 目标用户年龄 8-12 岁
- 当前用户主要痛点：单词记不住
- 我们已经有"单词卡片"功能，但留存差

带上这些上下文，模型给出的方案会针对你的真实场景，而不是泛泛而谈。

注意

  • 上下文要与任务直接相关，无关信息会干扰
  • 长度控制：超过 1000 字考虑用 RAG 或直接附文件
  • 关键事实排在前面（模型对开头更敏感）

什么时候必须有

  • 模型缺乏的领域知识、内部信息
  • 你期望的特殊视角

什么时候可以省

  • 模型自身知识够用的常识题

5. 输入（Input）

作用

待处理的具体内容：要分析的代码、要翻译的文本、要总结的会议记录。

写法

用明显的分隔符把输入括起来：

输入：
"""
{用户输入}
"""

或：

<input>
{用户输入}
</input>

例子

请翻译下面的文本：

"""
The quick brown fox jumps over the lazy dog.
"""

注意

  • 永远要用分隔符，避免输入和指令混在一起
  • 三引号、XML 标签、Markdown 代码块都行
  • Claude 推荐 XML 标签，GPT 偏好 Markdown 标题
  • 输入很长时，明确告诉模型：
下面的输入很长（约 5000 字），请完整阅读后再回答。

什么时候必须有

任务有具体处理对象时（基本上 80% 的提示词都要）

6. 约束（Constraints）

作用

限制模型的发挥空间，让输出落在期望范围内。

写法

要求：
- {约束 1}
- {约束 2}
- {约束 3}

例子

要求：
- 总结控制在 300 字
- 不要使用任何形容词
- 提到具体数字时保留原文数字
- 不要主观评价
- 不要发散到原文未提及的内容

常见的约束维度

维度 例子
长度 不超过 500 字、3 段以内、5 条
风格 平实、口语化、学术、营销文
词汇 避免某些词、保留专有名词
格式 Markdown / JSON / 表格
范围 只讨论 X、不讨论 Y
语气 严肃 / 幽默 / 中性
受众 给 5 岁孩子、给资深工程师

注意

约束越具体越好：

❌ "简洁一点" ✅ "每段不超过 50 字"

❌ "专业一些" ✅ "使用本领域术语，假设读者是同行"

7. 输出格式（Format）

作用

明确模型应该输出什么样的结构。给程序处理的输出，必须明确格式。

写法

直接说结构 + 给一个空模板：

按以下格式输出：

# 标题
## 摘要
（一段话）

## 关键点
- ...
- ...

## 建议
1. ...
2. ...

JSON 输出

按以下 JSON 输出，仅输出 JSON 不要任何额外文字：

{
  "title": "string",
  "tags": ["string"],
  "summary": "string",
  "score": "number 1-10"
}

表格输出

按 markdown 表格输出：

| 序号 | 问题 | 严重程度 | 修复建议 |
|---|---|---|---|

注意

  • 用程序处理输出时，JSON > 表格 > 自由格式
  • 长复杂结构，用嵌套 JSON 比 Markdown 更稳定
  • 在末尾再强调一次"只输出 X，不要前言后语"

8. 示例（Example）

作用

让模型从范例中学，比解释一百句更有效。这就是 Few-shot 的核心。

写法

示例：

输入：{example_input_1}
输出：{example_output_1}

输入：{example_input_2}
输出：{example_output_2}

现在的输入：
{actual_input}

例子

请把英文产品描述改写成中文营销文案。

示例：

输入：Lightweight design for all-day comfort
输出：轻盈到几乎感觉不到，戴一整天也不累

输入：Premium aluminum body
输出：航空级铝合金机身，质感更高级

现在的输入：
Active noise cancellation up to -45dB
输出：

模型会"学到"你期望的风格（动词开头、感性描写、不直译）。

注意

  • 2-3 个示例足够，太多反而过拟合
  • 示例要多样化，覆盖不同情况
  • 示例的输出必须高质量，模型会把它当标准

9. 七要素的优先级

不是全部都重要。按"必须 → 推荐 → 可选"分级：

优先级 要素 何时省略
🔴 必须 任务 永远不能省
🔴 必须 输入 任务有处理对象时必须
🟠 强烈推荐 输出格式 程序消费输出时必须
🟠 强烈推荐 约束 防止输出跑偏
🟡 推荐 角色 输出风格无要求时可省
🟡 推荐 上下文 通用任务可省
🟢 可选 示例 模型已经熟悉格式时可省

10. 三个完整模板

模板 A：分析任务

[角色]
你是一名 {领域} 专家。

[任务]
请分析下面的 {对象}，重点关注 {关注点}。

[上下文]
背景：{相关背景}

[输入]
"""
{待分析内容}
"""

[约束]
- 不要分析 {无关项}
- 输出限 {长度}
- 用 {语气}

[格式]
按 markdown 表格输出：
| {字段1} | {字段2} | {字段3} |

[示例]
{示例输入 → 示例输出}

模板 B：生成任务

[角色]
你是一名 {领域} 专家。

[任务]
为 {对象} 生成 {产物}。

[上下文]
{产品/受众/目标}

[约束]
- {风格}
- {长度}
- {禁止项}

[格式]
{结构模板}

[示例]
{2-3 个示例}

模板 C：提取任务

[任务]
从下面文本中提取信息。

[输入]
"""
{文本}
"""

[字段定义]
- field1: 类型，含义
- field2: 类型，含义

[约束]
- 仅输出 JSON，不要任何额外文字
- 字段缺失用 null，不要省略字段
- 多结果用数组

[示例]
{1 个示例}

11. 一个错误对照案例

需求：让模型把日记总结成 100 字的摘要。

❌ 全要素混乱版

我希望你能帮我，最好是非常仔细地，看一下下面我写的日记，
然后给我一个总结。要求是简洁、好懂、抓重点。请用一种比较温暖
但又不失专业的语气，不要太长，但也不能太短，差不多就好。

日记内容：今天天气不错……

问题： - 任务模糊（"看一下"、"给我一个总结"） - 约束矛盾（"温暖"+"专业"，"不太长不太短"） - 输入和指令混在一起，没分隔符

✅ 七要素清晰版

[任务]
将下面的日记总结成 100 字的摘要。

[约束]
- 字数：90-110 字
- 保留具体事件和情感，不做抽象升华
- 不要使用形容词堆砌（如"美好的"、"难忘的"）
- 用第三人称叙述

[格式]
直接输出摘要，不要前言后语。

[输入]
"""
今天天气不错……
"""

输出质量提升明显。

12. 不同模型的"偏好"

模型 偏好的结构
Claude XML 标签包裹各部分，长指令耐受好
GPT Markdown 分节，明确编号
Gemini 类似 GPT，但对长上下文支持极好
开源小模型 短而严格的指令，多给示例

Claude 推荐风格：

<role>你是一名资深技术编辑</role>

<task>校对下面的文章，找出语法错误</task>

<constraints>
  - 只指出错误，不要重写
  - 用表格输出
</constraints>

<article>
{文章内容}
</article>

GPT 推荐风格：

# Role
你是一名资深技术编辑

# Task
校对下面的文章，找出语法错误

# Constraints
- 只指出错误，不要重写
- 用表格输出

# Article
{文章内容}

13. 一个被忽略的"隐藏要素"：失败处理

模型遇到不会、不确定的情况怎么办？显式告诉它：

如果信息不足以完成任务，
不要硬答，而是输出：
{"status": "need_more_info", "missing": ["xxx", "yyy"]}

如果输入与任务无关，
输出：
{"status": "out_of_scope"}

这样可以避免模型"硬编"，提高生产环境可靠性。

14. 检查清单

写完提示词后，对照这张表检查：

要素 必须 / 可选 是否有 是否具体
角色 推荐 □ □
任务 必须 □ □
上下文 推荐 □ □
输入 视情况 □ □
约束 强烈推荐 □ □
输出格式 强烈推荐 □ □
示例 可选 □ □

每个要素打两个勾：有没有，以及够不够具体。

总结

  • 提示词的七大核心要素：角色、任务、上下文、输入、约束、格式、示例
  • 任务和输入是必须，约束和格式是强烈推荐，其他按需取舍
  • 角色要具体（"PostgreSQL DBA" > "技术专家"）
  • 约束要量化（"50 字内" > "简洁"）
  • 示例要多样、要高质量（模型会把它当标准）
  • Claude 偏 XML，GPT 偏 Markdown，按目标模型选风格
  • 加上"失败处理"指令，让生产可靠性提升一个档次
  • 用七要素检查表自查，避免漏掉关键维度

评论