MVP 上线后：如何做第一轮用户测试与产品迭代

联系有近期任务的人#

从之前访谈过、提交过样例或主动询问过进度的人开始。他们已经描述过问题，容易把试用放回实际工作里。

第一轮可以约三到五位符合条件的人，逐个观察。小样本适合找操作障碍和理解偏差，不能据此推断整个市场的留存或付费比例。

邀请时说清处理什么、需要多久、材料会怎样使用。对于需要发送原文给外部模型的工具，在提交前说明这一点，提供公开样例作为选择；不要为了得到“真实数据”，要求对方上传未获授权的内部材料。

1
你之前提到，整理文章标题和摘要比较费时间。
2
现在有一个第一版工具，想请你用一篇允许提交的文章试一次。
3
它只处理中文纯文本，暂不保存历史记录。
4
原文会发送给所选模型服务；不便提交时，可以使用公开样例。
5

6
希望了解你能否完成任务、结果需要改哪里，以及是否适合当前工作。

发送邀请前，按产品的真实功能、数据处理方式和可用时间改好这份模板。

先观察，再解释#

测试开始时，给用户任务和材料，让他自己找输入入口、提交文章、等待结果、复制内容。提前讲解每个按钮的位置，会掩盖页面里不容易理解的地方。

用户停住时，先问“你刚才想做什么”。如果他以为输入框只接收链接，就记录这处误解；如果在等结果，却不知道请求已经失败，就记录失败提示没有被看到。

必要时可以帮助用户继续，但要把这次任务标为“需要帮助后完成”，与独立完成分开。否则统计里会显示全部成功，实际每次都需要开发者解释。

录屏、访谈记录或其他行为数据应先取得相应同意，只收集本轮需要的内容。小规模观察也可以采用脱敏笔记，不必马上接入录像工具。

成功要包括结果可用#

对于内容整理工具，完成标准可以写成：用户提交符合要求的文章，得到三个约定字段，能复制结果，并确认只需可接受的修改就能继续工作。

复制动作可以记录，但它不能单独证明内容有用。用户也可能复制一份错误摘要，或者为了反馈而复制。测试结束后，请他指出具体要改的句子，比问“你满意吗”更容易发现问题。

也可以比较原来的处理方法与当前工具。使用相近难度的材料，记录耗时和返工内容；不要拿一篇简单短文的结果，去对照过去最复杂的一次任务。

先用一张表留下事实#

第一轮可以人工记录，等重复测试多起来再考虑自动统计：

把行为和建议分开。例如，“希望支持 PDF”是一条建议；“为了试用，先花八分钟把 PDF 转成文本”是一条观察。后者能说明当前输入方式增加了什么成本，值得进一步核实。

指标的分母要一致#

如果需要计算完成率，先约定“开始任务”是什么。可以定义为点击提交一份符合要求的输入，再将独立得到可用结果的人数作为分子。不同定义得到的比例不能直接比较。

假设邀请五人，四人开始任务，其中两人独立完成，一人得到帮助后完成，一人失败。这个教学例子可以记为：

1
独立完成率：2 / 4 = 50%。
2
需要帮助后完成：1 人。
3
失败：1 人。
4
未开始任务：1 人，另查未开始原因。

这些记录比“成功率 75%”更便于排查，后者把需要帮助和独立完成混在了一起。样本只有几人时，优先查看每次任务的原因，而不是给比例设行业合格线。

回访也要按问题发生频率解释。每周才整理一次文章的用户，当天没有回来，不说明产品无用。约定一个与任务频率相符的观察时间，再核实是否出现了第二次任务，以及当时选了哪种方法。

根据问题安排修改#

收到反馈后，可以先放进同一份记录，再决定处理顺序：

修复影响当前任务的问题通常优先于扩展功能。少数用户提出的严重问题也可能需要立刻处理，例如错误结果会误导工作、数据暴露或费用失控；不能只按反馈人数排序。

一次只改一个能观察效果的问题。比如把输入提示改清楚，就看是否减少误填；换模型，就用原来的内容样例检查质量和成本。若界面、价格、输入范围和模型一起更换，很难知道变化来自哪里。

用一张迭代卡安排下一轮#

1
问题：用户没有看到输入长度要求，提交后才发现文章太长。
2
证据：填写对应的实际测试编号、版本和操作记录。
3
修改：输入时显示字符数和上限，并给出明确提示。
4
预期：用户能在提交前发现并处理长度问题。
5
复测：使用同类超长材料，观察能否独立完成修改。
6
暂不增加：自动拆文、文件上传和批量处理。

这是示范卡片，证据一栏必须由真实测试补齐。开发结束后把复测结果写回来；提示出现了，却仍没人注意到，就继续查呈现位置和措辞。

我会先自己使用，再邀请目标用户测试，按实际反馈安排修改。开发天数和更新频率不能代替使用记录；这轮改什么，要看用户在哪一步失败，以及修改后能否顺利完成任务。

什么时候继续，什么时候回到需求#

如果用户能得到可用结果，并在下一次同类任务中主动回来，可以围绕已经出现的阻碍继续改。愿意用但不愿付费时，则回到第三篇的价格与付费验证，检查结果价值、替代方案和购买条件。

如果连续几轮都找不到真实任务，或每个人都需要完全不同的结果，先暂停扩展。记录这几轮联系了谁、观察到了什么、哪些假设没有成立，再决定换用户、换场景还是停止这个方向。

下一轮开发就从这些记录里选任务：修复已经发现的失败点，为有证据的新需求估算工作量，再写回开发任务书。