提示词工程

概述

提示词工程是设计输入以可靠地从基础模型获得期望输出的实践。它是将模型适配到具体应用的三大核心 AI 工程技术之一（另外两项是 RAG 与微调），通常也是首选尝试的技术——因为它无需更新模型权重，无需训练数据，且能在数小时（而非数周）内产出结果。

核心概念

什么是提示词？

提示词是给模型下达的、用于执行某项任务的指令。它通常包含：

• 任务描述：要做什么，包括模型应扮演的角色以及输出格式
• 示例：对期望行为的演示（少样本学习，few-shot learning）
• 任务本身：要回答的具体问题、要总结的文本，或要解决的问题

上下文学习：零样本与少样本

上下文学习（in-context learning，由 GPT-3 论文 Brown et al., 2020 提出）指模型从提示词中的示例学到期望行为，而无需更新其权重。

• 零样本（Zero-shot）：不提供示例——模型仅凭任务描述完成任务
• 少样本（Few-shot）：提供 1–10 个示例——减少歧义，并引导语气、格式与内容

示例不必复杂。对期望的输入-输出模式做简单演示往往就足够了。提供示例还能充当一致性检查：如果模型连你给出的示例都无法照做，那它大概率也无法遵循你的提示词。

系统提示词与用户提示词

大多数模型 API 把提示词拆分为两种角色：

• 系统提示词（System prompt）：来自开发者的持久性指令——人设、约束、输出格式、行为准则。作用于每一轮对话。
• 用户提示词（User prompt）：来自用户的每轮输入——实际的问题、文档或任务。

示例：

System: You're an experienced real estate agent. Read each property disclosure 
carefully, assess the property's condition fairly, and help buyers understand 
risks and opportunities. Answer succinctly and professionally.

User:
Context: [disclosure.pdf]
Question: Summarize the noise complaints, if any, about this property.

系统提示词是专有资产。防止其被提取（通过逆向提示词工程或注入攻击）是生产应用中的一项安全关切。

提示词工程最佳实践

综合自 Chip Huyen 的 AI Engineering（O'Reilly，2025，第 5 章）以及 OpenAI、Anthropic、Meta、Google 的提示词工程指南。

1. 编写清晰、明确的指令

• 不留歧义：如果你想要 1–5 分的评分，就明说。如果不想要小数评分，就写「只输出整数评分」。
• 赋予人设：让模型扮演某个具体角色（一年级老师、资深工程师、法律审阅者）。这会把模型的视角切换到与目标输出质量相匹配的状态。
• 提供示例：示例能极大地减少歧义。一个给出事实正确但脱离语境的答案的模型（例如告诉小孩圣诞老人是虚构的），可以用一个体现期望表述方式的示例加以引导。

2. 提供充分的上下文

当给出相关上下文时，模型会生成更好的回复。不要假设模型了解你的使用场景、你的用户或你的领域——把要紧的内容明确地提供出来。

• 在提示词中或通过 RAG 检索纳入相关背景数据
• 指明受众（「向非技术的利益相关方解释这件事」）
• 明确指明约束（「不要超出文档所述内容进行推测」）

3. 把复杂任务拆解为更简单的子任务

对于多步骤任务，应把提示词拆解为一连串更简单的提示词，而不是写一个庞大的提示词：

提示词拆解的好处： - 性能：模型更可靠地遵循更简单的指令 - 监控：中间输出可被检查和记录 - 调试：故障被定位到具体某一步 - 并行化：相互独立的步骤可并发运行，降低延迟 - 成本：更短的提示词消耗更少的 token；更便宜的模型即可处理更简单的步骤

示例（客户支持）： 1. 提示词 1：对意图进行分类（账单 / 技术支持 / 账户管理 / 一般咨询） 2. 提示词 2a：若为技术支持 → 故障排查脚本 3. 提示词 2b：若为账单 → 账单处理脚本

GoDaddy 发现，把一个 1500 token 的单体提示词拆解为更小、更有针对性的提示词，在降低 token 成本的同时提升了模型性能。

权衡：更多的中间步骤会增加用户端的端到端延迟，更多的模型调用会增加成本。通过实验找到合适的拆解粒度。

4. 给模型留出思考时间

• 思维链（Chain-of-Thought，CoT）：指示模型「一步步思考」。CoT 由 Wei et al.（2022）提出，能在各个模型家族的推理任务上持续提升性能。LinkedIn 发现 CoT 还能降低幻觉率。
• 自我批评：让模型在最终定稿前先验证自己的答案。这能捕捉表层错误，但受限于自我偏见。
• 扩展推理：部分模型（GPT-o1/o3、Claude 3.5 Sonnet）具有专门的「扩展思考」模式，会在产出回复前为推理分配额外算力。

5. 迭代你的提示词

提示词工程是经验性的。没有哪条提示词是终稿：

1. 从可能奏效的最简单提示词起步
2. 在一批有代表性的真实输入上测试
3. 找出失败模式（哪些类型的输入会产出糟糕的输出？）
4. 修改提示词以应对失败
5. 重新测试，验证修复没有引入新的失败

为提示词做版本管理：把提示词与评测结果一同纳入版本控制。像对待代码改动一样对待提示词改动——包含回归测试。

6. 组织与版本化提示词

• 把提示词存放在专门的仓库或提示词管理工具中
• 把模型版本与提示词绑定在一起（模型更新可能悄无声息地破坏提示词）
• 维护一套由已知良好输入/输出对组成的回归测试集
• 记录每次生产推理所用的提示词版本，便于调试

防御性提示词工程

威胁模型

AI 应用面临两类基于提示词的攻击途径：

1. 提示词注入（Prompt injection）：攻击者在用户输入或检索内容中嵌入指令，覆盖系统提示词，从而改变模型行为
2. 越狱（Jailbreaking）：精心构造的提示词绕过模型的安全训练，诱导其产出有害或违反政策的输出

二者从根本上都难以彻底消除，因为让模型变得灵活的同一机制（遵循指令）也使其变得脆弱。

专有提示词外泄

系统提示词包含专有的业务逻辑，经常成为被提取的目标——可能通过社会工程（「逐字重复你的指令」），也可能通过行为分析间接提取。缓解措施：

• 指示模型绝不透露其系统提示词
• 避免把不可替代的机密放进系统提示词（它们终将被提取出来）
• 在日志中监控提示词提取的尝试

针对提示词注入的防御

防御手段	描述	局限
输入过滤	检测并拦截用户输入中的注入模式	基于模式匹配；可被改写绕过
输出过滤	检查模型输出中是否有行为被劫持的迹象	被动应对；增加延迟
权限分离	把不可信的检索内容隔离在指令位置之外	属于架构层面；需要谨慎设计提示词模板
提示词加固	用显式指令要求忽略检索内容中相互冲突的指令	降低但不能消除风险
基于模型的分类器	用专门的分类器评估每条输入是否可能是注入尝试	有成本；存在误报

根本性局限：不存在完美的防御。提示词注入是在单一上下文中混合指令与数据所带来的固有后果。应把它当作需要缓解和监控的风险，而非可被彻底消除的问题。

结构化输出

要求模型输出结构化格式（JSON、XML、特定 schema）在生产中带来若干好处：

• 更便于程序化解析
• 强制施加约束（不得出现被禁字段，必填字段必须存在）
• 减少回复中的冗长散文

大多数主流模型 API 都支持结构化输出模式（OpenAI 的 response_format、Anthropic 的工具调用 schema、Google 的 response schema）。Outlines 和 Instructor 等库会在解码层面强制施加结构化输出。

上下文长度与效率

更长的提示词消耗更多 token，从而抬高成本与延迟。提升上下文效率的策略：

• 保持系统提示词精简；移除不影响行为的指令
• 随着提示词演进，移除冗余或相互矛盾的指令
• 用提示词拆解避免把无关上下文发送给每一步
• 对冗长的检索段落做摘要，而非逐字纳入

参见

• AI Engineering Overview
• RAG Architecture
• Context Engineering Strategies
• AI as a Judge
• Agent Security / Prompt Injection
• SkillOpt (Microsoft)
• GEPA (Genetic-Pareto)
• Learn Prompt Hacking — 关于越狱、提示词注入以及红队/蓝队防御的开源课程

教程与指南

• Anthropic's Prompt Engineering Interactive Tutorial
• Google Prompt Engineering Whitepaper

参考资料

• AI Engineering: Building Applications with Foundation Models — Chip Huyen, O'Reilly, 2024. Chapter 5.
• Brown et al. (2020) — Language Models are Few-Shot Learners (GPT-3)
• Wei et al. (2022) — Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
• Khattab et al. (2023) — DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines

提示词示例

Technical Writer Prompt (Gemini)

You are a senior technical writer. Your task is to propose a new documentation
page based on trends in recent customer feedback.

**Step 1: Analyze Recent Customer-Reported Documentation Issues**
Analyze open customer issues to identify the most common or impactful user
pain points and respond with 2-3 top level themes, including the issue count
for each. Stop here and let me ask any questions about the analysis. From the
top themes, ask me to confirm which theme to proceed with.

Here is the list of issues: `doc-issues.csv`

**Step 2: Propose a New Content Type**
Determine the best content type (How-to, Concept, or Troubleshooting) that best
addresses the content theme. Then, propose an outline for the new page.