LLM提示词工程实战：告别玄学可落地方法

你肯定遇到过这种情况：精心准备的提示词，AI却给出了完全走样的答案。花了大量时间研究各种技巧，比如“请充当专家”“请用XX语气”，但效果还是不稳定。问题出在哪？很可能是因为一个认知误区——把AI协作能力，简单等同于一个孤立的提示词。

这两年很多人都有一种感觉：模型越来越强，但提示词却越来越难写。原因其实不复杂：模型更强了，生成空间更大，自然就更容易“想多了”；模型更复杂了，那些取巧的提示越来越不稳定；模型更会联想了，模糊的表达会被自动补全，输出就更不可控。特别是当你让模型执行具体任务时，比如生成代码、文案或结构化内容，你会发现，提示词细节写不对，输出就会彻底失控。

这篇文章的目标，就是把那些零散的提示技巧，打包成一套工程化、可迁移、可复用的方法论。重点不是写得有多华丽，而是写得更可控、更稳定。

LLM 为什么容易跑偏？从模型机制理解 Prompt 的本质

Google《Prompt Engineering》白皮书（2025）里说得很直白：LLM 本质上就是“基于已生成的 token 加上输入上下文，来预测下一个 token 是什么”。这句话决定了几个非常重要的事实。

事实 1：模型不会“理解你的意图”，只会预测“最可能后续”

你输入一个模糊的问题，模型会从训练数据里找“它觉得你想要的东西”，而不是你的真实需求。

事实 2：Prompt 本质上是在控制输入空间

你给的信息越少，模型越容易自由发挥；你提供的结构——角色、步骤、格式、示例——越多，模型就越容易按图索骥。

事实 3：配置参数和 Prompt 同等重要

白皮书专门用一整章讲采样配置：Temperature、Top-K、Top-P 如何影响输出。需要警惕的是：Temperature=0 更稳定但也更呆板；Top-P、Top-K 控制的是“可选词空间”，不同模型表现差异极大；输出 token 限制不等于“更简洁”，它会直接截断内容。换句话说，Prompt 写得再好，参数错了也一样会跑偏。Prompt 工程 = Prompt 文本 + 配置工程，缺一不可。

实战框架：工程实践里最常用的「五段式 Prompt 工程模型」

从实践角度来看，相比 COSTAR 这类框架，更推荐一套更适合执行任务的结构：五段式 Prompt 工程模型。包含角色、目标、输入、流程和输出。逐一来看。

1）角色：给模型一个稳定人格

比如“你是一个资深的数据工程师，擅长结构化输出与多步骤推理”。角色一旦固定，模型的语言风格和行动逻辑都会稳定很多。白皮书里称之为 System Prompt 或 Role Prompt，是最稳定的工程手段之一。

2）目标：明确这次任务的判定标准

不要写“帮我总结一下xxx”，而要写清楚：目标生成一个结构化总结，便于直接导入 Notion，总结需覆盖背景、问题、核心结论和可执行建议。

3）输入：告诉模型你要处理什么内容

模型处理的不是“你想让它做的事情”，而是“你给它看的内容”。建议写成：下面是原始材料：———（内容）———

4）流程：明确步骤，让模型按流程走

这一步是控制模型最强的纵深武器。例如：请按以下步骤执行：阅读输入材料 → 提取关键词 → 生成结构化总结 → 按 Output 模板输出结果。白皮书反复强调：LLM 不擅长一次性解决复杂任务，拆步骤效果更稳。

5）输出：格式永远要单独写

比如要求严格按照 JSON 输出，并给出模板。你会发现 JSON 是最稳定的输出方式，白皮书也强调结构化格式等于限制模型自由度，能有效减少跑偏。

理解 JSON 输出与参数配置

JSON 本质上是一种结构化数据格式，可以理解为“机器读得懂的人类笔记格式”。它格式固定、层级清晰、能保证字段完整，输出也容易被其他系统读取。想让 JSON 输出更稳定，有三个技巧：永远给结构模板，告诉模型禁止输出解释，用“必须”“严格”“不可缺失”这类强约束语言。

聊完格式，再来看采样配置。这几个参数直接影响模型的风格、创造力和稳定性。Temperature 控制随机性，高温度（0.7–1.2）发散射，低温度（0–0.3）稳定可控。写代码、生成文档时温度越低越好；写故事、创意文案时温度越高越好。Top-P 控制模型能考虑的候选词概率区间，严谨任务设 0.9，创意任务设 0.95 到 1.0。Top-K 控制模型能考虑的前 K 个词，K=1 最确定，K=40 常用且稳定，K 越大越发散。Max output tokens 则控制模型最多能说多少内容。

默认推荐配置：temperature=0.2，top_p=0.95，top_k=30。创意类任务可以调到 temperature=0.9，top_p=0.99，top_k=40。严格任务直接设 temperature=0。当然，如果你用的是 ChatGPT 这类没有参数设置界面的工具，也可以通过指令 Prompt 来控制，比如要求“请以接近 temperature=0 的方式回答，保持内容确定性，不要发散”。

高级 Prompt 技法：从 Gemini 到 Google 白皮书的关键实践

从各种资料中，可以挑出最实用、最工程化的技术，不是最炫的，而是最好落地的。

1）Few-shot：比零示例更稳定

白皮书明确指出，高质量示例是最有效的 prompt 工程手段之一。要点在于：示例越相似模型越准确，至少 3 到 5 个例子，示例格式必须统一。示例能隐形约束模型输出。

2）Chain of Thought（CoT）：让模型说出心路

白皮书举了典型例子：数学题零样本出错，但加上“Let’s think step by step”后推理正确。适合复杂推理、数据分析、调试代码、法律类审查，以及需要保留逻辑链路的文本重写。

3）Step-back Prompting：先从抽象层面给问题列提纲

先让模型列出“FPS 游戏关卡的关键元素”，再让它写关卡故事，质量显著提升。适合写报告、写文档，以及复杂内容生成。

4）Self-Consistency：同一题生成多次，选概率最高的答案

白皮书有明确示例：分类邮件“重要/不重要”任务，多次生成出现不同答案，通过多数投票找到更稳定结果。适合风险类内容、法律类、数学逻辑以及决策性任务。

5）采样配置的工程化实践

白皮书集中强调了 Temperature、Top-K、Top-P、Max output tokens 这四个必须理解的开关。特别是重复循环 bug，是常见问题，会在极低或极高 temperature 下出现。

上下文工程：Prompt 之外，更重要的是你丢进去的东西

各类资料反复强调一个观点：写 Prompt 不如写 Context。Prompt 只是命令，上下文才是素材、限制、规则、示例和目标环境。工程实战里，上下文可以拆成五类：任务背景、输入材料、历史对话、工具 / API / Schema、示例（Few-shot Context）。一个 Prompt 好不好，关键不在写得多高级，而在你是否给模型提供了足够上下文，让它无需“猜测意图”。

实战示例：从劣质 Prompt 到工程化 Prompt

来看一个真实案例：任务让模型总结一段会议内容。

劣质 Prompt 就是“帮我总结下这段会议记录”，问题是没有角色、目标、结构、限制和上下文，模型想怎么写就怎么写，输出必然混乱。

工程化 Prompt 则采用五段式结构：先设定角色，你是资深会议纪要分析专家；明确目标，生成可直接用于项目管理的纪要，包含背景、任务进展、决策点、风险和下一步行动；提供输入材料并划定范围；规定执行步骤，阅读内容、提取关键事件、按目标结构生成纪要、确保所有信息来自材料；最后强制使用 JSON 格式输出。两者跑一下，差异会非常明显。

总结：写 Prompt 最重要的三个动作

用一句最工程的方式收尾：Prompt 就是人为构造一个低不确定性输入空间。真正重要的，说到底就三点。

1）结构化，而不是堆字数

永远应该写清楚角色、目标、步骤、格式、示例。

2）给足上下文，不要让模型猜

上下文越完整，模型越稳。

3）把复杂任务拆成过程，而不是一句话丢进去

CoT、Step-back、Few-shot 都是为了解决“模型一次性做不好”的问题。做好这三件事，Prompt 工程的效果立刻上一个台阶。