之前写了 Transformer、大模型训练流程、采样参数这几篇，但我们日常用 AI 最头疼的是——怎么写提示词啊！同样的模型，Prompt 写得好和写得差，输出质量能差出十条街。今天结合 OpenAI 官方指南和通义千问最佳实践，把提示词设计的三大核心原则讲透，附送大量实战对比案例
先看一个血淋淋的对比
❌ 差的 Prompt:
"帮我写个关于AI的文章"
✅ 好的 Prompt:
"你是一位资深AI技术博主。请写一篇800字的科普文章，主题是'大模型如何改变程序员的工作方式'。
目标读者是有1-3年经验的初中级开发者。语气轻松幽默，多用类比，避免学术术语。
结构要求：开头用一个真实场景引入，正文分3个小节，结尾给出3个可执行的学习建议。
用Markdown格式输出。"
看到差距了吗？差的 Prompt 像在跟 AI "闲聊"，好的 Prompt 像在给 AI "下需求文档"。
这背后就是今天要讲的三大原则：清晰性、具体性、上下文给足。
一、清晰性：让模型秒懂你要什么
1.1 核心思想
清晰性 = 没有歧义。模型不是你肚子里的蛔虫，你不说清楚，它就只能猜。
1.2 四个实操技巧
技巧 1：用确定性动词开头
别用"帮我"、"能不能"这种模糊说法，直接用动词告诉模型做什么。
# ❌ 模糊
prompts_bad = [
"帮我看看这个代码",
"能不能写个方案",
"关于AI你了解多少",
]
# ✅ 清晰
prompts_good = [
"审查以下Python代码的安全漏洞，列出所有问题并给出修复方案",
"撰写一份面向CTO的AI技术选型方案，对比GPT-4和Claude-3.5",
"用200字解释Transformer的自注意力机制，面向非技术背景的读者",
]
OpenAI 官方建议：在 Prompt 开头直接使用"撰写"、"对比"、"生成JSON"、"列出3个"、"提取字段"、"重写为口语化表达"等确定性动词。
技巧 2：一句话只说一件事
别把多个任务塞进一个 Prompt，模型会"顾此失彼"。
❌ 一锅炖:
"帮我写个用户注册API，要有参数校验，还要写单元测试，
顺便把文档也写了吧，用FastAPI，数据库用MySQL"
✅ 拆开来:
第一步: "用FastAPI写一个用户注册API的接口定义，包含参数校验。
输入：手机号、密码、验证码。输出：用户ID和Token。
用JSON格式返回。"
第二步: "基于上面的注册API，编写3个核心场景的单元测试：
正常注册、手机号格式错误、验证码过期。用pytest框架。"
第三步: "基于上面的注册API，生成OpenAPI格式的接口文档。"
技巧 3：指定输出格式
告诉模型你想要什么格式，别让它自己猜。
# ❌ 没指定格式
"分析这段文本的情感"
# ✅ 指定格式
"""
分析以下用户评论的情感倾向。
输出格式：
{
"sentiment": "positive/negative/neutral",
"confidence": 0.0-1.0,
"keywords": ["关键词1", "关键词2"],
"reason": "一句话解释判断理由"
}
用户评论：这个产品真的太好用了，推荐给所有人！
"""
技巧 4：用分隔符区分指令和内容
当你的 Prompt 包含指令和待处理内容时，用明确的分隔符区分。
❌ 混在一起:
"把这段代码从Java转成Python：public class Hello { public static void main(String[] args) { System.out.println("Hello"); } }"
✅ 用分隔符:
"将以下Java代码转换为Python，保持功能不变，添加类型注解和docstring。
---JAVA CODE START---
public class Hello {
public static void main(String[] args) {
System.out.println("Hello");
}
}
---JAVA CODE END---
"
Qwen 官方建议：结构指令必须前置、独立、无歧义。不要把格式要求和自然语言描述混在一起，模型会优先执行"简洁""别啰嗦"这类模糊指令，反而忽略"表格"这个硬性格式要求。
二、具体性：越具体，输出越精准
2.1 核心思想
具体性 = 约束越多，自由度越低，输出越可控。
这跟写需求文档是一个道理——需求越模糊，开发出来的东西越离谱。
2.2 五个实操技巧
技巧 1：限定对象实体，避免宽泛术语
❌ 宽泛:
"写一个产品介绍"
"分析一下市场趋势"
"优化这段代码"
✅ 具体:
"写一份'防水等级IP68'的技术说明文案，用于淘宝详情页，面向户外运动爱好者"
"分析2024年Q1-Q3中国新能源汽车市场销量数据，重点关注比亚迪和特斯拉的份额变化"
"优化这个Python函数的时间复杂度，当前是O(n²)，目标优化到O(n log n)"
技巧 2：量化你的要求
数字是最强的约束——字数、条数、比例、范围，能量化就量化。
# ❌ 没有量化
"写一篇关于AI的文章"
"列出一些学习资源"
"给几个优化建议"
# ✅ 量化约束
prompt_templates = {
"文章": "写一篇{800}字的文章，分{3}个小节，每节{200-300}字",
"资源": "列出{5}个学习资源，按难度从低到高排序，每个附带{1-2}句推荐理由",
"建议": "给出{3}个可执行的优化建议，每个建议包含：问题描述、解决方案、预期效果",
}
技巧 3：指定目标受众
同一件事，给不同人讲的方式完全不同。告诉模型你的读者是谁。
❌ 没指定受众:
"解释什么是微服务"
✅ 指定受众:
# 面向初中级开发者
"用类比的方式解释微服务架构，假设读者是有2年经验的Java开发者，
熟悉Spring Boot单体应用，但没接触过微服务。"
# 面向非技术人员
"用'开餐厅'的类比解释微服务，让没有任何技术背景的产品经理也能理解。"
技巧 4：指定语气和风格
❌ 没指定风格:
"写一封催款邮件"
✅ 指定风格:
"写一封催款邮件。语气：专业但友好，不要咄咄逼人。
收件人是合作半年的老客户，这次是第一次逾期。
目标：提醒付款的同时维护好客户关系。长度：100字以内。"
技巧 5：嵌入硬性约束
有些规则是"不可绕过"的，必须明确声明。
❌ 软约束:
"尽量简洁一点"
"最好不要有英文"
✅ 硬约束:
"回答不超过200字，超出部分直接截断"
"全文使用中文，不出现任何英文单词（包括技术术语的英文缩写）"
"不使用'可能'、'大概'、'也许'等不确定的措辞"
"输出纯JSON，不要包含任何解释性文字"
Qwen 官方建议：嵌入不可绕过的硬性约束，例如"不出现'可能''大概'等模糊词"、"必须包含数据来源"等。软约束（"尽量""最好"）模型经常无视，硬约束效果更好。
三、上下文给足：信息越充分，幻觉越少
3.1 核心思想
上下文 = 模型做决策的依据。你给的信息越充分，模型越不需要"瞎编"。
大模型的"幻觉"（Hallucination）问题，很大程度上就是因为上下文不够，模型只能靠猜来填补空白。
3.2 四个实操技巧
技巧 1：提供背景信息
❌ 没有背景:
"帮我优化这个SQL查询"
✅ 给足背景:
"""
帮我优化以下SQL查询。
背景信息：
- 数据库：MySQL 8.0
- 表规模：orders表 2000万行，users表 500万行
- 当前查询耗时：3.2秒
- 业务场景：后台管理系统的订单列表页，需要分页展示
- 索引情况：orders.order_date有索引，users.id是主键
当前SQL：
SELECT o.*, u.name FROM orders o JOIN users u ON o.user_id = u.id
WHERE o.order_date > '2024-01-01' ORDER BY o.amount DESC LIMIT 20;
目标：将查询耗时降到500ms以内。
"""
技巧 2：用 Few-Shot 示例教模型
Few-Shot Prompting（少样本提示） 是最有效的提示技巧之一。给模型 1-3 个"输入→输出"的示例，它就能学会你想要的模式。
❌ Zero-Shot（没示例）:
"判断以下评论是正面还是负面：
1. 这个手机拍照真清楚
2. 电池太差了，半天就没电"
✅ Few-Shot（给示例）:
"""
判断用户评论的情感倾向，输出：positive / negative / neutral
示例：
- "物流很快，包装也很好" → positive
- "第三次坏了，再也不会买" → negative
- "今天收到货了" → neutral
现在判断：
- "这个手机拍照真清楚" →
- "电池太差了，半天就没电" →
"""
Few-Shot 的效果通常比 Zero-Shot 好很多，尤其是分类、格式转换这类任务。但示例不要超过 5 个，否则会占用太多 token，而且边际收益递减。
技巧 3：用 System Prompt 设定全局规则
如果你在用 API 调用模型，System Prompt 是最强大的工具。它会在整个对话中持续生效。
import openai
# System Prompt 设定全局行为
system_prompt = """
你是一个专业的Python代码审查助手。
## 你的职责
审查用户提交的Python代码，关注以下方面：
1. 安全漏洞（SQL注入、XSS、硬编码密钥等）
2. 性能问题（不必要的循环、内存泄漏等）
3. 代码规范（PEP 8、命名规范、类型注解）
4. 错误处理（异常捕获、边界条件）
## 输出格式
对每个问题，按以下格式输出：
- 【严重程度】🔴高/🟡中/🟢低
- 【问题类型】安全/性能/规范/错误处理
- 【代码位置】行号
- 【问题描述】一句话说明
- 【修复建议】给出修改后的代码
## 规则
- 只报告真正的问题，不要吹毛求疵
- 修复建议必须可直接使用，不要用伪代码
- 如果代码整体质量很高，先肯定再提建议
"""
response = openai.chat.completions.create(
model="gpt-4",
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": "请审查以下代码：\n```python\n...```"}
]
)
OpenAI 官方建议：System Prompt（developer message）的优先级高于用户消息。可以把"业务规则"放在 System Prompt 里，把"用户输入"放在 user message 里。这样即使用户的输入很随意，模型也会遵循你设定的规则。
技巧 4：用 XML 标签组织复杂上下文
当你的 Prompt 包含多种类型的信息（指令、示例、待处理内容、参考文档），用 XML 标签来组织结构。
<instructions>
你是一个技术文档翻译助手，将英文技术文档翻译为中文。
</instructions>
<rules>
- 保持技术术语的准确性
- 代码块中的内容不翻译
- 保留Markdown格式
- 翻译要自然流畅，不要机翻味
</rules>
<examples>
Input: "The function returns a JSON object with user data."
Output: "该函数返回一个包含用户数据的JSON对象。"
</examples>
<document_to_translate>
## Getting Started
To use this API, you need an API key. You can get one from
the developer dashboard. Here's a quick example:
```python
import sdk
client = sdk.Client(api_key="your-key")
写在最后
提示词工程不是玄学，而是一门有章可循的工程学科。
核心就三件事：
- 说清楚（清晰性）——别让模型猜
- 说具体（具体性）——约束越多越好
- 给依据（上下文）——信息越充分越好
记住那个黄金公式：角色 + 任务 + 约束 + 上下文，套用这个公式写出来的 Prompt，质量不会差到哪里去。
当然，提示词工程也是一个持续迭代的过程——第一次写出来的 Prompt 很少是完美的，多试几次，根据输出结果不断调整，才能找到最优解。
**觉得有用？点赞收藏！你在写 Prompt 时遇到过什么坑？评论区聊聊 **
