3. Prompt核心要素：指令、上下文、输入数据、输出格式
聊到Prompt设计，很多人一上来就堆砌各种要求。结果模型要么跑偏，要么输出一堆废话。
我刚开始也踩过这个坑。后来慢慢总结出四个核心要素——指令、上下文、输入数据、输出格式。说白了，你把这四样东西交代清楚，模型基本不会翻车。
3.1 指令（Instruction）——你要模型干什么
指令是最直白的东西。就是告诉模型：你现在的任务是什么。
比如“翻译这段文字”、“总结这篇文章”、“写一封邮件”。指令要清晰、具体、无歧义。
❌ 模糊指令：“帮我处理一下这段文本。”
✅ 清晰指令：“请将以下中文文本翻译成英文，保持专业语气。”
我个人习惯把指令放在Prompt的最前面。这样模型一上来就知道自己要干嘛，不会跑偏。
小技巧：指令里可以加一个动词，比如“生成”、“总结”、“改写”、“分类”。动词越具体，模型越听话。
3.2 上下文（Context）——给模型一点背景
光有指令还不够。模型不知道你是谁，也不知道你为什么要做这件事。
上下文就是给模型提供背景信息。比如：
- 你是什么角色？（产品经理、开发者、学生）
- 目标用户是谁？（技术团队、客户、老板）
- 场景是什么？（内部沟通、对外发布、技术文档）
我在项目中遇到过一件事：让模型写一封道歉邮件，结果语气太生硬。后来加了上下文——“用户是一位资深客户，关系比较熟”，模型立刻调整了语气，变得自然多了。
上下文示例：
“你是一名资深UI设计师，正在给产品团队写一份设计评审反馈。团队风格偏技术，喜欢直接、简洁的表达。”
3.3 输入数据（Input Data）——模型要处理的东西
输入数据就是你要模型具体处理的内容。可以是文本、代码、表格、问题等等。
这里有个坑：很多人把输入数据和上下文混在一起。结果模型分不清哪些是背景，哪些是待处理的内容。
⚠️ 注意：输入数据要单独标出来。用分隔符或者明确的标签，比如“以下是待处理的文本：”或者用三个反引号包起来。
我曾经犯过一个错：把一整段客户反馈直接塞进Prompt，没做任何标记。模型把反馈里的例子当成了指令，输出了一堆莫名其妙的东西。嗯，从那以后我再也不敢偷懒了。
# 推荐写法
请总结以下客户反馈的核心问题：
【输入数据】
产品界面加载太慢，经常卡顿。
客服响应不及时，等了三天才回复。
功能操作复杂，新手很难上手。3.4 输出格式（Output Format）——你想要什么样的结果
这是很多人忽略的一点。你想想看，模型默认输出是一段文字。但你要的是表格、列表、JSON、还是Markdown？
不指定输出格式，模型就会按它自己的习惯来。结果你还要手动整理一遍，浪费时间。
输出格式示例：
“请以表格形式输出，包含三列：问题描述、严重程度、建议方案。”
我建议在Prompt末尾明确写出输出格式。比如：
- “用Markdown列表输出”
- “返回JSON格式，包含name和age字段”
- “每一条不超过50字”
小技巧：如果你不确定格式，可以给一个示例。模型看到示例后，输出会更稳定。
3.5 四个要素的组合示例
把四个要素串起来，就是一个完整的Prompt。我拿一个实际场景演示一下：
【指令】
请分析以下用户反馈，提取出三个最需要改进的功能点。
【上下文】
你是一名产品经理，正在为下一版本做需求优先级排序。
目标用户是中小企业主，他们最看重效率和易用性。
【输入数据】
1. 导出报表时经常报错，数据丢失。
2. 移动端界面按钮太小，容易点错。
3. 搜索功能不支持模糊匹配，找东西很麻烦。
4. 权限设置太复杂，普通员工不会用。
【输出格式】
请以表格形式输出，包含三列：
- 功能点（一句话描述）
- 严重程度（高/中/低）
- 改进建议（不超过20字）你看，这样写出来的Prompt，模型几乎不会出错。四个要素各司其职，清清楚楚。
⚠️ 避坑指南：我曾经把上下文和输入数据写在一起，结果模型把输入数据当成了背景信息，直接忽略了。记住：上下文是背景，输入数据是待处理的内容，两者要分开。
3.6 小结
四个核心要素，说白了就是：
- 指令：告诉模型做什么
- 上下文：告诉模型为什么做
- 输入数据：告诉模型处理什么
- 输出格式：告诉模型怎么输出
你想想看，这四样东西都交代清楚了，模型还有什么理由跑偏？
下一章我们聊聊更进阶的技巧——如何用角色设定和示例来提升Prompt的效果。到时候见。