Zane-qin pm-prd-requirement-details
与全文 PRD 的关系
- 全文骨架与必备表仍遵守
pm-prd-doc；文风遵守pm-writing-style-fayemax。 - 本 skill 只收紧 「需求详情」这一章 的结构与写法，便于研发 / 测试 / 设计对齐。
推荐章节顺序（强制）
本章结论（1 段 callout 或引用块）
用一句话说清：做什么、覆盖多少对象、§1 / §2 分工。明确「计费 / 埋点 / 接口字段若已在总表或其它章写清，本章不重复」。§0 范围与名词
小表：名词 | 口径（入口、用户动作名如 Create、会员/外部模型定义等）。
单列 「不在本章」，避免需求详情膨胀成百科全书。§1 模型 / 配置清单（冻结事实）
- 只陈述可配置事实：模式、分辨率、时长、声音、成本相关字段等；每行可对照总表。
- 子节按类型拆（自研升级 / 能力扩展 / 新接入）。
- API 文档对照单独成节（模型 | 批次 | 链接 | 状态）；缺链写「待补」而非空白。
§2 产品方案（可验收）
- 不要用「需求点 | 需求详情」两列笼统表。改用 四列：
编号 | 需求点 | 规则/行为 | 验收要点。 - 编号建议按域前缀：
S-选择器、P-参数、F-流程、M-会员……便于评审口述与用例映射。 - 每条规则必须 可测：能看出「怎么验收」，避免「优化体验」「与线上一致」单独出现而无对照物（若确实同线上，写清「错误态与线上一致，对照 xxx」）。
- 不要用「需求点 | 需求详情」两列笼统表。改用 四列：
待确认 / 风险
从正文里拆出未闭环项；区分 阻塞 / 非阻塞；删掉重复句、粘贴错误（如同一问题写两遍）。
反模式（不要写）
- 飞书里只有一列表格、单元格内丢样式、中英文混用无空格、同一需求在「清单」和「方案」里各写一套数字却互相矛盾。
- 「追加 10 个模型」与清单 11 个 这种不一致。
- 把 API 说明、埋点、计费推导全塞进需求详情导致没人读完。
成稿后自检（6 条）
- 本章首段能否单独转发给老板 / 研发仍成立
- §1 任意数字在 §2 中引用时是否一致
- §2 每一行是否都有「验收要点」
- 待确认是否无重复、无乱粘贴
- 「不在本章」是否覆盖埋点 / 后台 / 纯服务端口径
- 已读
pm-writing-style-fayemax：结论前置、表格化、无模糊优先级词
参考范例（可对照）
Quokka 第二批外部视频模型 PRD 中「需求详情」重写版（本地路径，便于 diff）：
工作内容/quokka/prd/20260429_quokka-video-models-round2.md 内 ## 需求详情 一节。
飞书同步文档（同一内容曾用于对齐）：