从没测过软件，怎么测你用 AI 做出来的应用

你用 AI 做了一个应用。在顺利的那条路上它能用 —— 你输入名字、点击按钮、看到成功界面。然后呢？它准备好发给你那三个内测用户了吗？发给你的团队？你的客户？

如果你没有软件背景，测试听起来就像那种”真正的开发者”才会做的事 —— 又是框架、又是断言、又是 CI 流水线。好消息是：大多数测试根本不是那么回事。大多数测试，尤其是当你刚上线一个又小又新的东西时，其实就是一个人带着目的到处点点点。这个你完全做得到。这篇文章讲的就是如何有意识地去做，好让你在用户之前先把 bug 找出来。

目标不是像专家那样测试你用 AI 做的应用，而是像一个真心希望它能用、又有点疑神疑鬼的朋友那样去测。

两张清单的小窍门

在你点任何东西之前，先花十分钟，对着一个空白文档，写两张清单。

**清单 A —— 顺利路径。**用户应该用这个应用做的三四件事是什么？对一个典型的 SaaS 来说，可能是：注册、创建第一个项目、邀请一名队友、导出一个结果。对一个目录型的应用：搜索、筛选、点开一条信息、收藏它。三四个真实的流程，用大白话写出来。

**清单 B —— 不顺利路径。**如果用户做的事差不多对、但又没完全对呢？输入邮箱时打错一个字。流程做到一半点了返回。开两个标签页，在两边改同一个东西。提交一个空表单。把一个 Word 文档的内容 —— 连同格式 —— 粘贴进一个文本框。合上笔记本，十分钟后再打开。试着用一个系统里已经存在的邮箱地址去邀请队友。

顺利路径那张清单，是你的 AI 应用构建器为之优化的对象。也是 AI 在写代码时在脑子里测过的东西。不顺利路径那张清单，才是 bug 藏身的地方，因为几乎没人 —— AI 没有，你在写提示词的时候也没有 —— 想过那些情况。

真正测试的时候，先走一遍清单 A，确认基本功能没问题。然后把大部分时间花在清单 B 上。清单 B 才是价值所在。清单 B 也是你弄清楚”事情走偏时，你到底希望应用怎么反应”的地方，而这往往会逼出一次和 AI 构建器之间的澄清对话（“表单填了一半时，应该弹出警告还是自动保存？”）。

三件可以故意搞坏的事

有了清单之后，下面这三类情况，能抓出 AI 做的应用里大多数真实的 bug。

**空的和奇怪的输入。**什么都不填就提交表单。只填一个字段就提交。提交一个 500 个字符那么长的名字。提交一个带 emoji 的名字。往一个本该填名字的字段里粘一个网址。在邮箱字段里试试 “test”、“test@”、“test@example”，再试试 “a@b.co” 这个地址 —— 它接受合法的短邮箱吗？AI 应用构建器常常会加校验，但校验可能两个方向都出错 —— 太严（把真实用户挡在门外）或者太松（什么垃圾都收）。

**往回走、往旁边走。**大多数应用，只要你像一个听话的旅行团那样一步步走过去，它都没问题。可一旦有人开始乱逛，它就崩了。点返回键。再点前进。流程进行到一半时刷新页面。在两个标签页里打开同一个页面，两边都改。退出登录再登回来。如果有”撤销”按钮，连按三次。这些都不是边角情况，这才是真实的人用软件的方式。

**事后的数据。**做一个你的应用本该能做出来的东西。一个项目、一篇帖子、一条记录，随便什么。然后明天再回来。它还在吗？格式撑过来了吗？如果你编辑它，编辑保存了吗？如果你删掉它，它是真的没了，还是一刷新又冒出来了？AI 应用构建器常常把”创建”流程做得很完美，却忘了你创建的一切都需要留存下来、并且以后还能编辑。

“够好”长什么样

你永远没法把用 AI 做的应用测到完美。软件太错综复杂，而你的时间又太宝贵。问题不是”它完美吗” —— 而是”对于我接下来要请来用它的那群人来说，它够好了吗”。

下面这套粗略的层级，你可以拿去用。

**够好可以演示：**顺利路径能跑通、不崩溃。按钮都跳到该去的地方。你能录一段屏幕演示，中间不用剪掉任何片段。

**够好可以给友善的用户用：**不顺利路径不会丢数据。表单会告诉你哪里错了，而不是默默地失败。刷新页面不会把东西搞坏。三个朋友能用起来，不用来私信向你求助。

**够好可以给付费用户用：**应用能扛住你素未谋面的用户。他们的浏览器、他们的数据、他们的习惯。你有办法知道东西什么时候出了问题（基本的错误追踪就够了 —— 你不需要一个花哨的仪表盘）。你能修复并重新部署，而不会把已经在用的人搞崩。

大多数构建者会在”友善用户”这个层级就上线，然后随着反馈进来再升级。这是对的。错误的做法是想从”够好可以演示”直接跳到”够好可以给付费用户用”，而跳过了中间那一步。友善用户会发现真实用户也会发现的问题 —— 但他们不会因此发火。利用好这个落差。

什么时候让 AI 替你测

你的 AI 应用构建器能帮你测试，但你得明确说出你想要什么。“加一些测试”是个糟糕的提示词。它会生成一些看起来像测试、而且多半能通过的代码，却并没有真正检查你在意的任何东西。那些自动生成的测试，大多只是在确认 1+1 还等于 2。

一个更好的提示词是：“我刚才把注册表单的邮箱字段留空提交，结果它崩了。找到处理这块的地方，加一个检查，改成显示一个友善的报错。“具体的 bug、具体的修法、具体的结果。AI 很擅长这个。它不擅长”确保我的应用没有 bug”，因为那不是一个任务 —— 那是一个愿望。

AI 构建器另一个擅长的，是重现你的 bug。如果你描述清楚你做了什么、你期望什么、实际发生了什么，构建器通常就能顺着代码追下去，并提出一个修复方案。你需要的纪律，就是把这三件事清清楚楚地写下来。大多数新手的 bug 报告都是某种版本的”它不工作”。大多数可修复的 bug 报告都是”我点了 X，期望是 Y，结果得到了 Z”。

测试是阅读，不只是点击

最后一件事。你不必看懂用 AI 做的应用里的每一行代码，也能测得很好。但你至少应该扫一眼。打开 AI 刚改过的那个文件。读一读它加上去的那个函数。你不需要知道每个关键字是什么意思 —— 你需要知道的是，这个函数看起来是不是在做你要它做的事。

很多 AI 做出来的 bug 并不是”代码坏了”，而是”代码做的事跟你想要的稍微不一样”。一个字段保存到了错误的地方。一个按钮更新了一样东西，却没更新与之相关的那样。一个”删除”按钮其实是隐藏、而不是删除。不读一读到底做出来的是什么，你是抓不到这些的。

把代码当成一个你可以审查的东西，而不是一个你必须亲手去写的东西。这就是”一个你信得过的 AI 应用”和”一个你只能祈祷它能用的应用”之间的区别。

简版

如果别的都记不住，那就记住：写下那两张清单，故意去搞坏东西，然后决定你要在哪个”够好”的层级上线。AI 做的应用里大多数 bug 都不微妙。它们就摆在那张没人愿意写下来的”不顺利路径”清单上。

如果想给自己留一点小作业：挑一个你做过的应用，试这四件事 —— 提交一个空表单、流程做到一半点刷新、编辑一条记录然后明天来看它、请一个朋友在你不盯着的情况下用一用。凡是坏掉的，就是你真正的 bug 清单。其他的一切，都只是拖延。