S19-B01 · 提示词工程的三层结构

适用读者：写过 Prompt，但结果时好时坏、没法复现的人。本系列第一篇。
前置：无（会写 Markdown 即可）。
口径：本篇为方法与结构说明；提示词效果依赖具体模型与版本，不含"提升 X%"这类无法核实的数字。
覆盖旧文：A-707（提示词工程，344 点）。
覆盖扩展：E-S19-003（六单元结构）、E-S19-004（提示词 vs 代码的三个差异）。
下一篇：S19-B02 · 提示词模板与占位符。

1. 一句话结论

提示词不是"一段话"，是"带约束的程序文本"：它描述目标、提供上下文、规定输出形态。写它的方式应该像写代码——分层、可复用、可测试、可版本化。

1.1 提示词与代码的三个差异（E-S19-004）

维度	传统代码	提示词
确定性	相同输入 → 相同输出	相同输入 → 可能不同（采样随机）
调试	断点、日志、栈	回归集 + 评分表（J01）
版本	`git diff` 精确到行	改一个词可能改整体行为 → 要配回归测试（J02）

这三条差异决定了：提示词工程的重心不在"写"，在"验证与维护"。

2. 六单元结构（E-S19-003）

一个生产级 Prompt 通常由六块组成：

单元	作用	必填	缺失后果
Role	角色设定（知识边界、语气）	✅	输出风格漂移
Directive	核心指令（做什么）	✅	模型不知道目标
Context	背景信息（决策依据）	可选	泛泛而谈
Exemplars	Few-shot 示例	可选	格式不稳
Format	输出格式（JSON/表格/字段）	推荐	无法程序化解析
Style	语气、长度、细节度	可选	长短不可控

2.1 一个完整例子

## 角色 (Role)
你是气象专家，熟悉天气数据解读与出行建议。

## 核心指令 (Directive)
根据用户提供的城市，给出天气概况与出行/穿衣建议。

## 背景信息 (Context)
- 当前季节：{{season}}
- 用户地区：{{region}}
- 可用字段：温度、湿度、风力、降水概率

## 输出格式 (Format)
{"city": "...", "weather": "...", "temperature": "...", "advice": "...", "clothing": "..."}

## 风格 (Style)
简洁（≤200 字），语气友好但专业。

为什么必须写 Format：不写格式，输出就是"自然语言散文"，下游程序无法解析。这一条是"能演示"与"能上线"的分界线。

3. 三层：结构层 / 策略层 / 评估层

旧文强调"结构"，这里补上后两层，形成完整闭环：

层	内容	产物
结构层	六单元怎么写	一份 Prompt 文本
策略层	Few-shot 放几个、CoT 要不要、温度设多少	参数与示例配置（J02 §3）
评估层	回归集、评分标准、通过率	改前/改后对比（J01）

判据：只有结构层的 Prompt 是"草稿"；有评估层的才算"资产"。

4. 从"随手版"到"六单元版"的对照

随手版	六单元版	改善点
"帮我看看这个天气"	Role + Directive + Context + Format + Style	输出可解析、语气稳定
"写个总结"	Directive 明确"面向谁/多长/要点几个"	不再每次长度各异
"改一下这段代码"	Context 给"语言/版本/约束"，Format 给"只输出 diff"	可直接应用

判据："这段 Prompt 换个人来用，结果会一样吗？" 不会 → 缺单元。

5. 五个误区

误区	真相
"提示词越长越好"	长不等于清楚；冗余上下文会稀释指令
"写了 Role 就够"	没有 Format，输出无法程序化使用
"Few-shot 越多越好"	示例多会推高成本与延迟，且可能引入偏差
"Prompt 一次写好就完了"	模型/需求变化后必须回归测试
"效果提升 30%–50%"	这类数字依赖模型与任务，不可直接引用（本文不采用）

6. 自检

六单元里哪两个是"必填"？缺了会怎样？
为什么 Format 是"能上线"的关键？
提示词与代码的三个差异分别对应什么工程手段？
"随手版"和"六单元版"最本质的区别是什么？
为什么本文不写"提升 X%"？

7. 下一篇

S19-B02 · 提示词模板与占位符

结构定好之后，下一篇解决"复用"：把 Role/任务/数据/输出要求做成模板，用占位符注入——并演示占位符注入带来的安全问题（实测）。

本篇属于系列《S19 · AI 素养与学习方法》。旧文来源：A-707；扩展点 E-S19-003/004。提示词效果依赖模型版本，本文只给结构与方法，不给无法核实的百分比。