CCGS 玩测报告工作流/playtest-report 技能规格、四段式报告结构与行为测试规范【免费下载链接】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/playtest-report是 Claude Code Game StudiosCCGS框架中负责把一次或多次游戏试玩playtest的会话笔记整理成结构化报告的 utility 类技能它将原始反馈归入 Feel/Accessibility、Bugs Observed、Design Feedback、Next Steps 四个固定小节在多测试者场景下区分多数派与少数派意见并在缺陷与既有 bug 报告匹配时自动交叉引用而非重复建档。本文以仓库中该技能的行为规格文档playtest-report.md为主体结合 CCGS Skill Testing Framework 的测试基础设施、catalog.yaml 注册表与相关 QA 技能源码完整讲解该技能的报告结构、写入协议、五条行为测试用例及其验证方式读完后你既能理解 CCGS 的玩测→缺陷→设计反馈闭环如何运转也能掌握如何用/skill-test对这类 utility 技能做结构检查与行为验收。一、技能定位玩测反馈的「结构化收口」环节在 CCGS 的 72 个技能与 49 个 Agent 构成的工作流体系中/playtest-report属于 utility 类别职责非常单一把非结构化的试玩记录转成四段式标准报告。规格文档开篇即给出其核心契约输入会话笔记session notes或用户直接输入的一段描述输出按 Feel/Accessibility、Bugs Observed、Design Feedback、Next Steps 组织成的报告文件多测试者场景自动识别不同测试者视角聚合反馈并区分**多数派majority与少数派minority**意见缺陷去重当报告的缺陷与production/bugs/下已有 bug 报告匹配时报告内直接给出指向既有文件的引用而不是建议重新建档写入路径production/qa/playtest-[date].md写入前必须先征得用户同意May I write结论verdict报告写入成功后即为 COMPLETE。它与仓库中其他 QA 类技能构成一条完整链路test-setup 负责搭建测试框架并创建tests/playtest/目录对应 coding-standards 规定的 unit/integration/performance/playtest 四层结构smoke-check 在实现与 QA 交接之间做冒烟验证并产出production/qa/smoke-[date].md而/playtest-report承接试玩现场的原始观感缺陷经它整理后Next Steps 会指向 bug-report产出production/bugs/bug-[date]-[slug].md或 design-review。在 catalog.yaml 中playtest-report被登记为category: utility、priority: low并记录了last_static/last_spec/last_category等测试追踪字段规格路径即CCGS Skill Testing Framework/skills/utility/playtest-report.md。二、技能测试框架规格文档在体系中的位置/playtest-report的规格文档并不是「使用说明」而是 CCGS Skill Testing Framework 的行为测试规格behavioral spec。该框架的定位见 CCGS Skill Testing Framework/README.md是测试技能与 Agent 本身而不是用它们做出来的游戏——它是一套独立、可选的 QA 基础设施。每个技能对应skills/[category]/[name].md一份规格统一由 templates/skill-test-spec.md 模板派生而来。规格结构固定为五个部分Skill Summary一段话说明技能做什么、输入是什么、产出是什么Static Assertions不依赖任何 fixture 的结构性断言由/skill-test static自动核验Director Gate Checks该技能是否会触发导演级门禁gateTest Cases通常 5 个行为用例每个包含 Fixture、输入、期望行为与可勾选断言Protocol Compliance 与 Coverage Notes协议合规清单与覆盖边界说明。/playtest-report的规格完整遵循了这一骨架playtest-report.md因此它既是技能的验收标准也是技能当前行为的快照——CCGS Skill Testing Framework/CLAUDE.md 特别强调「规格描述的是当前行为而非理想行为」当技能在实践中表现异常时应先修正技能本身、再更新规格使其与修复后的行为对齐。2.1 静态断言Static Assertions这五条由/skill-test static自动检查无需任何 fixture任何 utility 技能都必须通过必备 frontmatter 字段齐全name、description、argument-hint、user-invocable、allowed-tools至少 2 个 phase 标题阶段化流程要求包含结论关键词COMPLETE在写报告前包含「May I write」协作协议用语结尾有下一步交接例如新缺陷指向/bug-report、设计反馈指向/design-review。这五条断言同时符合 quality-rubric.md 中 utility 类别的 U1 指标通过全部 7 项静态检查返回 COMPLIANT。模板中定义的 verdict 关键词全集为PASS、FAIL、CONCERNS、APPROVED、BLOCKED、COMPLETE、READY见 skill-test-spec.md/playtest-report只需用到 COMPLETE 一种。2.2 导演门禁检查Director Gate Checks本技能规格明确声明None。/playtest-report是纯文档工具不触发任何导演门禁。规格特别标注CD-PLAYTEST创意总监审阅玩测洞察、评估设计影响是独立的一次调用separate invocation不属于本技能的一部分。这条边界在两处得到印证创意总监 Agent 的门禁清单中包含 CD-PLAYTEST见 creative-director.md 中 Gate IDs 列表CD-PILLARS、CD-GDD-ALIGN、CD-SYSTEMS、CD-NARRATIVE、CD-PLAYTEST、CD-PHASE-GATE但该 Agent 的规格「Coverage Notes」中明确记录「Playtest report interpretation (CD-PLAYTEST) is not covered — a dedicated case should be added when the playtest-report skill produces structured output」——即当 playtest-report 技能产出的结构化输出就绪后才需要为 CD-PLAYTEST 补充专门用例。这揭示了一个重要的测试策略报告结构化是导演审阅的前提。玩测报告若只是自由文本创意总监无法稳定地做设计影响评估/playtest-report的四段式模板正是为 CD-PLAYTEST 这类下游消费方提供的结构化输入。三、报告结构四段式模板与内容规整规则3.1 四个固定小节无论输入是粘贴的笔记还是逐题回答报告最终都必须收敛为四个固定小节小节收录内容典型示例Feel / Accessibility手感、操作体验、可访问性观察controls feel floaty、UI font too smallBugs Observed实际观察到的缺陷含可复现细节帧率骤降、角色卡在平台边缘Design Feedback测试者对设计的反馈教程太长、难度曲线不合理Next Steps下一步动作建议缺陷 →/bug-report反馈 →/design-review规格中的 Case 1 明确要求「Bug is listed in the Bugs section (not the Design Feedback section)」即缺陷与设计反馈必须分置——这是防止报告内容错位的第一条断言。3.2 多测试者的聚合规则当输入包含多个测试者视角时报告要区分意见权重多数派意见例如 2/3 测试者认为操作「intuitive」报告记为Majority (2/3): controls intuitive少数派意见例如 1/3 测试者指出 UI 字号过小报告记为Minority (1/3): UI font size concern一致确认的缺陷所有测试者都遇到同一缺陷如 player stuck on ledge记为All testers: player stuck on ledge (confirmed)语义上等同「已确认」。覆盖说明中补充匿名反馈无法识别测试者身份遵循与 Case 3 相同的聚合模式只是不标注测试者标签。3.3 缺陷去重与既有 bug 报告交叉引用报告整理缺陷时技能会扫描production/bugs/目录bug 报告由/bug-report按bug-[date]-[slug].md命名规则生成。若发现匹配项Bugs 小节中会写入See existing report: production/bugs/bug-2026-03-30-player-stuck-ledge.md并且不会再建议为该缺陷新建/bug-report。这套去重逻辑与 bug-report.md 技能自身的「possible duplicate」检查扫描既有报告、提供 link-as-duplicate 或 create-new 选项互相呼应共同保证缺陷台账不膨胀、不重复。3.4 Next Steps 交接规范Next Steps 必须给出可执行的下游动作且要匹配问题类型崩溃/帧率类缺陷 → 建议/bug-report教程过长等设计问题 → 建议/design-review。这既是报告的一部分也是规格静态断言中「next-step handoff」的体现——模板要求所有技能规格在结尾提供明确的下一步交接。四、写入协议日期化文件名与「May I write」报告的落盘遵循 CCGS 统一的协作写入协议技能完成内容整理后先以完整路径询问May I write to production/qa/playtest-[date].md?获得用户批准后才写入写入完成即给出 verdictCOMPLETE。文件名采用playtest-[date].md模式例如production/qa/playtest-2026-04-06.md。同样的「May I write 完整路径」协议也出现在/bug-reportproduction/bugs/bug-[date]-[slug].md与/smoke-checkproduction/qa/smoke-[date].md的规格中是 CCGS 所有写文件类技能的通用约定见 CCGS Skill Testing Framework/CLAUDE.md 中「Asks May I write before any file writes」的协议合规要求。这份协议保证 Agent 永不静默写盘所有落盘动作都经过人类确认。五、行为测试用例全解5 个 Case 的验证逻辑规格文档的核心是五条行为测试用例。每条用例都给出 Fixture前置状态、输入、期望行为步骤与可勾选断言由/skill-test spec playtest-report逐条评估。下面逐例展开。Case 1Happy Path —— 用户提供笔记产出结构化报告Fixture用户粘贴单次会话的试玩笔记覆盖手感game feel、一个缺陷帧率下降、一个设计顾虑教程过长production/bugs/存在但为空缺陷尚未上报。期望行为技能读取笔记并归入四段式模板Feel/Accessibility 提取手感观察Bugs 记录帧率下降及其可复现细节Design Feedback 记录教程长度顾虑Next Steps 建议帧率问题 →/bug-report教程反馈 →/design-review询问May I write to production/qa/playtest-2026-04-06.md?批准后写入verdict 为 COMPLETE。断言报告含全部 4 个小节缺陷出现在 Bugs 小节而非 Design FeedbackNext Steps 与问题类型匹配写入前询问了「May I write」verdict 为 COMPLETE。这条用例是全部其他用例的基线验证的是技能「笔记 → 标准报告」的核心转换能力。Case 2Empty Input —— 空输入时的引导式提问Fixture调用时用户未提供任何笔记。期望行为技能检测到空输入按小节逐个引导提问Describe the overall feel and any accessibility observationsWere any bugs observed? Describe themWhat design feedback did testers provide?用户逐题作答技能根据答案汇编报告并询问「May I write」批准后写入verdict 为 COMPLETE。断言至少提出 3 个引导问题每个主小节一个在所有小节都有输入或用户明确跳过某个小节之前不生成报告文件写入后 verdict 为 COMPLETE。这条用例保证技能在输入缺失时不会产出残缺报告而是通过对话补齐信息——与 bug-report.md 的「Minimal Input」用例对缺失必填字段逐项追问采用了相同的补全策略。Case 3Multiple Testers —— 多测试者反馈聚合与多数/少数标记Fixture用户提供 3 位测试者的笔记2/3 认为操作「intuitive」1/3 认为 UI 字号过小3 人都遇到同一缺陷player stuck on ledge。期望行为技能识别出输入中的 3 个不同测试者视角操作直觉性 →Majority (2/3): controls intuitive字号问题 →Minority (1/3): UI font size concern卡平台缺陷 →All testers: player stuck on ledge (confirmed)生成带多数/少数标签的聚合报告「May I write」批准后写入verdict 为 COMPLETE。断言多数派意见2/3被标记为多数少数派意见1/3被标记为少数全员确认的缺陷标注为 confirmedverdict 为 COMPLETE。这是/playtest-report区别于简单「笔记整理」的关键能力它不只是转录而是有意识地做意见加权让设计者一眼看出哪些反馈是共识、哪些是单点意见。覆盖说明还明确匿名反馈沿用本用例的聚合模式只是去掉测试者标签。Case 4Bug Matches Existing Report —— 匹配既有 bug 报告并交叉引用Fixtureproduction/bugs/bug-2026-03-30-player-stuck-ledge.md已存在用户笔记描述「player gets stuck on ledges near walls」。期望行为技能结构化报告并识别出卡平台缺陷扫描production/bugs/找到bug-2026-03-30-player-stuck-ledge.mdBugs 小节写入See existing report: production/bugs/bug-2026-03-30-player-stuck-ledge.md技能不会建议为该问题新建 bug 报告报告写入verdict 为 COMPLETE。断言既有 bug 报告被找到并在玩测报告中给出链接已上报的问题不会再建议/bug-reportBugs 小节出现指向既有文件的交叉引用verdict 为 COMPLETE。这条用例验证的是技能的台账意识玩测报告不是孤立文档而是与production/bugs/缺陷库联动的节点。这里的设计意图是防止同一缺陷被反复上报、反复处理。Case 5Director Gate Check —— 无门禁CD-PLAYTEST 为独立调用Fixture用户提供了玩测笔记。期望行为技能生成并写入玩测报告不产生任何导演 Agent此处不调用 CD-PLAYTEST输出中不出现任何 gate ID。断言未调用任何导演门禁不出现 CD-PLAYTEST 的 skip 消息无需任何门禁检查即可达到 COMPLETE。这条用例把「文档工具」与「导演审阅」的边界固化成测试断言防止技能在未来迭代中无意引入门禁逻辑而破坏 utility 技能的定位。六、协议合规清单Protocol Compliance规格文档收尾的合规清单是这五条用例的浓缩也是每次评估的汇总检查项输出结构化为全部 4 个小节Feel、Bugs、Design Feedback、Next Steps多测试者场景下标记多数派与少数派意见缺陷与既有 bug 报告匹配时给出交叉引用写入前询问May I write to production/qa/playtest-[date].md?报告写入后 verdict 为 COMPLETE。对照模板skill-test-spec.md的通用合规要求——「May I write」前置、先呈现草稿再请求批准、以下一步建议收尾、不未经批准自动建文件——/playtest-report全部满足。七、覆盖边界与已知空白Coverage Notes规格诚实列出了三类未覆盖场景避免测试过度承诺CD-PLAYTEST 门禁创意总监对玩测洞察的设计影响评审是独立调用本规格不测试。如前所述creative-director.md 的 Coverage Notes 也承认该场景暂缺专用用例待 playtest-report 的结构化输出稳定后补充——两条规格互相印证了这一已知空白多媒体附件视频录制或截图附件不在测试范围内报告是纯文本文档匿名反馈无法识别测试者身份的场景遵循与 Case 3 相同的聚合模式只是省略测试者标签已说明但未单列用例。这份边界声明让读者能准确判断该技能「已验证什么、尚未验证什么」也展示了规格体系对待未知场景的态度——显式标注而非假装覆盖。八、如何执行测试从静态检查到行为验收/playtest-report的规格接入的是 CCGS Skill Testing Framework 的标准测试入口见 CCGS Skill Testing Framework/README.md# 结构合规检查7 项静态断言本规格的 Static Assertions 部分 /skill-test static playtest-report # 行为规格测试逐条评估上述 5 个 Case 与协议合规清单 /skill-test spec playtest-report # 类别指标评估对照 utility 类别的 U1/U2 指标quality-rubric.md /skill-test category playtest-report # 全量覆盖视图技能与 Agent 的 has-spec、上次测试时间与结果 /skill-test audit # 失败技能的改进循环测试 → 诊断 → 提议修复 → 重测 /skill-improve playtest-report运行流程遵循 CCGS Skill Testing Framework/CLAUDE.md 的规定先读catalog.yaml拿到技能的spec:路径与category:再读技能本体与规格文件逐用例评估断言最后询问是否将结果写入results/并更新catalog.yaml的last_spec/last_spec_result字段。/skill-test命令还提供static all检查全部 72 个技能与category all全类别指标扫描两种批量模式。九、小结一份规格如何支撑「试玩 → 缺陷 → 反馈」闭环回看整个设计/playtest-report的规格文档至少承担了三重职责行为契约用四段式模板 多数/少数聚合 缺陷去重交叉引用把「整理玩测记录」这件模糊的事固化为可断言的行为协作边界通过「无导演门禁」「CD-PLAYTEST 独立」「May I write 前置」「COMPLETE 判结」四条规则明确它是纯文档工具、是导演审阅CD-PLAYTEST的下游数据源而非替代品验收标准五条用例 协议合规清单 覆盖边界让任何人都能通过/skill-test spec playtest-report复现验证也让技能的每一次修改都有回归依据。对于要在自己的 CCGS 工作流中接入玩测环节的开发者这份规格本身就是最权威的「需求文档」报告该有什么结构、多测试者怎么加权、缺陷怎么去重、什么时候该写盘全部有据可查、有测试可跑。而对于想为框架贡献新 utility 技能的人skill-test-spec.md 模板与这份playtest-report规格互为参照后者可作为「文档整理类技能」的完整范例。【免费下载链接】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），仅供参考