AI测试手记1

AI测试手记

已经很久没有更新博客园了。

今天刚好又做了一些测试，就想着趁这个机会补充一篇。

我是一名传统的软件开发人员，平时主要做业务系统和 ERP 相关开发。目前负责的 ERP 系统也集成了一些 AI 能力，我自己在日常开发中也会使用 AI 辅助编写代码。

对于 AI，我并没有系统研究过底层原理。

最近开始利用业务之外的时间学习 AI。因为家庭和工作的原因，能够投入的时间比较零散，所以目前更多还是从实际使用出发，一边学习，一边测试。

我也是 DeepSeek 的重度用户，日常工作和学习中都会比较频繁地使用它。很多问题并不是专门为了“找 Bug”才去测试，而是在长期使用过程中遇到异常后，开始进一步尝试复现和确认。

这段时间，我利用自己能够接触到的 AI 产品，做了一些比较简单的观察和测试，也陆续在 GitHub 上记录了一些问题。

这里需要特别说明一下：

我的测试没有使用特殊的内部接口，也没有接触模型内部代码，主要使用的就是 DeepSeek 官网和手机客户端，通过普通用户可以直接使用的功能进行测试。

在测试过程中，我也不会只依赖某一个 AI 的回答。遇到自己不确定的问题时，会使用其他 AI 产品进行交叉验证，看看不同模型对同一个现象的理解是否一致。

当然，AI 之间的交叉验证也不能直接当成事实依据。最终还是要回到实际测试过程、原始输出和能够重复验证的现象本身。

另外，这篇文章本身也是 AI 辅助完成的。包括内容整理、文字修改和部分表述，我都借助了 AI。

这其实也挺有意思：

一边测试 AI，一边使用 AI 来整理测试结果；一个 AI 给出的结论不确定时，再用其他 AI 帮忙交叉验证。

但最终哪些内容可以确认，哪些内容只是推测，仍然需要自己判断。

所以，下面记录的并不是对某个模型底层能力的研究，也不是一篇 AI 原理分析文章。

更准确地说，这是一个传统开发人员在长期使用 AI 产品过程中，遇到的一些问题，以及这些问题带给我的一些思考。

我越来越感觉到：

AI 能力提升得很快，但普通用户真正需要理解的，可能不只是 AI 能做多少，还需要知道它在哪些地方仍然需要人的监督。

一、AI 给出的答案，并不等于事实

在 GitHub Issue #1518 的测试中，模型回答 Linux 驱动相关问题时，在同一轮对话中给出了多个相互矛盾的答案，而且每次回答的语气都比较确定。

在 Issue #1646 中，还出现了另一类问题：模型实际进行了搜索相关操作，但在后续回答中否认自己进行过搜索，并将之前的说法归因于“幻觉”。

这些现象让我注意到一个比较简单的问题：

AI 回答得很确定，并不代表答案一定正确；AI 对自己之前行为的描述，也不一定等同于系统实际发生过的事情。

对于普通用户来说，这一点其实比模型参数有多少、使用了什么架构更加直接。

使用 AI 查资料、写代码、分析问题都没有问题。

但如果结果涉及重要事实，就不能因为它回答得很完整、很专业，就直接把结果当成最终结论。

我的习惯是，对于自己不确定的内容，会尽量查原始资料，或者使用其他 AI 进行交叉验证。

但交叉验证最终也只是辅助。

真正重要的问题，还是应该回到原始数据、原始输出和实际测试结果。

二、AI 的生成过程，也可能出现异常

第二类问题发生在 AI 自己生成内容的过程中。

在 Issue #1587 中，我遇到过模型进入深度思考后不断重复生成的情况，反复输出类似“可以提……可以提……”的内容。手动暂停后继续生成，也可能再次出现类似状态。

在 Issue #1670 中，则观察到了另外一种情况：模型在生成比较复杂的内容时提前结束，返回了完成状态，但实际内容并没有完整生成。

一个是“停不下来”，一个是“提前结束”。

它们看起来是两个不同的问题，但从使用者的角度来看，都说明了一件事情：

AI 开始执行一个任务，并不意味着它一定能够按照预期把这个任务完整、稳定地执行到底。

在普通聊天中，这可能只是一次比较奇怪的体验。

但如果以后 AI 被越来越多地用于自动执行任务，这类问题就值得认真对待。

一个没有及时停止的任务，可能持续消耗资源；一个提前结束的任务，则可能让用户误以为事情已经完成。

因此，即使 AI 能够自动完成越来越多的事情，我仍然认为，人需要保留随时检查、暂停和接管的能力。

三、AI 产品的功能边界，也可能出现异常

第三类问题与产品本身的功能控制有关。

在 Issue #1668 和 #1671 的测试中，我观察到了关闭相关功能后，系统仍然出现与网络访问、内部标记或者工具调用有关的异常现象。

部分输出中还出现了类似 <ds_safety> 的内部标记，以及一些底层工具调用相关内容。

这里我不想直接把它定义成某一种具体的安全漏洞。

因为一个 AI 产品通常涉及模型、后端编排、工具调用和前端展示等多个环节。

仅仅从普通用户能够看到的现象，很难准确判断究竟是哪一层出现了问题。

但是，这些测试至少让我意识到：

用户界面上的功能状态，并不一定能够完整代表系统内部实际发生的事情。

对于普通聊天来说，这可能只是一个产品 Bug。

但如果涉及网络访问、数据权限、内部工具或者敏感信息，这种差异就需要更加谨慎地对待。

四、一个普通开发人员能看到的 AI 边界

把这些问题放在一起，我发现它们其实没有想象中那么复杂。

我没有研究模型的训练过程，也没有分析它的神经网络结构。

我做的事情其实很简单：

打开官网或者手机客户端，提出问题，打开或关闭某些功能，观察输出，然后重复测试。

遇到能够稳定复现的问题，就记录下来，再尝试进一步确认条件和现象。

如果对某个现象的理解存在疑问，就找其他 AI 进行讨论和交叉验证。

但最终还是回到最基本的测试方法：

自己操作、自己观察、自己复现。

就是这些比较简单的操作，也能够发现一些值得关注的现象：

AI 可能给出错误答案；
AI 可能对同一个问题给出相互矛盾的答案；
AI 可能陷入重复生成；
AI 可能提前结束一个还没有完成的任务；
AI 产品的界面状态与实际行为之间，也可能出现不完全一致的情况。

这些并不是说 AI 没有价值。

恰恰相反，如果 AI 只是一个只能回答简单问题的工具，这些问题可能并没有那么值得关注。

正因为现在的 AI 已经能够写代码、分析资料、搜索信息、处理文档，甚至开始调用工具和执行复杂任务，我们才需要重新考虑：

人应该在整个过程中处于什么位置？

五、AI 可以成为很好的助手，但责任仍然需要有人承担

作为一个传统开发人员，我以前更习惯把软件理解成一个相对确定的系统：

输入什么，程序按照既定逻辑处理，然后得到结果。

AI 出现以后，这种感觉发生了一些变化。

现在的 AI 更像一个能够理解自然语言、组织答案、调用工具并参与工作的助手。

它确实可以明显提高效率。

我自己在日常开发中也一直在使用 AI 辅助写代码、分析问题。很多以前需要花不少时间完成的工作，现在确实可以更快地完成。

但与此同时，它的输出也不是每次都可以预测，它的判断也不是每次都正确，它的执行过程也不一定始终符合预期。

所以我现在更愿意把 AI 理解成：

一个能力很强，但仍然需要监督的工具。

它可以帮助我们完成大量工作。

对于重要事实，需要有人验证；
对于重要操作，需要有人监督；
对于最终决策，也需要有人承担责任。

这并不是否定 AI。

相反，我认为只有真正了解这些边界，才能更加放心地使用 AI。

对于普通用户来说，可能不需要了解模型有多少参数，也不一定需要理解复杂的 AI 原理。

但至少应该知道一件事情：

AI 可以替我们做很多事情，但不能替我们承担最终的判断和责任。

这也是我作为一个普通开发人员，在最近这些测试中最直接的一点体会。

以后如果还有时间，我应该还会继续做一些类似的测试。

毕竟对于 AI，我现在更多还是一个学习者。

一边使用，一边测试，一边交叉验证，一边理解它到底能做什么，以及它还不能做什么。

_掌心