关于 game-performance-profiler
game-performance-profiler 是用于 Unity 和 Unreal 游戏性能诊断的技能，面向需要解读性能数据并确定下一步采集的团队。它先判断可能的瓶颈，再提出最小化的后续测量或设备审查方案。
主要功能
- 01整理引擎、设备与性能证据
- 02选择单一分析模式和主要瓶颈
- 03规划下一次最小化性能采集
- 04制定可复现的基准测试路线
- 05区分编辑器与打包设备表现
适用场景
- 01分析 Unity 性能分析器截图或数据
- 02排查 Unreal 帧时间尖峰或卡顿
- 03规划 Steam Deck 等目标设备审查
- 04为性能回归选择下一项采集
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/game-performance-profiler确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
SKILL.toonevals/evals.jsonreferences/capture-packets-and-benchmark-routes.mddevice-review-and-steam-deck.mdescalation-ladder.mdmode-selection-and-route-outs.mdprofiling-patterns.md详细介绍
游戏性能分析器
当主要问题是 “我们应该相信哪份数据包、最可能是哪类瓶颈，以及接下来值得产出哪项采集或审查材料？” 时，使用此技能。
这项工作不是罗列泛泛的优化建议。 这项工作的目标是规范当前数据包、选择一种运行模式、确定一个主要瓶颈类别、推荐能提升判断信心的最小化下一次采集，并产出一份团队可以据此采取行动的分析材料。
处理不熟悉的请求类型前，请阅读 references/mode-selection-and-route-outs.md。 设计可复现的测试前，请阅读 references/capture-packets-and-benchmark-routes.md。 在将编辑器数据用于掌机或目标设备审查前，请阅读 references/device-review-and-steam-deck.md。 对薄弱或模糊的证据进行分类前，请阅读 references/profiling-patterns.md。 从截图或统计数据包直接升级到更深入的引擎或 GPU 工具前，请阅读 references/escalation-ladder.md。
何时使用此技能
- Unity 或 Unreal 项目出现低 FPS、帧时间尖峰、卡顿或性能回退，且尚未定位瓶颈
- 需要解读 Profiler 截图、
stat unit/stat gpu输出、Unreal Insights 跟踪、叠加层采集、路线说明或基准测试问题 - Steam Deck、掌机、移动设备、主机、VR 或低规格设备的审查请求，且打包后的设备运行情况比编辑器观感更重要
- 需要性能分析计划、基准测试路线、设备审查数据包、CPU/GPU 拆分说明或升级处理方案，而非立即修改代码
- 性能数据包内容混杂，尚不清楚下一步由谁负责，首要任务是在快速数据包、深入跟踪或相邻游戏技能之间做出选择
何时不使用此技能
- 主要问题是 Unity/Unreal 构建、烘焙、打包、编辑器或 CI 故障，且尚无运行时帧时间诊断 → 使用
game-build-log-triage - 主要问题是通用 Web/应用/服务性能，而非引擎特定的运行时采集解读 → 使用
performance-optimization - 实际任务是围绕缺陷、游戏测试记录、发布目标和路线图权衡进行广泛的里程碑或制作协调 → 使用
bmad-gds - 数据包主要是游戏测试/演示/社区反馈，且问题在于优先确定先修复什么 → 使用
game-demo-feedback-triage - 下一步已经明确是进行深度实现更改，且原因已确认；先产出性能分析简报，再转交实现技能
说明
步骤 1：整理数据包
诊断前，先收集最低限度的有效上下文。
记录：
- 引擎：
Unity|Unreal|Unknown - 目标平台：PC | Steam Deck / 掌机 | 主机 | 移动设备 | VR | 低规格笔记本电脑 | 未知
- 环境：编辑器 | 打包版/开发版构建 | 发布版/出货版构建 | 未知
- 症状：平均 FPS 偏低 | 间歇性卡顿 | 移动时卡顿 | 战斗时尖峰 | 加载停滞 | 热量导致性能漂移 | 未知
- 可用证据：Profiler 截图、跟踪/采集文件、统计命令截图、叠加层截图、视频、基准测试记录、复现步骤
- 复现情形：确切场景、存档槽位、遭遇战、移动路线、菜单、过场动画或未知
- 质量变量：分辨率、预设、帧率上限、升频器状态、电源模式，以及适用时的电池状态
快速整理：
Engine: Unreal
Target: Steam Deck
Environment: packaged build unknown
Symptom: traversal hitch after two minutes in market square
Evidence: `stat unit` screenshot + overlay photo
Repro: route not yet fixed
规则：如果数据包内容单薄，应保持较低的判断信心，并让下一次采集更精简，而不是扩大范围。
步骤 2：选择一个主要模式
使用 references/mode-selection-and-route-outs.md。
恰好选择一个主要模式：
quick-triage-packetbottleneck-classificationbenchmark-route-plandevice-reviewtool-escalation
规则：一个主要模式，可选一个次要说明。不要试图一次处理所有模式。
步骤 3：提出修复建议前，先指出可能的瓶颈类别
选择一个主要类别，以及一个可选的次要类别。
主要类别：
cpu-gameplay-scriptingcpu-render-thread-draw-call-pressuregpu-rendering-shaders-postfxmemory-gc-allocation-churnloading-streaming-iophysics-animation-simulationplatform-config-thermal-device-specificunknown-needs-better-capture
良好的瓶颈描述：
- “最明显的信号表明，问题是在移动过程中出现流式加载／IO 卡顿，而不是稳定状态下的 GPU 负载。”
- “这份数据包显示，战斗期间出现 GC／分配峰值的可能性高于渲染饱和。”
- “这似乎受设备／配置影响，因为团队仍依赖编辑器中的主观印象，而不是目标设备上的打包版本证据。”
避免使用：“整体性能很差。”
步骤 4：建议成本最低的下一次采集
选择成本最低、又能有效区分可能原因的采集方式。
常见的下一步采集：
- 使用有代表性的玩家版本，采集一份更完善的 Unity Profiler CPU／GPU／Memory 数据包
- 在精确的 Unreal 复现路线中采集一组
stat unit和stat gpu - 采用一条固定的移动路线，进行预热并设定重复次数
- 采集一份设备上打包版本的数据，而不是再截取编辑器截图
- 只有在首份数据包有依据时，才进行更深入的跟踪（Unreal Insights、GPU Visualizer、Frame Debugger 或外部 GPU 工具）
规则：除非数据包已明确指向渲染路径问题，否则优先使用引擎原生采集工具，而不是厂商 GPU 工具。
步骤 5：明确路线和设备背景
如果缺少可复现性，就定义一条尽可能短、可重复的测试流程。
请说明：
- 存档槽／检查点／场景
- 起点和移动路径
- 预热次数
- 测量的重复次数或时长
- 图形预设／帧率上限／电源模式
- 数据包来自仅编辑器、仅打包版本，还是目标设备
不要把“市场区域感觉很卡”当作可靠的基准测试路线。
步骤 6：返回一份性能分析简报
始终按以下格式返回一份简洁的交付物：
# Game Performance Profiling Brief
## Scope
- Mode: ...
- Engine: ...
- Target: ...
- Environment: ...
- Symptom: ...
- Confidence: high | medium | low
## Evidence packet
- What exists now: ...
- What's missing: ...
- Editor vs packaged / device note: ...
## Primary bottleneck hypothesis
- Bucket: ...
- Why it fits: ...
- Evidence: ...
## Secondary hypothesis
- Bucket: ...
- Why it still matters: ...
## Next capture
1. ...
2. ...
3. ...
## Benchmark route / device review
- Repro route or save: ...
- Repeat / warm-up guidance: ...
- Device or packaged-build checks: ...
## Escalation path
- Stay with quick packet | move to engine profiler | escalate to GPU tool
- Why: ...
## Recommended next artifact
- Choose one: quick triage packet | profiling plan | benchmark route brief | CPU/GPU split note | memory/GC checklist | streaming hitch checklist | device review brief
## What not to do yet
- 1-3 bullets that prevent premature optimization or blind rewrites
输出格式
要求：
- 先判断瓶颈，再讨论修复方案
- 区分证据与假设
- 建议下一步采集、路线或设备检查，而不是罗列大量待办事项
- 明确说明编辑器与打包版本、数据包与跟踪的界限
- 除非用户要求更多内容，否则报告控制在约 300-550 个词
- 使用引擎原生术语，例如 Unity Profiler、Frame Debugger、Unreal Insights、
stat unit、stat gpu、帧时间、绘制调用压力、GC、流式加载和打包版本
示例
示例 1：Unity 战斗期间出现卡顿峰值
输入：“我们的 Unity 游戏在战斗期间会从 120 FPS 降到 45 FPS。我们有 Profiler 截图，有人怀疑是 GC 峰值。请分诊并说明首先要检查什么。”
**预期格式：**将问题归为 memory-gc-allocation-churn 或 cpu-gameplay-scripting，将现有截图作为真实数据包，并建议成本最低的下一步采集；不要先入为主地转向渲染建议。
示例 2：Unreal 开放世界移动卡顿
输入：“Unreal 在室内表现正常，但在开放世界区域帧时间会暴增。请帮我判断问题来自 CPU、GPU、流式加载还是着色器。”
**预期格式：**使用 bottleneck-classification 或 benchmark-route-plan，酌情建议使用 stat unit／stat gpu 或 Unreal Insights，并定义一条可复现的移动路线，而不是猜测修复方案。
示例 3：Steam Deck 评审材料包
输入：“我们需要在演示版发布前制定 Steam Deck 性能评审计划。编辑器体验不够流畅，但我们还没有在设备上分析过打包后的构建版本。”
**预期形式：**选择 device-review，对结论保持审慎，优先收集设备上打包版本的证据，并返回设备评审简报或基准测试路线简报。
示例 4：转交给构建失败分类
输入：“我们的 Unreal 打包构建版本在 cook 期间崩溃，而且我们甚至还没有运行时数据。”
**预期形式：**转交给 game-build-log-triage，而不是假装这已经是一个性能分析问题。
最佳实践
- 从团队已有的材料包着手，而不是一开始就要求理想的性能跟踪数据。
- 讨论优化之前，先明确一个主要瓶颈类别。
- 将可复现性视为诊断的一部分，而非可有可无的额外项。
- 如果发布目标是掌机或资源受限的机器，优先采用设备上打包版本的证据，而不是编辑器中的主观印象。
- 从截图和统计数据包逐步升级到引擎原生性能分析工具，再考虑 GPU 厂商工具。
- 只建议一个后续材料，不要列出一长串优化待办事项。
- 明确说明转交事项，避免游戏性能工作扩展到构建分类、通用应用调优或生产协调。