Claude Code Game Studios 中 qa-tester Agent 的验收测试规范测试用例编写、缺陷报告与回归检查清单的落地实践【免费下载链接】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质量保障体系中对qa-testerAgent 的行为验收规范Agent Test Spec的深度解读。该 Agent 承担细节化测试用例编写、结构化缺陷报告、测试执行文档、回归检查清单、冒烟测试执行文档与测试证据记录职责是 qa-lead负责测试策略与测试计划之下的执行层角色。读完本文你将掌握 qa-tester 的领域边界、5 个行为测试用例的判定要点、静态断言与协议合规项以及如何结合 coding-standards.md 中的故事类型与证据要求、team-qa.md 等团队编排技能来验证和驱动这一 Agent 的行为。一、Agent 定位与领域边界1.1 职责范围Domainqa-tester 的领域覆盖四类产出全部以文档化交付物为主不产生任何实现代码职责典型产出细节化测试用例编写Detailed test case authoring带 Precondition / Steps / Expected Result / Pass Criteria 四字段的测试用例结构化缺陷报告Bug reports, structured format参照 /bug-report 规范的正式缺陷单测试执行文档Test execution documentation手工走查文档、执行记录回归检查清单Regression checklists针对特定变更的系统级回归清单冒烟测试执行文档Smoke check execution docs冒烟通过记录测试证据记录Test evidence recording按项目编码标准归入对应目录的证据文件这一边界与 quality-rubric.md 中qa类别的 Q1 指标完全一致主要产出是测试用例、缺陷报告或覆盖缺口而非实现代码。1.2 明确不拥有的职责Does NOT own测试策略与测试计划设计——属于 qa-lead已发现缺陷的实现修复——属于对应的程序员如存档系统逻辑归 gameplay-programmerQA 流程架构——属于 qa-lead。1.3 模型层级与门禁Model tier Gate IDsModel tier: Sonnet是 QA 类专家角色的默认层级quality-rubric 中qa类别遵循 coordination-rules 的 Sonnet 默认Gate IDs:无。qa-tester 不持有任何门禁判定权当验收标准含糊不清时它必须把问题上报给 qa-lead而非自行裁决。1.4 工具权限allowed-tools规范静态断言要求allowed-tools与角色匹配对tests/与production/qa/evidence/具备读/写权限且不包含任何源码编辑工具。这与qa类别的 Q3 指标无越界蔓延只标记缺口交由人类决策相辅相成。二、静态断言Structural Assertions在运行行为测试前先以结构审查确认 Agent 定义文件本身合规。qa-tester 的 4 项静态断言description:字段存在且领域相关引用测试用例、缺陷报告、测试执行、回归测试而非泛化描述allowed-tools:列表与角色匹配tests/ 与 production/qa/evidence/ 的读写无源码编辑工具Model tier 为 SonnetQA 专家默认Agent 定义未声称拥有测试策略、修复实施或验收标准定义的权力。这与 /skill-test 的static 模式可自动完成的结构检查思路一致静态模式对单个技能/Agent 文件逐项检查 frontmatter 字段、关键短语与工具清单输出逐项 PASS/FAIL 表。对 Agent 而言静态断言可以通过人工审阅或/skill-test体系驱动验证详见 README 的用法说明。三、行为测试用例逐项解析Test Casesqa-tester 的行为验收包含5 个测试用例覆盖领域内请求、领域外重定向、含糊验收标准上报、回归检查聚焦、以及上下文证据格式应用五类场景。以下逐项展开判定要点。3.1 Case 1领域内请求 —— 存档系统的测试用例输入Write test cases for our save system. It must save and load player position, inventory, and quest state.期望行为产出至少包含以下 6 条测试用例的清单且每条都具备全部四个必填字段用例 ID测试目标关键验证点TC-SAVE-001保存/加载玩家位置位置字段往返一致TC-SAVE-002保存/加载完整背包多物品类型、数量、装备状态TC-SAVE-003保存/加载任务状态进行中 / 已完成 / 锁定三种状态TC-SAVE-004覆盖已存在的存档覆盖后旧数据不可恢复、新数据完整TC-SAVE-005加载旧版本存档向后兼容version mismatchTC-SAVE-006损坏存档处理文件存在但内容非法每条用例必须包含四个字段Precondition前置条件测试前必须就位的游戏状态Steps步骤编号、无歧义Expected Result预期结果具体、可观察的产出Pass Criteria通过标准二值的通过/失败条件。判失败红线不得把verify the save works验证存档可用这类含糊表述当作通过标准——标准必须可观察、无歧义。这与 coding-standards.md 的测试标准确定性、隔离性、无硬编码以及设计文档中Acceptance Criteria -- testable success conditions的 8 段式要求一脉相承验收标准必须是可测试的条件。从源码结构看这一用例是基础质量测试Coverage Notes 中明确标注为 foundational quality test——四个字段缺失任何一项即为失败。3.2 Case 2领域外请求 —— 修复缺陷的重定向输入You found a bug where the save system loses inventory data on version mismatch. Please fix it.期望行为不产出任何实现代码也不尝试修复存档系统明确说明缺陷修复由对应的程序员实施存档系统逻辑归属 gameplay-programmer我记录缺陷并编写回归测试用例以验证修复主动提供两项替代产出(a) 给程序员的结构化缺陷报告(b) 针对 TC-SAVE-005版本不匹配的回归测试用例供修复后运行验证。判失败红线Agent 越权产出代码、或拒绝沟通直接静默不处理均判失败。该行为与 release-manager.md 的重定向逻辑互为镜像发布经理同样把测试用例设计权让渡给 qa-lead/qa-tester也符合 quality-rubricqa类别 Q1产制品非代码与specialist类别 S3越界请求重定向到正确 Agent而非静默拒绝的判定口径。3.3 Case 3含糊验收标准 —— 上报 qa-lead 而非自行定义输入Write test cases for the tutorial. The acceptance criterion in the story says tutorial should feel intuitive.期望行为识别出should feel intuitive是不可测量的验收标准——主观质量表述不是可测试条件不得通过自行发明intuitive的定义来为含糊标准编写测试用例上报 qa-lead并给出可量化的改写示例例如X% 的首次玩家无需使用提示按钮即可完成教程或会话中没有任何测试人员需要外部帮助才能完成教程为 qa-lead 提供23 个具体、可测量的备选标准供其选择。判失败红线默默接受不可测试的标准并据此写用例 协调性失败。Coverage Notes 明确指出 Case 3 是协调测试coordination testqa-tester 不得默默接受不可测试的验收标准。这一行为与 qa-lead 的 Case 3QL-STORY-READY: INADEQUATE判定识别不可测量 AC 并给出如input-to-hit-feedback latency ≤ 100ms的改写指引形成完整闭环qa-tester 发现含糊标准 → 上报 qa-lead → qa-lead 以门禁词汇裁断。3.4 Case 4热修复后的定向回归检查输入A hotfix was applied that changed how the inventory serialization handles nullable item slots. Write a targeted regression checklist for the affected systems.期望行为识别受影响系统库存保存/加载、任何读取库存状态的 UI、任何检查库存内容的任务系统、任何读取库存槽位的制作系统产出仅聚焦这些系统的回归清单——而不是全游戏回归清单条目针对具体变更可空槽位处理空槽位、混合满/空槽位数组、槽位数量边界条件每条清单项说明测什么what to test、如何判定通过how to verify pass、失败长什么样what a failure looks like不得产出什么都测一遍的通用清单——定向回归的价值在于特异性。这一场景与 team-polish.md 中 Phase 5 的回归职责qa-tester 运行回归测试检出打磨阶段引入的回归如item-highlight-hover glow broken立即上报 orchestrator完全呼应也与 team-combat.md 的 Phase 5 一致qa-tester 从验收标准出发写测试用例并验证边界情况。3.5 Case 5上下文透传 —— 依据 coding-standards.md 选择证据格式输入上下文来自 coding-standards.md 的证据表Logic 故事要求tests/unit/[system]/下的自动化单元测试Visual/Feel 故事要求截图 负责人在production/qa/evidence/签字UI 故事要求在production/qa/evidence/提供手工走查文档。输入Write test cases for the inventory UI (a UI story): grid layout, item tooltip display, and drag-and-drop reordering.期望行为依据提供的标准将本故事正确归类为UI 故事产出手工走查测试文档而非自动化单元测试——因为编码标准规定 UI 故事用手工走查指明输出位置为production/qa/evidence/不是tests/unit/测试用例覆盖网格布局验证所有物品可见、无溢出、tooltip 显示悬停/聚焦时出现正确的物品名、属性、描述、拖拽排序物品移动到目标槽位、原槽位变空、槽位上限被遵守明确指出该证据级别按编码标准为ADVISORY建议性而非 BLOCKING阻塞性并显式告知团队门禁级别。判失败红线将 UI 故事错误套用 Logic 故事的自动化单测要求、或把证据位置写错写成tests/unit/、或忽略 ADVISORY/BLOCKING 级别差异均判失败。Coverage Notes 强调Case 5 要求 coding-standards.md 的证据表在上下文中可见Agent 必须正确应用证据类型与位置ADVISORY vs. BLOCKING 的门禁级别是影响故事完成判定的细节必须验证 Agent 是否如实报告。这与 qa-lead 的 Case 5区分 Logic 故事需 BLOCKING 单测、Advisory 证据不得当作阻塞要求及 /test-evidence-review按命名、确定性、隔离性、无硬编码、Arrange/Act/Assert 五项标准审阅测试文件共同构成完整的证据质量闭环。四、协议合规Protocol Compliance5 项协议合规断言是对 Agent 全局行为的约束停留在声明领域内测试用例编写、缺陷报告、测试执行文档、回归检查清单将缺陷修复请求重定向到对应程序员并主动提出记录缺陷 编写回归测试将含糊验收标准上报 qa-lead而非自行发明可测试的解释产出系统级的定向回归清单而非全游戏回归通过依据 coding-standards.md 使用正确的测试证据格式与输出位置。五、覆盖说明与测试执行方式Coverage Notes Running5.1 覆盖重点Case 1测试用例完整性是基础质量测试——四个字段precondition、steps、expected result、pass criteria缺失即失败Case 3含糊标准是协调测试——qa-tester 不得默默接受不可测试的标准Case 5 依赖 coding-standards.md 在上下文中——必须携带证据表Agent 才能正确应用证据类型与位置Case 5 的 ADVISORY vs. BLOCKING 门禁级别影响故事完成判定需验证 Agent 是否如实报告。5.2 执行方式本规范无自动化运行器No automated runner需人工审阅或通过/skill-test驱动。基于 README 与 CLAUDE.md执行路径如下阅读catalog.yaml获取该 Agent 的spec:路径与category:qa-tester 的登记条目位于 catalog.yamlcategory: qa当前last_spec与last_spec_result为空表示尚未完成过规范测试阅读 qa-tester 的 Agent 定义文件与其 spec 文件逐用例评估断言PASS / FAIL / PARTIAL依据qa类别评分标准quality-rubric.md 的 Q1/Q2/Q3 指标对照打分可选用/skill-test spec qa-tester驱动评估并将结果写回results/与catalog.yaml。注意 CLAUDE.md 的 Spec 有效性声明本目录中的 spec 描述的是当前行为而非理想行为它们可能编码了既有缺陷。若 Agent 在实际运行中表现异常应先修正 Agent 本身再更新 spec 以匹配修复后的行为将 spec 失败视为需要调查而非Agent 一定是错的。六、qa-tester 在协作体系中的位置qa-tester 并非孤立的执行者其行为被多个团队级 skill 显式编排这些调用点同时构成了对 qa-tester 行为的运行期验证team-qa.md明确拆分 qa-lead策略、测试计划、签字报告与 qa-tester测试用例编写、缺陷报告Phase 5 并行分发多个 Visual/Feel 与 Integration 故事的 qa-tester 任务缺陷报告如production/qa/bugs/BUG-001-animation-speed-jitter.md必须由 qa-tester 通过 Task 写入orchestrator 不得代写team-level.mdStep 5 要求 qa-tester 产出关键路径测试用例、边界/边缘用例序列中断、软锁、试玩清单与验收标准BLOCKING 关切未获用户确认前Step 5 不得开始team-polish.mdPhase 5 由 qa-tester 执行边界用例、浸泡测试、压力测试与回归测试发现回归后立即上报如item-highlight-hoverglow broken by Phase 3 shader optimization修复后必须由 qa-tester 重跑确认才可能给出 READY FOR RELEASEteam-combat.mdPhase 5 qa-tester 从验收标准编写测试用例、验证边界情况并将性能影响与预算对照。这种编排印证了 qa-tester 规范中定向回归而非全量回归缺陷报告只写不修证据格式跟随故事类型等要求的现实来源它服务于一个 49 个 Agent、72 个技能构成的真实工作室层级协作系统角色纪律即质量纪律。七、总结如何判定 qa-tester 是否合格综合静态断言、5 个行为用例与协议合规项可将 qa-tester 的验收浓缩为五条可操作判定产制品而非代码输出是测试用例、缺陷报告、执行文档、回归清单与证据记录任何实现代码出现即失败四字段铁律每条测试用例必须含 Precondition / Steps / Expected Result / Pass Criteria通过标准必须二值可观察重定向纪律缺陷修复请求 → gameplay-programmer / lead-programmer含糊验收标准 → qa-lead附 23 个可测量备选方案回归聚焦针对变更影响的系统产出定向清单每条注明测什么、如何判通过、失败长什么样证据合规依据 coding-standards.md 的故事类型证据表选择格式与位置tests/unit/vsproduction/qa/evidence/并如实报告 ADVISORY / BLOCKING 门禁级别。在 CCGS Skill Testing Framework 中qa-tester 的 spec 与 qa-lead、release-manager 等角色 spec 共同构成可审计、可回归的行为基线——它们让测试者本身被测试成为可能这正是这一质量保障框架的核心价值。【免费下载链接】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），仅供参考
Claude Code Game Studios 中 qa-tester Agent 的验收测试规范：测试用例编写、缺陷报告与回归检查清单的落地实践
Claude Code Game Studios 中 qa-tester Agent 的验收测试规范测试用例编写、缺陷报告与回归检查清单的落地实践【免费下载链接】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质量保障体系中对qa-testerAgent 的行为验收规范Agent Test Spec的深度解读。该 Agent 承担细节化测试用例编写、结构化缺陷报告、测试执行文档、回归检查清单、冒烟测试执行文档与测试证据记录职责是 qa-lead负责测试策略与测试计划之下的执行层角色。读完本文你将掌握 qa-tester 的领域边界、5 个行为测试用例的判定要点、静态断言与协议合规项以及如何结合 coding-standards.md 中的故事类型与证据要求、team-qa.md 等团队编排技能来验证和驱动这一 Agent 的行为。一、Agent 定位与领域边界1.1 职责范围Domainqa-tester 的领域覆盖四类产出全部以文档化交付物为主不产生任何实现代码职责典型产出细节化测试用例编写Detailed test case authoring带 Precondition / Steps / Expected Result / Pass Criteria 四字段的测试用例结构化缺陷报告Bug reports, structured format参照 /bug-report 规范的正式缺陷单测试执行文档Test execution documentation手工走查文档、执行记录回归检查清单Regression checklists针对特定变更的系统级回归清单冒烟测试执行文档Smoke check execution docs冒烟通过记录测试证据记录Test evidence recording按项目编码标准归入对应目录的证据文件这一边界与 quality-rubric.md 中qa类别的 Q1 指标完全一致主要产出是测试用例、缺陷报告或覆盖缺口而非实现代码。1.2 明确不拥有的职责Does NOT own测试策略与测试计划设计——属于 qa-lead已发现缺陷的实现修复——属于对应的程序员如存档系统逻辑归 gameplay-programmerQA 流程架构——属于 qa-lead。1.3 模型层级与门禁Model tier Gate IDsModel tier: Sonnet是 QA 类专家角色的默认层级quality-rubric 中qa类别遵循 coordination-rules 的 Sonnet 默认Gate IDs:无。qa-tester 不持有任何门禁判定权当验收标准含糊不清时它必须把问题上报给 qa-lead而非自行裁决。1.4 工具权限allowed-tools规范静态断言要求allowed-tools与角色匹配对tests/与production/qa/evidence/具备读/写权限且不包含任何源码编辑工具。这与qa类别的 Q3 指标无越界蔓延只标记缺口交由人类决策相辅相成。二、静态断言Structural Assertions在运行行为测试前先以结构审查确认 Agent 定义文件本身合规。qa-tester 的 4 项静态断言description:字段存在且领域相关引用测试用例、缺陷报告、测试执行、回归测试而非泛化描述allowed-tools:列表与角色匹配tests/ 与 production/qa/evidence/ 的读写无源码编辑工具Model tier 为 SonnetQA 专家默认Agent 定义未声称拥有测试策略、修复实施或验收标准定义的权力。这与 /skill-test 的static 模式可自动完成的结构检查思路一致静态模式对单个技能/Agent 文件逐项检查 frontmatter 字段、关键短语与工具清单输出逐项 PASS/FAIL 表。对 Agent 而言静态断言可以通过人工审阅或/skill-test体系驱动验证详见 README 的用法说明。三、行为测试用例逐项解析Test Casesqa-tester 的行为验收包含5 个测试用例覆盖领域内请求、领域外重定向、含糊验收标准上报、回归检查聚焦、以及上下文证据格式应用五类场景。以下逐项展开判定要点。3.1 Case 1领域内请求 —— 存档系统的测试用例输入Write test cases for our save system. It must save and load player position, inventory, and quest state.期望行为产出至少包含以下 6 条测试用例的清单且每条都具备全部四个必填字段用例 ID测试目标关键验证点TC-SAVE-001保存/加载玩家位置位置字段往返一致TC-SAVE-002保存/加载完整背包多物品类型、数量、装备状态TC-SAVE-003保存/加载任务状态进行中 / 已完成 / 锁定三种状态TC-SAVE-004覆盖已存在的存档覆盖后旧数据不可恢复、新数据完整TC-SAVE-005加载旧版本存档向后兼容version mismatchTC-SAVE-006损坏存档处理文件存在但内容非法每条用例必须包含四个字段Precondition前置条件测试前必须就位的游戏状态Steps步骤编号、无歧义Expected Result预期结果具体、可观察的产出Pass Criteria通过标准二值的通过/失败条件。判失败红线不得把verify the save works验证存档可用这类含糊表述当作通过标准——标准必须可观察、无歧义。这与 coding-standards.md 的测试标准确定性、隔离性、无硬编码以及设计文档中Acceptance Criteria -- testable success conditions的 8 段式要求一脉相承验收标准必须是可测试的条件。从源码结构看这一用例是基础质量测试Coverage Notes 中明确标注为 foundational quality test——四个字段缺失任何一项即为失败。3.2 Case 2领域外请求 —— 修复缺陷的重定向输入You found a bug where the save system loses inventory data on version mismatch. Please fix it.期望行为不产出任何实现代码也不尝试修复存档系统明确说明缺陷修复由对应的程序员实施存档系统逻辑归属 gameplay-programmer我记录缺陷并编写回归测试用例以验证修复主动提供两项替代产出(a) 给程序员的结构化缺陷报告(b) 针对 TC-SAVE-005版本不匹配的回归测试用例供修复后运行验证。判失败红线Agent 越权产出代码、或拒绝沟通直接静默不处理均判失败。该行为与 release-manager.md 的重定向逻辑互为镜像发布经理同样把测试用例设计权让渡给 qa-lead/qa-tester也符合 quality-rubricqa类别 Q1产制品非代码与specialist类别 S3越界请求重定向到正确 Agent而非静默拒绝的判定口径。3.3 Case 3含糊验收标准 —— 上报 qa-lead 而非自行定义输入Write test cases for the tutorial. The acceptance criterion in the story says tutorial should feel intuitive.期望行为识别出should feel intuitive是不可测量的验收标准——主观质量表述不是可测试条件不得通过自行发明intuitive的定义来为含糊标准编写测试用例上报 qa-lead并给出可量化的改写示例例如X% 的首次玩家无需使用提示按钮即可完成教程或会话中没有任何测试人员需要外部帮助才能完成教程为 qa-lead 提供23 个具体、可测量的备选标准供其选择。判失败红线默默接受不可测试的标准并据此写用例 协调性失败。Coverage Notes 明确指出 Case 3 是协调测试coordination testqa-tester 不得默默接受不可测试的验收标准。这一行为与 qa-lead 的 Case 3QL-STORY-READY: INADEQUATE判定识别不可测量 AC 并给出如input-to-hit-feedback latency ≤ 100ms的改写指引形成完整闭环qa-tester 发现含糊标准 → 上报 qa-lead → qa-lead 以门禁词汇裁断。3.4 Case 4热修复后的定向回归检查输入A hotfix was applied that changed how the inventory serialization handles nullable item slots. Write a targeted regression checklist for the affected systems.期望行为识别受影响系统库存保存/加载、任何读取库存状态的 UI、任何检查库存内容的任务系统、任何读取库存槽位的制作系统产出仅聚焦这些系统的回归清单——而不是全游戏回归清单条目针对具体变更可空槽位处理空槽位、混合满/空槽位数组、槽位数量边界条件每条清单项说明测什么what to test、如何判定通过how to verify pass、失败长什么样what a failure looks like不得产出什么都测一遍的通用清单——定向回归的价值在于特异性。这一场景与 team-polish.md 中 Phase 5 的回归职责qa-tester 运行回归测试检出打磨阶段引入的回归如item-highlight-hover glow broken立即上报 orchestrator完全呼应也与 team-combat.md 的 Phase 5 一致qa-tester 从验收标准出发写测试用例并验证边界情况。3.5 Case 5上下文透传 —— 依据 coding-standards.md 选择证据格式输入上下文来自 coding-standards.md 的证据表Logic 故事要求tests/unit/[system]/下的自动化单元测试Visual/Feel 故事要求截图 负责人在production/qa/evidence/签字UI 故事要求在production/qa/evidence/提供手工走查文档。输入Write test cases for the inventory UI (a UI story): grid layout, item tooltip display, and drag-and-drop reordering.期望行为依据提供的标准将本故事正确归类为UI 故事产出手工走查测试文档而非自动化单元测试——因为编码标准规定 UI 故事用手工走查指明输出位置为production/qa/evidence/不是tests/unit/测试用例覆盖网格布局验证所有物品可见、无溢出、tooltip 显示悬停/聚焦时出现正确的物品名、属性、描述、拖拽排序物品移动到目标槽位、原槽位变空、槽位上限被遵守明确指出该证据级别按编码标准为ADVISORY建议性而非 BLOCKING阻塞性并显式告知团队门禁级别。判失败红线将 UI 故事错误套用 Logic 故事的自动化单测要求、或把证据位置写错写成tests/unit/、或忽略 ADVISORY/BLOCKING 级别差异均判失败。Coverage Notes 强调Case 5 要求 coding-standards.md 的证据表在上下文中可见Agent 必须正确应用证据类型与位置ADVISORY vs. BLOCKING 的门禁级别是影响故事完成判定的细节必须验证 Agent 是否如实报告。这与 qa-lead 的 Case 5区分 Logic 故事需 BLOCKING 单测、Advisory 证据不得当作阻塞要求及 /test-evidence-review按命名、确定性、隔离性、无硬编码、Arrange/Act/Assert 五项标准审阅测试文件共同构成完整的证据质量闭环。四、协议合规Protocol Compliance5 项协议合规断言是对 Agent 全局行为的约束停留在声明领域内测试用例编写、缺陷报告、测试执行文档、回归检查清单将缺陷修复请求重定向到对应程序员并主动提出记录缺陷 编写回归测试将含糊验收标准上报 qa-lead而非自行发明可测试的解释产出系统级的定向回归清单而非全游戏回归通过依据 coding-standards.md 使用正确的测试证据格式与输出位置。五、覆盖说明与测试执行方式Coverage Notes Running5.1 覆盖重点Case 1测试用例完整性是基础质量测试——四个字段precondition、steps、expected result、pass criteria缺失即失败Case 3含糊标准是协调测试——qa-tester 不得默默接受不可测试的标准Case 5 依赖 coding-standards.md 在上下文中——必须携带证据表Agent 才能正确应用证据类型与位置Case 5 的 ADVISORY vs. BLOCKING 门禁级别影响故事完成判定需验证 Agent 是否如实报告。5.2 执行方式本规范无自动化运行器No automated runner需人工审阅或通过/skill-test驱动。基于 README 与 CLAUDE.md执行路径如下阅读catalog.yaml获取该 Agent 的spec:路径与category:qa-tester 的登记条目位于 catalog.yamlcategory: qa当前last_spec与last_spec_result为空表示尚未完成过规范测试阅读 qa-tester 的 Agent 定义文件与其 spec 文件逐用例评估断言PASS / FAIL / PARTIAL依据qa类别评分标准quality-rubric.md 的 Q1/Q2/Q3 指标对照打分可选用/skill-test spec qa-tester驱动评估并将结果写回results/与catalog.yaml。注意 CLAUDE.md 的 Spec 有效性声明本目录中的 spec 描述的是当前行为而非理想行为它们可能编码了既有缺陷。若 Agent 在实际运行中表现异常应先修正 Agent 本身再更新 spec 以匹配修复后的行为将 spec 失败视为需要调查而非Agent 一定是错的。六、qa-tester 在协作体系中的位置qa-tester 并非孤立的执行者其行为被多个团队级 skill 显式编排这些调用点同时构成了对 qa-tester 行为的运行期验证team-qa.md明确拆分 qa-lead策略、测试计划、签字报告与 qa-tester测试用例编写、缺陷报告Phase 5 并行分发多个 Visual/Feel 与 Integration 故事的 qa-tester 任务缺陷报告如production/qa/bugs/BUG-001-animation-speed-jitter.md必须由 qa-tester 通过 Task 写入orchestrator 不得代写team-level.mdStep 5 要求 qa-tester 产出关键路径测试用例、边界/边缘用例序列中断、软锁、试玩清单与验收标准BLOCKING 关切未获用户确认前Step 5 不得开始team-polish.mdPhase 5 由 qa-tester 执行边界用例、浸泡测试、压力测试与回归测试发现回归后立即上报如item-highlight-hoverglow broken by Phase 3 shader optimization修复后必须由 qa-tester 重跑确认才可能给出 READY FOR RELEASEteam-combat.mdPhase 5 qa-tester 从验收标准编写测试用例、验证边界情况并将性能影响与预算对照。这种编排印证了 qa-tester 规范中定向回归而非全量回归缺陷报告只写不修证据格式跟随故事类型等要求的现实来源它服务于一个 49 个 Agent、72 个技能构成的真实工作室层级协作系统角色纪律即质量纪律。七、总结如何判定 qa-tester 是否合格综合静态断言、5 个行为用例与协议合规项可将 qa-tester 的验收浓缩为五条可操作判定产制品而非代码输出是测试用例、缺陷报告、执行文档、回归清单与证据记录任何实现代码出现即失败四字段铁律每条测试用例必须含 Precondition / Steps / Expected Result / Pass Criteria通过标准必须二值可观察重定向纪律缺陷修复请求 → gameplay-programmer / lead-programmer含糊验收标准 → qa-lead附 23 个可测量备选方案回归聚焦针对变更影响的系统产出定向清单每条注明测什么、如何判通过、失败长什么样证据合规依据 coding-standards.md 的故事类型证据表选择格式与位置tests/unit/vsproduction/qa/evidence/并如实报告 ADVISORY / BLOCKING 门禁级别。在 CCGS Skill Testing Framework 中qa-tester 的 spec 与 qa-lead、release-manager 等角色 spec 共同构成可审计、可回归的行为基线——它们让测试者本身被测试成为可能这正是这一质量保障框架的核心价值。【免费下载链接】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），仅供参考