Adversarial Ux Test

扮演最挑剔、最抗拒技术的用户来测试你的产品。以该用户角色的身份浏览应用，找出每一个用户体验痛点，然后通过一层实用主义过滤器筛选投诉，区分出真正的问题和噪音。只针对真实问题生成可操作的任务工单。

技能元信息

来源	可选 — 使用 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 在触发该技能时加载的完整技能定义。这是 Agent 在技能激活时看到的指令。

Adversarial UX Test

扮演你的产品最糟糕的用户 —— 那种讨厌科技、不想要你的软件、并且会找出所有理由来抱怨的人。然后通过一层实用主义过滤器来筛选他们的反馈，将真正的 UX 问题与“我讨厌电脑”的噪音区分开。

可以把它看作是一个自动化的“老妈测试”——只不过脾气更暴躁。

为什么这招有效

大多数质量保障能找到 Bug。但这招能找到摩擦。一个在技术上正确的应用，对真实用户来说可能仍然难以使用。这种对抗性角色能捕捉到：

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

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

如何使用

告诉 Agent：

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

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

第一步：定义角色

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

1. 这个产品最难搞的用户是谁？（50岁以上、非技术岗位、几十年都在按“老办法”做事）
2. 他们的技术水平如何？（越低越好——只会用 WhatsApp、纸质笔记本、老婆给设的邮箱）
3. 他们需要完成的唯一一件事是什么？（他们的核心工作，而不是你的功能列表）
4. 什么会让他们放弃？（点击太多、术语太多、太慢、太困惑）
5. 他们感到沮丧时怎么说话？（直白、骂人、不屑、叹气）

好的角色示例

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

--- 结束文档片段 ---

糟糕的角色示例

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

角色必须足够具体，以便在20分钟的测试中保持角色一致。

第二步：变成混蛋（以角色身份浏览）

1. 阅读所有可用的项目文档，了解应用上下文和URL

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

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

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

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

5. 测试以下摩擦类别：

   • 第一印象 —— 他们甚至会费心浏览着陆页吗？
   • 核心工作流 —— 他们最常做的一件事
   • 错误恢复 —— 当他们做错事时会发生什么？
   • 可读性 —— 文本大小、对比度、信息密度
   • 速度 —— 感觉比他们当前的方法快吗？
   • 术语 —— 有没有他们不理解的 jargon？
   • 导航 —— 他们能原路返回吗？他们知道自己在哪吗？

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

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

第三步：发泄（以角色身份写反馈）

以角色的身份写反馈 —— 用他们的语气，带着他们的挫折感。这不是一份 bug 报告。这是一个真实的人在吐槽。

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

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

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

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

丑陋的方面（致命障碍）：
- [会让他们立即卸载/取消的东西]

具体投诉：
1. [页面/功能]："[角色原话]" —— [发生了什么，期望什么]
2. ...

最终结论："[一句话的角色原话，总结他们的体验]"

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

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

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

过滤标准

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

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

第 5 步：创建工单

仅针对 RED 和 GREEN 项目：

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

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

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

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

第 6 步：报告

交付内容：

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

提示

• 每次会话只使用一个人设。 不要混合不同视角。
• 在第 2–3 步期间保持角色。 只在第 4 步跳出角色。
• 先测试核心工作流。 不要在设置页面分心。
• 空白状态是金矿。 新用户体验最能暴露摩擦点。
• 最佳发现是用户在做其他事情时偶然发现的 RED 项目。
• 如果人设没有任何抱怨，那你的人设太懂技术了。 把年纪设大一些，耐心少一些，更固执一些。
• 在演示、发布或批量功能上线前运行此测试。
• 尽可能注册为新用户。 不要使用预置的管理员账户——冷启动体验是摩擦最多的地方。
• 零 WHITE 项目不是失败，而是一个信号。 如果务实过滤器找不到噪音，说明你的产品确实有用户体验问题，而不仅仅是人设在抱怨。
• 测试后再检查项目文档中的已知问题。 如果人设发现了一个已在已知问题列表中的 bug，那实际上是最致命的发现——说明团队明知问题存在，却从未感受过用户的痛苦。
• 订阅/付费墙测试至关重要。 用过期账户测试，而不仅仅是活跃账户。“当你付不了费时会发生什么”这个体验，能揭示产品是尊重用户，还是在挟持用户数据。
• 计算完成人设的单一任务所需的点击次数。 如果超过 5 次，那几乎总是 RED 发现，无论人设的技术水平如何。

按行业分列的示例人设

以下为起点——请根据你的具体产品进行定制：

产品类型	人设	年龄	关键特征
CRM	养老院院长	68	目前用的是文件柜作为 CRM
摄影 SaaS	乡村婚礼摄影师	62	用电话接客户，纸质发票
AI/ML 工具	百货商店采购员	55	被 3 家失败的科技初创公司伤过
健身应用	传统健身房教练	58	纸质笔记本，手指粗，眼神差
会计	家庭面包店老板	64	鞋盒装收据，讨厌订阅制
电商	菜市场摊主	60	只收现金，手机只用来打电话
医疗健康	资深全科医生	63	口述病历，护士操作电脑
教育	资深教师	57	粉笔加讲课，练习本装订在文件夹里

规则

• 在第 2-3 步期间保持角色设定
• 要真正刻薄但公平——找出真实问题，而不是捏造的问题
• 实用主义过滤器（第 4 步）是强制性的
• 每个投诉都需要截图
• 每轮会话最多 10 个工单
• 在预发布/已部署的应用上测试，而不是本地开发环境
• 一个人设、一轮会话、一份报告