# Improve Prompt

> 当用户要求改写、增强或澄清提示词时使用。触发短语包括「改写提示词」「优化 prompt」「improve prompt」「补 DoD」「提示词不完整」「让提示词可执行」。在意图、约束、范围、输出格式、非功能要求（NFR）或 Definition of Done 不清晰时激活。

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

---


# 优化提示词

> **铁律**：先把意图拆开——已明示目标、有依据的上下文推断、成功标准、隐含 NFR、未决歧义——再结构化改写。不把“真实意图”写成无证据的心理猜测。补全逻辑，不编造事实；减少误解，不扩大范围。

## 核心边界

**允许**：

- 重组表达，让目标、上下文、步骤、输出和约束更清晰。
- 将用户已暗示、任务逻辑必需的信息显式化，并标为“推断”。
- 补充操作性要求：格式、验证、边界、成功标准。
- 把模糊完成标准（“做好、完整、高质量”）转成可观察 DoD，并按可靠性分级选验证方式（见 DoD 生成规则）。
- 输入不清且答案会改变执行方向时，先问 1 个最关键、可处理、窄焦点的澄清问题。

**禁止**：

- 添加用户未表达、未暗示、也非任务必需的新需求。
- 把猜测写成事实，或替用户决定业务偏好。
- 删除用户明确要求，或改变任务目标、技术栈、范围、语气偏好。
- 把未授权的执行动作写进 DoD；若用户只要求提案、分析或改写，DoD 只验证该交付物本身。
- 用 LLM-as-judge 替代可程序化检查（测试、命令退出码、schema/正则、编译、数学推导）。
- 为了显得完整而加入模板化废话。
- 在无 NFR 含义的任务上硬塞性能/安全/可维护性条款。

### 负面约束优先原则

输出易泛化、跑偏或脑补时，优先「禁止 X」而非「要求 Y」。

- 「禁止脑补未提及功能」比「请贴合需求」更有效
- 「不输出泛泛套话」比「请具体」更有效

### 比例原则

说明性文字从属于改写本体：改进说明的总长度不得超过改写本体。没有发生变化的维度不写，没有推断就不列推断。

## 执行流程

### 1. 意图诊断

先分析原始提示词，不急着改写。按固定格式分析（内部分析，不单独输出；只有实际进入改写的推断才作为改进说明表格的行呈现）：

- 已明示目标：...
- 上下文推断：...
- 成功标准（明示 / 推断 / 未指定）：...
- 隐含 NFR（有 / 无）：...
- 未决歧义：...

规则：

- “已明示目标”只写用户明确说过的事。
- “上下文推断”只写能从上下文合理推出、且会影响改写的内容。
- “成功标准”标明明示 / 推断 / 未指定；不把用户没说的结果写成事实。
- “隐含 NFR”是意图的质量面，不是独立章节。根据任务类型推断质量维度：代码生成 → 可维护性；API/网络 → 性能与安全；数据处理 → 可靠性与合规。只推断维度，具体门槛只采用用户提供的值。有则列出并标“推断”；无则写“无”，后续不展开。无论有无，诊断结论必须在输出中可见：有则进约束段；无则在改进说明中保留一行「隐含 NFR：无」。
- “未决歧义”只列会改变执行方向的点；若没有，写“未决歧义：无关键歧义”。

完成诊断后再用下表自检，不必逐项输出：

| 项 | 判断问题 |
| --- | --- |
| 已明示目标 | 用户明确要求完成什么？ |
| 上下文推断 | 哪些信息只能标为推断？ |
| 成功标准 | 最终要拿改写后提示词完成什么？明示 / 推断 / 未指定？ |
| 可验证 DoD | 哪些条件满足即完成？每条能否落到分级验证？ |
| 验证方式 | 确定性（测试/命令/schema）→ LLM-as-judge（rubric）→ 人工兜底？ |
| 已知约束 | 范围、禁用项、格式、工具、风格、已给 NFR 门槛？ |
| 隐含 NFR | 任务逻辑必需的质量维度？有则标「推断」，门槛仅采用用户提供的值 |
| 缺失上下文 | 缺什么会走错方向？ |
| 高风险歧义 | 猜错会明显改方案的点？ |
| 受众与产出场景 | 给谁用？促成什么决策或动作？ |
| 范式类型 | 有源文档 → 抽取式；无源 → 生成式；混合则分两段。 |

### 2. 澄清或继续

- 高风险歧义存在且上下文不足：只问 1 个最关键问题，并说明为何改变方向。
- 缺失信息不影响主方向：继续改写，加入“未指定时采用保守默认”。
- 只是表达松散：直接结构化改写。

常见高风险歧义：目标受众、交付物类型、技术栈、数据来源、时间范围、权限边界、是否允许联网、执行还是只分析。

### 3. 结构化改写

默认使用最小形态；只有命中升级触发条件时才加对应 section。

**默认形态**：`## 目标` / `## 执行要求` / `## 输出要求` / `## Definition of Done`（单行：完成 = 可观察条件）。DoD 默认在场，因为完成标准是每次改写的交付依据。

**升级触发条件**（命中哪条加哪段，不命中不加）：

- 诊断为「隐含 NFR：有」→ 加 `## 约束`（推断维度标「推断」，门槛仅采用用户提供的值）
- 输出易泛化、易脑补或需明确排除项 → 加 `## 非目标`
- 用户提供了背景信息，或存在需标注的推断 → 加 `## 背景与上下文`（已知 / 推断 / 未指定三栏）
- 存在多步依赖或执行顺序敏感 → `## 执行要求` 用编号步骤
- 同消息授权执行、完成标准模糊，或交付物将被直接执行/消费 → DoD 升级为三字段完整形式（验证层级 / 证据或 rubric / 失败处理）
- 存在执行中需再次确认的不确定点 → 加 `## 对齐检查`

三层思路（已有字段复用）：

| 层 | 回答 | 对应字段 |
| --- | --- | --- |
| 角色与边界 | AI 是谁？不能碰什么？ | 约束 + 背景推断标注 |
| 格式与标准 | 输出长什么样？ | 输出要求 + 执行要求 |
| 目标与受众 | 给谁用？达成什么？ | 目标 + 受众 |

以下为完整形态模板，仅作字段参考，不是默认输出：

```markdown
## 目标

[一句话说明用户真实目标]

## 背景与上下文

- 已知：[用户明确提供的信息]
- 推断：[从上下文合理推出的信息]
- 未指定：[会影响细节但不阻塞执行的信息]

## 执行要求

1. [步骤]
2. [步骤]

## 输出要求

- [格式、粒度、语言、长度、证据要求]

## Definition of Done

任务完成必须同时满足：

1. [完成条件]
   - 验证层级：确定性 | LLM-as-judge | 人工兜底
   - 证据或 rubric：[命令/测试/schema 输出；或二元/三级 rubric 锚点；或人工检查点]
   - 失败处理：[不满足时怎么报告或继续]
2. [完成条件]
   - 验证层级：...
   - 证据或 rubric：...
   - 失败处理：...

## 约束

- 必须：[用户明确要求；推断 NFR 维度（标「推断」），门槛仅采用用户提供的值]
- 禁止：[用户明确禁止或为防跑偏必须限制的行为]

## 非目标

- [明确不做什么，避免 DoD 扩范围]

## 对齐检查

- 若遇到 [关键不确定点]，先提问；否则按 [保守默认] 执行。
```

#### Definition of Done 生成规则

- 每条 DoD 必须可观察：禁止只写“高质量、完善、合理、足够好”。
- 每条 DoD 按可靠性分级绑定验证（高 → 低）：
  - **确定性**（优先）：测试通过、命令退出码、schema/正则、数学推导、编译检查。能程序判定的，禁止交给 LLM。
  - **LLM-as-judge**：仅当无法确定性验证（语义准确性、语气、解释质量、品牌一致性）。须二元 pass/fail 或三级 rubric 与锚点（如 `pass: 全部事实可追溯 / partial: 大部分可追溯 / fail: 存在无来源声明`）。禁止模糊形容词。
  - **人工兜底**：仅当前两种都不适用时使用，写明人工检查点。
- 最小足够：只写判定完成所必需的条件。
- 不越权：用户说 propose only / 只分析 / 不要执行时，DoD 只验证提案或分析质量。
- 默认单行：默认形态中 DoD 用单行（完成 = 可观察条件）；命中升级触发条件时改三字段完整形式。单行不等于省略——每个改写都必须有可观察完成标准。

### 4. 对齐验证

输出前检查：

- 原始每个明确要求都保留。
- 每个新增内容属于：结构化表达、任务必需步骤、合理推断、或防跑偏边界。
- DoD 已存在（单行或三字段完整形式），验证层级与规则一致（确定性 → judge → 人工兜底）。
- 隐含 NFR 诊断结论已在输出中可见：有则约束段已显式化并标「推断」；无则改进说明保留「隐含 NFR：无」一行，且未硬塞 NFR 条款。
- 推断和未知已标明，未伪装成事实。
- 改写后比原文更容易执行，且未改变用户目标。

## 输出格式

```markdown
### 增强版提示词

[改写后的版本]

---

### 改进说明

| 改动 | 原因 |
| ---- | ---- |
| [实际发生的变化] | [为什么] |
```

- 不回显原始提示词（用户上文已有）。
- 改进说明只列实际发生变化的维度（推断、NFR、防跑偏边界、DoD 设计等），每条一行；没有变化的维度不写。
- 例外：隐含 NFR 诊断结论（有 / 无）始终保留一行，作为诊断已执行的证据。
- 若改写仅为结构化整理、无推断无新增约束，其余栏目省略，仅保留 NFR 结论一行。

若需追问，先输出：

```markdown
### 需要澄清

[一个关键问题]

### 原因

[为什么不问会导致方向跑偏]
```

## 工具推荐

仅当工具与用户原始目标直接相关且不扩大范围时，推荐 1–3 个会话中相关工具。无强相关则省略。

格式：`工具名` - 一句话说明用途。

## 执行增强版提示词

仅当用户在调用本 skill 的同一条消息中明确要求改写后立即执行，才执行增强版提示词。否则交付增强版提示词后停止，不追问是否执行。

即使用户要求执行，以下情况仍停止：

- 改写阶段触发了必须澄清的问题。
- 执行包含同一条消息未具体授权的外部操作。

执行时遵守增强版的范围与约束，不再自行新增目标、工具、技术栈或交付物。