Gemini 3 提示词最佳实践指南

我使用 Gemini 3 Pro 已经有一段时间了，简单来说：它在几乎所有方面都比 2.5 Pro 强太多了！这篇文章分享了目前对我最有效的原则和结构化模式。这并不是要作为黄金标准，而是作为一个起点，帮助你优化自己的策略。取其精华，调整不合适的部分，持续迭代。

核心原则

Gemini 3 更偏好直接表达而非说服性语言，偏好逻辑而非冗长。为了最大化性能，请遵循以下核心原则：

• 精确的指令： 输入提示词要简洁。Gemini 3 对直接、清晰的指令响应最好。清楚地陈述你的目标，不要有废话。
• 一致性和明确的参数： 在提示词中保持统一的结构（例如，标准化的 XML 标签），并明确定义模糊的术语。
• 输出详细程度： 默认情况下，Gemini 3 不那么冗长，更倾向于提供直接、高效的答案。如果你需要更多对话式或"健谈"的风格，必须明确要求。
• 多模态一致性： 文本、图像、音频或视频都应被视为同等级别的输入。指令应该明确引用特定的模态，以确保模型跨模态综合而不是孤立分析。
• 约束放置： 将行为约束和角色定义放在系统指令或提示词的最顶部，以确保它们锚定模型的推理过程。
• 长上下文结构： 处理大型上下文（书籍、代码库、长视频）时，将具体指令放在提示词的末尾（数据上下文之后）。
• 上下文锚定： 当从大块数据过渡到你的问题时，明确建立桥梁。在你的问题前使用框架性短语，如*"基于以上信息..."*。

推理和规划

明确的规划和分解

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

自我更新的待办事项跟踪器

创建一个待办事项列表来跟踪进度：

- [ ] 主要目标
- [ ] 任务 1
- [ ] 任务 2
....
- [ ] 审核

批判自己的输出

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

1. 我是否回答了用户的*意图*，而不仅仅是他们的字面意思？
2. 语气是否符合所要求的角色？
3. 如果我因为缺少数据而做了假设，我是否标记了它？

结构化提示

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

XML 示例：

<rules>
    1. 保持客观。
    2. 引用来源。
</rules>

<planning_process>
    1. 分析请求：识别核心目标和所有明确的约束。
    2. 分解：将问题分解为逻辑子任务或变量。
    3. 制定策略：概述解决每个子任务的分步方法。
    4. 验证：检查你的计划是否有逻辑漏洞或边缘情况。
</planning_process>

<error_handling>
    如果 <context> 为空、缺少代码或缺少必要数据：
    不要尝试生成解决方案。
    不要编造数据。
    输出对缺失信息的礼貌请求。
</error_handling>

<context>
    [在此插入用户输入 - 模型知道这是数据，而不是指令]
</context>

Markdown 示例：

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

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

# 输出格式
返回一个代码块。

智能体工具使用

持久性指令

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

预计算反思

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

特定领域用例

研究和分析

1. 将主题分解为关键研究问题
2. 为每个问题独立搜索/分析提供的来源
3. 将研究结果综合成连贯的报告
4. 引用规则：如果你做出具体声明，必须引用来源。如果没有来源，说明这是一般估计。每个声明必须紧跟一个引用 [来源 ID]

创意写作

1. 确定目标受众和具体目标（例如，同理心 vs. 权威性）。
2. 如果任务需要同理心或随意性，严格避免企业术语（例如，"协同效应"、"协议"、"确保"）。
3. 起草内容。
4. 内部阅读草稿。这听起来像人类还是模板？如果听起来像机器人，重写。

问题解决

1. 用你自己的话重述问题。
2. 确定"标准解决方案"。
3. 确定"高级用户解决方案"（是否有技巧、特定工具或大多数人错过的细微差别？）。
4. 呈现解决方案，优先考虑最有效的方法，即使它与用户请求的格式略有偏差。
5. 理智检查：这是否解决了根本问题？

教育内容

1. 根据用户的查询评估他们当前的知识水平。
2. 在使用关键术语之前定义它们。
3. 使用相关类比解释概念。
4. 在结尾提供"理解检查"问题。

示例模板

此模板将最佳实践（缓存友好结构、规划和 XML 分隔符）组合成一个可重用的基线。

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

系统指令

<role>
你是 Gemini 3，一个专门用于 [插入领域，例如数据科学] 的助手。
你精确、善于分析且坚持不懈。
</role>

<instructions>
1. **规划**：分析任务并创建分步计划，分解为不同的子任务。在 <plan> 标签中记录你的计划。
2. **执行**：执行计划。如果使用工具，在每次调用之前进行反思。在待办事项列表中跟踪进度，使用 [ ] 表示待处理，[x] 表示完成。
3. **验证**：根据用户的任务审核你的输出。
4. **格式化**：以请求的结构呈现最终答案。
</instructions>

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

<output_format>
按如下方式组织你的响应：
1. **计划**：[你的分步计划]
2. **执行摘要**：[2 句话概述]
3. **详细响应**：[主要内容]
</output_format>

用户提示词

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

<task>
[在此插入具体的用户请求]
</task>

<final_instruction>
记住在回答之前逐步思考。
</final_instruction>