---

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 — 需要方法论原文、各领域完整模板或完整论证时读；只做日常增强 时无需通读。