AI Prompt工程实战指南:从提示设计到少样本学习
前言:Prompt 不是聊天,是工程
很多人对 Prompt 的理解是"和 AI 对话"。但真正做下来才发现:同样的需求,今天能跑通,明天就报错。模型本身的随机性 + 表述的细微差异 = 充满不确定性。
Prompt 工程的核心目标:把 prompt 从"一次性对话"变成"可维护的工程产物"——有结构、有边界、能验证、能改。
一、Prompt 工程的三大痛点
1.1 稳定性问题
让 AI「写个 Python 脚本处理 CSV」:
- 第一次只做清洗
- 第二次加了异常处理却把核心逻辑改了
- 第三次要格式化输出,它又把前面重构一轮
1.2 可复用性问题
遇到类似问题时,不应该每次都重新试探。应该能基于已有模板快速适配。
1.3 可迭代性问题
prompt 效果不满足时,应该能定位问题、局部调整、验证效果,而不是推翻重来。
二、结构化 Prompt 设计框架
2.1 核心结构(七要素)
## 角色
你是一个 [具体角色],擅长 [具体技能]。
## 背景
当前任务的背景是 [真实场景描述]。
## 目标
你需要完成 [明确的目标]。
## 限制
- 限制条件 1
- 限制条件 2
## 输入
[实际数据或问题描述]
## 输出格式
[具体的输出格式要求]
## 示例
输入: [示例输入]
输出: [示例输出]
每个部分都有明确目的:
- 角色:定义能力边界
- 背景:提供上下文
- 目标:锁定期望结果
- 限制:防止跑偏
- 输出格式:保证可用性
- 示例:降低理解成本
2.2 角色定义要精确
同样的任务,换个角色定义,结果差异很大:
| 角色定义 | 优化侧重点 |
|---|---|
| “资深 Python 工程师” | 性能、可读性、维护性 |
| “代码审查专家” | 安全性、边界条件、异常处理 |
| “教学助手” | 详细注释、解释、新手友好 |
推荐写法:
## 角色
你是一个专注于性能优化的 Python 后端工程师,擅长识别瓶颈、重构热点代码、降低复杂度。
你熟悉 asyncio、并发编程和常见的性能分析工具,但不建议为了优化牺牲可读性。
比"Python 专家"更精确:限定了"专注性能"和"不牺牲可读性"两个边界。
2.3 目标拆分:从模糊到具体
模糊目标(不推荐):
- “帮我写个脚本”
- “优化这段代码”
- “解释一下这个概念”
具体目标(推荐):
## 目标
基于输入的 CSV 文件,完成以下任务:
1. 读取数据并验证字段完整性
2. 清洗异常值(空值、负数、超出范围的数值)
3. 计算每个用户的消费总额和平均消费
4. 按消费总额降序排序
5. 输出清洗后的数据和统计结果
拆解的好处: 每一步可以独立验证,整体进度可以追踪,问题可以快速定位。
2.4 限制条件:告诉模型"不要做什么"
只说"要做什么"经常收到意料之外的输出:
## 限制
- 只提取明确提及的信息,不要推断或添加内容
- 保持原文的表述风格和语序
- 如果某个字段在输入中不存在,输出 "N/A" 而非猜测
- 代码中不要使用需要额外安装的库,只使用 Python 标准库
- 处理异常时要给出明确的错误信息,而不是静默失败
限制条件直接降低模型的"发挥空间",反而提升了结果的可预期性。
2.5 输出格式:让结果直接可用
## 输出格式
以 Markdown 代码块形式输出 Python 脚本,包含以下部分:
1. 文件头部注释,说明脚本用途、依赖、使用方式
2. 导入语句
3. 常量定义
4. 主函数
5. if __name__ == '__main__' 调用
代码中每个函数都要有清晰的文档字符串。
三、基础技巧:把话说清楚
3.1 用输出格式减少歧义
“解释一下这段代码"这类指令,AI 可能给你一行一行注释,也可能讲设计模式,也可能给重构建议。
请解释以下 Python 代码的工作原理。
要求输出格式:
1. 一句话概括代码的主要功能
2. 列出代码中使用的 3 个关键函数/方法,并说明各自的作用
3. 指出代码中可能存在的性能问题或改进空间
4. 给出适合这个代码的使用场景和不适用的场景
3.2 用示例代替描述
少样本学习(Few-Shot)的基础:给了几个例子,AI 更容易抓住模式。
以下是一个 MySQL 连接池的配置示例:
```python
import mysql.connector.pooling
dbconfig = {
"host": "localhost",
"user": "root",
"password": "password",
"database": "mydb",
"pool_name": "mypool",
"pool_size": 5,
}
pool = mysql.connector.pooling.MySQLConnectionPool(**dbconfig)
请参考上面的示例,给出一个 PostgreSQL 连接池的配置。要求:
- 使用 psycopg2.pool
- 最小连接数为 2,最大连接数为 10
- 连接超时时间为 30 秒
- 添加异常处理和连接验证逻辑
### 3.3 用负样本排除误解
```markdown
请帮我优化以下查询语句。
要求:
1. 保持查询逻辑不变,不要修改返回结果
2. 不要使用窗口函数或复杂的子查询(系统版本不支持)
3. 优化目标:优先提高查询速度,其次减少内存占用
4. 如果当前已经是最优写法,直接说明原因
四、思维链(Chain of Thought)
4.1 用分步引导拆解复杂任务
请帮我设计一个 RESTful API,用于管理用户订阅。
请按照以下思路进行设计:
**步骤 1:需求分析**
- 首先列出订阅系统需要支持的核心功能
- 标出哪些功能是必须的,哪些是可选的
**步骤 2:资源建模**
- 确定需要哪些核心资源(User, Subscription, Plan 等)
- 定义资源之间的关系
**步骤 3:API 设计**
- 为每个资源设计 CRUD 接口
- 考虑分页、过滤、排序等通用需求
**步骤 4:安全考虑**
- 哪些接口需要认证?哪些需要授权?
- 如何处理过期订阅、降级场景?
**步骤 5:错误处理**
- 列出可能出现的错误情况
- 为每种错误设计合理的 HTTP 状态码
请在每个步骤之间明确标注"---步骤 N---",方便我阅读和分段讨论。
优势: 如果 AI 在某个步骤错了,可以直接定位到问题位置,而不是重写整个 prompt。
4.2 用对比分析优化决策
做技术选型时,与其让 AI 直接给结论,不如让它先对比:
我需要在一个新的 Python 项目中选择异步 Web 框架,候选包括:FastAPI, Sanic, Tornado。
请从以下维度进行对比分析:
1. 性能:基于公开的基准测试数据
2. 生态成熟度:可用插件、社区支持
3. 学习曲线:文档质量、上手难度
4. 实际考虑:我的项目需要高并发、WebSocket 支持
对比完成后,请给出一个推荐,并说明在什么情况下你会推荐另一个框架。
4.3 自一致性(Self-Consistency):多路径采样投票
思维链解决了"怎么让模型分步推理”,但单次 CoT 仍然受概率采样影响——同一道题跑三遍可能得到三个不同答案,两个对、一个错。生产环境没有"再试一次"的余地。
自一致性的思路很朴素:让模型沿多条不同的推理路径各做一遍,再对最终答案投票,取出现次数最多的那个。好比找十个同学独立做同一道题,多数人选的答案大概率就是对的。它天然和 CoT 搭配——每条路径本身就是一条完整的思维链。
# 单次采样(传统方式)
def single_sample_llm(prompt):
return llm.generate(prompt)
# 自一致性采样:多次采样 + 投票
def self_consistency_llm(prompt, num_samples=5):
reasoning_chains = []
for _ in range(num_samples):
# temperature>0 才会产生不同路径
response = llm.generate(prompt, temperature=0.7)
reasoning_chains.append(response)
return majority_vote(reasoning_chains), reasoning_chains
核心价值有三:解决单点故障(不再看运气拿到哪一次的结果)、提升复杂推理准确率(多角度覆盖)、并通过"多路径共识"增强结果可信度。
4.4 四步实现
第一步:设计固定格式的推理模板,让每条路径都能抽出统一的"最终答案"字段:
reasoning_template = """
请按以下步骤回答:
问题:{question}
步骤1:分析关键点 → {step1}
步骤2:列出思路 → {step2}
步骤3:逐步推导 → {step3}
步骤4:验证合理性 → {step4}
最终答案:{final_answer}
"""
第二步:多路径采样,用略有差异的温度制造多样性:
def multi_path_sampling(prompt, num_paths=5):
paths = []
for i in range(num_paths):
temp = 0.6 + i * 0.1 # 0.6 ~ 1.0
paths.append({
'temperature': temp,
'response': llm.generate(prompt, temperature=temp, max_tokens=1000)
})
return paths
第三步:答案提取与投票:
def vote_on_answers(paths):
answers = [extract_answer(p['response']) for p in paths]
counts = Counter(answers)
top = counts.most_common(1)[0]
return {'final_answer': top[0], 'vote_count': top[1], 'all_answers': answers}
第四步:用投票占比作为置信度,决定是否需要追加采样:
confidence = vote_result['vote_count'] / num_paths
整个流程可以概括为:输入 → 多路采样(不同温度)→ 逐条提取答案 → 投票 → 置信度。
4.5 参数与踩坑
温度是成败关键。 温度太高(>0.9)每条路径差异过大、投票失去意义;太低又失去多样性。实践经验值:
| 任务类型 | 推荐温度 |
|---|---|
| 保守任务(判断题、选择题) | 0.5–0.6 |
| 一般推理 | 0.6–0.7 |
| 创造性任务 | 0.7–0.8 |
答案提取要鲁棒。 模型输出格式不规范会让投票失效,需要多模式兜底匹配:
def robust_answer_extraction(chain):
patterns = [r'最终答案[::]\s*(.+)', r'答案[::]\s*(.+)',
r'结论[::]\s*(.+)', r'因此[,,]\s*(.+)']
for p in patterns:
m = re.search(p, chain)
if m:
return m.group(1).strip()
return chain.strip().split('。')[-1] # 兜底:最后一句
答案要先标准化再投票。 否则"对/正确/Yes"会被当成三个不同答案:
def normalize_answer(answer):
return {'是':'yes','对':'yes','正确':'yes',
'不是':'no','错':'no','错误':'no'}.get(answer.lower().strip(), answer)
耗时线性增长。 5 路采样 ≈ 5 倍耗时。实时场景用异步并行采样摊平延迟:
async def async_multi_path_sampling(prompt, num_paths=3):
tasks = [llm.agenerate_async(prompt, temperature=0.6 + i*0.1)
for i in range(num_paths)]
return await asyncio.gather(*tasks)
非关键路径直接走单次采样,只有关键决策才启用自一致性。
4.6 效果:5 路是性价比最高的平衡点
在数学推理任务上的实测:
| 方法 | 准确率 | 调用次数 | 平均耗时 |
|---|---|---|---|
| 单次采样 | 72% | 1 | 1.2s |
| 3 路自一致性 | 84% | 3 | 3.6s |
| 5 路自一致性 | 89% | 5 | 6.0s |
| 10 路自一致性 | 91% | 10 | 12.0s |
5 路 89% 相比 10 路只差 2 个百分点、却省下一半时间,是最佳配置;再往上收益递减明显。
不同任务的提升差异很大——自一致性主要利好推理类任务:
| 任务类型 | 单次采样 | 5 路自一致性 |
|---|---|---|
| 数学推理 | 72% | 89% |
| 代码生成(通过率) | 78% | 92% |
| 分类 | 85% | 88%(提升有限) |
| 摘要(BLEU) | 0.35 | 0.42(提升小,但稳定性更好) |
成本会线性增加(5 路 = 5 倍 API 费用),可按任务重要性做自适应采样:关键任务 5 路、普通任务 3 路、低价值任务单次。
4.7 进阶优化
- 自适应置信度采样:边采样边算置信度,达到目标(如 0.8)即提前停止,避免固定跑满。
- 推理链过滤:投票前剔除过短或缺少推理标记(“分析/因此/所以”)的低质量链。
- 分层采样:先粗采样拿到 Top-2 候选答案,再用"请验证答案 X 是否正确"引导精采样。
4.8 什么时候用
适合: 复杂推理(数学、逻辑、多步问题)、高准确性要求(关键决策、自动化报告)、可容忍延迟(批处理、后台任务)、有明确答案格式(选择/判断)。
不适合: 实时对话、简单分类、开放性创意生成、大规模低成本任务。
五、动态 Prompt
5.1 根据输入调整策略
请先快速评估以下代码的复杂度(简单/中等/复杂),然后根据复杂度采用不同的分析策略。
**简单代码**(< 50 行,逻辑单一):
- 直接给出功能说明
- 指出潜在 bug 或改进点
**中等代码**(50-200 行,有多个函数或类):
- 先拆分功能模块
- 每个模块单独分析
- 最后给出整体架构评价
**复杂代码**(> 200 行,涉及多个模块或设计模式):
- 先画出模块依赖关系
- 标出核心路径和边界情况
- 分析设计模式的适用性
让 AI 自己做"路由",根据情况选择不同处理流程。
六、少样本学习(Few-Shot Learning)
6.1 问题分类
少样本学习的场景有两类,解法完全不同:
6.2 迁移学习:最常见的路
def get_model(num_classes, pretrained=True, freeze_backbone=True):
model = models.resnet50(pretrained=pretrained)
if freeze_backbone:
for param in model.parameters():
param.requires_grad = False
model.fc = nn.Linear(model.fc.in_features, num_classes)
else:
model.fc = nn.Linear(model.fc.in_features, num_classes)
return model
# 小数据情况:冻结骨干网络,只训练分类头
model = get_model(num_classes=11, pretrained=True, freeze_backbone=True)
optimizer = torch.optim.Adam(model.fc.parameters(), lr=1e-3)
关键经验:
- 冻结骨干网络,只训练最后的分类器
- 如果解冻部分层,用小学习率(1e-4 或 1e-5)
- 注意预训练数据和目标数据的分布差异
6.3 元学习:MAML
class MAML:
def __init__(self, model, inner_lr=1e-3, meta_lr=1e-3, inner_steps=5):
self.model = model
self.meta_optimizer = optim.Adam(model.parameters(), lr=meta_lr)
def inner_loop(self, support_data, support_labels, query_data, query_labels):
fast_weights = [p.clone() for p in self.model.parameters()]
for _ in range(self.inner_steps):
logits = self.model.functional_forward(support_data, fast_weights)
loss = nn.CrossEntropyLoss()(logits, support_labels)
grads = torch.autograd.grad(loss, fast_weights)
fast_weights = [w - self.inner_lr * g for w, g in zip(fast_weights, grads)]
logits = self.model.functional_forward(query_data, fast_weights)
return nn.CrossEntropyLoss()(logits, query_labels)
MAML 的坑:
- 计算成本高(每个任务做几次内层梯度)
- 调参复杂(内层学习率、元学习率、内层步数)
- 对任务分布敏感
6.4 原型网络(更实用)
def compute_prototypes(support_features, support_labels, num_classes):
prototypes = []
for c in range(num_classes):
mask = (support_labels == c)
if mask.sum() > 0:
prototypes.append(support_features[mask].mean(dim=0))
else:
prototypes.append(torch.zeros_like(support_features[0]))
return torch.stack(prototypes)
def prototypical_loss(query_features, query_labels, prototypes):
distances = torch.cdist(query_features, prototypes)
logits = -distances
return nn.CrossEntropyLoss()(logits, query_labels)
优势: 简单、直观、训练成本低。假设"类内紧凑、类间分离"。
6.5 数据增强:最省钱的办法
小数据情况下,增强不是"锦上添花",而是"雪中送炭"。
强增强(数据极少时):
strong_transform = A.Compose([
A.RandomResizedCrop(height=224, width=224, scale=(0.5, 1.0)),
A.HorizontalFlip(p=0.5),
A.VerticalFlip(p=0.3),
A.RandomBrightnessContrast(p=0.8),
A.ShiftScaleRotate(p=0.8, shift_limit=0.2, scale_limit=0.2, rotate_limit=30),
A.OneOf([
A.GaussianBlur(p=1.0),
A.MotionBlur(p=1.0),
A.MedianBlur(p=1.0),
], p=0.5),
A.CoarseDropout(max_holes=8, max_height=32, max_width=32, p=0.5),
A.Normalize(),
ToTensorV2(),
])
正则化手段:
# 标签平滑
def label_smoothing_loss(pred, target, smoothing=0.1):
n_classes = pred.size(1)
one_hot = torch.zeros_like(pred).scatter(1, target.unsqueeze(1), 1)
one_hot = one_hot * (1 - smoothing) + smoothing / n_classes
return nn.KLDivLoss(reduction='batchmean')(torch.log_softmax(pred, dim=1), one_hot)
# Mixup
def mixup_data(x, y, alpha=0.2):
lam = np.random.beta(alpha, alpha)
batch_size = x.size(0)
index = torch.randperm(batch_size)
mixed_x = lam * x + (1 - lam) * x[index]
return mixed_x, y, y[index], lam
6.6 少样本学习的坑
坑一:用错评估指标
小数据下准确率很容易骗人。如果一个类别占 90% 样本,全猜这个类别也有 90% 准确率。要看 F1-score 和混淆矩阵。
坑二:忘记类别平衡
# 方案一:加权损失
class_weights = compute_class_weight('balanced', classes=np.unique(train_labels), y=train_labels)
criterion = nn.CrossEntropyLoss(weight=torch.tensor(class_weights, dtype=torch.float32))
# 方案二:过采样
ros = RandomOverSampler(random_state=42)
train_data_resampled, train_labels_resampled = ros.fit_resample(train_data, train_labels)
坑三:对比基线不足
一定要有合理基线:
- 随机猜测
- 最近邻(k-NN)
- 简单模型(Logistic Regression)
教训: 有个项目折腾一周 MAML,最后发现效果还不如简单的 k-NN。
坑四:数据泄露
- 数据增强应该在 split 之后做
- 归一化只用训练集的统计
- 预训练时不能用测试数据
七、零样本学习(Zero-Shot Learning)
7.1 零样本的本质
零样本学习不是"不学习",而是"学得早"。模型在预训练阶段已经学好了语言理解能力、世界知识和推理模式。
from transformers import pipeline
classifier = pipeline("zero-shot-classification", model="facebook/bart-large-mnli")
result = classifier(
"这个手机续航差劲,一天要充三次电",
candidate_labels=["正面", "负面", "中性"]
)
# 输出:负面(置信度 0.894)
7.2 标签就是提示
零样本学习中,标签本身就是提示的一部分。标签怎么写、顺序怎么排,都会影响结果。
# 不好的标签
candidate_labels = ["好", "坏", "一般"]
# 好的标签
candidate_labels = ["服务态度好", "服务态度差", "服务态度一般"]
标签顺序也有影响:
# 这个顺序给"正面"更多机会
classifier(text, candidate_labels=["正面", "负面", "中性"])
# 这个顺序给"中性"更多机会
classifier(text, candidate_labels=["中性", "正面", "负面"])
7.3 假设模板
result = classifier(
"我想取消订单",
candidate_labels=["取消订单", "查询订单", "修改订单"],
hypothesis_template="这句话的意图是 {}。"
)
7.4 模型选择
| 模型 | 适用场景 | 推理速度 |
|---|---|---|
| BART-large-MNLI | 零样本分类(首选) | 50ms/样本(GPU) |
| T5-3B | 效果更好 | 180ms/样本 |
| DistilBART-MNLI | CPU 部署 | 300ms/样本 |
| BERT-base | 不适合零样本 | - |
7.5 零样本的坑
坑一:多语言问题
直接用英文模型处理中文效果差。要用中文预训练模型:
classifier = pipeline(
"zero-shot-classification",
model="uer/roberta-base-finetuned-chinanews-chinese-news-classifier"
)
坑二:领域适配
通用模型在医疗、法律等专业领域效果差。要用领域预训练模型:
# 医疗领域
classifier = pipeline(
"zero-shot-classification",
model="microsoft/BiomedNLP-PubMedBERT-base-uncased-abstract-fulltext"
)
坑三:阈值调整
零样本模型的置信度普遍比监督学习低,阈值要调低:
def classify_with_threshold(text, labels, threshold=0.55):
result = classifier(text, labels)
if result['scores'][0] > threshold:
return result['labels'][0]
else:
return "不确定"
7.6 多标签分类
result = classifier(
"这个产品价格还可以,但是物流太慢了",
candidate_labels=["价格相关", "物流相关", "服务相关"],
multi_label=True
)
# 结果:[("物流相关", 0.89), ("价格相关", 0.76), ("服务相关", 0.21)]
八、Prompt 工程的常见坑
8.1 坑一:过度依赖角色设定
“你是一个有 10 年经验的资深工程师"这种角色设定基本没用。“资深工程师"不会改变逻辑。
有效的角色设定: “你是一个技术文档作者,面向新手读者”——影响语气和解释深度。
8.2 坑二:prompt 越写越长
为追求"精确”,把 prompt 写得非常详细,结果关键信息被淹没。
原则: 每个部分只保留最必要的信息,去掉"可能有帮助"的补充说明。
8.3 坑三:一次性要求太多步骤
一个 prompt 塞满所有步骤,越往后的部分质量越差。
解决: 复杂任务拆成多个 prompt,每个专注一个具体步骤。
8.4 坑四:没限制输出长度
让 AI “详细解释"可能生成几万字回答。
要求:
- 总字数不超过 500 字
- 每个概念解释不超过 2 句话
- 只解释最核心的 3 个概念
8.5 坑五:用了错误的少样本示例
如果示例本身有错误,AI 会把错误当成"正确模式”。少样本示例一定要自己先验证一遍。
8.6 坑六:忽略上下文窗口
习惯:
- 每个 prompt 控制在 500-800 token
- 复杂任务拆分成多次调用
- 输出部分明确限制长度
九、实际应用场景
9.1 代码审查
请对以下代码进行审查,重点关注以下问题:
1. 安全问题:SQL 注入、XSS、未过滤用户输入
2. 性能问题:N+1 查询、不必要的计算
3. 可维护性:命名规范、代码重复、缺少注释
4. 边界情况:空值处理、异常捕获、并发问题
对于每个发现的问题,请按以下格式输出:
- **问题类型**:[安全/性能/可维护性/其他]
- **严重程度**:[高/中/低]
- **具体位置**:指出代码行号或函数名
- **问题描述**:简要说明问题是什么
- **修复建议**:给出具体的修复方案
- **代码示例**:如果适用,提供修复后的代码片段
9.2 技术选型对比
我需要在 Redis 和 Memcached 之间选择一个缓存方案:
业务背景:
- 高并发读取(主要操作是 get)
- 需要支持过期时间(TTL)
- 预计 QPS 峰值在 5k-10k 之间
请对比 Redis 和 Memcached 在上述场景下的适用性,包括:
1. 性能差异(吞吐量、延迟)
2. 功能差异(数据结构、持久化、集群)
3. 运维复杂度(部署、监控、故障恢复)
最后给出一个明确的推荐,并说明在什么情况下你会改变这个推荐。
9.3 问题诊断
我的 Node.js 服务最近出现内存泄漏:
现象描述:
- 服务运行 2-3 天后内存从 200MB 增长到 2GB
- CPU 使用率稳定
- 重启后恢复正常
环境信息:
- Node.js v18.16.0
- 框架:Express.js
- 数据库:MongoDB(mongoose)
- 消息队列:RabbitMQ(amqplib)
请帮我分析可能的原因,并给出排查步骤:
1. 列出最可能的 3-5 个原因,按可能性排序
2. 针对每个原因,给出具体的排查方法
3. 提供一段诊断脚本
4. 给出预防类似问题的最佳实践
十、效果评估
10.1 用了结构化 Prompt 后的效果
| 指标 | 改善前 | 改善后 |
|---|---|---|
| 任务完成轮次 | 7-8 轮 | 2-3 轮 |
| 整体时间 | 基线 | 减少 60% |
| 代码可用率 | 60% | 85%+ |
| 模板复用率 | 0% | 70% |
10.2 少样本学习的效果判断
from sklearn.metrics import classification_report, f1_score
# 不要只看 accuracy
print(classification_report(target, pred))
# 特别关注 Macro F1
f1_macro = f1_score(target, pred, average='macro')
十一、方法选择的边界
11.1 结构化 Prompt 的边界
- 简单一问一答:结构化是"杀鸡用牛刀”
- 高度创造性任务(写小说、设计游戏):过度结构化限制发挥
- 模型能力不够:prompt 写到头也救不了
11.2 少样本学习的边界
- 数据质量差:再好的模型也救不了垃圾数据
- 任务定义不清:得先知道要识别什么
- 预期不合理:5 个样本就是不如 5000 个
11.3 零样本学习的边界
- 准确率上限低:同等算力下监督学习通常更好
- 推理成本高:大模型推理比小模型慢
- 稳定性差:对提示敏感
十二、写在最后
Prompt 工程不是一门能速成的技术,更像是一种需要大量练习的手艺。
几个核心原则:
- 把 prompt 当工程产物管——有结构、有边界、能验证、能改
- 把话说清楚比堆技巧重要——输出格式、示例、限制条件
- 拆解复杂任务——逐步引导比一次塞满好
- 坏了就改,而不是不断加长 prompt
- 学会看 AI 的输出——找出理解偏差,而不是怪"AI 不够聪明"
技术选型建议:
- 简单任务:基础 prompt 技巧(格式、示例、限制)
- 复杂推理任务:结构化 prompt + 思维链 + 自一致性
- 数据极少:少样本学习(迁移学习 + 数据增强)
- 无标注数据:零样本学习(先验证可行性)
最重要的体会:很多时候不是 AI 不够聪明,是我们自己没把话说清楚。
Prompt 工程的本质,是学会用 AI 能理解的方式表达需求。这跟人际沟通其实是一样的——清晰、具体、有边界,永远比模糊、宏大、堆砌有效。
本文整合了 7 篇 Prompt 工程相关文章,涵盖结构化 Prompt 设计、思维链、自一致性、少样本学习、零样本学习、动态 Prompt 等核心技术。
版权声明: 本文首发于 指尖魔法屋-AI Prompt工程实战指南:从提示设计到少样本学习(https://blog.thinkmoon.cn/post/ai-prompt-engineering-comprehensive-guide/) 转载或引用必须申明原指尖魔法屋来源及源地址!
评论
使用 GitHub 账号登录后即可留言,支持 Markdown。