ℹ️ 读者
我会写"你是顶级专家"，这算 Prompt 工程吗？
ℹ️ 作者
这是起步。真正的 Prompt 工程，是把模糊要求写成模型能执行、你也能验收的任务规格。
这篇内容讲五件事：Prompt 工程是什么、如何写出稳定骨架、怎样用案例验证、如何团队化，以及它和其他 AI 工程如何分工。
一、先建立正确直觉
1.1. Prompt 工程是什么
Prompt Engineering（提示词工程）不是寻找"万能咒语"，而是设计模型完成任务时应看到的目标、资料、规则、示例和输出格式，并用测试持续改进。
bash
Prompt 工程 = 任务规格设计 + 样本验证 + 持续迭代临时聊天只追求一次满意；工程追求可重复交付。它不保证模型永远正确，也不能替代 RAG、规则校验、权限控制或人工审核。
1.2. 为什么"顶级专家"不够
bash
你是资深客服专家，请分析下面的用户反馈。这句没有说清分类标准、信息不足时怎么办、最终输出给谁使用。模型只能猜。
更可执行的规格是：
bash
任务：将用户反馈归为"功能缺陷、使用疑问、功能建议、其他"之一。
规则：只依据反馈；证据不足时输出"其他"，不要猜测产品事实。
输出：仅输出 JSON，字段为 category、priority、reason。角色决定语气；任务、边界与输出契约决定交付质量。
二、搭出可复用的 Prompt 骨架
2.1. 五块内容就够了
| 区块 | 要交代什么 | 缺失后的症状 |
|---|---|---|
| 目标 | 对谁做什么，什么算完成 | 跑题、答案空泛 |
| 资料 | 能依据哪些文本或事实 | 补造事实 |
| 规则 | 范围、优先级、未知时的动作 | 边界输入乱判 |
| 示例 | 合格输入与输出长什么样 | 口径、格式不稳定 |
| 输出契约 | 字段、类型、长度、禁止项 | 下游无法解析 |
bash
## 目标
完成：{任务}；完成标准：{验收条件}。
## 输入资料
只依据下方资料，不要补充未提供的事实：
{资料}
## 规则
1. {规则一}
2. {规则二}
3. 信息不足时：{明确动作}
## 输出格式
仅输出 {JSON/表格/列表}；字段为：{字段定义}。
Prompt 任务规格信息流
2.2. 分隔指令与数据，输出写成契约
用 Markdown 标题、三引号或 XML 标签把规则和待处理内容隔开；项目里保持一致即可。外部文本中即便出现"忽略以上指令"，也只能当作数据处理，不应覆盖你的任务规则。
如果结果给程序消费，别写"尽量 JSON"，而要写明允许值和字段：
bash
{
"category": "功能缺陷 | 使用疑问 | 功能建议 | 其他",
"priority": "P0 | P1 | P2 | P3",
"reason": "不超过 40 字，说明判断依据"
}Prompt 提高格式命中率；程序端仍需 JSON 解析、Schema 校验和失败处理。高风险业务还必须有权限边界与人工升级路径。
三、跟着案例跑一遍
3.1. 先建样本集，再改 Prompt
以"用户反馈分类"为例，先准备 20 条脱敏反馈，并人工标注类别和优先级。样本必须包含：明确 Bug、使用疑问、功能建议、信息不足和混合诉求。
例如：
付款成功但订单还是待支付。在哪里能导出月报？希望能按项目筛选通知。不好用，快修。导出失败，而且希望支持 CSV。
这些人工标注就是你的最小真值集。没有它，所谓调优大多只是感觉。
3.2. 从基线版本开始
先写短小、可比较的基线 Prompt：
bash
你是产品反馈分流助手。
目标：把反馈归为功能缺陷、使用疑问、功能建议、其他。
规则：只依据反馈；无法判断或多个类别并存时输出其他。
输入：{{feedback}}
输出：仅输出 JSON：{"category":"...","priority":"...","reason":"..."}跑完全部样本，记录三项：JSON 是否可解析、分类是否正确、理由是否来自输入。
3.3. 一次只改一个变量
| 症状 | 优先改什么 |
|---|---|
| 类别概念混淆 | 补定义或一个反例 |
| JSON 不合法 | 明确 Schema，代码侧校验 |
| 信息不足仍乱判 | 写清输出"其他"的条件 |
| 混合输入不稳 | 先抽取事实，再做分类 |
不要同时改示例、规则、模型和参数。否则结果变了，也不知道真正原因。
3.4. 验证不只看准确率
每版 Prompt 都要检查：格式能否解析、枚举是否合法、优先级是否合规、信息不足时是否承认不确定，以及旧失败样本是否回归。
Prompt 评估迭代闭环
⚠️ 注意
对支付、医疗、法律、人事等高风险场景，模型输出不能直接代替规则、专业审核或最终决定。Prompt 可以用于整理和分流，不能单独承担责任。
四、把 Prompt 变成团队资产
4.1. 版本、样本和标准一起保存
bash
prompts/
├─ feedback-triage-v1.md
├─ feedback-triage-v2.md
└─ evals/
├─ golden-set.jsonl
└─ regression-cases.jsonl每次改动记录修改原因、覆盖的失败样本和预期指标。这样模型、Prompt 或上下文变化时，团队才能追溯行为变化。
4.2. 四个高频坑
- 越写越长。 删除重复人设，把规则改成可执行句。
- 规则冲突。 写清优先级，例如"字段完整优先于字数限制"。
- 只留成功案例。 失败样本才是最有价值的测试资产。
- 所有问题都调 Prompt。 缺资料、缺验证、缺工具或缺执行循环，应切换工程层处理。
五、Prompt 的边界与下一步
5.1. 它和其他 AI 工程如何分工
Prompt 工程回答"这一轮希望模型做什么"；Context 工程回答"这一轮该给模型看什么"；Harness 工程提供工具、约束、测试和可观测性；Loop 工程负责计划、行动、观察、重试和停止。
Prompt 是意图接口，是起点，但不是整套 AI 系统。
5.2. 立即可做的练习
- 选一个你每天交给 AI 的任务。
- 写下目标、资料、规则、输出格式。
- 准备 10-20 条真实样本和期望结果。
- 先跑基线，每轮只改一个变量。
- 把失败样本加入回归集；问题不再是表达不清时，转向检索、校验或 Agent 环境设计。
最后记住：
bash
好的 Prompt，不是让模型显得更聪明；而是让任务更清楚、更可验证、更容易维护。