2 提示词解剖

引言

结构良好的提示词是有效AI交互的基础。研究表明，结构化提示词相比非结构化查询可将输出质量提高3-5倍（Lakera，2025）。

本章将拆解有效提示词的基本组成部分，并介绍领先AI团队使用的经过验证的框架。

五个核心组件

每个有效的提示词都包含五个核心组件。将它们视为构建块，当组合在一起时，就能创建精确、可靠的指令。

组件1：角色定位

定义：定义AI在回应时应该扮演什么角色。

重要性：清晰的角色定位建立：

专业知识水平：初级与高级视角
领域知识：专业背景和经验
沟通风格：正式、随意、技术性或友好
决策框架：风险容忍度、优先级、价值观

最佳实践：

<!-- ✅ 具体且可操作 -->
<persona>
你是一位拥有15年构建高吞吐量电商平台经验的资深Java架构师。
你专精于Spring Boot、事件驱动架构和云原生模式。
你偏好实用主义解决方案而非理论纯粹性。
</persona>

<!-- ❌ 太模糊 -->
<persona>你是一位专家程序员。</persona>

<!-- ❌ 过度指定（不必要的约束） -->
<persona>
你是一位42岁的男性Java架构师，2003年毕业于MIT，
GPA 3.8，曾在Google、Amazon和两家初创公司工作，
住在德克萨斯州奥斯汀，有两个孩子，喜欢攀岩，
更喜欢IntelliJ而非Eclipse，使用Cherry MX Brown开关的机械键盘...
</persona>

何时包含角色定位：

领域特定任务（医疗、法律、技术）
风格敏感的应用（客户支持、营销）
需要一致视角的多步推理
当默认"有帮助助手"不足时

何时跳过角色定位：

简单的事实查询（"法国的首都是什么？"）
客观性比视角更重要的任务
当简洁性至关重要且角色定位不增加价值时

组件2：指令

定义：核心任务定义——你想要模型做什么。

重要性：清晰的指令防止：

关于预期结果的歧义
对范围的误解
不完整或偏离目标的回应

最佳实践：

1. 使用行动动词：

// ❌ 弱
"也许你可以看看这段代码"

// ✅ 直接
"审查这段代码的安全漏洞"

2. 将复杂任务分解为步骤：

<instructions>
步骤1：识别代码中的主要安全漏洞
步骤2：解释为什么它是可利用的
步骤3：提出带有代码示例的特定修复方案
步骤4：建议如何在未来预防类似问题
</instructions>

3. 明确指定范围：

<!-- ✅ 清晰的边界 -->
`<instruction>`
分析提供的SQL查询的性能问题。

重点关注：
- 索引使用情况
- 连接效率
- 潜在的N+1问题

不要建议：
- 模式更改
- 反规范化
- 架构替代方案
`</instruction>`

4. 对多部分任务使用编号列表：

`<instruction>`
完成以下分析：
1. 用一句话总结用户的投诉
2. 分类紧急程度（低/中/高）
3. 提出三种可能的解决方案
4. 推荐最佳选项并给出理由
`</instruction>`

组件3：上下文

定义：模型理解情况所需的背景信息。

重要性：上下文防止模型做出错误的假设，并支持领域相关的回应。

上下文类型：

上下文类型	目的	示例
环境	物理/系统设置	"处理10K TPS的电商平台"
领域	行业/领域知识	"医疗保健，需要HIPAA合规"
历史	之前的尝试/数据	"之前的解决方案因X而失败"
受众	谁会消费输出	"给非技术高管"
约束	已知的限制	"不能修改现有的数据库模式"

最佳实践：

1. 提供适量的上下文：

<!-- ✅ 充分的上下文 -->
<context>
我们正在使用Spring Boot构建一个支付处理微服务。
系统在高峰期处理10,000个事务/秒。
当前问题：高负载期间数据库连接池耗尽。
</context>

<!-- ❌ 信息过载 -->
<context>
我们正在使用Spring Boot 3.2.1构建支付处理微服务
使用Java 21，部署在us-east-1的3个可用区的Kubernetes上，
使用PostgreSQL 15和pgBouncer连接池，
Redis用于缓存，TTL为6小时，
RabbitMQ用于消息队列，4个分区，复制因子为2，
我们使用Spring Cloud Kubernetes进行服务发现，
使用Spring Cloud Config进行配置管理，
团队由5名开发人员组成...
</context>

2. 将上下文放在指令之前：

<!-- ✅ 正确的顺序 -->
<context>系统处理10K TPS</context>
`<instruction>`优化这个数据库查询`</instruction>`

<!-- ❌ 效果较差 -->
`<instruction>`优化这个数据库查询`</instruction>`
<context>系统处理10K TPS</context>

3. 使用分隔符来分隔上下文：

<context>
###
你正在分析高频交易平台的代码。
要求：亚毫秒级延迟，零数据丢失。
###
</context>

组件4：约束

定义：关于不要做什么（负向提示）和必须做什么的规则。

重要性：约束条件：

防止不想要的建议或解决方案
强制执行技术或业务要求
确保输出符合特定格式或限制
通过限制响应空间来减少幻觉

约束类型：

1. 负向约束（不要做的事）：

`<constraints>`
- 不要建议架构更改
- 不要推荐Spring生态系统之外的外部库
- 不要超过200行代码
- 不要包含TODO注释或占位符代码
- 不要修改现有的数据库模式
`</constraints>`

2. 正向约束（必须做的事）：

<requirements>
- 必须使用Java 17+特性（records、模式匹配、sealed classes）
- 必须包含全面的错误处理
- 必须提供>80%覆盖率的单元测试
- 必须遵循Spring Boot约定
- 必须处理边缘情况（null输入、空集合等）
</requirements>

3. 格式约束（如何输出）：

<output_constraints>
- 最多3个段落
- 每个段落不超过50个单词
- 使用简单的语言（8年级阅读水平）
- 不要使用技术术语
- 包含一个具体的例子
</output_constraints>

4. 质量约束：

<quality_requirements>
- 准确性：必须为事实声明引用来源
- 完整性：解决问题的所有方面
- 可操作性：提供具体、可实施的建议
- 相关性：专注于陈述的问题
</quality_requirements>

最佳实践：

1. 对硬性要求使用"MUST"：

<requirements>
解决方案必须：
- 安全地处理并发请求
- 在95百分位内500ms内返回
- 使用不超过100MB内存
</requirements>

2. 对偏好使用"SHOULD"：

<preferences>
方案应该：
- 优先考虑可读性而非微优化
- 在适用的情况下遵循Spring Boot约定
- 为复杂逻辑包含注释
</preferences>

3. 明确具体的约束条件：

<!-- ✅ 具体 -->
`<constraints>`
回应必须在100个单词以内
必须包含恰好3个要点
必须只使用简单句子（每句一个子句）
`</constraints>`

<!-- ❌ 模糊 -->
`<constraints>`
保持简洁和简单
`</constraints>`

组件5：输出格式

定义：响应应该如何结构的规范。

重要性：输出格式规范：

使响应可被下游系统解析
确保多次调用的一致性
支持自动处理
减少后处理需求

常见格式：

1. JSON（用于API集成）：

<output_format>
只返回此确切格式的有效JSON：
{
  "summary": "string（最多200字符）",
  "issues": [
    {
      "severity": "critical|high|medium|low",
      "description": "string",
      "location": "string",
      "fix": "string"
    }
  ],
  "recommendations": ["string"]
}

不要使用markdown格式。不要使用代码块。只返回原始JSON。
</output_format>

2. Markdown（用于文档）：

<output_format>
## 摘要
[一段摘要]

## 主要发现
- 要点1
- 要点2
- 要点3

## 建议
1. 第一个建议
2. 第二个建议
3. 第三个建议

## 代码示例
```java
[代码在这里]
```
</output_format>

3. 表格（用于比较数据）：

<output_format>
以markdown表格返回结果，包含以下列：
| 方法 | 优点 | 缺点 | 使用场景 |
|------|------|------|----------|
| ...  | ...  | ...  | ...      |
</output_format>

4. XML（用于结构化通信）：

<output_format>
<analysis>
  <summary>[内容]</summary>
  <findings>
    <finding id="1">
      <issue>[描述]</issue>
      <severity>[级别]</severity>
      <recommendation>[操作建议]</recommendation>
    </finding>
  </findings>
</analysis>
</output_format>

最佳实践：

1. 明确格式要求：

<!-- ✅ 清晰且可强制执行 -->
<output_format>
只返回JSON。不要使用markdown代码块。不要使用解释性文本。
响应必须以{开头，以}结尾。
</output_format>

<!-- ❌ 模糊 -->
<output_format>
以JSON格式给我结果
</output_format>

2. 为复杂格式提供模式：

<output_format>
JSON Schema：
{
  "type": "object",
  "required": ["name", "price", "category"],
  "properties": {
    "name": {"type": "string", "minLength": 1},
    "price": {"type": "number", "minimum": 0},
    "category": {
      "type": "string",
      "enum": ["electronics", "clothing", "food", "other"]
    },
    "features": {
      "type": "array",
      "items": {"type": "string"}
    }
  }
}
</output_format>

3. 使用示例进行澄清：

<output_format>
按此格式返回结果：

示例：
{
  "status": "success",
  "confidence": 0.95,
  "classification": "electronics",
  "reasoning": "产品提到了技术规格"
}

你的回应应该遵循此确切结构。
</output_format>

经过验证的提示词框架

已经出现了几个作为结构化提示词最佳实践的框架。每个框架服务于不同的用例。

框架1：CO-STAR

由新加坡GovTech开发，CO-STAR赢得了2023年新加坡提示词工程竞赛。

组件：

Context（上下文）：背景信息
Objective（目标）：要实现什么
Style（风格）：期望的沟通风格
Tone（语气）：回应的情感语气
Audience（受众）：谁会接收输出
Response（回应）：输出格式

示例：

<context>
我正在为CTO级别的高管准备关于在支付处理平台中采用Spring AI的技术演示。
</context>

<objective>
在5分钟的演讲时间内解释业务价值和技术方法，重点关注ROI和风险缓解。
</objective>

<style>
执行摘要，可按需提供技术深度。
使用业务指标（成本、速度、可靠性）而非实现细节。
</style>

<tone>
对挑战保持自信但现实。
避免炒作语言；透明地承认权衡。
</tone>

<audience>
理解软件架构但需要业务理由的技术决策者。
假设他们了解Spring Boot但不具体了解Spring AI。
</audience>

<response_format>
返回结构化大纲：
1. 执行摘要（最多3个要点）
2. 业务价值（附带指标）
3. 技术方法（高层次）
4. 风险缓解（3个主要风险+缓解措施）
5. 下一步（3个可操作项目）

总计不超过500个单词。
</response_format>

最适合：

业务沟通
执行摘要
营销文案
面向用户的内容

框架2：RTF（角色-任务-格式）

一个受欢迎的用于快速、直接提示词的最小化框架。

组件：

Role（角色）：模型应该扮演的角色
Task（任务）：需要做什么
Format（格式）：如何呈现输出

示例：

<role>
专精于Kubernetes和AWS基础设施的资深DevOps工程师。
</role>

<task>
为使用Spring AI的Spring Boot应用程序设计部署策略。
包括CI/CD流水线、监控设置和灾难恢复程序。
</task>

<format>
提供：
1. 架构图（文字描述）
2. 分步实施清单
3. 示例部署YAML文件
4. 监控配置片段
</format>

最适合：

技术任务
代码生成
问题解决
快速原型设计

框架3：CRISPE

一个需要多个维度的细微提示词的详细框架。

组件：

Capacity/Role（能力/角色）：专业知识和角色定位
Request/Task（请求/任务）：核心指令
Instructions（指令）：特定步骤或约束
Style（风格）：沟通方法
Personality（个性）：性格特征
Example（示例）：样本输入/输出

示例：

<capacity>
你是一位有15年大气物理学研究经验的气候科学家。
你专长于向普通受众传播复杂科学。
</capacity>

<request>
解释温室效应及其与气候变化的关系。
</request>

<instructions>
- 使用类比使概念易于理解
- 避免科学术语
- 包含3个具体的温室气体例子
- 解决常见误解
- 以个人可以采取的行动步骤结束
</instructions>

<style>
教育性但对话式。使用清晰、简单的语言。
将复杂的思想分解成易于消化的块。
</style>

<personality>
平易近人且鼓舞人心。激发行动而不引起焦虑或绝望。
</personality>

<example>
输入："什么是温室效应？"

输出：
"把地球想象成一个温室。阳光透过玻璃（大气层）照射进来，
温暖植物，而玻璃阻止了一些热量逃逸。像CO2这样的温室气体
就像那块玻璃——它们让阳光进入但困住热量，使地球变暖..."
</example>

最适合：

教育内容
创意写作
品牌传播
客户互动

框架4：RICE-FACT

一个涵盖所有基本要素的全面框架。

组件：

Role（角色）：身份和专业性
Instruction（指令）：核心任务定义
Context（上下文）：必要的背景
Examples（示例）：样本输入/输出
Format（格式）：输出结构
Action（行动）：用户将如何使用结果
Constraints（约束）：限制和要求
Tone（语气）：沟通风格

示例：

<role>
你是一位专精于Java安全最佳实践的代码审查员。
</role>

`<instruction>`
审查以下Spring Boot控制器代码的安全漏洞，
并提供具体的修复建议。
`</instruction>

<context>
这是一个处理支付交易的电子商务应用程序。
需要PCI DSS合规。代码库使用Spring Security 6。
</context>

<examples>
好的审查：
"第45行：SQL注入风险。使用参数化查询：
```java
@Query(\"SELECT u FROM User u WHERE u.email = :email\")
```

坏的审查：
"这段代码有安全问题。修复它们。"
</examples>

<format>
以markdown格式返回：
## 发现的漏洞
[严重性] 位置：描述 + 修复

## 最佳实践违规
[问题编号] 描述 + 建议

## 积极发现
[做得好的地方]
</format>

<action>
开发团队将使用你的审查来：
1. 按严重程度优先修复
2. 立即更新代码
3. 将这些模式添加到安全检查清单中
</action>

`<constraints>`
- 不要建议架构更改
- 只专注于安全性（不是性能或风格）
- 为所有修复提供Java代码示例
- 仅限于严重和高严重性问题
`</constraints>

<tone>
建设性和教育性的。解释为什么问题重要，
而不只是指出它们是错误的。
</tone>

最适合：

代码审查
复杂的多维任务
团队工作流
质量保证

框架5：CREATE

一个针对生成任务优化的较新框架。

组件：

Context（上下文）：情况和背景
Role（角色）：角色和专业性
Examples（示例）：参考样本
Actions/Tasks（行动/任务）：要采取的特定步骤
Target（目标）：成功标准
Evolve（演进）：改进反馈循环

示例：

<context>
我们正在为SaaS产品构建客户支持聊天机器人。
用户主要是非技术商业用户。
</context>

<role>
你是一位客户支持专员，专长于简单解释技术概念。
</role>

<examples>
好的回应：
"我理解您在连接方面遇到问题。让我们试试这个：
首先，通过打开任何网站检查您的互联网连接。
如果有效，请尝试清除浏览器缓存..."
</examples>

<actions>
1. 同情地确认用户的问题
2. 如需要，询问1-2个澄清问题
3. 提供分步故障排除
4. 如果问题未解决，提供升级路径
</actions>

<target>
- 80%的问题无需人工升级即可解决
- 平均对话时间少于5分钟
- 客户满意度>4.5/5
</target>

<evolve>
每次回应后进行自我评估：
- 解决方案是否清晰？
- 步骤是否可操作？
- 语气是否合适？
为下一次迭代提出改进建议。
</evolve>

最适合：

内容生成
聊天机器人开发
创意任务
迭代改进

整合起来：完整示例

让我们一步步构建完整的提示词，展示每个组件如何做出贡献。

任务：审查代码的安全问题

第1步：添加角色定位

<persona>
你是一位拥有12年应用安全经验的资深安全工程师。
你专精于Java和Spring Boot。
你曾为财富500强公司进行过安全审查，并持有CISSP和CEH认证。
</persona>

第2步：添加上下文

<context>
这是一个支付处理服务的REST API控制器。
应用程序处理约10,000个事务/小时。
PCI DSS合规是强制性的。
当前Spring Boot版本：3.2.0
Spring Security版本：6.2.0
</context>

第3步：添加指令

`<instruction>`
审查提供的控制器代码的安全漏洞。

对每个发现的漏洞：
1. 识别行号
2. 分类严重程度（CRITICAL/HIGH/MEDIUM/LOW）
3. 解释利用场景
4. 提供特定的修复代码
5. 建议未来开发的预防策略

还要识别：
- 正在遵循的任何安全最佳实践
- 超过关键问题的潜在改进
`</instruction>`

第4步：添加约束

`<constraints>`
必须：
- 只专注于安全性（不是性能、风格或架构）
- 为所有修复提供可执行代码示例
- 按严重程度优先排序发现
- 考虑PCI DSS要求

不要：
- 建议架构更改（保持范围在此控制器内）
- 推荐关键之外的第三方安全库
- 提出现有表的架构更改
`</constraints>`

第5步：添加输出格式

<output_format>
## 执行摘要
[总体安全态势：1-2句话]

## 严重漏洞
### [漏洞名称]
- **位置**：第[X]行
- **严重性**：CRITICAL
- **描述**：[它是什么]
- **利用场景**：[如何被滥用]
- **修复**：
```java
[修复后的代码]
```
- **预防**：[如何在将来避免]

## 高严重性问题
[与上述相同格式]

## 中等问题和低严重性问题
[带有行号和快速修复的简要列表]

## 积极发现
[正确遵循的安全最佳实践]

## 建议
[优先排序的一般性安全改进]
</output_format>

完整提示词：

<persona>
你是一位拥有12年应用安全经验的资深安全工程师。
你专精于Java和Spring Boot。
你曾为财富500强公司进行过安全审查，并持有CISSP和CEH认证。
</persona>

<context>
这是一个支付处理服务的REST API控制器。
应用程序处理约10,000个事务/小时。
PCI DSS合规是强制性的。
当前Spring Boot版本：3.2.0
Spring Security版本：6.2.0
</context>

`<instruction>`
审查提供的控制器代码的安全漏洞。

对每个发现的漏洞：
1. 识别行号
2. 分类严重程度（CRITICAL/HIGH/MEDIUM/LOW）
3. 解释利用场景
4. 提供特定的修复代码
5. 建议未来开发的预防策略

还要识别：
- 正在遵循的任何安全最佳实践
- 超过关键问题的潜在改进
`</instruction>

`<constraints>`
必须：
- 只专注于安全性（不是性能、风格或架构）
- 为所有修复提供可执行代码示例
- 按严重程度优先排序发现
- 考虑PCI DSS要求

不要：
- 建议架构更改（保持范围在此控制器内）
- 推荐关键之外的第三方安全库
- 提出现有表的架构更改
`</constraints>

<output_format>
## 执行摘要
[总体安全态势：1-2句话]

## 严重漏洞
### [漏洞名称]
- **位置**：第[X]行
- **严重性**：CRITICAL
- **描述**：[它是什么]
- **利用场景**：[如何被滥用]
- **修复**：
```java
[修复后的代码]
```
- **预防**：[如何在将来避免]

## 高严重性问题
[与上述相同格式]

## 中等问题和低严重性问题
[带有行号和快速修复的简要列表]

## 积极发现
[正确遵循的安全最佳实践]

## 建议
[优先排序的一般性安全改进]
</output_format>

---
**要审查的代码**：
```java
[在此粘贴控制器代码]
```

组件交互

五个组件不是孤立存在的——它们相互作用并相互强化。

交互矩阵

交互	效果	示例
角色定位 + 上下文	上下文帮助角色定位应用相关知识	"资深架构师" + "高流量电商平台" → 专注于可扩展性模式
上下文 + 约束	上下文决定哪些约束重要	"需要PCI DSS" → "必须加密PII"
指令 + 格式	格式影响如何遵循指令	"分析安全性" + "JSON输出" → 结构化漏洞报告
约束 + 格式	格式约束必须与输出格式对齐	"不超过100个单词" + "JSON" → 可能冲突，需要协调
角色定位 + 格式	角色定位影响如何解释格式	"技术专家" + "执行摘要" → 与"通才"不同深度

顺序很重要

推荐的顺序：

角色定位（设定心态）
上下文（提供背景）
指令（定义任务）
约束（设置边界）
格式（指定输出）

为什么这个顺序有效：

角色定位在解释上下文之前建立视角
在分配任务之前理解上下文
在应用约束之前任务清晰
在指定格式之前所有参数已知

特定场景的替代顺序：

场景	更好的顺序	原因
简单查询	指令 → 格式	快速回答，最少设置
教育内容	上下文 → 角色定位 → 指令 → 格式	情况优先，然后是专业知识
问题解决	指令 → 上下文 → 约束	任务优先，然后是背景

常见错误

错误1：过度提示

问题：太多细节让模型不知所措并增加token成本。

<!-- ❌ 过度详细 -->
<persona>
你是一位47岁的名叫Sarah的Java架构师，1998年以3.8 GPA毕业于斯坦福，
曾在Google、Amazon和两家初创公司工作，住在德克萨斯州奥斯汀，
有两个孩子，喜欢攀岩，更喜欢IntelliJ而非Eclipse，
使用Cherry MX Brown开关的机械键盘，并且从Spring 1.2版本就开始使用...
</persona>

<!-- ✅ 专注 -->
<persona>
你是一位拥有15年企业经验的资深Java架构师。
你专精于Spring Boot和云原生微服务。
你优先考虑实用主义和生产可靠性。
</persona>

修复：删除不相关的细节。专注于影响任务的内容。

错误2：冲突的指令

问题：矛盾的要求让模型困惑。

<!-- ❌ 冲突 -->
`<constraints>`
- 保持回应在100个单词以内
- 提供带有多个例子的全面分析
- 包含详细的代码解释
`</constraints>

<!-- ✅ 一致 -->
`<constraints>`
- 保持回应在300个单词以内
- 提供2-3个关键例子，附带简要解释
- 只关注最关键的问题
`</constraints>`

修复：确保所有约束可以同时满足。

错误3：缺少示例

问题：没有具体示例的抽象指令导致不一致的结果。

<!-- ❌ 抽象 -->
<instruction>
审查代码并提供反馈。
</instruction>

<!-- ✅ 具体 -->
<instruction>
审查代码并以以下格式提供反馈：

示例反馈：
"第23行：空指针风险。添加空检查：

    if (user != null) {
        user.process();
    }

优先级：高"
</instruction>

修复：为复杂任务包含示例输入和输出。

错误4：忽略模型能力

问题：要求模型无法做的事情。

<!-- ❌ 不可能 -->
`<instruction>`
执行这段代码并告诉我运行时性能。
`</instruction>

<!-- ✅ 现实 -->
`<instruction>`
分析这段代码的潜在性能问题，并基于使用的算法
建议优化方案。
`</instruction>

修复：保持在模型能力范围内（分析，而非执行）。

错误5：任务错误的框架

问题：为简单任务使用复杂框架（浪费token）或为复杂任务使用简单框架（指导不足）。

任务复杂度	最佳框架	原因
非常简单（事实、查找）	不需要	直接问题就可以了
简单（单任务）	RTF	快速有效
中等（多维）	CO-STAR	平衡结构
复杂（多个要求）	CRISPE 或 RICE-FACT	全面覆盖

快速参考

组件检查清单

发送提示词前，验证：

角色定位：专业知识水平是否适合任务？
上下文：是否提供了所有必要的背景？
指令：任务是否清晰具体？
约束：所有要求是否明确？
格式：输出结构是否指定？
一致性：所有组件是否一致？
完整性：是否遗漏了什么？
简洁性：是否删除了不必要的细节？

框架选择指南

开始：你的任务是什么？

├─ 简单事实查询？
│  └─ 不需要框架
│
├─ 代码生成或技术任务？
│  └─ RTF（角色-任务-格式）
│
├─ 业务沟通？
│  └─ CO-STAR
│
├─ 创意或教育内容？
│  └─ CRISPE
│
├─ 复杂多维审查？
│  └─ RICE-FACT
│
└─ 生成/迭代任务？
   └─ CREATE

模板库

用于技术任务：

<persona>资深[语言]开发人员，[专长]</persona>
<context>[项目类型、规模、要求]</context>
`<instruction>`[带有验收标准的特定任务]`</instruction>`
`<constraints>`
必须：[技术要求]
不要：[排除项]
`</constraints>`
<output_format>
[代码或文档格式]
</output_format>

用于分析任务：

<persona>[领域]专家，[经验水平]</persona>
<context>[主题、目的、利益相关者]</context>
`<instruction>`
1. [分析步骤1]
2. [分析步骤2]
3. [分析步骤3]
`</instruction>`
<output_format>
## 发现
[结构化分解]

## 建议
[优先列表]
</output_format>

用于内容生成：

<persona>[角色]，[语调/风格]专长</persona>
<context>[主题、受众、目的]</context>
`<instruction>`[内容要求]`</instruction>`
`<constraints>`
- 长度：[单词/字符限制]
- 风格：[语调/声音]
- 必须：[包含项]
- 不要：[排除项]
`</constraints>`
<output_format>[内容结构]</output_format>

总结

要点：

五个组件：角色定位、指令、上下文、约束、格式
结构制胜：结构良好的提示词比巧妙的提示词表现好3-5倍
框架选择：根据任务复杂度选择框架
一致性很重要：确保所有组件一致
迭代：从简单开始，根据需要添加组件

下一章：现在您理解了提示词解剖，让我们探索核心推理模式，学习链式思维、ReAct和自洽性等技术，这些技术解锁强大的推理能力。

上一篇：1. 介绍 ← 下一篇：2.2 核心推理模式 →

2 提示词解剖

引言

五个核心组件

组件1：角色定位

组件2：指令

组件3：上下文

组件4：约束

组件5：输出格式

经过验证的提示词框架

框架1：CO-STAR

框架2：RTF（角色-任务-格式）

框架3：CRISPE

框架4：RICE-FACT

框架5：CREATE

整合起来：完整示例

任务：审查代码的安全问题

组件交互

交互矩阵

顺序很重要

常见错误

错误1：过度提示

错误2：冲突的指令

错误3：缺少示例

错误4：忽略模型能力

错误5：任务错误的框架

快速参考

组件检查清单

框架选择指南

模板库

总结

AiDIY 助手

AiDIY 助手

引言​

五个核心组件​

组件1：角色定位​

组件2：指令​

组件3：上下文​

组件4：约束​

组件5：输出格式​

经过验证的提示词框架​

框架1：CO-STAR​

框架2：RTF（角色-任务-格式）​

框架3：CRISPE​

框架4：RICE-FACT​

框架5：CREATE​

整合起来：完整示例​

任务：审查代码的安全问题​

组件交互​

交互矩阵​

顺序很重要​

常见错误​

错误1：过度提示​

错误2：冲突的指令​

错误3：缺少示例​

错误4：忽略模型能力​

错误5：任务错误的框架​

快速参考​

组件检查清单​

框架选择指南​

模板库​

总结​

引言

五个核心组件

组件1：角色定位

组件2：指令

组件3：上下文

组件4：约束

组件5：输出格式

经过验证的提示词框架

框架1：CO-STAR

框架2：RTF（角色-任务-格式）

框架3：CRISPE

框架4：RICE-FACT

框架5：CREATE

整合起来：完整示例

任务：审查代码的安全问题

组件交互

交互矩阵

顺序很重要

常见错误

错误1：过度提示

错误2：冲突的指令

错误3：缺少示例

错误4：忽略模型能力

错误5：任务错误的框架

快速参考

组件检查清单

框架选择指南

模板库

总结