设计评审意见汇总

设计评审后，意见散在四处

产品走查、Figma 线程、飞书/Slack 记录和口头「就这么改」混在一起时，团队往往缺一份可复核的清单：当前到底是哪一版、评论落在哪个页面/组件、哪些是观察、哪些是建议、谁已经拍板。主持人总结或评论标 done，也不等于指定决策人已接受，或问题按你们的「已解决」定义闭环。

技能在做什么

本技能把用户提供的 Figma 评论、会议记录、聊天摘录 收敛成内部草稿式反馈清单，固定 设计版本与页面锚点，并按六类陈述拆分，且每类都保留原话来源：

• 观察：评论者描述的现象（不自动当缺陷）
• 理由/约束：可定位的用户目标、数据、规范、技术或合规依据
• 偏好：主观审美，不包装成用户事实
• 建议：改法提案，不等于已采纳
• 问题：待确认的设计意图、状态或证据
• 决定/行动：仅记录指定决策人的接受/拒绝/暂缓，以及有 Owner 与交付物的行动

处理上大致遵循：锁定版本与统计口径 → 按类拆句并核对锚点 → 仅在锚点与含义一致时去重（保留全部来源与方案分支）→ 并列冲突意见 → 按规则标注处置状态（待定位、待验证、待决策、已接受/已拒绝/暂缓、已修改待复核、待迁移核对、已解决）。输出对齐 references/design-feedback-template.md，频次只代表本批材料计数，不冒充优先级。

边界与注意点

• 不访问或修改 Figma，不生成视觉稿，不建任务、不回复评论，也不替设计负责人接受/拒绝或承诺日期。
• 无测量值与规范版本时，不能宣称无障碍不合规；只有截图时，需声明未覆盖动态、异常、加载、空态与键盘/读屏行为。
• 无指定决策人时只输出待决策项；材料为空时说明无可整理评论，不能推断设计已通过。修改设计、建单与对外承诺须由有权人员复核执行。