用户场景文档生成 Skill
目的
本 Skill 专用于根据产品的模型设计和产品需求文档（PRD），自动研究、分析目标产品的典型用户场景，并生成一份结构完整、内容详实的用户场景文档。整个过程纯文档产出，不涉及任何代码编写。
触发条件
当用户的请求属于以下任一情形时，加载本 Skill：
- 明确要求「生成/撰写/输出」用户场景文档
- 要求基于产品需求或模型设计来分析用户故事
- 要求输出包含产品概述、MVP 功能、用户故事、非功能需求的场景报告
- 表述为「帮我研究 XX 产品的用户场景」、「根据这些需求写场景文档」
文档结构规范
生成的用户场景文档 必须 严格遵循以下四大部分结构，不得省略：
1. 产品概述 (Product Overview)
内容包括：
- 产品定位：用一句话概括产品是什么、为谁解决什么问题
- 目标用户群体：列出主要用户角色（Persona），每个角色需包含：
- 角色名称
- 典型特征（年龄、职业、技术背景等）
- 核心痛点与期望
- 产品愿景与价值主张：产品希望达成的长期目标与核心价值
- 使用环境与约束：产品在何种环境下使用，存在哪些已知限制
2. 核心功能 — MVP (Core Features / MVP)
内容包括：
- 功能清单：以表格形式列出 MVP 范围内的核心功能
- 功能编号 | 功能名称 | 功能描述 | 优先级（P0/P1/P2）| 验收标准简述
- 功能依赖关系：说明功能之间的前置依赖
- 范围边界：明确说明 MVP 不包含 的内容（Out of Scope）
- 信息架构概览：核心模块/页面/实体的组织关系（文字描述即可）
3. 用户故事 (User Stories)
每个用户故事 必须 采用标准格式：
> 作为 <用户角色>，
> 我想要 <执行某个操作/获得某种能力>，
> 以便于 <实现某价值/解决某问题>。
组织要求：
- 按用户角色分类分组
- 每个用户故事附带：
- 优先级：Must Have / Should Have / Could Have / Won't Have（MoSCoW）
- 验收标准 (Acceptance Criteria)：Given-When-Then 格式的可验证条件（至少 2 条）
- 关联的 MVP 功能编号
- 按「主流程 → 次要流程 → 异常流程」的逻辑顺序排列
- 数量要求：每个用户角色至少 3 个用户故事，总计不少于 8 个
4. 非功能需求 (Non-Functional Requirements)
必须覆盖以下维度（根据产品特性选择相关项，至少覆盖 4 个维度）：
| 维度 | 说明 |
|---|---|
| 性能 (Performance) | 响应时间、吞吐量、并发能力等量化指标 |
| 可用性 (Usability) | 易学性、操作效率、错误预防、无障碍访问等 |
| 可靠性 (Reliability) | 系统稳定性、故障恢复、数据持久化保障 |
| 安全性 (Security) | 认证授权、数据加密、审计日志、隐私保护 |
| 响应式布局 (Responsive Design) | 多端适配策略、断点定义、屏幕兼容性要求 |
| 可扩展性 (Scalability) | 水平/垂直扩展能力、模块化解耦程度 |
| 可维护性 (Maintainability) | 代码规范、日志体系、监控告警、部署流程 |
| 兼容性 (Compatibility) | 浏览器/操作系统/设备/第三方服务版本要求 |
每个维度的非功能需求应包含：
- 需求描述
- 具体指标或标准（尽量量化）
- 验证方式
执行流程
第一步：收集与分析输入
-
获取输入材料：从用户处获取以下信息（至少需要产品基本定位 + 核心需求列表）：
- 产品名称与定位
- 产品需求文档（PRD）/ 需求条目列表
- 数据模型设计（如有：ER 图、字段定义、实体关系）
- UI/UX 设计稿或原型描述（如有）
- 技术栈约束（如有） -
主动补全研究：若用户提供的信息不足以支撑完整的场景分析，通过以下方式补全：
- 基于已有信息进行合理的行业常识推断（明确标注「推断」）
- 对于模糊的需求点，向用户提出针对性的澄清问题
第二步：构建用户画像与场景框架
- 根据产品定位推导目标用户角色（2–4 个典型 Persona）
- 为每个角色梳理使用产品的典型任务路径
- 识别关键交互触点（Touchpoints）
第三步：按规范逐节撰写文档
- 严格遵循「文档结构规范」中定义的四部分框架
- 用户故事部分务必使用标准模板并附带验收标准
- 非功能需求部分根据产品类型选取合适维度，不要机械罗列所有维度
第四步：质量自检
输出前逐一核对：
- [ ] 四个章节是否齐全且无遗漏
- [ ] 用户故事是否均采用「作为…我想要…以便于…」格式
- [ ] 每个 User Story 是否有至少 2 条 Given-When-Then 验收标准
- [ ] 非功能需求是否覆盖了至少 4 个维度
- [ ] 是否有具体的量化指标（而非空泛描述）
- [ ] 文档中是否未包含任何代码
第五步：输出交付
- 将最终文档以 Markdown 格式 输出
- 若用户有特定文件名或存放路径要求，按其指示写入文件；否则直接在对话中呈现
- 在文档末尾附上「文档元信息」小节，记录：
- 文档版本（v1.0 起）
- 编制日期
- 基于的输入材料摘要
- 待确认/待澄清的事项清单（如有）
重要约定
- 禁止输出任何代码：本 Skill 的唯一产物是 Markdown 格式的用户场景文档，绝对不生成代码、配置文件、脚本等内容。
- 标注推断内容：所有基于推断补充的信息，必须在对应位置以
*(推断)*或*[待确认]*标注。 - 适度追问优于胡乱猜测：当关键信息严重缺失时，优先向用户提问澄清，而非自行编造大量假设性内容。
- 保持语言简洁专业：文档采用中文撰写，术语准确，避免冗余表述。面向领导汇报时适当增强可视化表现力（表格、分层标题等）。
