01｜为什么你和AI的对话总是”答非所问”

场景引入：一份让人抓狂的周报

周五下午五点，你打开AI对话窗口，输入一句话：“帮我写个周报。”

AI 的回复洋洋洒洒三百字，从”本周工作充实而忙碌”开始，到”下周将继续努力”结束，中间全是模板化的套话。这不是你要的东西——你这周分明做了三件有实质进展的事，可AI一件都没提。

你换了一种方式：

我是后端开发工程师，本周完成了以下三项工作：1）完成订单服务从 MySQL 到 PostgreSQL 的数据库迁移，涉及 23 张表；2）修复了支付回调接口的幂等性问题，上线后重复支付投诉降为零；3）参与新人 Code Review，提交了 15 条审查意见。请用”本周进展 + 下周计划”的结构写一份技术周报，语言简洁专业，300 字以内。

这次AI给出的周报准确命中了每一项成果，格式清晰，甚至还自动推导出了合理的下周计划。

同一个AI，同一个需求，两次对话的效果天差地别。差别不在AI的能力，而在你如何向它提问。

这就是 Prompt Engineering（提示词工程） 的价值所在。

什么是提示词工程

Prompt Engineering，中文常译为”提示词工程”或”提示工程”，指的是通过设计和优化输入给大语言模型的文本（即 prompt / 提示词），来引导模型产出更准确、更有用的输出。

你可以把它类比为向一位极其博学但完全不了解你处境的顾问提问。这位顾问读过海量的书籍和文档，具备回答几乎任何问题的知识储备，但他不知道你是谁、你的项目处于什么阶段、你想要什么格式的答案。如果你只说”帮我想个方案”，他只能给出一个泛泛而谈的通用建议。但如果你把背景、约束、期望讲清楚，他就能给出精准的、可直接落地的方案。

提示词工程不是一种玄学，而是一套可学习、可复用的工程方法。它的核心思想很简单：你给AI的输入质量，决定了AI输出的质量。

大语言模型如何理解你的输入

要写好提示词，首先需要理解大语言模型（LLM）的基本工作方式。你不需要深入数学原理，但掌握几个关键概念会让你在调试 prompt 时游刃有余。

Token：模型看到的不是文字，而是碎片

当你输入”人工智能改变世界”时，模型并不是逐字阅读的。它会先将文本切分成token——一种介于字和词之间的语义碎片。

比如英文中，"understanding" 可能被切分为 "under" 和 "standing" 两个 token。中文里，“人工智能”可能被切分为”人工”和”智能”，也可能是”人”、“工”、“智”、“能”四个独立 token，具体取决于模型的分词策略。

理解 token 有什么实际意义？

费用计算：API 调用按 token 数计费，输入和输出都算。以 OpenAI 的 tokenizer 为例（早期模型使用 cl100k_base，GPT-4o 及后续模型已升级为 o200k_base，对中文分词效率有显著提升），一段 1000 字的中文文本在使用 o200k_base 的模型上大约消耗 1500-2000 个 token（约 1.5-2 token/字），而在使用 cl100k_base 的早期模型上约为 2-3 token/字。不同模型和 tokenizer 的实际消耗会有差异，建议用官方的 tokenizer 工具实测。
长度限制：模型有最大 token 上限，过长的输入会被截断。
表达效率：同样的意思，简洁的表达消耗更少 token，留给输出的空间更大。

上下文窗口：模型的”工作记忆”

上下文窗口（Context Window）是模型在一次对话中能同时处理的 token 总量。你可以把它想象成一张书桌的面积：书桌越大，能同时摊开的资料越多，模型就能参考更多信息来生成回答。

不同模型的上下文窗口差异很大（以下为 2026 年初的主流模型参数，具体数值请以各厂商官方文档为准）：

模型	上下文窗口
GPT-4.1	1M tokens
GPT-4o	128K tokens
Claude Sonnet 4.6	1M tokens
DeepSeek-V3	128K tokens

上下文窗口同时包含你的输入和模型的输出。如果你在一个 128K 窗口的模型中塞入 127K token 的提示词，留给模型回答的空间就所剩无几，回答自然会被截断。

在多轮对话中，之前的对话历史也会占用上下文窗口。当对话越来越长，最早的内容可能被”挤出”窗口，导致模型”遗忘”之前说过的话。这不是AI在敷衍你，而是它的工作记忆确实有限。

模型的本质：概率预测

大语言模型的核心工作方式是根据已有的文本，预测下一个最可能出现的 token。它不是在”思考”，而是在做高维度的概率计算。

当你输入”中国的首都是”时，模型根据训练数据中的统计规律，计算出下一个 token 是”北京”的概率远高于其他选项，于是输出”北京”。

这个机制解释了为什么模型有时会”一本正经地胡说八道”——它追求的是语言层面的合理性，而不是事实层面的正确性。这种现象叫做幻觉（Hallucination）。理解这一点，你就知道为什么在 prompt 中提供准确的上下文信息如此重要：上下文越充分，模型偏离事实的空间就越小。

推理模型：一种新的范式

2024 年起，OpenAI 的 o1/o3/o4-mini、DeepSeek-R1 等推理模型（Reasoning Model） 开始崭露头角。与传统模型直接生成答案不同，推理模型会在输出答案之前进行内部的链式推理——你可以把它理解为模型自带了”打草稿”的能力。

这对提示词工程有一个重要影响：对于推理模型，简洁直接的指令往往比精心设计的复杂模板效果更好。传统模型需要你在 prompt 中手动触发”请一步步思考”，而推理模型会自动完成这个过程。过多的指令反而可能干扰它的内部推理链。

我们会在第 5 章深入讨论推理模型与提示词设计的关系。目前你只需要知道：模型在快速演进，不同类型的模型对提示词的”偏好”有所不同，这也是为什么提示词工程是一门需要持续学习的技能。

提示词的四个核心要素

一个高质量的提示词，通常由以下四个要素组成。不是每次都需要四个要素齐备，但了解它们能帮助你在遇到问题时快速定位优化方向。

1. 角色（Role）

告诉模型”你是谁”，设定它的专业视角和行为风格。

你是一位有 10 年经验的技术文档工程师，擅长将复杂的技术概念用简洁清晰的语言解释给非技术人员。

设定角色就像给模型戴上一副特定的”透镜”，它会从这个角色的知识体系和行为习惯出发来组织回答。一个”安全工程师”角色会优先关注漏洞和风险，而”产品经理”角色会更关注用户价值和业务指标。

2. 指令（Instruction）

明确告诉模型要做什么。这是提示词的核心。

分析以下 Python 代码中的性能瓶颈，列出前三个最严重的问题，并为每个问题提供优化方案。

好的指令应当具体、可执行。“分析一下这段代码”是模糊的；“列出前三个最严重的性能瓶颈并提供优化方案”是明确的。

3. 上下文（Context）

提供模型做出正确判断所需要的背景信息。

这是一个日均处理 50 万订单的电商系统，使用 Python 3.11 + FastAPI 框架，
数据库为 PostgreSQL 15，部署在 4 核 8GB 的云服务器上。

同一个”优化代码”的需求，在单机部署和分布式集群中的答案完全不同。上下文帮助模型缩小答案的搜索空间，给出真正适用于你场景的建议。

4. 输出格式（Output Format）

指定你期望的输出形态。

请用 Markdown 表格输出，列包括：问题描述、严重程度（高/中/低）、优化方案、预期效果。

如果不指定格式，模型会自行决定输出结构，而它的选择不一定符合你的需要。你可能想要 JSON 用于程序解析，想要表格用于汇报，想要编号列表用于逐项核对——这些都需要在 prompt 中明确。

四要素协同示例

下面用一个完整示例展示四要素的组合效果。

需求：把一段技术变更记录改写为面向普通用户的更新说明。

糟糕的 prompt：

改写下面这段话：
系统于 3 月 10 日 02:00 执行了 PostgreSQL 主从切换，
RTO 实测 12 秒，期间 API 返回 503，已完成故障自愈。

AI 的回复：

系统在 3 月 10 日凌晨 2 点进行了 PostgreSQL 主从切换操作，实际恢复时间为 12 秒。在此期间，API 接口返回 503 错误代码，系统已完成自动故障恢复。

几乎只是把原文换了一种说法，仍然充斥着技术术语。

优化后的 prompt：

【角色】你是一位面向普通用户撰写产品公告的运营编辑。
【任务】将以下技术变更记录改写为用户能理解的更新公告。
【上下文】我们的用户是不具备技术背景的小商户店主，
他们只关心"服务是否受影响"和"现在是否正常"。
【格式要求】
- 标题一行
- 正文不超过 3 句话
- 不使用任何技术术语
- 语气亲切但专业

技术记录原文：
系统于 3 月 10 日 02:00 执行了 PostgreSQL 主从切换，
RTO 实测 12 秒，期间 API 返回 503，已完成故障自愈。

AI 的回复：

系统维护通知

3 月 10 日凌晨 2 点，我们对系统进行了一次例行维护升级。维护过程中服务曾短暂中断约 12 秒，目前一切已恢复正常。如您在该时段遇到过访问问题，现在可以放心使用了。

同一条技术记录，两种 prompt 产出的内容在可读性和实用性上差距明显。

LLM 的关键参数

除了提示词的文本内容，大语言模型还提供了几个可调节的参数，它们直接影响输出的风格和质量。无论是通过 API 调用还是在某些对话界面的高级设置中，你都可能遇到这些参数。

Temperature（温度）

Temperature 控制模型输出的随机性。不同 API 提供商的取值范围有所不同：OpenAI API 为 0 到 2，Anthropic Claude API 为 0 到 1。以下以 OpenAI 的范围为例说明。

你可以把它类比为厨师的创意开关。温度低，厨师严格按菜谱做，每次端出的菜味道一模一样；温度高，厨师开始即兴发挥，可能做出惊艳的创意菜，也可能翻车。

温度值	特点	适用场景
0	几乎确定性输出，每次结果高度一致	代码生成、数据提取、事实问答
0.3-0.7	平衡创造性和稳定性	日常写作、邮件起草、技术文档
0.8-1.2	高创造性，结果多样	头脑风暴、创意写作、广告文案
>1.5	输出高度随机，可能不连贯	极少使用

实用建议：如果你的任务有”标准答案”（如代码、数据转换），用低温度；如果你需要多样化的创意输出，用较高温度。大多数日常场景下，0.3-0.7 是最佳区间。

Top-p（核采样）

Top-p 是另一种控制随机性的参数，与 temperature 作用类似但机制不同。它的取值范围是 0 到 1。

当 top_p = 0.9 时，模型只从累积概率前 90% 的候选 token 中选择。换句话说，它排除了那些极不可能出现的词汇。

你可以将它类比为考试时的答题策略：top_p = 1.0 表示所有选项都考虑；top_p = 0.1 表示只考虑最有把握的几个选项。

实用建议：一般情况下，调节 temperature 就够了。如果同时调节两者，建议固定一个、调节另一个，避免效果叠加导致输出不可控。

Max Tokens（最大输出长度）

Max tokens 限制模型单次回复的最大 token 数。

这个参数很直接：设为 100，回复超过 100 token 就会被截断；设为 4096，模型可以输出更长的内容。

场景	建议 max_tokens
分类标签	10-50
简短回答	100-300
文章段落	500-1000
长文写作	2000-4096
代码生成	根据需要，通常 1000-4096

注意：max_tokens 只控制输出的上限，不会强制模型写满。如果模型认为 200 token 就能完成回答，即使你设了 4096，它也只输出 200。

参数调节的实际示例

下面是一个通过 API 调用 LLM 时设置参数的 Python 示例，让你对参数的使用方式有一个直观感受：

from openai import OpenAI

client = OpenAI(api_key="your-api-key")

# 场景 1：代码生成——低温度，追求确定性
code_response = client.chat.completions.create(
    model="gpt-4o",
    temperature=0,
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "用 Python 写一个函数，输入一个列表，返回去重后的结果并保持原顺序。"}
    ]
)

# 场景 2：广告文案——高温度，追求创意多样性
creative_response = client.chat.completions.create(
    model="gpt-4o",
    temperature=1.0,
    max_tokens=512,
    messages=[
        {"role": "user", "content": "为一款智能台灯写三条不同风格的社交媒体广告语。"}
    ]
)

你可以先用默认参数跑通需求，再根据输出效果微调。参数调优是一个经验积累的过程，没有放之四海而皆准的最优值。

完整对比：同一需求的两种写法

让我们用一个完整的真实场景，从头到尾对比”随手一写”和”精心设计”的 prompt 效果差异。

需求：让AI帮忙翻译一段技术文档。

版本一：随手一写

翻译下面这段话：
Kubernetes uses a declarative model. You describe the desired state
of your application in YAML files, and the control plane continuously
works to make the actual state match the desired state.

AI 输出：

Kubernetes 使用声明式模型。您在 YAML 文件中描述应用程序的期望状态，控制平面持续工作以使实际状态与期望状态匹配。

翻译没有错误，但读起来很”机翻味”——“控制平面持续工作以使”这种句式在中文技术文档中显得生硬。

版本二：精心设计

你是一位资深的云原生技术文档译者，熟悉 Kubernetes 生态的中文社区术语惯例。

请将以下英文段落翻译为中文，要求：
1. 术语处理：Kubernetes、YAML 保留英文；declarative 译为"声明式"；
   control plane 译为"控制面"；desired state 译为"期望状态"
2. 译文风格：符合中文技术博客的行文习惯，句式自然流畅，避免欧化长句
3. 在译文之后，用括号标注你拿不准的翻译选择

原文：
Kubernetes uses a declarative model. You describe the desired state
of your application in YAML files, and the control plane continuously
works to make the actual state match the desired state.