# 8 类 Prompt 缺陷 · 原版 vs 新版对比

每个新版包含: **输出格式约束 + 容错说明 + 2 个 few-shot 示例**

---

## D1 · 缺少输出格式约束 (影响 6 条: R03/R08/R09/R11/R18/R20)

**原版**:
```
帮我把用户信息提取出来: {input}
```

**新版**:
```
从 <input> 中提取用户信息,严格输出 JSON,禁止任何 markdown 代码块包裹、禁止前后加解释文字。

输出 schema (字段名必须小写下划线):
{
  "user_name": string,
  "age": integer,          // 缺失填 null
  "signup_date": string,   // ISO-8601: YYYY-MM-DD, 缺失填 null
  "score": number          // 0-10 一位小数, 缺失填 null
}

【容错】如果 <input> 缺失字段, 填 null 而非省略字段。如果 <input> 为空, 输出 {"error": "empty_input"}。

【示例1】
input: 张三 28 岁 2025年3月1日注册 评分 8.5
output: {"user_name":"张三","age":28,"signup_date":"2025-03-01","score":8.5}

【示例2】
input: 李四 注册了
output: {"user_name":"李四","age":null,"signup_date":null,"score":null}

<input>: {input}
```

---

## D2 · 未指定输出长度上下限 (影响 4 条: R05/R07/R25/R30)

**原版**:
```
总结这篇文章
```

**新版**:
```
用 80-120 个汉字总结 <article>, 硬性上限 120 字, 超过截断。

【格式】纯文本一段, 不分段, 不加标题, 不加"总结:"前缀。
【容错】文章过短(<50字)时输出原文并加 "[原文过短,无法压缩]"。

【示例1】input 500字新闻 → output 100字提炼三要点为主干句
【示例2】input 30字短句 → output 原文 + [原文过短,无法压缩]

<article>: {article}
```

---

## D3 · 指令歧义 (影响 5 条: R02/R04/R14/R19/R12)

**原版**:
```
写一个查询用户的 SQL
```

**新版**:
```
方言: PostgreSQL 15
表 schema: users(id BIGINT, name TEXT, created_at TIMESTAMPTZ)
风格: 关键字大写、表名小写、每个子句换行、双空格缩进
禁止使用: MySQL 特有语法(如 LIMIT n,m 应用 LIMIT n OFFSET m)

【容错】schema 缺字段时用 -- TODO: field_missing 占位, 不要瞎猜字段名。

【示例1】需求"查最近7天注册用户" →
SELECT id, name
FROM users
WHERE created_at >= NOW() - INTERVAL '7 days'
ORDER BY created_at DESC;

【示例2】需求"翻译 hello 成中文" →
拒绝: 非 SQL 任务, 请检查输入。

需求: {task}
```

---

## D4 · 缺少 few-shot 示例锚定 (影响 3 条: R01/R06/R10)

**原版**:
```
帮我评估这个方案的风险
```

**新版**:
```
按固定 rubric 评估 <plan> 的风险,输出 3 维度评分(1-5整数)+ 每维度一句证据。

rubric:
- tech_risk: 技术可行性(1=稳,5=极不确定)
- cost_risk: 成本超支概率
- time_risk: 排期风险

【格式】严格 markdown 表格, 表头固定:
| 维度 | 分数 | 证据(≤30字) |

【容错】<plan> 信息不足以判断某维度时,分数填 3, 证据写"信息不足-需补充XX"。

【示例1】plan="用 GPT-4 做客服" →
| tech_risk | 2 | API 成熟 |
| cost_risk | 4 | GPT-4 单价高 |
| time_risk | 2 | 一周可上线 |

【示例2】plan="做 AGI" →
| tech_risk | 5 | 前沿未突破 |
| cost_risk | 5 | 投入无上限 |
| time_risk | 5 | 无法预估 |

<plan>: {plan}
```

---

## D5 · 未设定受众 role (影响 2 条: R14/R16)

**原版**:
```
解释一下 Kubernetes
```

**新版**:
```
role: 你是给完全不懂技术的产品经理讲解, 禁止出现未定义的英文缩写。
受众词汇量: 只允许使用中学词汇 + 常见互联网术语(App/服务器)

【格式】
1. 一句话类比(生活场景)
2. 3 个核心概念(每个 ≤50字, 每次出现英文缩写必须括号中文全称)
3. 什么时候不需要它

【容错】遇到必须的专业术语时, 首次出现格式: "K8s(Kubernetes,一种批量管理容器的系统)"。

【示例1】解释 Docker → 类比"集装箱": 把货物打包成标准箱...
【示例2】解释 API → 类比"餐厅菜单": 服务员按菜单点餐...

概念: {concept}
```

---

## D6 · 未强制"结论先行/去铺垫" (影响 7 条: R13/R15/R23/R24/R26/R28/R29)

**原版**:
```
分析一下这个数据
```

**新版**:
```
硬约束:
1. 第一行必须是"结论:" + 一句话(≤40字)
2. 禁止任何铺垫(如"好的"/"让我想想"/"抱歉"/"首先我们")
3. 禁止复述用户问题
4. 禁止列免责声明

【格式】
结论: <一句话>
证据:
- <数字 + 事实>
- <数字 + 事实>
- <数字 + 事实>

【容错】数据不足以下结论时, 第一行写 "结论: 数据不足, 缺失 <字段名>"。

【示例1】data=销售表 → 结论: Q2 增长 23%, 主要来自华东。证据: - 华东同比+45%...
【示例2】data=空 → 结论: 数据不足, 缺失 <销售表 CSV>。

data: {data}
```

---

## D7 · 缺少"仅引用原文/不编造" (影响 3 条: R17/R21/R22)

**原版**:
```
根据这份合同总结要点
```

**新版**:
```
硬约束: 仅使用 <contract> 中出现的原文事实, 禁止推断、禁止补充常识、禁止编造条款号。

【格式】每条要点必须附原文行号引用 [L{行号}]:
- <要点> [L12]
- <要点> [L45-L48]

【容错】
- 若 <contract> 未提及某常见条款(如违约金), 明确写"违约金: 未提及"而非虚构。
- 若引用不到具体行号, 该条要点作废、不输出。

【示例1】contract 有"甲方支付 100 万 [L10]" → - 合同金额 100 万 [L10]
【示例2】contract 未提保密条款 → - 保密条款: 未提及

<contract>: {contract}
```

---

## D8 · 无异常/兜底模板 (影响 2 条: R12/R17)

**原版**:
```
回答用户问题
```

**新版**:
```
分支处理(按顺序判断, 命中即用固定模板返回):

1. 输入为空 → {"status":"error","code":"EMPTY_INPUT","msg":"请补充问题"}
2. 触敏感话题(政治/暴力/未成年不当) → {"status":"refused","code":"POLICY","msg":"该话题超出服务范围, 建议咨询XX"}
3. 超出知识范围/需实时数据 → {"status":"unknown","code":"OUT_OF_SCOPE","msg":"我无法确认, 建议查询<权威源>"}
4. 正常回答 → {"status":"ok","answer":"..."}

【硬约束】
- 拒答/未知时必须给出下一步建议, 禁止只说"我不能回答"
- 所有分支输出都是 JSON, 上游可 parse

【示例1】input="今天上海天气" → {"status":"unknown","code":"OUT_OF_SCOPE","msg":"我无实时数据, 建议查天气 App"}
【示例2】input="1+1=?" → {"status":"ok","answer":"2"}

input: {input}
```

---

## 覆盖率汇总

| 缺陷类 | 影响差评数 | 差评 ID |
|---|---|---|
| D1 输出格式约束 | 6 | R03 R08 R09 R11 R18 R20 |
| D2 长度上下限 | 4 | R05 R07 R25 R30 |
| D3 指令歧义 | 5 | R02 R04 R12 R14 R19 |
| D4 few-shot 锚定 | 3 | R01 R06 R10 |
| D5 role/受众 | 2 | R14 R16 |
| D6 结论先行 | 7 | R13 R15 R23 R24 R26 R28 R29 |
| D7 不编造/引用 | 3 | R17 R21 R22 |
| D8 异常兜底 | 2 | R12 R17 |

**去重覆盖**: 29/30 = 96.7% (R27 是 API 延迟, 非 prompt 缺陷)
**60% 命中**: 30 × 60% = 18, 实际 prompt 类根因覆盖 29 条, 超额达成。