Claude-Code-Game-Studios 原型代码标准实战：在宽松迭代与生产隔离之间保持平衡

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-Studios 仓库中.claude/rules/prototype-code.md所定义的原型代码标准（Prototype Code Standards，宽松模式）。该标准为prototypes/**路径下的临时验证代码划定了明确的"宽松边界"：允许硬编码、允许全局状态、允许复制粘贴，但强制要求目录隔离、README 记录假设与结论、严禁与生产代码互相引用。读完本文，你将掌握在 Claude Code 驱动的游戏开发流程中如何用最快速度验证玩法假设，同时确保原型永远不会悄悄"长成"生产代码，并理解该标准与prototyperAgent、/prototypeSkill、worktree 隔离机制之间的完整协作链路。

一、规则文件在仓库中的定位

Claude-Code-Game-Studios 是一个把 Claude Code 组织成完整游戏工作室的仓库：49 个 AI Agent、72 个工作流技能以及一套镜像真实工作室层级关系的协调系统。其中，.claude/rules/目录存放的是路径驱动的规则文件——当 AI 编辑匹配路径下的文件时，对应规则会被自动强制执行。

根据 rules-reference.md 中的规则映射表：

可以看到，prototype-code.md是与src/下生产代码规则（gameplay-code、engine-code、network-code、ui-code 等）并列但基调相反的一套规则：生产代码追求工程严格性，原型代码则刻意放松标准以换取迭代速度。这份文件开头的 frontmatter：

paths: - "prototypes/**"

表明它只在prototypes/**路径下生效——这是整个宽松策略的第一道护栏：宽松只存在于隔离区域内。

二、核心设计哲学：目标不是工程质量，而是学习

规则文件第一段即点明立场：

Prototypes are throwaway code for validating ideas. Standards are intentionally relaxed to maximize iteration speed. The goal is learning, not production quality.

（原型是用于验证想法的临时代码。标准被有意放宽以最大化迭代速度。目标是学习，而非生产质量。）

这一理念在仓库的 Agent 定义中被进一步展开。prototyper.md 中prototyperAgent 的定位是"为前期制作服务的快速原型专家"，其核心哲学"速度优先于质量（Speed Over Quality）"列出了一组被有意放宽的生产标准：

• 架构模式：用什么最快就用什么
• 代码风格：可读性足以调试即可，别无他求
• 文档：最少——只要能说明在测试什么
• 测试覆盖：仅手工测试，不要求单元测试
• 性能：只有当性能本身就是被测试的问题时才做优化
• 错误处理：响亮地崩溃，不要优雅处理边界情况

同时文件强调了最关键的一句：

What is NOT relaxed: prototypes must be isolated from production code and clearly marked as throwaway.

（不可放松的部分：原型必须与生产代码隔离，并被明确标记为临时产物。）

这正是.claude/rules/prototype-code.md整份文件的灵魂：该放松的绝不苛求，该守住的一条不放。

三、原型中允许什么：八项宽松豁免

规则文件以清单形式明确了原型代码中"允许存在"的做法，这些在生产代码规则（如engine-code.md的零分配、线程安全要求）下都是违规项，但在prototypes/**下是被鼓励的：

1. 硬编码值（无需数据驱动配置）
2. 极少或没有文档注释
3. 简单架构（不需要依赖注入）
4. 单例与全局状态
5. 复制粘贴的代码（不需要抽象）
6. 保留调试输出
7. 占位美术与音频
8. 快捷但粗糙的解决方案

这八项与 /prototype Skill 的 Phase 4"实现"阶段完全对齐，该技能同样要求："自由硬编码数值、使用占位资源、跳过错误处理、使用能工作的最简单方案、复制代码而不是从生产导入。"

值得注意的边界是第 5 条"复制粘贴"——它背后有一条隐含的隔离规则：原型不得从生产源码 import 或依赖（需要什么就复制过来）。这条约束在规则文件的"仍然要求"部分有明确表述，也在 prototyper.md 中被强调为"原型代码绝不能泄漏到生产代码库"的第一条。

四、仍然要求什么：四条不可逾越的硬约束

宽松不等于失控。规则文件列出了即使在原型中也必须遵守的四项要求：

1. 每个原型拥有独立子目录：prototypes/[name]/

所有原型代码必须放在以原型命名的子目录中。这保证了：

• 原型之间互不干扰；
• 原型区域与src/生产区域在文件系统层面天然分离；
• 后续归档、清理、反向文档化都有明确的边界。

2. 每个原型必须有 README.md，且包含四个要素

规则文件规定README.md必须具备：

• 正在测试的假设（What hypothesis is being tested）——原型必须回答一个明确问题；
• 如何运行原型（How to run the prototype）——保证任何接手者（包括未来的自己）都能复现；
• 当前状态（Current status: in-progress / concluded）——进行中还是已结束；
• 结论（Findings，原型结束时更新）——测试后沉淀的知识。

这一要求与prototyperAgent 的"文档记录你学到了什么，而不是你构建了什么（Document What You Learned, Not What You Built）"哲学一脉相承：代码是临时的，知识是永久的。

3. 生产代码不得引用或导入prototypes/

隔离是单向且严格禁止的。任何src/下的生产代码不得依赖原型目录中的任何东西。

4. 原型不得修改prototypes/之外的文件，不得被部署或发布

原型活动被物理限制在prototypes/区域内；且原型永远不能进入发布、部署或交付流程。

这四条硬约束在 prototyper.md 的隔离要求（Isolation Requirements）中得到了更细的执行细则，包括每个原型文件必须带文件头注释：

// PROTOTYPE - NOT FOR PRODUCTION // Question: [What this prototype tests] // Date: [When it was created]

以及"原型不得从生产源文件导入或依赖（需要就复制）、生产代码永远不得从原型导入"。两条方向相反的 import 禁令合在一起，构成了防止代码泄漏的"双向防火墙"。

五、原型成功后的转化流程：重写，而非迁移

规则文件明确规定了"原型验证成功、功能转入生产"时的三个步骤：

1. 原型代码不直接迁移——必须按生产标准重写（rewritten to production standards）；
2. **原型 README.md 中的结论（findings）**指导生产设计文档的撰写；
3. 原型目录保留作参考，但永不再扩展。

这条"重写而非迁移"原则是整个原型策略中最容易被忽视、却最关键的一条。它防止了两种常见事故：原型里的 hack 借"清理一下"的名义混入生产；以及原型代码因持续修补而无限膨胀。

prototyper.md 中的 Agent 定义甚至将这一原则延伸到行为约束层面：Agent 被明确禁止"把原型代码拷入 src/ 或在不警告其非生产质量的情况下建议作为起点"，并且"如果原型需要打磨，说明它需要的是生产实现"。这与/prototypeSkill Phase 7 的约束一致："如果建议是 PROCEED，生产实现必须从零编写——原型代码不会被重构进生产。"

此外，仓库还提供了 concept-doc-from-prototype.md 模板，用于通过/reverse-document concept prototypes/[name]将已完成的原型反向文档化为正式的概念文档（包含核心机制、验证/否定结论、生产就绪度评估、设计支柱对齐等 14 个章节），实现"原型结论指导生产设计"的第二步。

六、清理策略：结论沉淀后归档或删除

规则文件的最后一部分处理原型的生命周期终点：

Concluded prototypes should be archived or deleted after findings are captured. Never let prototype code grow into production code through incremental "cleanup."

（结论已沉淀的原型应被归档或删除。绝不要让原型代码通过渐进式"清理"长成生产代码。）

这里提出了一个鲜明的反模式警示："渐进式清理"（incremental cleanup）是把原型变成生产代码的最危险路径——每次改一点、补一点，原型就会在不知不觉中积累生产级复杂度，同时保留着原型级的设计缺陷。正确的做法是明确的二选一：

• 归档：保留目录作参考（比如后续反向文档化、或为相似机制提供灵感）；
• 删除：结论已完全沉淀进 README 或设计文档后直接移除。

prototyper.md 将这一清理动作放在 7 步"原型生命周期"的最后一步："归档或删除——无论如何，它永远不能变成生产代码。"而 /prototype Skill 的 Phase 2 还提供了对已存在原型的三种处理选项：扩展（Extend）、替换（Replace）、归档（Archive）——其中归档路径是将旧原型移动到prototypes/archive/而非删除，与规则文件的"归档或删除"形成互补。

七、从规则到执行的完整闭环：Agent、Skill 与隔离机制

.claude/rules/prototype-code.md不是孤立的文档，它在仓库中与三层执行机制联动，形成完整的"宽松原型"工作流：

7.1 规则层：路径自动触发

正如 rules-reference.md 所述，.claude/rules/下的规则在编辑匹配路径的文件时自动生效。prototype-code.md声明prototypes/**，因此当 AI 在原型目录内写代码时，它会按宽松标准行事；一旦操作越过src/**，则自动切换为gameplay-code.md等严格标准。

7.2 Agent 层：prototyper 专责

prototyper.md 定义了专职的prototyperAgent（模型档位 Sonnet，maxTurns: 25，工具权限 Read/Glob/Grep/Write/Edit/Bash）。它明确声明："你的工作是快速构建、了解什么有效、然后把代码扔掉。你存在的意义是用运行中的软件回答设计问题，而不是构建生产系统。"其职责边界（Delegation Map）显示：向creative-director（概念验证决策）和technical-director（技术可行性评估）汇报，与game-designer（定义测试问题）、lead-programmer（生产架构约束）、systems-designer（机制验证与平衡实验）、ux-designer（交互模型原型）协作。

7.3 Skill 层：/prototype 七阶段工作流

prototype/SKILL.md 将规则落地为一个可调用命令/prototype [concept-description] [--review full|lean|solo]，包含七个阶段：

其中 Phase 1 的--review full|lean|solo参数读取production/review-mode.txt决定是否触发导演门禁（Director Gate CD-PLAYTEST）；而 Skill 的测试规范（见 CCGS Skill Testing Framework/skills/utility/prototype.md）明确指出原型不适用任何导演门禁——"原型是可丢弃的验证产物，没有导演门禁适用"，终局判定只有PROTOTYPE COMPLETE或PROTOTYPE ABANDONED两种。

7.4 隔离机制层：worktree 沙箱

prototyper.md 与 /prototype Skill 的 frontmatter 都声明了isolation: worktree。这意味着原型代码默认在临时 git worktree（仓库的隔离副本）中编写：

• 若原型被终止或放弃，worktree 自动清理，主工作树不留痕迹；
• 若原型产出有用结果，worktree 分支可在合并前接受审查。

这是规则文件"原型不得修改prototypes/之外文件"的工程级强化：即使 Agent 写偏了，物理沙箱也能兜底。

八、质量验证：技能测试规范如何守护这条标准

仓库的CCGS Skill Testing Framework/为这条宽松标准配套了可验证的测试用例，确保规则在实践中被执行到位。以 skills/utility/prototype.md 中的测试断言为例：

• Case 1（正常路径）：断言"写入任何文件前必须询问May I write to prototypes/grapple-hook/?"、实现隔离在prototypes/而非src/、findings.md至少包含 tested/worked/didn't-work/recommendation；
• Case 4（机制不可行）：验证放弃路径——findings.md记录具体失败原因（而非含糊描述）、给出替代方案建议、原型文件保留而非删除以供参考；
• Coverage Notes特别强调："原型实现质量（代码风格）有意不被测试——原型是临时产物，质量标准不适用"，并提醒"放松编码标准是特性而非缺陷，不要把缺少测试或注释标记为原型输出的失败"。

同样地，agents/specialists/prototyper.md 中的测试用例（如 Case 2 生产重定向、Case 4 放弃诚实性）验证了 Agent 不会把原型代码泄漏进src/、不会因沉没成本而坚持失败机制——这正是规则文件"清理"与"重写"章节要防住的两种行为。

九、落地建议：如何在你的项目中启用这套标准

在本仓库中使用这套原型标准的方式如下：

1. 查看规则与参考：阅读 .claude/rules/prototype-code.md（本文主体）及配套的 rules-reference.md，理解prototypes/**路径下宽松与严格的分界；
2. 调用技能：在 Claude Code 中执行/prototype [概念描述]，由 /prototype Skill 引导完成"定义问题 → 规划 → 实现 → 报告"全流程，产出带 PROTOTYPE 文件头标记的代码和REPORT.md；
3. 强制 README：确保每个prototypes/[name]/目录下的README.md写清假设、运行方式、状态与结论；
4. 转化时重写：验证成功后，由gameplay-programmer等生产 Agent 按src/下对应规则（如 gameplay-code.md）从零重写，可用 concept-doc-from-prototype.md 沉淀概念，但绝不迁移原型代码本身；
5. 结论沉淀后清理：按规则文件的清理章节，归档或删除已结束的原型，杜绝"渐进式清理"式膨胀。

十、总结

.claude/rules/prototype-code.md是一份"以退为进"的规则文档：它用显式列举的宽松换取原型迭代速度，用四条不可协商的硬约束（目录隔离、README 记录、双向 import 禁令、不部署）守住生产边界，再用**"重写而非迁移 + 结论沉淀后清理"**两条策略确保原型永远止步于验证工具的角色。

在 Claude-Code-Game-Studios 的完整体系中，这份规则与prototyperAgent（执行者）、/prototypeSkill（工作流）、worktree 隔离（沙箱）、技能测试框架（验证者）层层咬合——单看它是八条允许项与四条要求项，合起来则是一套被测试用例守护、被 Agent 行为约束贯彻的完整原型治理机制。对任何想用 AI 辅助游戏开发又担心原型污染生产库的团队而言，这套"该松的松、该严的严"的标准都是值得直接借鉴的模板。

【免费下载链接】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