对抗性用户体验测试

扮演你产品中最难搞、最抗拒技术的用户。以该角色浏览应用，找出所有用户体验痛点，然后通过实用主义层过滤投诉，将真正的问题从噪声中分离出来。仅从真实问题创建可执行的工单。

技能元数据

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

参考：完整 SKILL.md

信息

以下是该技能被触发时 Hermes 加载的完整技能定义。当技能激活时，Agent 会将其视为指令。

对抗性用户体验测试

扮演你产品的最坏情况用户——一个讨厌技术、不想要你的软件、并且会找各种理由抱怨的人。然后通过实用主义层过滤他们的反馈，将真正的用户体验问题从“我讨厌电脑”的噪声中分离出来。

把它想象成自动化的“妈妈测试”——但更暴躁。

为什么这管用

大多数 QA 测试发现的是 bug。这个测试发现的是 摩擦。一个技术上正确的应用，对真人来说可能仍然很难用。对抗性角色能捕捉到：

• 让开发者觉得合理但用户看不懂的混淆术语
• 完成基本任务需要的步骤太多
• 缺少新手引导或“啊哈时刻”
• 可访问性问题（字体大小、对比度、点击目标）
• 冷启动问题（空状态、没有演示内容）
• 影响转化率的付费墙/注册摩擦

实用主义过滤器（第三阶段）正是让它变得有用而不是仅仅有趣的关键。没有它，你会在每个屏幕上都加一个“打印此页”的按钮，因为老爷爷不会用 PDF。

如何使用

告诉 Agent：

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

你可以提供一个角色，也可以让 Agent 根据你产品的目标受众自动生成一个。

第一步：定义角色

如果没有提供角色，请通过回答以下问题来生成一个：

1. 谁是这个产品最难搞的用户？（年龄 50+、非技术岗位、有几十年“老方法”经验）
2. 他们的技术舒适度如何？（越低越好——只会用 WhatsApp、纸质笔记本、老婆帮他们设置的邮箱）
3. 他们需要完成的唯一一件事是什么？（他们的核心工作，不是你的功能列表）
4. 什么会让他们放弃？（点击太多、术语、慢、困惑）
5. 他们沮丧时怎么说话？（直白、爱骂人、不耐烦、叹气）

好的角色示例

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

反面角色示例

"一个不喜欢该应用的用户"——过于模糊，没有约束条件，没有语气。

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

第二步：化身“刁民”（以角色身份浏览）

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

2. 完全代入角色——他们的挫败感、限制条件和目标

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

4. 尝试角色的实际任务（而不是功能导览）：

   • 他们能完成想做的事吗？
   • 需要多少次点击/多少个页面才能完成？
   • 什么让他们感到困惑？
   • 什么让他们生气？
   • 他们在哪里迷失方向？
   • 什么会让他们放弃并回到旧方法？

5. 测试以下摩擦类别：

   • 第一印象——他们是否愿意费心越过着陆页？
   • 核心工作流——他们最常需要做的那一件事
   • 错误恢复——当他们做错事时会发生什么？
   • 可读性——文本大小、对比度、信息密度
   • 速度——感觉比他们当前的方法快吗？
   • 术语——有没有他们理解不了的行业术语？
   • 导航——他们能找到回去的路吗？他们知道自己在哪里吗？

6. 对每个痛点截图

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

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

以角色的身份撰写反馈——用他们的语气，表达他们的挫败感。这不是一份 bug 报告。这是一个真实的人在发泄。

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

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

好的方面（勉强承认）：
- [连他们也不得不承认好用的地方]

不好的方面（合理的 UX 问题）：
- [会阻止他们使用产品的真正问题]

糟糕的方面（致命问题）：
- [会让他们立即卸载/取消的东西]

具体投诉：
1. [页面/功能]："[角色语气的引述]" — [发生了什么，预期是什么]
2. ...

结论："[一句话的角色引述，总结他们的体验]"

第四步：实用主义过滤器（关键——不可跳过）

跳出角色。以产品人员的身份评估每条投诉：

• 红色：真正的 UX Bug——任何用户都会遇到这个问题，不仅仅是脾气暴躁的用户。修复它。
• 黄色：有效但优先级低——真实问题，但只针对极端用户。记录下来。
• 白色：角色噪音——是“我讨厌电脑”在说话，不是产品问题。跳过它。
• 绿色：功能请求——投诉中隐藏的好主意。考虑它。

过滤标准

1. 一个 35 岁、能干但忙碌的用户会有同样的投诉吗？→ 红色
2. 这是真正的可访问性问题（字体大小、对比度、点击目标）吗？→ 红色
3. 这是“我希望它像纸一样工作”对数字化的抵触吗？→ 白色
4. 这是角色偶然发现的真正工作流低效问题吗？→ 黄色或红色
5. 修复这个问题会增加 80% 正常用户的复杂性吗？→ 白色
6. 投诉是否揭示了缺失的上手引导环节？→ 绿色

此过滤器是强制性的。 切勿将原始的角色投诉直接作为工单提交。

第 5 步：创建工单

仅针对 RED 和 GREEN 项：

• 清晰、可操作的标题
• 包含用户角色的原话引用（有趣且令人印象深刻）
• 底层的真实 UX 问题（客观描述）
• 建议的修复方案（可操作）
• 标签/标记："ux-review"

针对 YELLOW 项：创建一个汇总工单，包含所有备注。

WHITE 项仅出现在报告中，不创建工单。

每轮测试最多 10 个工单 —— 聚焦在最严重的问题上。

第 6 步：报告

交付内容：

1. 用户角色的吐槽（第 3 步）—— 生动且直击痛点
2. 过滤后的评估（第 4 步）—— 务实且可操作
3. 已创建的工单（第 5 步）—— 附带链接
4. 关键问题的截图

提示

• 每轮测试只用一个用户角色。 不要混合不同视角。
• 在第 2-3 步期间保持角色扮演。 只在第 4 步时跳出角色。
• 优先测试核心工作流。 不要被设置页面分散注意力。
• 空状态是金矿。 新用户体验最能暴露摩擦点。
• 最好的发现是用户角色在尝试做其他事情时意外找到的 RED 项。
• 如果用户角色零抱怨，说明你的角色设定得太懂技术了。 把角色设得更年长、更没耐心、更固执己见。
• 在演示、发布或推送一批功能之前运行此测试。
• 尽可能注册为新用户。 不要使用预置的管理员账户 —— 冷启动体验是摩擦最多的地方。
• 零 WHITE 项是一个信号，不是失败。 如果务实过滤器没有发现噪音，说明你的产品存在真正的 UX 问题，而不仅仅是一个脾气暴躁的用户角色。
• 测试结束后再查看项目文档中的已知问题。 如果用户角色发现了一个已在已知问题列表中的 bug，这实际上是最致命的发现 —— 说明团队早就知道但从未感受过用户的痛苦。
• 订阅/付费墙测试至关重要。 不仅要测试活跃账户，还要测试过期账户。"付不了费会发生什么"的体验能揭示产品是尊重用户还是挟持用户数据。
• 统计完成用户角色单一任务所需的点击次数。 如果超过 5 次，无论用户角色的技术水平如何，这几乎总是 RED 发现。

按行业划分的示例用户角色

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

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

规则

• 在步骤2-3期间保持角色一致
• 要真正地挑剔但公正——找出真实的问题，而不是编造的问题
• 实用主义过滤器（步骤4）是强制性的
• 每条投诉都需要截图
• 每次会话最多10个ticket
• 在staging/已部署的应用上测试，而不是本地开发环境
• 一个角色，一次会话，一份报告