ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

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

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 中的规则映射表规则文件路径模式强制执行内容gameplay-code.mdsrc/gameplay/**数据驱动数值、delta time、不得引用 UIengine-code.mdsrc/core/**热路径零分配、线程安全、API 稳定性prototype-code.mdprototypes/**宽松标准、必须 README、记录假设test-standards.mdtests/**测试命名、覆盖率要求、fixture 模式可以看到prototype-code.md是与src/下生产代码规则gameplay-code、engine-code、network-code、ui-code 等并列但基调相反的一套规则生产代码追求工程严格性原型代码则刻意放松标准以换取迭代速度。这份文件开头的 frontmatterpaths: - 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/**下是被鼓励的硬编码值无需数据驱动配置极少或没有文档注释简单架构不需要依赖注入单例与全局状态复制粘贴的代码不需要抽象保留调试输出占位美术与音频快捷但粗糙的解决方案这八项与 /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 禁令合在一起构成了防止代码泄漏的双向防火墙。五、原型成功后的转化流程重写而非迁移规则文件明确规定了原型验证成功、功能转入生产时的三个步骤原型代码不直接迁移——必须按生产标准重写rewritten to production standards**原型 README.md 中的结论findings**指导生产设计文档的撰写原型目录保留作参考但永不再扩展。这条重写而非迁移原则是整个原型策略中最容易被忽视、却最关键的一条。它防止了两种常见事故原型里的 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模型档位 SonnetmaxTurns: 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定义待回答的核心问题README 必须记录正在测试的假设Phase 2加载项目上下文引擎、语言原型需与项目技术栈兼容Phase 33-5 条要点规划最小可行原型只构建回答问题所需的最小代码Phase 4请求许可后创建prototypes/[name]/并实现文件头必须带 PROTOTYPE 标记标准有意放宽Phase 5生成 Prototype Report 并写入REPORT.mdfindings 沉淀含 PROCEED / PIVOT / KILL 建议Phase 6Creative Director 审核按 review 模式概念验证决策上移给导演层Phase 7汇总与下一步PROCEED → /design-system成功转化走重写而非迁移其中 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/didnt-work/recommendationCase 4机制不可行验证放弃路径——findings.md记录具体失败原因而非含糊描述、给出替代方案建议、原型文件保留而非删除以供参考Coverage Notes特别强调原型实现质量代码风格有意不被测试——原型是临时产物质量标准不适用并提醒放松编码标准是特性而非缺陷不要把缺少测试或注释标记为原型输出的失败。同样地agents/specialists/prototyper.md 中的测试用例如 Case 2 生产重定向、Case 4 放弃诚实性验证了 Agent 不会把原型代码泄漏进src/、不会因沉没成本而坚持失败机制——这正是规则文件清理与重写章节要防住的两种行为。九、落地建议如何在你的项目中启用这套标准在本仓库中使用这套原型标准的方式如下查看规则与参考阅读 .claude/rules/prototype-code.md本文主体及配套的 rules-reference.md理解prototypes/**路径下宽松与严格的分界调用技能在 Claude Code 中执行/prototype [概念描述]由 /prototype Skill 引导完成定义问题 → 规划 → 实现 → 报告全流程产出带 PROTOTYPE 文件头标记的代码和REPORT.md强制 README确保每个prototypes/[name]/目录下的README.md写清假设、运行方式、状态与结论转化时重写验证成功后由gameplay-programmer等生产 Agent 按src/下对应规则如 gameplay-code.md从零重写可用 concept-doc-from-prototype.md 沉淀概念但绝不迁移原型代码本身结论沉淀后清理按规则文件的清理章节归档或删除已结束的原型杜绝渐进式清理式膨胀。十、总结.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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表