Prompt学习一：从提问到结构化表达

发表于 分类于 Disqus：

如果把大语言模型当成一个聊天对象，Prompt 很容易学偏：你会把注意力放在“怎么说更像咒语”，而不是“怎么让结果更稳定、更可控”。但如果你的目标是成为一名 AI 应用开发工程师，那么 Prompt 更像是一种接口设计能力，甚至可以把它理解成一种写给模型看的接口协议。

这篇文章聚焦 Prompt 最基础的一层：模型设置、基本概念、提示词要素、通用技巧，以及它们为什么共同指向一件事——Prompt 不是提问技巧，而是结构化表达能力。

为什么 AI 应用工程师必须先学 Prompt 基础

做 AI 应用开发，最终目标不是“和模型聊得顺”，而是把模型接进真实系统：接 API、接工具、接数据库、接工作流。

这时候你会发现，Prompt 其实承担了一个很像接口层的角色：

  • 它定义任务目标
  • 它组织上下文
  • 它约束输出格式
  • 它影响下游程序能否稳定消费结果

所以第一阶段学习 Prompt，我最重要的收获不是记住了几个技巧，而是开始把 Prompt 看成一种结构化输入设计。这篇文章先聚焦单轮 Prompt，本质上是在回答一个更基础的问题：怎样把输入组织得足够清晰，让模型在推理端更可控地工作。

Prompt 至少要包含什么

一个可用的 Prompt 至少要想清楚四件事：

  1. 指令：你到底要模型做什么
  2. 上下文：模型需要哪些背景信息
  3. 输入数据：这一轮真正要处理的内容是什么
  4. 输出指示：你希望它按什么格式返回

这四项不一定每次都要完整展开，但脑子里必须有这个结构。很多“模型不稳定”的问题，根本原因不是模型不行，而是 Prompt 本身没有把这四件事说清楚。

如果换成工程语言，这四项其实对应着：

  • 指令：函数目标
  • 上下文：依赖环境
  • 输入数据：调用参数
  • 输出指示：返回协议

把 Prompt 看成这类接口之后，很多后续问题都会变得更容易理解。

一个坏 Prompt，通常坏在哪里

比如我们想让模型总结一段文章内容。

一个很常见的写法是：

1
帮我总结下面的文章。

这句话不是不能用，但问题也很明显：

  • 总结成多长？
  • 用什么语言？
  • 要不要保留原文术语？
  • 能不能扩展原文没有提到的内容？
  • 输出给人看，还是给程序解析？

如果这些都没说清楚，模型只能自己猜。

一个更适合工程场景的版本，会更像这样：

1
2
3
4
5
6
7
8
9
10
11
12
你是一名信息整理助手。

请将下面内容总结成 3 条要点。

要求：
1. 使用中文
2. 每条不超过 20 字
3. 仅保留原文明确信息
4. 输出格式为 Markdown 列表

文章：
{{content}}

这时候 Prompt 做的事情已经不是“问一句话”，而是在明确：角色、任务、约束、格式。

这个版本之所以更好，不是因为它“更礼貌”或者“更会说话”，而是因为它提供了更完整的信息、设置了更明确的边界，并且让输出结果更容易被验收。

模型参数不是高级技巧，而是基础控制项

学习这一块时，我也开始真正理解 temperature、top_p、max length 这些设置的意义。

以前很容易把这些参数当成“有空再研究”的高级项，但对 AI 应用工程来说，它们其实是基础控制项。

temperature

我会先把它理解成“结果发散程度”。

  • 较低：更稳定、更确定，适合总结、抽取、分类、问答
  • 较高：更发散、更有创造性，适合文案、脑暴、创意生成

如果目标是让系统输出更一致，通常不会把 temperature 调得太高。尤其在结构化输出、标签分类、信息抽取这类任务里，低 temperature 往往比“更有想象力”更重要。

max length

这不只是控制输出长度，也是在控制：

  • 成本
  • 延迟
  • 模型跑偏的空间

很多时候不是模型不会答，而是它答得太多，开始离题。对于工程系统来说，输出失控不仅影响阅读体验，还会直接影响成本、延迟和下游解析成功率。

Prompt 设计里最容易被忽略的一点：具体

这里最值得反复咀嚼的一条原则是：具体比聪明更重要。

很多人会下意识想把 Prompt 写得很“灵”，但模型并不会因为你写得有气势就更懂你。它更依赖的是清晰、直接、低歧义的表达。

比如：

1
解释一下 Prompt Engineering，简短一点，不要太复杂。

这句话看起来像是提出了要求，但其实仍然很模糊：

  • “简短”是几句话？
  • 面向谁解释？
  • 什么叫“不复杂”？

如果改成：

1
请用 2-3 句话，向刚接触大语言模型的前端工程师解释什么是 Prompt Engineering。

结果通常会稳定得多。

从“会提问”到“会设计输入”

第一块内容学完后，我对 Prompt 最大的认知变化是：

Prompt 的核心不是提问，而是设计输入。

这个变化很关键。

因为一旦你把 Prompt 当成输入设计，后面的很多能力都会自然衔接上来：

  • few-shot，本质是在补充模式样本
  • 结构化输出，本质是在约束返回协议
  • function calling，本质是在给模型看工具接口文档
  • context engineering，本质是在管理模型当前可见的信息边界

也就是说，第一阶段虽然叫“Prompt 基础”，但它其实是在打 AI 应用开发的底座。

我给自己留下的一个实践标准

如果把这部分内容落到实践里，可以先用一个很朴素的标准来检查：

以后写 Prompt，先检查这四个问题：

  1. 任务说清楚了吗？
  2. 上下文够用但不过量吗？
  3. 输出格式明确吗？
  4. 这个结果能被人或者程序稳定使用吗？

如果这四个问题答不上来，那大概率说明 Prompt 还没写好。

再往工程一点说，我会给自己补一个发布前 checklist：

  • 任务有没有说清楚，是否存在多种理解方式？
  • 上下文是不是最小必要信息，而不是一股脑全塞进去？
  • 输出格式有没有明确到程序可以稳定解析？
  • 边界情况有没有定义，比如“无法判断时怎么办”？
  • temperature 和输出目标是否匹配？
  • 这个 Prompt 未来能不能被复用、测试和版本管理？
  • 别人拿到这段 Prompt，是否也能稳定产出可用结果？

结语

对 AI 应用工程师来说，Prompt 不是玄学，也不是聊天技巧，而是你和模型之间最早出现的一层工程接口。Prompt 负责定义上游输入规范，而输出格式则决定下游系统边界。

回头看这部分内容，真正建立起来的，不是“怎么把问题问得更好”，而是“怎么把输入组织得更可靠”。

这也是我接下来继续学 few-shot、system prompt、结构化输出、tool use 和 context engineering 的起点。等进入下一块内容，我会继续把“怎么让输出更稳定”这件事展开。

参考文档

  • Prompt Engineering Guide - 大语言模型设置
  • Prompt Engineering Guide - 基本概念
  • Prompt Engineering Guide - 提示词要素
  • Prompt Engineering Guide - 设计提示的通用技巧
  • Prompt Engineering Guide - 提示词示例