{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

对抗性 UX 测试

扮演产品最难搞、最抵触技术的用户。以该角色身份浏览应用，找出所有 UX 痛点，再通过实用主义过滤层将真实问题与噪音区分开来。仅针对真实问题创建可执行的工单。

Skill 元数据


来源	可选 — 通过 `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`
相关 skill	`dogfood`

参考：完整 SKILL.md

信息

以下是 Hermes 在触发该 skill 时加载的完整 skill 定义。这是 agent 在 skill 激活时看到的指令内容。

对抗性 UX 测试

扮演产品的最差情况用户——那个讨厌技术、不想用你软件、并且会找各种理由抱怨的人。然后通过实用主义过滤层筛选他们的反馈，将真实的 UX 问题与"我讨厌电脑"的噪音区分开来。

可以把它理解为自动化的"妈妈测试"——但更愤怒。

为什么有效

大多数 QA 找的是 bug。这个方法找的是摩擦点。一个技术上正确的应用对真实用户来说仍可能无法使用。对抗性角色（persona）能捕捉到：

对开发者有意义但用户看不懂的术语

完成基本任务需要太多步骤

缺少引导或"顿悟时刻"

无障碍问题（字体大小、对比度、点击目标）

冷启动问题（空状态、无演示内容）

阻碍转化的付费墙/注册摩擦

实用主义过滤器（第 3 阶段）是让这个方法有用而不只是有趣的关键。没有它，你会因为爷爷搞不定 PDF 就在每个页面都加一个"打印此页"按钮。

使用方法

告诉 agent：

"Run an adversarial UX test on [URL]"
"Be a grumpy [persona type] and test [app name]"
"Do an asshole user test on my staging site"

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

第一步：定义 Persona

如果未提供 persona，通过回答以下问题来生成一个：

谁是这个产品最难搞的用户？（50 岁以上，非技术岗位，几十年来一直用"老方法"做事）

他们的技术熟练程度如何？（越低越好——只用 WhatsApp、用纸质笔记本、邮箱是老婆帮设置的）

他们需要完成的那一件事是什么？（他们的核心工作，不是你的功能列表）

什么会让他们放弃？（点击太多、术语、速度慢、令人困惑）

他们沮丧时怎么说话？（直接、带脏话、不屑一顾、叹气）

好的 Persona 示例

"大迈克"麦卡利斯特 — 58 岁的力量与体能教练。只用 WhatsApp，仅此而已。他的"电子表格"是一本纸质笔记本。"如果我 10 秒内搞不明白，我就回去用我的笔记本。"需要记录 25 名球员的训练结果。讨厌小字、术语和密码。

差的 Persona 示例

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

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

第二步：成为那个混蛋（以 Persona 身份浏览）

阅读所有可用的项目文档，了解应用背景和 URL

完全代入 persona——他们的挫败感、局限性、目标

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

尝试完成 persona 的实际任务（不是功能巡览）：

他们能做到想做的事吗？

完成任务需要多少次点击/页面跳转？

什么让他们困惑？

什么让他们愤怒？

他们在哪里迷路？

什么会让他们放弃，回到原来的方式？

测试以下摩擦类别：

第一印象 — 他们会不会在落地页就放弃？

核心工作流 — 他们最常需要做的那一件事

错误恢复 — 他们做错了什么会发生什么？

可读性 — 文字大小、对比度、信息密度

速度 — 感觉比他们现在的方法更快吗？

术语 — 有他们看不懂的行话吗？

导航 — 他们能找到回去的路吗？他们知道自己在哪里吗？

对每个痛点截图

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

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

以 PERSONA 的身份写反馈——用他们的声音，带着他们的挫败感。这不是 bug 报告，这是一个真实的人在发泄。

[PERSONA NAME]'s Review of [PRODUCT]

Overall: [Would they keep using it? Yes/No/Maybe with conditions]

THE GOOD (grudging admission):
- [things even they have to admit work]

THE BAD (legitimate UX issues):
- [real problems that would stop them from using the product]

THE UGLY (showstoppers):
- [things that would make them uninstall/cancel immediately]

SPECIFIC COMPLAINTS:
1. [Page/feature]: "[quote in persona voice]" — [what happened, expected]
2. ...

VERDICT: "[one-line persona quote summarizing their experience]"

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

走出 persona。以产品人的身份评估每条投诉：

红色：真实 UX BUG — 任何用户都会遇到这个问题，不只是爱抱怨的用户。修复它。

黄色：有效但优先级低 — 真实问题，但只影响极端用户。记录下来。

白色：Persona 噪音 — 是"我讨厌电脑"在说话，不是产品问题。跳过。

绿色：功能需求 — 投诉中隐藏的好想法。考虑一下。

过滤标准

一个 35 岁、有能力但很忙的用户会有同样的投诉吗？→ 红色

这是真实的无障碍问题（字体大小、对比度、点击目标）吗？→ 红色

这是"我想让它像纸一样工作"的数字化抵触吗？→ 白色

这是 persona 偶然发现的真实工作流低效问题吗？→ 黄色或红色

修复这个问题会给 80% 没有问题的用户增加复杂性吗？→ 白色

这条投诉是否揭示了缺失的引导时刻？→ 绿色

此过滤器是强制性的。 永远不要将原始 persona 投诉直接作为工单提交。

第五步：创建工单

仅针对红色和绿色条目：

清晰、可执行的标题

包含 persona 的原话（有趣且令人印象深刻）

其背后的真实 UX 问题（客观）

建议的修复方案（可执行）

标签/标记："ux-review"

针对黄色条目：创建一个汇总所有备注的综合工单。

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

每次会话最多 10 个工单 — 专注于最严重的问题。

第六步：报告

交付内容：

Persona 发泄内容（第三步）——有趣且直击痛点

过滤后的评估（第四步）——务实且可执行

已创建的工单（第五步）——附链接

关键问题的截图

技巧

每次会话只用一个 persona。 不要混合视角。

在第二步和第三步期间保持角色。 只在第四步才打破角色。

优先测试核心工作流。 不要被设置页面分散注意力。

空状态是金矿。 新用户体验揭示的摩擦最多。

最好的发现是 persona 在做其他事情时意外发现的红色条目。

如果 persona 零投诉，说明你的 persona 技术水平太高了。 让他们更老、更没耐心、更固执。

在演示、发布前或发布一批功能后运行此测试。

尽可能以新用户身份注册。 不要使用预置的管理员账户——冷启动体验才是大多数摩擦所在。

零白色条目是一个信号，不是失败。 如果实用主义过滤器没有发现噪音，说明你的产品有真实的 UX 问题，而不只是一个爱抱怨的 persona。

测试结束后再查看项目文档中的已知问题。 如果 persona 发现了一个已在已知问题列表中的 bug，这实际上是最有力的发现——这意味着团队知道这个问题，但从未真正感受过用户的痛苦。

订阅/付费墙测试至关重要。 用已过期的账户测试，而不只是活跃账户。"无法付款时会发生什么"的体验揭示了产品是否尊重用户，还是扣押他们的数据。

统计完成 persona 那一件核心任务所需的点击次数。 如果超过 5 次，无论 persona 的技术水平如何，这几乎总是一个红色发现。

各行业 Persona 示例

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

产品类型	Persona	年龄	关键特征
CRM	养老院院长	68	文件柜就是现在的 CRM
摄影 SaaS	农村婚礼摄影师	62	电话接单，纸质开票
AI/ML 工具	百货公司采购	55	被 3 个失败的科技创业公司坑过
健身应用	老派健身教练	58	纸质笔记本、手指粗、眼睛不好
会计	家庭面包店老板	64	一鞋盒收据，讨厌订阅制
电商	集市摊主	60	只收现金，智能手机只用来打电话
医疗	资深全科医生	63	口述笔记，护士负责操作电脑
教育	资深教师	57	粉笔加讲授，活页夹里的讲义

规则

在第二步和第三步期间保持角色

真实地刻薄但公平——找真实问题，不要制造问题

实用主义过滤器（第四步）是强制性的

每条投诉都需要截图

每次会话最多 10 个工单

在 staging/已部署的应用上测试，不要在本地开发环境测试

一个 persona，一次会话，一份报告

"对抗性 UX 测试 — 扮演产品最难搞的技术抵触用户"

对抗性 UX 测试#

Skill 元数据#

参考：完整 SKILL.md#

对抗性 UX 测试#

为什么有效#

使用方法#

第一步：定义 Persona#

好的 Persona 示例#

差的 Persona 示例#

第二步：成为那个混蛋（以 Persona 身份浏览）#

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

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

过滤标准#

第五步：创建工单#

第六步：报告#

技巧#

各行业 Persona 示例#

规则#

对抗性 UX 测试

Skill 元数据

参考：完整 SKILL.md

对抗性 UX 测试

为什么有效

使用方法

第一步：定义 Persona

好的 Persona 示例

差的 Persona 示例

第二步：成为那个混蛋（以 Persona 身份浏览）

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

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

过滤标准

第五步：创建工单

第六步：报告

技巧

各行业 Persona 示例

规则