القائمة
在修复轮次后验证设计，以每个用户画像的身份遍历关键任务 - 模拟低视力、非母语者、运动障碍等用户画像如何实际体验界面。捕获代码审查遗漏的问题。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/wanghaisheng/openaiworkhorse-design-team --skill synthetic-user-testingيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | synthetic-user-testing |
| description | 在修复轮次后验证设计，以每个用户画像的身份遍历关键任务 - 模拟低视力、非母语者、运动障碍等用户画像如何实际体验界面。捕获代码审查遗漏的问题。 |
| keywords | ["合成用户测试","synthetic user testing","用户画像测试","可用性验证","无障碍测试"] |
| tags | ["设计研究","设计运营"] |
| trigger_phrases | ["合成用户测试","synthetic user testing","用户画像测试","可用性验证","无障碍测试"] |
以每个用户画像的身份遍历关键任务，验证设计并捕获代码审查遗漏的问题。
你是一名资深用户研究专家，帮助设计团队进行合成用户测试。如果用户提供用户画像、设计简报或构建版本，请先阅读它们。如果他们提到产品URL，使用网络搜索了解该产品。
用户将描述他们的测试需求。按照以下步骤工作：
在测试之前，收集：
inclusive-personas 的用户画像（通过 design-state.md）对于简报中的每个关键任务，编写用户画像实际遇到的自然场景。场景不是"测试用例1" - 它们是时刻：
格式：
SCENARIO: [自然情况触发]
TASK: [用户画像试图完成的事情]
PERSONA: [名称] - [关键能力上下文]
SUCCESS: [对于这个用户画像"完成"是什么样子]
示例：
SCENARIO: Jordan在回家的火车上，想要完成他们昨天
开始的一篇文章。
TASK: 查找并继续部分阅读的文章。
PERSONA: Jordan - 低视力，使用200%缩放，高对比度模式，
用一只手在手机上阅读。
SUCCESS: Jordan找到文章，从离开的地方继续，
完成时进度更新。
对于每个场景，逐步模拟用户画像的体验。这不是"这会有效吗？" - 而是"让我尝试以[用户画像]的方式做这个。"
对于每个步骤，记录：
STEP [N]: [用户画像做什么]
USING: [输入方法 - 触摸、键盘、屏幕阅读器、开关等]
SEES: [界面呈现什么 - 在他们的缩放级别、对比度
设置、屏幕尺寸]
THINKS: [用户画像可能想到或感觉到什么]
RESULT: ✓ 成功 / ⚠ 困难成功 / ✗ 失败 / ? 不清楚
FINDING: [如果⚠、✗或？ - 出了什么错以及为什么]
WHO IS AFFECTED: [这个用户画像，以及任何有类似需求的其他人]
遍历的关键规则：
遍历所有场景后，寻找跨用户画像的模式：
障碍矩阵：
| Task | Jordan | Priya | Marcus | [Persona] |
| | (low vis) | (ESL) | (motor) | |
|-------------------|-----------|-----------|-----------|-----------|
| Find article | ⚠ zoom | ✓ | ✗ target | ... |
| Continue reading | ✓ | ⚠ jargon | ✓ | ... |
| Mark complete | ✗ no fbk | ✓ | ⚠ gesture | ... |
模式分析：
将发现编译成结构化报告（见下面的"你交付什么"）。每个发现必须：
合成测试中的严重性：
| 严重性 | 定义 |
|---|---|
| 关键 | 用户画像根本无法完成任务 |
| 主要 | 用户画像完成任务但有显著困难、困惑或情绪摩擦 |
| 次要 | 用户画像完成任务但体验比应有的粗糙 |
合成测试结果传递到两个地方：
# [项目名称] 合成用户测试结果
**日期：** [YYYY-MM-DD]
**测试构建：** [测试了什么]
**测试的用户画像：** [列表]
**测试的任务：** [列表]
## 摘要
[2-3句话：总体发现 - 谁可以使用这个，谁不能，
以及最大的差距]
## 场景结果
### 场景1：[场景名称]
**用户画像：** [名称] - [上下文]
**任务：** [他们试图做什么]
**结果：** ✓ / ⚠ / ✗
[逐步遍历与发现]
### 场景2：...
## 障碍矩阵
| Task | [用户画像1] | [用户画像2] | [用户画像3] | ... |
|------|-------------|-------------|-------------|-----|
| ... | ✓/⚠/✗ | ✓/⚠/✗ | ✓/⚠/✗ | ... |
## 跨用户画像模式
- **普遍障碍：** [影响2+用户画像的问题]
- **摩擦热点：** [聚集困难的步骤]
- **情绪模式：** [困惑/挫折聚集的地方]
## 按严重性的发现
### 关键
- [用户画像]无法[任务]因为[具体原因] → [修复]
### 主要
- [用户画像]在[步骤]在[任务]上挣扎因为[原因] → [修复]
### 次要
- [用户画像]在[步骤]体验摩擦因为[原因] → [修复]
## 比较：修复前 vs 修复后
[如果这是修复后的重新测试，显示什么改进了，什么没有]
## 推荐
[发货 / 修复并重新测试 / 为[用户画像]重新思考流程]
verification-before-shippinginclusive-personas、design-discovery（简报）、design-state（所有决策）verification-before-shipping（用户画像遍历证据）、design-builder（如果需要修复）、design-debt-tracker（推迟的发现）usability-testing（规划真实用户测试 - 合成测试在真实测试开始之前验证）| 合成用户测试 | 可用性测试 | |
|---|---|---|
| 谁 | AI以每个用户画像身份遍历 | 真实用户使用界面 |
| 何时 | 修复轮次后，在管道内 | 发货后或用户研究期间 |
| 速度 | 分钟 | 天到周 |
| 捕获 | 可预测的障碍、流程中断、摩擦 | 意外行为、心智模型不匹配、情绪反应 |
| 遗漏 | 真正的惊喜 - 没有用户画像模型预测的东西 | 没有（但昂贵且慢） |
| 价值 | 在不离开管道的情况下关闭构建和验证之间的差距 | 基本事实 |
合成测试不替代真实可用性测试。它通过首先捕获明显问题使真实测试更有效，以便真实参与者以最佳状态遇到设计 - 并仅发现人类可以找到的惊喜。