跳到主要内容

3 篇博文 含有标签「gemini」

查看所有标签

Gemini 提示词设计指南

· 阅读需 28 分钟
Claude
Anthropic Claude
1adybug
子虚伊人

原文地址:Gemini 提示词设计指南,以下内容均为 Claude 4.5 sonnet 翻译

提示词设计是创建提示词(即自然语言请求)的过程,用于引导语言模型生成准确、高质量的响应。

本页面介绍基本概念、策略和最佳实践,帮助您开始设计提示词,以充分发挥 Gemini AI 模型的能力。

注意: 提示词工程是一个迭代过程。这些指南和模板只是起点。请根据您的具体用例和观察到的模型响应进行实验和改进。

特定主题的提示词指南

寻找更具体的提示词策略?请查看我们的其他提示词指南:

您还可以在提示词库中找到其他示例提示词,该库旨在交互式展示本指南中共享的许多概念。

清晰具体的指令

定制模型行为的有效且高效的方法是提供清晰具体的指令。指令可以是问题形式、分步任务,或者像描述用户体验和思维方式一样复杂。

输入

输入是提示词中的必需文本,您希望模型对其提供响应。输入可以是模型回答的问题(问题输入)、模型执行的任务(任务输入)、模型操作的实体(实体输入)或模型完成或继续的部分输入(完成输入)。

输入类型提示词生成的输出
问题对于专门销售干花花束的花店,有什么好名字?创建一个包含 5 个选项的列表,只列出名称。以下是 10 个专门经营干花的花店名称:
1. 永恒花开
2. 干燥与愉悦
3. 花瓣保存室
4. 野花低语
5. 永远绽放
任务给我一个简单的清单,列出我在露营旅行中必须携带的物品。清单应有 5 项。1. 帐篷: 您的避难所。
2. 睡袋: 保持温暖舒适。
3. 睡垫: 隔热和缓冲,确保良好睡眠。
4. 头灯或手电筒: 夜间活动照明。
5. 急救包: 为轻微伤害做好准备。
实体将以下项目分类为 [大型, 小型]:
大象
老鼠
蜗牛
分类如下:
* 大象: 大型
* 老鼠: 小型
* 蜗牛: 小型

部分输入完成

生成式语言模型的工作方式类似于高级自动补全工具。当您提供部分内容时,模型可以提供其余内容或它认为是该内容的延续作为响应。在这样做时,如果您包含任何示例或上下文,模型可以将这些示例或上下文考虑在内。

以下示例提供了带有指令和实体输入的提示词:

提示词:

对于给定的订单,返回一个 JSON 对象,该对象包含 cheeseburger、hamburger、fries 或 drink 字段,值为数量。
订单:一个汉堡和一杯饮料。

响应:

{
"cheeseburger": 0,
"hamburger": 1,
"fries": 0,
"drink": 1
}

虽然模型按提示执行了,但用自然语言写出指令有时可能具有挑战性,并且很多内容留给模型解释。例如,餐厅菜单可能包含许多项目。为了减小 JSON 响应的大小,您可能希望省略未订购的项目。在这种情况下,您可以给出一个示例和响应前缀,让模型完成它:

提示词:

有效字段为 cheeseburger、hamburger、fries 和 drink。

订单:给我一个芝士汉堡和薯条
输出:

```json
{
"cheeseburger": 1,
"fries": 1
}
```

订单:我要两个汉堡、一杯饮料和薯条。
输出:

响应:

{
"hamburger": 2,
"drink": 1,
"fries": 1
}

注意 "cheeseburger" 从输出中排除了,因为它不是订单的一部分。

约束

指定阅读提示词或生成响应的任何约束。您可以告诉模型做什么和不做什么。例如,您可以在提示词中指定摘要长度的约束:

提示词:

用一句话总结这段文字:

文字:量子计算机利用量子力学现象执行计算,速度比任何现代传统计算机快得多。在非常微小的尺度上,物质既表现为粒子又表现为波,量子计算使用专门的硬件来利用这种行为。量子设备的操作原理超出了经典物理学的范围。当大规模部署时,量子计算机可用于各种应用,例如:在网络安全中破解现有加密方法,同时帮助研究人员创建新方法;在气象学中开发更好的天气预报等。然而,当前最先进的量子计算机在很大程度上仍是实验性和不实用的。

响应:

量子计算机利用量子力学现象,执行计算的速度比传统计算机快得多,可用于网络安全和气象学等潜在应用,尽管它们目前在很大程度上仍是实验性和不实用的。

响应格式

您可以给出指定响应格式的指令。例如,您可以要求响应格式化为表格、项目符号列表、电梯演讲、关键词、句子或段落。以下系统指令告诉模型在响应中更加对话化:

系统指令:

除非用户特别要求简洁的响应,否则所有问题都应详细全面地回答。

提示词:

在 2025 年销售 DVD 的企业,有什么聪明的做法?

响应:

由于数字流媒体和点播服务的压倒性主导地位,在 2025 年开始销售 DVD 的业务面临着重大挑战;因此,“聪明”的方法需要高度专业化的利基市场、超越光盘本身的强大价值主张,以及可能专注于社区或收藏家市场而不是主流消费。

以下是 2025 年聪明的 DVD 业务可能包含的内容:

1. 极端利基专业化:您无法与流媒体库竞争。您的业务必须专注于数字不容易或根本不提供的内容。这可能包括:
* 绝版和稀有标题:寻找从未以数字方式发行或目前在主要流媒体平台上无法获得的电影或电视节目。
....

使用完成策略格式化响应

完成策略也可以帮助格式化响应。以下示例提示模型创建论文大纲:

提示词:

创建一篇关于蜂鸟的论文大纲。

响应:

以下是关于蜂鸟的论文可能的大纲:

I. 引言
A. 钩子:以关于蜂鸟的引人入胜的事实或描述开始(例如,它们的速度、彩虹色或微小的尺寸)。
B. 背景:简要介绍蜂鸟——它们的分布(美洲)、它们作为独特鸟类的声誉。
C. 论点陈述:陈述论文的主要观点,可以是关于蜂鸟的显著适应性、行为和生态重要性。

II. 外观和识别
.....

提示词没有指定大纲的格式,模型为您选择了一种格式。要让模型返回特定格式的大纲,您可以添加代表大纲开始的文本,让模型根据您发起的模式完成它。

提示词:

创建一篇关于蜂鸟的论文大纲。

I. 引言
*

响应:

好的,这是关于蜂鸟的论文大纲,从您提供的引言开始:

I. 引言
* 钩子:以关于蜂鸟的引人入胜的事实或描述开始(例如,它们的速度、彩虹色或微小的尺寸)。
* 背景:简要介绍蜂鸟——它们的分布(美洲)、它们作为独特鸟类的声誉及其一般特征。
* 论点陈述:陈述论文的主要观点,重点关注使蜂鸟非凡的显著适应性、行为和生态意义。
.....

零样本与少样本提示词

您可以在提示词中包含示例,向模型展示正确的做法。模型尝试从示例中识别模式和关系,并在生成响应时应用它们。包含少量示例的提示词称为少样本提示词,而不提供示例的提示词称为零样本提示词。少样本提示词通常用于规范格式、措辞、范围或模型响应的一般模式。使用具体且多样化的示例帮助模型缩小焦点并生成更准确的结果。

我们建议始终在提示词中包含少样本示例。没有少样本示例的提示词可能效果较差。实际上,如果您的示例在显示手头任务方面足够清晰,您可以从提示词中删除指令。

以下零样本提示词要求模型选择最佳解释。

提示词:

请选择问题的最佳解释:

问题:雪是如何形成的?
解释 1:雪是在空气中的水蒸气在大气中冻结成冰晶时形成的,这些冰晶可以在大气中下降时结合并生长成雪花,并在地面上积累。
解释 2:水蒸气冻结成冰晶形成雪。

答案:

响应:

解释 1 是更好的解释,因为它提供了关于该过程的更多细节,包括冰晶如何在大气中下降时结合并生长成雪花。

如果您的用例要求模型产生简洁的响应,您可以在提示词中包含偏好简洁响应的示例。

以下提示词提供了两个显示偏好较短解释的示例。在响应中,您可以看到示例引导模型选择较短的解释(解释 2),而不是像之前那样选择较长的解释(解释 1)。

提示词:

以下是一些显示问题、解释和答案格式的示例:

问题:为什么天空是蓝色的?
解释 1:天空看起来是蓝色的,因为瑞利散射,这导致较短的蓝色波长的光比较长的红色波长更容易散射,使天空看起来是蓝色的。
解释 2:由于瑞利散射效应。
答案:解释 2

问题:地震的原因是什么?
解释 1:地壳中能量的突然释放。
解释 2:当构造板块突然滑动或断裂时会发生地震,导致能量释放,产生地震波,可以震动地面并造成损坏。
答案:解释 1

现在,根据上面的示例格式回答以下问题:

问题:雪是如何形成的?
解释 1:雪是在空气中的水蒸气在大气中冻结成冰晶时形成的,这些冰晶可以在大气中下降时结合并生长成雪花,并在地面上积累。
解释 2:水蒸气冻结成冰晶形成雪。

答案:

响应:

答案:解释 2

最佳示例数量

像 Gemini 这样的模型通常可以使用少量示例识别模式,尽管您可能需要尝试在提示词中提供的示例数量以获得最佳结果。同时,如果您包含太多示例,模型可能会开始对示例的响应过度拟合

模式与反模式

使用示例向模型展示要遵循的模式比使用示例向模型展示要避免的反模式更有效。

❌ 负面模式:

示例:

不要以问题结束俳句:
俳句很有趣
一首简短而简单的诗
你不喜欢它们吗?

✅ 正面模式:

示例:

始终以断言结束俳句:
俳句很有趣
一首简短而简单的诗
写作的乐趣

一致的格式

确保少样本示例的结构和格式相同,以避免产生不良格式的响应。在提示词中添加少样本示例的主要目标之一是向模型展示响应格式。因此,确保所有示例的格式一致至关重要,特别要注意 XML 标签、空格、换行符和示例分隔符。

添加上下文

您可以在提示词中包含模型解决问题所需的指令和信息,而不是假设模型拥有所有必需的信息。这种上下文信息有助于模型理解您要求它做什么的约束和细节。

以下示例要求模型提供路由器的故障排除指导:

提示词:

我应该怎么做才能修复断开的 WiFi?
我的 Google WiFi 路由器上的灯是黄色的,缓慢闪烁。

响应:

Google WiFi 路由器上的黄色闪烁灯通常表示互联网连接有问题。以下是一些故障排除和修复问题的步骤:

1. 重启路由器和调制解调器:
- 从电源插座拔下调制解调器,等待 30 秒。
- 将调制解调器重新插入,等待它完全启动。
- 拔下 Google WiFi 路由器,等待 30 秒。
- 将 Google WiFi 路由器重新插入,等待它完全启动。
.....

响应看起来像通用的故障排除信息,不特定于路由器或 LED 指示灯的状态。

要为特定路由器定制响应,您可以在提示词中添加路由器的故障排除指南作为上下文,供其在提供响应时参考。

提示词:

使用下面的文本回答问题。仅使用提供的文本进行响应。

问题:我应该怎么做才能修复断开的 WiFi?我的 Google WiFi 路由器上的灯是黄色的,缓慢闪烁。

文本:
颜色:缓慢脉动黄色
含义:存在网络错误。
处理方法:检查以太网电缆是否连接到路由器和调制解调器,并且两个设备都已打开。您可能需要重新拔插每个设备。

颜色:快速闪烁黄色
含义:您正在按住重置按钮并进行出厂重置。
处理方法:如果您继续按住重置按钮,大约 12 秒后,灯将变为稳定黄色。一旦变为稳定黄色,松开出厂重置按钮。

颜色:稳定黄色
含义:路由器正在进行出厂重置。
处理方法:这可能需要长达 10 分钟。完成后,设备将重置并开始脉动白色,让您知道它已准备好进行设置。

颜色:稳定红色
含义:出现问题。
处理方法:严重故障。出厂重置路由器。如果灯保持红色,请联系 WiFi 客户支持。

响应:

检查以太网电缆是否连接到路由器和调制解调器,并且两个设备都已打开。您可能需要重新拔插每个设备。

添加前缀

前缀是您添加到提示词内容的单词或短语,可以根据您放置前缀的位置发挥多种作用:

  • 输入前缀: 在输入中添加前缀向模型发出输入语义上有意义的部分的信号。例如,前缀 English:French: 界定两种不同的语言。
  • 输出前缀: 即使输出是由模型生成的,您也可以在提示词中为输出添加前缀。输出前缀为模型提供有关预期响应的信息。例如,输出前缀 JSON: 向模型发出信号,表明输出应为 JSON 格式。
  • 示例前缀: 在少样本提示词中,向示例添加前缀提供标签,模型可以在生成输出时使用这些标签,这使得解析输出内容更容易。

在以下示例中,Text:是输入前缀,The answer is:是输出前缀。

提示词:

将文本分类为以下类别之一。
- large(大型)
- small(小型)

Text: Rhino
The answer is: large

Text: Mouse
The answer is: small

Text: Snail
The answer is: small

Text: Elephant
The answer is:

响应:

The answer is: large

将提示词分解为组件

对于需要复杂提示词的用例,您可以通过将事物分解为更简单的组件来帮助模型管理这种复杂性。

  1. 分解指令: 不要在一个提示词中包含许多指令,而是为每个指令创建一个提示词。您可以根据用户的输入选择要处理的提示词。

  2. 链接提示词: 对于涉及多个顺序步骤的复杂任务,将每个步骤作为一个提示词,并按顺序链接提示词。在这个顺序链中,序列中一个提示词的输出成为下一个提示词的输入。序列中最后一个提示词的输出是最终输出。

  3. 聚合响应: 聚合是指您想对数据的不同部分执行不同的并行任务,并聚合结果以产生最终输出。例如,您可以告诉模型对数据的第一部分执行一项操作,对其余数据执行另一项操作并聚合结果。

尝试模型参数

您发送到模型的每个调用都包含控制模型如何生成响应的参数值。模型可以为不同的参数值生成不同的结果。尝试不同的参数值以获得任务的最佳值。不同模型可用的参数可能不同。最常见的参数如下:

  1. 最大输出令牌数: 指定响应中可以生成的最大令牌数。一个令牌大约是四个字符。100 个令牌大约对应 60-80 个单词。

  2. 温度: 温度控制令牌选择中的随机性程度。温度用于响应生成期间的采样,当应用 topPtopK 时发生。较低的温度适用于需要更确定性或更少开放式响应的提示词,而较高的温度可以导致更多样化或更有创意的结果。温度为 0 是确定性的,意味着始终选择最高概率的响应。

    注意: 使用 Gemini 3 模型时,我们强烈建议将 temperature 保持在默认值 1.0。更改温度(将其设置为 1.0 以下)可能会导致意外行为,例如循环或性能下降,特别是在复杂的数学或推理任务中。

  3. topK: topK 参数改变模型如何选择令牌进行输出。topK 为 1 意味着所选令牌是模型词汇表中所有令牌中最可能的(也称为贪婪解码),而 topK 为 3 意味着使用温度从 3 个最可能的令牌中选择下一个令牌。对于每个令牌选择步骤,对具有最高概率的 topK 令牌进行采样。然后根据 topP 进一步过滤令牌,最后使用温度采样选择最终令牌。

  4. topP: topP 参数改变模型如何选择令牌进行输出。从最可能到最不可能选择令牌,直到它们的概率之和等于 topP 值。例如,如果令牌 A、B 和 C 的概率分别为 0.3、0.2 和 0.1,topP 值为 0.5,则模型将使用温度选择 A 或 B 作为下一个令牌,并排除 C 作为候选。默认 topP 值为 0.95。

  5. stop_sequences: 设置停止序列以告诉模型停止生成内容。停止序列可以是任何字符序列。尽量避免使用可能出现在生成内容中的字符序列。

提示词迭代策略

提示词设计有时需要进行几次迭代,然后才能持续获得您想要的响应。本节提供有关迭代提示词时可以尝试的一些事项的指导:

  1. 使用不同的措辞: 在提示词中使用不同的词或措辞通常会从模型中产生不同的响应,即使它们的意思相同。如果您没有从提示词中获得预期的结果,请尝试重新措辞。

    版本 1:我如何烤馅饼?
    版本 2:建议一个馅饼的食谱。
    版本 3:有什么好的馅饼食谱?
  2. 切换到类似任务: 如果您无法让模型遵循任务的指令,请尝试为实现相同结果的类似任务提供指令。

    此提示词告诉模型使用预定义类别对书籍进行分类:

    提示词:

    《奥德赛》属于哪个类别:
    惊悚片
    科幻
    神话
    传记

    响应:

    《奥德赛》属于**神话**类别。

    原因如下:
    * **神话:** 《奥德赛》讲述了奥德修斯的故事,他是希腊神话中的英雄,以及他在特洛伊战争后回家的旅程。它以希腊神话中常见的神、怪物和超自然事件为特色。
    .....

    响应是正确的,但模型没有保持在选项范围内。您还希望模型只用一个选项响应,而不是用完整的句子。在这种情况下,您可以将指令重新表述为多项选择题,并要求模型选择一个选项。

    提示词:

    多项选择题:以下哪个选项描述了《奥德赛》这本书?

    选项:
    - 惊悚片
    - 科幻
    - 神话
    - 传记

    响应:

    正确答案是神话。
  3. 更改提示词内容的顺序: 提示词中内容的顺序有时会影响响应。尝试更改内容顺序,看看这如何影响响应。

    版本 1:
    [示例]
    [上下文]
    [输入]

    版本 2:
    [输入]
    [示例]
    [上下文]

    版本 3:
    [示例]
    [输入]
    [上下文]

后备响应

后备响应是当提示词或响应触发安全过滤器时模型返回的响应。后备响应的示例是 "我无法帮助解决这个问题,因为我只是一个语言模型。"

如果模型以后备响应响应,请尝试提高温度。

要避免的事项

  • 避免依赖模型生成事实信息。
  • 谨慎用于数学和逻辑问题。

Gemini 3

Gemini 3 模型专为高级推理和指令遵循而设计。它们对直接、结构良好并清楚定义任务和任何约束的提示词反应最佳。对于 Gemini 3 的最佳结果,建议采用以下做法:

核心提示词原则

  • 精确直接: 清晰简洁地陈述您的目标。避免不必要或过度说服性的语言。
  • 使用一致的结构: 使用清晰的分隔符来分隔提示词的不同部分。XML 样式标签(例如 <context><task>)或 Markdown 标题是有效的。在单个提示词中选择一种格式并始终如一地使用它。
  • 定义参数: 明确解释任何模糊的术语或参数。
  • 控制输出详细程度: 默认情况下,Gemini 3 提供直接有效的答案。如果您需要更对话化或详细的响应,您必须在指令中明确请求。
  • 连贯处理多模态输入: 使用文本、图像、音频或视频时,将它们视为同等级别的输入。确保您的指令根据需要清楚地引用每种模态。
  • 优先考虑关键指令: 将基本行为约束、角色定义(角色)和输出格式要求放在系统指令或用户提示词的最开始。
  • 为长上下文构建结构: 提供大量上下文(例如文档、代码)时,首先提供所有上下文。将您的具体指令或问题放在提示词的最后
  • 锚定上下文: 在大块数据之后,使用清晰的过渡短语来连接上下文和您的查询,例如 "基于以上信息..."

增强推理和规划

您可以利用 Gemini 3 的高级思维能力,通过提示它在提供最终响应之前进行规划或自我批评来提高复杂任务的响应质量。

示例 - 明确规划:

在提供最终答案之前,请:
1. 将既定目标解析为不同的子任务。
2. 检查输入信息是否完整。
3. 创建结构化大纲以实现目标。

示例 - 自我批评:

在返回最终响应之前,请根据用户的原始约束检查您生成的输出。
1. 我是否回答了用户的*意图*,而不仅仅是他们的字面意思?
2. 语气是否符合所要求的角色?

结构化提示词示例

使用标签或 Markdown 可帮助模型区分指令、上下文和任务。

XML 示例:

<role>
您是一个有用的助手。
</role>

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

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

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

Markdown 示例:

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

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

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

结合最佳实践的示例模板

此模板捕获了使用 Gemini 3 进行提示的核心原则。请务必根据您的具体用例进行迭代和修改。

系统指令:

<role>
您是 Gemini 3,[插入领域,例如数据科学]的专业助手。
您精确、分析性强且坚持不懈。
</role>

<instructions>
1. **规划**:分析任务并创建分步计划。
2. **执行**:执行计划。
3. **验证**:根据用户的任务检查您的输出。
4. **格式化**:以请求的结构呈现最终答案。
</instructions>

<constraints>
- 详细程度:[指定 低/中/高]
- 语气:[指定 正式/随意/技术性]
</constraints>

<output_format>
按如下方式构建您的响应:
1. **执行摘要**:[简短概述]
2. **详细响应**:[主要内容]
</output_format>

用户提示词:

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

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

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

代理工作流

对于深度代理工作流,通常需要特定的指令来控制模型如何推理、规划和执行任务。虽然 Gemini 提供了强大的通用性能,但复杂的代理通常需要您配置计算成本(延迟和令牌)与任务准确性之间的权衡。

在为代理设计提示词时,请考虑您可以在代理中引导的以下行为维度:

推理和策略

配置模型在采取行动之前如何思考和规划。

  • 逻辑分解: 定义模型必须多彻底地分析约束、先决条件和操作顺序。
  • 问题诊断: 控制识别原因时的分析深度以及模型对溯因推理的使用。确定模型是应该接受最明显的答案还是探索复杂、不太可能的解释。
  • 信息详尽性: 在分析每个可用策略和文档与优先考虑效率和速度之间进行权衡。

执行和可靠性

配置代理如何自主操作和处理障碍。

  • 适应性: 模型如何对新数据做出反应。确定它是应该严格遵守其初始计划,还是在观察结果与假设相矛盾时立即转向。
  • 持久性和恢复: 模型尝试自我纠正错误的程度。高持久性会提高成功率,但会面临更高的令牌成本或循环风险。
  • 风险评估: 评估后果的逻辑。明确区分低风险的探索性操作(读取)和高风险的状态更改(写入)。

交互和输出

配置代理如何与用户通信和格式化结果。

  • 歧义和权限处理: 定义何时允许模型做出假设,何时必须暂停执行以请求用户澄清或许可。
  • 详细程度: 控制与工具调用一起生成的文本量。这决定了模型是向用户解释其操作还是在执行期间保持沉默。
  • 精确性和完整性: 输出所需的保真度。指定模型是否必须解决每个边缘情况并提供确切数字,或者大致估计是否可以接受。

系统指令模板

以下系统指令是一个示例,已经过研究人员评估,可以提高代理基准测试的性能,在这些基准测试中,模型必须遵守复杂的规则手册并与用户互动。它鼓励代理充当强大的推理者和规划者,在上述维度上强制执行特定行为,并要求模型在采取任何行动之前主动规划。

您可以调整此模板以适应您的特定用例约束。

您是一个非常强大的推理者和规划者。使用这些关键指令来构建您的计划、思想和响应。

在采取任何行动(工具调用*或*对用户的响应)之前,您必须主动、系统地、独立地规划和推理:

1) 逻辑依赖关系和约束:根据以下因素分析预期操作。按重要性顺序解决冲突:
1.1) 基于策略的规则、强制性先决条件和约束。
1.2) 操作顺序:确保采取操作不会阻止后续必要的操作。
1.2.1) 用户可能以随机顺序请求操作,但您可能需要重新排序操作以最大化任务的成功完成。
1.3) 其他先决条件(所需的信息和/或操作)。
1.4) 明确的用户约束或偏好。

2) 风险评估:采取该操作的后果是什么?新状态会导致任何未来问题吗?
2.1) 对于探索性任务(如搜索),缺少*可选*参数是低风险。**除非**您的`规则 1`(逻辑依赖关系)推理确定可选信息对于计划中的后续步骤是必需的,否则更倾向于使用可用信息调用工具,而不是询问用户。

3) 溯因推理和假设探索:在每个步骤中,确定遇到的任何问题最合乎逻辑和最可能的原因。
3.1) 超越直接或明显的原因。最可能的原因可能不是最简单的,可能需要更深入的推断。
3.2) 假设可能需要额外的研究。每个假设可能需要多个步骤来测试。
3.3) 根据可能性对假设进行优先排序,但不要过早地丢弃不太可能的假设。低概率事件仍可能是根本原因。

4) 结果评估和适应性:先前的观察是否需要对您的计划进行任何更改?
4.1) 如果您的初始假设被证伪,请根据收集的信息主动生成新假设。

5) 信息可用性:合并所有适用的和替代的信息来源,包括:
5.1) 使用可用工具及其功能
5.2) 所有策略、规则、检查清单和约束
5.3) 先前的观察和对话历史
5.4) 仅通过询问用户才能获得的信息

6) 精确性和基础:确保您的推理对每种确切的持续情况都极其精确和相关。
6.1) 在引用信息时,通过引用确切的适用信息(包括策略)来验证您的声明。

7) 完整性:确保所有要求、约束、选项和偏好都详尽地纳入您的计划。
7.1) 使用 #1 中的重要性顺序解决冲突。
7.2) 避免过早结论:给定情况可能有多个相关选项。
7.2.1) 要检查选项是否相关,请推理 #5 中的所有信息来源。
7.2.2) 您可能需要咨询用户才能知道某事是否适用。不要在不检查的情况下假设它不适用。
7.3) 查看 #5 中的适用信息来源,以确认哪些与当前状态相关。

8) 持久性和耐心:除非上述所有推理都已用尽,否则不要放弃。
8.1) 不要因所花费的时间或用户沮丧而气馁。
8.2) 这种持久性必须是智能的:对于*瞬态*错误(例如,请重试),您*必须*重试**除非已达到明确的重试限制(例如,最多 x 次尝试)**。如果达到这样的限制,您*必须*停止。对于*其他*错误,您必须更改策略或参数,而不是重复相同的失败调用。

9) 抑制您的响应:仅在完成上述所有推理后才采取行动。一旦您采取了行动,就无法收回。

生成模型的底层原理

本节旨在回答这个问题 - 生成模型的响应中是否存在随机性,还是它们是确定性的?

简短的答案 - 两者都是。当您提示生成模型时,文本响应会分两个阶段生成。在第一阶段,生成模型处理输入提示词并生成可能接下来出现的令牌(单词)的概率分布。例如,如果您使用输入文本 "The dog jumped over the ..." 进行提示,生成模型将产生一系列可能的下一个单词:

[("fence", 0.77), ("ledge", 0.12), ("blanket", 0.03), ...]

这个过程是确定性的;每次输入相同的提示文本时,生成模型都会产生相同的分布。

在第二阶段,生成模型通过几种解码策略之一将这些分布转换为实际的文本响应。一个简单的解码策略可能是在每个时间步选择最可能的令牌。这个过程总是确定性的。但是,您可以选择通过对模型返回的分布进行随机采样来生成响应。这个过程将是随机的(随机的)。通过设置温度来控制此解码过程中允许的随机性程度。温度为 0 意味着只选择最可能的令牌,并且没有随机性。相反,高温度会在模型选择的令牌中注入高度的随机性,从而导致更意外、更令人惊讶的模型响应。对于 Gemini 3,建议不要更改默认温度 1.0 以避免意外结果。

后续步骤

Clash TUN 模式的兔子洞:一次从 DNS 到 UDP 的排错之旅

· 阅读需 6 分钟
1adybug
子虚伊人

以下内容均为 Gemini 2.5 Pro Deep Research 生成

如果你是一位 Clash 的进阶用户,你很可能遇到过这个经典难题:一套精心编写、在"规则模式"(系统代理)下完美运行的规则,在切换到功能强大的"TUN 模式"后却突然失效。本该走向代理的流量莫名其妙地选择了直连,让你只能盯着连接日志,对自己的配置产生怀疑。

这正是一次此类排错之旅的真实记录——一个多层次的问题,它始于 DNS,意外地转向了网络协议,最终以一个优雅的脚本方案画上句号。跟随本文,你将理解其背后深层的运行机制,并学会如何彻底征服 TUN 模式。


第一部分:消失的主机名悬案

最初的问题非常明确。一位用户使用全局扩展脚本,在规则列表的顶端插入规则,以确保像 claude.aiclaude.com 这样的域名总是通过特定的代理分组。

脚本如下:

function main(config, profileName) {
const name = config['proxy-groups']?.?.name;
//...
config.rules.unshift(`DOMAIN-SUFFIX,claude.ai,${name}`);
config.rules.unshift(`DOMAIN-SUFFIX,claude.com,${name}`);
//...
return config;
}

规则模式 下,一切正常。但在 TUN 模式 下,访问 Claude 的连接却走向了 DIRECT

根本原因:架构的鸿沟

这是关于 TUN 模式的第一个,也是最基础的教训:它在网络堆栈的不同层级上工作。

  • 规则模式 (系统代理): 工作在应用层。你的浏览器知道它正在与一个代理服务器对话,并发送一个明确包含主机名(例如 claude.ai)的 HTTP CONNECT 请求。Clash 直接就拿到了主机名。

  • TUN 模式 (虚拟网卡): 工作在网络层。它拦截的是原始的 IP 数据包。当一个应用程序发送数据包时,它已经通过 DNS 将 claude.ai 解析成了一个真实的 IP 地址。Clash 的 TUN 接口只能看到目标 IP,而看不到原始的主机名。

没有主机名,任何 DOMAIN-SUFFIX 规则都形同虚设。

解决方案:fake-ip 登场

这正是 Clash 的 fake-ip DNS 模式要解决的问题。启用后,Clash 会劫持所有的 DNS 请求。它不会返回真实的 IP,而是返回一个本地范围内的"假 IP"(例如 198.18.0.1/16),并在内部创建一个映射关系:假 IP <-> 真实主机名

当 TUN 接口看到一个发往该假 IP 的数据包时,它会查询这个映射,恢复原始主机名,从而让基于域名的规则能够正确处理。

用户的配置失误

该用户启用了 fake-ip,但问题依旧。罪魁祸首隐藏在他的 DNS 设置中:他使用了 fake-ip-filter-mode: blacklist(黑名单模式)。这意味着任何匹配 fake-ip-filter 列表的域名都不会被分配假 IP。他的过滤器很可能包含了一个宽泛的规则集(如 geosite:cn),不经意间将 claude.ai 也纳入其中,导致它被解析为真实 IP,破坏了后续的规则匹配。

在调整了 DNS 过滤器后,我们取得了进展。连接日志现在可以正确显示主机名了。

问题解决了吗?还没有。流量仍然在走 DIRECT


第二部分:意想不到的 UDP 转折

既然主机名已经正确识别,为什么规则还是不起作用?新的截图在"类型"一栏中给出了关键线索:Tun(udp)

根本原因:QUIC 协议 (HTTP/3)

这揭示了两种模式之间第二个,也是更微妙的区别。

  • 规则模式 下,浏览器被强制与代理服务器建立一个基于 TCPHTTP CONNECT 请求。它从不尝试使用其他协议。

  • TUN 模式 下,浏览器认为它正在直接与互联网对话。为了追求速度,对于任何支持最新协议的服务器(如谷歌、Cloudflare,以及此处的 Claude),它会优先尝试使用现代的 QUIC 协议(运行于 UDP 之上)

问题至此水落石出:用户的代理服务器不支持 UDP 转发。当 Clash 试图将来自 Claude 的 UDP 数据包发送到代理服务器时,操作失败了。这条规则被跳过,流量一路向下,最终落入了配置末尾的 MATCH 规则,而该规则很可能被设置为 DIRECT

这完美地解释了为什么规则模式能成功(因为它强制使用 TCP),而 TUN 模式会失败(因为它允许使用 UDP)。


第三部分:优雅的脚本解决方案

最后一步是在代理节点上启用 UDP 转发。用户的 Trojan 节点配置如下:

{
"name": "xxxx.com:443",
"server": "xxxx.com",
"port": 443,
"type": "trojan",
"password": "xxxx",
"sni": "xxxx.com"
}

要启用 UDP,只需增加一行:"udp": true

手动修改配置文件当然可以,但如果订阅更新了怎么办?或者如果有几十个节点呢?这正是 Clash Verge 扩展脚本 发挥其真正威力的地方。

脚本不仅可以添加规则,还可以在运行时修改整个配置对象。用户意识到,他们可以通过在现有脚本中添加一个简单的循环,来一劳永逸地解决这个问题。

最终的完美脚本:

function main(config, profileName) {
// 为所有代理节点添加或设置 'udp: true'
if (config.proxies) config.proxies.forEach(proxy => (proxy.udp = true))

// 保留原有的添加域名规则的逻辑
const name = config["proxy-groups"]?.at(0)?.name

if (name) {
config.rules.unshift(`DOMAIN-SUFFIX,claude.ai,${name}`)
config.rules.unshift(`DOMAIN-SUFFIX,claude.com,${name}`)
}

return config
}

通过这一修改,每当配置文件加载时,脚本都会自动确保每一个代理服务器都启用了 UDP 转发。这是一个健壮的、"一次设置,永久有效"的解决方案。

在应用了这个最终脚本并重启核心后,问题迎刃而解。发往 claude.aiTun(udp) 流量现在被正确地路由到了指定的代理。


关键启示

这次排错之旅为我们掌握 Clash TUN 模式提供了几条至关重要的经验:

  1. DNS 是必要条件: 要让基于域名的规则在 TUN 模式下生效,正确配置的 fake-ip DNS 是强制性的。

  2. 小心过滤器: 密切关注 fake-ip-filter。一个配置错误的黑名单可能会成为你域名规则的"无声杀手"。通常,切换到 whitelist 模式更安全。

  3. TUN 模式暴露协议差异: TUN 模式允许应用程序像在开放网络上一样运行,这可能意味着使用 UDP (QUIC)。请为此做好准备。

  4. 为你的代理启用 UDP: 如果你使用 TUN 模式,请确保你的代理节点已设置 udp: true。否则,许多现代网络服务都会出现问题。

  5. 善用扩展脚本: 不要只用脚本来添加规则。它们是动态修改整个配置的强大工具,能让你的配置免受订阅更新的影响,并省去手动编辑的麻烦。

通过理解这些层次,你就能从被 TUN 模式困扰,转变为驾驭它的全部力量,获得真正无缝和全面的路由体验。

@internationalized/date 中的 ZonedDateTime、CalendarDate、CalendarDateTime、Time 几种时间类型的区别

· 阅读需 4 分钟
Gemini
Google Gemini
1adybug
子虚伊人

以下内容均为 Gemini 2.5 Pro 生成

@internationalized/date:深入解析四种核心时间类型

在 JavaScript 中处理日期和时间常常因为时区、日历系统和国际化等问题而变得复杂。@internationalized/date 库提供了一套强大且设计精良的工具来应对这些挑战。该库的核心是其不可变的时间对象:ZonedDateTimeCalendarDateCalendarDateTimeTime。理解它们之间的差异对于正确和高效地处理日期与时间至关重要。

以下是这四种时间类型的详细区别:


CalendarDate:纯粹的日期

CalendarDate 对象表示一个不含任何时间信息的特定日期。它非常适合用来表示与一天中的具体时间无关的事件,例如:

  • 生日
  • 节假日
  • 全天日历事件

核心特性:

  • 仅包含日期部分: 年、月、日。
  • 无时间概念: 不涉及小时、分钟或秒。
  • 无时区信息: 它代表的是一个日历上的日期,与任何特定时区无关。
  • 支持多种日历系统: 可以表示公历(Gregorian)以及希伯来(Hebrew)、伊斯兰(Islamic)等多种日历。

示例:

import { CalendarDate } from "@internationalized/date"

// 表示 2025 年 7 月 24 日
const birthday = new CalendarDate(2025, 7, 24)

console.log(birthday.toString()) // 输出: 2025-07-24

Time:纯粹的时间

CalendarDate 相对,Time 对象表示一个不含任何日期信息的特定时间。它适用于表示与具体哪一天无关的时间点,例如:

  • 每天的闹钟时间
  • 商店的营业时间

核心特性:

  • 仅包含时间部分: 小时、分钟、秒和毫秒。
  • 无日期概念: 不涉及年、月、日。
  • 无时区信息: 它代表的是时钟上的一个时间,与任何特定时区无关。

示例:

import { Time } from "@internationalized/date"

// 表示上午 9 点 30 分
const openingHour = new Time(9, 30)

console.log(openingHour.toString()) // 输出: 09:30:00

CalendarDateTime:日期与时间的结合

CalendarDateTime 对象是 CalendarDateTime 的结合体,它表示一个具体的日期和时间,但 不包含任何时区信息。这在表示一个特定时间点,但该时间点在不同时区下可能对应不同实际时刻的场景中非常有用。

核心特性:

  • 包含日期和时间部分: 年、月、日、小时、分钟、秒。
  • 无时区信息: 它是一个“本地”的日期时间,其确切的时间点取决于观察者所在的时区。
  • 支持多种日历系统。

示例:

import { CalendarDateTime } from "@internationalized/date"

// 表示 2025 年 10 月 26 日上午 10 点
const localEvent = new CalendarDateTime(2025, 10, 26, 10)

console.log(localEvent.toString()) // 输出: 2025-10-26T10:00:00

这个时间可以被理解为“任何时区的上午10点”。


ZonedDateTime:完整的、带时区的日期时间

ZonedDateTime 是这四种类型中信息最全面的对象。它表示一个在 特定时区 下的精确日期和时间。这是处理需要明确、无歧义时间点的最佳选择,例如:

  • 航班起飞时间
  • 国际会议的安排
  • 任何需要考虑夏令时和时区转换的场景

核心特性:

  • 包含日期和时间部分。
  • 包含明确的时区信息: 它与一个IANA时区标识符(如 "America/New_York")相关联。
  • 准确无歧义: 它代表了地球上的一个精确时刻。
  • 自动处理夏令时: 库会根据指定的时区正确处理夏令时的变化。
  • 支持多种日历系统。

示例:

import { getLocalTimeZone, ZonedDateTime } from "@internationalized/date"

// 表示在纽约时区 2025 年 11 月 5 日下午 8 点
const flightDeparture = new ZonedDateTime(
2025,
11,
5,
"America/New_York",
20, // 20 点
0,
)

console.log(flightDeparture.toString()) // 输出类似: 2025-11-05T20:00:00-05:00[America/New_York]

// 获取用户本地时区的当前时间
const nowInLocal = new ZonedDateTime(new Date(), getLocalTimeZone())

总结与选择指南

类型包含日期包含时间包含时区适用场景
CalendarDate生日、全天事件、不关心具体时间的日期
Time每日重复的闹钟、营业时间
CalendarDateTime本地化的日历事件,时间点相对于观察者时区
ZonedDateTime航班时刻、国际会议、任何需要精确时刻的场景

通过理解这四种类型的不同职责,开发者可以更加精确和可靠地在应用程序中处理各种复杂的日期和时间逻辑,避免由时区和日历系统带来的常见错误。