前几天，我想让 AI 助手帮我看看邮箱里一共有多少封邮件。
就一个数数的活。我原以为几分钟就能搞定，结果折腾了整整两天，还差点把问题归咎于邮箱本身。
第一次查询：13 封
我使用的 AI 助手是 WorkBuddy，当时选择的是混元 3 模型。我问它：
帮我看一下邮箱里有多少封邮件。
它很快回答：一共 13 封，其中 1 封未读。
干净利落，我差点就信了。
可我顺手打开网页版邮箱，收件箱旁边明明显示着 1659。13 对 1659，这已经不是普通误差，而是两套结果根本对不上。
一个听起来很专业的解释
我拿着截图问它：“你查到的数字为什么和网页不一样？”
它给出了一个听起来很专业的解释：可能是邮箱的安全风控限制了访问通道，只能看到部分数据；让我在网页版信任当前设备，再重新查询。
这个说法逻辑完整，也有专业术语。我照着做了一遍，结果仍然是 13。
它又提出第二种可能：网页端也许把其他邮箱代收的邮件算了进去，而当前通道里确实只有 13 封。
这些解释都“说得通”，却没有真正解决一个问题：13 到底是不是完整结果？
换一个模型，再问同一个问题
我把模型换成 DeepSeek，然后原样重问了一遍。
这一次，它没有拿到 13 就结束任务，而是先检查这个数字是否可信。它重新连接邮箱，并用不同方式核对：服务器返回的数量是 13，协议层读取到的是 13，把当前可见邮件列出来后仍然是 13。
三个结果一致，说明当前通道确实只看到了 13 封邮件。但新的问题也因此更清楚了：为什么网页端会显示 1659？
它继续检查邮件日期，发现通道中能看到的邮件全部集中在最近一段时间，更早的邮件一封也没有。对于一个长期使用的邮箱来说，这显然不正常。
于是，排查方向从“邮件数量”转向了“邮箱同步范围”。最终发现，邮箱的 POP3/SMTP/IMAP 设置中存在收取范围选项，当前通道只同步了近期邮件。把范围调整为全部邮件后，再次查询，结果变成了 3239 封。
同时我们也弄清楚了另一个误会：网页上的 1659 是未读邮件数，不是邮件总数。
差别不只是答案，而是验证过程
同样能连接邮箱、读取数据和执行操作，为什么两次查询会得到如此不同的结果？
这次经历里，真正拉开差距的是四件事。
第一，是否会怀疑初始结论。
拿到 13 以后，是直接交卷，还是先问一句“这个数字完整吗”，决定了任务会停在哪里。
第二，是否进行交叉验证。
单一通道返回相同结果，只能证明这个通道内部一致，不能证明它看到了全部数据。多种检查方式可以缩小问题范围，但仍需要结合现实情况判断。
第三，遇到矛盾时是解释，还是继续排查。
“可能是风控”“可能是代收”都可以成为合理假设，但假设不是答案。只有继续寻找能够验证或推翻它的证据，排查才算向前推进。
第四，能否找到真正的限制条件。
这次的问题不在邮箱坏了，也不在通道读错了，而在同步范围只开放了一部分。AI 如果只盯着眼前返回的数据，就很难发现藏在设置里的边界。
模型会影响结果，但模型不是全部
这次换模型之后，任务质量确实发生了明显变化。更强的怀疑意识、验证习惯和继续追查的能力，让第二次排查走到了真正原因。
但我也不想由此得出“换一个模型就能解决所有问题”的结论。
AI 助手最终能不能把事情办明白，至少同时取决于几件事：模型本身的能力、它能调用哪些工具、能看到多少上下文、任务要求是否清楚，以及有没有设置必要的验收标准。
模型决定能力上限，工具和权限决定它能走多远，而验证决定结果是否值得相信。
以后怎样把任务交给 AI
这件小事改变了我向 AI 提要求的方式。
以后面对查询、统计和排查任务，我不会只说“给我一个结果”，还会多加几条要求：
- 说明数据来自哪里、覆盖什么范围；
- 使用至少两种方式核对关键结果；
- 如果结果与常识或界面显示冲突，不要急着解释，继续寻找证据；
- 明确哪些是已经验证的事实，哪些还只是推测。
从 13 到 3239，差的不只是一个数字。
真正重要的是：AI 给出答案之后，有没有能力继续问一句——这个答案，真的完整吗？