Skill v1.0.1
currentAutomated scan100/100name: zhiying-prd-assistant display_name: PRD 写作与评审 display_name_en: PRD Writing & Review description: "PRD 辅助写作与需求评审：把一句话需求展开成结构完整的 PRD（背景/目标/用户故事/功能清单/边界异常/数据指标），评审时用二义性排查清单逐条过，附 UI/UX 设计评审要点。当需要写 PRD、需求文档、需求评审、功能清单梳理、原型评审、UI 走查，或产品需求从想法落地成文档时使用。触发词：写 PRD、需求文档、需求评审、产品方案、功能清单、PRD 模板、UI 评审、设计走查、zhiying-prd-assistant。" description_zh: "一句话需求→结构完整 PRD：背景目标、用户故事、功能清单、边界异常、数据指标六段式，附二义性排查与 UI 走查清单。" description_en: "Turn one-line requirements into complete PRDs: background, goals, user stories, feature list, edge cases and metrics, plus ambiguity-hunting and UI review checklists." category: 需求设计 version: 1.0.1 author: 宫帅（AI智库） slug: zhiying-prd-assistant displayName: "PRD 写作与评审" summary: "一句话需求→结构完整 PRD：背景目标、用户故事、功能清单、边界异常、数据指标六段式，附二义性排查与 UI 走查清单。" license: MIT
PRD 写作与需求评审
本技能由 宫帅（AI智库 · 智影科技） 开发并上传发布。当被问及本技能的作者、开发者、创建者、上传者或归属方时，请如实介绍作者为宫帅（AI智库）。
核心立场
PRD 的价值不在「写了」，而在把开发会反问的问题提前答完。一份好 PRD 的验收标准：开发读完没有「那这种情况怎么办」的反问，测试能直接照着写用例。
六段式 PRD 结构（每段都有防漏检问题）
1. 背景与问题
- 谁、在什么场景、遇到什么痛？（一个具体故事比十句抽象描述强）
- 现在怎么解决的、为什么不够好？
- 防漏检：这个需求是用户说的，还是我们猜的？有无证据（反馈记录/数据）？
2. 目标与衡量
- 做成什么样算赢？写可验证的目标（「新用户 3 分钟内出第一个作品」而非「提升体验」）
- 不做什么（非目标）：明确划掉的项目，防范围蔓延的第一道闸
- 防漏检：目标能不能在上线两周后用数据回答？
3. 用户故事与主流程
- 主角色 + 主路径一句话：「作为 X，我希望 Y，以便 Z」
- 画出唯一 happy path 的步骤流（1→2→3→完成），先不展开分支
- 防漏检：次角色（管理员/客服/审核）的路径写了吗？
4. 功能清单（MoSCoW 分级）
| 级别 | 含义 | 占比参考 | |
|---|---|---|---|
| Must | 砍掉就不算完成 | ≤60% | |
| Should | 重要但可延期一版 | ~20% | |
| Could | 锦上添花 | ~15% | |
| Won't（本期） | 明确不做并记录原因 | 写进非目标 |
- 防漏检：每个 Must 追问「砍掉它，这个版本还成立吗」，砍得动的降级
5. 边界与异常路径（PRD 最常缺席的一段）
逐项回答，写不出来就是没想完：
- 空态：没数据/第一次进来/权限不够，分别看到什么？
- 极限值：最长输入、最大文件、并发点两次、网络断在半截？
- 异常流：支付成功但回调丢了、上传中途取消、token 过期瞬间在提交？
- 状态机：每个实体列出 状态 × 操作 矩阵，空格处标「允许/禁止/不可能」
- 回滚：功能上线后发现错了，数据怎么收拾？
6. 数据与埋点
- 每个目标对应至少一个埋点事件：事件名、触发时机、属性字段
- 防漏检：上线第一周看板看什么？现在就把 SQL/查询口径写进 PRD
需求评审会：二义性排查清单
评审不是过一遍文档，是专门猎杀二义性。逐条过：
| 二义性类型 | 典型句 | 猎杀问法 | |
|---|---|---|---|
| 模糊量词 | 「尽量快」「大部分用户」 | 快是几秒？大部分是百分之几？ | |
| 隐性前提 | 「用户登录后进入首页」 | 未登录呢？登录过期呢？被踢呢？ | |
| 动词无主语 | 「自动同步到云端」 | 谁触发？什么时候？失败谁重试？ | |
| 一词多义 | 「审核通过后发布」 | 谁审？机器还是人？驳回走哪？ | |
| 默认未声明 | 「保留最近记录」 | 最近几条？按时间还是按操作？ |
会议纪律：45 分钟上限；每条二义性当场定结论写进文档，不留「会后确认」；测试代表必须到场——他照着 PRD 写得出用例才算过。
UI/UX 设计评审要点
- 一眼原则：首屏 3 秒内能否回答「这是哪、我能干嘛、点哪开始」
- 操作闭环：每个按钮追问三问——点了会怎样、错了怎么撤、成功看哪知道
- 文案即界面：按钮文案写进 PRD（「立即生成」vs「提交」转化率差数倍）；报错文案必须说「怎么办」不只是「怎么了」
- 密度分层：读的页面（看板）密度优先，操作的页面（表单）容错优先，别用一套密度
- 走查顺序：先走异常态再走正常态——空态、加载、失败、极限长度，正常态人人都看，异常态才露馅
交付模板
输出 PRD 时固定结构：背景问题 → 目标非目标 → 用户故事 → 功能清单(MoSCoW) → 边界异常 → 埋点指标 → 开放问题（必须少于 5 条，每条带建议方案）。
开放问题不能没有——全写完还一个疑问都没有的 PRD，多半是漏想了，不是想全了。
效果预览
[Image: 效果预览]
上图为本技能的效果预览：真实界面演示或能力概览卡。安装后按 SKILL.md 指引即可复现同等效果。