如果把大语言模型当成一个聊天对象，Prompt 的学习方向就很容易偏向“怎么说更像咒语”，而忽略“怎么让结果更稳定、更可控”。在 AI 应用开发场景里，Prompt 更适合被理解为一种接口设计能力，也可以把它视为一种写给模型的接口协议。
这篇文章聚焦 Prompt 最基础的一层：模型设置、基本概念、提示词要素、通用技巧，以及它们为什么共同指向一件事——Prompt 不是提问技巧，而是结构化表达能力。
Table of contents
Open Table of contents
为什么 AI 应用工程师必须先学 Prompt 基础
做 AI 应用开发，最终目标不是“和模型聊得顺”，而是把模型接进真实系统：接 API、接工具、接数据库、接工作流。
这时候可以看到，Prompt 实际上承担了一个很像接口层的角色：
- 它定义任务目标
- 它组织上下文
- 它约束输出格式
- 它影响下游程序能否稳定消费结果
因此，Prompt 的第一阶段重点不在于记住若干技巧，而在于把 Prompt 理解为一种结构化输入设计。这篇文章聚焦单轮 Prompt，核心问题是：怎样把输入组织得足够清晰，从而让模型在推理端更可控地工作。
Prompt 至少要包含什么
一个可用的 Prompt 至少要想清楚四件事：
- 指令：你到底要模型做什么
- 上下文：模型需要哪些背景信息
- 输入数据：这一轮真正要处理的内容是什么
- 输出指示：你希望它按什么格式返回
这四项不一定每次都要完整展开，但脑子里必须有这个结构。很多“模型不稳定”的问题，根本原因不是模型不行，而是 Prompt 本身没有把这四件事说清楚。
如果换成工程语言，这四项可以对应为：
- 指令：函数目标
- 上下文：依赖环境
- 输入数据：调用参数
- 输出指示：返回协议
把 Prompt 看成这类接口之后，很多后续问题都会变得更容易理解。
一个坏 Prompt，通常坏在哪里
例如，目标是让模型总结一段文章内容。
一个很常见的写法是：
帮我总结下面的文章。这句话不是不能用，但问题也很明显：
- 总结成多长？
- 用什么语言？
- 要不要保留原文术语？
- 能不能扩展原文没有提到的内容？
- 输出给人看，还是给程序解析？
如果这些都没说清楚，模型只能自己猜。
一个更适合工程场景的版本，会更像这样：
你是一名信息整理助手。
请将下面内容总结成 3 条要点。
要求：
1. 使用中文
2. 每条不超过 20 字
3. 仅保留原文明确信息
4. 输出格式为 Markdown 列表
文章：
{{content}}这时候 Prompt 做的事情已经不是“问一句话”，而是在明确：角色、任务、约束、格式。
这个版本之所以更好，不是因为它“更礼貌”或者“更会说话”，而是因为它提供了更完整的信息、设置了更明确的边界，并且让输出结果更容易被验收。
模型参数不是高级技巧，而是基础控制项
这一部分需要明确 temperature、top_p、max length 这些设置的意义。
以前很容易把这些参数当成“有空再研究”的高级项，但对 AI 应用工程来说，它们其实是基础控制项。
temperature
temperature 可以先理解为“结果发散程度”。
- 较低：更稳定、更确定，适合总结、抽取、分类、问答
- 较高：更发散、更有创造性，适合文案、脑暴、创意生成
如果目标是让系统输出更一致，通常不会把 temperature 调得太高。尤其在结构化输出、标签分类、信息抽取这类任务里，低 temperature 往往比“更有想象力”更重要。
max length
这不只是控制输出长度，也是在控制：
- 成本
- 延迟
- 模型跑偏的空间
很多时候不是模型不会答，而是它答得太多，开始离题。对于工程系统来说，输出失控不仅影响阅读体验，还会直接影响成本、延迟和下游解析成功率。
Prompt 设计里最容易被忽略的一点：具体
这里最值得反复咀嚼的一条原则是：具体比聪明更重要。
Prompt 容易被写成一种“听起来很灵”的表达方式，但模型并不会因为措辞更有气势就更容易理解任务。它更依赖的是清晰、直接、低歧义的表达。
比如：
解释一下 Prompt Engineering，简短一点，不要太复杂。这句话看起来像是提出了要求，但其实仍然很模糊：
- “简短”是几句话？
- 面向谁解释？
- 什么叫“不复杂”？
如果改成：
请用 2-3 句话，向刚接触大语言模型的前端工程师解释什么是 Prompt Engineering。结果通常会稳定得多。
从“会提问”到“会设计输入”
这一部分内容可以归纳出一个核心结论：
Prompt 的核心不是提问，而是设计输入。
这一转变很关键。
因为一旦你把 Prompt 当成输入设计，后面的很多能力都会自然衔接上来：
- few-shot，本质是在补充模式样本
- 结构化输出，本质是在约束返回协议
- function calling，本质是在给模型看工具接口文档
- context engineering，本质是在管理模型当前可见的信息边界
也就是说，第一阶段虽然叫“Prompt 基础”，但它其实是在打 AI 应用开发的底座。
一个可直接使用的实践标准
如果把这部分内容落到实践里，可以先用一个直接的标准来检查：
以后写 Prompt，先检查这四个问题：
- 任务说清楚了吗？
- 上下文够用但不过量吗？
- 输出格式明确吗？
- 这个结果能被人或者程序稳定使用吗？
如果这四个问题答不上来，那大概率说明 Prompt 还没写好。
再进一步，可以补充一个发布前 checklist：
- 任务有没有说清楚，是否存在多种理解方式？
- 上下文是不是最小必要信息，而不是一股脑全塞进去？
- 输出格式有没有明确到程序可以稳定解析？
- 边界情况有没有定义，比如“无法判断时怎么办”？
- temperature 和输出目标是否匹配？
- 这个 Prompt 未来能不能被复用、测试和版本管理？
- 别人拿到这段 Prompt，是否也能稳定产出可用结果？
本篇结论
对 AI 应用工程师来说，Prompt 不是玄学，也不是聊天技巧，而是你和模型之间最早出现的一层工程接口。Prompt 负责定义上游输入规范，而输出格式则决定下游系统边界。
这一部分真正建立起来的，不是“怎么把问题问得更好”，而是“怎么把输入组织得更可靠”。
这也是继续学习 few-shot、system prompt、结构化输出、tool use 和 context engineering 的起点。
下一篇将进入“如何让输出更稳定”，重点讨论 zero-shot、few-shot 和结构化输出约束。