迭代优化工作流
提示词工程从来不是一蹴而就的。专业的做法是:写 → 测试 → 分析 → 修改 → 再测试,循环迭代,直到满意。
为什么需要迭代?
第一次很难完美
无论你多有经验,第一次写的提示词几乎总是有改进空间:
- AI可能误解了你的意图
- 输出格式可能不稳定
- 某些边界情况没处理好
- 规则之间可能有冲突
AI的行为难以完全预测
大语言模型是复杂的系统,同样的提示词在不同情况下可能产生不同结果。只有通过实际测试,才能发现问题。
标准迭代流程
┌─────────────────────────────────────────┐
│ │
│ ① 起草第一版提示词 │
│ ↓ │
│ ② 用多种不同的输入测试 │
│ ↓ │
│ ③ 分析哪里出了问题 │
│ - 输出跑题了?→ 指令不够清晰 │
│ - 格式不对?→ 格式描述不够具体 │
│ - 推理出错?→ 缺少思维链 │
│ - 内容虚假?→ 缺乏防幻觉设计 │
│ ↓ │
│ ④ 针对问题修改提示词 │
│ ↓ │
│ ⑤ 回到②,再次测试 │
│ │
└─────────────────────────────────────────┘一个真实的迭代过程
场景:让AI总结文章
第一轮
提示词:
总结这篇文章。问题:结果太笼统,没有重点,篇幅不可控。
第二轮
提示词:
用三个要点总结这篇文章的核心论点。问题:三个要点只是原文句子的复述,没有提炼;篇幅仍然偏长。
第三轮
提示词:
假设你是中学老师,用通俗易懂的语言分三个部分总结
这篇文章的主要观点,每部分举一个生活中的例子,
每部分不超过50字。结果:结构清晰,语言易懂,有具体例子,篇幅可控。
结论:迭代了三次,才达到理想效果。
测试提示词的关键问题
每次修改后,用这几个问题检验输出质量:
1. 它做了我要求的事吗?
基本任务有没有完成?
测试方法:对照提示词的要求逐一检查
如果要求:生成JSON格式
检查:输出是否是合法JSON?
如果要求:不超过100字
检查:字数是否超了?2. 格式对吗?
输出结构是否符合预期?
测试方法:检查格式一致性
如果格式不稳定:
- 添加更具体的格式模板
- 提供示例
- 使用预填充技巧3. 换一种输入还能稳定输出吗?
不要只用一个例子测试,要测试多种情况:
测试输入多样性:
- 长输入 vs 短输入
- 复杂情况 vs 简单情况
- 边界情况(空输入、异常输入)
如果输出不稳定:
- 添加更多约束
- 用示例覆盖更多情况4. 有没有边界情况没处理?
思考可能的异常情况:
常见的边界情况:
- 空输入或缺失输入
- 超长输入
- 格式错误的输入
- 不在预期范围内的输入
示例:如果提示词是"翻译这段文字"
边界测试:传入空字符串会怎样?5. 有没有我不想要的内容出现?
AI有时会"自作聪明":
常见的多余内容:
- 不必要的开场白:"当然!我很乐意帮助您..."
- 过度的解释说明
- 与任务无关的延伸
解决方案:明确说明"不要..."的约束诊断与修复速查表
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 输出跑题 | 指令模糊 | 更具体地描述任务 |
| 格式混乱 | 格式说明不足 | 提供模板或示例 |
| 内容遗漏 | 规则不完整 | 添加约束条件 |
| 推理错误 | 缺少思维链 | 要求先思考再回答 |
| 内容虚假 | 缺乏防幻觉设计 | 限制信息来源、允许说不知道 |
| 风格不符 | 角色设定弱 | 加强角色描述 |
| 篇幅失控 | 没有长度限制 | 添加字数约束 |
迭代优化的实战案例
场景:代码审查提示词
V1.0 - 初始版本
请审查这段代码,找出问题并给出建议。测试发现:输出太随意,有时只说"代码不错",有时又太啰嗦。
V1.1 - 添加角色
你是一位代码审查专家。请审查这段代码,找出问题并给出建议。测试发现:稍微好一点,但格式还是不统一。
V1.2 - 添加格式要求
你是一位代码审查专家。请审查这段代码,按以下格式输出:
## 问题列表
1. [问题描述]
## 改进建议
- [建议内容]
## 评分
X/10分测试发现:格式统一了,但问题分析不够深入。
V1.3 - 添加行为规则
你是一位资深代码审查专家,专注于代码质量、安全性和性能。
请审查以下代码,按格式输出:
## 问题列表
| 序号 | 问题 | 严重程度 | 位置 |
|------|------|----------|------|
## 改进建议
1. [具体建议,包含示例代码]
## 评分
X/10分,[一句话理由]
行为规则:
1. 指出问题的具体代码行
2. 严重程度分为:高/中/低
3. 改进建议要具体可执行
4. 关注安全漏洞、性能问题、代码规范测试发现:质量明显提升,但偶尔会遗漏性能分析。
V1.4 - 最终版本
你是一位资深代码审查专家,专注于代码质量、安全性和性能。
请审查以下代码:
<code>
{代码内容}
</code>
按以下维度分析:
1. 安全性(SQL注入、XSS、敏感信息暴露等)
2. 性能(时间复杂度、内存使用、数据库查询效率)
3. 可读性(命名规范、注释、代码结构)
4. 健壮性(错误处理、边界检查、输入验证)
输出格式:
<security>
安全问题:[有/无]
[如有问题,列出详情]
</security>
<performance>
性能问题:[有/无]
[如有问题,列出详情]
</performance>
<readability>
可读性问题:[有/无]
[如有问题,列出详情]
</readability>
<robustness>
健壮性问题:[有/无]
[如有问题,列出详情]
</robustness>
<suggestions>
改进建议:
1. [具体建议]
2. [具体建议]
</suggestions>
<rating>
综合评分:X/10
一句话总结:......
</rating>结果:经过4轮迭代,提示词已经相当成熟,输出质量稳定可靠。
提示词版本管理
为什么需要版本管理?
迭代过程中,你可能会改坏一些原本正常的东西。有版本记录,就能快速回退。
简单的版本注释法
在提示词文件开头添加版本信息:
python
# 提示词:代码审查助手
# v1.0 - 2024-01-10 - 初始版本
# v1.1 - 2024-01-15 - 添加角色设定
# v1.2 - 2024-01-20 - 添加格式要求
# v1.3 - 2024-02-01 - 添加安全分析维度,修复格式不稳定问题
# v1.4 - 2024-02-15 - 重构为XML标签格式,提升可读性
SYSTEM_PROMPT = """
你是一位资深代码审查专家...
"""使用Git管理
如果项目用Git,可以把提示词文件纳入版本控制:
bash
# 修改提示词
git add prompt.py
git commit -m "feat: 优化代码审查提示词,添加安全分析维度"什么时候该停止迭代?
判断标准
- 覆盖了所有测试用例 - 各种输入都能正确处理
- 输出质量稳定 - 连续测试10次,结果都满意
- 边际收益递减 - 继续优化的效果不明显了
不要过度优化
提示词不是越复杂越好。过度优化可能导致:
- 提示词难以维护
- Token消耗增加
- 引入新的问题
原则:够用就好,在满足需求的前提下保持简洁。
小结
迭代优化的核心要点:
| 阶段 | 关键动作 |
|---|---|
| 起草 | 写出第一版,不必追求完美 |
| 测试 | 用多种输入测试,覆盖边界情况 |
| 分析 | 诊断问题根源,不是只看表面 |
| 修改 | 针对问题调整,一次改一个问题 |
| 验证 | 回归测试,确保修改有效且没引入新问题 |
专业建议
建立一个"失败案例库",把效果不好的测试用例记录下来。每次修改提示词后,用这些案例回归测试,确保问题不会复现。
提示词工程完整学习路线
恭喜你完成了提示词工程的全部学习!让我们回顾一下:
| 阶段 | 内容 | 核心技能 |
|---|---|---|
| 基础篇 | 结构、角色、Token、清晰表达 | 提示词基本功 |
| 进阶篇 | 角色设定、XML标签、格式控制、思维链、少样本、防幻觉 | 效果提升技巧 |
| 高级篇 | 提示词链、元提示、五段式架构、迭代优化 | 生产级应用 |
下一步
掌握了提示词工程后,建议你:
- 在实际项目中练习这些技巧
- 建立自己的提示词模板库
- 继续学习 AI编程工具实战,掌握Cursor等工具的使用