你一定遇到过这样的情况：费尽心思写了一个自认为完美的提示词（Prompt），但AI给出的结果却总是不够精确，甚至完全“跑偏”。我们投入了大量时间学习各种提示词技巧，比如使用“请充当…”、“请使用XX语气”，但效果依然不稳定。
为什么会这样？因为我们可能陷入了一个误区：把AI的协作能力，简单地等同于一个孤立的“提示词”。
这两年很多人都有一种强烈感受：“模型越来越强，但 Prompt 却越来越难写。”
原因不复杂：
模型更强 → 生成空间更大 → 更容易“想多了”
模型更复杂 → 投机 Prompt 越来越不稳定
模型更会联想 → 模糊表达会被自动补全 → 输出更不可控
特别是当你让模型执行任务（生成代码、文案、结构化内容），你会明显看到：Prompt 的细节写不对，输出就会失控。
这篇文章想做的，就是把那些“零散的提示技巧”打包成一套工程化、可迁移、可复用的 Prompt 方法论。
重点：
不是写得更华丽，而是写得更可控、更稳定。
Google 《Prompt Engineering》白皮书（2025）里说得非常直接：
LLM 本质上是“基于已生成 token + 输入上下文”预测下一个 token。
——Prompt Engineering (2025)
这句话决定了几件非常重要的事实：
你输入一句模糊问题，模型会从训练分布里找“它觉得你想要的东西”，而不是你的真实需求。
你给的信息越少，模型越容易“自由发挥”；
你提供结构（角色、步骤、格式、示例）越多，模型越容易「按图索骥」。
PDF 中专门用一整章讲解 Sampling 配置：Temperature、Top-K、Top-P 如何影响输出。
特别值得注意：
Temperature=0 → 更稳定但更呆板
Top-P、Top-K 控制“可选词空间” → 不同模型行为差异很大
输出 token 不等于“更简洁”，会直接截断内容
换句话说：
Prompt 写得再好，参数错了也会跑偏。
Prompt 工程 = Prompt 文本 + 配置工程。
结合多方面写模型提示词的经验，我更推荐一套比 COSTAR 更适合执行任务的结构：
Role（我要你扮演谁）
Goal（这次任务的最终目标是什么）
Input（我给你的材料是什么）
Process（行动步骤 & 限制）
Output（我要得到的格式是什么）
下面逐段解释。
例子：
你是一个资深的数据工程师，擅长结构化输出与多步骤推理。
模型角色一旦固定，它的语言风格与行动逻辑都会稳定很多。
白皮书里称之为 System Prompt / Role Prompt，是最稳定的工程手段之一。
不要写：
帮我总结一下xxx
目标：生成一个结构化总结，便于直接导入Notion。总结需覆盖：-背景-问题-核心结论-可执行建议
模型处理的不是“你想让它做的事情”，而是“你给它看的内容”。
建议写：
下面是原始材料：———（内容）———
这一步非常关键，是控制模型最强的纵深武器。
例如：
请按以下步骤执行：1.阅读输入材料2.提取关键词3.生成结构化总结4.按Output模板输出结果
请严格按照如下JSON输出：{"background":"","problems": [],"conclusions": [],"recommendations": []}
你会发现 JSON 是最稳定的输出方式，白皮书也强调“结构化格式 = 限制模型自由度 = 减少跑偏”。
你可以把 JSON 理解成“机器读得懂的人类笔记格式”。但当你要求模型“按 JSON 输出”之后，它就会严格遵守格式。
它具有以下特点：
格式固定（键值对结构）
层级清晰
能保证字段完整
输出容易被其他系统读取（如 Notion、数据库、自动化流程）
结构模板必须写清楚，如：
{"title":"","points":[]}模型看到这个，就会按格式输出。
例如：
不要输出模板之外的任何文字。
否则模型有时会加一句“以下是 JSON 输出：”。
3）用“必须 / 严格 / 不可缺失”等强约束语言
请严格输出JSON。所有字段不可缺失。
模型对这种限制词非常敏感，会显著提升稳定性。
从各种资料中，我选出最“实用”、最“工程化”的技术（不是最炫，而是最好落地的）。
白皮书说：
“高质量示例是最有效的 prompt 工程手段之一。”
要点：
示例越相似，模型越准确
至少 3–5 个例子
示例格式必须统一
示例能隐形约束模型输出
PDF 举了典型例子：数学题零-shot 出错，但加 “Let’s think step by step” 后推理正确。
使用场景：
复杂推理
数据分析
调试代码
法律类审查
文本重写需保留逻辑链路
白皮书里展示了非常漂亮的提升效果：
先让模型列出“FPS 游戏关卡的关键元素”，再让它写关卡故事，质量显著提升。
适合：
写报告
写文档
复杂内容生成（例如产品描述）
白皮书有明确示例：
分类邮件“重要/不重要”任务，多次生成出现不同答案，通过“多数投票”找到更稳定结果。
适合：
风险类内容
法律类
数学逻辑
决策性任务
白皮书集中强调了 4 个必须理解的开关：
Temperature
Top-K
Top-P
Max output tokens
尤其是重复循环 bug（repetition loop bug），是常见问题，会在极低或极高 temperature 下出现。
建议默认配置：
temperature=0.2top_p=0.95top_k=30
temperature=0.9top_p=0.99top_k=40
temperature=0
控制“随机性/创造力”的开关。
高温度（0.7–1.2）→发散、有创意、可能胡说
低温度（0–0.3）→ 稳定、公式化、不发散
Temperature = 0→ 最确定、最可控
写代码、生成文档、写总结 →温度越低越好
写故事、创意、文案 →温度越高越好
控制“模型能考虑的候选词的概率区间”。
Top-P = 1→ 模型可以选所有候选词（更混乱）
Top-P = 0.9→ 模型只会从最可能的前 90% 里选词（更稳定）
严谨任务：0.9创意任务：0.95~1.0
控制“模型能考虑的前 K 个词”。
Top-K = 1→ 只选最可能的词
Top-K = 40→ 常用、稳定
Top-K = 100+→ 更发散、随机
这在 PDF 中属于“影响输出随机性的重要参数”。
用来控制“模型最多能说多少内容”。
值越大 → 输出越长
值越小 → 容易内容没说完就被截断
例如：
要写报告 → 设置大一点
要生成一句短文案 → 设置小一点防止啰嗦
请以接近temperature=0的方式回答：保持内容确定性，不要发散。
各类网上资料反复强调：
写 Prompt 不如写 Context。
Prompt 只是“命令”，
上下文（Context）才是“素材 + 限制 + 规则 + 示例 + 目标环境”。
工程实战里，我会把上下文拆成五类：
任务背景（Background Context）
输入材料（Raw Input）
历史对话（Conversation Memory）
工具 / API / Schema（Tool Context）
示例（Few-shot Context）
一个 Prompt 好不好，关键不在“写得多高级”，而在：
你是否给模型提供了足够上下文，让它无需“猜测意图”。
来做一个真实例子：
任务：让模型“总结一段会议内容”。
帮我总结下这段会议记录。
问题：
没有角色
没有目标
没有结构
没有限制
没有上下文
模型想怎么写就怎么写
输出肯定乱。
[Role]你是一个资深会议纪要分析专家，擅长提炼结构化信息与关键决策。[Goal]目标：基于给定会议记录，生成一个可直接用于项目管理的纪要，包含：- 背景- 任务进展- 决策点- 风险- 下一步行动[Input]下面是会议原文：———（会议全文）———[Process]请严格按照以下步骤执行：1. 阅读输入内容2. 提取关键事件（不超过10条）3. 根据 Goal 的结构生成纪要4. 确保所有信息均来自材料，不可推测[Output]请严格按照如下 JSON 格式输出：{"background":"","progress": [],"decisions": [],"risks": [],"next_steps": []}
用一句最工程的方式收尾：
Prompt = 人为构造一个“低不确定性输入空间”。
真正重要的不是花哨技巧，而是以下三点：
你永远应该写：
角色
目标
步骤
格式
示例
上下文越完整，模型越稳。
CoT、Step-back、Few-shot 都是为了解决“模型一次性做不好”的问题。
做好这三件事，Prompt 工程的效果立刻上一个台阶。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |