想象你新招了一个实习生。
这个实习生的背景堪称离谱——他读过人类有史以来出版过的几乎所有书籍、论文、代码库和论坛帖子。他的知识储备碾压地球上任何一个活人。
但他有一个致命的毛病：他完全不会猜测你的意图。你让他"写个登录页"，他会交给你一个只有用户名和密码框、连 CSS 都没有的 HTML 文件——因为从逻辑上讲，这确实是一个登录页。
你叹了口气，重新说："写一个现代风格的登录页面，要有圆角卡片、渐变背景、输入框带图标、支持邮箱和手机号两种登录方式、响应式布局。"
这次他交出了一个像样的页面。
这就是你和 AI 大模型的关系。它不是不聪明，它只是太听话了——听话到你需要精确地告诉它你想要什么。
而「提示词工程」，就是研究怎么和这个"超级实习生"沟通，才能稳定拿到你想要的结果的那门手艺。
一、什么是提示词工程
提示词工程（Prompt Engineering），说白了就是设计给 AI 模型的输入指令，让它输出你想要的东西。
别被"工程"两个字吓到。它和你熟悉的软件工程不一样——你不写代码，不改模型参数，不做训练。你只是在组织语言。
提示词工程这个概念并非凭空出现。它的学术根基可以追溯到 GPT-3 论文（Brown et al., 2020） 中提出的 In-Context Learning（上下文学习）。研究者发现，大语言模型不需要针对特定任务做微调，只需要在输入中给几个示例（demonstrations），模型就能"当场学会"这个任务——整个过程不更新任何权重参数，仅仅通过前向推理完成。这一发现直接催生了后续提示词工程的所有技术路线。
从 NLP 学术视角来看，提示词工程的本质是把下游任务重新表述为语言模型的原生任务：将分类问题变成"请在 A 和 B 之间选择"，将抽取问题变成"从以下文本中找出……"。这种"任务重述"（Task Reformulation）的能力，决定了提示词质量的天花板。
OpenAI 官方对它的定义是：
Prompt engineering is the process of writing effective instructions for a model, such that it consistently generates content that meets your requirements.
关键词是 consistently ——稳定地、可复现地拿到好结果。这恰恰是纯靠"感觉"写提示词最难做到的事。
提示词为什么能"操控"模型——Token 的底层逻辑 要理解为什么换几个词就能让模型输出天差地别，需要先理解一个概念：Token。
大模型不直接处理"文字"，它处理的是 Token——你可以把它理解为模型词汇表中的最小语义单元。一个中文字通常对应 1-2 个 token，一个英文单词对应 1-3 个 token。当你输入一段提示词，模型做的第一件事就是把它切分成 Token 序列，然后基于这个序列预测下一个最可能出现的 Token。
这就是为什么提示词的措辞如此重要：不同的措辞会产生不同的 Token 序列，激活模型中不同的注意力路径，最终导向完全不同的输出分布。 这不是模型"理解"了你的意图，而是在统计意义上，某些 Token 序列会显著提升输出落在你期望区域内的概率。
但即使是最先进的模型（包括 2025-2026 年的 GPT-5 系列），依然遵循同一底层原理：输入决定输出分布。
提示词工程是一套经过大量实践验证的方法论体系，涵盖角色设定、示例引导、推理拆解、格式约束、上下文管理等一整套技巧。
二、为什么你写的提示词总是不灵？
写提示词这件事，很像你在电话里教一个从来没进过你家厨房的朋友做菜。
糟糕的提示词：
"帮我做个好吃的菜。"
你朋友可能在冰箱里翻出一根黄瓜，切了切撒点盐端给你。你觉得难吃，你觉得他不会做菜。但实际上，是你没告诉他：
- 你冰箱里有什么食材（上下文）
- 你想吃什么菜系（角色/风格）
- 几个人吃、有什么忌口（约束条件）
- 你希望成品是什么样（输出期望）
合格的提示词：
"冰箱里有鸡胸肉、青椒、洋葱、鸡蛋。做一个两人份的中式家常小炒，少油少盐，15 分钟内能完成。告诉我每一步怎么做。"
你看，同样的"厨师"，同样的"厨房"，换个说法，结果天差地别。
这就是提示词工程研究的核心问题：如何用最小的沟通成本，拿到最稳定的高质量输出。
三、核心技巧：从"能跑"到"好用"的五层心法
很多人学提示词是东学一个模板、西抄一个套路，感觉好像懂了，拿回去一用还是翻车。根本原因在于没有建立体系化的认知。
我把提示词工程的核心技巧分为五个层次，从入门到进阶，一层一层来。
3.1 给AI设定一个角色
这是提示词工程里门槛最低、效果最立竿见影的技巧。
大模型就像一个千面演员。你不给它角色，它就只能用自己的"默认人格"来演——那个会礼貌地说"作为一个 AI 助手，我不能……"的老好人。
当你给它一个明确的角色，它就仿佛被激活了另一套知识体系和表达风格。
技术原理：指令层级（Instruction Hierarchy）
从技术角度看，角色扮演不是"魔法"，而是 OpenAI 在 Model Spec（模型规范） 中明确定义的指令层级机制。
在 OpenAI API 中，一条对话由三种角色的消息组成，按优先级排列：
- developer message（开发者消息）——应用开发者设定的全局规则和角色，优先级最高
- user message（用户消息）——终端用户发出的指令，优先级次之
- assistant message（助手消息）——模型自己的历史输出
这个设计类比编程语言中的函数定义：developer message 好比函数体（规则和逻辑），user message 好比函数参数（具体输入）。模型在处理时，会将 developer message 中定义的角色、边界、风格作为"最高准则"来约束后续行为。
在实践中，我们通常在 API 的 instructions 参数或对话的第一条消息中设定角色。各家模型对角色设定的实现路径略有不同——Claude 称之为 System Prompt，GPT 区分 developer 和 system 角色——但内核一致：在推理开始前，先为模型建立一套稳定的行为基线。
比如：
| 提示词 | 输出风格 |
|---|---|
| "解释一下 React 的 useEffect" | 教科书式的技术说明 |
| "你是一名在字节跳动工作了 5 年的前端架构师，用口语化的方式给你带的实习生解释 useEffect" | 带真实场景案例、有"踩坑经验"、语气亲近 |
| "你是一位严厉的计算机教授，正在给研究生上 React 高级课" | 学术化、强调原理和边界情况、带批判性思维 |
写法模板：
你是一名 [角色]，拥有 [年限/背景] 的经验。
你的说话风格是 [风格描述]。
你的读者/听众是 [受众]。
一个反例告诉你角色有多重要：
如果你直接问模型"写一段代码审查意见"，它给出的可能是不痛不痒的"可以考虑优化变量命名"。
但如果你说"你是一名以毒舌著称的 Tech Lead，以毫不留情地指出代码问题闻名，写一段 code review"，它很可能会输出："这个函数名 doStuff，你是认真的吗？命名规范是写给外星人看的？"
角色的力量，就在于此。
3.2 少样本学习-给示例
大模型有一个神奇的特性：你不需要重新训练它，只需要在提示词里放几个例子，它就能立刻领会你想要什么。
这就是少样本学习（Few-shot Learning），学术上更准确地称之为 In-Context Learning（上下文学习）。
少样本学习本质上是在用示例重新校准模型的输出分布：示例中的输入-输出对向模型传递了一个清晰的"映射关系"信号，让模型在统计上更倾向于复现这种模式。
没有例子的情况：
把下面的句子翻译成"程序员黑话"：
"这个需求做不了"
给了例子的情况：
把下面的句子翻译成"程序员黑话"：
示例1：
输入："这个需求很简单"
输出："这个需求很简单，怎么实现我不管"
示例2：
输入："明天能上线吗"
输出："明天能上线吗，上线了能下班吗"
现在请翻译：
输入："这个需求做不了"
现在模型立刻懂了你要的"程序员黑话"是什么风格。它会输出类似"这个需求做不了，除非你给我加钱"之类符合你例子风格的内容。
少样本学习的黄金法则：
- 给 2-3 个例子就够了，太多的例子浪费 token 且可能过拟合
- 例子要覆盖不同情况，别三个例子都很像
- 例子的质量比数量重要，一个高质量的例子胜过十个平庸的
3.3. 思维链-让AI“打草稿”
这是提示词工程里可能最被低估的技巧。
大模型在回答简单问题时，基本上"张口就来"。但面对需要多步推理的复杂问题（数学题、逻辑推理、代码调试），直接回答的错误率会急剧上升。
思维链（Chain of Thought，CoT）的思路简单到令人发指：在提示词里加一句话，让模型把推理过程写出来。
不加思维链：
小明有 5 个苹果，给了小红 2 个，
又买了 3 个，然后吃掉了 1 个。
小红又还给他 1 个。
小明现在有几个苹果？
模型直接算，可能会错。
加上思维链：
小明有 5 个苹果，给了小红 2 个，
又买了 3 个，然后吃掉了 1 个。
小红又还给他 1 个。
小明现在有几个苹果？
请一步一步地推理。
模型会输出：
初始：5 个 给小红 2 个：5 - 2 = 3 买了 3 个：3 + 3 = 6 吃掉 1 个：6 - 1 = 5 小红还 1 个：5 + 1 = 6 答案：6 个苹果
你看，就加了一句"请一步一步地推理"，正确率就从"看运气"变成了"几乎 100%"。
思维链最管用的场景：
- 数学计算和逻辑推理
- 代码调试（让它自己先分析 bug 可能在哪）
- 多条件判断（"如果 A 则 B，如果 C 则 D，否则 E" 这种）
- 需要权衡利弊的复杂决策
任何你觉得需要"动脑子"的问题，都试试在末尾加上"请一步步思考"。
3.4 结构化输出
很多时候，AI 的输出不是内容不对，而是格式不对。
你让模型"分析一下竞品"，它写了 2000 字洋洋洒洒的散文。你想把它放进飞书文档里给老板看，可能得手动整理半小时。
结构化输出的核心思想是：在提示词里就把格式定死。
几种实用的格式约束方式：
方式一：指定 Markdown 结构
请按以下结构输出：
## 概述
（一句话总结，不超过 50 字）
## 核心功能
- 功能1：（一句话描述）
- 功能2：（一句话描述）
...
## 优劣势分析
| 维度 | 优势 | 劣势 |
|------|------|------|
| ... | ... | ... |
## 结论
（是否推荐，理由）
方式二：要求 JSON 输出
请用 JSON 格式输出，结构如下：
{
"summary": "一句话总结",
"features": ["功能1", "功能2", ...],
"pros": ["优势1", "优势2", ...],
"cons": ["劣势1", "劣势2", ...],
"score": 8
}
方式三：指定输出长度和风格
请用 3 个 bullet point 总结，每个不超过 20 字。
语气要像和朋友聊天，不要用术语。
一个冷知识： 很多模型对 JSON 输出的可靠性已经非常高（OpenAI 甚至有专门的 Structured Outputs 功能），你可以直接把模型返回的 JSON 塞进你的业务代码里，不需要再做清洗。
结构化输出的工程实践：Function Calling 与 JSON Schema
在工程实践中，结构化输出不只是"让模型返回 JSON"，它已经演进为一套标准化的 API 设计模式。
OpenAI 在 2024 年推出的 Structured Outputs 功能，允许开发者在 API 调用时直接传入 JSON Schema 定义，模型在生成时会严格遵循这个 schema——输出的 JSON 结构、字段类型、必填项都会精确匹配你的定义。这意味着你不再需要写防御性的解析代码来处理"模型偶尔少了个字段"这种问题。
更进一步的是 Function Calling（函数调用）：你定义好函数签名（函数名、参数、参数类型），模型在需要的时候不会"猜测"地返回一段文字，而是返回一个结构化的函数调用请求——{ "name": "get_weather", "arguments": { "city": "Beijing" } }。你的程序解析这个请求、执行真正的函数、把结果返回给模型，模型再基于结果生成自然语言回复。
这其实就是 AI Agent（智能体）的基础架构：模型是"大脑"，Function Calling 是"手臂"。模型通过结构化输出来驱动外部系统——查数据库、调 API、发邮件、操作文件——而不是仅仅停留在"聊天"层面。
3.5 上下文管理-别让AI“失忆”
大模型有一个硬伤：上下文窗口有限。
GPT-4 的上下文窗口是 128K token，GPT-4.1 系列可达 100 万 token——听起来很大。但如果你在一个对话里聊了上百轮，或者每次都给模型塞几十页文档，很快就会被截断。模型会"忘记"最早说过的话。
看不见的陷阱：Lost in the Middle
更隐蔽的问题是 "Lost in the Middle"（中间信息丢失）——这是 Liu et al.（2023）在论文中揭示的一个反直觉现象：
大模型在处理长文本时，对开头和结尾的信息抓取最强，而对中间位置的信息提取能力显著下降。换句话说，即使你的上下文窗口还没满，放在中间的关键信息也可能被模型忽略。
这项研究的实验数据显示，当信息处于文档开头或结尾位置时，模型的多文档问答准确率可达 70% 以上，但当同样信息被移动到文档中间位置时，准确率可能骤降至不足 50%。窗口越大，这个效应越明显——因为模型需要在更长的文本中分配注意力。
这直接影响了提示词的信息排布策略：最重要的指令和上下文不要堆在中间，而是有意识地向两端集中。
这就像一个只有短期记忆的同事——你跟他聊了两个小时后，他已经忘了第一个小时你们在说什么。
两种解决思路：
思路一（轻量级）：对话摘要 + 滚动窗口
在每轮对话前，用一句话提醒模型当前的状态：
"当前进度：我们已经完成了需求分析，现在正在进行接口设计。之前确认了 3 个核心接口：登录、支付、订单查询。"
这就是手动做"记忆压缩"。
思路二（系统级）：RAG（检索增强生成）
当你需要 AI 基于特定知识库（比如公司内部文档、产品手册）回答问题时，不要在 prompt 里塞整个文档。先把文档切成小块存到向量数据库里，用户提问时检索出最相关的那几段，塞进 prompt。
这就是 RAG 的核心逻辑——不是让模型记住一切，而是只给它当下最需要的。
四、进阶：从"手工作坊"到"工程化"
上面的五层心法还是"单次交互"的优化。当你开始把 AI 真正嵌入产品和工作流时，你需要的不再是"写好一个 prompt"，而是"管理一个 prompt 体系"。
这就是行业内正在发生的转变——从提示词 1.0 到提示词 2.0。
| 维度 | 提示词 1.0 | 提示词 2.0 |
|---|---|---|
| 定位 | 手工技巧、单次指令 | 系统工程、可迭代资产 |
| 方法 | 试错、直觉、套模板 | 框架、度量、A/B 测试、持续迭代 |
| 管理 | 无版本、无监控 | Git 版本控制、效果监控、回归测试 |
| 推理 | 直接问答 | 思维链、思维树、反思修正 |
五、避坑指南：5 个最常见的错误
坑 1：提示词写得太模糊
❌ "帮我分析一下这个产品"
✅ "分析 XX 产品的目标用户、核心功能和定价策略，用 SWOT 框架输出，每个维
度至少 3 条"
模糊的输入必然导致模糊的输出。
坑 2：一次问太多问题
❌ "帮我写个登录页面，要求支持邮箱手机号登录、记住密码、验证码、第三方登录
、忘记密码、注册跳转，对了还要做响应式，还要支持暗黑模式，还要有交互动画……"
模型可能会"丢三落四"。把大任务拆成小步骤，一个一个来。
坑 3：忽视模型的"边界"
❌ "帮我预测明天的股票涨跌"
❌ "帮我黑进隔壁公司的 WiFi"
大模型不是万能的。它有知识截止日期、有安全边界、不会预测未来。了解模型的"能力边界"是提示词工程的前提。
坑 4：用同一套提示词套不同模型
GPT-4、Claude、Gemini、DeepSeek……不同模型对提示词的敏感度不同。一个在 GPT-4 上好用的 prompt，放到 Claude 上可能效果打折。针对目标模型调优，而不是"一招鲜吃遍天"。
坑 5：忘了给模型"退出机制"——幻觉的工程治理
❌ "你是一个永远不说不知道的专家"
这会让模型在碰到不确定的问题时开始编答案——这就是 AI 领域最棘手的问题之一：幻觉（Hallucination）。
幻觉分为两类：内在幻觉（模型输出与输入上下文矛盾）和外在幻觉（模型输出无法被验证或与现实不符）。OpenAI 的 Model Spec 也明确指出，模型在缺乏足够信息时应诚实地表达不确定性，而非臆造答案。
从提示词工程的角度，减轻幻觉有几条经过验证的策略：
- 给模型"不知道"的许可——在提示词中明确：如果你不确定答案，直接说"我不确定"，不要猜测。
- 强制引用来源——要求模型在给出事实性陈述时标注出处，没有出处就不要说。
- 设定置信度阈值——让模型自评每条信息的确定程度（高/中/低），对低置信度内容标记警告。
✅ "如果你不确定答案，直接说'我不确定'，不要猜测。
对于所有事实性陈述，请标注信息来源。如果无法核实，请明确标注'未经核实'。"
六、实战：手把手写一个高质量的提示词
假设你要让 AI 帮你写一份周报。
第一步：定义角色和场景
你是一名互联网公司的前端开发工程师，工作 3 年，所在团队负责用户端 H5 页面开发。
第二步：提供上下文
本周你完成了以下工作：
商品详情页性能优化，首屏加载从 3.2s 降到 1.1s
接入了新的埋点 SDK，完成了 5 个核心页面的埋点
修了 3 个线上 bug（iOS 输入框遮挡、安卓白屏、图片加载失败兜底）
下周计划：
购物车页面重构
配合后端完成支付流程联调
第三步：明确格式和风格
请生成周报，要求：
使用 Markdown 格式
语气专业但不死板，适合发给直属 leader
每个工作项用一句话描述成果，再加半句话说明影响
总字数控制在 300 字以内
第四步：把以上拼成一个完整的提示词
你是一名互联网公司的前端开发工程师，工作 3 年，所在团队负责用户端 H5 页面开发。
本周工作：
商品详情页性能优化，首屏加载从 3.2s 降到 1.1s
接入了新的埋点 SDK，完成了 5 个核心页面的埋点
修复 3 个线上 bug：iOS 输入框遮挡、安卓白屏、图片加载失败兜底
下周计划：
购物车页面重构
配合后端完成支付流程联调
请生成 Markdown 格式的周报。语气专业但不死板，适合发给直属 leader。每个工作项用一句话描述成果加半句话说明影响。总字数 300 字以内。
你看，这就是一个结构完整的提示词：角色 + 上下文 + 任务 + 格式约束 + 风格要求。
七、最后：提示词工程是 AI 时代的"英语"
2023 年初，有人说"提示词工程师年薪百万"。后来很多人发现这活儿好像就是"会写 prompt"，于是嘲讽这是"新时代的搜索引擎优化"。
但近三年过去了，一个事实越来越清晰：提示词工程不是昙花一现的炒作品类，而是 AI 时代的核心能力。
这就好比——30 年前，会打字是一项专门的技能，可以靠它吃饭；今天不会打字的人已经很难找到白领工作了。提示词工程正在走同样的路：从"专门的岗位"变成"通用的基本功"。
本文写于 2026 年 7 月。提示词工程这个领域每半年就变一个样，如果你发现文中的某些信息已经过时了——恭喜你，说明你一直在跟进。
欢迎大家交流提示词实战经验，踩过的坑和总结的套路~
