Prompt Enhance

Prompt Enhance · 提示词增强

0. 一句话总览

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

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

四条铁律（一句话版）

只补形式不造事实 · 成品内只放占位符 · 关键缺失先问后做 · 该不改时就不改。

30 秒上手（只记四步）

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

1. 增强的目标

1.1 要达成什么

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

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

1.3 什么算成功

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

2. 适用场景

2.1 该用：三个触发入口

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 支持则用，不支持直接跳过，不影响主流程）：

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

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 输入什么 → 输出什么

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

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

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

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

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

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

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

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

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

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

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 句式库（素材）

按需加载表

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

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

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

11. 常见错误速查

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