与模型对话时，同一个需求换一种问法，得到的结果可能天差地别：一次得到可用的生产代码，另一次得到一堆正确的废话。这不是模型“看心情”，而是提示词（Prompt）本身就在决定模型的注意力分配与输出形态。提示工程（Prompt Engineering）就是把这件看似玄学的事，变成一套可复现、可迭代的工程方法。本文按“基本结构 → 核心技巧 → 结构化输出 → 迭代优化 → 常见误区 → 总结”组织全文。
1、概述
提示工程研究的是：如何通过精心设计输入给模型的文本，让模型输出更准确、更可控、更符合预期的结果。它不改模型权重、不微调、不换模型，是成本最低、见效最快的模型调用优化手段。
为什么它值得认真对待？因为大模型本质上是“按上文续写下文”的概率系统，你给的上文质量，直接决定了它续写的下限。模型参数里的知识再丰富，如果你的问题模糊、约束缺失、示例缺位，它也只能靠猜——猜，就是一切翻车的根源。
提示工程在实践中的定位可以概括为：
- 模型选型之后的第一道质量防线，优先级高于换更大的模型
- 与模型对话的接口协议，把需求、上下文、约束、格式标准化
- 一种低成本高杠杆的优化手段，改几行文字就能生效
- 智能体系统的地基，系统提示词的质量决定 Agent 行为上限
OpenAI 与 Anthropic 都发布了官方提示工程指南，建议对照阅读：OpenAI 提示工程指南与 Anthropic 的 Agent 构建实践。
2、提示词的基本结构
一条工程化的提示词，不是一句话，而是一组各司其职的构件。虽然不同场景取舍不同，但核心构件是稳定的：角色、任务、上下文、约束、输出格式。
一个典型骨架如下：
[角色] 你是一名资深 Android 工程师,熟悉 Kotlin 与 Jetpack。
[任务] 请审查下面的代码片段,找出潜在的性能问题。
[上下文] 这段代码运行在列表页的 Adapter 中,每秒可能被调用数十次。
[约束] 只报告有把握的问题,每个问题给出定位与修复建议。
[输出格式] 按以下结构输出:
1. 问题清单(编号)
2. 每个问题:严重程度 + 原因 + 修复建议
[待处理内容]
<code>
{粘贴代码}
</code>
解读：角色设定激活模型对应领域的知识分布；任务动词要具体到可执行；上下文补齐模型看不到的环境信息；约束划定行为边界；输出格式约定让结果可被下游程序直接消费。五个构件不必每次齐全，但缺一个，模型就要多猜一分。
各构件的作用对比如下：
| 构件 | 作用 | 缺失后果 |
|---|---|---|
| 角色 | 圈定知识域与口吻 | 回答泛泛而谈 |
| 任务 | 明确“做什么” | 模型自行脑补目标 |
| 上下文 | 补齐环境与背景 | 模型用默认假设补位 |
| 约束 | 划定边界与禁止项 | 输出越界、答非所问 |
| 输出格式 | 约定结果形态 | 结构随机，难以解析 |
提示词的长度不是成本负担，方向错误的短提示词才是——试错次数才是最大的隐性成本。
3、核心技巧详解
3.1、具体明确，拒绝歧义
模型不会读心。把“帮我优化一下这段代码”换成“在保持接口不变的前提下，把这段代码的时间复杂度从 O（n²） 降到 O（n log n），并说明优化思路”，输出质量会立刻不同。判断标准很简单：给一个不了解你背景的实习生看这条提示，他能不能不用追问就开工？ 能，就合格。
3.2、用分隔符隔离内容
当提示词里既有指令又有待处理数据时，用 XML 标签、三引号或 Markdown 分隔线把两者隔开：
请总结以下用户反馈,输出三条最重要的改进建议:
<feedback>
{这里粘贴数千字的原始反馈}
</feedback>
解读：分隔符的最大价值是防止提示注入与指令混叠——明确告诉模型“标签内是待处理数据，不是给你的指令”。处理外部文本（网页、邮件、用户输入）时，这一条是安全底线。
3.3、少样本提示（Few-shot）
模型极其擅长模仿示例。与其用一大段话描述你想要的格式，不如直接给一两个例子。这项能力的经典出处是 GPT-3 论文，其中的“上下文学习”一词正是由此而来，详见 GPT-3 论文。
把产品描述转成结构化的卖点:
输入:便携折叠风扇,续航 12 小时,三档风速
输出:{"product":"折叠风扇","selling_points":["续航12小时","三档风速","便携"]}
输入:无线充电板,兼容 iPhone 与 Android,带防滑硅胶
输出:
解读：示例要覆盖典型情况，也要覆盖边界情况。若输出要求里有“遇到缺失字段填 null”这类规则，必须在示例里体现出来，否则模型不会执行。
3.4、思维链（Chain-of-Thought）
让复杂推理任务先输出中间步骤，再给最终答案，这就是思维链。原理论文见 Chain-of-Thought Prompting。对数学、逻辑、多步规划类任务，它的效果提升显著；对简单任务则是画蛇添足，平白增加 token 开销。
问题:某应用崩溃率从 0.5% 升到 2.3%,日活 100 万。
昨天上线了新版本,覆盖 40% 用户,崩溃全部发生在新版。
请逐步推理,估算新版崩溃率,并给出回滚建议。
解读：注意当代推理模型（如 o 系列、DeepSeek-R1）已把思维链内置为训练后的行为，无需在提示词中显式要求；对普通模型，提示“先分析再作答”仍然有效。
3.5、角色设定的正确用法
“你是一位资深律师”这类设定，真正的作用不是让模型“变聪明”，而是收窄回答的视角、语气与深度。写角色设定的要点是用行为描述能力：与其说“你是专家”，不如说“你审查代码时会关注空指针、线程安全与内存泄漏”。
3.6、控制输出长度与详略
“详细一点”和“控制在 300 字以内”是完全不同的约束。模型对长度的服从并不精确，用“不超过 5 条”“每个要点一句话“这类可数的结构约束，比”简短“这种程度副词可靠得多。
各技巧的适用场景速查如下：
| 技巧 | 一句话要点 | 适用场景 |
|---|---|---|
| 具体明确 | 把需求写到实习生可执行 | 所有场景 |
| 分隔符 | 数据与指令物理隔离 | 处理外部文本 |
| 少样本 | 用例子代替描述 | 格式转换、抽取 |
| 思维链 | 先推理再作答 | 数学、逻辑、规划 |
| 角色设定 | 用行为描述能力 | 收窄视角与口吻 |
| 结构约束 | 用可数限定替代程度副词 | 控制长度与详略 |
4、结构化输出实战
应用开发中，模型输出通常要喂给下游程序解析，此时“格式漂移”是头号故障源。两道防线：第一道在提示词里声明格式，第二道直接使用 API 的结构化输出能力，让模型在解码阶段就被约束。
第一道防线，在提示词中明确格式：
请以 JSON 输出,字段如下:
- "summary": 一句话摘要,不超过 30 字
- "category": 从 ["bug","feature","doc"] 中选一个
- "confidence": 0 到 1 的数字,保留两位小数
只输出 JSON,不要输出任何其他文字。
第二道防线，直接启用 JSON Schema 约束（以 OpenAI API 为例）：
from pydantic import BaseModel
class Issue(BaseModel):
summary: str
category: str
confidence: float
resp = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "分析这条反馈:..."}],
response_format={
"type": "json_schema",
"json_schema": {"name": "issue", "schema": Issue.model_json_schema()},
},
)
解读：启用 Schema 约束后，模型输出的 JSON 在语法层面保证合法，category 若定义了枚举，取值也保证不越界。提示词约束与 Schema 约束建议同时使用：前者让模型“想输出对的值”，后者保证“输出的格式是对的”。
5、迭代优化流程
提示工程不是一锤子买卖，而是一个写、测、改的循环。与其凭感觉改，不如把它变成流程：
这个循环的关键在两端：入口必须有失败案例集，把线上真实翻车的输入沉淀成用例；出口必须有回归测试，每次改提示词都全量跑一遍，防止按下葫芦浮起瓢。没有用例集的提示词优化，本质是在碰运气；有了用例集，提示词就变成了可以版本化管理的工程资产。
实践中还有一个高频技巧：让模型自己当提示词医生。把提示词、失败输入、实际输出、期望输出四样东西丢给模型，让它诊断问题出在哪、怎么改，往往比自己盯着文本空想快得多。
6、常见误区
第一，堆砌形容词。'请你一定要非常认真、非常仔细、竭尽全力地……“——这类话术几乎不改变模型行为，真正起作用的是可执行的具体约束。语气可以强调一两次，但别指望它替代清晰指令。
第二，提示词里塞进互相冲突的约束。“回答要简洁”与“每个问题都要给出完整论证步骤”并存时，模型行为不可预测。冲突约束是输出不稳定的常见根因，发现即修。
第三，把长上下文当万能解。把十份文档全部塞进提示词并不等于效果好：无关内容会稀释注意力，模型可能捡了芝麻丢了西瓜。相关性筛选、只喂必要的上下文，永远优于无差别堆料。
第四，忽视系统性差异。在 A 模型上精心调好的提示词，换到 B 模型上可能明显退化——不同模型对指令的敏感度、格式服从度差异很大。提示词与模型是绑定的工程资产，换模型必须重新回归测试。
第五，从不沉淀。每次都现写提示词、用完即弃，团队里每个人都在重复踩同样的坑。值得维护一个团队提示词库，收录各场景验证过的版本与失败记录，社区项目 awesome-chatgpt-prompts 就是这种思路的公开版。
7、总结
回顾全文要点：提示词是角色、任务、上下文、约束、输出格式五种构件的组合；核心技巧包括具体明确的指令、分隔符隔离、少样本示例、思维链推理、行为化的角色设定与可数化的格式约束；程序化场景要叠加提示词与 Schema 双重防线；迭代优化必须建立在失败案例集与回归测试之上；最后，警惕堆砌形容词、冲突约束、无差别堆上下文与跨模型裸迁移这些高频误区。
提示工程的上限是模型的下限决定的，但绝大多数人的问题根本没到拼模型上限的程度——先把手里的提示词写到合格线以上，收益立竿见影。对于刚起步的团队，建议从今天开始：把线上翻车的输入记进用例集，把验证过的提示词入库版本化，让每一句话术都变成可积累的工程资产。
