# Optimize Prompt

> 在回答前先把用户的问题改写成针对该问题类型最优的提示词（补齐上下文、明确目标、指定输出格式与约束），把改写版本展示给用户，再基于改写版回答。用户说"帮我优化提示词 / 用优化的方式回答 / 帮我把这个问得更好"，或使用 /optimize-prompt 时使用；对非平凡的开放问题也应主动使用。

- Skill: `simon-zj1/optimize-prompt` (Agent Skill)
- Install (CLI): `npx skillmds@latest add simon-zj1/optimize-prompt`
- Raw SKILL.md: https://api.skillmd.com/api/skills/simon-zj1/optimize-prompt/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Simon-zj1 (https://skillmd.com/u/simon-zj1)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/simon-zj1/optimize-prompt

---


# optimize-prompt

用户不一定知道怎么写好的提示词，但对同一个问题，好提示词能得到明显更好的回答。本 skill 让 AI 在回答前先做一次"提示词优化"——用 AI 自己认为最能激发高质量回答的方式重述用户的问题，把改写版本展示给用户，然后基于改写版回答。

## 何时使用

**主动使用**（用户的问题符合以下情况时）：

- 问题较开放、目标不明确（"帮我看看这个"、"这怎么办"、"帮我写个 X"）
- 问题涉及多个可能的解读方向
- 问题涉及非平凡任务：写作、分析、调试、方案设计、学习解释、创意创作、决策比较
- 问题里省略了明显重要的信息（目标读者、语气、长度、语言、预算、约束等）

**用户明确触发时**：

- "帮我优化提示词 / 用优化的方式回答 / 帮我把这个问得更好"
- 使用 `/optimize-prompt` 或调用本 skill 名

**不要使用**（会增加噪音）：

- 简单事实性问答（"2+2=?"、"Python 里怎么把字符串转小写？"）
- 简短闲聊、打招呼
- 已经非常具体、约束齐全的问题（用户已经写好了详细提示词）
- 连续多轮对话时，第一轮已优化过、后续在同一话题下推进——不要每轮都重复优化

## 输出格式

```yaml
> **优化后的提示词**
> [改写后的完整提示词——包含明确目标、必要背景、输出格式、约束条件]
>
> *（如做了非平凡假设：已假设 xxx，如不对请告诉我）*

---

[基于改写版的实际回答]
```

改写版长度：一般 2–6 句为宜。**不是越长越好**——目标是让 AI 精准命中，不是塞满关键词。

## 优化流程

### 1. 理解原始意图

- 用户最想解决什么问题（不是字面问题，是背后的目标）
- 判断问题类型：写作 / 代码调试 / 分析决策 / 学习解释 / 方案设计 / 创意 / 其他

### 2. 识别缺失维度

针对识别出的问题类型，检查关键维度是否缺失（见下方"各类型关键维度清单"）。

### 3. 改写提示词

- 能从上下文合理推断的维度直接补上（用户角色、项目背景、之前对话内容都是线索——**特别是 memory 里已经记录的用户偏好和项目上下文**）
- 无法推断但对结果影响很大的关键点，用"假设 xxx，如不对请告知"标注
- 明确目标和成功标准
- 指定输出结构和格式
- 必要时加"分步推理"、"考虑对立视角"、"给出验证方式"这类指令

### 4. 展示改写版本（关键步骤，不要跳过）

用引用块 `>` 展示改写后的提示词。这样做的价值：

- 用户能验证方向是否正确（如果 AI 猜错了意图，早发现比整篇跑偏后再改代价小）
- 用户逐渐学到"好的提示词长什么样"
- 若假设不成立，用户能立刻指出

### 5. 基于改写版回答

- 遵循改写版里的所有约束和格式
- 别机械按模板输出——改写版是自我指引，答案才是重点

## 各类型问题的关键维度

**写作类**（文章、邮件、报告、文档）

- 目标读者、语气（正式/口语/技术）、长度、结构、示例风格、必须包含 / 避免的点

**代码 / 调试类**

- 语言 + 版本、运行环境、已尝试方案、错误信息完整版、期望行为 vs 实际行为、约束（不能改哪些文件、性能要求）

**分析 / 决策类**

- 决策标准、可选方案、权重、时间预算、风险容忍度、对比基线

**学习 / 解释类**

- 用户当前知识水平、学习目的（应付考试 / 深入理解 / 实操）、比喻偏好、深度期望

**方案设计类**

- 硬约束（预算、时间、技术栈）、软偏好、成功指标、失败情形、迭代节奏

**创意类**

- 风格参考、受众情绪目标、长度、必须元素、禁止元素、变体数量

## 撰写守则

- **不要问回用户**：优化的意义就是替用户想清楚。除非缺失的维度真的无法从上下文合理假设（比如需要知道具体报错信息才能诊断代码），否则直接补上并标"假设"
- **假设要合理**：从对话历史、memory 里的项目背景与角色偏好里推断，不要瞎猜
- **不要过度设计**：一个 20 字的问题不需要改成 200 字的提示词。改写的复杂度应与问题复杂度成比例
- **保留用户原意**：改写是澄清和补全，不是替换用户想问的问题。如果改写偏离了用户明显的意图，说明你猜错了
- **展示改写版本**：不能偷偷优化不给用户看——用户学不到东西，也无法在你猜错时纠正

## 示例

### 示例 1：开放写作请求

用户原始：`帮我写个关于 AI 的文章`

优化并回答：

> **优化后的提示词**
> 请写一篇约 800 字的中文文章，主题是"AI 在 2026 年对普通开发者日常工作的实际影响"。目标读者是有 1–3 年经验的软件工程师，语气偏理性、有具体例子（工具名、场景、代码），避免"AI 会改变一切"式的空泛表达。结构：引子 + 3 个具体影响 + 一个务实的结论。
>
> *（已假设主题聚焦到"对开发者的影响"、约 800 字；若需其他角度或长度请告诉我）*

---

（此处开始写文章正文）

### 示例 2：调试问题但信息不足

用户原始：`我这个代码为什么跑不起来`

优化后（此时"优化"的结论是要用户补信息，而不是硬编）：

> **优化后的提示词**
> 帮我诊断代码报错。分析报错信息里最可能的根因（不要一上来列 10 个可能性），说明为什么这么改 + 给出最小改动方案 + 一句话的验证方式。
>
> *需要补充：完整报错信息、语言/版本、相关代码片段。请贴上来，否则只能凭猜测*

---

（此时不硬回答，而是引导用户提供信息）

### 示例 3：不需要优化

用户原始：`Python 里 datetime.now() 返回什么类型？`

→ 直接答：`datetime.datetime` 对象。**不做优化。**

### 示例 4：项目上下文里的问题（从 memory 推断）

用户原始：`帮我看下这个报错`（memory 里已有 [[fw-mid-pro-bridge-project]] 项目背景）

优化并回答：

> **优化后的提示词**
> 基于当前 FW-mid-pro ROS1↔ROS2 桥接项目（Docker 方案）的上下文，诊断刚贴出的报错。请先判断报错发生在桥接层还是原生节点，给出最可能的一个根因（不要罗列多种可能）+ 具体修复动作 + 验证命令。
>
> *（已假设报错和桥接相关，如果是别的模块请告诉我）*

---

（然后基于用户实际贴出的报错做诊断）

## 与其他 skill 的关系

- 用户想"复盘调试全过程"→ 该用 `debug-journey-recap`，不是本 skill
- 用户想"刷新长对话上下文"→ 该用 `refresh-debug-context`，不是本 skill
- 用户明确说"不要优化直接答"→ 立即停用本 skill，本轮及之后按用户直接问的回答