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

{/* 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`](/user-guide/skills/bundled/dogfood/dogfood-dogfood) |

## 参考：完整 SKILL.md

:::info
以下是 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，通过回答以下问题来生成一个：

1. **谁是这个产品最难搞的用户？**（50 岁以上，非技术岗位，几十年来一直用"老方法"做事）
2. **他们的技术熟练程度如何？**（越低越好——只用 WhatsApp、用纸质笔记本、邮箱是老婆帮设置的）
3. **他们需要完成的那一件事是什么？**（他们的核心工作，不是你的功能列表）
4. **什么会让他们放弃？**（点击太多、术语、速度慢、令人困惑）
5. **他们沮丧时怎么说话？**（直接、带脏话、不屑一顾、叹气）

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

### 差的 Persona 示例
> "一个不喜欢这个应用的用户"——太模糊，没有约束，没有声音。

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

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

1. 阅读所有可用的项目文档，了解应用背景和 URL
2. **完全代入 persona**——他们的挫败感、局限性、目标
3. 使用浏览器工具导航到应用
4. **尝试完成 persona 的实际任务**（不是功能巡览）：
   - 他们能做到想做的事吗？
   - 完成任务需要多少次点击/页面跳转？
   - 什么让他们困惑？
   - 什么让他们愤怒？
   - 他们在哪里迷路？
   - 什么会让他们放弃，回到原来的方式？

5. 测试以下摩擦类别：
   - **第一印象** — 他们会不会在落地页就放弃？
   - **核心工作流** — 他们最常需要做的那一件事
   - **错误恢复** — 他们做错了什么会发生什么？
   - **可读性** — 文字大小、对比度、信息密度
   - **速度** — 感觉比他们现在的方法更快吗？
   - **术语** — 有他们看不懂的行话吗？
   - **导航** — 他们能找到回去的路吗？他们知道自己在哪里吗？

6. 对每个痛点截图
7. 在每个页面检查浏览器控制台的 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 噪音** — 是"我讨厌电脑"在说话，不是产品问题。跳过。
- **绿色：功能需求** — 投诉中隐藏的好想法。考虑一下。

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

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

## 第五步：创建工单

仅针对**红色**和**绿色**条目：
- 清晰、可执行的标题
- 包含 persona 的原话（有趣且令人印象深刻）
- 其背后的真实 UX 问题（客观）
- 建议的修复方案（可执行）
- 标签/标记："ux-review"

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

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

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

## 第六步：报告

交付内容：
1. Persona 发泄内容（第三步）——有趣且直击痛点
2. 过滤后的评估（第四步）——务实且可执行
3. 已创建的工单（第五步）——附链接
4. 关键问题的截图

## 技巧

- **每次会话只用一个 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，一次会话，一份报告