文章

《让LLM更懂你：prompts 构建技巧》

发表于 更新于
作者 byte-wrangler
39 分钟阅读
《让LLM更懂你：prompts 构建技巧》

一、为什么提示词这么重要?

在深入技巧之前,先理解一个核心问题:为什么同样的需求,不同的提问方式会得到完全不同的结果?

大模型的本质

之前的文章有说过，大模型可以看做是在玩”词语接龙”游戏。每一个字、每一句话,都会影响它接下来生成的内容。

就像跟一个人聊天:

  • 如果你说话含糊不清,对方只能猜你的意思
  • 如果你表达清晰、提供足够背景,对方就能给出更准确的回应

大模型也是一样的道理,只不过它更”较真”——你怎么问,它就怎么答。

提示词工程的价值

好的提示词能让大模型:

  • 理解更准确:减少歧义,明确你的真实意图
  • 输出更可控:按照你期望的格式和风格生成内容
  • 质量更稳定:减少”一本正经胡说八道”的情况
  • 效率更高:一次就能得到满意的结果,不用反复调整

二、构建高质量提示词的四步法

经过大量实践,我发现 COSTAR 框架是一套非常系统化的方法,有助于建出高质量的提示词。

第一步：选择合适的表达框架

找一个合适的”容器”,让大模型知道这是什么类型的任务。

以 COSTAR 框架为例

COSTAR 框架由新加坡政府科技局（GovTech）提出,是六个英文单词的首字母缩写:

  • Context (上下文)
  • Objective (目标)
  • Style (风格)
  • Tone (语气)
  • Audience (受众)
  • Response (响应格式)

C - Context (上下文)

作用:告诉大模型这个任务的背景信息,帮助它理解你在讨论什么场景。

为什么重要?

  • 同样一个词在不同场景下含义完全不同
  • 提供上下文能让大模型的理解更精准
  • 减少不必要的猜测和误解

举个例子:

❌ 不好的提问:

1

帮我写个测试

✅ 好的提问:

1
2

我正在开发一个电商网站的购物车功能,需要为"添加商品到购物车"这个 API 编写单元测试。
这个 API 接收商品 ID 和数量,返回更新后的购物车信息。

第二个提问提供了:

  • 项目背景(电商网站)
  • 具体功能(购物车)
  • 技术细节(API 的输入输出)

O - Objective (目标)

作用:明确告诉大模型你希望它完成什么任务。

为什么重要?

  • 清晰的目标能让大模型聚焦在正确的方向
  • 避免大模型”发散思维”,给你一堆不相关的内容

技巧:

  • 使用动词开头:”生成”、”分析”、”总结”、”优化”
  • 说清楚期望的结果是什么
  • 如果有多个子目标,可以用列表形式列出

举个例子:

❌ 模糊的目标:

1

帮我处理一下这段代码

✅ 清晰的目标:

1
2
3
4
5

请帮我完成以下任务:
1. 检查这段代码中的潜在 bug
2. 优化性能瓶颈
3. 添加必要的错误处理
4. 补充代码注释

S - Style (风格)

作用:指定你希望大模型使用什么样的写作风格。

为什么重要?

  • 不同场景需要不同的表达方式
  • 风格统一能让输出更符合你的需求

常见风格:

  • 专业正式:适合商务文档、技术报告
  • 轻松口语:适合博客文章、社交媒体
  • 教学讲解:适合教程、说明文档
  • 简洁直接:适合代码注释、API 文档

举个例子:

1
2

请用轻松幽默的口吻,像跟朋友聊天一样,解释什么是 Docker。
避免使用过多专业术语,多用比喻和生活化的例子。

T - Tone (语气)

作用:设定回应的情感态度。

为什么重要?

  • 语气会影响内容的感染力和可读性
  • 合适的语气能让内容更贴近目标受众

常见语气:

  • 正式严谨:学术论文、法律文件
  • 友好亲切:客服回复、用户指南
  • 激励鼓舞:演讲稿、宣传文案
  • 客观中立:新闻报道、分析报告

举个例子:

1
2

请用鼓励和支持的语气,给刚开始学编程的新手写一封欢迎信。
要让他们感受到学习编程是一件有趣且值得坚持的事情。

A - Audience (受众)

作用:明确这个内容是给谁看的。

为什么重要?

  • 不同受众的知识背景不同
  • 同样的内容,给专家看和给小白看,表达方式完全不同

考虑因素:

  • 专业水平(专家/从业者/初学者)
  • 年龄层次(儿童/青少年/成人)
  • 文化背景(不同地区的表达习惯)

举个例子:

1
2

这篇文章的读者是刚毕业的计算机专业学生,他们有基本的编程基础,
但对分布式系统还不太了解。请用他们能理解的方式解释什么是微服务架构。

R - Response (响应格式)

作用:指定你希望得到什么格式的输出。

为什么重要?

  • 明确的格式要求能让输出更规范
  • 方便后续处理和使用
  • 特别是在需要程序化处理输出时,格式非常关键

常见格式:

  • Markdown:适合文档、博客
  • JSON:适合程序调用、数据交换
  • 表格:适合对比、统计
  • 代码:指定编程语言和风格

举个例子:

1
2
3
4
5
6
7

请以 JSON 格式输出,包含以下字段:
{
  "title": "文章标题",
  "summary": "一句话总结",
  "keyPoints": ["要点1", "要点2", "要点3"],
  "tags": ["标签1", "标签2"]
}

一个完整的例子

把 COSTAR 框架应用到一个实际场景中:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# Context (上下文)
我正在为一个在线教育平台开发用户注册功能。
这个平台面向中小学生和他们的家长。

# Objective (目标)
请帮我生成一套完整的单元测试用例,覆盖用户注册的各种场景,
包括正常流程、异常情况和边界条件。

# Style (风格)
使用清晰易懂的测试用例描述方式,让团队其他成员能快速理解每个测试的目的。

# Tone (语气)
保持专业但不失友好,测试描述要简洁明了。

# Audience (受众)
这些测试用例主要给开发团队和测试团队使用,
他们都有基本的软件测试知识。

# Response (响应格式)
请以表格形式输出,包含以下列:
- 测试场景
- 优先级(P0/P1/P2)
- 测试类型(正向/负向/边界)
- 测试步骤
- 预期结果

第二步：选择合适的表达方式

有了框架,接下来就是如何更好地表达你的需求。这里我常用的两个技巧。

技巧 1: 善用”变量”

就是用特殊符号标记出来的占位符,让大模型知道这是一个需要替换的部分。

为什么要用变量?

  • 让提示词更加模块化和可复用
  • 清晰地区分”模板”和”内容”
  • 方便批量处理类似任务

常见的变量标记方式:

  • <<<变量名>>>
  • ``
  • [变量名]
  • <变量名>

举个例子:

假设经常需要让大模型优化不同的文案,你可以这样写:

1
2
3
4
5
6
7
8
9
10

# 任务
请按照 COSTAR 框架优化下面的<<<文案类型>>>

注意事项:
- 不要改变<<<文案类型>>>的核心意思
- 保持原有的风格和语气

<<<文案类型>>>
[用户输入的实际文案]
<<<文案类型>>>

使用时,你只需要:

  1. 把 <<<文案类型>>> 替换成具体类型(如”产品介绍”、”活动通知”)
  2. 把 [用户输入的实际文案] 替换成真实内容

更进一步:引用外部内容

还可以让变量引用外部文件或模板:

1
2
3
4
5
6

请参考 <<<Context:接口文档.md>>> 的格式,
为以下 API 生成文档:

API 名称: getUserInfo
功能: 获取用户详细信息
...

这样做的好处是:

  • 提示词更简洁
  • 可以复用已有的文档和模板
  • 便于维护和更新

技巧 2: 善用 Few-shot 示例

什么是 Few-shot?

Few-shot 就是”少样本学习”,意思是给大模型提供几个示例,让它模仿这些例子来处理新任务。

为什么 Few-shot 这么有效?

对比维度效果
教小孩做题先看两道例题 → 自己做第三道
学习写作风格看几篇范文 → 写出相似风格的新文章
不教规则,只给例子模型自动”归纳”出规律

Few-shot 的三大优势:

  1. 比文字描述更直观
    • 与其说”用简洁的语言”,不如直接给个简洁的例子
    • 一个好例子胜过千言万语
  2. 降低理解成本
    • 不需要精确定义每个细节
    • 大模型能从例子中学习模式
  3. 提高输出质量
    • 有了参考,输出更稳定
    • 减少”创造性发挥”带来的偏差

例如:生成测试用例

可以这样写:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

请参考以下测试用例模板,为新的 API 生成类似的测试用例:

<<<Context:测试用例模板.md>>>

## 测试用例设计

### 测试矩阵

| 测试场景 | 优先级 | 测试类型 | 验证点 | 预期结果 |
|---------|--------|---------|--------|---------|
| 正常获取用户信息 | P0 | 正向测试 | 接口返回 | 返回完整用户信息,状态码 200 |
| 用户ID不存在 | P1 | 负向测试 | 错误处理 | 返回错误信息,状态码 404 |
| 用户ID格式错误 | P1 | 边界测试 | 参数校验 | 返回参数错误,状态码 400 |

### Mock 策略

- **需要 Mock 的依赖**: 用户数据库、缓存服务
- **Mock 工具**: Mockito
- **测试数据策略**: 使用固定测试数据,避免随机数据

<<<Context:测试用例模板.md>>>

---

现在请为以下 API 生成测试用例:

API 名称: createOrder
功能: 创建订单
参数: userId, productId, quantity
返回: orderId, status

Few-shot tips:

  1. 示例数量: 通常 2-3 个就够了,太多反而会让提示词过长
  2. 示例质量: 确保示例本身是高质量的,因为大模型会模仿
  3. 示例多样性: 如果任务有多种情况,最好每种情况都给一个例子

第三步：让 AI 帮你优化提示词

为什么需要 AI 优化?

即使已经掌握了 COSTAR 框架和各种技巧,但要写出完美的提示词仍然不容易:

  • 可能遗漏了某些重要信息
  • 表达不够精确
  • 没有考虑到边界情况

让大模型帮你优化提示词，可以事半功倍。

三阶段优化流程

我总结了一个实用的三阶段流程:

阶段 1: 提示词优化阶段

目标: 让 AI 理解你的需求,并帮你完善提示词。

做法:

1
2
3
4
5
6
7
8
9
10
11
12
13

我需要让 AI 完成一个任务,但我的提示词可能不够完善。
请帮我分析并优化这个提示词。

我的原始需求:
[你的需求描述]

我当前的提示词:
[你写的提示词]

请帮我:
1. 指出提示词中可能存在的问题
2. 建议需要补充的信息
3. 给出优化后的版本

AI 会帮你:

  • 识别模糊不清的地方
  • 补充缺失的上下文
  • 调整表达方式
  • 优化结构和格式

阶段 2: 人工反馈阶段

目标: 你来审核 AI 优化后的提示词,给出反馈。

做法:

1
2
3
4
5
6
7

你优化后的提示词我看了,整体不错,但有几个地方需要调整:

1. [具体问题 1]
2. [具体问题 2]
3. [具体问题 3]

请根据我的反馈再次优化。

为什么需要这一步?

  • AI 可能误解了你的某些意图
  • 你可能想到了新的需求
  • 需要根据实际情况微调

这就像软件开发中的”迭代”过程,通过多轮反馈不断完善。

阶段 3: 任务执行阶段

目标: 使用优化后的提示词执行实际任务。

做法:

1
2
3

很好,现在请使用这个优化后的提示词,帮我完成实际任务:

[具体任务内容]

注意事项:

  • 如果结果不理想,回到阶段 2 继续优化
  • 记录下好用的提示词模板,方便以后复用
  • 不同类型的任务可能需要不同的优化策略

一个完整的例子

原始需求:

1

帮我写一个 Python 函数,计算斐波那契数列。

阶段 1: AI 优化

AI 可能会这样优化:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

请帮我编写一个 Python 函数,实现斐波那契数列的计算。

# Context
这个函数将用于一个算法学习平台,帮助学生理解递归和动态规划。

# Objective
1. 实现斐波那契数列计算
2. 提供两种实现方式:递归和动态规划
3. 添加详细的代码注释
4. 包含时间复杂度分析

# Style
代码风格遵循 PEP 8 规范,注释清晰易懂。

# Audience
面向有基础 Python 知识的编程学习者。

# Response
请提供:
1. 函数定义和实现
2. 使用示例
3. 性能对比说明

阶段 2: 人工反馈

1
2
3
4

优化得不错,但我还需要:
1. 添加输入参数的类型检查和异常处理
2. 提供单元测试用例
3. 说明两种方法的适用场景

阶段 3: 执行任务

使用最终优化后的提示词,AI 就能给出高质量的代码和文档。

优化提示词的通用模板

我整理了一个通用模板,你可以直接使用:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 任务背景
我需要 AI 帮我完成 [任务类型],目标是 [具体目标]。

# 当前问题
我写的提示词可能存在以下问题:
- [问题 1]
- [问题 2]

# 优化需求
请帮我:
1. 按照 COSTAR 框架重新组织提示词
2. 补充必要的上下文信息
3. 明确输出格式要求
4. 添加必要的约束条件

# 我的原始提示词
[你的提示词]

# 期望的优化方向
[你希望如何改进]

第四步：善用系统提示词

最后一个技巧,也是最容易被忽视的:系统提示词。

什么是系统提示词?

系统提示词(System Prompt)是在对话开始前,预先设定的”角色和规则”,相当于给 AI 设定了一个”人设”。

类比一下:

  • 用户提示词 = 你每次具体的问题
  • 系统提示词 = AI 的”职业设定”和”行为准则”

为什么系统提示词很重要?

关键发现: 系统提示词对模型行为的约束力,远强于用户提示词中的设定。

实验数据表明:

  • 使用系统提示词后,模型遵守约束的概率提升 40%+
  • 输出格式的一致性提高 60%+
  • 减少”创造性发挥”导致的偏差

系统提示词的三大作用

1. 定义角色与身份

告诉 AI “你是谁”,决定它的说话方式和专业程度。

示例:

1
2
3
4
5
6
7
8

你是一位资深的软件架构师和 TDD(测试驱动开发)专家,
精通六边形架构(Hexagonal Architecture)的设计原则。

你的专长包括:
- API 层设计(接口适配器)
- 应用层设计(应用服务)
- 领域层设计(业务逻辑核心)
- 基础设施层设计(外部依赖)

效果:

  • AI 会以专家的口吻回答
  • 回答会更专业、更深入
  • 会主动考虑架构层面的问题

2. 设定行为规范

控制 AI 的行为方式,确保输出符合你的期望。

示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

请严格遵循以下协议:

## 流程控制协议
- 按照 <<<Workflow>>> 定义的步骤顺序执行
- 每完成一个 <<<Task: [任务名称]>>>,输出: ✅ [任务名称] 已完成
- 收到用户明确确认后才可继续下一步

## 格式遵循协议
- 严格按照 <<<Context:[输出内容名称]>>> 要求输出
- 如果输出格式要求的内容不清楚,请明确询问而不是猜测
- 格式不明确的先询问: 📋 请确认输出格式要求

## 信息准确性协议
- 仅基于已验证的真实信息回答
- 信息不足时明确回复: ❌ 信息不足,无法提供准确回答
- 绝不生成虚构或推测性内容
- 遵循现有技术规范和架构约束

## 主动澄清协议
- 遇到模糊信息时立即询问: 💭 需要澄清:[具体问题]
- 获得明确回复后再继续执行

效果:

  • AI 会严格按照流程执行
  • 遇到不确定的情况会主动询问
  • 减少”自作主张”的情况

3. 限制知识范围与领域

让 AI 专注于特定领域,避免泛化或编造答案。

示例:

1
2
3
4
5
6
7

你只能基于公司内部文档提供客服支持,不得使用外部知识。

知识范围限制:
- 仅回答产品功能、使用方法、常见问题
- 不涉及公司战略、财务信息、未发布功能
- 遇到超出范围的问题,回复:"抱歉,这个问题超出了我的服务范围,
  建议您联系人工客服获取帮助。"

效果:

  • 避免 AI “发散思维”
  • 确保回答的准确性和一致性
  • 降低风险

系统提示词的最佳实践

1. 系统提示词可以引用用户提示词中的变量

这是一个很实用的技巧:

1
2
3
4
5
6
7
8
9
10
11

# 系统提示词
你是一位 [专业领域] 专家,请按照以下规则回答问题:
- 使用 <<<Context:[输出内容名称]>>> 中定义的格式
- 保持 [风格要求] 的表达方式

# 用户提示词
<<<Context:输出内容名称>>>
[具体格式定义]
<<<Context:输出内容名称>>>

请帮我 [具体任务]

好处:

  • 系统提示词更通用
  • 用户提示词更灵活
  • 两者配合更强大

2. 分层设计

将系统提示词分成几个层次:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 第一层:角色定义
你是一位 [角色]

# 第二层:核心能力
你擅长:
- [能力 1]
- [能力 2]

# 第三层:行为准则
你必须遵守:
- [规则 1]
- [规则 2]

# 第四层:输出规范
你的回答应该:
- [要求 1]
- [要求 2]

3. 使用清晰的标记

用特殊符号让 AI 更容易识别:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

**🎯 流程控制**
- 按步骤执行
- 等待确认

**📋 格式遵循**
- 严格按照模板
- 不添加额外说明

**✅ 信息准确性**
- 基于事实回答
- 不确定时询问

**💭 主动澄清**
- 遇到歧义立即询问
- 获得明确回复后继续

三、综合实际案例

案例背景

现在我是一个技术团队的负责人,需要让 AI 帮你为团队的 API 生成标准化的技术文档。这个任务涉及多个步骤,需要精心设计提示词才能得到高质量的输出。

第一步：选择表达框架 - 使用 COSTAR

首先,用 COSTAR 框架来组织用户提示词:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# Context (上下文)
我们正在开发一个 SaaS 平台的用户管理模块,需要为前端团队和第三方集成商提供标准化的 API 文档。

# Objective (目标)
请为"创建用户"API 生成完整的技术文档,包括:
1. 接口基本信息(URL、方法、认证方式)
2. 请求参数说明(类型、必填、校验规则)
3. 响应格式(成功和失败情况)
4. 错误码列表
5. 代码示例(cURL 和 JavaScript)

# Style (风格)
使用清晰的技术文档风格,专业但易懂,避免过于复杂的术语。

# Tone (语气)
保持客观中立,重点突出关键信息和注意事项。

# Audience (受众)
面向有一定开发经验的前端工程师和第三方集成商的技术人员。

# Response (响应格式)
请使用 Markdown 格式输出,包含清晰的章节划分和代码块。

第二步：选择表达方式 - 使用变量和 Few-shot

使用变量让提示词更灵活

我们可以把 API 的具体信息抽取成变量:

1
2
3
4
5
6
7

请为 <<<API名称>>> 生成技术文档。

API 基本信息:
- 路径: <<<API路径>>>
- 方法: <<<HTTP方法>>>
- 功能: <<<功能描述>>>
- 参数: <<<参数列表>>>

提供 Few-shot 示例

为了让 AI 理解我们期望的文档格式,提供一个完整的示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

参考以下示例格式:

**示例: 获取用户信息 API**

接口路径: GET /api/v1/users/{userId}

请求参数:
- userId (必填): 用户唯一标识

响应示例:
{
  "code": 0,
  "data": {
    "userId": "123",
    "username": "张三"
  }
}

---

现在请按照类似格式,为"创建用户"API 生成文档。

第三步：AI 优化提示词

在实际使用中,我们可以先让 AI 帮我们优化提示词:

第一轮 - 请求优化:

1
2
3
4

我需要让 AI 生成 API 文档,但我的提示词可能不够完善。
请帮我优化以下提示词,使其更清晰、更完整:

[你的初始提示词]

第二轮 - 人工反馈:

1
2
3
4

优化得不错,但还需要:
1. 增加错误处理的说明
2. 补充安全性注意事项
3. 添加性能优化建议

第三轮 - 执行任务:

1

很好,现在请使用优化后的提示词,为我生成实际的文档。

第四步：设置系统提示词

为了确保输出质量的一致性,我们设置系统提示词:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

你是一位资深的 API 文档工程师,专注于编写清晰、准确、易用的技术文档。

你的核心能力:
- 熟悉 RESTful API 设计规范
- 精通 OpenAPI/Swagger 标准
- 擅长用简洁的语言解释复杂的技术概念

你必须遵守:
- 使用标准的 Markdown 格式
- 确保所有示例代码可以直接运行
- 每个参数都要有清晰的说明
- 考虑各种边界情况和错误处理

你的输出应该:
- 结构清晰,层次分明
- 包含完整的代码示例
- 便于开发者快速上手

完整提示词示例

综合以上四步,最终的完整提示词如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# 系统提示词
你是一位资深的 API 文档工程师,专注于编写清晰、准确、易用的技术文档。

# 用户提示词
## Context
我们正在开发一个 SaaS 平台的用户管理模块,需要为开发者提供标准化的 API 文档。

## Objective
请为"创建用户"API 生成完整的技术文档。

## Style & Tone
使用清晰的技术文档风格,专业但易懂,保持客观中立。

## Audience
面向有一定开发经验的前端工程师和第三方集成商。

## Response
请使用 Markdown 格式,参考以下示例结构:

[示例文档结构]

## API 信息
- 路径: POST /api/v1/users
- 功能: 创建新用户账号
- 参数: username, email, password

预期效果

使用这套完整的提示词,AI 会生成:

  • ✅ 结构清晰的文档
  • ✅ 完整的参数说明
  • ✅ 可运行的代码示例
  • ✅ 详细的错误处理说明
  • ✅ 实用的注意事项

如果输出不理想,可以根据第三步的方法进行迭代优化,直到满意为止。

四、总结

  1. 选择一个科学的框架是基础

  2. 善用变量和模板
    • 让提示词更模块化
    • 提高复用性
    • 便于维护
  3. Few-shot 是利器
    • 示例比描述更直观
    • 能显著提升输出质量
    • 2-3 个示例通常就够了
  4. 让 AI 帮你优化提示词
    • 三阶段迭代流程
    • 不断完善和优化
    • 积累好用的模板
  5. 系统提示词是关键
    • 定义角色和能力
    • 设定行为规范
    • 限制知识范围

参考资源

COSTAR 框架出处

COSTAR 框架最早由新加坡政府科技局（GovTech）的数据科学与人工智能部门（DSAID）提出，旨在帮助开发者和用户更好地构建提示词。

相关资源：

其他参考资料

本文基于实际项目经验总结，COSTAR 框架引用自新加坡政府科技局，部分案例经过简化处理。

技术探索, 人工智能
LLM Prompt Engineering AI
本文由作者按照 CC BY 4.0 进行授权