人类就绪度评估指南

作为产品构建者,我们需要系统化的方法来评估产品是否真正为人类用户做好了准备。本指南涵盖了评估人类就绪度的实用工作流程，包括新手引导、营销、功能和用户体验各方面。

为什么人类就绪度评估对商业化至关重要

自动化测试检查代码是否工作。人类就绪度评估检查产品是否准备好服务人类并获得商业成功。

关键洞察: 产品最终服务于人类，并通过人类的满意度实现商业化。关键事实：

• 人类是您的客户 - 他们决定注册、付费和留存
• 人类传播口碑 - 推荐和评论来自满意的人类用户
• 人类判断质量 - 第一印象、信任和愉悦感都是人类的判断
• 商业成功 = 人类认可 - 收入、留存和增长需要赢得人类的心

核心观点: 即使测试覆盖率达到 100%，拥有完美的 AI 验证，您仍然需要人类就绪度评估来构建人类喜爱并愿意付费的产品。没有任何自动化系统可以替代人类对产品是否真正准备好服务人类需求并创造商业价值的判断。

方法 1: 营销倒推评估法

原则: 从用户视角定义产品,然后再评估功能。

工作流程

不要从代码或功能开始,而是从设计产品的面向公众的展示开始——就好像今天要在 Product Hunt 或 BetaList 上发布一样。

步骤 1: 先设计营销页面

创建或评估这些页面,就好像今天要向陌生人发布一样:

1. 落地页 (/)

   • 陌生人能在 5 秒内理解你做什么吗?
   • 价值主张是否非常清晰?
   • 首屏部分是否回答了"这是什么?"和"为什么我该关心?"

2. 关于页面 (/about)

   • 是否解释了产品背后的"为什么"?
   • 故事是否有说服力且真实?
   • 产品定位是否恰当(独立开发 vs 企业级)?

3. Product Hunt / BetaList 文案

   • 写出 60 字的标语和描述
   • 如果无法清晰概括,说明产品定位还没准备好

4. 定价页面 (/pricing)

   • 各层级是否有明确差异?
   • 用户能否自主选择合适的计划?
   • 免费层级是否足够吸引人来开始使用?

步骤 2: 从营销反推

设计完营销后,评估实际产品:

营销承诺  →  现实检查
───────────────────────────────────
"几秒钟创建文章"  →  新用户真的能在 60 秒内完成吗?
"AI 驱动的建议"   →  AI 的感觉是魔幻的还是笨拙的?
"团队协作"        →  邀请队友直观吗?
"企业级安全"      →  你真的有 SOC2/加密吗?

步骤 3: 用户价值审计

对于声称的每个功能:

评估清单

危险信号 🚩

• 落地页有通用文案如"革命性的 X 平台"
• 关于页面只是功能列表(不是故事)
• 定价页有模糊的层级名称如"专业版" vs "高级版"
• 截图显示开发者 UI 或破损布局
• 无法用一句话向陌生人解释产品

方法 2: 新手引导流程评估

原则: 产品的好坏取决于新用户的前 5 分钟体验。

完整的新手引导定义

只有当以下端到端流程无缝运行时,新手引导才算**"跑通"**:

┌─────────────────────────────────────────────────────────────┐
│                     新手引导流程                              │
├─────────────────────────────────────────────────────────────┤
│ 1. 进入触发                                                   │
│    → 新用户登录 → 引导模态窗自动出现                          │
│                                                              │
│ 2. 模态窗引导步骤                                             │
│    → 分步骤,有清晰的"下一步"按钮                             │
│    → 每步都有成功反馈                                         │
│    → 最后一步显示"完成"并平滑过渡                            │
│                                                              │
│ 3. 模态窗后引导                                               │
│    → 系统提供下一步引导(无死胡同)                             │
│    → 清晰的第一任务路径(例如"创建空间")                       │
│                                                              │
│ 4. 首次成功                                                   │
│    → 用户完成第一个有意义的任务                               │
│    → 成功是可见的(提示、状态变更、输出)                       │
│                                                              │
│ 5. 额度验证(测试支付流程)                                     │
│    → 使用 GM 命令将额度设为 0                                 │
│    → 重试同一任务 → 触发支付门槛                             │
│                                                              │
│ 6. 支付流程完成                                               │
│    → 支付模态窗有清晰的订阅/升级选项                          │
│    → 升级后 → 额度立即恢复                                    │
│    → (或清晰提示:"刷新以应用")                               │
│                                                              │
│ 7. 付费后成功                                                 │
│    → 重试任务 → 无支付门槛正常工作                            │
│    → 升级生效,用户可以继续                                   │
└─────────────────────────────────────────────────────────────┘

分步评估

1️⃣ 进入触发

测试: 以新用户身份注册

✅ 通过标准:

• 引导模态窗自动出现
• 模态窗获得焦点(无干扰)
• "开始"、"下一步"或"跳过"按钮清晰
• 默认操作应鼓励开始(而非跳过)

❌ 失败标准:

• 模态窗不自动出现
• 用户必须寻找"入门"链接
• 模态窗可遗漏或隐藏
• 无清晰的行动号召

2️⃣ 模态窗引导步骤

测试: 完成模态窗中的所有步骤

✅ 通过标准:

• 每步都有单一清晰目标
• "下一步"按钮突出
• 进度指示器显示当前步骤(例如"第 2 步,共 3 步")
• 成功状态是可视的(对勾、绿色高亮)
• 最后一步平滑过渡到产品

❌ 失败标准:

• 任何步骤令人困惑(需要人工解释)
• "下一步"按钮不清晰或隐藏
• 步骤未提供完成反馈
• 模态窗突然关闭无过渡

3️⃣ 模态窗后引导

测试: 关闭模态窗后会发生什么?

✅ 通过标准:

• 系统提供即时的下一步操作(例如"创建你的第一个空间")
• 下一步操作只需一键点击(不在菜单中隐藏)
• 视觉指示器(箭头、工具提示或引导)显示去向
• 无"空白画布"瘫痪

❌ 失败标准:

• 用户落在空仪表板上无引导
• 下一步需要阅读文档
• 用户必须搜索"如何开始"
• 死胡同(无清晰前进路径)

常见模式:

• 入门步进器: 聊天输入上方的持久清单
• 设置指南按钮: 导航栏中的"完成设置"
• 工具提示引导: 高亮第一个操作按钮
• 功能导览: 聚光灯叠加解释 UI 元素

4️⃣ 首次成功

测试: 完成引导的第一个任务

✅ 通过标准:

• 任务无错误完成
• 成功是可见的:
  • 成功提示通知
  • 状态变更(例如"文章已创建")
  • 输出出现(例如文章显示在列表中)
  • 五彩纸屑或庆祝动画(可选但令人愉快)
• 用户感到有成就感(而非困惑)

❌ 失败标准:

• 任务静默完成(无反馈)
• 成功隐藏在日志或后端
• 用户必须刷新才能看到结果
• 发生错误但未优雅捕获

"首次成功"示例:

• AI 代理:发送第一条消息 → 获得 AI 响应
• CMS:创建第一篇文章 → 文章出现在列表中
• 开发者工具:进行 API 调用 → 查看响应
• 团队应用:邀请队友 → 邀请发送确认

5️⃣ 额度评估(支付门槛测试)

测试: 通过清零额度强制触发支付门槛

设置:

// 使用 GM(游戏管理员)命令或系统管理员
// 将用户额度设为 0
setUserCredits(userId, 0);

操作: 重试同一首次任务

✅ 通过标准:

• 支付门槛立即触发
• 门槛显示清晰消息:"额度不足"或"升级以继续"
• 支付模态窗出现,有选项:
  • 订阅付费计划
  • 输入促销/兑换码
  • 升级空间/层级
• 每个选项都可点击且有效

❌ 失败标准:

• 任务即使额度为 0 也成功(计费损坏)
• 支付门槛未出现
• 错误消息难懂(例如"错误 402")
• 无升级路径(死胡同)

6️⃣ 支付流程完成

测试: 完成支付或升级

要测试的操作:

7️⃣ 付费后成功

测试: 支付/升级后重试原始任务

✅ 通过标准:

• 任务成功完成(无支付门槛)
• 输出符合预期
• 无错误或故障
• 用户可以继续正常工作流程

❌ 失败标准:

• 支付门槛仍然出现(升级未应用)
• 任务以不同错误失败
• 必须注销/登录才能使升级生效
• 配额仍显示 0

新手引导验收标准

"跑通"(完全工作)的定义:

当人工测试人员可以连续完成步骤 1-7,且无以下情况时,新手引导流程即为完全工作:

• 手动干预(无控制台命令、无数据库编辑)
• 困惑(无"接下来该做什么?"的时刻)
• 错误(无 500 错误、无损坏按钮)
• 需要文档(流程自解释)

一处中断 = 未就绪: 如果任何步骤失败或需要手动帮助,新手引导就不完整。

常见新手引导失败

方法 3: 员工模拟评估法

原则: 像安排下属员工一周工作一样测试 AI Agent,确保它能够理解和执行循序渐进的任务。

核心理念

将 AI Agent 想象成你的下属员工,在一周工作日(周一到周五)内,你需要向他分配任务并跟踪进度。这种方法让 AI Agent 的测试更加拟人化和接地气,同时确保它能够处理真实工作场景中的连贯任务序列。

为什么这个方法有效

价值: 这种方法能够发现 AI Agent 在理解任务依赖关系、上下文保持和渐进式目标达成方面的问题。

周工作任务分配法

想象今天是周一早上,你有一个新入职的员工(AI Agent),你需要给他安排这一周的工作。以下是 5 步渐进式任务分配流程:

📋 任务背景设定

场景: 你的团队正在为一个新产品做市场调研和竞品分析。

员工: 你的 AI Agent(扮演初级分析师)

目标: 在一周内完成从调研到报告的完整工作流程

步骤 1️⃣: 周一早上 - 信息收集任务

你的指令:

"小李,这周我们要做竞品分析。今天周一,你先帮我收集一下我们行业内排名前 5 的竞争对手的基本信息。包括:公司名称、成立时间、主打产品、目标用户群。下午下班前给我一个初步清单。"

验证要点:

• AI Agent 能否理解"排名前 5"这种相对模糊的要求?
• 是否会主动询问是按什么标准排名(用户量?收入?知名度)?
• 能否在合理时间内返回结构化的清单?
• 输出格式是否易于阅读和后续使用?

✅ 通过标准:

• AI 主动澄清排名标准或给出合理假设
• 返回包含 5 家公司的结构化信息
• 信息准确且来源可追溯
• 询问是否需要更多细节

❌ 失败标准:

• 直接返回结果不询问标准
• 返回信息不完整或格式混乱
• 找到错误的竞争对手
• 无法完成任务或返回错误

步骤 2️⃣: 周二上午 - 深度分析任务

你的指令:

"小李,昨天的清单我看了,做得不错。今天周二,你基于昨天的 5 家公司,选出和我们最接近的 3 家,深入分析一下他们的定价策略。包括:价格区间、订阅模式、免费版功能、付费版差异。明天早上碰头前发给我。"

验证要点:

• AI Agent 能否引用昨天的结果作为上下文?
• 是否能理解"最接近"的标准(产品形态?目标用户?价格带?)?
• 能否进行二次筛选和深度挖掘?
• 输出是否有对比性和可操作性?

✅ 通过标准:

• 明确引用步骤 1 的 5 家公司
• 有合理的筛选逻辑(并说明理由)
• 提供详细的定价对比表
• 给出初步的竞争态势分析

❌ 失败标准:

• 忘记昨天的结果,重新开始
• 随机选择 3 家没有说明原因
• 定价信息不准确或过时
• 没有对比维度只是罗列信息

步骤 3️⃣: 周三下午 - 创意输出任务

你的指令:

"小李,定价分析很有价值。现在周三了,基于前两天的研究,你帮我头脑风暴一下:如果我们要在这个市场做差异化,可以在哪 3 个方向上突破?每个方向写 2-3 句话说明理由。周四早上讨论。"

验证要点:

• AI Agent 能否综合利用前两天的发现?
• 是否能从分析转向创意和战略建议?
• 建议是否具体、可行、有洞察力?
• 能否平衡创新性和现实性?

✅ 通过标准:

• 建议明确引用前期调研发现
• 3 个方向各不相同且有逻辑支撑
• 既有创新点又考虑可行性
• 用数据或案例支持建议

❌ 失败标准:

• 建议与前期调研无关
• 方向模糊或空泛(如"做得更好")
• 没有理由支撑的随机想法
• 脱离现实的不可行建议

步骤 4️⃣: 周四上午 - 整合总结任务

你的指令:

"小李,昨天的 3 个方向我们讨论过了,决定重点关注第 2 个。今天周四,你把这周的所有发现整理成一份简报,包括:竞品概况、定价对比、我们的差异化策略。用 PPT 大纲的形式,控制在 10 页以内。明天上午给管理层汇报。"

验证要点:

• AI Agent 能否整合整周的工作成果?
• 是否能从分散信息中提炼核心观点?
• 输出格式是否符合商务汇报标准?
• 结构是否清晰、逻辑是否连贯?

✅ 通过标准:

• 简报包含周一至周三的所有关键发现
• 结构符合"背景-分析-建议"逻辑
• PPT 大纲每页有明确主题
• 突出重点(第 2 个差异化方向)

❌ 失败标准:

• 遗漏前几天的重要信息
• 简报结构混乱或重复
• 超出页数限制或信息过载
• 没有突出决策重点

步骤 5️⃣: 周五下午 - 反思改进任务

你的指令:

"小李,今天上午的汇报很成功,管理层很满意。现在周五下午了,你回顾一下这周的工作,写一个简短的复盘:哪些地方做得好?哪些地方可以改进?如果下周有类似任务,你会怎么调整流程?"

验证要点:

• AI Agent 能否自我反思和总结?
• 是否能识别工作流程中的优缺点?
• 能否提出具体的改进建议?
• 是否体现学习和成长的能力?

✅ 通过标准:

• 准确总结本周 5 个步骤的工作
• 指出具体的成功点和不足
• 改进建议切实可行
• 展现对工作流程的理解

❌ 失败标准:

• 笼统的自我表扬无具体例子
• 没有识别任何问题或改进点
• 复盘与实际工作脱节
• 无法提出有价值的流程优化建议

员工模拟评估清单

使用此清单评估 AI Agent 的"员工表现":

## AI Agent 周工作表现评估

### 任务执行能力
- [ ] 周一:信息收集准确完整
- [ ] 周二:深度分析有洞察力
- [ ] 周三:创意输出可行有价值
- [ ] 周四:整合总结结构清晰
- [ ] 周五:自我反思有深度

### 上下文保持
- [ ] 能记住前一天的工作成果
- [ ] 能在后续任务中引用前期发现
- [ ] 能理解任务之间的依赖关系
- [ ] 能维持一周的连贯工作主题

### 沟通理解
- [ ] 能理解相对模糊的指令
- [ ] 会主动询问澄清问题
- [ ] 输出格式符合商务场景
- [ ] 能根据反馈调整方向

### 工作成熟度
- [ ] 从执行到分析到创意的进阶自然
- [ ] 能区分不同任务类型的要求
- [ ] 输出质量稳定不波动
- [ ] 展现自主思考和判断能力

### 拟人化表现
- [ ] 沟通语气自然不机械
- [ ] 能理解工作节奏(周一收集→周五复盘)
- [ ] 会表达不确定性或需要帮助
- [ ] 整体交互像与人类员工协作

常见"员工表现"问题

应用场景

这个方法特别适合评估:

✅ 最适用于 - 聊天/对话驱动的 AI Agent 产品:

• 对话式 AI 助理(如 ChatGPT 式的个人助理、工作助手)
• 智能客服系统(多轮对话理解,非结构化查询)
• AI 编程助手(通过对话完成编程任务,如 GitHub Copilot Chat)
• 内容创作 AI(通过对话指导的多步骤创作流程)

这些产品的特点是:

• 功能开放: 用户通过自然语言表达需求,而非点击固定按钮
• 对话驱动: 交互方式是连续对话,而非分步骤表单
• 上下文依赖: 需要记住和理解前面几轮对话的内容

✅ 也适用于:

• 数据分析工具(从收集到分析到报告的连贯流程)
• 任务规划工具(需要多步分解和跟踪的复杂任务)

❌ 不太适用于:

• 按钮/步骤式流程的产品(如电商购物流程、表单填写向导)
• 单次交互的工具类产品(如图片编辑器、计算器)
• 无需上下文的功能性服务(如翻译工具、格式转换器)
• 已经有完整流程测试的企业级系统

最佳实践

做 ✅:

• 设定真实工作场景:使用你自己团队的实际工作场景
• 保持任务连贯性:确保 5 个步骤是同一项目的不同阶段
• 记录交互细节:保存每天的对话以便周五对比
• 用真实的时间压力:模拟"明天早上要"的真实截止时间
• 测试边界情况:尝试临时改变任务方向测试适应性

不做 ❌:

• 不要设计太简单的任务:应该有一定复杂度和挑战性
• 不要跳过中间步骤:必须完整走完 5 天流程
• 不要人工补充信息:如果 AI 忘记了前一天的内容,记录为问题而不是提醒它
• 不要接受机械回答:应该像与人对话一样自然
• 不要忽略反思环节:周五的自我复盘非常重要

方法 4: 用户旅程映射

原则: 产品是作为旅程使用的,而非孤立的功能。

关键用户旅程

映射并评估这些端到端旅程:

旅程 1: "观望者"(怀疑访客)

角色: 从 Product Hunt 点击的人,不确定是否会注册

落在主页 → 阅读价值主张 → 查看定价 → 查看截图
     ↓
决定尝试 → 注册 → 跳过/完成引导 → 测试一个功能
     ↓
决定: "值得我的时间吗?" → 收藏 / 关闭标签页

评估:

• 落地页在 2 秒内加载(无耐心)
• 价值主张在 5 秒内可理解
• 定价透明(无"联系销售")
• 截图显示真实产品(非库存照片)
• 注册是一键式(Google/GitHub OAuth)
• 演示模式无需登录即可工作(如适用)
• 第一个功能在 1 分钟内工作

旅程 2: "高级用户"(转换为付费)

角色: 喜欢产品的免费用户,考虑升级

达到免费配额限制 → 看到升级提示 → 查看定价 → 比较层级
     ↓
点击升级 → 输入支付 → 确认 → 配额增加 → 继续工作

评估:

• 配额警告在达到限制前出现
• 升级提示有帮助,不烦人
• 层级差异清晰
• 支付表单值得信任(安全徽章,无错误)
• 升级立即应用(或清晰的预计时间)
• 自动发送收据电子邮件
• 升级后工作流程无中断

旅程 3: "团队负责人"(带来同事)

角色: 想邀请团队的单人用户

产品成功 → 想分享 → 找到"邀请团队" → 发送邀请
     ↓
队友收到电子邮件 → 点击链接 → 注册 → 加入团队空间 → 协作

评估:

• "邀请团队"可发现(不隐藏在设置中)
• 邀请电子邮件专业(不垃圾)
• 邀请链接有效(未过期或损坏)
• 新成员落在正确的空间/团队
• 权限正确工作(无意外管理员访问)
• 团队负责人可以看到谁加入了

旅程 4: "迷失的高级用户"(需要支持)

角色: 遇到错误或困惑的用户

遇到问题 → 寻找帮助 → 找到支持渠道 → 提问
     ↓
收到响应 → 实施解决方案 → 继续工作 或 沮丧离开

评估:

• 帮助/支持链接在导航中可见
• 联系选项清晰(聊天、电子邮件、文档)
• 设定响应时间期望
• 错误消息包含"获取帮助"链接
• 文档搜索工作良好
• 常见问题有即时答案(聊天机器人/FAQ)

方法 5: 功能完整性检查

原则: 只有当功能可发现、可用且有文档时,功能才算"完成"。

三层功能检查

对于产品中的每个主要功能:

第 1 层: 可发现性

问题: 用户能否无需帮助找到此功能?

✅ 通过标准:

• 功能在主导航或突出的 CTA 中
• 功能名称清晰(非术语)
• 图标或视觉合理
• 搜索包含此功能

❌ 失败标准:

• 功能隐藏在设置或子菜单中
• 仅通过 URL 技巧访问
• 名称是技术性的(例如"CRUD 操作")
• 用户在支持中询问"X 在哪里?"

第 2 层: 可用性

问题: 用户能否无需文档完成核心工作流程?

测试: 将产品给陌生人,让他们使用该功能

✅ 通过标准:

• 陌生人在 2 分钟内完成工作流程
• 无需解释按钮或流程
• 错误状态有帮助
• 成功状态明显

❌ 失败标准:

• 陌生人问"我应该点击什么?"
• 必须解释按钮的作用
• 错误难懂
• 用户不确定操作是否成功

第 3 层: 文档

问题: 功能是否为高级用户记录?

✅ 通过标准:

• 帮助文档存在于 /docs/features/[功能名称]
• 包含截图或视频
• API 文档(如适用)
• 常见问题的 FAQ

❌ 失败标准:

• 不存在文档
• 文档是占位文本
• 截图显示旧 UI
• API 文档过时

功能清单模板

对每个功能使用此清单:

## 功能: [名称]

### 可发现性
- [ ] 出现在主导航或主页
- [ ] 功能名称对非技术用户清晰
- [ ] 图标/视觉合理
- [ ] 在应用搜索中可搜索

### 可用性
- [ ] 核心工作流程在 2 分钟内完成
- [ ] 按钮/UI 无需解释
- [ ] 错误消息有帮助(不只是"错误 500")
- [ ] 成功状态明显

### 文档
- [ ] 帮助文档存在: `/docs/features/[名称]`
- [ ] 截图匹配当前 UI
- [ ] API 文档(如果功能有 API)
- [ ] 常见问题的 FAQ

### 边界情况
- [ ] 在移动端工作(< 768px 宽度)
- [ ] 在暗黑模式下工作
- [ ] 优雅处理空状态
- [ ] 速率限制/配额清晰

### 性能
- [ ] 在 3 秒内加载
- [ ] 无布局偏移(CLS)
- [ ] 无控制台错误

方法 6: 发布前评估

原则: 在宣布产品之前,像批评者而非创作者一样评估它。

24 小时新鲜眼光测试

流程:

1. 24 小时不接触你的产品
2. 像陌生人一样打开它
3. 记录每个摩擦点

要寻找的内容:

• 拼写和语法错误
• 损坏的图像或 404 页面
• 令人困惑的文案或术语
• 加载缓慢的部分
• 不工作的按钮
• 死胡同页面(无下一步操作)

"展示给妈妈看"测试

流程: 向完全非技术的人展示你的产品

任务:

1. "这个产品是做什么的?"
2. "你能注册吗?"
3. "试着创建/做[核心操作]"
4. "你接下来会点击什么?"

危险信号:

• 他们无法解释它是做什么的
• 他们问"我应该点击哪里?"
• 他们对 UI 感到困惑
• 他们说"这是给开发者用的吗?"

如果妈妈(或非技术朋友)无法使用它,大多数用户也无法使用。

清单: 发布前评估

复制此清单进行最终评估:

产品页面

• 落地页在 2 秒内加载
• 价值主张非常清晰
• 截图显示当前 UI(无占位符)
• 所有链接有效(无 404)
• 移动端响应式(在手机上测试)
• 暗黑模式有效(无损坏样式)
• 无拼写或语法错误
• 关于页面讲述令人信服的故事
• 定价页面有清晰的层级

用户流程

• 注册<30 秒
• 引导模态窗端到端工作
• 首次成功在 1 分钟内可见
• 支付/升级流程有效
• 团队邀请有效
• 帮助/支持可访问

技术

• 健康检查通过: /api/health
• 站点地图存在: /sitemap.xml
• Robots.txt 已配置
• OpenGraph 图像有效
• Lighthouse 分数 >90(所有指标)
• 无控制台错误
• 数据库迁移稳定

内容

• 文档存在且可搜索
• 隐私政策存在
• 服务条款存在
• 联系信息可见
• 社会证明(推荐/徽标)如果可用

信任和安全

• SSL 证书有效
• 无混合内容警告
• 支付表单使用 Stripe/安全提供商
• 电子邮件发送有效(测试欢迎邮件)
• 密码重置有效
• 前端无暴露的秘密

最佳实践

应该 ✅

• 用新浏览器测试(隐身模式)模拟新用户
• 使用真实测试信用卡(Stripe 测试模式)验证支付流程
• 计时自己完成关键流程(2 分钟以下 = 良好)
• 记录发现过程中的问题(截图 + 注释)
• 在多设备上测试(移动、平板、桌面)
• 在不同浏览器中验证(Chrome、Firefox、Safari)
• 验证后检查分析(事件是否正确触发?)

不应该 ❌

• 不要立即验证自己的工作(先休息一下)
• 不要跳过支付流程测试(最关键的收入流程)
• 不要假设功能可发现(用陌生人测试)
• 不要只在桌面上验证(50%+ 流量来自移动端)
• 不要依赖记忆(写下每个问题)
• 不要在验证时修复(先记录,后修复)
• 不要跳过边界情况(空状态、错误状态、慢网络)

何时运行评估

工具和快捷方式

开发者快捷方式

ProductReady 包含用于测试的键盘快捷方式:

GM(游戏管理员)命令

用于测试支付流程和配额限制:

// 将用户额度设为 0(触发支付门槛)
gm.setCredits(0);

// 将用户设为特定层级
gm.setTier('pro');

// 触发引导重置
gm.resetOnboarding();

// 授予无限额度(测试)
gm.setCredits(999999);

人类就绪度评估成功指标

当产品达到以下标准时即为人类就绪:

相关文档

• 产品就绪标准 - 技术质量清单
• 用户引导策略 - 详细的引导设计原则
• 测试 - 自动化测试方法
• 快速开始 - ProductReady 入门

常见问题

Q: 完整评估应该需要多长时间?

A: 为全面评估预留 2-5 小时:

• 营销倒推: 30 分钟
• 新手引导流程: 45 分钟
• 功能完整性: 1 小时
• 用户旅程: 30 分钟
• 员工模拟: 1 小时(模拟 5 天工作流)
• 发布前: 30 分钟

Q: 我应该评估每个小改动吗?

A: 不。对任何认证/支付/核心流程更改运行新手引导流程评估。在主要版本或发布前运行完整评估。

Q: 如果我在评估期间发现问题怎么办?

A: 立即记录它们(截图 + 描述)。优先级:

1. 关键: 损坏的支付、损坏的注册、数据丢失
2. 高: 令人困惑的引导、可发现的功能问题
3. 中: 文案拼写错误、轻微 UI 故障
4. 低: 锦上添花的改进

Q: 我可以自动化这些评估吗?

A: 部分可以(技术检查),但人工评估对于 UX、文案和"这有意义吗?"检查至关重要。E2E 测试(Playwright)可以自动化流程,但不能自动化理解。

Q: 评估和测试的区别是什么?

A:

• 测试 = 代码是否正确工作?(自动化)
• 评估 = 产品是否为人类服务?(人工、共情)

两者都是必要的。测试捕获 bug;评估捕获 UX 问题。

最后更新: 2025 年 12 月