prompt-enhancer · diff
git:20260910.97b7c0d to git:20260925.32ce6c0
82 added, 77 removed. Audit A to A.
---
name: prompt-enhancer
- description: 将用户给出的"弱提示词 / 草稿指令"按《开发强指令.md》方法论增强为生产级强指令。方法论核心为八段式结构（角色+目标 -> 上下文 -> 复述对齐 -> 先思考 -> 执行要求 -> 明确不要 -> 自我批评 -> 输出与验收），配套八条指导思想（角色目标 / 复述对齐 / 先思考 / 明确不要 / 自我批评 / 不同方向 / 给例子 / 充分上下文）。当用户说"增强提示词"、"强化提示词"、"优化一下这段 prompt"、"把这句需求改写成强指令"、"按开发强指令方法论改写"、"enhance/strengthen this prompt"、或给出一段任务描述草稿并要求"让它更稳更准 / 更少返工"时触发。输入：原始提示词（必须）+ 可选领域背景 / 参考例子。输出：可粘贴的强指令全文 + 增强对照表（原稿薄弱点 -> 增强处理）+ 用法说明（占位符与可裁剪闸门）。不用于直接执行提示词描述的任务本身。
+ description: 将用户给出的"弱提示词 / 草稿指令"按《开发强指令》方法论增强为生产级强指令。方法论核心为八段式结构（角色+目标 -> 上下文 -> 复述对齐 -> 先思考 -> 执行要求 -> 明确不要 -> 自我批评 -> 输出与验收），配套八条指导思想（角色目标 / 复述对齐 / 先思考 / 明确不要 / 自我批评 / 不同方向 / 给例子 / 充分上下文）。当用户说"增强提示词"、"强化提示词"、"优化一下这段 prompt"、"把这句需求改写成强指令"、"按开发强指令方法论改写"、"enhance/strengthen this prompt"、或给出一段任务描述草稿并要求"让它更稳更准 / 更少返工"时触发。输入：原始提示词（必须）+ 可选领域背景 / 参考例子。输出：可粘贴的强指令全文 + 增强对照表（原稿薄弱点 -> 增强处理）+ 用法说明（占位符与可裁剪闸门）。不用于直接执行提示词描述的任务本身。
agent_created: true
---
# 增强提示词（prompt-enhancer）
+ ## Purpose
+
把"一句话草稿"变成"八段式生产级强指令"，减少 AI 拿到任务就开干、做错方向、交出平庸结果的行为。
+ 产出物是三件：可直接粘贴的强指令全文、增强对照表、用法说明。
- ## 用法
+ ## When to Use
- ```
- 增强提示词：<原始提示词>
- ```
+ - 用户给出一段任务描述草稿，要求"增强 / 强化 / 优化"它。
+ - 用户要求把口语化需求改写成结构化强指令。
+ - 用户说"让它更稳更准 / 更少返工 / 少走弯路"，意图是改指令而不是执行指令。
+ - 触发词：增强提示词、强化提示词、优化一下这段 prompt、把这句需求改写成强指令、按开发强指令
+ 方法论改写、enhance this prompt、strengthen this prompt。
+ - 用法：`增强提示词：<原始提示词>`；可追加说明 `受众 / 领域 / 我满意的例子 / 输出语言`。
- - 直接贴入原始提示词即可；可追加说明：`受众 / 领域 / 我满意的例子 / 输出语言`
- - 权威方法论来源：`references/开发强指令.md`（含第 2-12 章各领域完整模板，需要时读取对应章节）
+ ## When NOT to Use
- ## 核心方法论（摘自《开发强指令.md》第 0 章 / 第 15 章）
+ - **本 Skill 不执行提示词里描述的任务。** 用户要的是"把指令写好"，不是"照着指令干活"；若用户想
+ 的是后者，直接执行任务，不要先产出增强版指令。
+ - 用户要的是某个具体领域的成品（方案、代码、文档）而非改进指令 -> 按该任务本身处理或路由到对应
+ Skill。
+ - 用户只想要翻译、润色或去 AI 味 -> 交给 `de-ai-writing` 等专项 Skill，不要套用八段式结构。
- ### 八条指导思想速查
+ ## Workflow
- | # | 思想 | 一句话动作 |
- | --- | --- | --- |
- | 1 | 复述需求 | 动手前让它说"我理解的是……" |
- | 2 | 先思考 | 让它先给 2-3 个候选方案及取舍，再给最终版 |
- | 3 | 角色+目标 | 给专业角色，并说清什么最重要 |
- | 4 | 不要什么 | 显式写"不要 XXX"，比只说目的地更有效 |
- | 5 | 自我批评 | 答完让它对照验收标准找最弱处并重写 |
- | 6 | 不同方向 | 要"完全不同的思路"而非"再来 5 个版本" |
- | 7 | 给例子 | 让它分析例子规律再创作，不模仿字面 |
- | 8 | 充分上下文 | 好结果 = 上下文 + 限制 + 反馈 + 例子 + 目标 |
+ 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）：
[必须交付什么 / 如何判断做对了]
如果信息不足，不要猜测。明确指出缺失信息，并基于现有证据完成能确定的部分。
```
- ## 工作流程
-
- ### 第 1 步 · 解析原稿
- 提取：意图（要 AI 完成什么）、产出物、目标受众、隐含约束、领域。留意原稿里的口语化/错字表达，按真实意图归一化（如"我向导的是"->"我想要的是"），不把错字带进增强版。
-
- ### 第 2 步 · 诊断缺口（对照骨架逐项检查）
- 逐项标记原稿缺失的块，重点查这些常见病：
-
- - 无角色 / 无目标，或目标不可验证
- - 口头结构要求没有固化为步骤（例："要有主业务路径、业务能力、产品能力"只是描述，没变成执行步骤+自检）
- - "不清楚就问 / 有问题随时问"太含糊，没定义问什么、什么时候问
- - 无"明确不要"，AI 易跑偏或虚构（编造仓库不存在的证据等）
- - 无验收标准 / 交付清单
- - 无防平庸机制（自我批评、不同方向）
-
- ### 第 3 步 · 选模板
- 按任务领域从下方"领域模板库"选取最贴近的骨架；跨领域任务合并多个模板的要素。
-
- ### 第 4 步 · 增强填充（核心技巧）
- 1. **角色落地**：给专业身份 + 判断准则（例：售前解决方案架构师，擅长把技术翻译成高层业务语言）
- 2. **目标可验证**：把"生成一张图"升级为带验收口径的目标（例：让不懂技术的客户高层 3 分钟看懂）
- 3. **口头结构要求 -> 显式步骤 + 闭环自检**：用户口述的层次/顺序要求逐条展开为执行步骤，并加"自检三层是否闭环"这类核对动作
- 4. **"不清楚就问" -> 分级澄清闸门**：拆成"必须由我确认"vs"可用合理假设"两级；策略是"先出基于证据的骨架 + 分级提问清单，不硬出全量结果"，避免白做也避免卡死
- 5. **防虚构红线**：凡是基于代码/事实/数据的任务，明确"只基于证据，不编造不存在的结论"
- 6. **受众表达规范**：目标受众决定了语言边界（高层->禁黑话禁技术图；工程师->保术语保精确）
- 7. **验收清单化**：输出部分写成"交付物 1/2/3..."，每项可核对
- 8. **保留原稿全部硬性要求**：可增不可删、不可篡改原意
+ ## Decision Rules
- ### 第 5 步 · 输出与自检
- - 自检增强版是否覆盖骨架全部八块、是否消化了原稿每个要求点
- - 输出：强指令全文（对话内 code block；用户要求保存时写 .md 到工作目录）+ 增强对照表 + 用法说明
- - 若原稿信息严重不足（缺目标受众 / 产出物 / 领域），先问 1-2 个关键问题再增强；或给"默认假设版 + 待确认项清单"两段式，不阻塞交付
+ - 八块骨架全覆盖 -> 交付；缺块 -> 补齐后再交付。
+ - 原稿含领域特征 -> 先取 `references/method-quickref.md` 对应模板（T1-T6），再套通用骨架。
+ - 需要方法论原文、章节化模板与完整论证 -> 读 `references/dev-strong-prompt.md`；仅需速查与领域
+ 模板 -> 只读 `references/method-quickref.md`。
+ - 原稿信息严重不足 -> 先问 1-2 个关键问题，或交"默认假设版 + 待确认项清单"。
+ - 附加可选：按原稿类型给出"极简版 / 完整版"两个档位供选择。
- ## 领域模板库
+ ## Priority
- ### T1 通用开发 / 编码任务
- 角色：资深[语言]工程师。骨架重点：复述对齐（要改哪些文件、怎么改）、先读相关模块再动手、保持 API 兼容、不改无关代码、不引入未说明的新依赖、不添加无实际价值的防御冗余；输出：修改了什么 / 为什么 / 影响模块 / 风险 / 如何测试。
+ 规则冲突时按此顺序取舍：
- ### T2 需求理解与分析
- 角色：资深软件产品架构师。骨架重点：目标是把模糊需求变成"问题被定义清楚"，不急于出方案；列出 2-3 种可能解读再选真问题；明确 vs 隐含需求；歧义与缺失信息清单；MVP vs 后续阶段；输出需求澄清结论 + 待确认问题清单。明确不要：急于设计技术方案、替需求方脑补约束。
+ 1. **保真高于增强**：原稿的硬性要求可增不可删，不可篡改原意。
+ 2. **不执行高于交付**：只改指令，不替用户执行指令描述的任务。
+ 3. **分级澄清高于一次交付**：宁可先交骨架 + 提问清单，也不靠猜测硬出全量结果。
+ 4. **可核对高于漂亮**：验收标准必须可检查，不用"做得更好"这类空话充数。
- ### T3 技术方案 / 架构设计
- 角色：资深软件架构师。骨架重点：问题定义 -> 核心业务流程 -> 边界 -> 模块 -> 数据流 -> 调用链 -> 数据模型 -> API -> 异常/并发/安全/性能/可观测性 -> 取舍记录 -> 推荐方案；每个关键设计说明"为什么这样设计 + 放弃其他方案的原因"。明确不要：过度设计、为模式而模式。
+ ## Constraints
- ### T4 代码仓库分析 -> 面向客户/高层的方案图（实战验证版）
- 角色：资深售前解决方案架构师（面对董事长 / CEO / 业务 VP / CIO）。目标：还原产品真实解决的业务问题，产出高层方案图，三层结构：主业务路径（客户视角业务环节）-> 业务能力支撑 -> 产品能力映射。验收：不懂技术的高管 3 分钟看懂"解决了什么、凭什么做到"。
+ - 不把原稿的错字、口语化表达带进增强版；按真实意图归一化。
+ - 不引入原稿没有的新需求、新约束或新事实。
+ - 凡涉及代码/事实/数据的任务，增强版必须含"只基于证据，不编造"红线。
+ - 文件输出无乱码字符：禁 Box Drawing、Unicode 箭头等装饰符。
+ - 强指令全文必须在对话内为 code block 完整给出，用户可直接复制。
- 执行步骤：仓库认知（README/docs/目录/入口）-> 抽主业务路径（客户语言命名，不用内部模块名）-> 抽业务能力（每项须有仓库证据）-> 映射产品能力（标注证据路径，无对应物如实写"待确认/规划中"）-> 结构成图（主路径贯通，能力/产品纵向挂接）-> 高管化表达（每环节标注提效/降本/控险/体验）-> 闭环自检。
+ ## Verification
- 先思考可选构图：A 三层价值塔 / B 端到端业务泳道（主路径横向贯通、环节下挂能力与产品）/ C 价值环。明确不要：技术架构图、部署图、依赖图、类图；功能清单罗列；编造仓库不存在的能力；高层听不懂的黑话；单图超载。交付：图（自包含 SVG/HTML，可嵌入 PPT）+ 三层映射表 + 证据与假设清单 + 3 分钟讲解话术 + 待确认问题清单。信息不足时先交"证据骨架 + 分级提问清单"。
+ 每次交付前逐项确认：
- ### T5 文档 / 写作任务
- 角色：技术写作者 / 开源项目维护者（按文体）。骨架重点：先复述对"好文档"的定义标准（如：没参会的人也能实施；命令必须可验证）；明确不要营销式描述、不虚构命令或配置、不写只有作者懂的缩写；完成后对照例子找规律落实最弱处重写。可用"示例驱动"段（原则7）：让 AI 先抽象例子规律并复述确认再创作。
+ - [ ] 八块骨架全覆盖（角色/目标/上下文/复述/先思考/执行/不要/验收）。
+ - [ ] 原稿每个要求点都被消化（不删不改原意）。
+ - [ ] 验收标准可核对，不是"做得更好"这类空话。
+ - [ ] 语言与目标受众匹配（高层 vs 工程师）。
+ - [ ] 无虚构风险敞口（涉及证据的任务都有"不编造"红线）。
+ - [ ] 无 Box Drawing、Unicode 箭头等装饰字符。
- ### T6 代码审查 / Bug 分析 / 重构
- 角色：严格资深 Reviewer / 调试工程师 / 重构工程师。骨架重点：审查优先级复述（正确性 > 安全 > 并发 > 可维护）；问题分级 P0-P3，每条给"位置/问题/后果/推荐修改/是否必须改"；Bug 分析禁止按表面现象直接改，必须根因 + 证据 + 防回归；重构要求每步可独立验证、保持行为不变。明确不要：为凑数提风格偏好、删失败测试换通过、降校验掩盖问题。
+ ## Output
- ## 输出规范
+ - **Outcome**：可粘贴的强指令全文 + 增强对照表（原稿薄弱点 -> 增强处理，5-8 行）+ 用法说明
+ （占位符与可裁剪闸门）。
+ - **Done when**：三件产出物齐备，`## Verification` 清单全绿；如需保存，另写 `.md` 到当前工作目录
+ 并 `present_files` 交付。
+ - **Evidence**：增强对照表能说明每处改动对应哪条原则，用法说明标出所有待替换的方括号占位符。
- 1. **强指令全文**：对话内 code block 完整给出（用户可直接复制）；若用户要求保存或原文较长，另写 .md 到当前工作目录并 present
- 2. **增强对照表**：原稿薄弱点 -> 增强处理（5-8 行，让用户看清改了什么、为什么）
- 3. **用法说明**：占位符（方括号处需替换的字段）、可选裁剪（哪些闸门可删以换取一次出图）
- 4. 附加可选：按原稿类型给出"极简版 / 完整版"两个档位供选择
+ ## References
- ## 自检清单（每次交付前过一遍）
+ 按需加载，不要预先全读：
- - [ ] 八块骨架全覆盖（角色/目标/上下文/复述/先思考/执行/不要/验收）
- - [ ] 原稿每个要求点都被消化（不删不改原意）
- - [ ] 验收标准可核对，不是"做得更好"这类空话
- - [ ] 语言与目标受众匹配（高层 vs 工程师）
- - [ ] 无虚构风险敞口（涉及证据的任务都有"不编造"红线）
- - [ ] 文件输出无乱码字符（禁 Box Drawing、Unicode 箭头等装饰符）
+ - `references/method-quickref.md` — 需要为具体领域挑选骨架（T1-T6），或速查八条指导思想时读。
+ - `references/dev-strong-prompt.md` — 需要方法论原文、各领域完整模板或完整论证时读；只做日常增强
+ 时无需通读。