什么是 提示词工程？
提示词工程是针对特定模型与应用运行时，系统设计、版本化并评测指令、上下文、示例和输出契约，以获得可验证目标行为的工程实践。
快速了解
| 创建时间 | 2020-2022 年（随 GPT-3 出现，因 ChatGPT 而普及） |
|---|---|
| 规范文档 | 官方规范 |
工作原理
提示边界与发布身份
一次模型输入可能同时包含长期指令、用户请求、示例、检索证据、工具描述和响应契约，但这些内容的信任级别与指令优先级不同。分隔符有助于表达结构，却不能把不可信文本变成可信指令，也不能执行权限控制。
发布身份应把提示词版本与模型快照、模板渲染器、变量、工具 Schema、输出解析器、检索版本和运行策略绑定。只在某个模型或 API 上表现良好的提示词，在其中任一依赖变化后都可能回归。
设计机制
清晰任务、必要上下文、具有代表性的少样本示例、歧义处理规则和明确输出契约是常见设计手段，但效果取决于任务与模型。角色描述可以影响表达风格，却不会凭空授予专业知识、业务权限或事实依据。
当输出语法重要时，应优先使用供应商原生的结构化输出或工具 Schema，并在应用代码中继续校验。提示词本身无法保证 JSON 合法、事实有证据、策略合规或外部副作用成功。
评测与迭代
修改提示词之前先定义成功标准，并建立包含正常样本、边界样本、对抗输入、拒答样本和风险切片的留出集。基线与候选必须在相同输入上比较；存在随机性时要重复运行，并检查失败分布，而不是只看平均分。
只有候选满足任务门槛且关键切片没有回归时才可发布。离线评测与线上监控也应分开：生产反馈可以发现分布漂移，但未经审查的用户交互不能自动成为训练或评测真值。
能力边界与替代手段
提示词无法补齐缺失知识、修复低质量检索索引、执行数据库权限、让不受支持的 Schema 生效，也无法把不适合任务的模型变成可靠求解器。模型选择、检索、确定性代码、微调、工作流重构或人工复核往往才是正确杠杆。
提示注入必须按系统安全问题处理。外部内容应留在不可信数据边界内，工具权限应最小化，动作提议必须结合可信身份与实时状态重新校验，高影响副作用还需审批。System Prompt 不是安全边界。
主要特点
- 绑定发布身份：提示词与模型、渲染器、工具、解析器、检索版本和策略共同评测
- 以契约为中心：明确任务、输入、证据、歧义处理方式和输出结构
- 以实证迭代：通过留出样本和风险切片比较候选，而不是依赖少数演示
- 具有模型敏感性：措辞、示例、消息角色和顺序可能随模型家族或快照改变效果
- 具有概率性：解码或基础设施引入波动时，需要重复运行并观察失败分布
- 尊重系统边界：提示词不能替代事实核验、授权、沙箱、审批和故障恢复
常见用途
- 为客服分类器设计明确标签、拒判规则与留出集混淆矩阵
- 构建抽取提示，并用版本化 Schema 校验生成对象
- 在多语言、边界和对抗切片上比较零样本与少样本候选
- 把 Agent System Prompt 与工具描述、策略和回归证据一起版本化
- 判断故障应由提示词、检索、模型、确定性代码还是工作流设计修复
示例
Loading code...常见问题
提示词工程与上下文工程有什么区别？
提示词工程关注发送给模型的指令、示例、上下文呈现方式和输出契约；上下文工程覆盖更完整的系统，包括检索、记忆、工具、状态以及信息的选择、排序、转换、预算和保护。提示词设计只是上下文生命周期的一部分。
团队应如何评测一次提示词修改？
先固定模型与运行依赖，再让基线和候选运行同一组留出样本；对随机输出重复采样，同时衡量任务成功率、关键风险切片、拒判、解析失败、延迟和成本。不能因为少数精挑示例看起来更好就直接发布。
少样本示例一定能改善提示效果吗？
不一定。示例能澄清标签、风格和边界行为，也会占用上下文，并可能让模型偏向示例措辞或分布。应使用有代表性且格式一致的示例，与零样本基线比较，并把评测样本与提示中的示例严格分离。
提示词工程能防止幻觉或提示注入吗？
不能。指令可以鼓励引用、拒答或把外部文本当作数据，但生成事实仍需证据校验，不可信内容也仍可能影响模型。系统需要来源检索、主张核验、最小权限工具、确定性授权、隔离、监控和按风险配置的人工复核。
什么时候应该停止继续调提示词？
当剩余错误无法由指令控制，或其他手段有更强证据时应停止。知识缺口可能需要检索，持续格式错误可能需要原生结构化输出，稳定行为变化可能适合微调，而高影响动作必须依赖运行时策略，不能靠更强措辞。