CCGS /perf-profile 技能全解Claude Code Game Studios 中的结构化性能剖析工作流与三类裁决体系【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios导读本文以 Claude Code Game StudiosCCGS框架中分析类技能的标准规格文档 perf-profile.md 为核心骨架系统讲解/perf-profile技能在游戏研发流程中的完整行为契约如何在提供 profiler 数据时直接定位瓶颈在无数据时输出可执行的手动剖析清单如何依据目标平台帧预算输出WITHIN BUDGET/CONCERNS/OVER BUDGET三类裁决以及报告落盘前的 May I write 协作协议。读完本文你将掌握该技能的全部输入输出契约、五条行为测试用例背后的判定逻辑以及它如何与 performance-analyst 专业 Agent 和 CCGS 七阶段研发流水线尤其是 Phase 6 Polish 阶段协同工作。一、技能定位分析类技能中的性能剖析工作流在 CCGS 的 72 个技能中/perf-profile属于analysis分析类别。根据 catalog.yaml 中的登记信息其category: analysis、priority: low规格文件位于 CCGS Skill Testing Framework/skills/analysis/perf-profile.md。分析类技能在 quality-rubric.md 中被统一界定为Analysis skills scan the project and surface findings. They are read-only during analysis and must ask before recommending any file writes.——即分析阶段只读扫描、输出发现、任何文件写入都需先征求许可。这一类别定位直接决定了/perf-profile的三大行为基调只读分析剖析阶段仅使用 Read / Glob / Grep 类工具对应分析类别指标 AN1结构化输出产出带严重度/优先级的发现清单或表格而非纯散文AN2不自动写盘任何报告写入都必须在 May I write 征得用户同意之后进行AN3。从规格文档的 Skill Summary 看/perf-profile的核心职责可概括为一句a structured performance profiling workflow that identifies bottlenecks and recommends optimizations——识别瓶颈、推荐优化但不负责实施优化。这一只诊断不开药方实施的边界与 performance-analyst Agent 的领域声明完全一致详见本文第七节。1.1 输入与输出的两条路径技能的行为遵循数据有无的分叉逻辑条件行为提供了 profiler 数据或性能日志直接分析数据识别瓶颈并给出裁决未提供任何数据输出一份手动剖析清单manual profiling checklist引导用户采集数据后再分析无论走哪条路径技能均不触发任何 director gate规格文档明确写着 No director gates are invoked并且在持久化报告到production/qa/perf-[date].md之前必须先问一句 May I write toproduction/qa/perf-[date].md?。1.2 三类裁决Verdicts整个技能的最终输出收敛为三种裁决之一WITHIN BUDGET—— 当前指标在预算内性能健康CONCERNS—— 平均值在预算内但存在尖峰或局部超标值得关注OVER BUDGET—— 全部或绝大多数帧超出预算属于系统性性能问题。这三类裁决的判定细节由五条行为测试用例逐一锁定下文第三、四、五节将结合用例深入拆解。二、Phase 6 中的实战位置性能剖析如何嵌入研发流水线在 CCGS 的七阶段工作流中性能剖析是Phase 6Polish阶段的第一步。依据 WORKFLOW-GUIDE.md 中 Phase 6 的流水线图/perf-profile -- /balance-check -- /asset-audit -- /playtest-report (x3) | | | | v v v v Profile CPU/GPU Analyze formulas Verify naming, Cover: new player, memory, optimize and data for formats, sizes mid-game, difficulty bottlenecks broken progressions curve /tech-debt -- /team-polish | | v v Track and Coordinated pass: prioritize performance art debt items audio UX QAWORKFLOW-GUIDE 对 Step 6.1 的说明进一步给出了该技能的三项产出承诺确立目标FPS、内存、平台按影响排序识别瓶颈生成带代码位置和预期收益的可执行优化任务。在 skill-flow-diagrams.md 的技能串联图上/perf-profile的输入输出被简洁标注为 perf report fixes——剖析报告连同优化建议共同流向后续的 /tech-debt 与 /team-polish 环节。换言之该技能是打磨阶段性能收口的入口其裁决结果会决定后续平衡分析、资源审计和团队打磨的优先级。此外WORKFLOW-GUIDE.md 的完整技能清单Reviews and Analysis 分组将/perf-profile标注为 Performance profiling workflow适用阶段为 6与 Phase 6 的定位互相印证。三、数据驱动模式从 profiler 导出到瓶颈定位当用户以/perf-profile 数据文件的形式传入 profiler 数据典型如production/qa/profiler-export-2026-03-15.json技能进入直接分析模式。规格文档的Case 1Happy Path完整演示了这条主路径的期望行为。3.1 Case 1 场景帧时间数据 绘制调用尖峰Fixture假定项目状态用户提供production/qa/profiler-export-2026-03-15.json内含帧时间数据数据表现为平均帧时间 14ms在 16.6ms 预算内但第 42–48 帧尖峰到 28ms尖峰与一个450 次 draw call的场景相关预算为 200。输入/perf-profile production/qa/profiler-export-2026-03-15.json期望行为六步技能读取 profiler 数据识别平均帧时间在预算内识别第 42–48 帧的 draw call 尖峰450 次 vs 200 次预算裁决为CONCERNS平均值正常但尖峰表明存在问题针对该场景推荐合批batching或剔除culling询问 May I write toproduction/qa/perf-2026-04-06.md?。断言要点尖峰帧必须按帧号精确定位不能只报有尖峰draw call 数量与预算必须显式对比450 vs 200平均值正常但尖峰超预算时裁决必须为 CONCERNS至少给出一条具体的优化建议写报告前必须出现 May I write 提示。这一用例揭示了技能判定的核心原则裁决不只看平均值更要看分布的极端值。14ms 的平均值虽然健康但 42–48 帧的 28ms 尖峰意味着肉眼可见的卡顿hitch因此正确裁决是 CONCERNS 而非 WITHIN BUDGET。同时优化建议必须绑定到具体场景与具体手段batching / culling而不是泛泛而谈优化性能。3.2 数据来源约定从规格文档与 performance-analyst.md 的覆盖说明可以推断profiler 数据约定存放在production/qa/目录下包括production/qa/evidence/子目录用于存档分析报告文件名形如profiler-export-YYYY-MM-DD.json。技能在读取数据的同时还需要读取technical-preferences.md以获取目标平台的帧预算详见 Case 3。四、无数据模式手动剖析清单Manual Profiling ChecklistCase 2定义了技能在裸调用场景下的行为——用户直接运行/perf-profile不带参数且production/qa/下不存在任何 profiler 数据文件。期望行为技能发现无 profiler 数据输出一份可执行的手动剖析清单引导用户逐步采集数据启用 Godot profiler 或目标引擎的 profiler录制一段 60 秒的游玩会话导出帧时间数据记录任何掉帧dropped frames或卡顿hitches请求用户在数据收集完毕后重新提供数据再运行分析。断言要点无数据时技能不崩溃、也不输出裁决没有可评估的对象输出的是可执行的清单actionable steps而不是一句简单的报错不产生任何裁决nothing to assess yet不写入任何文件。这一用例是分析类技能只在有依据时才下结论哲学的体现/perf-profile宁可输出一份引导性清单也不凭空捏造性能结论。清单本身也具备引擎中立性——它同时列举了 Godot profiler 与目标引擎的 profiler意味着该技能面向多引擎Godot / Unity / Unreal通用。Coverage Notes 同时指出在实际应用中Case 2 的清单内容会是平台相关的主机、移动端各有不同的剖析工具链本规格不覆盖平台特有的剖析流程。五、预算判定与裁决逻辑OVER BUDGET 与回归对比5.1 Case 3系统性超预算 → OVER BUDGETFixtureProfiler 数据一致显示 22ms 帧时间目标 16.6ms对应 60fps所有帧均超预算无单一尖峰——属于系统性systemic问题technical-preferences.md指定目标平台为 PC、60fps。期望行为技能读取 profiler 数据与技术偏好确定性能预算所有帧均超 16.6ms 预算裁决为OVER BUDGET输出按优先级排序的优化清单例如 LOD 系统、shader 复杂度、物理 tick rate写报告前询问 May I write。断言要点全部或绝大多数帧超预算时裁决为OVER BUDGET目标帧预算必须从technical-preferences.md读取而非硬编码这是本用例最重要的断言之一必须提供优化优先级清单不能只给一个干巴巴的裁决报告写入前有 May I write 提示。关键设计意图有二。其一预算来源的单一化16.6ms 这类数值不应写死在技能里而应随项目技术偏好目标平台、目标帧率、内存上限动态变化这与 performance-analyst Agent 的 Case 5Applies budget thresholds from provided context rather than assumed defaults遥相呼应。其二裁决要配处方OVER BUDGET 只是开始技能必须继续产出按影响排序的优化路线LOD 降面、shader 复杂度收敛、物理步进频率调整让用户可以立即转入实施。5.2 Case 4先前报告对比 → delta 分析与回归检查Fixtureproduction/qa/perf-2026-03-28.md已存在记录先前结果avg 15ms, max 19ms新 profiler 导出显示avg 13ms, max 17ms两份报告针对同一场景。输入/perf-profile production/qa/profiler-export-2026-04-05.json期望行为技能读取新 profiler 数据检测到存在针对同一场景的先前报告计算 deltaavg 改善 2ms、max 改善 2ms呈现回归检查结果未检测到回归裁决为WITHIN BUDGET并在报告中记录自上次剖析以来的改善。断言要点写报告前技能会先检查production/qa/中是否存在先前的 perf 报告呈现关键指标的delta 对比先前 vs 当前当前指标在预算内时裁决为WITHIN BUDGET报告中正面记录改善趋势。Case 4 将/perf-profile从一次性体检升级为持续性能监控工具通过按日期归档的perf-YYYY-MM-DD.md报告序列技能可以量化每次优化迭代带来的真实收益本次 2ms / 2ms 的改善同时自动执行回归检查——如果新版指标反而恶化这个对比机制会立刻暴露出来。这也解释了为什么协议规范Protocol Compliance要求Checks for prior perf reports to enable delta comparison。5.3 三类裁决判定速查数据形态裁决对应用例平均值与峰值均在预算内且较先前无恶化WITHIN BUDGETCase 4平均值在预算内但存在超预算尖峰CONCERNSCase 1、Case 5全部或绝大多数帧超预算系统性OVER BUDGETCase 3无数据可评估不输出裁决仅给剖析清单Case 2六、报告写入协议May I write 与 production/qa 归档贯穿全部五个用例的一条铁律是任何报告写入都必须先征得用户同意。技能的固定问法是May I write toproduction/qa/perf-[date].md?对应的静态断言Static Assertions也把这条语言纳入了结构校验项必须包含裁决关键词WITHIN BUDGET、CONCERNS、OVER BUDGET必须包含 May I write 语言技能会写性能报告必须包含 ≥2 个 phase 标题必须具备 frontmatter 必备字段name、description、argument-hint、user-invocable、allowed-tools结尾必须有下一步交接next-step handoff即性能发现评审后的行动指引。这与 skill-test-spec.md 模板中定义的通用断言一一对应也与 CCGS 的协作式设计原则一致Agent 可以起草、可以建议但落盘动作必须由人确认。报告命名规范perf-[date].md如perf-2026-04-06.md与归档目录production/qa/共同构成了后续 delta 对比机制的数据基础——没有规范命名Case 4 的查找先前报告就无法成立。七、边界与协作为何不触发 Director Gate以及与 performance-analyst 的关系7.1 无 Gate 设计Case 5规格文档的Case 5Gate Compliance专门验证了技能的治理边界FixtureProfiler 数据显示 CONCERNS 级发现存在一些尖峰review-mode.txt内容为full全量评审模式。期望行为技能分析数据裁决为 CONCERNS无论 review mode 为何都不调用任何 director gate输出注明For in-depth analysis, consider running/perf-profilewith the performance-analyst agent询问 May I write在用户批准后写入报告。断言要点任何评审模式下都不触发 director gateperformance-analyst 咨询被建议而非强制写报告前有 May I write基于尖峰的发现裁决为 CONCERNS。设计理由在规格文档的 Director Gate Checks 一节写得很直白Performance profiling is an advisory analysis skill; no gates are invoked.性能剖析属于建议型分析不控制阶段转换、不产生绑定性决策因此无需导演creative-director / technical-director / producer / art-director介入。这正对应 quality-rubric 中分析类别的 AN4 指标Analysis skills do not spawn director gates; they produce findings for human review。7.2 与 performance-analyst Agent 的分工当需要更深入的剖析时技能建议而非强制与performance-analyst专业 Agent 配合。对照 performance-analyst.md 的 Agent 规格两者的分工清晰互补维度/perf-profile 技能performance-analyst Agent职责结构化剖析流程、裁决、生成报告领域内深度分析瓶颈识别、指标跟踪、优化建议实施优化不实施明确不拥有实施权Does NOT own: implementing optimizations预算来源读取technical-preferences.md使用上下文提供的预算值不自行假设默认值越界处理—将实现类请求转交给对应程序员 Agent如渲染合批转给 engine-programmer模型层级技能随 Claude Code 调用Sonnetspecialist 默认层级性能剖析链条的完整语义是/perf-profile负责标准化的第一轮剖析 裁决归档performance-analyst 负责按需深入挖掘 产出带行动负责人action owner的瓶颈报告而优化实施最终落到对应领域的程序员 Agent——例如渲染合批归 engine-programmer、物理调优归 gameplay-programmer。这个分析 → 建议 → 实施的三段式在 performance-analyst.md 的 Case 2 中体现得尤为明确Agent 对实现合批优化的请求会明确拒绝并重定向绝不越俎代庖。八、质量验证如何用 skill-test 框架校验 /perf-profile 的行为契约/perf-profile的规格文档本身即是 CCGS 技能测试基础设施的一部分。依据 README.md 与 skill-test.md该技能可通过多层方式验证8.1 静态结构检查/skill-test static perf-profile自动校验规格文档的 5 项结构断言frontmatter 字段、≥2 个 phase 标题、裁决关键词、May I write 语言、下一步交接无需任何 fixture。对应 catalog.yaml 中perf-profile的last_static字段记录。8.2 行为规格测试/skill-test spec perf-profile将技能的实际行为与本文拆解的五条测试用例逐一比对逐条产出 PASS/FAIL/ PARTIAL最终汇总为 PASS / PARTIAL / FAIL 裁决。五条用例合计覆盖了主路径分析Case 1、无数据降级Case 2、系统性超预算Case 3、回归对比Case 4、Gate 合规Case 5。8.3 类别指标评分/skill-test category perf-profile按 quality-rubric.md 中analysis 类别的四条指标AN1–AN4评分AN1 — Read-only scan分析阶段仅用 Read/Glob/Grep扫描过程不写不改AN2 — Structured findings table输出必须含带严重度/优先级的发现表格或清单AN3 — No auto-write任何建议的文件写入性能报告都 gated 在 May I write 之后AN4 — No director gates during analysis分析过程不触发 director gate产出交由人工评审。这四条指标与规格文档的 Protocol Compliance 清单逐条对齐形成规格声明 → 行为用例 → 类别指标的三层验证闭环。8.4 协议合规总览规格文档最后以 Protocol Compliance 清单收束技能的全部行为承诺提供 profiler 数据时读取分析未提供时输出剖析清单从technical-preferences.md读取目标平台的帧预算检查先前的 perf 报告以支持 delta 对比写报告前始终询问 May I write不触发任何 director gate裁决必须是 WITHIN BUDGET / CONCERNS / OVER BUDGET 三者之一。九、覆盖边界与已知限制规格文档的 Coverage Notes 诚实标注了两处未覆盖的场景使用时应加以注意平台特定剖析流程未测试主机console、移动端mobile的平台专属剖析工作流不在本规格测试范围内Case 2 中的手动剖析清单在实际使用时应当是平台特定的不同平台有不同的 profiler 工具与采集协议。跨场景对比未显式处理Case 4 的 delta 对比假定先后报告覆盖同一场景跨场景cross-scene的性能对比没有显式逻辑直接拿不同场景的历史报告做对比可能得出误导性结论。这两条限制意味着使用/perf-profile进行历史对比时应确保比对对象是同一场景的多次测量而非不同场景间的数字比较。十、总结一套可测试、可归档、可协作的性能治理方案回看整个/perf-profile规格其设计价值可以归纳为四个关键词数据驱动有数据直接分析、无数据给清单绝不空谈结论预算外置帧预算来自technical-preferences.md随目标平台与帧率动态变化裁决分级WITHIN BUDGET / CONCERNS / OVER BUDGET 三档覆盖了健康、局部尖峰、系统超标全部性能形态并配以对应的处方具体优化建议或优先级清单协作留痕报告按production/qa/perf-[date].md归档形成时间序列支持 delta 对比与回归检查写盘前必须征得用户同意深入分析可衔接 performance-analyst Agent实施则转交对应程序员——职责边界全程清晰。作为 CCGS Phase 6 打磨流水线的第一环/perf-profile把性能问题从模糊的体感转化为可归档、可对比、可裁决、可追踪的结构化数据是这套 49 Agent / 72 技能协同体系中诊断类能力的典型样本。想要验证其行为契约是否被正确实现可随时借助/skill-test spec perf-profile与/skill-test category perf-profile回归测试想深入某一瓶颈的机理则按技能建议引入 performance-analyst Agent 做专项分析。相关文件索引技能规格主体CCGS Skill Testing Framework/skills/analysis/perf-profile.md技能登记与优先级CCGS Skill Testing Framework/catalog.yaml分析类别质量指标 AN1–AN4CCGS Skill Testing Framework/quality-rubric.md协作 Agent 规格CCGS Skill Testing Framework/agents/specialists/performance-analyst.md技能测试工具模式说明CCGS Skill Testing Framework/skills/utility/skill-test.md测试框架使用方式CCGS Skill Testing Framework/README.md规格模板五用例骨架CCGS Skill Testing Framework/templates/skill-test-spec.mdPhase 6 流水线位置docs/WORKFLOW-GUIDE.md技能串联图docs/examples/skill-flow-diagrams.md【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CCGS /perf-profile 技能全解：Claude Code Game Studios 中的结构化性能剖析工作流与三类裁决体系
CCGS /perf-profile 技能全解Claude Code Game Studios 中的结构化性能剖析工作流与三类裁决体系【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios导读本文以 Claude Code Game StudiosCCGS框架中分析类技能的标准规格文档 perf-profile.md 为核心骨架系统讲解/perf-profile技能在游戏研发流程中的完整行为契约如何在提供 profiler 数据时直接定位瓶颈在无数据时输出可执行的手动剖析清单如何依据目标平台帧预算输出WITHIN BUDGET/CONCERNS/OVER BUDGET三类裁决以及报告落盘前的 May I write 协作协议。读完本文你将掌握该技能的全部输入输出契约、五条行为测试用例背后的判定逻辑以及它如何与 performance-analyst 专业 Agent 和 CCGS 七阶段研发流水线尤其是 Phase 6 Polish 阶段协同工作。一、技能定位分析类技能中的性能剖析工作流在 CCGS 的 72 个技能中/perf-profile属于analysis分析类别。根据 catalog.yaml 中的登记信息其category: analysis、priority: low规格文件位于 CCGS Skill Testing Framework/skills/analysis/perf-profile.md。分析类技能在 quality-rubric.md 中被统一界定为Analysis skills scan the project and surface findings. They are read-only during analysis and must ask before recommending any file writes.——即分析阶段只读扫描、输出发现、任何文件写入都需先征求许可。这一类别定位直接决定了/perf-profile的三大行为基调只读分析剖析阶段仅使用 Read / Glob / Grep 类工具对应分析类别指标 AN1结构化输出产出带严重度/优先级的发现清单或表格而非纯散文AN2不自动写盘任何报告写入都必须在 May I write 征得用户同意之后进行AN3。从规格文档的 Skill Summary 看/perf-profile的核心职责可概括为一句a structured performance profiling workflow that identifies bottlenecks and recommends optimizations——识别瓶颈、推荐优化但不负责实施优化。这一只诊断不开药方实施的边界与 performance-analyst Agent 的领域声明完全一致详见本文第七节。1.1 输入与输出的两条路径技能的行为遵循数据有无的分叉逻辑条件行为提供了 profiler 数据或性能日志直接分析数据识别瓶颈并给出裁决未提供任何数据输出一份手动剖析清单manual profiling checklist引导用户采集数据后再分析无论走哪条路径技能均不触发任何 director gate规格文档明确写着 No director gates are invoked并且在持久化报告到production/qa/perf-[date].md之前必须先问一句 May I write toproduction/qa/perf-[date].md?。1.2 三类裁决Verdicts整个技能的最终输出收敛为三种裁决之一WITHIN BUDGET—— 当前指标在预算内性能健康CONCERNS—— 平均值在预算内但存在尖峰或局部超标值得关注OVER BUDGET—— 全部或绝大多数帧超出预算属于系统性性能问题。这三类裁决的判定细节由五条行为测试用例逐一锁定下文第三、四、五节将结合用例深入拆解。二、Phase 6 中的实战位置性能剖析如何嵌入研发流水线在 CCGS 的七阶段工作流中性能剖析是Phase 6Polish阶段的第一步。依据 WORKFLOW-GUIDE.md 中 Phase 6 的流水线图/perf-profile -- /balance-check -- /asset-audit -- /playtest-report (x3) | | | | v v v v Profile CPU/GPU Analyze formulas Verify naming, Cover: new player, memory, optimize and data for formats, sizes mid-game, difficulty bottlenecks broken progressions curve /tech-debt -- /team-polish | | v v Track and Coordinated pass: prioritize performance art debt items audio UX QAWORKFLOW-GUIDE 对 Step 6.1 的说明进一步给出了该技能的三项产出承诺确立目标FPS、内存、平台按影响排序识别瓶颈生成带代码位置和预期收益的可执行优化任务。在 skill-flow-diagrams.md 的技能串联图上/perf-profile的输入输出被简洁标注为 perf report fixes——剖析报告连同优化建议共同流向后续的 /tech-debt 与 /team-polish 环节。换言之该技能是打磨阶段性能收口的入口其裁决结果会决定后续平衡分析、资源审计和团队打磨的优先级。此外WORKFLOW-GUIDE.md 的完整技能清单Reviews and Analysis 分组将/perf-profile标注为 Performance profiling workflow适用阶段为 6与 Phase 6 的定位互相印证。三、数据驱动模式从 profiler 导出到瓶颈定位当用户以/perf-profile 数据文件的形式传入 profiler 数据典型如production/qa/profiler-export-2026-03-15.json技能进入直接分析模式。规格文档的Case 1Happy Path完整演示了这条主路径的期望行为。3.1 Case 1 场景帧时间数据 绘制调用尖峰Fixture假定项目状态用户提供production/qa/profiler-export-2026-03-15.json内含帧时间数据数据表现为平均帧时间 14ms在 16.6ms 预算内但第 42–48 帧尖峰到 28ms尖峰与一个450 次 draw call的场景相关预算为 200。输入/perf-profile production/qa/profiler-export-2026-03-15.json期望行为六步技能读取 profiler 数据识别平均帧时间在预算内识别第 42–48 帧的 draw call 尖峰450 次 vs 200 次预算裁决为CONCERNS平均值正常但尖峰表明存在问题针对该场景推荐合批batching或剔除culling询问 May I write toproduction/qa/perf-2026-04-06.md?。断言要点尖峰帧必须按帧号精确定位不能只报有尖峰draw call 数量与预算必须显式对比450 vs 200平均值正常但尖峰超预算时裁决必须为 CONCERNS至少给出一条具体的优化建议写报告前必须出现 May I write 提示。这一用例揭示了技能判定的核心原则裁决不只看平均值更要看分布的极端值。14ms 的平均值虽然健康但 42–48 帧的 28ms 尖峰意味着肉眼可见的卡顿hitch因此正确裁决是 CONCERNS 而非 WITHIN BUDGET。同时优化建议必须绑定到具体场景与具体手段batching / culling而不是泛泛而谈优化性能。3.2 数据来源约定从规格文档与 performance-analyst.md 的覆盖说明可以推断profiler 数据约定存放在production/qa/目录下包括production/qa/evidence/子目录用于存档分析报告文件名形如profiler-export-YYYY-MM-DD.json。技能在读取数据的同时还需要读取technical-preferences.md以获取目标平台的帧预算详见 Case 3。四、无数据模式手动剖析清单Manual Profiling ChecklistCase 2定义了技能在裸调用场景下的行为——用户直接运行/perf-profile不带参数且production/qa/下不存在任何 profiler 数据文件。期望行为技能发现无 profiler 数据输出一份可执行的手动剖析清单引导用户逐步采集数据启用 Godot profiler 或目标引擎的 profiler录制一段 60 秒的游玩会话导出帧时间数据记录任何掉帧dropped frames或卡顿hitches请求用户在数据收集完毕后重新提供数据再运行分析。断言要点无数据时技能不崩溃、也不输出裁决没有可评估的对象输出的是可执行的清单actionable steps而不是一句简单的报错不产生任何裁决nothing to assess yet不写入任何文件。这一用例是分析类技能只在有依据时才下结论哲学的体现/perf-profile宁可输出一份引导性清单也不凭空捏造性能结论。清单本身也具备引擎中立性——它同时列举了 Godot profiler 与目标引擎的 profiler意味着该技能面向多引擎Godot / Unity / Unreal通用。Coverage Notes 同时指出在实际应用中Case 2 的清单内容会是平台相关的主机、移动端各有不同的剖析工具链本规格不覆盖平台特有的剖析流程。五、预算判定与裁决逻辑OVER BUDGET 与回归对比5.1 Case 3系统性超预算 → OVER BUDGETFixtureProfiler 数据一致显示 22ms 帧时间目标 16.6ms对应 60fps所有帧均超预算无单一尖峰——属于系统性systemic问题technical-preferences.md指定目标平台为 PC、60fps。期望行为技能读取 profiler 数据与技术偏好确定性能预算所有帧均超 16.6ms 预算裁决为OVER BUDGET输出按优先级排序的优化清单例如 LOD 系统、shader 复杂度、物理 tick rate写报告前询问 May I write。断言要点全部或绝大多数帧超预算时裁决为OVER BUDGET目标帧预算必须从technical-preferences.md读取而非硬编码这是本用例最重要的断言之一必须提供优化优先级清单不能只给一个干巴巴的裁决报告写入前有 May I write 提示。关键设计意图有二。其一预算来源的单一化16.6ms 这类数值不应写死在技能里而应随项目技术偏好目标平台、目标帧率、内存上限动态变化这与 performance-analyst Agent 的 Case 5Applies budget thresholds from provided context rather than assumed defaults遥相呼应。其二裁决要配处方OVER BUDGET 只是开始技能必须继续产出按影响排序的优化路线LOD 降面、shader 复杂度收敛、物理步进频率调整让用户可以立即转入实施。5.2 Case 4先前报告对比 → delta 分析与回归检查Fixtureproduction/qa/perf-2026-03-28.md已存在记录先前结果avg 15ms, max 19ms新 profiler 导出显示avg 13ms, max 17ms两份报告针对同一场景。输入/perf-profile production/qa/profiler-export-2026-04-05.json期望行为技能读取新 profiler 数据检测到存在针对同一场景的先前报告计算 deltaavg 改善 2ms、max 改善 2ms呈现回归检查结果未检测到回归裁决为WITHIN BUDGET并在报告中记录自上次剖析以来的改善。断言要点写报告前技能会先检查production/qa/中是否存在先前的 perf 报告呈现关键指标的delta 对比先前 vs 当前当前指标在预算内时裁决为WITHIN BUDGET报告中正面记录改善趋势。Case 4 将/perf-profile从一次性体检升级为持续性能监控工具通过按日期归档的perf-YYYY-MM-DD.md报告序列技能可以量化每次优化迭代带来的真实收益本次 2ms / 2ms 的改善同时自动执行回归检查——如果新版指标反而恶化这个对比机制会立刻暴露出来。这也解释了为什么协议规范Protocol Compliance要求Checks for prior perf reports to enable delta comparison。5.3 三类裁决判定速查数据形态裁决对应用例平均值与峰值均在预算内且较先前无恶化WITHIN BUDGETCase 4平均值在预算内但存在超预算尖峰CONCERNSCase 1、Case 5全部或绝大多数帧超预算系统性OVER BUDGETCase 3无数据可评估不输出裁决仅给剖析清单Case 2六、报告写入协议May I write 与 production/qa 归档贯穿全部五个用例的一条铁律是任何报告写入都必须先征得用户同意。技能的固定问法是May I write toproduction/qa/perf-[date].md?对应的静态断言Static Assertions也把这条语言纳入了结构校验项必须包含裁决关键词WITHIN BUDGET、CONCERNS、OVER BUDGET必须包含 May I write 语言技能会写性能报告必须包含 ≥2 个 phase 标题必须具备 frontmatter 必备字段name、description、argument-hint、user-invocable、allowed-tools结尾必须有下一步交接next-step handoff即性能发现评审后的行动指引。这与 skill-test-spec.md 模板中定义的通用断言一一对应也与 CCGS 的协作式设计原则一致Agent 可以起草、可以建议但落盘动作必须由人确认。报告命名规范perf-[date].md如perf-2026-04-06.md与归档目录production/qa/共同构成了后续 delta 对比机制的数据基础——没有规范命名Case 4 的查找先前报告就无法成立。七、边界与协作为何不触发 Director Gate以及与 performance-analyst 的关系7.1 无 Gate 设计Case 5规格文档的Case 5Gate Compliance专门验证了技能的治理边界FixtureProfiler 数据显示 CONCERNS 级发现存在一些尖峰review-mode.txt内容为full全量评审模式。期望行为技能分析数据裁决为 CONCERNS无论 review mode 为何都不调用任何 director gate输出注明For in-depth analysis, consider running/perf-profilewith the performance-analyst agent询问 May I write在用户批准后写入报告。断言要点任何评审模式下都不触发 director gateperformance-analyst 咨询被建议而非强制写报告前有 May I write基于尖峰的发现裁决为 CONCERNS。设计理由在规格文档的 Director Gate Checks 一节写得很直白Performance profiling is an advisory analysis skill; no gates are invoked.性能剖析属于建议型分析不控制阶段转换、不产生绑定性决策因此无需导演creative-director / technical-director / producer / art-director介入。这正对应 quality-rubric 中分析类别的 AN4 指标Analysis skills do not spawn director gates; they produce findings for human review。7.2 与 performance-analyst Agent 的分工当需要更深入的剖析时技能建议而非强制与performance-analyst专业 Agent 配合。对照 performance-analyst.md 的 Agent 规格两者的分工清晰互补维度/perf-profile 技能performance-analyst Agent职责结构化剖析流程、裁决、生成报告领域内深度分析瓶颈识别、指标跟踪、优化建议实施优化不实施明确不拥有实施权Does NOT own: implementing optimizations预算来源读取technical-preferences.md使用上下文提供的预算值不自行假设默认值越界处理—将实现类请求转交给对应程序员 Agent如渲染合批转给 engine-programmer模型层级技能随 Claude Code 调用Sonnetspecialist 默认层级性能剖析链条的完整语义是/perf-profile负责标准化的第一轮剖析 裁决归档performance-analyst 负责按需深入挖掘 产出带行动负责人action owner的瓶颈报告而优化实施最终落到对应领域的程序员 Agent——例如渲染合批归 engine-programmer、物理调优归 gameplay-programmer。这个分析 → 建议 → 实施的三段式在 performance-analyst.md 的 Case 2 中体现得尤为明确Agent 对实现合批优化的请求会明确拒绝并重定向绝不越俎代庖。八、质量验证如何用 skill-test 框架校验 /perf-profile 的行为契约/perf-profile的规格文档本身即是 CCGS 技能测试基础设施的一部分。依据 README.md 与 skill-test.md该技能可通过多层方式验证8.1 静态结构检查/skill-test static perf-profile自动校验规格文档的 5 项结构断言frontmatter 字段、≥2 个 phase 标题、裁决关键词、May I write 语言、下一步交接无需任何 fixture。对应 catalog.yaml 中perf-profile的last_static字段记录。8.2 行为规格测试/skill-test spec perf-profile将技能的实际行为与本文拆解的五条测试用例逐一比对逐条产出 PASS/FAIL/ PARTIAL最终汇总为 PASS / PARTIAL / FAIL 裁决。五条用例合计覆盖了主路径分析Case 1、无数据降级Case 2、系统性超预算Case 3、回归对比Case 4、Gate 合规Case 5。8.3 类别指标评分/skill-test category perf-profile按 quality-rubric.md 中analysis 类别的四条指标AN1–AN4评分AN1 — Read-only scan分析阶段仅用 Read/Glob/Grep扫描过程不写不改AN2 — Structured findings table输出必须含带严重度/优先级的发现表格或清单AN3 — No auto-write任何建议的文件写入性能报告都 gated 在 May I write 之后AN4 — No director gates during analysis分析过程不触发 director gate产出交由人工评审。这四条指标与规格文档的 Protocol Compliance 清单逐条对齐形成规格声明 → 行为用例 → 类别指标的三层验证闭环。8.4 协议合规总览规格文档最后以 Protocol Compliance 清单收束技能的全部行为承诺提供 profiler 数据时读取分析未提供时输出剖析清单从technical-preferences.md读取目标平台的帧预算检查先前的 perf 报告以支持 delta 对比写报告前始终询问 May I write不触发任何 director gate裁决必须是 WITHIN BUDGET / CONCERNS / OVER BUDGET 三者之一。九、覆盖边界与已知限制规格文档的 Coverage Notes 诚实标注了两处未覆盖的场景使用时应加以注意平台特定剖析流程未测试主机console、移动端mobile的平台专属剖析工作流不在本规格测试范围内Case 2 中的手动剖析清单在实际使用时应当是平台特定的不同平台有不同的 profiler 工具与采集协议。跨场景对比未显式处理Case 4 的 delta 对比假定先后报告覆盖同一场景跨场景cross-scene的性能对比没有显式逻辑直接拿不同场景的历史报告做对比可能得出误导性结论。这两条限制意味着使用/perf-profile进行历史对比时应确保比对对象是同一场景的多次测量而非不同场景间的数字比较。十、总结一套可测试、可归档、可协作的性能治理方案回看整个/perf-profile规格其设计价值可以归纳为四个关键词数据驱动有数据直接分析、无数据给清单绝不空谈结论预算外置帧预算来自technical-preferences.md随目标平台与帧率动态变化裁决分级WITHIN BUDGET / CONCERNS / OVER BUDGET 三档覆盖了健康、局部尖峰、系统超标全部性能形态并配以对应的处方具体优化建议或优先级清单协作留痕报告按production/qa/perf-[date].md归档形成时间序列支持 delta 对比与回归检查写盘前必须征得用户同意深入分析可衔接 performance-analyst Agent实施则转交对应程序员——职责边界全程清晰。作为 CCGS Phase 6 打磨流水线的第一环/perf-profile把性能问题从模糊的体感转化为可归档、可对比、可裁决、可追踪的结构化数据是这套 49 Agent / 72 技能协同体系中诊断类能力的典型样本。想要验证其行为契约是否被正确实现可随时借助/skill-test spec perf-profile与/skill-test category perf-profile回归测试想深入某一瓶颈的机理则按技能建议引入 performance-analyst Agent 做专项分析。相关文件索引技能规格主体CCGS Skill Testing Framework/skills/analysis/perf-profile.md技能登记与优先级CCGS Skill Testing Framework/catalog.yaml分析类别质量指标 AN1–AN4CCGS Skill Testing Framework/quality-rubric.md协作 Agent 规格CCGS Skill Testing Framework/agents/specialists/performance-analyst.md技能测试工具模式说明CCGS Skill Testing Framework/skills/utility/skill-test.md测试框架使用方式CCGS Skill Testing Framework/README.md规格模板五用例骨架CCGS Skill Testing Framework/templates/skill-test-spec.mdPhase 6 流水线位置docs/WORKFLOW-GUIDE.md技能串联图docs/examples/skill-flow-diagrams.md【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考