让 Claude 扮演小红书读者之后，我更想见真人了

有一次随手试，我让 Claude 扮演过两种人：一种是在小红书上刷到某条笔记的读者，一种是写这条笔记的人。给它看的是随手找来的一段文字，让它说说这段东西到了那两种人手里，会不会被划走。它写得很像。

这也是让 AI 扮演用户时最容易被说服的地方，它能把一个简单的设定写得很具体。给它“赶时间的上班族”，它会补出午休、会议、电梯、网络和预算。一段场景放在面前，比需求文档里那句“操作要方便”好讨论得多。产品设计里一些默认条件也开始露出来：我们是不是默认用户有空看说明，默认网络一直正常，默认他愿意把每一步走完？

但往下看，我又会犹豫。这个用户怎么这么配合？为什么他每一个烦恼，都刚好指向我准备做的功能？

我想保留这个用法，也想把它的边界想明白。它可以帮忙展开假设、检查遗漏，不能因为写得细，就当作见过了真实用户。真正值得拿走的，是一串更具体的问题。

场景不能只剩一个地点

“在家里用”“在公司用”“在路上用”，这些描述有用，但不够。坐在工位上慢慢挑午饭，和开会间隙只有几分钟点餐，都发生在公司，用户愿意投入的注意力却完全不同。

我会沿用 Who、Where、When、How、What 来拆，不是什么新公式，只是提醒自己别漏上下文。Who，他和这项任务有关的经验、身体状态、熟悉程度，比“二十八岁白领”更直接。Where，光线、噪声、周围的人、网络条件。When，临近会议和周末闲逛，对等待、选择和解释的耐心不同。How，设备和动作，也包括现在已经有的办法，切换 App、找同事帮忙，甚至干脆不做。What，显性目标是吃上饭，背后可能还在意按时、预算、口味、少费脑子，这些要当作待确认的动机。

拼起来，才开始接近一个可以讨论的场景。我还会补一句“如果不用我们的产品，他怎么办”，否则很容易把人圈在自己设计的流程里。

让它具体，也别让它补过头

拿早高峰单手点餐来说，我会这么写提示词：

假设用户在拥挤的地铁里，一只手扶着扶手，另一只手操作手机。请分析他完成点餐可能遇到的限制。分开列出设定已经给出的事实、你补充的假设，以及需要通过真实观察确认的地方，不要直接推荐我们必须做哪些功能。

模型可能提出，拇指够不到顶部入口、车厢摇晃导致误触、周围声音影响语音输入、进站时网络变化。都值得检查，但“顶部搜索框无法触及”就过于绝对了。手机尺寸、握法、是否停下来操作，都可能改变结果。直接把这段输出放进需求文档，很容易把“可能”写成“一定”。我的处理是把它变成设计问题：关键操作是否过于依赖精确点击？换一种握姿还能不能完成？有没有必要保留多个入口？

正常流程之外，也给它一些麻烦。支付时断网、字体调大后按钮被挤出屏幕、户外看不清浅灰字，这类情况往往比一段完整故事更值得留下。但没必要让它无止境地列一百种灾难，先看哪些和当前产品有关，再看发生后是否有明确恢复办法。模拟列出来的风险可以进入测试清单，不能替代测试本身。文字说“界面会重叠”和实际看到重叠，是两回事。

用午餐预订走一遍

下面以外卖 App 的午餐预订为例。这是一组用于说明方法的假设，不是真实访谈记录。

先做角色卡，但不把角色卡当结论。“目标用户是上班族”太宽，我会先限制任务，再让 AI 帮我补充需要问的条件：

我在考虑一个工作日午餐预订功能。已知假设是，用户在写字楼工作，午餐时间受会议影响，希望减少点餐时的反复选择。请围绕这项任务制作一张角色卡。将信息分为三类：我已提供的条件、为了讨论暂时补充的设定、必须通过访谈或观察确认的问题。不要把年龄、性别直接推导成口味和消费习惯。请同时列出一个可能不需要这个功能的反例。

假设角色叫 Linda：在写字楼工作，午休名义上一小时，遇到会议时可能只有半小时；暂定一餐预算三十到四十元。这些数字用于固定讨论条件，没有调查依据时不能写进市场结论。如果她的会议经常临时延长，预订也可能带来新麻烦，饭送来了却没法下楼，能不能改时间、放在哪里、谁来取？我更想让角色卡帮我看到这种分歧，而不是生成一个天然需要午餐预订的目标用户。

再把环境展开，沿一次完整任务看，而不是只描述点按钮的几秒钟。模型很容易把合理的细节拼成不合理的时间线，已经在电梯里取餐的人，不一定还在决定午餐点什么。场景越长，越要检查先后关系。可以得到一组待检查的情况：早上预订时，修改和取消是否比“一键下单”更重要；临时点餐时，送达时间是区间还是承诺；在电梯里打开订单，哪些已加载信息可以继续看；和同事一起取餐时，状态提示能不能一眼看清。

第三步才落到数据。容易有两种极端：只有故事，开发不知道缺什么；或者模型列出几十个字段，仿佛采得越多越完整。我会问得收一点，区分业务本身需要的数据、用于诊断体验的问题记录、暂时没有必要采集的数据。角色卡里的疲惫和压力，尤其不该直接变成后台字段。场景分析的产出是需要哪些信息才能把事做好，不是替所有人建立越来越细的画像。

我会怎样使用这份模拟结果

我更愿意把输出分成三份。一份是可以直接检查的产品问题，大字体有没有遮挡、重复点击会不会多下一单，用原型就能测。一份是要问真实用户的问题，他会不会提前订午饭，愿不愿意为了少选一次接受固定套餐，这些不能让模型代答。还有一份是当前不值得投入的设想，模型也会推荐很多听起来体贴的功能，不必每条都进入排期。

团队讨论时，我会带上最初的提示词和场景条件。有人不同意结论，可以往回看：是条件不成立，还是条件成立但设计推论不对？更重要的是，不要展示“九成模拟用户点不到按钮”这种数字。没有真实用户样本，模型扮演一千次，也不能制造出有意义的成功率，相同的设定和偏差可能被重复了一千次。

留下来的习惯有三个。多写限制，用户在什么状态下、缺什么信息、没法做什么，比一长串性格标签有帮助。把异常接着想下去，断网之后怎么恢复，信息冲突时问谁。把感受翻译成可检查的设计要求，“用户很急”不必直接等于三步以内、两百毫秒，而是先看哪一步有无谓等待。

如果 AI 给了一份什么都解释得通的场景，我反而想追问：它有没有允许这个人拒绝我的功能，有没有留下不知道的地方。模拟最该帮到我的，也许就是在见用户之前，把自己那些太确定的想法松一松。