推荐语

告别提示词玄学，掌握这套工程化方法让你的AI输出更精准可控。

核心内容：
1. 从模型机制剖析提示词失效的根本原因
2. 五段式Prompt工程框架详解（角色/目标/输入/流程/输出）
3. 参数配置与提示词协同优化的实战技巧

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

1、引言：为什么你的AI输出总是“差一点”？

你一定遇到过这样的情况：费尽心思写了一个自认为完美的提示词（Prompt），但AI给出的结果却总是不够精确，甚至完全“跑偏”。我们投入了大量时间学习各种提示词技巧，比如使用“请充当…”、“请使用XX语气”，但效果依然不稳定。

为什么会这样？因为我们可能陷入了一个误区：把AI的协作能力，简单地等同于一个孤立的“提示词”。

这两年很多人都有一种强烈感受：“模型越来越强，但 Prompt 却越来越难写。”

原因不复杂：

• 模型更强 → 生成空间更大 → 更容易“想多了”

• 模型更复杂 → 投机 Prompt 越来越不稳定

• 模型更会联想 → 模糊表达会被自动补全 → 输出更不可控

特别是当你让模型执行任务（生成代码、文案、结构化内容），你会明显看到：Prompt 的细节写不对，输出就会失控。

这篇文章想做的，就是把那些“零散的提示技巧”打包成一套工程化、可迁移、可复用的 Prompt 方法论。

重点：
不是写得更华丽，而是写得更可控、更稳定。

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

Google 《Prompt Engineering》白皮书（2025）里说得非常直接：

LLM 本质上是“基于已生成 token + 输入上下文”预测下一个 token。
——Prompt Engineering (2025)

这句话决定了几件非常重要的事实：

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

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

事实 2：Prompt = 控制输入空间

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

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

PDF 中专门用一整章讲解 Sampling 配置：Temperature、Top-K、Top-P 如何影响输出。

特别值得注意：

• Temperature=0 → 更稳定但更呆板

• Top-P、Top-K 控制“可选词空间” → 不同模型行为差异很大

• 输出 token 不等于“更简洁”，会直接截断内容

换句话说：
Prompt 写得再好，参数错了也会跑偏。

Prompt 工程 = Prompt 文本 + 配置工程。

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

结合多方面写模型提示词的经验，我更推荐一套比 COSTAR 更适合执行任务的结构：

五段式 Prompt 工程模型

1. Role（我要你扮演谁）

2. Goal（这次任务的最终目标是什么）

3. Input（我给你的材料是什么）

4. Process（行动步骤 & 限制）

5. Output（我要得到的格式是什么）

下面逐段解释。

1）Role：给模型一个“稳定人格”

例子：

你是一个资深的数据工程师，擅长结构化输出与多步骤推理。

模型角色一旦固定，它的语言风格与行动逻辑都会稳定很多。

白皮书里称之为 System Prompt / Role Prompt，是最稳定的工程手段之一。

2）Goal：明确这次任务的“判定标准”

不要写：

帮我总结一下xxx

目标：生成一个结构化总结，便于直接导入 Notion。总结需覆盖：- 背景- 问题- 核心结论- 可执行建议

3）Input：告诉模型“你要处理什么内容”

模型处理的不是“你想让它做的事情”，而是“你给它看的内容”。

建议写：

下面是原始材料：———（内容）———

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

这一步非常关键，是控制模型最强的纵深武器。

例如：

请按以下步骤执行：1. 阅读输入材料2. 提取关键词3. 生成结构化总结4. 按 Output 模板输出结果

请严格按照如下 JSON 输出：{  "background": "",  "problems": [],  "conclusions": [],  "recommendations": []}

你会发现 JSON 是最稳定的输出方式，白皮书也强调“结构化格式 = 限制模型自由度 = 减少跑偏”。

PS: JSON 输出是什么意思？如何在 Prompt 中使用？

JSON 是一种结构化数据格式

你可以把 JSON 理解成“机器读得懂的人类笔记格式”。但当你要求模型“按 JSON 输出”之后，它就会严格遵守格式。
它具有以下特点：

• 格式固定（键值对结构）

• 层级清晰

• 能保证字段完整

• 输出容易被其他系统读取（如 Notion、数据库、自动化流程）

让 JSON 输出“更稳定”的 3 个技巧

1）永远给“结构模板”

结构模板必须写清楚，如：

{  "title": "",  "points": []}

模型看到这个，就会按格式输出。

2）告诉模型“禁止输出解释”

例如：

不要输出模板之外的任何文字。

否则模型有时会加一句“以下是 JSON 输出：”。

3）用“必须 / 严格 / 不可缺失”等强约束语言

请严格输出 JSON。所有字段不可缺失。

模型对这种限制词非常敏感，会显著提升稳定性。

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

从各种资料中，我选出最“实用”、最“工程化”的技术（不是最炫，而是最好落地的）。

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

白皮书说：

“高质量示例是最有效的 prompt 工程手段之一。”

要点：

• 示例越相似，模型越准确

• 至少 3–5 个例子

• 示例格式必须统一

• 示例能隐形约束模型输出

  
  

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

PDF 举了典型例子：数学题零-shot 出错，但加 “Let’s think step by step” 后推理正确。

使用场景：

• 复杂推理

• 数据分析

• 调试代码

• 法律类审查

• 文本重写需保留逻辑链路

3）Step-back Prompting：先从抽象层面对问题“提纲”

白皮书里展示了非常漂亮的提升效果：
先让模型列出“FPS 游戏关卡的关键元素”，再让它写关卡故事，质量显著提升。

适合：

• 写报告

• 写文档

• 复杂内容生成（例如产品描述）

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

白皮书有明确示例：
分类邮件“重要/不重要”任务，多次生成出现不同答案，通过“多数投票”找到更稳定结果。

适合：

• 风险类内容

• 法律类

• 数学逻辑

• 决策性任务

5）Sampling 配置（非常工程化）

白皮书集中强调了 4 个必须理解的开关：

• Temperature

• Top-K

• Top-P

• Max output tokens

尤其是重复循环 bug（repetition loop bug），是常见问题，会在极低或极高 temperature 下出现。

建议默认配置：

temperature=0.2  top_p=0.95  top_k=30

temperature=0.9  top_p=0.99  top_k=40

temperature=0

PS: 理解Temperature、Top-K、Top-P、Max output tokens

这些参数被归类为 Sampling Configuration，被认为是影响模型“风格、创造力、稳定性”的核心因素。

✔ Temperature（温度）

控制“随机性/创造力”的开关。

• 高温度（0.7–1.2） → 发散、有创意、可能胡说

• 低温度（0–0.3） → 稳定、公式化、不发散

• Temperature = 0 → 最确定、最可控

写代码、生成文档、写总结 → 温度越低越好
写故事、创意、文案 → 温度越高越好

✔ Top-P（核采样）

控制“模型能考虑的候选词的概率区间”。

• Top-P = 1 → 模型可以选所有候选词（更混乱）

• Top-P = 0.9 → 模型只会从最可能的前 90% 里选词（更稳定）

严谨任务：0.9  创意任务：0.95~1.0

✔ Top-K

控制“模型能考虑的前 K 个词”。

• Top-K = 1 → 只选最可能的词

• Top-K = 40 → 常用、稳定

• Top-K = 100+ → 更发散、随机

这在 PDF 中属于“影响输出随机性的重要参数”。

✔ Max output tokens（最大输出 token 限制）

用来控制“模型最多能说多少内容”。

• 值越大 → 输出越长

• 值越小 → 容易内容没说完就被截断

例如：

• 要写报告 → 设置大一点

• 要生成一句短文案 → 设置小一点防止啰嗦

  
  

LLM如ChatGPT无“参数设置界面”，通过 指令 Prompt 控制采样行为，或使用 API 精确设定数值，如

请以接近 temperature=0 的方式回答：保持内容确定性，不要发散。

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

各类网上资料反复强调：
写 Prompt 不如写 Context。

Prompt 只是“命令”，
上下文（Context）才是“素材 + 限制 + 规则 + 示例 + 目标环境”。

工程实战里，我会把上下文拆成五类：

1. 任务背景（Background Context）

2. 输入材料（Raw Input）

3. 历史对话（Conversation Memory）

4. 工具 / API / Schema（Tool Context）

5. 示例（Few-shot Context）

一个 Prompt 好不好，关键不在“写得多高级”，而在：

你是否给模型提供了足够上下文，让它无需“猜测意图”。

6. 实战示例：从“劣质 Prompt”到“工程化 Prompt”

来做一个真实例子：
任务：让模型“总结一段会议内容”。

❌ 劣质 Prompt

帮我总结下这段会议记录。

问题：

• 没有角色

• 没有目标

• 没有结构

• 没有限制

• 没有上下文

• 模型想怎么写就怎么写

输出肯定乱。

✅ 工程化 Prompt（五段式）

[Role]你是一个资深会议纪要分析专家，擅长提炼结构化信息与关键决策。
[Goal]目标：基于给定会议记录，生成一个可直接用于项目管理的纪要，包含：- 背景- 任务进展- 决策点- 风险- 下一步行动
[Input]下面是会议原文：———（会议全文）———
[Process]请严格按照以下步骤执行：1. 阅读输入内容2. 提取关键事件（不超过 10 条）3. 根据 Goal 的结构生成纪要4. 确保所有信息均来自材料，不可推测
[Output]请严格按照如下 JSON 格式输出：{  "background": "",  "progress": [],  "decisions": [],  "risks": [],  "next_steps": []}

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

用一句最工程的方式收尾：

Prompt = 人为构造一个“低不确定性输入空间”。

真正重要的不是花哨技巧，而是以下三点：

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

你永远应该写：

• 角色

• 目标

• 步骤

• 格式

• 示例

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

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

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

CoT、Step-back、Few-shot 都是为了解决“模型一次性做不好”的问题。

做好这三件事，Prompt 工程的效果立刻上一个台阶。