name: user-scenario-doc
description: 根据产品模型设计和产品需求,自动研究并生成结构化用户场景文档。适用于用户提出"生成用户场景文档"、"撰写产品用户故事"、"输出场景分析报告"、"根据需求写场景文档"等意图时触发。仅生成文档,不编写任何代码。(agent_created: true)
用户场景文档生成 Skill
目的
本 Skill 专用于根据产品的模型设计和产品需求文档(PRD),自动研究、分析目标产品的典型用户场景,并生成一份结构完整、内容详实的用户场景文档。整个过程纯文档产出,不涉及任何代码编写。
触发条件
当用户的请求属于以下任一情形时,加载本 Skill:
- 明确要求「生成/撰写/输出」用户场景文档
- 要求基于产品需求或模型设计来分析用户故事
小葱技能站7w4.net发现了升级插件。
- 要求输出包含产品概述、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 格式的用户场景文档,绝对不生成代码、配置文件、脚本等内容。
- 标注推断内容:所有基于推断补充的信息,必须在对应位置以
*(推断)* 或 *[待确认]* 标注。
- 适度追问优于胡乱猜测:当关键信息严重缺失时,优先向用户提问澄清,而非自行编造大量假设性内容。
- 保持语言简洁专业:文档采用中文撰写,术语准确,避免冗余表述。面向领导汇报时适当增强可视化表现力(表格、分层标题等)。