企业官网建设流程全解析

Claude Code Game Studios 派系设计指南：用 faction-design 模板构建自洽的世界阵营体系

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

本文以仓库中的 faction-design.md 文档模板为骨架，讲解如何为游戏世界设计一个完整、内部自洽的派系（Faction）。文中将展示该模板从 Identity 身份表、History 历史、Beliefs 信仰，到 Reputation System 声望系统、Lore Consistency 一致性备注的完整填写方法，并结合 Claude Code Game Studios 中 world-builder 世界构建 Agent、narrative-director 一致性门禁与 entities.yaml 实体注册表，说明如何让派系设定在不同文档间保持一致、可被 Agent 检索与复用。

一、模板在项目中的定位：谁负责写派系文档

在 Claude Code Game Studios 的 Agent 架构中，派系设定不是随手写下的背景文字，而是由专门的 Agent 负责并拥有明确职责边界的领域资产。

1.1 归属：world-builder

从 world-builder.md 的 Agent 定义可以看出，world-builder 的领域（Domain）明确包含：

"World lore architecture — factions and their cultures/governments/motivations, world history, geography and ecology, cosmology and metaphysics, world rules…"

也就是说，派系及其文化、政府形态、动机、历史、地理生态、宇宙观与世界规则都属于 world-builder 的职责范围。但它的边界同样是清晰的——不负责：

• 具体 NPC 或任务的对话（归 writer 文案 Agent）
• 由世界规则推导出的游戏机制规则（归 game-designer / systems-designer）
• 叙事结构、故事弧线设计（归 narrative-director）

这意味着，填写 faction-design 模板时写下的内容，一旦涉及"这条派系设定会如何影响玩家可感知的机制"，就应当标注出来并交给 game-designer 接手，而不是在派系文档里越权定义玩法数值。

1.2 使用时机：Phase 2 叙事设计阶段

根据 WORKFLOW-GUIDE.md 中 Phase 2（Systems Design）的 Step 2.5，当游戏包含故事、传说或对话时，世界构建按以下顺序展开：

1. World-building— 使用world-builder定义派系、历史、地理与世界规则
2. Story structure— 使用narrative-director设计故事弧线、角色弧线与叙事节拍
3. Character sheets— 使用narrative-character-sheet.md模板

因此，faction-design 文档属于design/narrative/（故事、传说、对话目录）一类设计资产的产物，是世界观底座的组成部分，早于具体 NPC 对话与任务文案。

二、模板头部：元信息约定

每一个派系文档都以固定的头部开始：

# Faction Design: [Faction Name] *Created: [Date]* *Owner: world-builder* *Status: [Draft / Approved / Implemented]*

这个头部不是形式主义。在 Claude Code Game Studios 的协作协议中，每个任务遵循Question -> Options -> Decision -> Draft -> Approval流程，Agent 在写入文件前必须询问"May I write this to [filepath]?"。状态字段让审阅者（尤其是 narrative-director）一眼判断这份派系文档处于哪个阶段、是否可以进入一致性门禁。

三、Identity：用一张表锁定派系"第一印象"

模板第一部分要求用结构化表格定义派系的基本身份，不能用一段散文代替。world-builder 的测试规范（Case 1）明确要求输出为"结构化派系档案（structured faction profile），而非叙事散文"。

填写要点：

• Type决定了后续所有章节的"逻辑基调"。world-builder 测试规范特别强调："a merchant consortium's government is driven by economic logic, not feudal or religious logic, unless a deliberate hybrid is specified"——商业行会的政府结构必须服从经济逻辑，而不是套用封建或宗教逻辑，除非明确声明是刻意混合体。
• Alignment 不是 D&D 九宫格，而是用一句话概括该派系的道德复杂性。模板用注释明确排除了 D&D 阵营定义，要求你写出"他们道德上的灰度"。
• Symbol / Colors / Motto三件套同时服务于 Aesthetic Guide 章节与美术团队，是后续美术参考的最早锚点。

四、Overview：给一无所知的人做简报

模板要求 2–3 段概述，写作目标是"像给完全不了解背景的人做简报一样"：

[2-3 paragraphs describing who this faction is, what they want, and why they matter to the game world. Write as if briefing someone who knows nothing.]

必须覆盖三个问题：

1. Who they are— 这个派系是谁？
2. What they want— 他们想要什么？
3. Why they matter— 为什么他们对游戏世界重要？

这一段是派系文档中少数允许（且鼓励）散文式表达的部分，但同样不能包含未定义的专有名词。凡是提到其他派系、地区、事件，都应在 Relationships 与 Dependencies 中登记。

五、History：起源、关键事件与现状

历史部分分三个子节，构成一条完整的时间线叙事。

5.1 Origin（起源）

[How did this faction form? What event or need brought them together?]

描述派系如何形成：什么事件或需求让这群人走到一起。这一节是派系"为什么存在"的根因，也是后续所有信念、结构与对外关系的逻辑起点。

5.2 Key Historical Events（关键历史事件）

用带时间标注的编号列表记录塑造派系的事件：

1. **[Event Name]** ([Date/Era]): [What happened and how it shaped the faction] 2. **[Event Name]** ([Date/Era]): [Impact] 3. **[Event Name]** ([Date/Era]): [Impact]

每个事件至少说明两件事：发生了什么+如何塑造了派系。这里写下的事件会成为世界时间线的一部分，因此必须与已有的世界史一致——这正是后面 Lore Consistency Notes 要审计的对象。

5.3 Current State（现状）

[Where is this faction now? Are they ascendant, declining, stable, fractured?]

用一句话定性派系当前处境：上升期（ascendant）、衰落期（declining）、稳定（stable）、还是分裂（fractured）。这个定性会直接影响声望系统的起点、任务线的基调与玩家与派系初次接触的姿态。

六、Beliefs and Values：信仰、珍视与鄙弃

模板用三组列表刻画派系的内在精神世界：

Core Beliefs（核心信念）

• [Belief 1 — what they hold as fundamental truth]

列出派系视为"根本真理"的信条。核心信念必须能解释该派系在 History 中的关键行为——否则信念就是空话。

What They Value（他们珍视什么）

• [Value 1 — what they reward and respect]

他们奖励和尊重什么。这一项与 Reputation System 直接联动：声望点数（Reputation Points）本质上就是对玩家行为是否符合"派系价值观"的量化。

What They Despise（他们鄙弃什么）

• [Thing 1 — what they punish or reject]

他们惩罚或拒绝什么。值得注意的是，world-builder 测试规范要求派系必须包含至少一个内部张力或矛盾——"factions without internal complexity are flat"（没有内部复杂性的派系是扁平的）。如果 Core Beliefs 与 What They Value 之间存在真实的、刻意的张力（例如"珍视自由"却"鄙弃无秩序"），这个派系就有了血肉。

七、Structure and Leadership：结构与领导层

7.1 Hierarchy（层级结构）

[How is the faction organized? Military ranks? Council of elders? Meritocracy? Describe the power structure.]

描述权力结构：军事等级？长老议会？精英制？模板要求写出决策如何做出、权力在谁手中、继任或任命流程。这里再次强调 Type 的一致性：一个商业行会如果采用军政府结构，必须给出明确解释。

7.2 Key Figures（关键人物）

用表格登记派系中的核心人物：

模板建议至少覆盖三层：领袖（Leader）、二把手（Second）、其他值得注意的人物（Notable）。Personality 用 2–3 个形容词，Motivation 写驱动他们的深层动机。这些人物如果在其他文档（对话、任务、角色表）中出现，应到 entities.yaml 实体注册表登记——凡是跨文档出现的具名世界事实，都需要"单一事实来源"。

7.3 Membership（成员制度）

• How to join（如何加入）：出生？入会仪式？购买？受邀？
• How to leave（如何退出）：能否退出？退出后会发生什么？
• Population（人口）：大致规模与构成

加入/退出机制直接服务 Gameplay Role 中的玩家互动设计——玩家能否"加入"这个派系、代价是什么、能否叛离，都从这里派生。

八、Relationships：关系表

模板用一张四列关系表刻画派系与外部的关系网络：

• Relationship使用固定词表：Allied（结盟）/ Friendly（友好）/ Neutral（中立）/ Tense（紧张）/ Hostile（敌对）/ War（战争）。
• Reason解释关系成因，通常可以回指 Key Historical Events。
• Trend表示关系走势：Improving（改善）/ Stable（稳定）/ Deteriorating（恶化）。
• 最后一行固定登记Player关系——玩家初始态度（Starting disposition）与原因，走势标注为Player-influenced（由玩家行为决定），这为声望系统与任务线提供了接口。

注意：关系表是双向的。如果派系 A 对派系 B 标记为 "Hostile"，那么派系 B 的文档中对应关系也应体现这一点。Claude Code Game Studios 的 consistency-check 技能在扫描跨 GDD 一致性时，会把"依赖双向性（dependency bidirectionality）"作为检查项——关系类设定同理。

九、Reputation System：声望系统

模板给出了一套可直接落地的六档声望表：

这张表的工程价值在于：点数区间是明确的数值定义，可以直接进入数值设计（balance）与实体注册。使用建议：

• Tier是玩家可见的档位名；Points是隐藏的数值区间；Benefits是玩家收益；Requirements是达成条件（同时也是后续任务设计的验收标准）。
• 区间边界设计为连续无重叠：[-1000,-500)、[-500,-100)、[-100,100]、(100,500]、(500,1000]、(1000,∞)，可精确映射为代码中的档位判定函数。
• 如果"声望点数"这个数值会被多个系统引用（例如经济系统结算折扣、任务系统解锁条件），按 entities.yaml 的规则，应在formulas或constants段登记，并在referenced_by中列出所有引用它的文档。
• 声望点数的增减来源（哪些行为加多少分）属于游戏机制领域，应在派系文档中描述设计意图，由 game-designer 定义具体数值——这是 world-builder 与 game-designer 的协作边界。

十、Gameplay Role：游戏玩法角色

Player Interaction（玩家互动）

[How does the player encounter and interact with this faction? Quests? Trading? Combat? Diplomacy?]

玩家如何遭遇并互动：任务？交易？战斗？外交？这一节把派系从"背景设定"转化为"玩家可体验的内容"。

Unique Mechanics（独特机制）

[Does this faction introduce any unique gameplay mechanics? Crafting recipes? Combat styles? Magic systems?]

派系是否引入独特玩法机制：专属配方？战斗风格？魔法系统？注意边界：这里适合记录"派系引入了什么独特玩法"的设计意图，具体数值与规则归属 GDD。参照 world-builder 测试规范 Case 4 的要求：当一条世界设定具有直接机制后果时（例如"铁矿石削弱奥术"），Agent 必须标记协调需求——"This world rule has gameplay mechanics implications — game-designer needs to define how this translates into player-facing mechanics"，不得单方面设计玩法机制。

Questlines（任务线）

[Brief overview of the major questlines associated with this faction.]

概述与该派系相关的主要任务线。这里的"概述"是任务蓝图，具体对话归属 writer，任务结构归属叙事设计。详细人物设定可使用 narrative-character-sheet.md 模板展开。

十一、Aesthetic Guide：美学指南

美学部分为美术与音频团队提供四组参考，同时呼应 Identity 表中的 Symbol / Colors / Motto：

Architecture（建筑）

建筑风格：材料、造型、规模。例如石料与木材的搭配、尖塔或拱门的形态、建筑尺度。

Clothing/Armor（服饰/护甲）

成员穿着：识别性视觉元素。成员的服装应能让人一眼认出派系归属——这里可与 Identity 的Colors字段呼应。

Technology/Magic Level（科技/魔法水平）

使用的工具、武器与能力。这一项需与 Territory and Resources 中的资源禀赋保持一致（有稀缺资源的派系很难拥有与之匹配的高科技装备）。

Audio Palette（音频色调）

与该派系相关的声响：音乐主题、环境音。这一项供 sound-designer 与 audio 相关团队技能（如 team-audio.md 协作）作为参考起点。

十二、Lore Consistency Notes：传说一致性备注

这是 faction-design 模板中最具"工程价值"的一节，直接对接 Claude Code Game Studios 的一致性保障体系：

• Canon level（正典等级）：Core（核心）/Extended（扩展）/Flavor（风味）——本派系对主线故事的重要性。
• Contradictions to watch（需要警惕的矛盾）：与其他传说的潜在冲突。
• Open questions（未决问题）：关于该派系尚未决定的事项。
• Off-limits（禁区）：绝对不能为真的设定。

为什么这一节如此重要？因为 Claude Code Game Studios 的世界构建由多个 Agent 协作完成，一致性冲突随时可能发生。world-builder 测试规范 Case 3 描述的标准流程是：当新传说与既有历史冲突时，Agent不得静默覆盖既有设定，而是——

1. 指出矛盾：陈述两版内容，标明哪一版是既有设定、哪一版是新提议
2. 提出解决选项：(a) 新条目有误应修正；(b) 若新版才是正典则更新旧版；(c) 存在世界内解释（如"叙述者不可靠"）
3. 无明确答案时升级给 narrative-director 裁决

narrative-director 拥有ND-CONSISTENCY门禁，对提交的传说文档返回ND-CONSISTENCY: CONSISTENT / INCONSISTENT的结构化裁决（见 narrative-director.md 测试规范）。此外，consistency-check 技能会扫描design/gdd/下所有文档并输出结构化冲突表（Conflict Type: formula mismatch / competing ownership / stale reference / dependency gap）。本节的 Contradictions to watch 与 Open questions 就是提前在这些扫描中"自首"矛盾，而不是等扫描器抓出来。

十三、Dependencies：依赖关系

模板用四行清单登记派系与其他设计资产的联系：

• Related factions：与本派系互动的其他派系
• Related areas：本派系出现的关卡/区域
• Related questlines：涉及本派系的故事弧线
• Affects：影响范围——economy（经济）、combat encounters（战斗遭遇）、narrative branches（叙事分支）

这一节的价值在于把派系文档接入依赖图谱。在 Claude Code Game Studios 中，依赖关系是双向的：A 依赖 B 时，B 也应反向引用 A（review-all-gdds的一致性检查会验证依赖双向性）。当某个派系设定变更时，通过 Dependencies 清单可以反向追踪所有受影响的任务线、区域与经济系统，这与 propagate-design-change 技能"Git-diff 设计文档、寻找受影响 ADR、生成影响报告"的思路一脉相承。

十四、与其他模板的配套使用

faction-design 不是孤立的文档，它与其他设计模板形成完整的叙事设计工具链：

结语：一份派系文档的完成标准

参照 world-builder 测试规范，一份合格的 faction-design 文档应同时满足：

1. 结构化：以表格与清单为主，而非叙事散文（Case 1）
2. 内部一致：政府结构服从派系类型逻辑，无未解释的混合体
3. 具备内部复杂性：至少包含一个内部张力或矛盾
4. 边界清晰：对话归属 writer，机制数值归属 game-designer，故事弧线归属 narrative-director（Case 2）
5. 不静默覆盖既有设定：冲突必须标注并走解决流程（Case 3）
6. 可被检索：关键具名事实（派系名、关键人物、声望数值）按需登记到 entities.yaml，供所有技能以 Grep 模式交叉检查

按照本文梳理的十三个章节逐项填写，你产出的派系就不再是孤立的背景文案，而是一个能够进入 Claude Code Game Studios 一致性检查流水线、可以被 world-builder 维护、被 narrative-director 审计、被 game-designer 消费的自洽世界资产。

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