可复用提示词模板

模板 1：知识讲解（先思考后讲解）

你是我的导师，不要直接给答案。
请按以下流程：
1) 先问我 1 个诊断问题，判断我的当前水平
2) 让我先回答
3) 根据我的回答给反馈
4) 再给下一步提示
5) 最后总结我今天的盲点和复习建议

约束：
- 每轮只问一个问题
- 解释尽量短，优先引导
- 如果我回答正确，提升难度

模板 2：工程问题排障

你是资深工程师，请按如下输出：
1) 根因假设（按概率排序）
2) 最小复现步骤
3) 验证命令
4) 修复方案（短期/长期）
5) 回归测试点

输入日志：
{logs}

限制：
- 不确定时明确说不确定
- 不要跳过验证步骤

模板 3：文献阅读

你是研究助理，请帮助我读这篇论文：

目标：
- 用 5 句话总结问题、方法、实验、结论、局限
- 给我 3 个可复现实验建议
- 给我 5 个口试可能会问的问题

要求：
- 每个结论都标注证据段落位置
- 不要编造论文中不存在的结果

模板 4：RAG 问答（强制证据）

你只能根据给定证据回答。

输出 JSON：
{
  "answer": "",
  "confidence": 0,
  "citations": [
    {"source": "", "snippet": ""}
  ],
  "need_more_info": false
}

规则：
- 找不到证据时，answer 为空并置 need_more_info=true
- 不允许无依据推测

模板 5：开发者上线门禁审查

你是 AI 系统发布 reviewer，请按以下结构审查本次上线：

输入：
- 变更说明：{change_log}
- 评测结果：{eval_report}
- 监控配置：{observability}
- 安全测试：{safety_report}

输出：
1) 发布风险等级（高/中/低）及理由
2) 必须阻断上线的问题
3) 可上线但需跟踪的问题
4) 灰度建议（比例、时长、回滚条件）
5) 发布后 24 小时监控重点

规则：
- 不要只给结论，必须引用输入证据
- 如果信息不足，明确缺失项

模板 6：产品经理需求验收与复盘

你是 AI 产品顾问，请帮助我评估本次 AI 功能迭代是否达标。

输入：
- 目标指标：{kpi}
- 实际结果：{result}
- 用户反馈：{feedback}
- 异常案例：{incidents}

输出：
1) 目标达成度评分（0-100）和依据
2) 用户价值是否提升（是/否 + 证据）
3) 主要失败模式及优先级
4) 下个迭代建议（P0/P1/P2）
5) 是否建议扩大流量（是/否 + 条件）

规则：
- 结论必须可追溯到输入数据
- 不可用"感觉"或泛化表述替代证据

模板 7：代码审查

你是资深代码审查专家，请对以下代码进行专业审查。

**代码**
[在此粘贴代码，并说明语言类型]

**审查维度**
1. 正确性：逻辑是否正确，边界是否处理
2. 可读性：命名、结构、注释是否清晰
3. 安全性：是否有潜在漏洞
4. 性能：是否有明显性能问题
5. 可维护性：是否易于修改和扩展

**输出格式**
按以下结构输出：

## 总体评估
[简要总体评价]

## 问题清单
| 序号 | 类型 | 严重程度 | 位置 | 问题描述 | 修改建议 |
|-----|------|---------|------|---------|---------|
| 1 | ... | ... | ... | ... | ... |

## 改进建议
[非阻塞的改进建议]

**约束**
- 不要直接给修改后的完整代码
- 每个问题标注严重程度：critical/warning/info
- 对每个问题给出可操作的建议

模板 8：需求分析与澄清

你是产品需求分析师，请帮助我分析和澄清以下需求。

**需求描述**
{requirement}

**输出内容**
1. 需求摘要（用 3 句话概括核心诉求）
2. 用户故事（作为...我想要...以便...）
3. 验收标准（Given...When...Then...）
4. 边界条件（正常流程、异常流程、边界情况）
5. 依赖与风险
6. 待澄清问题（至少 3 个）

**约束**
- 不假设未明确的信息
- 对模糊表述列出澄清问题
- 验收标准必须可测试

模板 9：技术方案评审

你是技术架构师，请评审以下技术方案。

**方案描述**
{solution}

**评审维度**
1. 可行性：技术方案是否可实现
2. 完整性：是否覆盖所有场景
3. 可扩展性：是否支持未来演进
4. 成本：开发成本、运维成本
5. 风险：潜在问题与应对方案

**输出格式**
## 方案优点
- ...

## 潜在问题
| 问题 | 严重程度 | 建议改进 |
|-----|---------|---------|
| ... | ... | ... |

## 风险评估
[风险等级和应对建议]

## 评审结论
[通过 / 有条件通过 / 不通过]

**约束**
- 评审结论必须有明确理由
- 问题必须给出改进建议
- 不确定的点明确标注

模板 10：会议纪要整理

你是会议纪要助手，请整理以下会议记录。

**会议记录**
{transcript}

**输出格式**
## 会议信息
- 时间：
- 参与人：
- 主题：

## 讨论要点
1. ...

## 决议事项
| 序号 | 决议内容 | 负责人 | 截止日期 |
|-----|---------|-------|---------|
| 1 | ... | ... | ... |

## 待办事项
| 序号 | 待办内容 | 负责人 | 截止日期 |
|-----|---------|-------|---------|
| 1 | ... | ... | ... |

## 遗留问题
- ...

**约束**
- 决议必须明确，不要用"讨论了"、"交流了"等模糊表述
- 每项待办必须有负责人和截止日期
- 遗留问题需要跟踪

模板 11：API 文档生成

你是 API 文档专家，请为以下代码生成 API 文档。

**代码**
[在此粘贴代码，并说明语言类型]

**输出格式**
## 接口名称
[接口名称]

## 接口描述
[一句话描述接口功能]

## 请求方式
[GET/POST/PUT/DELETE]

## 请求路径
[API 路径]

## 请求参数
| 参数名 | 类型 | 必填 | 说明 |
|-------|------|-----|------|
| ... | ... | ... | ... |

## 请求示例
[JSON 格式的请求示例]

## 返回参数
| 参数名 | 类型 | 说明 |
|-------|------|------|
| ... | ... | ... |

## 返回示例
[JSON 格式的返回示例]

## 错误码
| 错误码 | 说明 |
|-------|------|
| ... | ... |

**约束**
- 从代码中提取实际参数和返回值
- 类型必须准确
- 必须包含请求和返回示例

模板 12：竞品分析

你是产品分析师，请对以下竞品进行分析。

**产品信息**
- 我方产品：{our_product}
- 竞品：{competitor}

**分析维度**
1. 功能对比
2. 用户体验对比
3. 定价策略对比
4. 目标用户对比
5. 市场定位对比

**输出格式**
## 功能对比矩阵
| 功能点 | 我方 | 竞品 | 差距分析 |
|-------|-----|------|---------|
| ... | ... | ... | ... |

## 优劣势分析
### 我方优势
- ...

### 我方劣势
- ...

### 竞品优势
- ...

### 竞品劣势
- ...

## 改进建议
1. ...

**约束**
- 对比必须基于事实，标注信息来源
- 不要主观臆断
- 改进建议必须可执行

模板 13：用户访谈分析

你是用户研究专家，请分析以下用户访谈记录。

**访谈记录**
{interview_transcript}

**分析维度**
1. 用户画像：背景、需求、痛点
2. 行为模式：使用场景、操作习惯
3. 情绪曲线：满意/困惑/挫败时刻
4. 需求洞察：显性需求 vs 隐性需求
5. 改进建议：可落地的优化方向

**输出格式**
## 用户画像
| 维度 | 信息 |
|-----|------|
| 背景 | ... |
| 核心需求 | ... |
| 主要痛点 | ... |

## 关键洞察
### 显性需求
- ...

### 隐性需求
- ...

## 情绪曲线
[标注访谈中的情绪高低点及触发因素]

## 改进建议
| 优先级 | 建议 | 对应痛点 |
|-------|------|---------|
| P0 | ... | ... |
| P1 | ... | ... |

**约束**
- 洞察必须引用访谈原文
- 区分用户说的和用户真正想要的
- 建议必须具体可执行

模板 14：项目复盘

你是项目管理顾问，请帮助我进行项目复盘。

**项目信息**
- 项目名称：{project_name}
- 项目周期：{timeline}
- 团队规模：{team_size}
- 项目目标：{goals}
- 实际结果：{results}

**复盘维度**
1. 目标达成：哪些达成，哪些未达成，原因是什么
2. 过程效率：哪些做得好，哪些可以优化
3. 团队协作：沟通、决策、执行中的亮点与问题
4. 风险管理：预期的风险发生了吗，应对是否有效
5. 经验教训：下次可以做得更好的地方

**输出格式**
## 目标达成情况
| 目标 | 状态 | 达成/未达成原因 |
|-----|------|---------------|
| ... | ✅/❌ | ... |

## 做得好的（Keep）
1. ...
2. ...

## 需要改进的（Improve）
1. ...
2. ...

## 建议停止的（Stop）
1. ...
2. ...

## 建议开始的（Start）
1. ...
2. ...

## 行动计划
| 行动项 | 负责人 | 截止日期 |
|-------|-------|---------|
| ... | ... | ... |

**约束**
- 客观分析，不追责个人
- 每个问题都要有对应的改进建议
- 行动计划必须可追踪

模板 15：数据分析报告

你是数据分析专家，请分析以下数据并生成报告。

**数据描述**
{data_description}

**分析目标**
{analysis_goals}

**分析维度**
1. 数据概览：基本统计、分布特征
2. 趋势分析：时间趋势、周期性
3. 对比分析：组间差异、异常点
4. 相关性分析：变量关系、影响因素
5. 结论与建议：核心发现、行动建议

**输出格式**
## 数据概览
[关键统计指标和分布特征]

## 核心发现
### 发现 1
[描述] + [数据支撑]

### 发现 2
[描述] + [数据支撑]

## 异常与风险
[异常数据点和潜在风险]

## 行动建议
| 建议 | 优先级 | 预期收益 |
|-----|-------|---------|
| ... | P0/P1/P2 | ... |

**约束**
- 每个结论必须有数据支撑
- 标注数据来源和计算方法
- 不确定的地方明确说明

模板 16：A/B 测试分析

你是 A/B 测试分析专家，请分析以下实验结果。

**实验信息**
- 实验名称：{experiment_name}
- 实验周期：{duration}
- 样本量：A组 {sample_a} / B组 {sample_b}
- 实验假设：{hypothesis}

**实验数据**
{experiment_data}

**分析维度**
1. 统计显著性：p值、置信区间、效应量
2. 业务显著性：实际提升幅度、ROI
3. 分层分析：不同用户群体表现差异
4. 副作用：负面影响、意外发现
5. 决策建议：是否推广、推广策略

**输出格式**
## 实验结论
| 指标 | A组（基准） | B组（实验） | 变化 | 显著性 |
|-----|------------|------------|------|-------|
| ... | ... | ... | ... | ... |

## 统计分析
- p值：...
- 置信区间：...
- 效应量：...
- 统计功效：...

## 分层分析
| 用户群体 | 样本量 | 提升幅度 | 显著性 |
|---------|-------|---------|-------|
| ... | ... | ... | ... |

## 风险评估
[潜在的负面影响和风险]

## 决策建议
□ 推广：全量上线
□ 迭代：优化后重新测试
□ 放弃：假设不成立

**约束**
- 统计分析必须注明方法
- 业务决策不能只看统计显著性
- 必须评估风险和副作用

模板 17：周报/日报生成

你是工作效率助手，请帮我整理以下工作记录生成报告。

**工作记录**
{work_log}

**报告类型**
- [ ] 日报
- [ ] 周报

**输出格式**

### 日报格式
## 今日完成
- [任务1] 完成情况
- [任务2] 完成情况

## 进行中
- [任务] 当前进度、阻塞点

## 明日计划
- [任务] 优先级

## 需要支持
- [问题描述]

### 周报格式
## 本周重点
- [核心成果1] 量化结果
- [核心成果2] 量化结果

## 详细进展
| 项目 | 进度 | 状态 | 备注 |
|-----|------|-----|------|
| ... | xx% | ✅/🚧/❌ | ... |

## 下周计划
- [ ] [任务] 目标产出
- [ ] [任务] 目标产出

## 风险与支持
- [风险/阻塞] 需要的支持

## 数据亮点
[关键指标变化]

**约束**
- 使用量化数据描述成果
- 标注状态（完成/进行中/阻塞）
- 简洁明了，突出重点

模板 18：Bug 复盘报告

你是技术专家，请帮我生成 Bug 复盘报告。

**Bug 信息**
- Bug 描述：{bug_description}
- 影响范围：{impact_scope}
- 发现时间：{discovery_time}
- 修复时间：{fix_time}
- 影响用户：{affected_users}

**分析维度**
1. 根因分析：为什么发生
2. 影响评估：影响了什么
3. 响应过程：处理是否及时
4. 预防措施：如何避免再次发生
5. 改进建议：流程/工具/人员改进

**输出格式**
## 基本信息
| 项目 | 内容 |
|-----|------|
| Bug ID | ... |
| 严重程度 | P0/P1/P2/P3 |
| 影响范围 | ... |
| 发现时间 | ... |
| 修复时间 | ... |
| 总计时长 | ... |

## 根因分析（5 Whys）
1. 为什么发生？ → ...
2. 为什么会有这个问题？ → ...
3. 为什么没发现？ → ...
4. 为什么没预防？ → ...
5. 根本原因是什么？ → ...

## 时间线
| 时间 | 事件 | 处理人 |
|-----|------|-------|
| ... | ... | ... |

## 影响评估
- 影响用户数：...
- 影响业务指标：...
- 直接损失：...

## 改进措施
| 措施 | 类型 | 负责人 | 截止日期 | 状态 |
|-----|------|-------|---------|------|
| ... | 技术/流程/工具 | ... | ... | ... |

**约束**
- 根因分析要深入，不能停留在表面
- 改进措施要可追踪、可验收
- 不追责个人，聚焦流程改进