Add prompt-optimizer skill with 57 prompt frameworks
This commit is contained in:
@@ -0,0 +1,168 @@
|
||||
# TRACE Framework
|
||||
|
||||
## 网址
|
||||
https://juuzt.ai/knowledge-base/prompt-frameworks/the-trace-framework/
|
||||
|
||||
## 应用场景
|
||||
- 角色扮演提示设计
|
||||
- AI助手配置
|
||||
- 对话系统开发
|
||||
- 虚拟角色创建
|
||||
- 内容生成指导
|
||||
- 交互体验设计
|
||||
|
||||
## 概述
|
||||
TRACE框架(Task, Role, Audience, Create, Evaluate)是一种综合性的AI提示词工程方法,涵盖了从任务定义到输出评估的完整流程。该框架确保AI输出既符合任务要求,又适合目标受众,并有明确的评估标准。
|
||||
|
||||
## 框架构成
|
||||
|
||||
| 组成部分 | 英文 | 说明 |
|
||||
|---------|------|------|
|
||||
| 任务 | Task | 定义需要完成的具体任务 |
|
||||
| 角色 | Role | 指定AI扮演的角色 |
|
||||
| 受众 | Audience | 明确目标受众群体 |
|
||||
| 创建 | Create | 指导如何创建输出 |
|
||||
| 评估 | Evaluate | 设定评估成功的标准 |
|
||||
|
||||
## 详细说明
|
||||
|
||||
### Task(任务)
|
||||
清晰定义任务:
|
||||
- 具体的任务描述
|
||||
- 任务的范围和边界
|
||||
- 预期的输出类型
|
||||
- 关键的约束条件
|
||||
|
||||
### Role(角色)
|
||||
指定AI的角色:
|
||||
- 专业身份
|
||||
- 专业水平
|
||||
- 个性特征
|
||||
- 知识范围
|
||||
|
||||
### Audience(受众)
|
||||
明确目标受众:
|
||||
- 受众特征
|
||||
- 知识水平
|
||||
- 需求和期望
|
||||
- 阅读/使用场景
|
||||
|
||||
### Create(创建)
|
||||
指导创建过程:
|
||||
- 格式要求
|
||||
- 风格指南
|
||||
- 必需包含的元素
|
||||
- 禁止的内容
|
||||
|
||||
### Evaluate(评估)
|
||||
设定成功标准:
|
||||
- 质量衡量标准
|
||||
- 完整性检查
|
||||
- 准确性验证
|
||||
- 可用性评估
|
||||
|
||||
## 优点
|
||||
- **全面性**: 覆盖提示词工程的关键方面
|
||||
- **受众意识**: 明确考虑目标受众
|
||||
- **质量保证**: 内置评估标准
|
||||
- **可复制**: 便于创建一致的高质量输出
|
||||
|
||||
## 缺点
|
||||
- **复杂度较高**: 需要更多时间设置
|
||||
- **可能过度详细**: 简单任务可能不需要如此完整
|
||||
- **需要经验**: 有效评估需要对输出质量有了解
|
||||
|
||||
## 最佳实践
|
||||
|
||||
### 示例1:技术博客文章
|
||||
```
|
||||
Task(任务):
|
||||
撰写一篇关于云原生架构的入门博客文章,
|
||||
解释核心概念和实际应用场景。
|
||||
|
||||
Role(角色):
|
||||
作为一名有10年经验的云架构师,
|
||||
曾帮助多家企业完成云迁移,
|
||||
擅长用简单语言解释复杂概念。
|
||||
|
||||
Audience(受众):
|
||||
目标读者是有1-3年经验的后端开发者,
|
||||
了解基本的服务器和部署概念,
|
||||
但对云原生技术接触有限,
|
||||
希望了解是否值得深入学习。
|
||||
|
||||
Create(创建):
|
||||
- 长度:1500-2000字
|
||||
- 结构:引言、核心概念、实际应用、入门建议、总结
|
||||
- 风格:专业但不枯燥,适当使用类比
|
||||
- 包含:至少2个实际案例或代码示例
|
||||
- 避免:过多专业术语,假设读者已了解的内容
|
||||
|
||||
Evaluate(评估):
|
||||
- 概念解释清楚,无歧义
|
||||
- 读者能够解释什么是云原生
|
||||
- 提供了清晰的学习路径
|
||||
- 语言流畅,无技术错误
|
||||
```
|
||||
|
||||
### 示例2:产品说明视频脚本
|
||||
```
|
||||
Task(任务):
|
||||
为新推出的项目管理软件编写2分钟的产品介绍视频脚本。
|
||||
|
||||
Role(角色):
|
||||
作为一名资深产品营销专家,
|
||||
了解如何用故事吸引观众,
|
||||
擅长突出产品价值而非功能列表。
|
||||
|
||||
Audience(受众):
|
||||
目标观众是中小企业的管理者,
|
||||
他们通常很忙,没有时间学习复杂工具,
|
||||
正在寻找提高团队效率的解决方案,
|
||||
可能已经使用过其他项目管理工具但不满意。
|
||||
|
||||
Create(创建):
|
||||
- 长度:精确2分钟(约300字)
|
||||
- 结构:痛点引入、解决方案、核心价值、行动号召
|
||||
- 风格:友好、自信、专业
|
||||
- 包含:1个具体使用场景、3个核心价值点
|
||||
- 避免:技术术语、功能堆砌、夸大承诺
|
||||
|
||||
Evaluate(评估):
|
||||
- 前10秒能抓住注意力
|
||||
- 价值主张清晰传达
|
||||
- 与竞品有明显区分
|
||||
- 行动号召有吸引力
|
||||
- 整体节奏适合视频呈现
|
||||
```
|
||||
|
||||
### 示例3:客户服务脚本
|
||||
```
|
||||
Task(任务):
|
||||
创建处理客户退款请求的客服对话脚本。
|
||||
|
||||
Role(角色):
|
||||
作为一名专业的客服代表,
|
||||
既理解公司政策又关注客户体验,
|
||||
擅长在坚持原则的同时保持客户满意。
|
||||
|
||||
Audience(受众):
|
||||
客户可能已经感到沮丧,
|
||||
期望问题能够快速解决,
|
||||
需要感受到被尊重和理解,
|
||||
可能不熟悉退款流程。
|
||||
|
||||
Create(创建):
|
||||
- 包含:问候、确认问题、解释流程、处理、结束
|
||||
- 提供:多种情况的处理分支
|
||||
- 语气:同理心、专业、解决导向
|
||||
- 包含:安抚话术和升级触发条件
|
||||
- 避免:推诿、冷漠、机械感
|
||||
|
||||
Evaluate(评估):
|
||||
- 客户问题得到解决
|
||||
- 流程解释清晰
|
||||
- 保持了客户关系
|
||||
- 遵守公司退款政策
|
||||
- 交互时间控制在5分钟内
|
||||
```
|
||||
Reference in New Issue
Block a user