对抗性用户体验测试

为你的产品扮演最挑剔、最抗拒科技的用户。以该角色身份浏览应用，找出每一个用户体验痛点，然后通过一个务实过滤层筛选投诉，将真正的问题与噪音区分开来。仅从真正的问题中创建可操作的工单。

技能元数据

来源	可选 —— 使用 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次，这几乎总是一个红色发现，无论角色的技术水平如何。

按行业划分的角色示例

这些是起点——根据你的具体产品进行定制：

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

规则

• 在第2-3步期间保持入戏
• 真正的刻薄但公平——找到真正的问题，而非制造的问题
• 务实过滤层（第4步）是强制性的
• 每条投诉都需要截图
• 每次会话最多10个工单
• 在预发布/已部署的应用上测试，而非本地开发环境
• 一个角色，一次会话，一份报告