用途 该技能用于将混乱的游戏反馈包转化为一份简短、带权重的游戏反馈简报。目标不是总结每一条笔记，而是识别最高置信度、面向玩家的阻碍项，把有代表性的信号与嘈杂的个例分开，并推荐团队在下一个构建、试玩、展会或发布节点之前应产出的单一后续产物。
何时使用 内部试玩笔记、问卷回复、Bug 列表和反馈文档需要排定优先级时；Steam Playtest、Next Fest、创作者或主播的 Demo 反应需要转化为排序后的修复简报时；团队混合了定性与技术证据，需要在下一构建前决定什么最重要时；反馈涉及新手引导、清晰度、难度、操作、性能、稳定性或转化，需要跨职能统一视图时；小型工作室需要简短的上/不上或先修什么建议，而非庞大产品报告时。
何时不使用 如果主要问题是原始构建或日志失败、没有更广泛的反馈包，应改用 game-build-log-triage；如果主要问题是明确的性能采集与瓶颈诊断，应改用 game-performance-profiler；如果团队需要在玩家反馈出现之前审计商店页或发布页，应改用 steam-store-launch-ops；如果用户只想要与游戏反馈证据无关的通用冲刺计划，应改用 task-planning 或 bmad-gds。
主要能力与流程 第一步：标记反馈包。记录最低限度事实，包括来源组合（内部试玩、Steam Playtest、创作者或主播、QA 通过、问卷或表单、Discord 或社区、混合）、构建阶段（原型、垂直切片、Demo、即将推出、展会 Demo、发布候选、发布后）、受众匹配度（目标玩家、友好测试者、广泛受众、未知）、证据类型（引述、问题列表、视频或片段、问卷计数、愿望单或上下文笔记、性能或日志发现）、目标约束（下一次试玩、Next Fest、创作者节点、发布日期、未知）、已知严重度信号（硬阻碍、流失或跳出、困惑、低转化、崩溃、卡顿、负面情绪）。如果反馈包稀薄或大量为个例，保持低置信度并说明。
第二步：将反馈聚类到一个主桶集合。主桶包括：onboarding-comprehension、core-loop-fun-clarity、difficulty-balance-progression、controls-ui-readability、stability-performance、content-polish-scope、store-demo-conversion-message、unknown-needs-better-evidence。典型映射：玩家不知道做什么归入 onboarding-comprehension；理解操作但十分钟后不再关心归入 core-loop-fun-clarity；Demo 不公平、节奏不对、资源经济崩坏归入 difficulty-balance-progression；菜单、HUD、教程提示或手柄手感令人沮丧归入 controls-ui-readability；人们提到崩溃、卡顿、Steam Deck 问题归入 stability-performance；构建大体没问题但粗糙边缘削弱印象归入 content-polish-scope；玩家或观众对幻想题材或 Demo 与商店卖点不买账归入 store-demo-conversion-message。不要把每个问题都压平成 Bug 或反馈，要区分玩家理解、乐趣、打磨、稳定性和转化。
第三步：在排序前对信号加权。对每个桶，从四个视角评分：频率、严重度、代表性、时间风险。然后将每项标记为 fix-before-next-build、watch-next-test 或 do-not-overreact-yet。一条响亮的单条评论不自动成为最高优先级。
第四步：构建反馈简报。返回固定结构：标题 Game Demo Feedback Brief；Scope 记录来源组合、构建阶段、受众匹配度、目标约束、置信度（高/中/低）；Highest-confidence signals 用2至4条要点说明证据最强烈暗示什么；Priority buckets 用表格列出桶、为何现在重要、证据权重（高/中/低）、行动；Top 3 fixes before the next beat 列出前三项修复；Issues to watch, not overreact to；Evidence gaps；Recommended next artifact（从 onboarding fix brief、demo polish checklist、creator-feedback summary、store-demo message update、performance follow-up brief、bug bash list、next playtest plan 中选一个）；What not to do yet 用1至3条要点防止嘈杂积压或过早重设计。
第五步：根据请求类型定制简报。内部试玩优先理解、乐趣和进度，再处理长尾打磨，区分团队已知问题与真正新的玩家困惑。Steam Playtest、Next Fest 或公开 Demo 反馈更重视声誉风险，区分 Demo 质量阻碍与商店页或流量问题，指出下一步最佳动作是修 Demo、修信息还是调整时间。创作者或主播反馈聚焦首次会话清晰度、可读性、展示时刻，以及流程在何处变得不可观看或不可分享，区分面向观众的信息问题与深层系统平衡抱怨。混合 Bug、性能与 UX 反馈包中，stability-performance 只作为一个桶而非全部结论；如需详细性能分析，建议 game-performance-profiler 作为下一步产物，再把结果折回简报。
第六步：需要时索取最小缺失证据。置信度低时，请求能实质性改善分类的最小补充包：5至10条代表性反馈引述或问题要点；测试者是目标玩家还是友好或内部测试者；当前构建阶段与下一个外部里程碑；任何崩溃或性能模式或设备特定抱怨；一段玩家在何处跳出、困惑或失去兴趣的简短总结。不要索取庞大复盘。
输出格式要求 始终返回简短分类简报，而非长设计文章。必须具备：优先突出最强单一玩家侧阻碍；区分代表性模式与个例离群值；除非用户要求更多，报告控制在约350至550词；只推荐一个下一步产物，而非十条并行工作流；涉及公开节点时明确发布或展会时间风险。
示例 示例一：Next Fest Demo 困惑。输入为小规模试玩，多数人说操作还行，但大量测试者在头十分钟迷路，部分主播不确定真正钩子是什么，少数人提到 Steam Deck 卡顿。输出要点：主桶 onboarding-comprehension，次桶 store-demo-conversion-message 与 stability-performance，前三修复聚焦早期清晰度、首次会话引导、针对性 Steam Deck 跟进，而非全面重设计，推荐下一步产物为 onboarding fix brief。
示例二：创作者外联前的混合内部笔记。输入为试玩笔记，Bug 列表很长，但真正模式是人们喜欢战斗却在菜单中流失。输出要点：最高置信信号是核心循环成立但菜单、操作、可读性损害继续游玩，优先修高摩擦菜单与 HUD 可读性问题，再打磨低频 Bug，推荐下一步产物为 demo polish checklist 或 creator-feedback summary。
示例三：带商店页与 Demo 混淆的硬反馈包。输入为 Steam Playtest 注册尚可，但玩家要么在教程后流失，要么说从页面和预告片期待的是另一种游戏。输出要点：桶为 onboarding-comprehension 与 store-demo-conversion-message，简报区分预期设定与玩法引导，推荐下一步产物为 store-demo message update 或 onboarding fix brief，暂不要用大范围扩张掩盖问题。
最佳实践 把反馈当作证据而非投票，优先代表性阻碍而非响亮个例；区分理解、乐趣与稳定性，它们产生不同后续产物；保持下一次外部节点可见，Next Fest、创作者外联与发布窗口会改变权重；用一份简短优先级简报替代把所有问题同时抛给团队；必要时把技术深潜路由出去，详细性能分析与原始日志分类属于专门技能；保护积压免受反复搅动，把部分问题标记为 watch-next-test 而非立即修复。
限制 该技能不处理原始构建或日志失败、不执行性能采集与瓶颈诊断、不在玩家反馈出现前审计商店页或发布页，也不替代通用冲刺规划。若反馈包稀薄或大量为个例，其置信度会保持低并需明确说明。它不产出长篇设计文章，报告长度受约350至550词约束，且只推荐一个下一步产物。