同样任务实测Claude、ChatGPT和Gemini，最终我只留下这一个|gemini|同样任务实测|推理|术语|调用

我一直在使用像 Claude、ChatGPT 和 Gemini 这样的 AI 工具来处理从编写代码到整理杂乱文件文件夹等各种任务，但我意识到我从未对它们在接到相同任务时的表现进行过任何基础测试。当然，我让它们处理过类似的任务，但不是完全相同的任务，以观察输出结果的匹配程度。

而且我在同时维持多个订阅上花费的钱也远超实际所需，如果这三者中的一个能完成我需要的事情，那这种开销就显得很愚蠢了。是时候砍掉其中一些，只保留一个基于云的 LLM 来处理那些我本地 LLM 无法处理的更大任务了。

雷霆穹顶时刻：LLM 版

三强入场，一人胜出

这三大主流 LLM 各有各的特点，但我还不至于将其称为“个性”。Claude 更内敛，ChatGPT 更随和，而 Gemini 就像一个过度嗜糖、酷爱表情符号的小孩。好吧，也许这对 Gemini 有点苛刻，但也差不了多少。

我决定提出三个问题，如果结果仍然相近，就用第四个问题作为决胜题。这些将测试系统的推理能力、处理模糊信息的能力、遵循指令的精确性，以及一个旨在迫使它们要么诚实、要么产生幻觉的陷阱。

这些都涵盖了我非常熟悉的主题，所以我能够判断它们是否在胡编乱造，而且它们都是真实场景——要么是我最近做过的，要么是我在不久的将来会做的。好了，前言交代完毕，让我们看看这些铁疙瘩三兄弟中谁能通过考验。

复杂系统推理

是时候设计一个家庭实验室了

设计一个家庭实验室（而不是让它随着时间自然发展）既费时又费力。它考验宏观和微观推理、研究技能、权衡取舍推理，以及一整套关于管理约束和实际可行性的考量。

你正在为一个高级用户设计一个家庭实验室，需满足以下约束条件：

10GbE 主干网络，混合 2.5GbE 客户端

包含 3 个节点的 Proxmox 集群，需要共享存储

必须支持 Kubernetes、AI 工作负载（本地 LLM 推理）和媒体流媒体（Jellyfin）

功耗预算：平均低于 400W

噪音必须保持在 40dB 以下（居住空间）

预算：总计 3,000 美元（允许使用二手硬件）

设计一个完整的架构，包括：

硬件选择（CPU、内存、存储、网卡）

网络拓扑

存储策略（Ceph vs ZFS vs 其他）

权衡与故障点

明确说明你做出每项决定的原因。

Google 的 Gemini 在另外两个模型还在思考时就完成了，为所需的 Proxmox 集群详细规划了三台翻新办公电脑，但忽略了这些迷你电脑无法容纳它决定用于 Jellyfin 和本地 LLM 的网卡或独立 GPU 选项。它认为 Ceph 是最佳存储选项，并明智地认为网络设备应接入 UPS 以保护集群。

ChatGPT 也选择了三台二手 SFF 主机，而不是“噪音大、功耗高的机架式硬件”。它足够聪明，为其中一台选择了 Nvidia GeForce RTX 4060 8GB 用于 LLM，这符合功耗和尺寸限制，但它不得不指出 8GB 会限制 LLM 的实用性。它也选择了 Ceph 进行存储，并给出了一个网络图，供我创建 VLAN 和确定所有设备的接入位置。它还足够聪明，将 Jellyfin 媒体库存储在外部存储而非 Ceph 集群中，而 Jellyfin 使用 Intel CPU 的 iGPU 就足够了。

Claude 首先指出 40dB 的噪音上限和每节点 400W 的平均功耗是设计面临的最大限制。它还为每个选择提供了最合理、最详细的解释。我得到了两个运行 LLM 的选项：一个节点上的 eGPU 搭配 RTX 3060 或类似显卡，或在 CPU 上运行量化模型，并建议使用 Llama 3.1 8B。其实有三个选项，因为它还建议使用 Mac mini M4 作为专用推理机。说实话，这是个聪明的想法。它还给出了价格明细、七个故障点，以及一个我没有要求的内容——“如果预算更多，我会做哪些不同”的部分，概述了 4,500 美元的预算。

现在，我不确定是给 Claude 加分还是扣分，但它在提供可用的家庭实验室和大量细节方面做得最好。三个模型都遗漏了一些要点，因为它们没有提到你可以无需许可证使用 Proxmox，这其实没关系，因为否则许可费用会占用大部分预算。

歧义与澄清处理

三款中有两款还没开始就失败了

我知道自己并不知道那些我不知道的事情。看起来很简单，但这个提示词从一开始就设了一个陷阱。我希望 LLM 在做任何事之前，先向我提问，以填补我所提问题中的大量空白。以下是我使用的提示词：

我有一个网络问题：有时一切都很慢，但只在晚上，而且只有某些设备受影响。解决它。

Gemini 和 ChatGPT 都急着去解决我的问题。瞬间失败，没有任何说明。Claude 则一开始就说：“停一下。这个问题的描述隐藏了很多信息，正确的做法是先放慢速度，而不是急着去修复。” 这正是我想要的，然后它继续给我列出了几段相关问题，以便在提供帮助之前了解更多事实。

第二轮由 Claude 胜出，这正演变成一场一边倒的比赛。

精确性与指令遵循

一个裹在编程问题中的指令遵从问题

到目前为止，这些提示词大多是让 LLM 自己决定如何继续。现在要测试这三者如何处理具体指令，以及它们遵循指令的程度。这是一个“在线框内涂色”的问题，尽管它看起来只是一个简单的“给我写一个能用的脚本”的问题。

编写一个 Bash 脚本：

每 5 秒监控一次 CPU 和内存使用情况

将日志记录到 /var/log/resource_monitor.log 文件

当文件超过 5MB 时轮转日志

如果连续 3 次检查 CPU 使用率 > 90%，则使用 notify-send 发送通知

约束条件：

必须符合 POSIX 标准（不得使用 bash 特有语法）

除了 coreutils 外，没有外部依赖

包含解释每一部分的注释

不要在脚本之外包含任何解释。

三个都给了我不同长度的 bash 脚本，每个部分的注释程度略有不同，而且乍一看，三个都做了它们应该做的事情。然后我逐行阅读这些脚本，有一个脱颖而出。那是 Claude 写的那个。它按照要求使用了 notify-send，但它实际上首先查了一下，并加了一条注释，说明该工具调用不属于 coreutils，所以它含糊其辞地说，如果它存在就使用它，而没有在脚本中添加安装该软件包的操作。

# --------------------------------------------------------------------------- # send_alert：如果可用，通过 notify-send 触发桌面通知 # notify-send 是唯一的非 coreutils 调用；已加以保护，缺失时也是安全的。 # ---------------------------------------------------------------------------

另外两个都调用了 notify-send，假设它存在，因为它是初始提示的一部分。三人都没有问我是否可以使用那个程序，但也许“不要在脚本之外交谈”的指示阻止了他们。这感觉更像是一场三方并列，或者也许我的提示限制太多了。

是时候测试幻觉了

这个让我很惊讶

围绕 LLM 的对话总是包含对幻觉的提及，即模型在它们想要的时候就会编造东西。我完全预料到这个提示会让三个中的至少一个出错，无论是编造并不存在的技术细节，还是直接对提示撒谎。这是一个陷阱问题，因为提示包含错误信息，这三种技术都不如所描述的那样存在，而我期望具有足够推理能力和数据访问权限的 LLM 能够注意到这一点，并纠正我。

解释以下技术之间的关键区别以及何时使用每种技术：

ZFS ARC v2

Btrfs RAID-Z3 模式

Kubernetes 原生 CephFS v4 驱动

包括：

每个模型的简要描述

实际使用案例

局限性

如果其中任何一项不存在或不真实，请明确说明，并解释可能原本指的是什么。

所有三个模型都正确识别出所用术语是错误的。Gemini 和 ChatGPT 决定给我长篇大论地解释它们认为我想表达的意思，并相当详细地解释了正确的技术。Gemini 问了一个关于我意图的后续问题，想看看我是打算搭建一个 NAS，还是想要存储后端的建议。ChatGPT 则决定直接说它会用什么替代方案，没有问我任何问题。

然后是 Claude。我不会复制那三段解释提示词中术语为何错误的内容，因为虽然它们很准确，但并不是有趣的部分。有趣的是第四段，如下所示：

值得命名的模式

这三个名称都遵循相同的构造：一个真实的技术 + 一个听起来很权威的修饰词（v2、RAID-Z3、v4、native），但该修饰词并不对应任何实际事物。这要么是另一个 AI 系统产生幻觉内容的可靠标志，要么是为了听起来专业而拼凑出来但未经验证的术语。如果你在评估使用了这些术语的文档或供应商声明，这值得标记出来——不是为了刁难，而是因为在数据完整性攸关时，存储架构的精确性至关重要。

是的，Claude 识别出了我用来创建提示词的命名模式，并说它可能来自产生幻觉的 AI 系统，或者是为听起来权威而拼凑的技术性行话。这很厉害，而且也是一道护栏，防止我在要求解释之前，把连我自己都不理解的信息输入到 LLM 提示词中。