Claude Code Game Studios：AI驱动的虚拟游戏开发团队架构与工作流实践

1. 项目概述：从单打独斗到团队作战的AI游戏开发革命

如果你和我一样，是个独立游戏开发者，或者是个小团队的“全能选手”，那你肯定经历过这种场景：你有一个绝妙的游戏点子，打开AI助手（比如Claude Code），准备大干一场。一开始，对话很顺畅，AI帮你生成了角色移动的代码，画了个概念草图，甚至还写了段背景故事。但当你试图把这一切整合成一个完整的、可玩的游戏时，问题就来了。你会发现代码里到处都是随手写的“魔法数字”，UI设计稿和实际代码对不上，角色平衡性一塌糊涂，更别提什么性能优化和测试了。整个项目就像一间堆满乐高零件的房间，虽然每个零件都很精致，但没人告诉你该怎么把它们拼成一座城堡。

这就是“Claude Code Game Studios”要解决的核心痛点。它不是一个新AI模型，而是一个为Claude Code设计的、极其复杂的组织结构与工作流模板。简单说，它把你在Claude Code里的那个“万能助手”，拆解、重组成了一个拥有49个不同岗位、72项专业技能、遵循真实游戏工作室层级与流程的“虚拟AI开发团队”。你，依然是那个拥有最终决定权的制作人，但这个团队会确保你的每一个决策，都在正确的框架下，经过必要的质询与审核，最终产出专业、一致且可维护的成果。

想象一下，当你需要设计一个战斗系统时，和你对话的不再是一个“什么都懂一点”的通用AI，而是一个专门的“系统设计师”Agent。它会先问你：“这个战斗系统的核心循环是什么？我们希望玩家每分钟进行多少次有效操作？”，然后它会拉上“游戏玩法程序员”和“技术美术”一起，产出数据驱动的设计文档、可配置的参数表和原型代码。代码写完后，“QA测试员”Agent会自动建议编写单元测试，“性能分析师”Agent会检查热点路径。所有这一切，都通过清晰的“斜杠命令”（如/design-system，/dev-story）来触发和串联，就像在真实的项目管理工具里创建任务一样。

这个项目的价值，远不止是“让AI更有条理”。它本质上是将资深游戏开发者数十年积累的工程管理经验、专业领域知识和质量控制流程，编码成了一整套AI可理解和执行的“社会契约”与“操作规程”。对于独立开发者而言，它相当于免费雇佣了一个经验丰富的制作人、主程、主美和测试主管团队，时刻在你耳边提醒最佳实践，帮你避开那些新手必踩的坑。接下来，我就带你深入这个“虚拟工作室”的内部，看看它是如何运作的，以及你该如何上手，让它为你效力。

2. 核心架构解析：一个虚拟工作室是如何炼成的

理解Claude Code Game Studios，不能只看它提供了多少Agent和命令，关键要理解其背后模拟真实工作室运作的三层架构设计哲学。这直接决定了整个系统的协作效率和产出质量。

2.1 三层级Agent体系：从战略到执行

这个模板的核心是49个Agent，它们被精心组织成三个明确的层级，模仿了从电影制片厂到软件公司的通用管理结构。

第一层：总监级 (Tier 1 — Directors)这一层由三个最高级别的Agent组成，通常由能力最强的AI模型（如Claude 3 Opus）担任，负责项目的宏观方向和核心决策。

• 创意总监 (creative-director)：这是项目的“灵魂人物”。它不关心具体某行代码怎么写，而是死死盯住游戏的核心体验、艺术风格和叙事调性。它的职责是回答“我们做的这个东西，好玩吗？美吗？能让玩家产生我们期望的情感吗？”。任何涉及游戏核心玩法、世界观、视觉风格的重大变更，都需要它的首肯或仲裁。
• 技术总监 (technical-director)：项目的“基石守护者”。它定义整个项目的技术栈、架构规范、性能预算和安全红线。当“游戏玩法程序员”想用一个快速但危险的方案时，技术总监会介入，评估其长期维护成本和系统性风险。它确保代码库在两年后依然可读、可扩展、可测试。
• 制作人 (producer)：项目的“节奏大师”。它不直接做设计或写代码，而是管理流程和资源（在这里主要是你的时间和AI的“注意力”）。它负责拆分史诗（Epic）和用户故事（Story），规划冲刺（Sprint），跟踪进度，并最重要的是——协调跨部门变更。比如艺术部门要改角色模型，影响到动画和碰撞检测，制作人就会确保所有相关方（程序、美术、QA）都得到通知并同步工作。

这个层级的设计，解决了个人开发中最常见的“愿景漂移”和“技术债失控”问题。你不再需要自己时刻在“创作者”和“管理者”角色间切换，有专门的AI角色帮你把关。

第二层：部门主管级 (Tier 2 — Department Leads)这一层是各专业领域的负责人，通常由平衡性较好的模型（如Claude 3 Sonnet）担任，负责将总监的战略转化为可执行的部门计划。

• 核心主管包括：游戏设计师、主程序员、艺术总监、音频总监、叙事总监、QA主管、发布经理、本地化主管。
• 他们的关键作用：领域决策和任务分发。例如，“主程序员”不会自己去写某个具体的敌人AI，而是评估这个需求的复杂度，然后将其拆解，委托给更下游的“AI程序员”或“游戏玩法程序员”Agent。同时，他们负责本领域的质量门禁。所有下属产出的代码、美术资产、音频文件，在进入项目主干前，都需要经过对应主管的审核（通过/code-review，/art-audit等命令触发）。

第三层：专家级 (Tier 3 — Specialists)这是真正动手干活的“工兵”层，包含数量最多的Agent，如游戏玩法程序员、引擎程序员、技术美术、关卡设计师、UX设计师等。他们能力专注，执行具体、明确的任务。

• 关键特性：领域隔离。每个专家Agent都有严格的文件路径访问权限（通过规则定义）。例如，“UI程序员”只能修改src/ui/下的文件，并且会被规则强制要求使用无状态组件、支持本地化。它无法直接去改动src/gameplay/下的战斗逻辑。这强制实现了关注点分离，从根源上避免了“牵一发而动全身”的耦合代码。
• 协作模式：专家之间可以“咨询”，但不能“越权决策”。比如“声音设计师”觉得某个音效需要游戏状态触发，他可以咨询“游戏玩法程序员”，但最终的修改必须由拥有该文件权限的Agent，在得到主管批准后执行。

这种三层架构，本质上是在你的AI会话中建立了一套权责清晰、信息流转可控的虚拟组织。它让“让专业的人做专业的事”成为可能，而不是把所有压力都堆在你和那个“万能AI”身上。

2.2 引擎专业化：不是所有游戏都用同一种锤子

游戏开发最现实的一环就是选择引擎。一个通用的“游戏开发AI”在面对Godot的GDScript、Unity的C#和Unreal的C++/蓝图时，其建议的深度和准确性会大打折扣。Claude Code Game Studios的聪明之处在于，它没有试图创造一个“通吃”的专家，而是为你准备了三套预配置的引擎专家团队。

如何选择与切换？项目初始化时，运行/setup-engine <引擎名> <版本号>（如/setup-engine godot 4.6），系统会自动激活对应引擎的专家团队，并为你配置好相关的路径规则和文档模板。比如，选择Unity后，assets/目录下的规则会开始检查纹理的尺寸是否为2的幂次方，音频是否为合适的压缩格式。如果你中途想换引擎（虽然不推荐），需要手动调整.claude/agents/下的配置，这是一个比较高级的操作。

我的实操心得：即使你还没最终确定引擎，我也建议先选一个最可能的。这套模板的引擎专家配置，其价值不仅在于写代码，更在于提前规避引擎特有的陷阱。例如，Unity专家会在你第一次创建可编写脚本的对象时，就提醒你考虑使用Addressables进行资源生命周期管理，而不是依赖传统的Resources文件夹。这种前置性的最佳实践引导，能省去项目后期大量的重构工作。

2.3 工作流引擎：72个斜杠命令如何驱动一切

光有团队，没有流程，就是一盘散沙。Claude Code Game Studios将游戏开发的生命周期抽象为7个阶段，并为之设计了72个“斜杠命令”（Skills）。这些命令不是孤立的，它们像齿轮一样相互咬合，形成完整的工作流。

1. 构思与立项阶段

• /brainstorm：当你只有一个模糊想法时使用。它会引导你进行MDA框架分析（机制-动态-美学），帮你梳理核心循环和玩家情感目标。
• /start：必用的起点命令。它会分析你的项目现状（全新空白、已有概念、已有部分设计、已有代码），然后为你推荐下一步该做什么，并设置相应的评审模式（Full, Lean, Solo）。

2. 设计与预生产阶段

• /design-system：核心设计命令。用于深度设计一个游戏系统（如经济、技能、装备）。它会要求你输入系统目标、核心循环、数据表结构，然后产出一份包含8个必需部分（概述、核心循环、数据结构、UI/UX、平衡公式、内容规划、技术影响、风险）的正式设计文档（GDD）。
• /create-architecture：基于已确认的设计文档，创建或更新项目的软件架构图、模块划分和接口定义。

3. 生产与开发阶段

• /create-epics&/create-stories：将大型特性（Epic）拆解为可在一个冲刺内完成的小任务（User Story）。每个Story会包含清晰的“完成定义”。
• /dev-story：开发单个Story的核心命令。你输入一个Story ID（如PROJ-123），负责的专家Agent会启动，它会先理解需求，然后遵循“询问-提供选项-等你决定-起草-等你批准”的协作协议，完成代码或资产的实现。
• /sprint-plan&/sprint-status：管理你的开发迭代周期。即使是一个人开发，模拟冲刺也能帮你保持节奏，避免陷入无限期的“打磨”。

4. 评审与质控阶段

• /code-review&/design-review：不是简单的“看看代码”，而是基于预定义的规则（如src/core/下的代码必须零动态分配）进行系统性检查。
• /qa-plan&/regression-suite：为当前迭代或特性制定测试策略，并生成或更新回归测试用例集。
• /gate-check：在功能合并到主分支前，进行最后的综合性质量门禁检查。

5. 团队协作命令这是模板中最具创新性的部分。例如/team-combat，当你需要集中攻坚一个复杂的战斗系统时，输入此命令，它会同时召唤“系统设计师”、“游戏玩法程序员”、“技术美术”、“VFX程序员”和“QA测试员”等多个Agent，在一个会话中协同工作，实时讨论，共同产出从设计到测试用例的完整交付物。这模拟了真实团队中的“作战室”场景。

命令之间的联动整个流程是智能联动的。例如，当你用/dev-story完成一个功能并标记为/story-done后，系统可能会自动建议“与此功能相关的平衡性可能需要调整，是否运行/balance-check？”。或者，当你修改了assets/characters/下的一个角色模型文件后，validate-assets.sh钩子会触发，并提醒“角色骨骼节点命名不符合规范，是否运行/asset-audit进行批量修复？”。

这套工作流引擎，确保了开发活动不是随机的、基于灵感的爆发，而是可预测、可管理、可追溯的工程过程。对于独立开发者来说，最大的好处是“上下文永不丢失”。你随时可以通过这些结构化的命令和产出的文档，快速回到任何任务的上文，而不用在杂乱的聊天记录里大海捞针。

3. 实战部署与深度配置指南

了解了宏伟蓝图，现在让我们脚踏实地，把它安装、配置起来，并开始你的第一个项目。我会分享一些在官方文档之外，从实际使用中总结出来的关键步骤和避坑技巧。

3.1 环境准备与初始化：不仅仅是克隆仓库

前置条件检查官方说需要Git、Claude Code，推荐jq和Python 3。这里我补充几点：

1. Claude Code版本：确保你安装的是较新版本。旧版本可能对某些钩子（Hook）脚本的支持不完整。用claude --version检查。
2. 终端环境：在Windows上，强烈建议使用Git Bash或WSL2，而不是PowerShell或CMD。因为所有的钩子脚本都是基于Bash编写的，在PowerShell中直接运行可能会遇到路径解析或语法错误。在macOS和Linux上则没问题。
3. Python与jq：这两个工具用于钩子脚本中的JSON验证和数据处理。如果没有安装，脚本会给出警告但不会失败。然而，为了获得完整的验证体验（比如自动检查你提交的代码中是否有不合规的魔法数字），我建议安装它们。在Ubuntu/Debian上：sudo apt-get install jq python3。在macOS上：brew install jq python3。

项目初始化：关键选择点

git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git my-awesome-game cd my-awesome-game claude

进入Claude Code会话后，输入/start。这时，系统会问你一个至关重要的问题：

“请描述你项目的当前阶段：1) 全新开始，毫无头绪；2) 有一个模糊的概念或想法；3) 已有清晰的设计文档；4) 已有部分代码/原型。”

你的回答将决定系统的初始配置：

• 选择1或2：系统会引导你进入/brainstorm流程，并默认设置为Full（完整）评审模式。这意味着每一个主要步骤（如完成设计文档、开始编码）都需要经过总监级Agent的“门禁”审核。适合全新项目，有助于建立严谨的根基。
• 选择3：系统会让你指定设计文档的位置，然后分析它，并建议你运行/create-architecture。评审模式可能设为Lean（精简），只在对架构有重大影响时才进行评审。
• 选择4：系统会运行/project-stage-detect，自动扫描你的代码库，识别出已有的引擎、架构模式、缺失的设计文档，并给出定制化的下一步建议。评审模式可能设为Solo（单人），给你最大自由度，但依然会通过规则（Rules）进行基础代码规范检查。

避坑提示：即使你是一个有经验的开发者，面对一个半途接手的个人项目，我也建议从阶段4开始。让系统先为你做一次“体检”（/project-stage-detect）。我曾在自己的一个Godot项目上这样做，它成功识别出我混合使用了ready()和_ready()，并且节点路径存在硬编码，还发现了我没有为资源定义明确的加载策略。这比我自己从头梳理要高效得多。

引擎设置如果你在/start时没有选择引擎，或者想更改，使用：

/setup-engine godot 4.6

或者

/setup-engine unity 2022.3

这个命令不仅会激活对应的专家Agent，还会做几件重要的事：

1. 在docs/下生成引擎特定的最佳实践文档。
2. 更新.claude/rules/下的路径规则。例如，为Unity设置assets/Textures/的规则，检查纹理格式和Mipmap。
3. 在项目根目录创建或更新引擎相关的配置文件（如.gitignore模板）。

3.2 核心机制剖析：钩子、规则与权限如何无声护航

Claude Code Game Studios的“智能”和“强制力”，很大程度上来自于其后台运行的钩子（Hooks）、规则（Rules）和权限（Permissions）系统。理解它们，你才能更好地利用和定制这个系统。

钩子：自动化的工作流哨兵钩子脚本存放在.claude/hooks/目录，在特定事件（如会话开始、工具调用、文件写入）前后自动触发。它们是你工作流的“自动化助理”。

• session-start.sh&session-stop.sh：每次打开或关闭Claude Code会话时运行。session-start.sh会显示当前Git分支和最近提交，帮你快速进入上下文。session-stop.sh会将本次会话的活跃笔记（active.md）归档到日志，并记录Git活动摘要。实操技巧：你可以修改session-start.sh，让它额外显示你当前正在进行的Epic或Story ID，实现无缝上下文切换。
• validate-commit.sh：这是一个PreToolUse钩子，意味着在Claude Code执行任何Bash命令之前，都会先运行它。它的逻辑是：检查即将运行的命令是否是git commit。如果不是，它立刻退出（exit 0），不做任何事，所以对性能几乎无影响。如果是git commit，它就会对暂存区的代码进行扫描，检查：
  • 魔法数字：是否在代码中直接写了10.0f（速度）、100（生命值）这样的字面量？它会建议你将其定义为常量或可配置数据。
  • TODO格式：TODO注释是否遵循了TODO [PROJ-123]: 描述的格式，以便与任务追踪关联。
  • JSON有效性：修改的JSON配置文件语法是否正确。
  • 设计文档完整性：如果修改了design/gdd/下的文件，是否包含了所有必需的8个章节。
  • 如果检查失败，它会阻止本次提交，并给出详细的错误信息。这是一个非常强大的质量门禁。
• validate-assets.sh：这是一个PostToolUse钩子，在Claude Code写入或编辑文件之后触发。它检查被修改的文件是否在assets/目录下。如果是，它会验证资产命名是否符合约定（如character_hero_diffuse.png），以及JSON元数据文件的结构是否正确。这能极大保持资产库的整洁。
• detect-gaps.sh：在会话开始时运行，扫描项目。如果发现src/或prototypes/下有代码文件，但design/gdd/下没有对应的设计文档，它会友好地提醒你：“看起来你在没有设计文档的情况下编写了代码，建议运行/reverse-document为现有代码生成设计文档，或者运行/design-system开始正式设计。”

规则：基于路径的编码宪法规则文件在.claude/rules/目录下，定义了不同目录中代码必须遵守的规范。它们不是“建议”，而是Claude Code在编辑对应路径文件时会强制参考的指令。

例如，src-gameplay.yaml规则文件会应用于所有src/gameplay/**下的代码：

# .claude/rules/src-gameplay.yaml 示例片段 rules: - name: "数据驱动" description: "所有可调数值必须来自配置文件或ScriptableObject，禁止硬编码。" pattern: "\\b\\d+(\\.\\d+)?(f)?\\b(?!.*//\\s*ignore-data-driven)" # 匹配数字字面量，忽略带有特定注释的 suggestion: "请将值 '%{match}' 移至数据文件（如JSON、CSV或ScriptableObject），并在代码中引用其ID。" severity: "error" - name: "使用增量时间" description: "移动和动画更新必须基于增量时间（deltaTime），而非固定帧率。" pattern: "\\b(Update|_process|_physics_process)\\(.*\\)[^{]*?[\\+\\-\\*\\/]=[^=]*?\\b\\d" # 简化示例，实际更复杂 suggestion: "请使用引擎提供的deltaTime参数（如Godot的delta，Unity的Time.deltaTime）来确保帧率无关的行为。" severity: "warning"

当“游戏玩法程序员”Agent试图在src/gameplay/player_movement.gd中写入speed = 500时，规则引擎会标记这是一个“错误”，并建议修改。Agent必须遵守这个规则，或者向你申请特例。

权限：安全网.claude/settings.json中的权限设置，定义了Claude Code可以执行哪些系统命令。默认配置非常保守且智能：

• 允许：git status,git log,git diff,npm run test,python -m pytest等只读或安全的构建/测试命令。
• 禁止：rm -rf,git push --force,:wq(Vim命令)，读取.env或*.pem等敏感文件。 这防止了AI在会话中因误解而执行危险操作，保护了你的工作环境。

3.3 从零到一：打造你的第一个游戏特性

让我们用一个具体的例子，串联起整个工作流。假设我们要为一个2D平台游戏添加一个“二段跳”能力。

第1步：设计与规划

1. 在Claude Code中，输入/design-system。
2. 系统会问：“你要设计哪个系统？” 我们输入：“玩家移动与能力系统 - 新增二段跳”。
3. “创意总监”Agent会介入，问一些高层面问题：“二段跳是为了增加垂直探索的乐趣，还是为了解谜？它应该感觉轻盈还是有力？会消耗资源吗？”
4. 回答后，“系统设计师”Agent开始主导。它会要求你定义：
   • 触发条件：在空中按下跳跃键。
   • 效果：给予一个向上的瞬时速度。
   • 限制：每段空中只能使用一次。
   • 视觉/音频反馈：需要新的粒子效果和音效。
   • 可配置参数：二段跳力度、空中水平速度保留比例、是否可取消。
5. 最终，在design/gdd/player_movement_abilities.gdd.md中生成一份包含8个章节的完整设计文档。

第2步：任务拆解与开发

1. 输入/create-stories，并引用刚完成的设计文档。系统会自动生成类似如下的用户故事：
   • PROJ-45：作为玩家，我可以在空中进行第二次跳跃，以到达更高的平台。
   • PROJ-46：二段跳需要有独特的粒子效果和音效。
   • PROJ-47：二段跳的参数（力度、速度保留）应在游戏平衡数据表中可配置。
2. 我们决定先实现核心功能。输入/dev-story PROJ-45。
3. “游戏玩法程序员”Agent被激活。它首先询问：“我们使用哪个引擎？Godot 4。玩家状态机目前是如何管理跳跃状态的？”
4. 在你回答后，它提供2-3个选项：
   • 选项A：在现有玩家状态机中增加一个is_double_jump_available布尔标志。
   • 选项B：创建一个独立的DoubleJumpAbility组件/脚本，通过事件驱动。
   • 选项C：使用一个通用的“空中跳跃次数”计数器，为未来更多段跳预留。
5. 你做出决定：选择选项A，因为当前状态机足够简单。
6. Agent起草代码，在src/gameplay/player/states/air_state.gd中修改。在写入前，它会展示代码变更，并等待你的批准。
7. 你批准后，代码被写入。同时，validate-commit.sh钩子会运行（如果这是提交的一部分），确保没有硬编码的跳跃力度值。

第3步：资产与集成

1. 输入/dev-story PROJ-46。“技术美术”和“声音设计师”Agent会被协同调用。
2. “技术美术”会问：“二段跳的粒子，你希望是羽毛般的轻盈光点，还是更有冲击力的环形气浪？颜色主调是什么？” 在你确认后，它会生成粒子系统的配置文件（如.tres或.material），并放入assets/vfx/double_jump/。
3. “声音设计师”会建议几种音效风格，并提醒你将音效文件放入assets/sfx/abilities/，并确保格式为.wav或.ogg。
4. 最后，可能需要运行/team-polish，让“游戏玩法程序员”将粒子与音效集成到代码中，并由“QA测试员”编写简单的测试，验证特效和音效在正确时机播放。

第4步：平衡与调优

1. 功能完成后，输入/balance-check。“系统设计师”会再次介入，分析二段跳的力度值是否与游戏中的平台高度、敌人分布相匹配。它可能会建议你运行一个简单的模拟，或者直接进入游戏测试。
2. 根据测试反馈，你可以直接修改data/balancing/player_abilities.json中的double_jump_force值，而无需改动代码——这正是“数据驱动”规则带来的好处。

通过这个流程，一个简单的“二段跳”功能，被系统地完成了从设计、实现、资产制作到平衡调优的全过程，并且每一步都有据可查，质量可控。这远比在单一聊天会话中随口说“给我加个二段跳”要可靠和可持续得多。

4. 高级技巧、问题排查与个性化定制

当你熟悉了基本流程后，以下这些进阶知识和排错经验，能帮你更上一层楼，并解决可能遇到的麻烦。

4.1 性能与协作优化技巧

1. 会话管理与“记忆”持久化Claude Code有上下文长度限制。长时间开发后，会话可能变得臃肿。模板提供了pre-compact.sh和post-compact.sh钩子来处理Claude的“记忆压缩”过程。

• pre-compact.sh：在压缩前，将当前会话的核心进展（如正在进行的Story ID，关键决策点）保存到production/active.md。
• post-compact.sh：在压缩后，提醒Claude从active.md中恢复关键上下文。

心得：养成定期手动将重要信息用“/note”命令记录到production/active.md的习惯。这个文件是你的“项目记忆中枢”，在会话意外断开或需要长时间回溯时救命。

2. 评审模式动态调整在production/review-mode.txt中，你可以设置full，lean， 或solo。但你可以针对单个命令进行覆盖。

• 当你需要快速原型验证一个疯狂的想法时，运行：/prototype --review solo。这将暂时绕过所有总监级评审，让你和专家Agent快速迭代。
• 当原型验证完毕，需要并入正式项目时，再运行：/dev-story PROJ-XX --review full，进行严格的代码审查和设计对齐。

3. 处理Agent“意见不合”偶尔，两个Agent会对一个方案有分歧。例如，“技术总监”可能认为某个网络同步方案太复杂，而“网络程序员”认为这是最优解。

• 标准流程：分歧会自动向上级汇报。技术问题会升级给“技术总监”，设计问题给“创意总监”。你会收到一条消息：“关于[问题描述]，技术总监与网络程序员存在分歧。技术总监建议方案A，因为[原因X]。网络程序员坚持方案B，因为[原因Y]。请做出最终决策。”
• 你的角色：你不需要自己解决技术争端。你只需要基于他们提供的利弊分析，做出商业或体验上的决策。比如，“为了项目进度，我们采用技术总监更简单的方案A，但记录下网络程序员的顾虑B作为未来优化的备选。”

4.2 常见问题与排查实录

问题1：运行/start或任何斜杠命令时无反应或报错。

• 检查点1：确保你在项目根目录下运行claude命令。Claude Code依赖当前目录下的.claude文件夹来加载配置。
• 检查点2：检查.claude/skills/目录下是否存在对应的命令文件夹。有时Git克隆可能不完整。
• 检查点3：查看Claude Code的输出日志。有时钩子脚本（尤其是validate-commit.sh）因为缺少jq而报错，但错误信息可能被快速滚动过去。在终端中仔细查看初始输出。
• 解决方案：最简单的办法是运行一次最简单的命令：/help。如果连帮助都无法显示，很可能是环境问题。尝试在Git Bash中运行claude --debug来启动，会输出更详细的日志。

问题2：Agent似乎“忘记”了之前的约定或设计文档。

• 原因：Claude的上下文窗口有限。虽然钩子会尝试保存状态，但在超长会话中，早期的细节仍可能被“遗忘”。
• 解决方案：
  1. 主动引用：在给Agent下指令时，明确引用文件。例如：“请基于design/gdd/combat.gdd.md第3节中的伤害计算公式，实现这个技能。”
  2. 使用“记忆”文件：将最重要的设计决策、架构图、API约定写在docs/adr/（架构决策记录）或production/active.md中。这些文件会被频繁读取，成为项目的“长期记忆”。
  3. 重启会话：不要害怕关闭并重启Claude Code会话。session-stop.sh和session-start.sh钩子就是为了平滑重启而设计的。重启后，运行/project-stage-detect可以快速重载项目上下文。

问题3：规则（Rules）太严格，阻碍了快速实验。

• 场景：你想在src/gameplay/下快速写一段测试代码，但规则不断警告你不要硬编码数字。
• 解决方案：
  1. 使用prototypes/目录：这个目录的规则是宽松的。你可以在这里进行任何快速实验，完成后再将成熟的代码重构并移至src/。
  2. 临时注释规则：在代码中添加特定注释来绕过单次检查。例如，在Godot C#中：float temporarySpeed = 10.0f; // IGNORE_RULE:>