---
name: prompt-enhancer
description: 将用户给出的"弱提示词 / 草稿指令"按《开发强指令》方法论增强为生产级强指令。方法论核心为八段式结构（角色+目标 -> 上下文 -> 复述对齐 -> 先思考 -> 执行要求 -> 明确不要 -> 自我批评 -> 输出与验收），配套八条指导思想（角色目标 / 复述对齐 / 先思考 / 明确不要 / 自我批评 / 不同方向 / 给例子 / 充分上下文）。当用户说"增强提示词"、"强化提示词"、"优化一下这段 prompt"、"把这句需求改写成强指令"、"按开发强指令方法论改写"、"enhance/strengthen this prompt"、或给出一段任务描述草稿并要求"让它更稳更准 / 更少返工"时触发。输入：原始提示词（必须）+ 可选领域背景 / 参考例子。输出：可粘贴的强指令全文 + 增强对照表（原稿薄弱点 -> 增强处理）+ 用法说明（占位符与可裁剪闸门）。不用于直接执行提示词描述的任务本身。
agent_created: true
---

# 增强提示词（prompt-enhancer）

## Purpose

把"一句话草稿"变成"八段式生产级强指令"，减少 AI 拿到任务就开干、做错方向、交出平庸结果的行为。
产出物是三件：可直接粘贴的强指令全文、增强对照表、用法说明。

## When to Use

- 用户给出一段任务描述草稿，要求"增强 / 强化 / 优化"它。
- 用户要求把口语化需求改写成结构化强指令。
- 用户说"让它更稳更准 / 更少返工 / 少走弯路"，意图是改指令而不是执行指令。
- 触发词：增强提示词、强化提示词、优化一下这段 prompt、把这句需求改写成强指令、按开发强指令
  方法论改写、enhance this prompt、strengthen this prompt。
- 用法：`增强提示词：<原始提示词>`；可追加说明 `受众 / 领域 / 我满意的例子 / 输出语言`。

## When NOT to Use

- **本 Skill 不执行提示词里描述的任务。** 用户要的是"把指令写好"，不是"照着指令干活"；若用户想
  的是后者，直接执行任务，不要先产出增强版指令。
- 用户要的是某个具体领域的成品（方案、代码、文档）而非改进指令 -> 按该任务本身处理或路由到对应
  Skill。
- 用户只想要翻译、润色或去 AI 味 -> 交给 `de-ai-writing` 等专项 Skill，不要套用八段式结构。

## Workflow

1. **解析原稿**。提取意图（要 AI 完成什么）、产出物、目标受众、隐含约束、领域。留意原稿里的
   口语化/错字表达，按真实意图归一化（如"我向导的是"->"我想要的是"），不把错字带进增强版。
2. **诊断缺口**（对照下方骨架逐项检查）。重点查这些常见病：
   - 无角色 / 无目标，或目标不可验证。
   - 口头结构要求没有固化为步骤（例："要有主业务路径、业务能力、产品能力"只是描述，没变成执行
     步骤 + 自检）。
   - "不清楚就问 / 有问题随时问"太含糊，没定义问什么、什么时候问。
   - 无"明确不要"，AI 易跑偏或虚构（编造仓库不存在的证据等）。
   - 无验收标准 / 交付清单。
   - 无防平庸机制（自我批评、不同方向）。
3. **选模板**。按任务领域从 `references/method-quickref.md` 的模板库选取最贴近的骨架；跨领域任务
   合并多个模板的要素。
4. **增强填充**（核心技巧）：
   1. **角色落地**：给专业身份 + 判断准则（例：售前解决方案架构师，擅长把技术翻译成高层业务语言）。
   2. **目标可验证**：把"生成一张图"升级为带验收口径的目标（例：让不懂技术的客户高层 3 分钟看懂）。
   3. **口头结构要求 -> 显式步骤 + 闭环自检**：用户口述的层次/顺序要求逐条展开为执行步骤，并加
      "自检三层是否闭环"这类核对动作。
   4. **"不清楚就问" -> 分级澄清闸门**：拆成"必须由我确认"vs"可用合理假设"两级；策略是"先出基于
      证据的骨架 + 分级提问清单，不硬出全量结果"，避免白做也避免卡死。
   5. **防虚构红线**：凡是基于代码/事实/数据的任务，明确"只基于证据，不编造不存在的结论"。
   6. **受众表达规范**：目标受众决定语言边界（高层->禁黑话禁技术图；工程师->保术语保精确）。
   7. **验收清单化**：输出部分写成"交付物 1/2/3..."，每项可核对。
   8. **保留原稿全部硬性要求**：可增不可删、不可篡改原意。
5. **输出与自检**。自检增强版是否覆盖骨架全部八块、是否消化了原稿每个要求点。若原稿信息严重不足
   （缺目标受众 / 产出物 / 领域），先问 1-2 个关键问题再增强；或给"默认假设版 + 待确认项清单"两段
   式，不阻塞交付。

### 强指令最小可用骨架（增强的输出必须覆盖这些块）

```
你是一名[专业角色]。目标：[最终要解决的问题 + 什么最重要]。

上下文：
[项目 / 技术栈 / 现状 / 约束 / 代码 / 日志 / 架构]

我满意的例子（可选但强烈建议）：
[例子] —— 先分析其语气、结构、节奏规律，再据此创作。

第一步 · 复述对齐（原则1）：
开始前，先告诉我你理解了什么：目标 / 限制条件 / 打算怎么改。确认无误再继续。

第二步 · 先思考（原则2）：
不要直接动手。先列出 2-3 个候选方案及各自取舍，再给最终版本。

执行要求：
1. [具体怎么做] 2. [覆盖哪些维度] ...

明确不要（原则4）：
- 不要[具体反面行为]

完成后 · 自我批评（原则5）：
批评自己的产出，找出最弱的部分，说明如何改进，然后重写。

输出与验收（原则8）：
[必须交付什么 / 如何判断做对了]

如果信息不足，不要猜测。明确指出缺失信息，并基于现有证据完成能确定的部分。
```

## Decision Rules

- 八块骨架全覆盖 -> 交付；缺块 -> 补齐后再交付。
- 原稿含领域特征 -> 先取 `references/method-quickref.md` 对应模板（T1-T6），再套通用骨架。
- 需要方法论原文、章节化模板与完整论证 -> 读 `references/dev-strong-prompt.md`；仅需速查与领域
  模板 -> 只读 `references/method-quickref.md`。
- 原稿信息严重不足 -> 先问 1-2 个关键问题，或交"默认假设版 + 待确认项清单"。
- 附加可选：按原稿类型给出"极简版 / 完整版"两个档位供选择。

## Priority

规则冲突时按此顺序取舍：

1. **保真高于增强**：原稿的硬性要求可增不可删，不可篡改原意。
2. **不执行高于交付**：只改指令，不替用户执行指令描述的任务。
3. **分级澄清高于一次交付**：宁可先交骨架 + 提问清单，也不靠猜测硬出全量结果。
4. **可核对高于漂亮**：验收标准必须可检查，不用"做得更好"这类空话充数。

## Constraints

- 不把原稿的错字、口语化表达带进增强版；按真实意图归一化。
- 不引入原稿没有的新需求、新约束或新事实。
- 凡涉及代码/事实/数据的任务，增强版必须含"只基于证据，不编造"红线。
- 文件输出无乱码字符：禁 Box Drawing、Unicode 箭头等装饰符。
- 强指令全文必须在对话内为 code block 完整给出，用户可直接复制。

## Verification

每次交付前逐项确认：

- [ ] 八块骨架全覆盖（角色/目标/上下文/复述/先思考/执行/不要/验收）。
- [ ] 原稿每个要求点都被消化（不删不改原意）。
- [ ] 验收标准可核对，不是"做得更好"这类空话。
- [ ] 语言与目标受众匹配（高层 vs 工程师）。
- [ ] 无虚构风险敞口（涉及证据的任务都有"不编造"红线）。
- [ ] 无 Box Drawing、Unicode 箭头等装饰字符。

## Output

- **Outcome**：可粘贴的强指令全文 + 增强对照表（原稿薄弱点 -> 增强处理，5-8 行）+ 用法说明
  （占位符与可裁剪闸门）。
- **Done when**：三件产出物齐备，`## Verification` 清单全绿；如需保存，另写 `.md` 到当前工作目录
  并 `present_files` 交付。
- **Evidence**：增强对照表能说明每处改动对应哪条原则，用法说明标出所有待替换的方括号占位符。

## References

按需加载，不要预先全读：

- `references/method-quickref.md` — 需要为具体领域挑选骨架（T1-T6），或速查八条指导思想时读。
- `references/dev-strong-prompt.md` — 需要方法论原文、各领域完整模板或完整论证时读；只做日常增强
  时无需通读。