提示工程是用好大模型最核心的技能，没有之一。同一个模型，提示写得好和写得差，效果天差地别。我见过有人用GPT-4写出一堆废话，也见过有人用7B小模型解决复杂问题——差距就在提示词上；

这篇文章把我在实际项目中验证有效的技巧整理出来，每一条都附带了对比示例；

系统提示的设计原则

系统提示是控制模型行为最强大的手段。一个好的系统提示应该包含四个要素：

角色定义告诉模型它是什么。不是"你是一个助手"这种泛泛的描述，而是"你是一个有10年经验的Python高级工程师，擅长性能优化和架构设计"；

能力边界告诉模型它能做什么、不能做什么。“你可以执行SQL查询，但只允许SELECT语句”；

输出格式告诉模型怎么回答。“按以下格式输出：### 发现的问题，### 改进建议”；

安全约束告诉模型什么不能做。“不要编造不存在的API接口，不要假设数据库表结构”；

你是一个资深的代码审查工程师。

## 职责
审查Python代码的质量、安全性和性能，给出具体可操作的改进建议。

## 输出格式
### 问题
1. [严重程度: 高/中/低] 问题描述
   - 位置：文件名:行号
   - 影响：这个问题会导致什么后果
   - 建议：具体的修复代码

### 做得好
- 值得肯定的地方（如果有）

## 规则
- 只审查提供的代码，不假设其他文件
- 代码没有问题就说"未发现问题"
- 不要编造问题
- 代码示例必须完整可运行

结构化输出

让模型输出JSON，比让它输出自由文本稳定得多：

分析以下用户反馈，输出JSON：

反馈："{feedback}"

输出格式（只输出JSON，不要其他文字）：
{
    "sentiment": "positive/negative/neutral",
    "topics": ["主题1", "主题2"],
    "urgency": "high/medium/low",
    "action_items": ["需要处理的事项"]
}

加了"只输出JSON，不要其他文字"之后，输出稳定性提升了一个量级。

少样本学习

给模型展示几个示例，比纯文字描述有效得多：

将非结构化地址标准化。

示例：
输入：北京市海淀区中关村大街1号清华科技园A座12层
输出：{"province":"北京市","city":"北京市","district":"海淀区","street":"中关村大街1号","building":"清华科技园A座12层"}

输入：{address}
输出：

关键：示例要覆盖常见场景和边界情况（缺少字段、格式异常等）。

思维链

复杂推理任务，引导模型一步步思考：

请按以下步骤分析这个问题：

问题：{question}

1. 首先理解问题的核心诉求
2. 列出解决问题需要的关键信息
3. 逐步推理（展示每一步的依据）
4. 得出结论并验证

参数调优

温度（temperature）：事实性任务用0-0.3，创意任务用0.7-1.0。需要确定性输出（JSON、代码）时务必用低温度；

Top-P：和温度二选一调就行，不要同时大幅调整两个；

max_tokens：设太小会被截断，设太大浪费Token。根据实际输出长度设定，留20%余量；

常见陷阱

提示太长导致指令被淹没。重要指令放在开头和结尾（首因效应和近因效应对模型也适用）；

没有给模型"拒绝的权利"。不说"信息不足就说不知道"，模型就会编造；

一次性塞太多任务。拆成多次调用，每次只做一件事，效果好得多；

提示模板里有残留变量。用了模板引擎（Jinja2等）后忘记替换某个变量，模型看到的是模板语法而不是实际值；

写在最后

提示工程不是玄学，是工程。建立自己的提示库，把好用的模板积累下来，遇到新场景时在模板基础上改。反复迭代，持续优化——这是提升AI应用效果性价比最高的方式。