用途：访谈用户，界定应用的真实使用者，然后撰写 USERS.md，定义每一种不同的用户类型。目标不是记录人口统计特征，而是越过“所有人”，找出少量行为上真正不同的用户类型，每类都有必须达成的目标，并明确指出产品不是为谁而做。
主要原则：
- 访谈而非记录。一次只问一个关键问题，并附带推荐答案与简要理由。
- 拒绝“所有人”。“所有用户”或宽泛人口统计无法描述任何人，也无法为评审提供可测试依据；必须强行确定一个必须成功的主用户，并用行为而非人口统计区分类型。
- 区分或合并。如果两个用户类型会以相同方式使用应用、目标相同，就合并；不同类别必须在目标、情境、熟练度或关注点上不同。
- 命名非目标用户。产品不适合谁，与适合谁同样有澄清作用。
- 产出可用文档。USERS.md 要足够具体，使他人在无需追问的情况下能选取场景并据此权衡优先级。
使用方式：先做侦察，扫描营销文案、角色与权限层、定价层、引导流程、证言、支持工单、已有 USERS.md 等已有信号，并总结发现。然后按问题树逐一提问，覆盖应用做什么、主用户、不同次用户、每类的情境/熟练度/目标/动机/挫败/成功、“这是为我而做”的共振点、非目标用户和相对优先级。撰写前先复述用户类型（标签、必须达成的目标、差异点、优先级），确认或修正，合并不真正不同的类型。最后按 references/users-md-format.md 写 USERS.md：结构化 YAML front matter（每种用户类型加非目标用户各一条）以及每类的散文说明；默认位置为仓库根目录 USERS.md，需确认路径。交付时报告文件路径、主用户、不同用户类型及其优先级。
好 USERS.md 的标准：恰好一个主用户；行为上真正不同的类型；每类有含可观察成功状态的具体目标，可直接用作测试场景；每类有优先级视角；每类有共振线索；命名非目标用户。若产品确实只有一种用户类型，说明并使其鲜明，不要为凑数虚构。
限制：资料未提供收费、价格、平台、效果或性能等信息。