为什么你的AI输出总是“差一点“？这篇必收藏的Prompt工程指南让你秒变AI高手

原创已于 2025-12-18 10:56:19 修改 · 766 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #prompt #ai #程序员 #转行 #产品经理 #大模型

于 2025-12-18 10:56:18 首次发布

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 工程模型

Role（我要你扮演谁）
Goal（这次任务的最终目标是什么）
Input（我给你的材料是什么）
Process（行动步骤 & 限制）
Output（我要得到的格式是什么）

下面逐段解释。

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

例子：

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

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

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

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

不要写：

帮我总结一下xxx

要写：

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

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

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

建议写：

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

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

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

例如：

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

白皮书中反复强调：“LLM 不擅长一次性解决复杂任务，拆步骤效果更稳”。

5）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）才是“素材 + 限制 + 规则 + 示例 + 目标环境”。

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

任务背景（Background Context）
输入材料（Raw Input）
历史对话（Conversation Memory）
工具 / API / Schema（Tool Context）
示例（Few-shot Context）

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

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

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

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

❌ 劣质 Prompt

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

问题：

没有角色
没有目标
没有结构
没有限制
没有上下文
模型想怎么写就怎么写

输出肯定乱。

✅ 工程化 Prompt（五段式）

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

如果你把两者跑一下，会看到巨大的差异