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

我使用 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.在继续之前验证你的理解。

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

css 复制代码

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

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

自我批判输出结果

复制代码

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

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

结构化提示词 (Structured Prompting)

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

XML 示例：

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>

Markdown 示例：

markdown 复制代码

# Identity (身份)
你是一名高级解决方案架构师。

# Constraints (约束)
- 不允许使用外部库。
- 仅限 Python 3.11+ 语法。

# Output Format (输出格式)
返回单个代码块。

代理工具使用 (Agentic Tool Use)

持久性指令 (The Persistence Directive)

markdown 复制代码

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

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

计算前反思 (Pre-Computation Reflection)

复制代码

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

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

研究与分析

css 复制代码

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

创意写作

复制代码

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

问题解决

scss 复制代码

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

教育内容

复制代码

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

示例模板 (Example Template)

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

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

System Instruction (系统指令)

markdown 复制代码

<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 (用户提示词)

xml 复制代码

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

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

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

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