Prompt 工程这个词听起来很高大上，但它本质上就是"怎么跟模型说话才能让它给出你想要的结果"。这篇文章分享一些实际项目里积累的经验。
明确角色和背景
给模型一个清晰的角色定位：
# 模糊
"帮我写一段代码"
# 清晰
"你是一个 Python 高级工程师，专注于性能优化。
帮我优化以下函数，要求：
1. 保持功能不变
2. 减少不必要的循环
3. 添加类型注解
4. 代码风格遵循 PEP 8"
角色描述告诉模型应该以什么视角和知识储备来回答。
Few-shot：给例子比给说明更有效
告诉模型你想要什么格式，最好的方式是给例子：
将以下文本分类为：正面/负面/中性
示例：
- "这个产品质量很好" → 正面
- "一般般，没什么特别" → 中性
- "完全是浪费钱" → 负面
现在分类以下文本：
- "还行，比预期好一点点"
Few-shot 比描述规则更直观，模型更容易理解你的意图。
Chain of Thought：让模型"想一想再说"
对于需要推理的任务，让模型展示推理过程：
# 直接问（效果差）
"一个工厂每天生产 500 个零件，工人效率提升 20% 后，
需要多少天生产 18000 个零件？"
# 加上 "一步一步思考"（效果好）
"一个工厂每天生产 500 个零件，工人效率提升 20% 后，
需要多少天生产 18000 个零件？请一步一步计算。"
“Let’s think step by step” 或"一步一步思考"这类指令能显著提升推理准确率，这是有论文支撑的结论。
输出格式控制
需要结构化输出时，直接指定格式：
从以下客服对话中提取信息，以 JSON 格式返回：
{
"issue_type": "产品问题/物流问题/退款问题",
"urgency": "高/中/低",
"customer_sentiment": "愤怒/不满/中性/满意",
"key_facts": ["事实1", "事实2"]
}
对话内容：
[...]
强制 JSON 输出时，在 prompt 末尾加上 “只返回 JSON，不要任何解释文字” 可以减少额外内容。
系统 Prompt 的作用
系统 Prompt 设置模型的基础行为，用户 Prompt 做具体任务：
system = """
你是一个专业的 Python 代码审查助手。
规则：
1. 只评审安全问题、性能问题和明显 bug
2. 不评论代码风格（那是 linter 的工作）
3. 评审结果用 Markdown 列表格式
4. 如果代码没有问题，直接说"代码看起来没问题"
"""
user = "帮我审查这段代码：[code]"
系统 Prompt 是定义模型"人格"的地方，把不变的规则放这里，减少每次 user Prompt 的重复。
减少幻觉的技巧
# 容易产生幻觉（模型可能编造不存在的函数）
"Python 里怎么做 X？"
# 减少幻觉
"Python 里怎么做 X？如果你不确定，请说不知道，不要猜测。
只使用 Python 标准库和以下已安装的包：[list]"
# 对于 RAG 场景
"根据以下材料回答问题。如果材料中没有答案，
回答'材料中没有相关信息'，不要根据自己的知识回答。
材料：[...]"
迭代优化 Prompt
Prompt 工程本质上是个实验过程：
- 写初版 Prompt
- 测试 10-20 个样本
- 找出失败案例，分析原因
- 针对性修改 Prompt
- 重复
不要指望第一版就完美，也不要凭感觉改，要基于失败案例来优化。