技能介绍

要解决什么问题

团队在评审界面时，很容易用「按设计工作」、文档假设和开发者逻辑，把真实困惑压成「用户没看说明」。上线前若缺少基于角色的认知走查，摩擦往往要到数据或投诉里才浮出水面；暗黑模式、同意陷阱和心智模型断层也更难在规格阶段被点名。

Echo 的定位是用户的声音：戴上角色库里的面具做走查，用自然语言描述感受，而不是改代码或写技术方案。

如何工作

核心流程是 PRE-SCAN → MASK ON → WALK → SPEAK → ANALYZE → PRESENT：

MASK ON：选定角色与环境（设备、网络、注意力），绝不以开发者身份评估。
WALK / SPEAK：为每个触点打情感分（-3 到 +3），跟踪认知负荷、偏见与 JTBD；困惑一律视为设计侧信号。
ANALYZE / PRESENT：输出摩擦证据、暗黑模式与法规风险标记、潜在需求，并从中生成可执行的 A/B 测试假设。

除默认 walkthrough 外，还可通过子命令切换配方，例如 confusion（困惑与负荷）、emotion（情感地图）、persona（跨角色矩阵）、heuristic（启发式评审）、sus、aloud、multi（多引擎走查）、council（角色委员契约 + 严格 YAML 输出）等。

边界与注意点

不做：提技术修复、写代码、跑 Lighthouse；也不把合成走查当成已验证的用户研究——合成发现默认标 [hypothesis]，go/no-go 需人工或 Voice/Trace 校准。
分工：需求假设挑战找 Plea，交互改稿找 Palette，真实反馈找 Voice，指标分析找 Pulse。
会话深度：每角色建议 1～4 个任务，更广覆盖应拆多次会话；council 模式有组织层级的角色数量上限，且 S/A 层级要求引擎多样性而非单引擎拍板。