3.1 Prompt 工程——把要求写成模型能执行的规格

本章导读

本 节 目 标

本 节 目 标能按角色/指令/约束/示例/输出格式五要素把要求写成模型能执行的规格，并在有限窗口里做「选而不是全塞」的上下文取舍；能为一个 Demo 补齐工具接入、输入输出契约、错误处理、护栏门禁与可观测五件套，并为 Agent Loop 设计明确的退出条件与人工关卡；能按「有没有人在场」在 PAT、OAuth 2.1、OAuth 2.0 之间选型，说清令牌的存、轮、撤、审计四件事，并掌握客户现场 MCP 连不上的排查顺序。

你在客户现场跑通了一个 Demo，客户很满意，说"这个能力我们要"。然后你把 Prompt 截图发给他们，让他们自己试。第二天客户反馈："昨天好用，今天它就不这么回答了。"

这个落差，就是"会点 Prompt 的用户"和"能长期交付的 FDE"之间的差别。

一个能长期交付的 FDE，不只是写出一个好 Prompt，而是能把一次成功稳定复现成一套系统。这套系统靠四根支柱加一个安全底座撑起来：

接下来我们一根一根讲。

概念

Prompt 不是"跟模型聊天"，而是给模型写一份规格说明书。你跟人沟通需求都得说清背景、目标、约束，跟模型沟通也一样——只不过模型比人更死板：你少说一个约束，它就按自己的默认值来，而它的默认值往往不是你想要的。

一个常见的坑是：同一个 Prompt，今天模型回答得好，明天就不行了。这不是模型在针对你，而是你的 Prompt 没有覆盖边界条件，模型在不同状态下选择了不同的"默认路径"。

用法

把任意一个需求拆成五个要素，写进 Prompt：

记住口诀：角色定调、指令定事、约束定界、示例定标、格式定形。

🖼 图：Prompt 五要素：角色（定调）· 指令（定事）· 约束（定界）· 示例（定标）· 输出格式（定形）——把任意需求拆成五个要素写进 Prompt，输出的稳定性与可复用性由结构化程度决定。

示例

假设客户场景是：把运维工单自动分类。一个合格的 Prompt 长这样：

# 角色

你是一位资深 IT 运维分类专家，有 10 年工单分拣经验。

# 指令

将用户提交的工单文本归入以下类别之一：

网络故障 / 硬件损坏 / 软件配置 / 权限申请 / 其他

# 约束

- 只能从上述五个类别中选一个，不得自创类别

- 如果信息不足无法判断，输出 "其他" 并在 reason 字段说明原因

- 不得编造工单中未出现的信息

# 示例

输入："打印机连不上，IP 是 192.168.1.50"

输出：{"category": "网络故障", "confidence": 0.9, "reason": "涉及 IP 连接问题"}

输入："帮我开通 ERP 系统的审批权限"

输出：{"category": "权限申请", "confidence": 0.95, "reason": "明确提到权限开通"}

# 输出格式

严格输出以下 JSON，不要包含任何解释文字：

{"category": "<类别>", "confidence": "<0-1的小数>", "reason": "<一句话理由>"}

预期输出：

{"category": "网络故障", "confidence": 0.9, "reason": "涉及 IP 连接问题"}

你看，这个 Prompt 里没有模糊空间：类别是枚举的、输出是 JSON 的、信息不足有兜底路径。这就是"规格"和"聊天"的区别。

**⚠️ 风险提示：**示例的"少样本"（Few-shot）数量不是越多越好。通常 2-3 个高质量示例足够，超过 5 个反而会引入噪声，让模型纠结于示例之间的差异而非模式本身。如果你的示例互相矛盾，模型会"平均"出一个你根本不想要的结果。