game-demo-feedback-triage

游戏演示版反馈分类

使用此技能，将杂乱的反馈材料整理成简短、加权的游戏反馈简报。

目标不是总结每条意见，而是找出最有把握的玩家体验阻碍，区分有代表性的信号与嘈杂的个别案例，并建议团队在下一次构建、试玩、游戏节或发布节点前应产出的唯一一项成果。

在处理边缘情况，或商店页面／演示版、用户体验、稳定性和性能信号混杂在一起时，请先阅读 references/feedback-buckets.md。

适用场景

• 内部试玩记录、问卷回复、错误列表和反馈文档需要确定优先级
• Steam Playtest、Next Fest、创作者或主播对演示版的反应需要整理成按优先级排序的修复简报
• 团队掌握了混合的定性和技术证据，需要在下一次构建前判断哪些问题最重要
• 反馈涉及新手引导、清晰度、难度、操控、性能、稳定性或转化，需要形成一份跨职能的统一视图
• 小型工作室需要简短的继续／停止或优先修复建议，而不是冗长的产品报告

不适用场景

• 主要问题是原始构建／日志故障，且没有更广泛的反馈材料 → 优先使用 game-build-log-triage
• 主要问题显然是性能采集和瓶颈诊断 → 优先使用 game-performance-profiler
• 在尚无玩家反馈时，团队需要审核商店页面或发布页面 → 优先使用 steam-store-launch-ops
• 用户想要通用的冲刺计划，且没有游戏专属的反馈证据 → 优先使用 task-planning 或 bmad-gds

说明

第 1 步：标注反馈材料

在确定优先级前，记录最基本的信息。

收集：

• 来源构成：内部试玩 | Steam Playtest | 创作者／主播 | QA 测试 | 问卷／表单 | Discord／社区 | 混合
• 构建阶段：原型 | 垂直切片 | 演示版 | 即将推出 | 游戏节演示版 | 发布候选版本 | 发布后
• 受众契合度：目标玩家 | 友好测试者 | 广泛受众 | 未知
• 证据类型：引述、问题列表、视频／片段、问卷统计、愿望单／背景说明、性能／日志发现
• 目标限制：下一次试玩 | Next Fest | 创作者节点 | 发售日期 | 未知
• 已知严重程度信号：严重阻碍、流失／跳出、困惑、转化率低、崩溃、卡顿、负面情绪

如果材料稀少或主要由个别案例组成，应保持较低置信度并明确说明。

第 2 步：将反馈归入一组主要类别

使用以下类别，并控制列表长度。

主要类别

• 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
• “他们理解了操控，但玩了 10 分钟后就失去兴趣” → core-loop-fun-clarity
• “演示版感觉不公平／节奏不对／资源经济系统感觉失衡” → difficulty-balance-progression
• “菜单、HUD、教程提示或手柄操控体验令人沮丧” → controls-ui-readability
• “玩家提到崩溃、卡顿、Steam Deck 问题或顿挫” → stability-performance
• “构建整体没问题，但粗糙之处或缺少表现力削弱了整体印象” → content-polish-scope
• “玩家／观众对游戏幻想或演示版／商店页面宣传不买账” → store-demo-conversion-message

不要把所有问题都归结为“错误”或“反馈”。要区分玩家理解、乐趣、润色、稳定性和转化。

第 3 步：在排序前为信号加权

对每个类别，从以下四个维度为证据评分：

1. 频率 — 它在测试者或来源中出现的频率有多高？
2. 严重性 — 它是否会阻碍理解、留存或对发布的信心？
3. 代表性 — 反馈来自目标玩家，还是存在偏差的受众？
4. 时机风险 — 忽略它是否会损害下一场活动、演示环节或版本发布？

然后将每项标记为以下其中一种：

• fix-before-next-build
• watch-next-test
• do-not-overreact-yet

单条意见再响亮，也不代表它自动成为首要任务。

第 4 步：撰写反馈简报

按以下确切结构返回一份简洁报告：

# Game Demo Feedback Brief

## Scope
- Source mix: ...
- Build stage: ...
- Audience fit: ...
- Target constraint: ...
- Confidence: high | medium | low

## Highest-confidence signals
- 2-4 bullets on what the evidence most strongly suggests

## Priority buckets
| Bucket | Why it matters now | Evidence weight | Action |
|--------|---------------------|-----------------|--------|
| ... | ... | high / medium / low | fix-before-next-build / watch-next-test / do-not-overreact-yet |

## Top 3 fixes before the next beat
1. ...
2. ...
3. ...

## Issues to watch, not overreact to
- ...
- ...

## Evidence gaps
- ...
- ...

## Recommended next artifact
- Choose one: 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 bullets that prevent noisy backlog churn or premature redesigns

第 5 步：根据请求类型调整简报

对于内部试玩：

• 优先关注理解、乐趣和进度推进，再考虑长期打磨
• 区分团队已知问题与新玩家真正遇到的困惑

对于 Steam Playtest / Next Fest / 公开试玩版反馈：

• 更加重视声誉风险
• 区分试玩版质量阻碍与商店页面或流量问题
• 明确下一步最佳行动是修复试玩版、调整信息传达，还是决定时机

对于创作者 / 直播主反馈：

• 关注首次游玩时的清晰度、可读性、值得展示的精彩时刻，以及流程在哪些地方变得难以观看或分享
• 区分面向观众的信息传达问题与深层系统平衡问题

对于混合了错误 + 性能 + UX 的反馈包：

• 将 stability-performance 作为一个类别，而不是全部结论
• 如果需要详细性能分析，建议将 game-performance-profiler 作为下一项材料，然后将分析结果纳入简报

第 6 步：必要时索取最少量的缺失证据

如果信心不足，请索取能够实质性改善分诊结果的最小一组材料：

1. 5-10 条有代表性的反馈引述或问题要点
2. 测试者是目标玩家，还是友好用户 / 内部测试者
3. 当前构建阶段和下一个外部里程碑
4. 是否存在崩溃 / 性能问题模式或特定设备的投诉
5. 简短说明玩家在哪里退出、感到困惑或失去兴趣

不要要求撰写一份庞大的事后总结。

输出格式

始终返回简短的分诊简报，而不是冗长的设计论文。

要求：

• 将最突出的面向玩家的阻碍放在首位
• 区分有代表性的模式与偶发的个别情况
• 报告控制在约 350-550 个词以内，除非用户要求更多
• 只建议一项后续材料，不要并行安排十项工作流
• 涉及面向公众的发布节点时，明确说明发布 / 活动的时机风险

示例

示例 1：Next Fest 试玩版令人困惑

输入

我们对 Next Fest 试玩版进行了一次小规模试玩。大多数人觉得操作还不错，但许多测试者在最初十分钟里迷了路，还有一些直播主表示，他们不确定游戏真正的亮点是什么。也有少数人提到 Steam Deck 上会卡顿。

输出概要

• 主要类别：onboarding-comprehension
• 次要类别：store-demo-conversion-message 和 stability-performance
• 前 3 项修复重点是前期清晰度、首次游玩的指引，以及有针对性地跟进 Steam Deck 问题，而不是彻底重新设计
• 建议的下一项材料：onboarding fix brief

示例 2：创作者联络前的混合内部记录

输入

在我们把试玩版发给创作者之前，请将这些试玩记录整理成优先事项。错误清单很长，但实际模式似乎是玩家喜欢战斗，却会在菜单中退出。

输出概要

• 信心最高的信号：核心循环受到玩家认可，但菜单 / 操作 / 可读性问题影响了他们继续游玩
• 优先行动：先修复影响较大的菜单 / HUD 可读性问题，再打磨低频错误
• 建议的下一项材料：demo polish checklist 或 creator-feedback summary

示例 3：反馈意见复杂，且混淆了商店页面与试玩版

输入

我们的 Steam Playtest 报名情况还不错，但玩家要么在教程后流失，要么表示他们从页面和预告片中期待的是另一种游戏。我们应该先解决什么？

输出示意

• 分类：onboarding-comprehension 和 store-demo-conversion-message
• 简报区分预期设定与游戏内引导
• 建议的下一份材料：store/demo message update 或 onboarding fix brief
• 暂时不要做的事：不要用扩大整体范围来掩盖问题

最佳实践

1. 将反馈视为证据，而非投票——优先处理具有代表性的阻碍，而不是声量大的个别意见。
2. 区分理解度、乐趣和稳定性——它们对应不同的后续材料。
3. 让下一个外部节点清晰可见——Next Fest、创作者联络和发布窗口都会改变优先级权重。
4. 使用一份简短的优先级简报，不要一次性把所有问题都堆给团队。
5. 必要时将深入技术分析转交出去——详细的性能分析和原始日志排查应交由相应的专业技能处理。
6. 避免待办事项列表反复变化——将部分问题标记为下次测试时关注，而非立即修复。

参考资料

• Steam Playtest
• Steam Next Fest - 提示
• 商店页面的创建与编辑
• 最佳实践：改善游戏测试的五条建议
• 独立开发者成功进行游戏测试的 6 个步骤
• 通过反馈测试做出更好的游戏决策
• 如何高效进行游戏测试