目录
1. 提示词工程基础
1.1 什么是提示词工程?
定义: 提示词工程(Prompt Engineering)是设计、优化与大语言模型(LLM)交互的输入文本的艺术与科学,以获得期望的输出结果。
核心目标:
- 🎯 准确性: 输出符合预期
- 📊 一致性: 多次运行结果稳定
- 💡 创造性: 激发模型潜力
- ⚡ 效率性: 减少迭代次数
1.2 为什么提示词重要?
影响因素分析:
输出质量 = f(模型能力, 提示词质量, 上下文)
| 提示词质量 | 输出质量 | 实际案例 |
|---|---|---|
| 低 | 模糊、不准确、偏离主题 | "写一篇文章" |
| 中 | 基本可用但需修改 | "写一篇关于AI的文章" |
| 高 | 精准、专业、开箱即用 | "写一篇2000字的技术博客,面向初学者,介绍Transformer架构,包含代码示例" |
关键洞察:
同样的模型,不同的提示词可能产生10倍甚至100倍的质量差异!
2. 核心原则与框架
2.1 提示词设计六大原则
原则1: 清晰性(Clarity)
定义: 明确表达意图,避免歧义
对比示例:
❌ 差:
帮我写代码
✅ 好:
用Python编写一个函数,输入两个日期字符串(格式:YYYY-MM-DD),
返回两个日期之间的天数差。包含错误处理和单元测试。
实现技巧:
- 使用具体的动词(编写、分析、总结 vs 做)
- 指定格式和长度
- 明确约束条件
原则2: 具体性(Specificity)
定义: 提供详细的背景和要求
对比示例:
❌ 差:
解释机器学习
✅ 好:
面向没有编程背景的产品经理,用通俗语言解释机器学习的核心概念,
包含3个实际业务场景的应用案例(推荐系统、欺诈检测、客户细分),
每个案例300字,总计约1000字。
具体化维度:
- 目标受众(专家 vs 初学者)
- 输出格式(文章、代码、表格、JSON)
- 长度限制
- 风格要求(正式、幽默、技术性)
原则3: 结构性(Structure)
定义: 使用清晰的结构组织提示词
CRISPE框架:
C - Capacity & Role (角色定位)
R - Insight (背景信息)
I - Statement (任务说明)
S - Personality (个性风格)
P - Experiment (实验要求)
E - Examples (示例)
示例:
# 角色(C)
你是一位资深的Python后端工程师,擅长性能优化和架构设计。
# 背景(R)
我们的API接口响应时间从平均200ms增加到2000ms,数据库查询是主要瓶颈。
# 任务(I)
分析以下代码,找出性能问题,并提供优化方案。
# 风格(S)
请用专业但易懂的语言解释,包含具体的代码示例。
# 要求(P)
1. 至少提供3种优化方案
2. 对比优化前后的性能指标
3. 说明实施难度和风险
# 示例(E)
期望输出格式:
## 问题分析
[具体问题]
## 优化方案
### 方案1: [名称]
- 实现: [代码]
- 性能提升: [数据]
- 风险: [说明]
原则4: 上下文性(Context)
定义: 提供充分的背景信息
上下文类型:
- 领域上下文
我们是一家医疗SaaS公司,服务于三甲医院...
- 历史上下文
我们之前尝试过Redis缓存但效果不佳...
- 约束上下文
必须兼容Python 3.8+,不能引入新的依赖...
最佳实践:
## 背景信息
- 项目: 电商推荐系统
- 技术栈: Python + FastAPI + PostgreSQL + Redis
- 规模: 日活100万,商品数10万
- 当前问题: 个性化推荐召回率不足30%
- 已尝试方案: 协同过滤(效果一般)
- 约束: 响应时间<100ms,成本控制在现有基础上+20%以内
原则5: 迭代性(Iteration)
定义: 通过持续反馈优化提示词
迭代流程:
初始提示词 → 测试输出 → 分析偏差 → 调整提示词 → 再测试
↑ ↓
└──────────────── 循环直到满意 ─────────────────┘
迭代维度:
- 调整细节程度
- 增删约束条件
- 修改输出格式
- 添加反例(不要做什么)
示例:
迭代1:
写一个排序函数
迭代2(增加语言):
用Python写一个排序函数
迭代3(增加算法):
用Python实现快速排序算法
迭代4(增加要求):
用Python实现快速排序算法,包含:
1. 类型注解
2. 单元测试
3. 时间复杂度分析注释
原则6: 约束性(Constraints)
定义: 明确限制条件和边界
约束类型:
- 格式约束
输出必须是有效的JSON,结构如下:
{
"title": "字符串",
"content": "字符串",
"tags": ["数组"]
}
- 长度约束
总字数控制在800-1000字之间
代码行数不超过50行
- 风格约束
使用学术论文的正式语气
代码遵循PEP8规范
避免使用行话和缩写
- 内容约束
不要包含:
- 个人观点或推测
- 未经验证的数据
- 商业推广内容
实战示例:
## 约束条件(必须严格遵守)
1. 输出格式: Markdown
2. 字数: 1500±100字
3. 代码: Python 3.10+,带类型注解
4. 禁止: 使用第三方库(仅标准库)
5. 必须: 包含错误处理和日志记录
6. 风格: 遵循Google Python风格指南
7. 文档: 每个函数必须有docstring
2.2 提示词设计框架对比
| 框架 | 适用场景 | 核心要素 |
|---|---|---|
| CRISPE | 复杂任务 | 角色+背景+任务+风格+要求+示例 |
| ROSES | 创意写作 | 角色+目标+场景+期望+范围 |
| APE | API调用 | 动作+参数+期望输出 |
| RACEF | 数据分析 | 角色+动作+上下文+示例+格式 |
| Chain-of-Thought | 推理任务 | 问题+思考步骤+答案 |
推荐使用场景:
代码生成 → CRISPE
内容创作 → ROSES
数据分析 → RACEF
逻辑推理 → Chain-of-Thought
简单查询 → 直接描述
3. 提示词编写完整流程
步骤1: 明确目标
核心问题:
- ✅ 我想要什么结果?
- ✅ 谁会使用这个输出?
- ✅ 输出用于什么场景?
- ✅ 成功的标准是什么?
目标模板:
## 任务目标
- **主要目标:** [一句话描述]
- **次要目标:** [补充说明]
- **成功指标:** [如何判断成功]
- **使用场景:** [实际应用]
示例:
## 任务目标
- **主要目标:** 生成一个Python REST API性能测试脚本
- **次要目标:** 支持并发测试和结果可视化
- **成功指标:**
- 能测试至少3种HTTP方法(GET/POST/PUT)
- 输出清晰的性能报告
- 代码可直接运行无需修改
- **使用场景:** 在发布前对新API进行压力测试
步骤2: 收集上下文
上下文清单:
## 上下文收集表
### 技术上下文
- [ ] 编程语言/框架
- [ ] 版本要求
- [ ] 依赖限制
- [ ] 环境约束(操作系统、硬件等)
### 业务上下文
- [ ] 行业领域
- [ ] 用户画像
- [ ] 业务流程
- [ ] 数据规模
### 历史上下文
- [ ] 已尝试的方案
- [ ] 已知的问题
- [ ] 可借鉴的经验
### 约束上下文
- [ ] 时间限制
- [ ] 成本限制
- [ ] 合规要求
- [ ] 性能要求
步骤3: 选择框架
决策树:
是否需要特定角色?
├─ 是 → 考虑CRISPE
└─ 否 → ↓
是否需要逻辑推理?
├─ 是 → 考虑Chain-of-Thought
└─ 否 → ↓
是否是创意任务?
├─ 是 → 考虑ROSES
└─ 否 → 直接描述法
步骤4: 编写初稿
模板(CRISPE框架):
# [任务标题]
## 角色定位
你是一位[职业/专家类型],擅长[核心能力1]和[核心能力2]。
## 背景信息
[提供充分的上下文,包括:]
- 项目背景
- 当前问题
- 已有尝试
- 技术栈
## 任务说明
请帮我[核心任务],具体要求:
1. [要求1]
2. [要求2]
3. [要求3]
## 输出格式
期望输出应包含:
- [部分1]: [说明]
- [部分2]: [说明]
- [部分3]: [说明]
## 约束条件
必须遵守:
- [约束1]
- [约束2]
不要:
- [禁止事项1]
- [禁止事项2]
## 示例参考
[如果有,提供示例]
步骤5: 测试与验证
测试检查表:
## 提示词质量检查
### 清晰性检查
- [ ] 任务描述无歧义
- [ ] 关键术语已定义
- [ ] 期望输出已明确
### 完整性检查
- [ ] 包含所有必要上下文
- [ ] 约束条件已列出
- [ ] 输出格式已说明
### 可执行性检查
- [ ] AI能理解所有要求
- [ ] 输入信息充分
- [ ] 没有自相矛盾的要求
### 效果检查
- [ ] 输出符合预期
- [ ] 质量达到标准
- [ ] 多次运行结果一致
测试方法:
- 基准测试
使用3-5个测试用例,验证输出质量
- 边界测试
测试极端情况(最长/最短/异常输入)
- 一致性测试
相同提示词运行5次,对比结果
步骤6: 迭代优化
优化策略:
问题 → 解决方案映射:
| 问题类型 | 症状 | 优化方向 |
|---|---|---|
| 输出过于笼统 | 缺乏细节 | 增加具体要求和示例 |
| 偏离主题 | 内容不相关 | 加强任务说明,添加约束 |
| 格式不对 | 结构混乱 | 明确输出模板 |
| 不够专业 | 术语不准确 | 增强角色定位,提供领域术语 |
| 缺乏创意 | 内容平庸 | 减少约束,增加开放性引导 |
迭代日志模板:
## 迭代记录
### 版本1.0
**提示词:** [初始版本]
**问题:** [发现的问题]
**改进方向:** [计划优化点]
### 版本1.1
**改动:** [具体修改]
**效果:** [改进情况]
**下一步:** [后续计划]
4. 高级技巧与模式
4.1 Chain-of-Thought (思维链)
适用场景: 复杂推理、数学问题、多步骤任务
核心思想: 让AI展示思考过程
模板:
请解决以下问题,并详细展示你的思考过程:
[问题描述]
请按以下步骤思考:
1. 理解问题:分析题意和关键信息
2. 拆解问题:划分为子问题
3. 逐步求解:解决每个子问题
4. 综合答案:得出最终结论
5. 验证结果:检查答案合理性
示例:
## 任务:API性能优化
请分析以下问题并给出优化方案,展示完整思考过程:
### 问题描述
用户列表接口响应时间从200ms增加到2000ms,
数据量从1万增长到10万条。
### 请按以下步骤分析:
#### 步骤1:问题定位
- 分析可能的性能瓶颈点
- 列出需要检查的指标
#### 步骤2:数据收集
- 需要收集哪些监控数据?
- 如何定位具体瓶颈?
#### 步骤3:方案设计
- 针对每个瓶颈设计解决方案
- 评估方案的优缺点
#### 步骤4:实施计划
- 确定优先级
- 制定实施步骤
#### 步骤5:效果预估
- 预期性能提升
- 潜在风险评估
4.2 Few-Shot Learning (少样本学习)
适用场景: 特定格式输出、风格模仿、模式识别
核心思想: 通过示例引导输出
模板:
请按照以下示例的格式/风格完成任务:
## 示例1
输入: [示例输入1]
输出: [示例输出1]
## 示例2
输入: [示例输入2]
输出: [示例输出2]
## 示例3
输入: [示例输入3]
输出: [示例输出3]
---
现在请处理:
输入: [实际任务]
输出: [期待AI生成]
实战示例:
## 任务:生成API文档
请按以下示例格式,为新的API接口生成文档:
### 示例1:
```json
{
"endpoint": "GET /api/v1/users",
"description": "获取用户列表",
"parameters": {
"page": {
"type": "integer",
"required": false,
"default": 1,
"description": "页码"
},
"limit": {
"type": "integer",
"required": false,
"default": 20,
"description": "每页数量"
}
},
"response": {
"200": {
"description": "成功",
"schema": {
"users": "array",
"total": "integer"
}
}
},
"example": {
"request": "GET /api/v1/users?page=1&limit=10",
"response": {
"users": [...],
"total": 100
}
}
}
示例2:
[另一个完整示例...]
现在请为以下接口生成文档:
POST /api/v1/orders 功能:创建新订单 参数:user_id, items(商品列表), address
---
### 4.3 Role-Playing (角色扮演)
**适用场景:** 需要特定专业视角、领域知识
**核心思想:** 赋予AI特定角色身份
**角色设定要素:**
```markdown
## 角色设定卡
### 基本信息
- 职业: [具体职位]
- 经验: [年限和领域]
- 专长: [核心技能]
### 知识背景
- 技术栈: [熟悉的技术]
- 行业经验: [了解的行业]
- 认证资质: [相关证书]
### 工作方式
- 分析方法: [如何思考问题]
- 沟通风格: [如何表达]
- 决策标准: [评判依据]
### 价值观
- 优先考虑: [关注重点]
- 规避事项: [避免内容]
示例:
## 角色设定
你是**张伟**,一位资深的Python后端架构师,具有以下背景:
### 专业背景
- 10年Python开发经验
- 曾在BAT担任架构师
- 主导过多个日活千万级系统设计
- 精通微服务、分布式系统、高并发优化
### 技术栈
- 语言: Python, Go
- 框架: Django, FastAPI, Flask
- 数据库: PostgreSQL, MySQL, MongoDB, Redis
- 中间件: Kafka, RabbitMQ, Elasticsearch
- 云平台: AWS, 阿里云
### 工作风格
- 注重系统的可扩展性和可维护性
- 喜欢用数据和指标说话
- 倾向于渐进式优化而非大规模重构
- 强调代码规范和文档完整性
### 沟通方式
- 先理解业务需求,再提供技术方案
- 会指出潜在风险和权衡
- 提供多个方案并说明优缺点
- 使用通俗语言解释技术概念
---
## 任务
现在,作为张伟,请帮我设计一个电商订单系统的后端架构,
要求支持每秒1000单的并发,具有高可用性和水平扩展能力。
请按照你的工作风格,提供详细的架构方案。
4.4 Constraint-Based (基于约束)
适用场景: 需要严格控制输出格式、内容范围
核心思想: 通过明确的"做"和"不做"来引导输出
约束设计模板:
## 严格约束(必须遵守)
### 格式约束
✅ 必须:
- [ ] 使用Markdown格式
- [ ] 包含目录
- [ ] 代码使用语法高亮
❌ 禁止:
- [ ] 使用HTML标签
- [ ] 超过指定字数
- [ ] 包含外部链接
### 内容约束
✅ 必须:
- [ ] 基于事实和数据
- [ ] 包含具体示例
- [ ] 提供可执行的代码
❌ 禁止:
- [ ] 个人观点和推测
- [ ] 未经验证的信息
- [ ] 商业推广内容
### 技术约束
✅ 必须:
- [ ] Python 3.10+
- [ ] 仅使用标准库
- [ ] 包含类型注解
❌ 禁止:
- [ ] 使用已弃用的API
- [ ] 引入外部依赖
- [ ] 忽略异常处理
### 风格约束
✅ 必须:
- [ ] 遵循PEP8
- [ ] 变量命名语义化
- [ ] 函数包含docstring
❌ 禁止:
- [ ] 单字母变量名
- [ ] 魔法数字
- [ ] 过度嵌套(>3层)
4.5 Self-Consistency (自洽性检查)
适用场景: 高精度要求、关键决策
核心思想: 让AI多次生成答案并自我验证
模板:
## 任务: [具体任务]
请按照以下步骤完成:
### 第1步:生成初始答案
根据问题描述,给出你的第一个解决方案。
### 第2步:换个角度思考
从不同的角度重新分析问题,给出第二个解决方案。
### 第3步:对比分析
对比两个方案的优缺点:
- 方案1的优势:
- 方案1的劣势:
- 方案2的优势:
- 方案2的劣势:
### 第4步:自我验证
检查每个方案是否:
- [ ] 满足所有约束条件
- [ ] 逻辑自洽
- [ ] 实现可行
- [ ] 考虑了边界情况
### 第5步:综合结论
基于以上分析,给出最终推荐方案并说明理由。
4.6 Progressive Disclosure (渐进式展开)
适用场景: 复杂任务、多阶段工作
核心思想: 将大任务拆分为多个子任务,逐步完成
模板:
## 复杂任务拆解
我将完成一个复杂任务,请按以下阶段逐步完成:
### 阶段1:需求分析
首先,帮我分析需求,输出:
- [ ] 核心功能列表
- [ ] 技术难点识别
- [ ] 依赖关系梳理
**停止,等待我确认后继续**
### 阶段2:架构设计
基于阶段1的分析,设计系统架构:
- [ ] 模块划分
- [ ] 接口定义
- [ ] 数据流设计
**停止,等待我确认后继续**
### 阶段3:详细设计
为每个模块设计实现细节:
- [ ] 类和函数定义
- [ ] 算法选择
- [ ] 数据结构设计
**停止,等待我确认后继续**
### 阶段4:代码实现
编写完整代码,包含:
- [ ] 核心逻辑
- [ ] 错误处理
- [ ] 单元测试
### 阶段5:优化与文档
- [ ] 性能优化
- [ ] 代码重构
- [ ] 文档完善
5. 最佳实践示例
示例1: 代码生成 - Python API开发
# 任务:开发RESTful API接口
## 角色定位
你是一位资深的Python后端工程师,精通FastAPI框架和异步编程,
拥有5年以上大型Web应用开发经验,注重代码质量和性能优化。
## 背景信息
我正在开发一个任务管理系统的后端API,需要实现任务的增删改查功能。
### 技术栈
- 框架: FastAPI 0.104+
- 数据库: PostgreSQL 15
- ORM: SQLAlchemy 2.0 (异步)
- Python: 3.11+
### 数据模型
```python
class Task:
id: int
title: str
description: str | None
status: str # 'pending', 'in_progress', 'completed'
priority: int # 1-5
created_at: datetime
updated_at: datetime
user_id: int
任务要求
请实现以下API接口:
-
GET /tasks - 获取任务列表
- 支持分页(page, limit)
- 支持筛选(status, priority)
- 支持排序(created_at, priority)
-
GET /tasks/{task_id} - 获取单个任务详情
-
POST /tasks - 创建新任务
-
PUT /tasks/{task_id} - 更新任务
-
DELETE /tasks/{task_id} - 删除任务
代码要求
必须包含
- 完整的路由定义
- Pydantic模型(请求/响应)
- 数据库操作(异步)
- 错误处理和HTTP状态码
- 类型注解(完整)
- API文档注释(自动生成Swagger)
- 输入验证
- 单元测试(至少2个)
代码规范
- 遵循PEP8
- 使用async/await
- 依赖注入模式(获取数据库会话)
- RESTful最佳实践
- 错误响应统一格式
性能要求
- 数据库查询优化(避免N+1问题)
- 使用索引(标注需要建立索引的字段)
- 连接池配置说明
输出格式
请按以下结构组织代码:
### 1. Pydantic模型定义
[请求/响应模型]
### 2. 数据库模型
[SQLAlchemy模型]
### 3. 路由实现
[完整的路由代码]
### 4. 单元测试
[测试代码]
### 5. 使用说明
[如何运行和测试]
### 6. 性能优化建议
[数据库索引、查询优化等]
约束条件
禁止
- ❌ 使用同步数据库操作
- ❌ 硬编码配置信息
- ❌ 忽略异常处理
- ❌ 返回内部错误详情给客户端
推荐
- ✅ 使用环境变量配置
- ✅ 实现请求日志记录
- ✅ 添加API限流考虑
- ✅ 使用transaction管理
示例参考
期望的响应格式:
{
"success": true,
"data": {
"tasks": [...],
"total": 100,
"page": 1,
"limit": 20
},
"message": "Success"
}
错误响应格式:
{
"success": false,
"error": {
"code": "TASK_NOT_FOUND",
"message": "Task with id 123 not found"
}
}
**为什么这是好提示词?**
- ✅ 角色明确(资深Python工程师)
- ✅ 背景完整(技术栈、数据模型)
- ✅ 要求具体(5个API,详细规格)
- ✅ 约束清晰(必须/禁止项明确)
- ✅ 格式规范(预期输出结构)
- ✅ 示例充分(响应格式示例)
---
### 示例2: 数据分析 - 性能优化报告
```markdown
# 任务:Web应用性能分析与优化方案
## 角色设定
你是一位性能优化专家,擅长全栈性能分析和调优,精通:
- 前端性能优化(Core Web Vitals)
- 后端性能优化(数据库、缓存、并发)
- 系统架构优化(微服务、分布式)
- 监控和诊断工具使用
## 问题背景
### 系统概况
- 类型: 电商网站
- 技术栈: React + Node.js + PostgreSQL + Redis
- 日活: 50万
- 峰值QPS: 5000
### 当前性能指标
| 指标 | 当前值 | 目标值 | 状态 |
|------|--------|--------|------|
| 首页加载时间 | 3.5s | <1.5s | ❌ |
| API响应时间(P99) | 2000ms | <500ms | ❌ |
| 数据库查询时间 | 800ms | <100ms | ❌ |
| 缓存命中率 | 45% | >80% | ❌ |
| CPU使用率 | 85% | <60% | ❌ |
### 已知问题
1. 首页需要加载20+个API请求
2. 商品详情页数据库查询复杂(多表JOIN)
3. 图片资源未优化(平均2MB)
4. 没有使用CDN
5. Redis缓存策略不合理
### 监控数据
[提供Grafana截图链接或数据]
- CPU使用率趋势
- 内存使用趋势
- 慢查询日志(top 10)
- API响应时间分布
## 任务要求
### 分析维度
请从以下角度进行全面分析:
#### 1. 前端性能
- [ ] 资源加载优化
- [ ] 代码分割和懒加载
- [ ] 渲染性能
- [ ] 网络请求优化
#### 2. 后端性能
- [ ] API接口优化
- [ ] 数据库查询优化
- [ ] 缓存策略优化
- [ ] 并发处理优化
#### 3. 架构层面
- [ ] 服务拆分必要性
- [ ] 负载均衡策略
- [ ] CDN部署方案
- [ ] 数据库分库分表
#### 4. 运维层面
- [ ] 监控完善建议
- [ ] 告警策略
- [ ] 自动化扩容
## 输出要求
请按以下结构输出详细报告:
### 第一部分:问题诊断(30%)
```markdown
## 1. 性能瓶颈识别
### 1.1 前端瓶颈
- **问题:** [具体描述]
- **数据支撑:** [监控数据]
- **影响程度:** [高/中/低]
### 1.2 后端瓶颈
[同上格式]
### 1.3 基础设施瓶颈
[同上格式]
第二部分:优化方案(50%)
## 2. 分层优化方案
### 2.1 快速见效方案(1周内)
| 方案 | 实施难度 | 预期提升 | 风险 | 优先级 |
|------|----------|----------|------|--------|
| CDN部署 | 低 | 50% | 低 | P0 |
| 图片压缩 | 低 | 30% | 无 | P0 |
| ... | ... | ... | ... | ... |
**详细说明:**
#### 方案1: CDN部署
- **实施步骤:**
1. [步骤1]
2. [步骤2]
- **技术细节:** [具体配置]
- **预期效果:** [数据预估]
- **回滚方案:** [如何回滚]
### 2.2 中期优化方案(1个月内)
[同上格式]
### 2.3 长期架构优化(3个月)
[同上格式]
第三部分:实施计划(10%)
## 3. 实施路线图
### 第1周
- [ ] 任务1: [具体任务]
- 负责人: [角色]
- 验收标准: [指标]
### 第2-4周
[同上]
### 监控指标
优化过程中需要持续关注:
- [ ] 指标1: [目标值]
- [ ] 指标2: [目标值]
第四部分:风险评估(10%)
## 4. 风险与应对
| 风险 | 概率 | 影响 | 应对措施 |
|------|------|------|----------|
| CDN同步延迟 | 中 | 中 | 降级回源 |
| 缓存雪崩 | 低 | 高 | 随机过期时间 |
输出格式要求
文档规范
- 使用Markdown格式
- 包含完整目录
- 表格对齐美观
- 代码块使用语法高亮
- 总字数4000-5000字
数据要求
- 所有优化方案必须有量化指标
- 性能提升用百分比表示
- 成本估算(人力+资源)
- ROI分析
可执行性
- 方案具体可落地
- 包含技术实现细节
- 提供配置示例
- 说明验证方法
约束条件
成本约束
- 服务器成本增加不超过30%
- 不引入昂贵的商业软件
- 优先使用开源方案
技术约束
- 不改变现有技术栈
- 向后兼容
- 不影响现有功能
时间约束
- 快速见效方案1周内完成
- 整体优化3个月内完成
参考资料
[如果有相关文档、监控数据链接,在此列出]
**为什么这是好提示词?**
- ✅ 角色专业(性能优化专家)
- ✅ 背景详实(系统概况+性能指标+已知问题)
- ✅ 要求全面(4个分析维度)
- ✅ 结构清晰(4部分输出结构)
- ✅ 量化明确(所有指标数字化)
- ✅ 约束合理(成本、技术、时间限制)
---
### 示例3: 技术写作 - 教程文档
```markdown
# 任务:编写技术教程文档
## 角色定位
你是一位技术作家,擅长将复杂的技术概念用通俗易懂的语言解释,
曾为多家知名科技公司编写技术文档,文章阅读量超过100万。
你的写作特点:
- 由浅入深,循序渐进
- 大量使用类比和实际案例
- 代码示例完整可运行
- 配图清晰易懂
- 注重实战应用
## 写作任务
### 主题
**《Docker容器化从入门到实战》**
### 目标读者
- 具备基础Linux命令行知识
- 了解基本的编程概念
- 没有容器化经验
- 需要在实际项目中使用Docker
### 文章目标
读者完成学习后应该能够:
- [ ] 理解容器化的核心概念
- [ ] 独立编写Dockerfile
- [ ] 使用docker-compose编排多容器应用
- [ ] 掌握Docker网络和数据卷
- [ ] 能部署一个完整的Web应用
## 内容要求
### 文章结构(必须按此结构)
#### 第1部分:概念篇(20%)
```markdown
## 1. 什么是Docker?
### 1.1 传统部署的痛点
[用生活化的例子说明环境问题]
### 1.2 容器化解决了什么问题
[对比传统部署 vs 容器化]
### 1.3 Docker核心概念
- 镜像(Image)
- 容器(Container)
- 仓库(Registry)
[用类比方式解释,如:镜像=菜谱,容器=做出的菜]
### 1.4 Docker vs 虚拟机
[表格对比,配架构图]
第2部分:入门篇(30%)
## 2. Docker快速上手
### 2.1 安装Docker
[各操作系统的安装步骤]
### 2.2 第一个容器
```bash
# 运行一个Nginx容器
docker run -d -p 8080:80 nginx
[详细解释每个参数的含义]
2.3 常用命令速查
[表格形式,命令+说明+示例]
2.4 实战练习
创建一个简单的Python Web应用容器 [完整步骤+代码]
#### 第3部分:进阶篇(30%)
```markdown
## 3. Dockerfile最佳实践
### 3.1 编写Dockerfile
[从简单到复杂,3个递进示例]
### 3.2 镜像优化技巧
- 多阶段构建
- 层缓存利用
- .dockerignore使用
### 3.3 实战:构建生产级镜像
[完整的Node.js应用Dockerfile]
第4部分:实战篇(20%)
## 4. Docker Compose编排
### 4.1 为什么需要Compose
[多容器应用的复杂性]
### 4.2 编写docker-compose.yml
[完整示例:Web + 数据库 + Redis]
### 4.3 部署完整应用
[详细步骤,从零到上线]
### 4.4 常见问题排查
[FAQ形式]
写作规范
语言风格
- 使用"你/我们"而非"用户/读者"
- 避免专业术语堆砌,必要时解释
- 多用主动语态
- 适当使用emoji增强可读性(但不过度)
代码示例要求
- 每个代码块必须完整可运行
- 包含注释解释关键步骤
- 提供预期输出
- 说明可能遇到的错误及解决方法
代码示例格式:
# 步骤1: 拉取镜像
docker pull nginx:latest
# 步骤2: 运行容器
docker run -d \
--name my-nginx \ # 容器名称
-p 8080:80 \ # 端口映射
nginx:latest
# 预期输出:
# 3f5a4b2c1d8e9... (容器ID)
# 验证:
curl http://localhost:8080
# 应该看到Nginx欢迎页面
图表要求
- 每个核心概念配图说明
- 流程图使用统一风格
- 架构图标注清晰
需要配图的部分:
- Docker架构图
- 镜像层级结构图
- 容器网络模式图
- docker-compose部署架构图
[用Mermaid或ASCII art绘制,如:]
┌─────────────────────────────────────┐
│ Docker Host │
│ ┌─────────┐ ┌─────────┐ │
│ │Container│ │Container│ │
│ │ App A │ │ App B │ │
│ └────┬────┘ └────┬────┘ │
│ │ │ │
│ └────────┬───┘ │
│ Docker Engine │
└───────────────────────────────────-─┘
实战项目要求
- 选择实际业务场景(电商/博客/API)
- 提供完整项目代码(GitHub链接)
- 分步骤详细说明
- 包含测试验证方法
实战项目结构:
## 实战项目:部署博客系统
### 项目介绍
- 技术栈: Django + PostgreSQL + Nginx
- 功能: [列举]
### 项目结构
[目录树]
### 部署步骤
#### 步骤1: 准备Dockerfile
[代码+解释]
#### 步骤2: 编写docker-compose.yml
[代码+解释]
#### 步骤3: 初始化数据库
[命令+说明]
#### 步骤4: 启动应用
[命令+验证]
### 访问测试
[URL+截图+说明]
### 故障排查
[常见问题+解决方案]
质量标准
文章指标
- 总字数: 8000-10000字
- 代码示例: 至少15个
- 图表: 至少6个
- 实战项目: 1个完整项目
可读性
- 段落长度: 不超过5行
- 代码块: 不超过30行(复杂逻辑拆分)
- 标题层级: 不超过4级
- 技术术语: 首次出现需解释
实用性
- 所有命令经过实际测试
- 代码可直接复制运行
- 包含常见问题解答
- 提供扩展学习资源
输出格式
# Docker容器化从入门到实战
> 📚 学习目标: [列出3-5个具体目标]
> ⏱️ 预计学习时间: 3-4小时
> 💻 前置知识: [列出必要的前置知识]
## 目录
[自动生成的详细目录]
---
## 1. 什么是Docker?
[按要求编写...]
## 2. Docker快速上手
[按要求编写...]
## 3. Dockerfile最佳实践
[按要求编写...]
## 4. Docker Compose编排
[按要求编写...]
## 5. 实战项目:部署博客系统
[完整实战项目...]
## 6. 进阶学习路径
[推荐资源...]
---
## 附录
### A. 常用命令速查表
[完整命令列表]
### B. 常见错误排查
[FAQ]
### C. 扩展资源
[官方文档、社区资源链接]
特别要求
教学技巧
- 使用"费曼学习法"结构(概念-解释-类比-实践)
- 每个章节包含"知识点总结"
- 提供"自检题"帮助读者验证理解
- 标注"难度等级"(入门/进阶/高级)
案例选择
- 优先使用读者熟悉的场景
- 从简单到复杂渐进
- 每个案例都解决实际问题
错误处理
- 预判新手可能遇到的坑
- 提供详细的错误信息解读
- 给出多种解决方案
约束条件
禁止
- ❌ 假设读者有高深的知识背景
- ❌ 使用未解释的缩写词
- ❌ 跳过关键步骤
- ❌ 提供无法运行的代码
推荐
- ✅ 用生活化类比解释抽象概念
- ✅ 每个重要概念重复3次(不同方式)
- ✅ 提供"为什么"而非仅"怎么做"
- ✅ 鼓励读者动手实践
验收标准
完成的文章应该:
- 零基础读者可以跟着完成实战项目
- 所有代码都经过实际测试
- 解释清楚了每个概念的"为什么"
- 提供了完整的故障排查指南
- 阅读体验流畅,不枯燥
**为什么这是好提示词?**
- ✅ 角色清晰(技术作家,有写作风格)
- ✅ 目标明确(目标读者+学习目标)
- ✅ 结构详细(4部分固定结构)
- ✅ 规范具体(语言风格+代码格式+图表要求)
- ✅ 质量标准量化(字数、代码数、图表数)
- ✅ 教学方法明确(费曼学习法)
---
### 示例4: 问题诊断 - 系统故障分析
```markdown
# 任务:系统故障诊断与解决方案
## 角色设定
你是一位经验丰富的DevOps工程师和系统架构师,具备:
- 10年以上大型分布式系统运维经验
- 处理过数百起生产环境故障
- 擅长根因分析(Root Cause Analysis)
- 精通系统监控、日志分析、性能调优
你的诊断风格:
- 系统化思考,不放过任何细节
- 基于数据和日志,而非猜测
- 提供多层次的解决方案(临时方案+根本方案)
- 重视预防措施和监控完善
## 故障背景
### 系统信息
- **应用:** 在线教育平台后端API
- **架构:** 微服务(10+服务)
- **技术栈:**
- 后端: Java Spring Boot + Python Flask
- 数据库: MySQL(主从) + MongoDB
- 缓存: Redis Cluster
- 消息队列: RabbitMQ
- 部署: Kubernetes + Docker
- **规模:**
- 日活: 200万
- 峰值QPS: 8000
- 数据库: 500GB
### 故障现象
**发生时间:** 2024-01-15 14:30
**用户影响:**
- 80%的用户无法登录
- 已登录用户操作缓慢(响应时间>10s)
- 视频播放服务完全不可用
- 部分支付订单丢失
**监控告警:**
14:28 - CPU usage spike: node-3 95% 14:29 - Memory alert: node-3 OOM killed 14:30 - Pod restart: video-service (5 replicas, all restarting) 14:31 - Database connection pool exhausted 14:32 - Redis connection timeout (1000+ instances) 14:35 - Message queue backlog: 50000+ messages
### 日志片段
**应用日志(video-service):**
[ERROR] 14:29:58 - Failed to connect to Redis: timeout after 5000ms [ERROR] 14:30:12 - Database query timeout: SELECT * FROM videos WHERE... [FATAL] 14:30:45 - OutOfMemoryError: Java heap space [ERROR] 14:31:03 - RabbitMQ connection refused
**数据库慢查询日志:**
```sql
# Query_time: 25.3 Lock_time: 0.1 Rows_sent: 50000
SELECT v.*, u.username, c.title
FROM videos v
JOIN users u ON v.user_id = u.id
JOIN courses c ON v.course_id = c.id
WHERE v.created_at > '2024-01-01'
ORDER BY v.view_count DESC;
系统指标(Prometheus):
- node-3-cpu: 95% (之前30%)
- node-3-memory: 92% → OOM
- video-service-heap: 3.8GB/4GB
- mysql-connections: 950/1000
- redis-connections: 9500/10000
- network-in: 800Mbps (平时100Mbps)
最近变更
- 2024-01-15 10:00: 部署了视频推荐算法优化(v2.5.0)
- 2024-01-14: 营销活动上线(新用户优惠)
- 2024-01-13: 数据库添加了新索引
环境信息
- Kubernetes: v1.28
- JVM: OpenJDK 17
- MySQL: 8.0.35
- Redis: 7.0.12
诊断任务
请按照以下步骤进行系统化诊断:
步骤1:故障分类与影响评估(10%)
## 1. 故障定性
### 1.1 故障级别
- [ ] P0 - 全站不可用
- [ ] P1 - 核心功能不可用
- [ ] P2 - 部分功能异常
- [ ] P3 - 性能下降
**结论:** [选择并说明理由]
### 1.2 影响范围
- 受影响用户比例: XX%
- 受影响功能: [列举]
- 业务损失估算: [金额或用户流失]
### 1.3 紧急程度
- [ ] 立即处理(5分钟内)
- [ ] 紧急处理(30分钟内)
- [ ] 优先处理(2小时内)
**结论:** [选择并说明理由]
步骤2:根因分析(40%)
## 2. 根因定位
### 2.1 时间线重建
基于日志和监控,重建故障发生过程:
| 时间 | 事件 | 可能原因 |
|------|------|----------|
| 14:28 | node-3 CPU飙升 | ? |
| 14:29 | OOM killed | ? |
| 14:30 | 服务雪崩 | ? |
### 2.2 问题分层分析
#### 应用层问题
- **现象:** [具体描述]
- **证据:** [日志/指标]
- **可能原因:** [假设1、假设2、假设3]
- **验证方法:** [如何验证每个假设]
#### 数据层问题
[同上格式]
#### 基础设施问题
[同上格式]
### 2.3 因果链推导
用5-Why方法深挖根因:
问题: 为什么服务不可用? └─ 因为: pod不断重启 └─ 为什么: OOM └─ 为什么: 内存泄漏 └─ 为什么: 新代码存在bug └─ 为什么: 缺少充分的压力测试 → 根因: 发布流程缺少性能测试环节
### 2.4 根因总结
**主要根因:** [1-2个核心问题]
**次要因素:** [放大问题的因素]
**触发条件:** [为什么偏偏这个时间点]
步骤3:解决方案(30%)
## 3. 分层解决方案
### 3.1 应急止血(5分钟内)
**目标:** 恢复基本可用性
| 操作 | 命令/步骤 | 预期效果 | 风险 |
|------|-----------|----------|------|
| 回滚代码 | `kubectl rollout undo...` | 恢复80%功能 | 丢失新功能 |
| 扩容实例 | `kubectl scale...` | 分散负载 | 成本增加 |
| 限流降级 | [配置修改] | 保护核心服务 | 部分功能不可用 |
**执行顺序:**
1. [第一步]
2. [第二步]
3. [第三步]
**验证方法:**
- [ ] 错误率降至5%以下
- [ ] 响应时间恢复到1s以内
- [ ] 用户可以正常登录
### 3.2 治标方案(1小时内)
**目标:** 完全恢复服务
[详细步骤]
### 3.3 治本方案(1周内)
**目标:** 根除问题,防止复发
#### 方案1: 代码修复
- **问题:** [具体bug]
- **修复:** [代码diff或伪代码]
- **测试:** [如何验证]
#### 方案2: 架构优化
- **问题:** [架构缺陷]
- **优化:** [设计方案]
- **实施:** [步骤]
#### 方案3: 监控加强
- **盲点:** [当前监控缺失]
- **补充:** [新增监控项]
- **告警:** [告警规则]
步骤4:预防措施(20%)
## 4. 预防与改进
### 4.1 短期措施(本周完成)
- [ ] 添加xxx监控指标
- [ ] 实施API限流
- [ ] 完善故障应急手册
- [ ] 开展事故复盘会议
### 4.2 中期改进(本月完成)
- [ ] 优化发布流程(增加性能测试)
- [ ] 实施混沌工程测试
- [ ] 完善服务降级策略
- [ ] 建立压力测试常态化机制
### 4.3 长期建设(季度目标)
- [ ] 微服务架构优化(服务拆分/合并)
- [ ] 建设分布式追踪系统
- [ ] 实施SRE最佳实践
- [ ] 团队技术能力提升计划
### 4.4 监控完善
新增监控项:
```yaml
# Prometheus规则示例
- alert: VideoServiceMemoryHigh
expr: jvm_memory_used_bytes / jvm_memory_max_bytes > 0.8
for: 5m
labels:
severity: warning
annotations:
summary: "Video service memory usage > 80%"
4.5 应急演练
建议每月进行一次故障演练:
- 数据库主从切换
- Redis集群故障
- 网络分区
- 流量激增
## 输出要求
### 报告结构
```markdown
# 故障诊断报告
## 执行摘要(给管理层看)
- 故障级别:
- 影响范围:
- 根本原因:
- 解决状态:
- 业务损失:
- 预防措施:
## 详细分析(给技术团队看)
[完整的4步骤内容]
## 附录
- A. 完整日志
- B. 监控截图
- C. 相关工单链接
撰写规范
- 使用时间线叙事,清晰易懂
- 所有结论必须有证据支撑
- 提供具体可执行的命令
- 标注每个方案的风险
- 包含监控截图或数据图表
技术深度
- 深入到代码/配置级别
- 解释技术原理(如:为什么OOM)
- 提供优化前后对比数据
- 引用最佳实践或官方文档
约束条件
必须包含
- 完整的时间线
- 根因的5-Why分析
- 至少3层解决方案(应急/治标/治本)
- 可执行的预防措施清单
- 监控告警规则示例
禁止
- ❌ 模糊的结论("可能是...""应该是...")
- ❌ 没有证据的猜测
- ❌ 只说问题不给方案
- ❌ 技术黑话堆砌
验收标准
完成的诊断报告应该:
- 初级工程师能看懂故障过程
- 高级工程师能根据方案操作
- 管理层能理解影响和改进计划
- 包含所有必要的技术细节
- 可作为未来培训材料
**为什么这是好提示词?**
- ✅ 角色专业(DevOps工程师,有故障处理经验)
- ✅ 背景完整(系统信息+故障现象+日志+监控)
- ✅ 流程系统(4步骤诊断流程)
- ✅ 深度要求明确(根因分析、5-Why)
- ✅ 输出分层(管理层摘要+技术细节)
- ✅ 可执行性强(具体命令+配置示例)
---
### 示例5: 创意任务 - 产品功能设计
```markdown
# 任务:AI功能产品设计方案
## 角色设定
你是一位资深的AI产品经理,具备:
- 5年以上AI产品设计经验
- 深入理解LLM技术能力与限制
- 成功推出过多款AI功能(MAU>100万)
- 擅长平衡技术可行性与用户价值
- 熟悉AI产品的UX设计最佳实践
你的设计理念:
- 技术服务于用户价值,而非炫技
- 渐进式体验,降低学习成本
- 可控性与智能化平衡
- 数据驱动迭代
## 产品背景
### 产品概况
- **产品:** 在线文档协作平台(类似Notion/飞书文档)
- **用户:** 知识工作者(程序员、产品经理、设计师等)
- **规模:** 月活500万,企业客户2000+
- **竞品:** Notion AI, Copilot for Docs
### 当前痛点
用户反馈top 3:
1. 从零开始写文档困难(空白页焦虑)
2. 内容整理和结构化耗时
3. 多文档间的知识关联困难
### 战略目标
- 通过AI功能提升用户创作效率30%
- 增加付费转化率(目标+15%)
- 打造差异化竞争力
## 设计任务
请设计一套完整的AI辅助写作功能,包含:
### 核心功能设计(40%)
```markdown
## 1. 功能列表
### 1.1 必备功能(MVP)
为每个功能提供:
#### 功能1: [功能名称]
**用户价值:** [解决什么问题]
**使用场景:**
- 场景1: [具体描述]
- 场景2: [具体描述]
**交互流程:**
- 用户操作: [具体操作]
- 系统响应: [AI生成/处理]
- 用户确认: [编辑/接受]
**界面设计(文字描述):**
┌─────────────────────────────┐ │ 📄 文档标题 │ │ ───────────────────── │ │ [光标位置] │ │ ╭─────────────────╮ │ │ │ 💡 AI建议: │ │ │ │ • 扩展这一段 │ │ │ │ • 生成大纲 │ │ │ │ • 改写语气 │ │ │ ╰─────────────────╯ │ └─────────────────────────────┘
**Prompt设计:**
角色: 你是一位专业的内容编辑 任务: [具体任务] 上下文: [文档上下文] 要求: [格式、风格、长度要求]
**技术实现要点:**
- 模型选择: [GPT-4/Claude/...]
- Token预算: [预估]
- 响应时间要求: [<3s]
- 降级方案: [如何处理失败]
**成功指标:**
- 使用率: 目标XX%
- 满意度: 目标>4.5/5
- 采纳率: 生成内容被保留的比例>60%
---
[为3-5个核心功能重复上述格式]
### 1.2 进阶功能(V2)
[同上格式,但简化]
### 1.3 功能优先级矩阵
| 功能 | 用户价值 | 技术难度 | 优先级 |
|------|----------|----------|--------|
| 智能续写 | 高 | 中 | P0 |
| 大纲生成 | 高 | 低 | P0 |
| 文档摘要 | 中 | 低 | P1 |
| ... | ... | ... | ... |
用户体验设计(30%)
## 2. 交互设计
### 2.1 触发方式
**设计原则:** 自然、不打扰、易发现
#### 方式1: Slash命令
- 输入 `/ai` 唤起AI菜单
- 输入 `/expand` 直接触发扩写
- 输入 `/outline` 生成大纲
#### 方式2: 快捷键
- `Cmd+J`: 打开AI助手
- `Cmd+Shift+A`: 续写
- `Cmd+Shift+R`: 改写
#### 方式3: 悬浮菜单
- 选中文字后出现快捷菜单
- 包含AI操作选项
#### 方式4: 智能推荐
- 检测到空段落,自动提示
- 长段落自动建议分段/添加小标题
**设计草图(ASCII art):**
用户输入: "介绍一下Docker的优势" + /ai ↓ ┌───────────────────────────────┐ │ 💡 AI操作 │ │ ───────────────────── │ │ ✨ 扩展成完整段落 │ │ 📝 生成要点列表 │ │ 🎯 添加实例说明 │ │ 📊 对比虚拟机与容器 │ └───────────────────────────────┘
### 2.2 反馈机制
**设计原则:** 可见、可控、可回退
#### 实时反馈
- 生成中显示进度(打字机效果)
- 每生成50字暂停,允许用户停止
- 显示token消耗(付费用户)
#### 结果呈现
┌─────────────────────────────┐ │ AI生成的内容以淡蓝色高亮 │ │ ─────────────────── │ │ [Accept] [Edit] [Discard] │ │ ↑ │ │ 点击可inline编辑 │ └─────────────────────────────┘
#### 质量控制
- 👍👎 点赞/点踩收集反馈
- "重新生成"按钮
- "生成更多选项"(3个变体)
### 2.3 边界情况处理
| 情况 | 处理方式 | 文案示例 |
|------|----------|----------|
| 上下文不足 | 提示补充信息 | "请提供更多背景,我可以..." |
| 生成失败 | 降级+重试按钮 | "生成遇到问题,要重试吗?" |
| 内容敏感 | 拒绝生成+说明 | "这个话题我无法处理,因为..." |
| Token超限 | 提示付费/精简 | "内容较长,建议精简或升级..." |
### 2.4 新手引导
**首次使用:**
1. 弹窗介绍核心功能(3屏)
2. 交互式教程(实际操作)
3. 示例文档(可复制使用)
**帮助文档:**
- 快捷键速查卡
- 视频教程(1-2分钟)
- 常见问题FAQ
技术方案设计(20%)
## 3. 技术实现
### 3.1 架构设计
┌─────────────────────────────────┐ │ 用户端(React) │ └────────────┬────────────────────┘ │ WebSocket/HTTP ┌────────────▼────────────────────┐ │ API网关 + 鉴权 │ └────────────┬────────────────────┘ │ ┌───────┴────────┐ │ │ ┌────▼─────┐ ┌─────▼─────┐ │AI服务 │ │文档服务 │ │(Python) │ │(Java) │ └────┬─────┘ └─────┬──────┘ │ │ ┌────▼──────────────▼────┐ │ 向量数据库(Pinecone) │ │ LLM API(OpenAI/...) │ └─────────────────────────┘
### 3.2 核心技术选型
| 组件 | 选型 | 理由 |
|------|------|------|
| LLM模型 | GPT-4-turbo | 质量+速度平衡 |
| 向量DB | Pinecone | 托管,易扩展 |
| 流式传输 | Server-Sent Events | 打字机效果 |
| 缓存 | Redis | 相似prompt复用 |
### 3.3 Prompt工程策略
**模板化管理:**
```python
# prompt_templates.py
EXPAND_TEMPLATE = """
角色: 你是一位专业的技术文档编辑
上下文:
- 文档标题: {title}
- 当前段落: {current_paragraph}
- 上文: {previous_context}
任务: 扩展当前段落为3-5句话的完整内容
要求:
1. 保持技术准确性
2. 语言简洁清晰
3. 逻辑连贯
4. 字数约150-200字
输出格式: 直接输出扩展后的段落,无需额外说明
"""
版本管理:
- Prompt存储在配置中心
- 支持A/B测试不同prompt
- 记录每个prompt的效果指标
3.4 成本优化
策略:
- 智能缓存(相似度>0.95复用)
- 模型降级(简单任务用GPT-3.5)
- Batch处理(非实时任务)
- Token限制(单次生成<500tokens)
预算估算:
- 月活500万,10%使用AI功能 = 50万活跃
- 人均调用5次/月 = 250万次
- 平均消耗1000 tokens/次 = 25亿tokens/月
- 成本: $XXX/月 (按GPT-4价格)
3.5 性能指标
| 指标 | 目标 | 监控 |
|---|---|---|
| P95响应时间 | <3s | ✓ |
| 可用性 | 99.9% | ✓ |
| Token利用率 | >80% | ✓ |
| 缓存命中率 | >30% | ✓ |
### 商业化与增长(10%)
```markdown
## 4. 商业策略
### 4.1 定价方案
| 套餐 | 月费 | AI功能额度 | 目标用户 |
|------|------|-----------|---------|
| 免费版 | $0 | 10次/月 | 试用用户 |
| 标准版 | $8 | 100次/月 | 个人用户 |
| 专业版 | $16 | 500次/月 | 重度用户 |
| 企业版 | 定制 | 无限制 | 企业客户 |
### 4.2 转化漏斗设计
首次体验(Free) ↓ (触达免费额度上限) 引导付费提示 ↓ (提供限时优惠) 付费转化 ↓ (使用习惯养成) 续费/升级
### 4.3 增长策略
- **Aha时刻:** 首次成功生成有价值内容
- **习惯培养:** 每日AI生成提醒
- **病毒传播:** 分享AI生成的精彩内容
- **推荐机制:** 邀请好友获得额外额度
输出格式要求
文档结构
# AI辅助写作功能设计方案 v1.0
## 文档信息
- 版本: 1.0
- 作者: [PM姓名]
- 日期: 2024-XX-XX
- 评审状态: 待评审
## 1. 产品概述
[背景+目标+核心价值]
## 2. 功能设计
[完整的功能列表+优先级]
## 3. 交互设计
[详细的UX方案]
## 4. 技术方案
[架构+实现细节]
## 5. 商业模式
[定价+增长策略]
## 6. 实施计划
[路线图+里程碑]
## 7. 风险与挑战
[风险评估+应对]
## 附录
- A. 竞品分析
- B. 用户调研数据
- C. Prototype链接
可视化要求
- 至少3个交互流程图
- 界面线框图(ASCII art或描述)
- 架构图
- 数据流图
详细程度
- 核心功能包含完整的Prompt示例
- 每个设计决策说明理由
- 提供备选方案对比
- 包含成功指标定义
约束条件
必须考虑
- AI幻觉问题(如何降低错误率)
- 隐私保护(用户数据如何使用)
- 成本控制(单用户成本<$X)
- 合规性(GDPR, 内容审核)
设计原则
- 可控性优先于智能化
- 渐进式体验,避免一次性过载
- 始终提供人工编辑选项
- 明确标注AI生成内容
禁止
- ❌ 过度承诺AI能力
- ❌ 强制使用AI功能
- ❌ 无差别替代人工创作
- ❌ 忽略边界情况
验收标准
完成的设计方案应该:
- 开发团队能据此开始技术方案设计
- 设计师能据此绘制高保真原型
- 业务方能理解商业价值
- 包含足够细节,减少实施中的歧义
- 可直接用于团队评审
**为什么这是好提示词?**
- ✅ 角色专业(AI产品经理,有成功案例)
- ✅ 背景丰富(产品+用户+痛点+目标)
- ✅ 要求全面(功能+UX+技术+商业)
- ✅ 细节具体(包含Prompt示例、界面草图)
- ✅ 考虑周全(成本、隐私、合规)
- ✅ 可执行性强(开发可直接使用)
---
## 6. 常见错误与优化
### 6.1 常见错误列表
| 错误类型 | 具体表现 | 后果 | 正确做法 |
|---------|---------|------|---------|
| **模糊不清** | "帮我写点东西" | 输出不可预测 | 明确主题、格式、长度 |
| **上下文缺失** | 不说明背景就提问 | 答案不切合实际 | 提供充分的背景信息 |
| **期望过高** | 要求AI做超出能力的事 | 结果令人失望 | 了解模型的限制 |
| **约束不足** | 没有明确限制条件 | 输出偏离预期 | 列出"必须"和"禁止" |
| **示例缺乏** | 新格式没有给示例 | AI理解偏差 | 提供1-3个清晰示例 |
| **单次提示词过长** | 超过10000字的提示词 | AI可能遗漏细节 | 拆分为多轮对话 |
### 6.2 优化前后对比
#### 案例1: 代码审查
❌ **优化前:**
请审查这段代码
✅ **优化后:**
```markdown
## 代码审查任务
### 审查上下文
- 语言: Python 3.11
- 项目: 电商订单系统
- 功能: 订单创建API
- 代码作者经验: 初级工程师
### 审查维度(请逐项检查)
1. **功能正确性**
- 逻辑是否正确
- 边界情况处理
- 错误处理完整性
2. **代码质量**
- 是否符合PEP8
- 命名是否语义化
- 注释是否清晰
3. **性能**
- 是否存在N+1查询
- 数据库操作是否优化
- 是否合理使用缓存
4. **安全性**
- SQL注入风险
- 输入验证
- 权限检查
5. **可维护性**
- 函数是否过长(>50行)
- 重复代码
- 耦合度
### 输出格式
对于每个发现的问题:
问题X: [问题标题]
- 严重程度: [Critical/High/Medium/Low]
- 位置: [行号]
- 问题描述: [具体说明]
- 修改建议: [代码示例]
- 理由: [为什么需要修改]
### 代码
```python
[待审查的代码]
**改进点:**
- 增加了审查上下文
- 明确了审查维度(5个方面)
- 规定了输出格式
- 要求提供具体修改建议
---
#### 案例2: 内容总结
❌ **优化前:**
总结这篇文章
✅ **优化后:**
```markdown
## 文章总结任务
### 目标读者
技术团队的项目经理,需要快速了解文章核心内容。
### 总结要求
1. **长度:** 200-300字
2. **结构:**
- 第1段: 文章主题和背景(2-3句)
- 第2段: 核心观点/论据(3-5个要点)
- 第3段: 结论或实际意义(1-2句)
3. **风格:** 客观、准确、简洁
4. **术语:** 保留专业术语,但简要解释
### 不要包含
- 个人观点或评论
- 次要细节或案例
- 引用或参考文献
### 输出格式
```markdown
## 文章摘要
**主题:** [一句话概括]
**背景:** [2-3句]
**核心观点:**
1. [观点1]
2. [观点2]
3. [观点3]
**结论:** [1-2句]
**关键词:** #标签1 #标签2 #标签3
原文
[文章内容]
**改进点:**
- 明确了目标读者
- 详细规定了总结结构和长度
- 指定了风格要求
- 提供了输出格式模板
---
### 6.3 调试技巧
#### 技巧1: 逐步细化
```markdown
## 迭代过程示例
### 迭代1: 基本需求
"写一个Python函数"
→ 输出: 太宽泛,可能返回任意函数
### 迭代2: 增加功能说明
"写一个Python函数,用于计算两个日期之间的天数"
→ 输出: 好一些,但缺少细节
### 迭代3: 增加技术要求
"写一个Python函数,用于计算两个日期之间的天数。
输入: 两个datetime对象
输出: 整数(天数)
包含错误处理"
→ 输出: 接近需求,但还可以更好
### 迭代4: 完整规格
"写一个Python函数,用于计算两个日期之间的天数。
要求:
- 输入: 两个datetime对象
- 输出: 整数(天数,绝对值)
- 包含类型注解
- 处理异常输入(None, 非datetime等)
- 包含docstring
- 包含3个单元测试
示例:
```python
>>> calculate_days_between(date1, date2)
15
```"
→ 输出: 完全符合需求
技巧2: 添加约束进行引导
## 通过约束塑造输出
### 问题: 代码过于复杂
**添加约束:**
"代码不超过20行,不使用第三方库"
### 问题: 解释过于学术
**添加约束:**
"用小学生能理解的语言解释,避免专业术语"
### 问题: 输出过长
**添加约束:**
"总字数不超过500字,每段不超过3句话"
### 问题: 缺少实例
**添加约束:**
"每个概念必须配一个实际业务场景的例子"
技巧3: 使用元提示词
## 元提示词技巧
### 自检提示
"在给出最终答案前,先自己检查:
1. 是否遵守了所有约束条件?
2. 输出格式是否正确?
3. 是否考虑了边界情况?
4. 代码能否直接运行?
如果发现问题,先修正,再输出最终版本。"
### 分步思考提示
"请一步步思考:
1. 先分析问题的关键点
2. 列出解决方案的可选路径
3. 评估每个路径的优缺点
4. 选择最佳方案并说明理由
5. 实现方案
6. 验证结果"
### 质量要求提示
"这个输出将直接用于生产环境,请确保:
- 代码经过充分测试
- 文档完整清晰
- 考虑了所有边界情况
- 性能已优化"
7. 领域专用提示词模板
7.1 软件开发
模板: Bug修复
# Bug修复提示词模板
## 环境信息
- 项目: [项目名称]
- 语言/框架: [技术栈]
- 版本: [版本号]
## Bug描述
### 预期行为
[应该发生什么]
### 实际行为
[实际发生了什么]
### 复现步骤
1. [步骤1]
2. [步骤2]
3. [步骤3]
### 错误信息
[完整的错误堆栈]
### 相关代码
```[语言]
[可能有问题的代码片段]
已尝试的方案
请求
请帮我:
- 分析问题根因
- 提供修复方案(至少2个)
- 说明每个方案的优缺点
- 给出推荐方案的完整代码
- 说明如何验证修复效果
约束
- 不改变现有API接口
- 向后兼容
- 包含单元测试
---
#### 模板: 架构设计
```markdown
# 架构设计提示词模板
## 项目背景
- 项目类型: [Web应用/移动应用/后端服务...]
- 业务领域: [电商/教育/金融...]
- 用户规模: [预期日活/月活]
- 数据量: [预估]
## 功能需求
### 核心功能
1. [功能1]: [简要描述]
2. [功能2]: [简要描述]
3. [功能3]: [简要描述]
### 非功能需求
- 性能: [QPS/响应时间要求]
- 可用性: [SLA要求]
- 安全性: [合规/认证要求]
- 扩展性: [预期增长]
## 技术约束
- 技术栈偏好: [列出偏好的技术]
- 必须使用: [强制技术]
- 禁止使用: [限制]
- 团队技能: [团队熟悉的技术]
- 预算: [成本限制]
## 请求
请设计一个架构方案,包含:
### 1. 整体架构(30%)
- 分层设计
- 组件划分
- 技术选型(说明理由)
- 架构图(Mermaid或文字描述)
### 2. 核心模块设计(40%)
为每个核心模块提供:
- 职责说明
- 接口定义
- 数据模型
- 关键流程
### 3. 技术决策(20%)
说明以下方面的技术选择:
- 数据库(关系型/NoSQL/图数据库)
- 缓存策略
- 消息队列(如需要)
- API设计(RESTful/GraphQL/gRPC)
### 4. 非功能实现(10%)
- 如何保证高可用?
- 如何应对流量峰值?
- 如何保障数据安全?
- 如何监控系统健康?
## 输出格式
[指定输出格式]
7.2 数据分析
模板: 数据分析报告
# 数据分析提示词模板
## 分析背景
- 业务问题: [需要解决的问题]
- 分析目的: [期望得到什么洞察]
- 决策场景: [分析结果将如何使用]
## 数据说明
### 数据源
- 来源: [数据库/日志/API...]
- 时间范围: [YYYY-MM-DD到YYYY-MM-DD]
- 数据量: [行数/大小]
### 数据字段
| 字段名 | 类型 | 说明 | 示例 |
|--------|------|------|------|
| user_id | int | 用户ID | 12345 |
| event | string | 事件类型 | "click" |
| ... | ... | ... | ... |
### 数据质量
- 完整性: [缺失值情况]
- 准确性: [已知问题]
- 时效性: [更新频率]
## 分析维度
请从以下角度分析:
1. [维度1]: [具体问题]
2. [维度2]: [具体问题]
3. [维度3]: [具体问题]
## 输出要求
### 结构
```markdown
## 1. 核心发现(Executive Summary)
[3-5条关键洞察]
## 2. 详细分析
### 2.1 [维度1分析]
- 现状: [数据描述]
- 趋势: [变化趋势]
- 原因: [可能的原因]
- 建议: [行动建议]
[为每个维度重复]
## 3. 数据可视化
[图表说明或代码]
## 4. 行动建议
[优先级排序的建议清单]
技术要求
- 使用Python pandas进行分析
- 提供完整可运行的代码
- 使用matplotlib/seaborn可视化
- 代码包含注释说明
统计方法
- 描述性统计(均值、中位数、分布)
- 相关性分析(如适用)
- 趋势分析(时间序列)
- 异常检测
数据文件
[CSV数据或数据库连接信息]
---
### 7.3 内容创作
#### 模板: 技术博客
```markdown
# 技术博客提示词模板
## 文章基本信息
- 主题: [具体技术主题]
- 目标读者: [读者画像]
- 阅读场景: [何时何地阅读]
- 预期收获: [读者能学到什么]
## 内容要求
### 文章结构
```markdown
## 标题 (吸引人的疑问句或陈述句)
### 开篇(10%)
- Hook: 提出问题或痛点
- 背景: 为什么这个话题重要
- 预览: 文章将涵盖什么
### 主体(80%)
#### 第1部分: 概念解释
[用类比+图解+代码示例]
#### 第2部分: 实战演示
[完整的示例项目]
#### 第3部分: 最佳实践
[经验总结+注意事项]
#### 第4部分: 常见问题
[FAQ形式]
### 结尾(10%)
- 总结: 核心要点回顾
- 延伸: 进一步学习资源
- 行动: 鼓励读者实践
写作规范
语言风格:
- 使用第二人称("你")
- 采用对话式语气
- 避免行话堆砌
- 适当使用emoji(不过度)
代码示例:
- 每个代码块完整可运行
- 包含详细注释
- 提供预期输出
- 语法高亮正确
可读性:
- 段落长度不超过5行
- 使用小标题分割内容
- 列表、表格增强结构
- 关键内容加粗强调
技术深度
- 不仅说"怎么做",更要解释"为什么"
- 包含底层原理
- 提供权威资料引用
- 指出常见误区
实用性
- 至少一个完整的实战项目
- 包含GitHub代码仓库链接
- 提供故障排查指南
- 给出性能优化建议
质量标准
- 字数: [目标字数]
- 代码示例数: [数量]
- 配图数: [数量]
- 阅读时间: [分钟]
参考资料
[如有,提供相关文档或文章链接]
---
## 总结
### 提示词编写核心要点
1. **清晰性**: 明确任务,避免歧义
2. **结构性**: 使用框架组织提示词
3. **上下文**: 提供充分背景信息
4. **约束性**: 明确"做什么"和"不做什么"
5. **示例性**: 提供参考示例
6. **迭代性**: 持续优化改进
### 提升提示词质量的检查清单
- [ ] 任务目标是否清晰?
- [ ] 角色定位是否明确?
- [ ] 上下文是否充分?
- [ ] 输出格式是否规范?
- [ ] 约束条件是否完整?
- [ ] 是否提供了示例?
- [ ] 成功标准是否量化?
- [ ] 技术细节是否足够?
### 进阶学习路径
1. 深入学习一种框架(如CRISPE)
2. 建立自己的提示词模板库
3. 研究特定领域的最佳实践
4. 实践Chain-of-Thought等高级技巧
5. 关注AI产品的prompt设计案例
6. 参与提示词工程社区交流
---
**记住:** 好的提示词是实践出来的,持续迭代优化是关键!
