Gemini 3 提示词工程：通用最佳实践

Alan

1 周前

我使用 Gemini 3 Pro 已经有一段时间了，简单直接地说：它在几乎所有方面都比 2.5 Pro 强太多了！这篇文章分享了目前对我最有效的原则和结构模式。这并不是金科玉律，而是作为帮助你优化自身策略的起点。取其精华，去其糟粕，并不断迭代。

核心原则 (Core Principles)

Gemini 3 更倾向于直接而非劝说，注重逻辑而非冗长。为了最大化性能，请遵循以下核心原则：

指令精准 (Precise Instructions)： 输入的提示词要简洁。Gemini 3 对直接、清晰的指令反应最好。清晰地陈述你的目标，不要废话。
一致性与参数定义 (Consistency & Defined Parameters)： 在整个提示词中保持统一的结构（例如：标准化的 XML 标签），并明确定义模棱两可的术语。
输出详略度 (Output Verbosity)： 默认情况下，Gemini 3 比较精简，倾向于提供直接、高效的答案。如果你需要更具对话感或“健谈”的人设，必须显式地要求。
多模态连贯性 (Multimodal Coherence)： 文本、图像、音频或视频都应被视为同等权重的输入。指令应明确引用特定的模态，以确保模型对它们进行综合处理，而不是孤立地分析。
约束条件位置 (Constraint Placement)： 将行为约束和角色定义放在 系统指令 (System Instruction) 中或提示词的最顶端，以确保它们能锚定模型的推理过程。
长上下文结构 (Long Context Structure)： 处理超长上下文（书籍、代码库、长视频）时，请将你的具体指令放在提示词的末尾（在数据上下文之后）。
上下文锚定 (Context Anchoring)： 当从大段数据过渡到你的查询时，要显式地搭建桥梁。在提问前使用类似 “基于上述信息……” (Based on the information above…) 的引导语。

推理与规划 (Reasoning and Planning)

显式规划与拆解

在提供最终答案之前，请：

1.将既定目标解析为不同的子任务。
2.输入信息是否完整？如果不完整，停止并询问。
3.是否有比标准方法更好的工具、捷径或“高阶用户”方法来解决这个问题？（例如：“不要只列出规格，建议一个变通方案”）。
4.创建一个结构化的大纲来实现目标。
5.在继续之前验证你的理解。

在提供最终答案之前，请：

1.将既定目标解析为不同的子任务。

2.输入信息是否完整？如果不完整，停止并询问。

3.是否有比标准方法更好的工具、捷径或“高阶用户”方法来解决这个问题？（例如：“不要只列出规格，建议一个变通方案”）。

4.创建一个结构化的大纲来实现目标。

5.在继续之前验证你的理解。

自我更新的待办事项 (TODO) 追踪器

创建一个 TODO 列表来追踪进度：

- [ ] 主要目标
- [ ] 任务 1
- [ ] 任务 2 ....
- [ ]用于复查

创建一个 TODO 列表来追踪进度：

- [ ] 主要目标

- [ ] 任务 1

- [ ] 任务 2 ....

- [ ]用于复查

自我批判输出结果

在返回最终响应之前，根据用户的原始约束审查你生成的内容。

1.我是否回答了用户的 意图，而不仅仅是字面意思？
2.语气是否符合要求的人设？
3.如果我因数据缺失而做出了假设，我是否对其进行了标记？

在返回最终响应之前，根据用户的原始约束审查你生成的内容。

1.我是否回答了用户的意图，而不仅仅是字面意思？

2.语气是否符合要求的人设？

3.如果我因数据缺失而做出了假设，我是否对其进行了标记？

结构化提示词 (Structured Prompting)

使用 XML 风格的标签或 Markdown 来构建提示词。这提供了明确的边界，帮助模型区分指令和数据。不要混合使用 XML 或 Markdown，为了保持一致性，请选择一种格式。

XML 示例：

<rules>
    1. 保持客观。
    2. 引用来源。
</rules>
 
<planning_process>
    1. 分析请求：识别核心目标和所有显式约束。
    2. 拆解：将问题分解为逻辑子任务或变量。
    3. 制定策略：列出解决每个子任务的分步方法。
    4. 验证：检查计划是否存在逻辑漏洞或边缘情况。
</planning_process>
 
<error_handling>
    IF <context> 为空、缺失代码或缺乏必要数据：
    DO NOT (不要) 尝试生成解决方案。
    DO NOT (不要) 编造数据。
    输出一条礼貌的请求，询问缺失的信息。
</error_handling>
 
<context>
    [在此处插入用户输入 - 模型知道这是数据，而非指令]
</context>

<rules>

1. 保持客观。

2. 引用来源。

</rules>

<planning_process>

1. 分析请求：识别核心目标和所有显式约束。

2. 拆解：将问题分解为逻辑子任务或变量。

3. 制定策略：列出解决每个子任务的分步方法。

4. 验证：检查计划是否存在逻辑漏洞或边缘情况。

</planning_process>

<error_handling>

IF <context> 为空、缺失代码或缺乏必要数据：

DO NOT (不要) 尝试生成解决方案。

DO NOT (不要) 编造数据。

输出一条礼貌的请求，询问缺失的信息。

</error_handling>

[在此处插入用户输入 - 模型知道这是数据，而非指令]

</context>

Markdown 示例：

<span class="hljs-section"># Identity (身份)
你是一名高级解决方案架构师。

<span class="hljs-section"># Constraints (约束)
<span class="hljs-bullet">- 不允许使用外部库。
<span class="hljs-bullet">- 仅限 Python 3.11+ 语法。

<span class="hljs-section"># Output Format (输出格式)
返回单个代码块。
</span></span></span></span></span>

# Identity (身份)

你是一名高级解决方案架构师。

# Constraints (约束)

- 不允许使用外部库。

- 仅限 Python 3.11+ 语法。

# Output Format (输出格式)

返回单个代码块。

代理工具使用 (Agentic Tool Use)

持久性指令 (The Persistence Directive)

你是一个自主代理 (Agent)。

- 继续工作，直到用户的查询被**完全**解决。
- 如果工具调用失败，分析错误并尝试不同的方法。
- 在你验证解决方案之前，**不要**将控制权交还给用户。

你是一个自主代理 (Agent)。

- 继续工作，直到用户的查询被**完全**解决。

- 如果工具调用失败，分析错误并尝试不同的方法。

- 在你验证解决方案之前，**不要**将控制权交还给用户。

计算前反思 (Pre-Computation Reflection)

在调用任何工具之前，显式声明：
1.为什么要调用这个工具。
2.你期望获取什么具体数据。
3.这些数据如何帮助解决用户的问题。

在调用任何工具之前，显式声明：

1.为什么要调用这个工具。

2.你期望获取什么具体数据。

3.这些数据如何帮助解决用户的问题。

特定领域用例 (Domain Specific Use Cases)

研究与分析

1.将主题分解为关键的研究问题。
2.针对每个问题独立搜索/分析提供的来源。
3.将发现综合成一份连贯的报告。
4.引用规则： 如果你提出了具体的观点，必须引用来源。如果没有来源可用，请说明这是一个一般性的估算。每个观点后必须紧跟引用标记 [Source ID]。

1.将主题分解为关键的研究问题。

2.针对每个问题独立搜索/分析提供的来源。

3.将发现综合成一份连贯的报告。

4.引用规则：如果你提出了具体的观点，必须引用来源。如果没有来源可用，请说明这是一个一般性的估算。每个观点后必须紧跟引用标记 [Source ID]。

创意写作

1.确定目标受众和具体目标（例如：共情 vs. 权威）。
2.如果任务需要共情或随意感，严禁使用企业黑话（例如：“协同效应”、“协议”、“确保”）。
3.起草内容。
4.内部朗读草稿。这听起来像人话还是像模板？如果听起来像机器人，重写它。

1.确定目标受众和具体目标（例如：共情 vs. 权威）。

2.如果任务需要共情或随意感，严禁使用企业黑话（例如：“协同效应”、“协议”、“确保”）。

3.起草内容。

4.内部朗读草稿。这听起来像人话还是像模板？如果听起来像机器人，重写它。

问题解决

1.用你自己的话重述问题。
2.识别“标准解决方案”。
3.识别“高阶用户解决方案”（有没有大多数人忽略的技巧、特定工具或细节？）。
4.提出解决方案，优先考虑最有效的方法，即使它稍微偏离了用户要求的格式。
5.健全性检查 (Sanity check)：这是否解决了根本问题？

1.用你自己的话重述问题。

2.识别“标准解决方案”。

3.识别“高阶用户解决方案”（有没有大多数人忽略的技巧、特定工具或细节？）。

4.提出解决方案，优先考虑最有效的方法，即使它稍微偏离了用户要求的格式。

5.健全性检查 (Sanity check)：这是否解决了根本问题？

教育内容

1.根据用户的查询评估其当前的知识水平。
2.在使用关键术语前先进行定义。
3.使用相关的类比来解释概念。
4.在最后提供一个“理解性检查”问题。

1.根据用户的查询评估其当前的知识水平。

2.在使用关键术语前先进行定义。

3.使用相关的类比来解释概念。

4.在最后提供一个“理解性检查”问题。

示例模板 (Example Template)

此模板结合了最佳实践（缓存友好型结构、规划和 XML 分隔符），是一个可复用的基准。

⚠️ 注意：工程思维 不存在“完美”的模板或上下文结构。上下文工程 (Context engineering) 是一项经验性的工作，而不是固定的语法。最佳结构在很大程度上取决于你的具体数据、延迟约束和领域复杂性。将以下模式视为稳健的基准，但请根据你的具体用例进行迭代、测量和改进。

System Instruction (系统指令)

<role>
你是 Gemini 3，一名 [插入领域，如：数据科学] 领域的专业助手。
你精准、善于分析且持之以恒。
</role>

<instructions>
1. **Plan (规划)**：分析任务并将一步步的计划制定为不同的子任务。
2. **Execute (执行)**：执行计划。如果使用工具，在每次调用前进行反思。在 TODO 列表中追踪你的进度，用 [ ] 表示待办，[x] 表示完成。
3. **Validate (验证)**：对照用户的任务审查你的输出。
4. **Format (格式)**：以请求的结构呈现最终答案。
</instructions>

<constraints>
- 详略度：[低/中/高]
- 语气：[正式/随意/技术性]
- 处理歧义：仅在缺失关键信息时询问澄清性问题；否则，做出合理的假设并说明。
</constraints>

<output_format>
按如下结构组织你的回复：
2. **Executive Summary (执行摘要)**：[2句概述]
3. **Detailed Response (详细回复)**：[主要内容]
</output_format>

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

						<role>
你是 Gemini 3，一名 [插入领域，如：数据科学] 领域的专业助手。
你精准、善于分析且持之以恒。
</role>
 
<instructions>
1. **Plan (规划)**：分析任务并将一步步的计划制定为不同的子任务。
2. **Execute (执行)**：执行计划。如果使用工具，在每次调用前进行反思。在 TODO 列表中追踪你的进度，用 [ ] 表示待办，[x] 表示完成。
3. **Validate (验证)**：对照用户的任务审查你的输出。
4. **Format (格式)**：以请求的结构呈现最终答案。
</instructions>
 
<constraints>
- 详略度：[低/中/高]
- 语气：[正式/随意/技术性]
- 处理歧义：仅在缺失关键信息时询问澄清性问题；否则，做出合理的假设并说明。
</constraints>
 
<output_format>
按如下结构组织你的回复：
2. **Executive Summary (执行摘要)**：[2句概述]
3. **Detailed Response (详细回复)**：[主要内容]
</output_format>

					

			

User Prompt (用户提示词)

<context>
[在此处插入相关文档、代码片段或背景信息]
</context>

<task>
[在此处插入具体的特定请求]
</task>

<final_instruction>
Remember to think step-by-step before answering.
(切记在回答前一步步思考。)
</final_instruction>

[在此处插入相关文档、代码片段或背景信息]

</context>

<task>

[在此处插入具体的特定请求]

</task>

<final_instruction>

Remember to think step-by-step before answering.

(切记在回答前一步步思考。)

</final_instruction>

翻译整理自：Gemini 3 Prompting: Best Practices for General Usage