会议纪要与 Figma 生成 PRD

要解决什么问题

产品侧常见断层：会议只留下零散原文或录音转写，设计稿在 Figma 里已经画完，但需求文档要么没人写，要么会议说法与界面细节对不上。开发、测试拿到的往往是「口头约定 + 几张截图」，缺少可评审的结构化 PRD，冲突点也无人标注。

本技能面向「会议纪要原文 + Figma 源文件/链接」这类输入，把业务意图与界面证据对齐，输出固定章节的 Markdown PRD，而不是泛泛的摘要。

如何工作

1. 消化会议材料：从纪要/转写/聊天记录里抽取背景、范围、非目标、约束、排期、灰度与指标、功能点与开放问题；涉及产品逻辑的措辞尽量保留原意，不把模糊表述擅自写成硬规则。
2. 解读 Figma：在可用时先配合 Figma 相关能力；可用 scripts/figma_extract.py 拉取节点结构，用 scripts/figma_export_images.py 按功能模块导出截图到 PRD 旁 assets/figma/ 等目录，并在功能表里用相对路径引用。
3. 证据对齐：按功能模块把会议条目映射到帧/文案/状态/原型连线；会议定范围，设计定界面与交互；冲突写 待确认，设计多出来的同流程页面标 设计稿补充，会议有而稿没有的标 UI待补充。
4. 按模板落稿：遵循 assets/prd-template.md，核心「需求内容详细描述」用 示意图 / 功能场景 / 需求详情 三列表格；标题格式如 【战绩玩法】+ 简短产品名；埋点节仅占位，不臆造事件名。

纪要不全时可 Figma 优先推断，并标「基于设计稿推断，待确认」；无 Token 或私有文件时继续写 PRD，设计细节标待补充/待校验。

适用边界

• 需要你能提供纪要类原文和/或可访问的 Figma（链接、导出或截图）；两者都缺时只能产出带 暂无/待补充 标记的草稿。
• 不会把未证实的假设写成已确认事实；最终 PRD 仍应经产品与设计评审。