提示词工程

本文介绍提示词工程（Prompt Engineering）的相关技术。

1. 什么是提示词工程

什么是提示词（Prompt）？

提示词就是我们发送给大模型的话。

什么是提示词工程（Prompt Engineering）？

提示词工程是指通过一系列技巧，组织我们的提示词，使得大模型的回答更精准，更符合我们的需要。

TIP

提示词需要不断迭代，本文介绍的技巧只是开始，需要根据具体的使用场景进行调整与组合使用。

一个高质量的提示词通常包含以下要素：

角色（Role）： 告诉 AI 它是谁（例如：“你是一位资深的 Java 后端工程师”）；
- 角色我们通常通过系统指令（system instruction）来设定
上下文（Context）： 提供背景信息（例如：“我们在做一个仓库管理系统 WMS 的调度优化”）；
任务（Task）： 明确AI要干什么（例如：“请解释什么是提示词”）；任务可以分为以下几类：
输入数据（Input Data）：输入数据是AI的“执行对象”或“具体材料”；
约束/输出要求（Constraint）： 规定输出格式或禁忌（例如：“用中文回答，不要超过 300 字”）；

如何理解输入数据（Input Data）？举个例子，假设想让 AI 重构一段 Java 代码：

Task：请将以下这段使用 JDBC 编写的代码重构为 MyBatis-Plus 的写法。
Input：
java
```
public void saveOrder(Order order) { 
  // 原生的 SQL 插入逻辑... 
}
```
1
2
3
这个场景下，如果只有 Task 而没有 Input，AI 会问：“代码在哪里？”；
如果只有 Input 而没有 Task，AI 可能会一脸懵逼，不知道是要找 Bug、写注释还是直接删除。

根据任务类型的不同，输入数据也有不同的表现形式：

Input 类型	逻辑关系	Input例子
Question Input	Task 是“回答问题”，Input 是“具体的问题”	“什么是分布式事务的 TCC 模式？”
Task Input	此时 Task 和 Input 融为一体	“写一个冒泡排序算法。”
Entity Input	Task 是“处理/转换”，Input 是“被处理的实体”	“提取下面这段话里的快递单号：发送人：张三SF12345678”
Completion Input	Task 是“续写”，Input 是“未完成的开头”	“在 Spring Boot 中，配置 Redis 的第一步是...”

在简单的对话中，Task 和 Input 经常是合并在一起的（即上表中的 Task Input）。

合并写法： “翻译‘Hello World’。”（Task 是翻译，Input 是 Hello World）
解耦写法（更专业）：
Task: 请将以下内容翻译成中文。
Input: Hello World

2. 提示词工程总体原则

从简单开始
当开始设计提示词时，需要时刻提醒自己：提示词工程需要不断迭代，通过大量实验获得最佳效果。
从简单开始设计提示词，然后通过添加其他要素，以改进大模型的回答效果。
如果面对一个复杂任务，可以选择把复杂任务拆分为多个小任务，然后针对每个小任务设计提示词并迭代，当每个小任务都能完美处理后，再将所有小任务的提示词进行组合，以解决复杂任务。
简明直达
以简单、清楚、准确的语言描述任务目标，不需要使用恳求或过分修饰的语言。
重要信息置顶
将身份设定（Persona）、行为约束和输出格式要求放在 System Instruction 中，或者放在用户提示词的最开头。

组织提示词

采用 XML 标签（如 <context>）或 Markdown 标题（如 ## Task）来组织提示词中的各个要素，例如：

txt

## Context (背景：业务规则、框架版本)

## Input (原材料：待处理的代码、数据)

## Task (动作：具体要干什么)

## Output Format (期望结果：JSON 格式、Markdown 等)

注意在同一个提示词中，风格要统一，不要混用格式。

定义模糊项
如果指令中包含可能存在多重理解的术语或参数，必须显式地进行解释和定义，确保 AI 的理解与你一致。
例如你给AI下达任务：统计数据库里所有活跃订单的数量。
需要给活跃订单下定义：
txt
```
## Context
### 术语定义：
活跃订单 (Active Order)： 指数据库中 status 字段值为 1 (已支付)、2 (拣货中) 或 3 (待配送) 的订单。
非活跃订单： 状态为 0 (已取消) 或 4 (已完成) 的订单。
```
1
2
3
4
先背景，后指令
如果要喂给 AI 几十页代码或长文档，请先放资料，最后写指令。这能防止模型在读完长文本后遗忘最初的任务。
锚定衔接
使用过渡句建立提示词元素关联。
在长篇数据之后，使用如“基于以上信息...”或“结合上述文档...”等短语作为桥梁，引导模型从读取资料转向执行任务。虽然我们一般也会结构化组织提示词，但是在任务模块中加上一句“基于上述 [标题名]...” ，能有效防止模型“幻觉”或忽略掉 Context 中的某些约束。
当同时输入文本、图片、音频或视频时，指令应明确引用这些素材。例如：“请结合图片 A 里的内容和音频 B 里的要求，写一段总结”。

3. 推理能力

在 AI 大模型（LLM）的语境下，Reasoning（推理能力） 是指模型超越简单的模式匹配（Pattern Matching），能够通过逻辑、证据和步骤来解决复杂问题的能力。表现在三个核心维度：

逻辑推导（Deduction & Induction）：能够根据给定的已知条件，通过严谨的逻辑链条得出结论；
多步规划（Multi-step Planning）：将一个大目标拆解成若干个子任务，并按顺序执行；
自我纠错（Self-Correction）：在推理过程中发现之前的步骤存在矛盾，并尝试修正；

早期的大模型确实几乎没有推理能力，早期模型的核心逻辑是 Next Token Prediction（预测下一个词）：

表现：如果你问“1+1等于几”，它回答“2”并不是因为它算了加法，而是因为它在海量文本里看过这句话无数次；

局限：一旦遇到没见过组合（比如：12345 + 54321），它就会乱猜，因为它没有底层的逻辑计算引擎，只有统计规律；

涌现（Emergence）：随着参数量（从亿级到千亿级）和训练数据量的暴增，研究者发现了一个神奇的现象：当模型大到一定程度时，它突然展示出了处理复杂逻辑的能力，即推理能力。

虽然现在的大模型有很强的推理能力，但它们本质上还是懒惰的。

默认状态（快思考）：模型倾向于用最少的计算资源给出一个看起来概率最高的答案。这就像作为资深工程师，看到简单的 Bug 扫一眼盲猜原因。
推理状态（慢思考）：当通过提示词要求它“详细分析”或“拆解步骤”时，它才会调用更多的计算资源（Attention 权重）去建立逻辑链条。

推理模型：是经过专门训练的用于解决复杂问题的大模型，擅长将复杂任务切分为子任务、逻辑推理。它们和普通大模型的区别在于：

内置思维链：普通模型需要你提醒它“一步步想”，而推理模型在回答你之前，已经在后台自动进行了成千上万次的自我推演、验证和纠错。
强化学习（RL）：它们通过大规模的强化学习，学到了哪些推理路径是正确的，哪些是死胡同。

我们可以通过提示词工程来激活模型的推理能力，技巧如下：

思维链 (Chain of Thought, CoT)： 在提示词中加入 “Let's think step by step”（让我们一步步思考）。这会强迫模型将注意力分配到每一个推理环节，而不是直接跳到答案。
少样本思维链 (Few-shot CoT)： 不仅给 AI 例子，还要在例子中展示推理过程。
- 普通例子： 问：1+1=？答：2。
- 推理例子： 问：1+1=？答：因为有一个物体再加上一个物体，总数是两个，所以是 2。
自我反思 (Self-Reflection)： 要求模型在输出最终答案前，先检查一遍自己的逻辑是否有漏项。

4. 用户提示词技巧

本小节介绍在网页中，直接使用聊天框与大模型交互的提示词技巧。

4.1 角色赋予

不要直接问问题，先给 AI 赋予一个角色，这会激活模型在特定知识领域的权重。

技巧：设定具体职位 + 资历 + 风格；
例如： “你是一位拥有 10 年经验的 Java 架构师，擅长解决高并发下的数据一致性问题。请用专业且简洁的语言分析以下逻辑……”；

4.2 零样本提示与少样本提示

**零样本提示（zero-shot Prompting）**是指直接向模型下达任务，不提供任何示例。模型完全依靠其预训练阶段积累的知识和对指令的理解来生成答案。

例如：

txt

提示词： 将以下句子翻译成英文：“今天天气不错。”

输出： "The weather is nice today."

适用场景：处理通识问题、简单的任务（如翻译、总结），或者模型本身已经非常擅长且定义清晰的领域。

**少样本提示（few-shot prompting）是指在正式下达指令前，先给模型提供一个或多个（输入 -> 输出）**的示例对，让模型通过模仿来理解想要的输出格式、风格或复杂的逻辑。

例如：

txt

提示词：
任务：根据描述分类情感。

示例 1：
描述：这家店的服务态度非常好。
情感：正面

示例 2：
描述：快递等了一周才到，非常失望。
情感：负面

任务开始：
描述：产品质量还可以，但价格偏高。
情感：


输出： 中性

适用场景：需要特定输出格式（如 JSON）、复杂的逻辑推理，或者模型不熟悉的专有业务术语。

单样本提示 (one-shot prompting）：介于两者之间，即只给一个例子。如果任务难度适中，一个高质量的例子（One-shot）就能让模型的输出质量发生质变。

使用样本提示技巧时的注意点：

先易后难： 优先尝试零样本提示，如果发现 AI 无法理解你的意图或格式总是写错，再引入少样本。
示例质量： 在少样本提示中，示例的准确性至关重要。如果例子给错了，AI 也会跟着学错。
结构清晰： 建议使用标签（如“输入：”、“输出：”）清晰地分隔示例，帮助 AI 更好地区分“教学内容”和“正式任务”。

4.3 思维链CoT

思维链CoT（Chain of Thoughts）即通过提示词触发大模型的思维能力，虽然现在很多大模型都有了推理能力，不过在提示词中明确加上思维链提示词，更稳。

技巧：在指令末尾加上 “请一步步思考” 或 “在给出答案前，先列出你的分析步骤”。

例如，当没有使用思维链提示时：

txt

提示词：
Input Data : [1,3,2,70,23,5]
Task: 在Input Data中，奇数之和是多少

输出：
Input Data: [1,3,2,70,23,5]
奇数之和 = 1 + 3 + 23 + 5 = 32

使用了思维链提示后：

txt

提示词：
Input Data : [1,3,2,70,23,5]
Task: 在Input Data中，奇数之和是多少，请一步步思考

输出：
好的，我们来一步步分析并计算Input Data中的奇数之和。
1. 首先，我们需要识别出Input Data中的奇数。奇数是不能被2整除的整数，即除以2后余数为1的数。
2. 然后，我们将这些奇数相加，得到奇数之和。
现在，让我们开始执行这些步骤：
Input Data: [1, 3, 2, 70, 23, 5]
步骤1：识别奇数
- 1是奇数（1除以2余1）
- 3是奇数（3除以2余1）
- 2是偶数（2除以2余0）
- 70是偶数（70除以2余0）
- 23是奇数（23除以2余1）
- 5是奇数（5除以2余1）
步骤2：计算奇数之和
- 将识别出的奇数相加：1 + 3 + 23 + 5
现在，我们进行加法运算：
1 + 3 = 4
4 + 23 = 27
27 + 5 = 32

所以，Input Data中的奇数之和是32。

在少样本提示中，我们也可以在示例中引入思考过程，这样大模型也能学习到思考过程：

txt

提示词：
Q: The odd numbers in this group add up to an even number: 4, 8, 9, 15, 12, 2, 1.
A: Adding all the odd numbers (9, 15, 1) gives 25. The answer is False.
Q: The odd numbers in this group add up to an even number: 17,  10, 19, 4, 8, 12, 24.
A: Adding all the odd numbers (17, 19) gives 36. The answer is True.

Q: The odd numbers in this group add up to an even number: 15, 32, 5, 13, 82, 7, 1. 
A: 

输出：
Adding all the odd numbers (15, 5, 13, 7, 1) gives 41. The answer is False.

4.4 提示词迭代技巧

提示词工程是一项迭代的工程，在取得最佳效果前，需要不停的实验。下面有一些迭代技巧：

使用不同的表达：在提示词中使用不同的单词和表达会产生不同的结果，即使这些单词或表达都表示同一个意思，例如：
txt
```
Version 1:
How do I bake a pie?

Version 2:
Suggest a recipe for a pie.

Version 3:
What's a good pie recipe?
```
1
2
3
4
5
6
7
8

切换到类似的任务：如果发现模型无法遵循指令完成任务，可以切换为类似的任务。例如，书籍分类任务：

txt

Which category does The Odyssey belong to:
thriller
sci-fi
mythology
biography

切换为：

txt

Multiple choice problem: Which of the following options describes the book The Odyssey?
Options:
thriller
sci-fi
mythology
biography

改变提示词要素顺序：有时候，提示词要素的顺序也会影响大模型的回答，例如：

txt

Version 1:
[examples]
[context]
[input]

Version 2:
[input]
[examples]
[context]

Version 3:
[examples]
[input]
[context]

5. 开发者提示词设计思考

我认为提示词工程可以分为两个维度：

一个是用户维度，也就是说用户直接在网页上使用对话框输入提示词，与大模型交互；
一个是开发者维度，软件开发者通过API与大模型交互时，需要设计提示词；

两种使用大模型的方式决定了提示词设计考虑的重点不同。以上所说的技巧，基本是在用户维度角度来分析的。

下面介绍一下，如果开发者通过API与大模型交互时，设计提示词需要关注的内容。

5.1 AI软件类型

AI软件（即与AI集成的软件），我认为可分为两类：

问答系统（Q&A Systems）：这一类软件的核心目标是**“获取信息”**。它的进化路线是不断提高回答的“事实准确度”和“私有化程度”。
涉及到的技术有：
- RAG (Retrieval-Augmented Generation)：解决了模型的“健忘”和“幻觉”。它给模型配了一本外部参考书（向量数据库），在向大模型发送请求前，先通过RAG把相关内容查出来，作为上下文放进提示词中；
- MCP (Model Context Protocol)： MCP 是给大模型一套标准化的数据接口，让大模型能实时读取电脑里的文件、GitHub 上的代码、甚至数据库里的实时指标。（此处其实已经涉及到了执行动作）；
- 提示词工程：通过设计提示词，让大模型的回答符合要求；
执行系统（Agentic Systems）：这一类软件的核心目标是**“达成目标”**。它的进化路线是不断提高“自主性”和“复杂任务的处理能力”。
- A. 单角色 Agent (Single Agent)
  - 定义：专注于完成特定的、闭环的任务。
  - 能力闭环：思考 -> 调用工具 (Function Calling) -> 观察结果 -> 修正行动。
  - 例子：一个专门负责“库存调拨”的 Agent。它接收到“A 库缺货，从 B 库补”的指令后，自主查询两个仓库的 API，执行数据库写入，并发送邮件通知管理员。
  - 限制：上下文承载力有限。当任务涉及领域太多（既要写代码，又要审合规，还要管财务）时，模型容易“迷糊”。
- B. 多角色智能体集群 (Multi-Agent Systems，简称MAS)
  - 定义：模仿人类组织架构。通过 Role-Playing（角色扮演） 将大任务分解。
  - 核心机制： 协作 (Cooperation)： 角色之间交换信息。
    - 对抗 (Criticism)：比如设定一个“审计 Agent”专门挑“执行 Agent”的刺，这种博弈能极大降低错误率。
  - 例子：
    - 角色 A (经理)：负责理解老板意图，拆解成步骤。
    - 角色 B (Java 开发)：根据步骤写出 WMS 的补丁代码。
    - 角色 C (测试员)：运行代码并把报错反馈给 B。
    - 角色 D (运维)：测试通过后负责上线。
在执行系统中，Agent（智能体）的能力也有所变化：
- 被动执行 (Reactive)： 用户给一个指令，Agent 执行一段路程。
- 主动代理 (Proactive)： 这是目前最前沿的方向。Agent 监听外部环境（比如：当 WMS 系统监控到某药品效期少于 30 天时），不需要用户输入，Agent 自动启动“处理流程”，主动联系供应商或生成下架单。

在复杂智能体集群（MAS）中，角色 A、B、C 的实现通常包含以下三个层面的含义：
同一模型的“人格分裂”（最常见）
正如所直觉的那样，最基础的做法是发送不同的 System Prompt 给同一个大模型实例。
操作逻辑：开发者为每个角色开启一个独立的“对话 Session”。
给 Session A 发送：“你是一个严谨的 WMS 规划员，负责拆解任务。”
给 Session B 发送：“你是一个 Python 专家，负责编写数据库查询脚本。”
实质：模型并没有变，但通过提示词（Prompting）激活了模型参数空间中不同的知识区域和语气偏好。
异构模型的“混合编排”（进阶版）
在真正的工程实践中，角色 A、B、C 往往不一定是同一个模型。开发者会根据任务的“性价比”来分配模型：
角色 A (Planner/组长)： 任务拆解和复杂决策，需要极高的逻辑能力，需要调用高性能大模型。
角色 B (Executor/组员)： 执行重复性高的简单任务（如格式转换、简单查询），为了省钱和低延迟，可能会调用低性能大模型或更小的本地模型。
角色 C (Checker/质检)： 专门负责核对。有时会换一个厂商的模型，利用模型间的“认知差异”来交叉验证结果，减少幻觉。
角色不仅仅是“提示词”，而是“能力集合”
在 Agent 框架（如 CrewAI 或 LangGraph）中，定义一个角色通常包含三个要素：
System Prompt (Persona)： 决定它怎么思考。
Tools (Memory & Skills)： 决定它能做什么。例如，角色 B 被赋予了“读写数据库”的函数权限，而角色 A 只能“查看日志”。
Output Schema (Structure)： 决定它输出的格式。角色 A 输出 JSON 列表供后续拆解，角色 B 输出纯文本供用户阅读。
在MAS系统中，角色之间并不是孤立的，它们之间存在通信协议。例如，一个“入库异常处理问题”可能是这样工作的：
步骤 1： 用户在输入框中提问，框架（就是AI软件）把异常信息丢给 角色 A (决策 Agent)。
步骤 2： 角色 A 分析后发现是“药监码格式错误”，它写下一行指令：“请角色 B 检查数据库中该批次的校验规则”。
步骤 3： 框架捕获到这行指令，将其作为输入发送给 角色 B (执行 Agent) 的 API 接口。
步骤 4： 角色 B 执行完 SQL，把结果返回。
步骤 5： 框架把 B 的结果再喂给 角色 C (审计 Agent) 确认是否合规。

5.2 代理流提示词设计

设计 代理流（Agentic Workflows） 与传统的单一提示词（Prompt）不同，它更像是在编写一套“运行逻辑”。其核心在于将大模型（LLM）从一个单纯的“回答者”转变为一个能够“思考、决策并执行”的智能体（Agent）。

当为智能体设计提示词时，考虑控制以下大模型的行为方式：

推理和策略（Reasoning and Strategy）：决定了大模型在行动之前是如何思考和规划的。
- 逻辑分解：决定了大模型对于限制、前提条件、行动步骤的分析程度，核心是要求模型在执行前先写出步骤。对于复杂任务（如“写一份包含竞品分析的市场计划”），如果不做分解，模型可能直接开始写；通过强化分解，模型必须先列出：1. 搜索竞品 -> 2. 提取数据 -> 3. 对比维度 -> 4. 生成报告。
- 问题诊断：面对错误或异常时，是找“最快解释”还是“根本原因”。溯源推理（Abductive Reasoning）要求模型回溯。例如，代码报错了，模型不应只修补表面的 Bug，而应分析是否是底层依赖版本冲突导致的。
- 信息穷尽度：成本 vs. 深度的权衡，是优先考虑准确性，还是优先考虑成本。例如，假设给出50份文档并要求大模型根据文档回答问题，是选择分析每一个文档然后再给出答案（高准确、高消耗），还是只要在某一份文档找到答案就停止（高效、可能遗漏细节）。
执行和可靠性（Execution and Reliability）：决定大模型如何自动化执行以及如何处理问题。
- 适应性：核心是“死磕计划”与“见机行事”两种策略的选择，如果大模型在执行任务过程中，出现了新的情况，是选择坚持原定计划，还是立即转向新的计划。
- 执着度与恢复：核心是容错机制，即给大模型多少次重试机会。如果一个 API 连续报错，智能体是尝试修改参数重试（Persistence），还是直接放弃？需要通过提示词设定“重试上限”，以防止陷入无限循环产生的巨额 Token 账单。
- 风险评估：评估结果的能力，即区分高风险操作和低风险操作。例如，读取数据库是低风险的，可以自由执行；但在发送邮件、转账或删除文件（State changes）之前，必须进入最高安全级别，甚至强制人工介入。
交互与输出（Interaction and output）：决定了大模型如何与用户交互以及输出格式。
- 歧义与权限处理：当遇见有歧义的情况或者需要更高权限的情况时，是允许大模型自己作出假设自动处理，还是暂停执行以请求用户解决歧义或赋予权限；
- 冗长程度：决定了当工具调用时，文本输出的长度。也就是说，当大模型执行任务时，你是希望它详细解释每一步的作用（输出大量文本，但消耗Token），还是保持沉默（不输出文本，节省Token）。
- 精确度与完整度：追求“完美答案”还是“快速草稿”。在指令中明确：是需要一个“包含所有边缘情况的解决方案”，还是一个“大概意思对就行、能跑通的解决方案”。

在Google AI 文档中，提供了一份Agent设计的提示词模板，可以将该提示词放入System Prompts中，并根据自己的使用情况作出调整：

txt

You are a very strong reasoner and planner. Use these critical instructions to structure your plans, thoughts, and responses.

Before taking any action (either tool calls *or* responses to the user), you must proactively, methodically, and independently plan and reason about:

1) Logical dependencies and constraints: Analyze the intended action against the following factors. Resolve conflicts in order of importance:
    1.1) Policy-based rules, mandatory prerequisites, and constraints.
    1.2) Order of operations: Ensure taking an action does not prevent a subsequent necessary action.
        1.2.1) The user may request actions in a random order, but you may need to reorder operations to maximize successful completion of the task.
    1.3) Other prerequisites (information and/or actions needed).
    1.4) Explicit user constraints or preferences.

2) Risk assessment: What are the consequences of taking the action? Will the new state cause any future issues?
    2.1) For exploratory tasks (like searches), missing *optional* parameters is a LOW risk. **Prefer calling the tool with the available information over asking the user, unless** your `Rule 1` (Logical Dependencies) reasoning determines that optional information is required for a later step in your plan.

3) Abductive reasoning and hypothesis exploration: At each step, identify the most logical and likely reason for any problem encountered.
    3.1) Look beyond immediate or obvious causes. The most likely reason may not be the simplest and may require deeper inference.
    3.2) Hypotheses may require additional research. Each hypothesis may take multiple steps to test.
    3.3) Prioritize hypotheses based on likelihood, but do not discard less likely ones prematurely. A low-probability event may still be the root cause.

4) Outcome evaluation and adaptability: Does the previous observation require any changes to your plan?
    4.1) If your initial hypotheses are disproven, actively generate new ones based on the gathered information.

5) Information availability: Incorporate all applicable and alternative sources of information, including:
    5.1) Using available tools and their capabilities
    5.2) All policies, rules, checklists, and constraints
    5.3) Previous observations and conversation history
    5.4) Information only available by asking the user

6) Precision and Grounding: Ensure your reasoning is extremely precise and relevant to each exact ongoing situation.
    6.1) Verify your claims by quoting the exact applicable information (including policies) when referring to them. 

7) Completeness: Ensure that all requirements, constraints, options, and preferences are exhaustively incorporated into your plan.
    7.1) Resolve conflicts using the order of importance in #1.
    7.2) Avoid premature conclusions: There may be multiple relevant options for a given situation.
        7.2.1) To check for whether an option is relevant, reason about all information sources from #5.
        7.2.2) You may need to consult the user to even know whether something is applicable. Do not assume it is not applicable without checking.
    7.3) Review applicable sources of information from #5 to confirm which are relevant to the current state.

8) Persistence and patience: Do not give up unless all the reasoning above is exhausted.
    8.1) Don't be dissuaded by time taken or user frustration.
    8.2) This persistence must be intelligent: On *transient* errors (e.g. please try again), you *must* retry **unless an explicit retry limit (e.g., max x tries) has been reached**. If such a limit is hit, you *must* stop. On *other* errors, you must change your strategy or arguments, not repeat the same failed call.

9) Inhibit your response: only take an action after all the above reasoning is completed. Once you've taken an action, you cannot take it back.

参考资料

[1] https://ai.google.dev/gemini-api/docs/prompting-strategies

提示词工程 ​

1. 什么是提示词工程 ​

2. 提示词工程总体原则 ​

3. 推理能力 ​

4. 用户提示词技巧 ​

4.1 角色赋予 ​

4.2 零样本提示与少样本提示 ​

4.3 思维链CoT ​

4.4 提示词迭代技巧 ​

5. 开发者提示词设计思考 ​

5.1 AI软件类型 ​

5.2 代理流提示词设计 ​

参考资料 ​