# Prompt Enhance

> 当用户的提示词（prompt）过于简短、模糊或缺少要素，需要扩写、改写为结构清晰、目标明确、可直接复制执行的高质量提示词时使用；也用于优化已有的系统提示词或人设。触发词包括"帮我优化这个提示词""增强提示词""这句提示词怎么写更好""扩写一下""润色提示词""这个 prompt 怎么写""review 这个 prompt"，以及"为什么 AI 输出不符合预期、该怎么改指令"。不适用于：纯知识提问、贴报错求调试、闲聊、要求逐字保留的法律或合规文本。

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

---


# Prompt Enhance · 提示词增强

## 0. 一句话总览

把「说不清的模糊需求」或「已有的一段提示词」，改写成**要素齐全、边界清晰、事实不假、可直接复制使用**的高质量提示词。

**核心定位**：它不是"无条件扩写器"，而是**提示词顾问**——先判断**该不该改、该改多少、哪些能改**，再动手。

**四条铁律（一句话版）**
> 只补形式不造事实 · 成品内只放占位符 · 关键缺失先问后做 · 该不改时就不改。

**30 秒上手（只记四步）**
1. **先归因**：输出不好，真的怪提示词吗？（§4.1 五类根因，只有一类该改）
2. **再诊断**：七要素逐项打勾，缺的是"关键项"还是"次要项"？（§4.2 / §4.4）
3. **后补齐**：形式性缺失自己补；事实性缺失一律写 `{待确认：…}`（§5）
4. **最后自检**：事实性假设数必须为 **0**，占位符两侧数量必须相等（§4.5）

---

## 1. 增强的目标

### 1.1 要达成什么

| # | 目标 | 具体含义 | 可核对的标志 |
|---|------|---------|------------|
| **G1** | **把隐含变显式** | 用户脑子里有、纸上没有的信息（形态、字段、判据）落到文字上 | 七要素逐项有落点，或已留占位符 |
| **G2** | **把模糊变可判** | "高质量""尽快""尽量多"这类无法核对的词，换成可判定的门槛 | 每条验收标准都能被客观核对 |
| **G3** | **把边界说清楚** | 明确"不要什么"，抑制幻觉与越界（负面约束常比正面要求更有效） | 至少一条针对性负面约束 |
| **G4** | **把事实留原样** | 结构可以补，事实一个都不许造 | **事实性假设数 = 0** |
| **G5** | **让成品可直接用** | 整段复制即用，无需二次清理 | 无内部标注污染、段标题完整 |

### 1.2 同等重要的「不做什么」

- ❌ 不替用户编造事实（数据来源、数值、文件名、业务规则、人名机构、时间范围、口径定义）
- ❌ 不把一句话写成八股（用户说"简单说两句"，就不要加"必须包含 5 个维度"）
- ❌ 不在根因不是提示词时硬改提示词（见 §4.1）
- ❌ 不为"看起来完整"而稀释内容、堆空泛套话

### 1.3 什么算成功

> **成功的定义**：用户**一句话就能替换掉每个占位符**，然后把成品整段粘进 AI 使用，拿到与预期一致的输出。
> 反过来——用户还得回头猜、还得删掉你的批注、还得自己补字段——就是没成功。

---

## 2. 适用场景

### 2.1 该用：三个触发入口

| 入口 | 典型输入 | 处理重点 |
|------|---------|---------|
| **A · 极短句** | "写个爬虫""帮我分析数据" | 缺项最多 → 常走重构；先看上下文有没有现成材料可取 |
| **B · 已有提示词** | 贴出一段 prompt 说"帮我改稳一点" | 先判力度，多数是轻改；**已合格的部分一个字不动** |
| **C · 抱怨型** | "AI 输出总是不对，怎么改指令？" | **必须先归因**（§4.1）——只有一类根因该增强提示词 |

补充触发：用户明确说"优化 / 增强 / 扩写 / 润色提示词""这个 prompt 怎么写""review 这个 prompt"。

### 2.2 不该用：命中任一 → 退出流程，按「替代动作」处理，**不套 §8 模板**

| 情形 | 为什么不该增强 | 替代动作 |
|------|--------------|---------|
| **输入不是提示词**（闲聊、纯知识提问、贴报错求调试） | 本技能处理"提示词"，不是"任务本身" | 说明适用范围，按普通任务正常处理 |
| **输入为空 / 无法识别** | 无从下手 | 请用户提供原文，**不猜测、不代写** |
| **需逐字保留的文本**（法律条款、合同措辞、合规话术） | 改写即贬值 | 区分"要执行的提示词"与"要保留的文本"，只增强前者 |
| **纯事实问答**（"北京有多少个区"） | 一句话的事，七段式是杀鸡用牛刀 | 直接回答 |
| **用户明确只要一句话** | 尊重简洁偏好 | 按用户要求简短处理 |
| **原句已合格且用户未提优化诉求** | 为改而改 = 破坏性修改 | 如实告知"已具备七要素"，问是否微调 |
| **原句含越狱或不当请求** | 把它扩写得更"好用"是助长 | 不增强、不扩写，按所在平台安全规则处置 |
| **§4.1 判定根因为模型 / 上下文 / 数据 / 预期** | 扩写提示词救不回来 | 给对应建议（换模型、精简前置、补数据、对齐预期） |

---

## 3. 核心原则（冲突时优先级从上到下；🔴 为硬红线，任何步骤不得违反）

| # | 原则 | 含义 | 违反后果 |
|---|------|------|---------|
| **🔴 1** | **只补形式，不造事实** | 结构、格式、字段"名"、体裁、篇幅可以补；**数据来源、文件名、具体数值、业务规则、人名机构、时间范围、口径定义一律不补** | 假事实 → 投喂下游 AI → 产出看似专业实则虚构 → **用户无法察觉** |
| **🔴 2** | **能补则补，不能补则问** | 形式性缺失直接补并标注；事实性缺失列入待确认。**成品内只放 `{待确认：…}`，假设说明写在成品外的「诊断」区**；关键缺失（会导致方向性错误的）**必须先问后做** | 标注混进正文会被一起复制走、污染成品；后置追问对关键缺失几乎无效 |
| 3 | **最小必要增强** | 能改一处解决就不改两处。原句已合格时，**「不改」是正当产出** | 为改而改 = 破坏性修改 |
| 4 | **原意保护** | 不得扭曲用户真实意图，不得注入用户未授权的约束。用户说"简单说两句"，就不要给它加上"必须包含 5 个维度" | 用户要的简洁被注水成八股 |

> 下文（含 `references/` 各文件）提到的「红线 1 / 红线 2」，即本表中带 🔴 的两条。

**为什么红线 1 不能让**：同类做法里常见"为缺失的关键信息提供**合理的**补充"——**"合理"恰恰是最危险的修饰词：编得越合理，越不会被发现。** 详见 `references/information-policy.md` §1。

---

## 4. 判断标准（先判断，再动手——本技能的核心竞争力都在这一节）

> 本节的表是**速查版**；需要展开的判据、边界案例与文案，见各 `references/` 文件（**冲突时以 references 为准**）。

### 4.1 判断一：这件事该由提示词来修吗？（Step 0 归因）

用户说"输出不好"时，根因至少有五类，**只有第一类值得增强提示词**：

| # | 可能根因 | 有效？ | 判断信号 | 应给的建议 |
|---|---------|:---:|---------|-----------|
| **1** | **提示词要素缺失** | ✅ | 说不清要什么形态、缺字段、缺约束 | 进入 Step 1 |
| 2 | 模型能力不匹配 | ❌ | 需长链推理 / 大上下文，却用了轻量模型；换强模型立刻变好 | 更换模型，任务按能力分层 |
| 3 | **上下文过长稀释指令** | ⚠️ 解法是**精简** | 会话很长、关键指令被埋在中段、"忘了"前面说过的 | **精简与前置**：关键约束挪到会话首条或末段重申 |
| 4 | 缺必要工具 / 数据 | ❌ | 模型根本拿不到所需信息 | 补数据源或工具，而不是把要求写得更狠 |
| 5 | 用户预期本身不合理 | ❌ | 要求超出模型或数据能力 | 对齐预期，拆小任务 |

命中 **2–5** → **如实告知根因 + 给出建议 + 不产出增强稿**。信息不足以判断时，**最多问 2 个问题**再定，不要硬接。

> 第 3 类最易误判：用户抱怨"输出变差了"，本能反应是"再加点要求"，而实际解法往往是**减掉一半**。

### 4.2 判断二：缺的是关键项还是次要项？（决定先问还是先做）

| 性质 | 判据 | 处置 |
|------|------|------|
| **关键缺失** | 会导致成品**方向性错误**——做错对象 / 做错结论 / 给错人看 | **先问后做**：只问最关键的 1–3 项，拿到答复再产出 |
| **次要缺失** | 只影响呈现细节（篇幅、语气、格式偏好） | **先产出后追问**：给完整草稿，末尾列待确认 |

**关键缺失的 5 个典型信号**：① 指代不明（"这些东西 / 这个方案"）② 目标对象未定 ③ 成品去向未定（给谁看、支持什么决定）④ 强制约束场景（合规 / 财务 / 医疗）下验收标准完全缺失 ⑤ 口径歧义（"环比"是与上月还是上季度、"活跃用户"是日活还是月活）。

> **为什么必须先问**：用户拿到一份看似完整的成品后，多数人不会再回头补答——**后置追问对关键缺失几乎无效**。

### 4.3 判断三：改多少？（力度三档）

| 力度 | 触发条件 | 做法 |
|------|---------|------|
| **轻改** | 仅缺 1–2 项 | 保留原措辞，只补缺口，并明确告知"其余部分未改动" |
| **中改** | 缺 3–4 项 | 在原文基础上补段落，**不重写已有内容** |
| **重构** | 缺 5 项以上，或原句结构混乱 | 才走完整七段式 |

### 4.4 判断四：什么算合格？（正向合格门槛）

七要素每一要素都有**可判定的门槛**，不凭直觉：

| # | 要素（诊断用） | 合格门槛 |
|---|--------------|---------|
| 1 | 目标 | 含明确动词 + 明确对象 |
| 2 | 背景与用途 | 能回答"谁、在什么场合、用来支持什么决定"（**「用途」必须以独立子句显式出现**） |
| 3 | 输入 | 指明具体来源（文件 / 粘贴内容 / 接口）与获取方式 |
| 4 | 流程 | **按任务性质分级，见下方两档** |
| 5 | 输出形式 | 指明体裁 + 结构（表格 / 报告 / 代码 / 清单） |
| 6 | 必含字段 | 逐项可枚举、可勾选核对 |
| 7 | 验收标准 | 含 ≥1 条可客观核对的判据 |

> 「**约束**」（过程红线，如"不得估算"）与「**验收标准**」（事后判据，如"结论不超过 5 条"）是**两件事**：前者属可选增强项，后者才是七要素之一。混为一谈会让"不得做 X"被误当成验收条件。

**「流程」要素按任务性质分两档**（对同类"从结果说起，不从步骤说起"主张的采纳与修正）：

| 任务性质 | 判定信号 | 门槛 |
|---------|---------|------|
| **可复现型** | 数据分析、代码修复、批量处理、报表生成、有明确口径的计算 | **要求 ≥2 步可顺序执行的动词短句**（默认档） |
| **开放型** | 研究、写作、创意、方案构思、头脑风暴 | **不指定过程**，改为给**判据**；成品写：`过程不限定，你自行选择路径。必须满足：<判据1>；<判据2>。` |

> **不要两档都不给。** 开放型既不定步骤也不给判据 = 完全放手 = 产出不可控。"留空间"和"没约束"是两回事。
> 完整对照表（含每要素的"缺失时典型表现"与「七要素 ↔ 七段式」映射）见 `references/elements.md`。

### 4.5 判断五：交付前自检（四维评分卡，100 分制）

| 维度 | 权重 | 满分标准 | 扣分项 |
|------|:---:|---------|-------|
| **A 要素齐全度** | 30 | 七要素全部达到 §4.4 门槛，可选增强项按任务类型已取舍 | 每个未达门槛的要素 −5；「用途」子句缺失 −5 |
| **B 事实性假设数** | 30 | **= 0**。所有具体值都能溯源到"用户本次消息 / 本次附件 / 同会话已确认" | **每出现 1 个未经授权的具体值 −15** |
| **C 占位符一致性** | 20 | 「待确认」清单与成品内占位符**一一对应**，语法统一 | 数量不等 −10；语法不统一 −5；事实性缺失未留占位 −10 |
| **D 可复制性** | 20 | 成品可整段复制直接使用：无内部标注污染、段落标题完整 | 假设标注混进成品 −10；整段被省略 −5；篇幅超上限未说明 −5 |

**评级**：90–100 优秀直接交付｜80–89 良好｜70–79 修完 C/D 扣分项再交付｜60–69 回 Step 2–3 重做｜**0–59 不得交付**。

> **B 维是一票否决**：其他三维再高，只要出现未经授权的事实性信息就不合格。出现 **2 个**具体值即跌破及格线。
> 评分卡完整版、对抗性自检清单（歧义 / 边界盲区 / 逻辑冲突 / 指令打架 / no-op 检查）、迭代闭环 → `references/iteration.md`。

---

## 5. 约束条件（做的时候不能越的线）

| 类别 | 约束 |
|------|------|
| **信息** | 只补形式，事实一律占位。**上下文来源优先级**：① 用户本次消息明确说明 → ② 用户本次提供的附件或粘贴内容 → ③ 同一会话中用户已确认的信息 → ④ 常识默认。**仅形式性信息可来自 ④**；事实性信息不得来自 ④，也不得来自"看起来合理"的推断——这正是造事实的主要来源 |
| **冲突** | 多来源冲突时以**更晚、更明确者**为准，并在诊断区说明取舍 |
| **成品纯净** | 成品内**只放占位符**，不得出现任何批注、假设说明、"注意："字样 |
| **占位符语法** | 需用户回答的写 `{待确认：<需要什么>}`；会随使用变化的值写 `{变量名}`（避免写死，否则换个文件就得重改） |
| **一一对应** | 凡进「待确认」清单的项，成品里必须有对应占位符；反之亦然。**两侧数量对不上即为不合格产出** |
| **敏感信息** | 密钥、客户名单、个人身份信息、内部经营数据不得写入成品，一律占位符替代 |
| **结构完整** | 某段确实无法填写时，写入占位符并**保留该段标题**，不得整段省略（省略会让成品结构不等价，用户无法判断缺了什么） |
| **术语一致** | 只用 `references/elements.md` 那一套叫法（要素名 / 段式名），**不得出现第三套**（如把"输出形式"叫成"输出格式"、"验收标准"叫成"成功判据"） |
| **追问** | **上限 3 项**；能自己判断的绝不问（形式性信息属"该你补的"，不是"该问的"）；每问必须附"**为什么要问**"；**问完就停**，拿到答复立即产出，不追加第二轮 |
| **篇幅** | 默认上限：正文 **500 字以内**（不含段落小标题与空行）；若原句本身已超过 100 字，上限放宽为原句的 5 倍。超限需在诊断区说明理由。**禁止为凑长度稀释成空泛套话**（"请认真分析""确保质量良好"） |
| **语言** | 默认跟随用户输入语言；用户明确指定时从其指定 |
| **成本与缓存** | 固定不变的部分（角色设定、通用约束）**统一前置且保持稳定**；会变的部分（数据、任务细节）放后面——长期批量调用时稳定前缀可命中缓存折扣，同时让提示词更易维护 |
| **展示格式** | 展示模板时**外层围栏用四反引号**，以免与内层三反引号冲突导致渲染断裂 |

---

## 6. 操作步骤（Step 0 → Step 4）

### Step 0 · 归因诊断：这件事该由提示词来修吗？
按 §4.1 五类根因表判定。**只有第 1 类进入 Step 1**；命中 2–5 类 → 给建议、**不产出增强稿**。

### Step 1 · 分类：类型、力度、成熟度、位置
- **① 提示词类型**：**一次性任务提示词**（用完即弃）→ 按七段式补齐即可；**长期复用的系统提示词 / 人设** → 额外要求：模块化分节、避免规则相互冲突、标明本次变更的影响；**所有会变化的值一律用占位符**。
- **② 增强力度**：见 §4.3 三档。
- **③ 使用者成熟度**：零基础用户 → 给可直接替换的填空式成品，少讲原理；熟练用户 → 给诊断 + 最小改动建议，不代其重写。
- **④ 拟放位置**：系统位 / 会话首条 / 每轮追加。长会话中前期指令会被稀释，若知道位置，可建议把关键约束前置。

### Step 2 · 诊断：逐项过七要素
读 `references/elements.md`，对照「七要素 ↔ 七段式」表**逐项**判定：**已具备 / 模糊 / 缺失**。
判定必须能指向原文片段（如"原句未提输出形式"），**不得笼统说"信息不足"**；合格与否按表中「合格门槛」列裁定，不凭直觉。
同时按 §4.2 识别**关键缺失**，决定先问还是先做。

### Step 3 · 补齐：补什么、问什么
读 `references/information-policy.md`。四条要点：
1. **信息性质分类**：形式性信息（段落结构与标题、体裁、格式、字段"名"、语言、篇幅、编号方式、表格列名）**可以补**，并在**成品外**的诊断区标注 `（按常规假设）`；事实性信息（数据来源、文件名、具体数值、业务规则、人名机构、时间范围、口径定义）**绝对不补**，一律转「待确认」并在成品对应位置留占位符。
2. **上下文来源优先级**：见 §5「信息」行。
3. **多来源冲突**：以更晚、更明确者为准，并在诊断区说明取舍。
4. **敏感信息**不得写入成品，一律用占位符替代。

**替代手法优先（强烈推荐）**：某个事实性信息取不到时，与其留一个空占位符，不如把提示词改成 **"先读取并报告实际值，不要假定"**——比占位符更可用，且零风险。

写约束 / 边界句时，取用 `assets/edge-phrases.md` 的句式库：**按风险挑 1–2 条即可，堆 10 条会让提示词互相打架。**

### Step 4 · 组装并输出
按 §8 契约固定成节 → 按 §4.5 四维自检 → 交付。语言、篇幅、成本与缓存约束见 §5。

**可选能力**（若所在 agent 支持则用，不支持直接跳过，**不影响主流程**）：

| 能力 | 用在哪 | 怎么用 |
|------|-------|-------|
| 读文件 / 搜索代码库 | Step 3 | 提示词自指"这个项目 / 这个文件 / 我们的 API"时，**实际读取**获取真实字段名与技术栈，用它替换占位符；诊断区标"**从上下文取得（非假设）**" |
| 联网检索 | Step 3 | 提示词依赖最新信息（API 版本、当年政策）时检索，并保留出处 |
| 子代理并行派发 | Step 3 | 需同时"读代码 + 查资料"时并行发出，互不可见 |
| 写入文件 | Step 4 | **仅当用户明确要求落盘时才写** |

> 这些能力只是**手段**，不改变红线：**取不到真实值就留 `{待确认：…}`，不得凭记忆填写。**

---

## 7. 输入 → 输出处理流程

### 7.1 全景流程（四个出口，只有一个是常态产出）

```
输入（用户消息）
   │
   ├─ 是提示词吗？────────────── 否 ──→ 退出，按普通任务 / §2.2 替代动作处理
   │  是
   ▼
Step 0 归因诊断（§4.1）
   │
   ├─ 根因 2–5（模型 / 上下文 / 数据 / 预期）──→ 【出口 ②】给根因与建议，不产出
   │  根因 1（要素缺失）
   ▼
Step 2 逐项诊断七要素（§4.4）+ 关键缺失识别（§4.2）
   │
   ├─ 命中关键缺失 ────────────────────────→ 【出口 ③】只发追问 1–3 项，不产出
   ├─ 原句已全部达门槛 ────────────────────→ 【出口 ④】如实告知"无需修改"
   │  存在缺口且非关键
   ▼
Step 1 判力度（轻改 / 中改 / 重构，§4.3）
   │
   ▼
Step 3 补齐（形式性 → 直接补并标注；事实性 → {待确认：…}）
   │
   ▼
Step 4 组装 → §4.5 四维自检（B 维必须 = 0）→ 交付
   │
   ▼
【出口 ①】五节完整产出 ← 常态出口
```

**②③④ 都不套用输出契约——这是规范内的正当产出，不是偷懒。**

### 7.2 输入什么 → 输出什么

| | 内容 |
|---|---|
| **输入** | 一句粗略需求 / 一段已有提示词 / 一句"输出不对"的抱怨；可附带上下文材料、指定语言、指定用途 |
| **输出** | 五节固定契约（§8）：**原始提示词（逐字保留）→ 诊断 → 增强后提示词 → 待确认 → 修改前后对比** |
| **输出通道** | 默认直接在对话中给出；**仅当用户明确要求落盘时才写文件** |
| **不产出** | 命中出口 ②③④ 时不套模板：② 给根因与建议　③ 只发追问　④ 如实告知已合格 |

### 7.3 从「已具备 / 模糊 / 缺失」到成品段的映射

| 诊断结果 | 成品里怎么落 |
|---------|------------|
| **已具备** | 保留原措辞，**不重写** |
| **模糊** | 补成可判定的表述，并在诊断区标"已按常规假设补全（仅形式性）"，或转为占位符 |
| **缺失 · 形式性** | 直接补 + 标"（按常规假设）" |
| **缺失 · 事实性** | 成品内写 `{待确认：…}`，**并保留该段标题** |
| **从上下文取得** | 用真实值，诊断区标"**从上下文取得（非假设）**"——与"假设补全"**分开写**，两类可信度不同 |

---

## 8. 输出契约（五节，固定结构）

展示时外层围栏用**四反引号**，以免与内层三反引号冲突：

````markdown
### 原始提示词
> （用户原句，逐字保留）

### 诊断
- 增强力度：轻改 / 中改 / 重构
- 已具备：xxx、xxx
- 模糊：xxx
- 缺失：xxx
- 从上下文取得（非假设）：xxx
- 已按常规假设补全（仅形式性）：xxx
- 建议添加的可选增强项：xxx（如有）
- 关键缺失判定：未命中 / 命中（命中则先追问，不产出以下内容）

### 增强后提示词
```
（完整成品，可直接复制。事实性缺失处用 {待确认：…} 占位）
```

### 待确认
1. {待确认：……} —— 为什么需要它
2. ……

### 修改前后对比
| 维度 | 修改前 | 修改后 | 为什么这样改 |
|------|--------|--------|------------|
| 输出形式 | （原句未提） | Markdown 报告 + 明确数量 | 原句无法约束产出形态 |

（「维度」列取值为七要素名称，不得自由新增维度）
````

### 分支处理（不套模板的情形）

| 情形 | 产出形态 |
|------|---------|
| 无待确认项 | 「待确认」段写"无" |
| 无实质可改（原句已合格） | **不套模板**，如实告知已具备七要素，问是否微调 |
| Step 0 判定为非提示词问题 | **不套模板**，给对应建议 |
| 命中关键缺失 | **只发追问（1–3 项）**，不产出成品 |
| 命中 §2.2 When NOT to Use | 退出流程，按表中「替代动作」处理 |

---

## 9. 典型示例

> 三个示例分别对应 §2.1 的三个入口；**完整原文（含五节全貌）见 `references/examples.md`**。

### 9.1 入口 A · 极短句 + 上下文有材料 → 重构

**输入**：`帮我分析一下这些数据`（上一条消息已附数据文件）

**诊断**：力度 = **重构**（七要素中仅"目标"部分具备）；已具备 = 目标（过于笼统）；缺失 = 「用途 / 读者」、输出形式、必含字段、验收标准；从上下文取得（非假设）= 输入材料 = 用户本次消息所附文件；关键缺失判定 = **未命中**（材料可从上下文取得，「用途」缺失属次要）→ **先产出后追问**。

**增强后成品（骨架摘录，正式产出必须是五节齐全、逐段可复制的完整文本）**：

```
# 目标定位   对用户本次提供的数据做结构化分析，产出可用于决策的结论。
# 背景场景   用途：{待确认：这份分析要支持什么决策？}
             读者：{待确认：给谁看（决定术语密度与结论前置策略）？}
             时间范围与指标口径：{待确认：数据覆盖的时间范围，以及核心指标的口径定义}
# 输入材料   使用用户本次消息所附文件；读取后先报告实际字段名与行数，不要假定字段构成。
# 处理流程   1 读取并报告：实际字段名、行数、缺失值分布
             2 清洗：剔除关键字段为空或明显异常的行，记录剔除条数与原因
             3 汇总：按 {待确认：分组维度（如门店 / 品类 / 月份）} 统计核心指标
             4 对比：找出上升最快与下降最明显的各 3 项
             5 归因：对异常波动给出可能原因，并标注"推测"
# 输出形式   Markdown 报告：按分组维度分节的表格 + 结论要点（数量由实际发现决定，不凑数）
# 必含字段   字段名清单、行数、分组维度、核心指标、变化幅度、异常标记、归因说明
# 验收标准   所有数字必须由所附数据计算得出，不得估算或引用记忆；无法由数据支撑的判断
             必须显式标注"数据不支持"；每条结论不超过 2 句话。
```

**待确认**：4 项（用途 / 读者 / 分组维度 / 时间范围与口径）——**每一项都对应成品里一个占位符，两侧数量必须相等**。

### 9.2 入口 B · 已有提示词 → 轻改（增量修补）

**输入**：`你是一个客服助手，负责回答用户关于订单的问题。要礼貌、专业。` + 用户诉求"帮我改稳一点，它老是瞎编订单状态"

**诊断**：力度 = **轻改**（七要素基本具备，仅缺 1 项）；缺失 = **约束 / 禁止项**——"瞎编订单状态"的根因是**缺负面约束**，不是缺正面指令。

**产出**：**原文一字不动**，只在末尾追加一节：

```
【约束】回答中涉及的订单状态、物流节点、金额与时间，只能来自系统实际查询结果。
查询不到或字段为空时，如实回复"系统暂未显示该项信息"，不得猜测，不得用经验值代替。
禁止承诺未在系统中确认的赔付、时效或补偿。
```

**待确认**：无。**对比表**只两行——约束 / 禁止项（无 → 3 条禁止项）；其余各项（保留原措辞 → 未改动）。

### 9.3 入口 C · 抱怨型输入 → 先归因，**不产出**（出口 ②）

**输入**：`AI 写的周报总是很水，帮我优化一下提示词`

**产出**：命中 Step 0 分支 → **不套用输出契约**。给出：① 诊断结论（暂不能判定为提示词问题，故本次不进入增强流程）② 待区分的可能根因（要素缺失 / 上下文不足 / 预期不合理）③ **需要补充的 3 件事**（现在用的提示词原文 / 本周工作记录是否提供给了 AI / "不水"具体指什么）。

> **三个示例的共同点**：都**先判断再动手**，且**没有一个编造事实**。
> **三个示例的入口、力度、出口各不相同**——用来证明"探索空间"是设计好的，不是随意发挥。
> 示例合规性对照表（哪个完整套用契约、哪个命中分支）见 `references/examples.md` 末尾。

---

## 10. 模块与文件地图

```
prompt-enhance/
├── SKILL.md                        # 入口·常驻：目标 + 场景 + 原则 + 判断标准 + 步骤 + 流程 + 契约
├── references/                     # 按需加载：被本文件的 pointer 指向才读
│   ├── elements.md                 # 七要素↔七段式对照表 + 合格门槛 + 四可选增强项 + 流程要素分性质
│   ├── diagnosis.md                # 五类根因详表 + 关键/次要缺失判据 + 追问文案规范 + 正反例
│   ├── information-policy.md       # 信息性质红线 + 上下文提取规则 + 占位符规范 + 常见错误对照
│   ├── examples.md                 # 三个完整示例（重构 / 轻改 / 归因不产出）
│   └── iteration.md                # 四维评分卡 + 对抗自检 + 迭代闭环 + 版本留档 + 成本缓存
├── assets/
│   └── edge-phrases.md             # 13 条边界句式库 + 四类场景模板（日常/交付/代码/Agent）
├── scripts/
│   └── check_output.py             # 零依赖机械自检
└── evals.json                      # 触发测试 8+6 例 + 14 条行为断言
```

**依赖是单向的、无环的**：

```
归因 ──→ 分类 ──→ 要素诊断 ──→ 补齐 ──→ 组装输出 ──→ 自检 / 迭代
                      ↑                      ↑
                 examples（旁证）      assets 句式库（素材）
```

### 按需加载表

| 文件 | 何时读 |
|------|-------|
| `references/elements.md` | Step 2 诊断、Step 4 组装时 |
| `references/diagnosis.md` | Step 0 归因、Step 2 判定缺失性质时 |
| `references/information-policy.md` | Step 3 补齐时 |
| `references/examples.md` | 需要一个完整样例时 |
| `references/iteration.md` | 产出之后：评分、对抗自检、迭代与留档 |
| `assets/edge-phrases.md` | Step 3 撰写约束 / 边界句时取用 |
| `scripts/check_output.py` | 交付前机械自检 |
| `evals.json` | 修改本技能后的回归测试 |

**机械自检用法**（零依赖，脚本位于本 skill 的 `scripts/` 下）：

```
python scripts/check_output.py <产出文件>        # 只查第一个产出块
python scripts/check_output.py <产出文件> --all  # 查全部产出块
```

> 校验对象是**完整产出**（含四反引号包裹的 §8 五节结构）。若手上只有一段裸提示词、没有五节外壳，本项自动跳过——此时用 §4.5 的四维评分卡人工核对。

---

## 11. 常见错误速查

> 完整版（含"正确做法"逐条对照）见 `references/iteration.md` §6。

| ❌ 最常犯的错 | ✅ 正确做法 |
|---|---|
| **把事实性信息当"可推断"补进成品** | 一律用 `{待确认：…}` 占位（**本技能最易犯、后果最重的错**） |
| 假设标注写进成品内部 | 成品内只放占位符；假设说明写在成品外的「诊断」区，并与待确认项一一对应 |
| 用户没关键缺失也停工反问 | 形式性缺失直接补并标注；**只有关键缺失才先问后做** |
| 追问超过 3 项、或追问形式性信息 | 上限 3 项，且每问附"为什么要问"；能自己判断的绝不问 |
| 为改而改，原句已合格仍强行重写 | 如实告知"无需修改"，或只做最小必要增强 |
| 只给抽象原则，不给可直接复制的成品 | 必须给完整成品 |
| 扩写成又长又空的套话 | 每段都要有具体信息；控制在下限内，超限须说明理由 |
| 用三反引号嵌套展示模板 | 外层用四反引号，避免提前闭合 |
| **示例不遵守自己定的输出契约** | 除命中分支处理的情形外，示例必须完整给出全部成节，并注明为何命中分支 |
| 规则与示例的量化阈值不一致（规则写 400 字、示例 501 字） | **规则与示例必须量化对账**——阈值类的规则，逐条比对自己的示例 |
| 术语漂移（"输出形式"/"输出格式"混用） | 只用 `elements.md` 那一套叫法 |
| 只做一次性增强，不留迭代回路 | 说明如何验证效果、如何增量修补、如何在用户侧留档 |