对抗性用户体验测试

扮演您产品中最难应付、最抗拒技术的用户。以该用户身份浏览应用程序，找出每一个用户体验痛点，然后通过务实筛选层来过滤投诉，区分真正的问题和无关的噪音。仅针对真实问题创建可执行的工单。

技能元数据

来源	可选 — 使用 hermes skills install official/dogfood/adversarial-ux-test 安装
路径	optional-skills/dogfood/adversarial-ux-test
版本	1.0.0
作者	Omni @ Comelse
许可证	MIT
平台	linux, macos, windows
标签	qa, ux, testing, adversarial, dogfood, personas, user-testing
相关技能	dogfood

参考：完整的 SKILL.md

信息

以下是此技能被触发时，Hermes 加载的完整技能定义。这是技能处于活动状态时智能体看到的指令。

对抗性用户体验测试

为您的产品扮演最差情况下的用户——一个讨厌技术、不想要您的软件、会找出每一个抱怨理由的人。然后通过务实筛选层来过滤他们的反馈，将真正的用户体验问题从“我讨厌电脑”的噪音中分离出来。

可以将其视为一个自动化版的“妈妈测试”——但这个“妈妈”很生气。

为什么有效

大多数质量保证测试发现的是程序错误。这个测试发现的是摩擦。一个技术上正确的应用程序对真人用户来说可能仍然难以使用。对抗性角色能捕捉到：

• 令开发者困惑、但对用户来说毫无意义的术语
• 完成基本任务步骤太多
• 缺少新手引导或“顿悟时刻”
• 无障碍性问题（字体大小、对比度、点击目标）
• 冷启动问题（空白状态、无演示内容）
• 摧毁转化的付费墙/注册摩擦

务实筛选（第3步）是让此方法实用而非仅仅是有趣的关键。没有它，你可能会在每个屏幕上都添加一个“打印此页面”按钮，只因为爷爷不知道怎么用PDF。

如何使用

告诉智能体：

“在 [URL] 上运行对抗性用户体验测试”
“扮演一个暴躁的 [角色类型] 测试 [应用名称]”
“在我的预发布站点上做一个混蛋用户测试”

您可以提供一个角色设定，或者让智能体根据您产品的目标用户生成一个。

第1步：定义角色设定

如果未提供角色设定，则通过回答以下问题生成一个：

1. 谁是这个产品最困难的用户？（50岁以上、非技术岗位、几十年都用“老方法”做事）
2. 他们的技术舒适度如何？（越低越好——只用WhatsApp、纸质笔记本、邮箱都是妻子帮忙设置的）
3. 他们需要完成的那件事是什么？（他们的核心工作，不是你的功能列表）
4. 什么会让他们放弃？（点击太多、行话太多、太慢、令人困惑）
5. 他们沮丧时怎么说话？（直率、骂人、不屑、叹气）

好的角色设定示例

“大个子米克”麦卡利斯特 —— 58岁的体能教练。只用WhatsApp。他的“电子表格”是一个纸质笔记本。“如果我10秒钟内搞不懂，我就回去用我的笔记本。”需要为25名球员记录训练结果。讨厌小字、行话和密码。

坏的角色设定示例

“一个不喜欢这个应用的用户” —— 太模糊，没有约束，没有声音。

角色设定必须足够具体，以便在20分钟的测试中保持角色状态。

第2步：成为混蛋（以角色设定身份浏览）

1. 阅读任何可用的项目文档，了解应用背景和URL

2. 完全进入角色 —— 他们的挫折感、限制、目标

3. 使用浏览器工具导航到应用

4. 尝试角色设定的实际任务**（不是功能展示）：

   • 他们能完成他们来这里要做的事吗？
   • 完成任务需要多少次点击/屏幕？
   • 什么让他们困惑？
   • 什么让他们生气？
   • 他们在哪里迷路了？
   • 什么会让他们放弃并回到老办法？

5. 测试这些摩擦类别：

   • 第一印象 —— 他们过了着陆页还会继续吗？
   • 核心工作流 —— 他们最常需要做的那件事
   • 错误恢复 —— 当他们做错事时会发生什么？
   • 可读性 —— 文字大小、对比度、信息密度
   • 速度 —— 是否感觉比他们当前的方法更快？
   • 术语 —— 有任何他们听不懂的行话吗？
   • 导航 —— 他们能找回去吗？他们知道自己在哪里吗？

6. 截取每个痛点的屏幕截图

7. 在每个页面检查浏览器控制台是否有JS错误

第3步：吐槽（以角色身份撰写反馈）

以角色设定的身份撰写反馈——用他们的声音，带着他们的挫败感。这不是一个错误报告。这是一个真人在发泄。

[角色名称] 对 [产品] 的评论

总体评价：[他们会继续使用吗？是/否/也许有条件地]

好的地方（不情愿的承认）：
- [即使是他们也必须承认做得好的事情]

糟糕的地方（合法的用户体验问题）：
- [会阻止他们使用产品的真实问题]

丑陋的地方（致命问题）：
- [会让他们立即卸载/取消的事情]

具体投诉：
1. [页面/功能]：“[用角色声音引用的原话]” —— [发生了什么，期望是什么]
2. ...

结论：“[一句用角色声音总结其体验的话]”

第4步：务实筛选（至关重要 —— 不可跳过）

跳出角色设定。作为产品人员评估每项投诉：

• 红色：真实的用户体验缺陷 —— 任何用户都会遇到此问题，不仅仅是暴躁的用户。需要修复。
• 黄色：有效但优先级低 —— 真实问题，但仅针对极端用户。记录下来。
• 白色：角色噪音 —— “我讨厌电脑”的言论，不是产品问题。跳过。
• 绿色：功能请求 —— 投诉中隐藏的好主意。考虑一下。

筛选标准

1. 一个35岁、能干但忙碌的用户会有同样的投诉吗？→ 红色
2. 这是真正的无障碍问题吗（字体大小、对比度、点击目标）？→ 红色
3. 这是“我想要它像纸一样工作”的抗拒数字化吗？→ 白色
4. 这是角色无意中发现的真实工作流低效问题吗？→ 黄色或红色
5. 修复此问题会增加那80%没问题的用户的复杂性吗？→ 白色
6. 这个投诉是否揭示了缺失的新手引导时刻？→ 绿色

此筛选是强制性的。 永远不要将原始角色投诉作为工单发布。

第5步：创建工单

仅针对红色和绿色项目：

• 清晰、可执行的标题
• 包含角色设定的原话引用（有趣且令人难忘）
• 其下真正用户体验问题（客观描述）
• 建议的修复方案（可执行）
• 标签/标签：“ux-review”

针对黄色项目：一个包含所有注释的汇总工单。

白色项目仅出现在报告中。不创建工单。

每次会话最多10个工单 —— 聚焦最严重的问题。

第6步：报告

交付：

1. 角色吐槽（第3步）—— 有趣且生动
2. 过滤后的评估（第4步）—— 务实且可执行
3. 已创建的工单（第5步）—— 附链接
4. 关键问题的屏幕截图

技巧

• 每次会话一个角色。 不要混合视角。
• 在第2-3步保持角色状态。 仅在第4步跳出角色。
• 首先测试核心工作流。 不要被设置页面分散注意力。
• 空白状态是金矿。 新手体验揭示了最多的摩擦。
• 最好的发现是角色在尝试做其他事情时意外发现的红色项。
• 如果角色设定零投诉，说明你的角色太懂技术了。 让他们年龄更大、更没耐心、更固执己见。
• 在演示、发布或发布一批功能后运行此测试。
• 尽可能以新用户身份注册。 不要使用预先设置的管理员账户——冷启动体验是大多数摩擦所在。
• 零白色项是一个信号，不是失败。 如果务实筛选没有发现噪音，说明你的产品有真正的用户体验问题，而不仅仅是一个暴躁的角色。
• 测试后检查项目文档中的已知问题。 如果角色发现了一个已经在已知问题列表中的错误，这实际上是最具破坏性的发现——这意味着团队知道它但从未感受到用户的痛苦。
• 订阅/付费墙测试至关重要。 使用过期账户测试，而不仅仅是活跃账户。当无法支付时发生什么，揭示了产品是尊重用户还是劫持了他们的数据。
• 计算完成角色那项任务的点击次数。 如果超过5次，这几乎总是红色发现，无论角色的技术水平如何。

按行业示例角色设定

这些是起点——为您的具体产品定制：

产品类型	角色设定	年龄	关键特征
CRM	养老院院长	68岁	文件柜是当前的CRM
摄影SaaS	乡村婚礼摄影师	62岁	通过电话接客户，用纸开发票
AI/ML工具	百货公司采购员	55岁	被3个失败的科技创业公司伤过
健身应用	老派健身房教练	58岁	纸质笔记本，手指粗，视力差
会计软件	家庭面包店老板	64岁	鞋盒装收据，讨厌订阅
电子商务	市场摊贩	60岁	只收现金，智能手机只用来打电话
医疗保健	资深全科医生	63岁	口述笔记，护士操作电脑
教育	资深教师	57岁	粉笔和讲授，活页夹里的练习题

规则

• 在第2-3步保持角色状态
• 真诚地刻薄但公平——找出真正的问题，而不是捏造的问题
• 务实筛选（第4步）是强制的
• 每个投诉都需要屏幕截图
• 每次会话最多10个工单
• 在预发布/已部署的应用上测试，而不是本地开发环境
• 一个角色，一次会话，一份报告