Claude Code Game Studios 质量评分标准：如何为不同技能类别定义 PASS/FAIL 指标（完整指南）-创锋一号

Claude Code Game Studios 质量评分标准：如何为不同技能类别定义 PASS/FAIL 指标（完整指南）

【免费下载链接】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 Studios 把一个 Claude Code 会话变成拥有 49 个 AI 代理、72 个工作流技能的游戏开发工作室。它的 quality-rubric.md 定义了一套质量评分标准：为 9 个技能类别和 6 个 Agent 角色类别，各定义 4~5 条二元 PASS/FAIL 指标，用/skill-test category一键打分。本文带你读懂这套评分体系，并学会为自己的技能类别定义专属的 PASS/FAIL 指标。

Claude Code Game Studios 质量评分标准与 PASS/FAIL 指标分类表

为什么需要「分类别」的评分标准

通用检查只能回答"技能文件格式对不对"，回答不了"它做本职的事够不够好"。比如：

分析类技能（如 code-review）的核心红线是"只读"——扫描阶段绝不能写文件；
门控类技能（gate-check）的核心红线是"不自动推进阶段"——未经用户确认不能写production/stage.txt；
团队类技能（team-combat 等）的核心红线是"阻塞必须立即上报"——不能静默跳过失败。

同一把尺子量不出这些差异。所以 CCGS 的思路是：每类技能有自己"岗位说明书"式的指标，评分时逐条打 PASS/FAIL，而不是给一个模糊的总分。

三级判定体系：PASS / FAIL / WARN 如何打

评分采用三级判定，规则定义在 quality-rubric.md 开头：

判定	含义
PASS	技能的书面说明清楚满足了该条标准
FAIL	说明缺失、含糊，或自相矛盾
WARN	部分满足，需要人工关注

💡 关键设计：指标是二元的、基于文本的。评分对象是"技能文件里写没写清楚"，而不是让它跑一遍看输出——所以整轮评分可以自动执行、可以反复执行，结果稳定可对比。

9 个技能类别各自的 PASS/FAIL 指标

下面按类别速览（完整原文见 quality-rubric.md）：

gate 门控类：守住阶段流转的 5 项检查

编号	指标	一句话标准
G1	读取评审模式	决定派哪些导演前，先读`production/session-state/review-mode.txt`
G2	full 模式齐人	full 模式下 4 位 Tier-1 导演的 PHASE-GATE 并行触发
G3	lean 模式精简	lean 模式只跑 PHASE-GATE，跳过内联闸门
G4	solo 模式放行	solo 模式不派任何导演闸门，且逐条记录"skipped — Solo mode"
G5	不自动推进	未经用户明确确认，绝不写`production/stage.txt`

review 评审类：只读 + 结构化结论

编号	指标	一句话标准
R1	只读执行	未经用户批准不改被评审文档，所有写操作挂在 "May I write" 之后
R2	8 节覆盖	明确评估 GDD 的全部 8 个必备章节
R3	结论词汇正确	只能输出 APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED（设计）或 PASS / CONCERNS / FAIL（架构）
R4	分析期不派闸门	分析阶段不触发导演闸门（architecture-review 在分析后触发属例外，已注明理由）
R5	结构化发现	最终结论前必须给出逐章节状态表或清单

authoring 写作类：逐节确认，骨架先行

编号	指标	一句话标准
A1	逐节循环	完整写作技能一节一节产出并请求批准；轻量技能可用单稿模式
A2	逐节确认	每节写入前问 "May I write this to [filepath]?"
A3	改造模式	目标文件已存在时，提供"更新指定章节"而不是整篇覆盖
A4	闸门层级正确	导演闸门在 full/lean 阈值下运行，solo 不触发
A5	骨架先行	先建含全部章节标题的文件骨架，防止会话中断丢失进度

readiness 就绪类：多维度、三级结论

编号	指标	一句话标准
RD1	多维检查	检查 ≥3 个独立维度（Design / Architecture / Scope / DoD）并分别报告
RD2	三级结论	READY/COMPLETE > NEEDS WORK > BLOCKED 的层级清晰
RD3	BLOCKED 有边界	只保留给"作者自己修不了"的问题（如需新增 ADR、依赖无法解决）
RD4	闸门模式正确	QL-STORY-READY 闸门在 full 模式触发，lean/solo 跳过并注明
RD5	下一棒交接	完成后自动浮现当前 Sprint 里下一个 READY 故事

pipeline 流水线类：产出物格式与顺序

编号	指标	一句话标准
P1	输出 Schema 正确	每个产出文件遵循项目模板（EPIC.md、story frontmatter 等）
P2	层级/优先级顺序	Epic/Story 遵循 core → extended → meta 层级与优先级字段
P3	逐件确认	每个产出文件单独问 "May I write [artifact]?"，不批量批准
P4	闸门层级正确	对应闸门在 full 运行、lean/solo 跳过并注明
P5	先读后写	产出前先读相关 GDD/ADR/manifest 确保对齐

analysis 分析类：只读是最高准则

编号	指标	一句话标准
AN1	只读扫描	分析阶段只使用 Read/Glob/Grep 工具
AN2	结构化发现表	输出带严重度/优先级的表格或清单，而不是纯散文
AN3	不自动写文件	任何建议写入（如 tech-debt 登记）都挂在 "May I write" 之后
AN4	分析期不派闸门	分析技能不触发导演闸门，发现留给人类判断

team 团队协作类：并行与阻塞上报

编号	指标	一句话标准
T1	指名代理	明确写出要派哪些代理、什么顺序
T2	独立则并行	输入互不依赖的代理在单条消息里并行派出
T3	BLOCKED 立即上报	任一代理阻塞就停下依赖工作，绝不静默跳过
T4	收齐再推进	依赖阶段等所有并行代理完成后再继续
T5	缺参即停	缺少必填参数时只输出用法提示，不派代理

sprint 冲刺类：读数据、有闸门、结构化

编号	指标	一句话标准
SP1	先读状态	产出前读`production/sprints/`或`production/milestones/`
SP2	正确闸门	规划用 PR-SPRINT、里程碑审评用 PR-MILESTONE，full 运行、lean/solo 跳过
SP3	结构化输出	速度表、风险清单、行动项，而非自由发挥
SP4	不自动落盘	未经 "May I write" 不写任何冲刺/里程碑记录

utility 工具类：先过硬指标

utility 类（start、help、brainstorm 等剩余技能）指标最简：

U1—/skill-test static [name]返回 COMPLIANT 且 0 个 FAIL（通过全部 7 项静态检查）；
U2— 若该技能恰好会派导演闸门，其 full/lean/solo 模式逻辑必须正确。

Agent 角色类别的评分标准

同一份评分标准文件还覆盖了 6 类 Agent（agents/ 下每层都有行为规范）：

类别	核心指标
director（导演）	D1 返回 APPROVE / CONCERNS / REJECT；D2 不越域做绑定决定；D3 冲突升级到共同上级；D4 使用 Opus 模型档位
lead（主管）	L1 返回领域判定（如 FEASIBLE/INFEASIBLE、PASS/FAIL）；L2 越域冲突升级；L3 使用 Sonnet 档位
specialist（专家）	S1 守住自己领域；S2 不跨域做单方决定；S3 正确转交而不是静默拒绝
engine（引擎专家）	E1 建议 API 前先查 docs/engine-reference/ 的版本；E2 按文件类型路由到正确子专家（如`.gdshader`→ shader 专家）；E3 强制引擎惯用法
qa（质量）	Q1 产出测试用例/缺陷报告而非实现代码；Q2 符合测试证据格式；Q3 不提议新功能
operations（运营）	O1 领域所有权清晰；O2 不写游戏逻辑；O3 allowed-tools 与运营角色匹配

📌 注意 director 的 D1：producer 的等价词汇是 REALISTIC / CONCERNS / UNREALISTIC——指标允许"领域等价"，但词汇表必须封闭，这样评分才能客观。

如何用 /skill-test category 运行评分

整套评分由 /skill-test 驱动，在 Claude Code 中执行：

命令	作用
`/skill-test static [name\\|all]`	结构合规检查（7 项静态断言）
`/skill-test spec [name]`	对照行为规范逐用例评估
`/skill-test category [name\\|all]`	对照 quality-rubric.md 的类别指标打分（本文主题）
`/skill-test audit`	查看全部 72 技能 + 49 Agent 的测试覆盖总览
`/skill-improve [name]`	未通过时的修复循环：测试 → 诊断 → 提案 → 复测

以category模式为例，它会：

读 catalog.yaml 拿到该技能的类别和 spec 路径；
读 quality-rubric.md 中对应类别的指标表；
逐条给出 PASS / WARN / FAIL 及依据；
汇总判定：全 PASS →COMPLIANT，有 WARN →WARNINGS，有 FAIL →NON-COMPLIANT；
提示把结果写回 catalog.yaml 的last_category/last_category_result字段，保持覆盖追踪。

💡 评分标准里还有一条元规则：规范描述的是当前行为而非理想行为，所以指标未通过应先视为"需要调查"，修正技能后再更新规范。

如何为自己的技能类别定义 PASS/FAIL 指标

想新增一个类别或调整指标？照抄这套模板的做法：

先写"岗位一句话"：参照 quality-rubric.md 每个类别开头的那段描述，用一句话说清这类技能的职责边界（gate 管阶段流转、analysis 只读出报告……）。
指标写成"主语 + 可观察行为 + 边界"句式：例如"技能在分析阶段只使用 Read/Glob/Grep 工具"——可观察、可对着文本判 PASS/FAIL；避免"表现良好"这类模糊词。
数量保持 4~5 条：覆盖"读什么、写什么、什么时候停、怎么报结果"即可，多了难以维护。
给例外留位置：每个类别表格后都有 Exceptions 注释（如 design-review 因"Revise now"路径拥有 Write 工具仍算 R1 通过）。写清例外理由，评分才不会误杀。
注册到目录：在 catalog.yaml 中登记技能的category与spec路径，规范文件放在 skills/ 对应子目录，写法参考模板 templates/skill-test-spec.md。

小结

质量评分标准 =每类岗位一张 4~5 条的二元指标表，评分对象是"技能写没写清楚"，可自动执行、可重复对比；
三级判定 PASS / FAIL / WARN 让"部分满足"有独立位置，不逼评分二选一；
/skill-test category all一键跑完 9 个类别，结果写回 catalog.yaml 形成覆盖追踪；
这套框架完全自包含：整个 CCGS Skill Testing Framework/ 文件夹删掉也不影响主框架运行。

理解并复用这套"分类别定指标"的思路，你也能给自己的 AI 工作流建立起同样客观、可回归的质量底线。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析