从原型到概念文档：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（CCGS）中通过快速原型验证游戏机制的开发者与设计团队。本文以.claude/docs/templates/concept-doc-from-prototype.md为核心，系统讲解如何在原型完成后，以"反向文档化"方式将实验成果沉淀为标准概念文档：覆盖原型概述、核心机制提炼、成败复盘、生产就绪评估、设计支柱对齐、下一步决策与版本管理等全部 14 个章节，并对照仓库内/prototype、/reverse-document、/design-system、/playtest-report等技能测试规格与实际工作流示例，说明该模板在 CCGS 完整游戏开发流水线中的位置与调用方式。读完本文，你将能独立完成一份可评审、可追溯、可驱动 GO/NO-GO/PIVOT 决策的高质量原型概念文档。

1. 模板定位：为什么原型之后需要一份"反向概念文档"

在传统开发流程中，概念文档写于开发之前，是"计划性设计"的产物；而 CCGS 强调的另一条路径恰好相反：先做原型，再写文档。模板开头的⚠️ Reverse-Documentation Notice明确界定了这一点：

This concept document was createdafterthe prototype was built. It captures the core mechanic, learnings, and design insights discovered through prototyping. This is a formalization of experimental work, not a pre-planned design.

（本概念文档创建于原型构建之后。它记录的是通过原型化发现的核心机制、经验教训与设计洞见。这是对实验性工作的正式化，而非预先规划的设计。）

模板元信息区定义了文档的四个基础字段，任何使用者在填写时都必须保持完整：

字段	说明	填写示例
Status	固定为`Reverse-Documented from Prototype`，表明文档来源	`Reverse-Documented from Prototype`
Prototype Path	原型在仓库中的存放路径	`prototypes/[name]/`
Date	文档创建日期	`2026-09-12`
Creator	创建者	`[User name]`
Outcome	原型总体结论	`Success \\| Partial Success \\| Failed \\| Needs More Testing`

1.1 模板在 CCGS 工作流中的位置

在 CCGS 的整体流水线中，原型化是"验证机制是否值得投入生产"的关键一环。仓库 prototype 技能测试规格对该技能的定义是：

/prototypemanages a rapid prototyping workflow for validating a game mechanic before committing to full production implementation. Prototypes are created inprototypes/[mechanic-name]/and are intentionally disposable.

也就是说，原型存放于prototypes/[mechanic-name]/，是**刻意设计为可丢弃（disposable）**的验证工件：编码标准放宽（无需 ADR、验收标准可极简、允许硬编码值）。测试规格同时规定了原型会话的两种裁决：

PROTOTYPE COMPLETE：原型构建完成且发现已记录；
PROTOTYPE ABANDONED：机制被证实不可行。

而本模板（concept-doc-from-prototype）正是承接这一环节的产物——它把原型会话中的findings.md（测试了什么、什么有效、什么无效、建议下一步）升级为更完整的、可进入正式设计流程的概念文档。当原型验证成功，设计系统技能（/design-system）会接手将概念正式化为 8 章节的 GDD；当原型失败，本模板同样记录失败原因并给出替代方案。

注意路径差异：模板中引用的是prototypes/[name]/这一相对占位路径。在当前仓库中，真正的模板文件位于 .claude/docs/templates/concept-doc-from-prototype.md，而相关技能规格位于 CCGS Skill Testing Framework/skills/utility/prototype.md 与 CCGS Skill Testing Framework/skills/utility/reverse-document.md。

1.2 与 /reverse-document 技能的关系

仓库中存在一个同名能力族：/reverse-document技能（规格见 CCGS Skill Testing Framework/skills/utility/reverse-document.md）用于从已有源码反向生成设计文档：

/reverse-documentgenerates design or architecture documentation from existing source code. It reads the specified source file(s), infers design intent from class structure, method names, constants, and comments, and produces either a GDD skeleton (for gameplay systems) or an architecture overview (for technical systems).

两者的区别在于：

/reverse-document的输入是代码，输出是GDD 骨架或架构总览，且会标注AMBIGUOUS VALUE等需要人工确认的推断（裁决为 COMPLETE 或 PARTIAL）；
本模板的输入是原型实验（原型代码 + 测试观察 + 反馈），输出是概念文档，记录的是"假设→验证→结论"这一完整的实验循环，而非单纯推断代码意图。

模板末尾的生成注记*This concept document was generated by /reverse-document concept prototypes/[name]*将两者串联起来：先跑/prototype构建并验证机制，再通过/reverse-document concept prototypes/[name]生成概念文档。仓库 docs/examples/reverse-document-workflow-example.md 提供了一个完整示例——开发者完成了 1200 行技能树代码却从未写设计文档，Agent 通过阅读代码、提出澄清问题、分离"意图与实现"最终产出了design/gdd/skill-system.md，这正是反向文档化思想在系统层面的落地。

2. 章节一：原型总览（Prototype Overview）

这是文档的事实基线，回答"我们到底验证了什么、怎么验证的、结果如何"。模板要求记录四个维度：

原始假设（Original Hypothesis）：这个原型要检验的问题或想法是什么？假设必须可证伪——例如"抓钩机制能让玩家在 3 秒内完成跨平台移动"而不是笼统的"抓钩很酷"。

实现方式（Approach）：原型是如何构建的？模板给出了关键词提示：Quick and dirty? Focused on one mechanic?（快速粗糙？是否聚焦单一机制？）。对应 prototype 技能规格的要求，原型实现应刻意粗糙：intentionally rough — no polish, hardcoded values acceptable（刻意粗糙——不做打磨，允许硬编码值），且实现必须隔离在prototypes/目录而非src/，避免污染生产代码。

耗时与复杂度（Duration）：

Time spent：X 小时/天；
Complexity三档评级：Throwaway（一次性）、Could be production-ready（可接近生产级）、Needs full rewrite（需完全重写）。

结论澄清（Outcome, clarified）：用三类符号归档实验结果：

✅Validated：验证有效，应进入下一步；
⚠️Needs Work：展现出潜力但需打磨；
❌Invalidated：无效，应放弃。

提示：Outcome 中的 ✅/⚠️/❌ 三态符号并非装饰，它们贯穿整个模板（第 3、4、5、6 章均复用同样的语义标记），保证全文对"成功/需改进/失败"的判断口径一致。

3. 章节二：核心机制（Core Mechanic）

这一章是全文档的灵魂，负责把"原型做了什么"转译为"玩家体验到了什么"。模板给出五个子维度：

原型做什么（What the Prototype Does）：描述被原型化的机制或系统。建议用一两段话讲清楚输入→处理→输出，而非罗列功能清单。

手感反馈（How It Feels, user feedback）：以感受形容词列表呈现用户反馈，模板给了三组对照示例：

"Satisfying"（令人满足）/"Clunky"（笨拙）/"Too complex"（过于复杂）
"Intuitive"（直观）/"Confusing"（令人困惑）/"Needs tutorial"（需要教学）
"Fun"（有趣）/"Boring"（无聊）/"Has potential"（有潜力）

这些原始感受词汇是后续第 11 章 Playtest Feedback 的定性前奏，也是设计洞察（第 6 章）的证据来源。

玩家幻想（Player Fantasy）：机制创造了什么样的幻想或体验？例如抓钩不只是移动手段，它创造的是"蜘蛛侠式自由穿梭"的幻想。在 CCGS 的概念阶段（见 WORKFLOW-GUIDE.md 第 1.1 节），核心幻想是概念文档的必备要素，原型阶段验证的正是这个幻想是否真的成立。

核心循环（Core Loop, if applicable）：用流程图式语法表达，模板格式为：

[Action 1] → [Result 1] → [Action 2] → [Result 2] → [Repeat or Conclude]

例如抓钩原型：瞄准 → 发射钩索 → 摆动加速 → 松开转向 → 落地/再瞄准。核心循环是可复用、可评审的浓缩资产，后续写 GDD 时可直接迁移。

涌现行为（Emergent Behaviors）：记录"玩家做了计划之外的事"。模板提示两类：[Behavior 1]（玩家没被计划到的行为）与[Behavior 2]（意外的策略或交互）。涌现行为是原型验证中最有价值的副产品之一——它可能催生新机制（例如《泰坦陨落》的滑墙源于玩家意外发现），也可能暴露平衡漏洞。

4. 章节三与四：什么有效 / 什么无效

这两章互为镜像，共同构成实验记录的核心证据链。

4.1 什么有效（What Worked）

分两个子节，且每个条目都要回答"是否保留到生产"：

机制成功（Mechanic Successes），条目格式为：

✅ [Success 1]: [What worked well] - **Why**: [What made this successful] - **Keep for Production**: [Should this be preserved?]

技术成功（Technical Successes），条目格式为：

✅ [Technical win 1]: [What technical approach worked] - **Lesson**: [What we learned] - **Reusable**: [Can this code/approach be used in production?]

技术成功章节直接服务于第 10 章"可复用代码"的盘点——Reusable标记为 Yes 的技术路径应被登记进第 10 章的可复用代码清单。

4.2 什么无效（What Didn't Work）

同样分为机制失败与技术失败，但每条必须回答"根因"与"可修复性"：

❌ [Failure 1]: [What didn't work] - **Why**: [Root cause] - **Could It Be Fixed**: [Is it salvageable or fundamentally flawed?]

技术失败的模板条目为：

❌ [Technical issue 1]: [What caused problems] - **Lesson**: [What to avoid in production]

对照 prototype 技能规格的 Case 4（PROTOTYPE ABANDONED 场景），当机制被证实不可行时，findings.md必须记录具体的失败原因而非模糊描述（例如"输出不连贯、玩家困惑、技术复杂度过高"），并建议替代方向（如用精选对话替代程序化生成）。本模板第 4 章与第 9 章（Next Steps）正是承接这一要求的正式落点：第 4 章记录失败，第 9 章据此给出归档或转向的行动清单。

5. 章节五与六：待打磨项与关键经验

5.1 需要打磨什么（What Needs Refinement）

该章针对"有潜力但不成熟"的元素，每条记录三要素：

⚠️ [Element 1]: [What showed promise but needs work] - **Issue**: [What's wrong with it currently] - **Path Forward**: [How to improve it] - **Effort**: [Small | Medium | Large refactor]

Effort三档（Small/Medium/Large）为第 7 章"生产工作量估算"提供直接输入——待打磨项的 Effort 之和基本决定了"从零到生产"的工作量级。

5.2 关键经验（Key Learnings）

模板把经验分为三类，每类均以"洞察 + 影响"的结构记录：

设计洞察（Design Insights）：

💡 [Insight 1]: [What we learned about game design] - **Implication**: [How this affects future work]

技术洞察（Technical Insights）：Implication 指向"架构或实现指引"——例如"事件总线在原型中的高频事件下性能可接受，但生产环境应改用批处理"。

玩家心理洞察（Player Psychology Insights）：记录玩家行为规律及其对设计哲学的影响。例如"玩家普遍在失败两次后放弃挑战，而非我们预期的三次"。

这三类经验与 creative-director 的 CD-PILLARS 评审场景直接相关——创意总监在评审概念文档时，正是依据这些经验判断机制是否符合设计支柱。

6. 章节七：生产就绪评估（Production Readiness Assessment）

这是文档的决策核心，模板要求明确给出四选一结论：

Should This Become a Full Feature?: Yes | No | Needs More Testing | Pivot to Different Approach

若 Yes——生产需求清单：以复选框列出进入生产前必须完成的硬性要求，模板给了四个示例方向：

- [ ] [Requirement 1 — e.g., "Rewrite for performance"] - [ ] [Requirement 2 — e.g., "Add proper UI"] - [ ] [Requirement 3 — e.g., "Design 10 more variations"] - [ ] [Requirement 4 — e.g., "Integrate with progression system"]

并给出生产工作量估算：

Estimated Production Effort: Small | Medium | Large
Prototype reusability: [X%] of code can be kept（原型代码可保留比例）
From-scratch effort: [X hours/days to production-ready]（从零重写耗时）

若 No——说明原因：模板提供三个典型否决理由方向：Fun but doesn't fit game pillars（好玩但不符合设计支柱）、Too complex for target audience（对目标受众过复杂）、Technically infeasible at scale（规模化后技术上不可行）。

若 Pivot——建议转向方向：列出替代方案清单，例如"改为 2D 俯视实现"或"把抓钩降级为单次位移技能"。

这一章与 CCGS 的阶段闸门（gate）体系呼应：仓库 gate-check 技能规定概念阶段闸门依赖design/gdd/game-pillars.md或概念文档中定义的支柱，而本模板第 8 章正是提供支柱对齐证据的位置。

7. 章节八：设计支柱对齐（Design Pillars Alignment）

设计支柱（Game Pillars）是 CCGS 概念阶段定义 3～5 条不可妥协的设计价值（见 WORKFLOW-GUIDE 的 concept document 清单）。本章以表格形式逐一评估原型机制与每条支柱的关系：

Pillar	Alignment	Notes
[Pillar 1]	✅ Strong / ⚠️ Weak / ❌ Conflicts	[Explanation]
[Pillar 2]	✅ Strong / ⚠️ Weak / ❌ Conflicts	[Explanation]
[Pillar 3]	✅ Strong / ⚠️ Weak / ❌ Conflicts	[Explanation]

对齐三态的含义：

✅ Strong：机制直接强化该支柱；
⚠️ Weak：机制与该支柱关系薄弱或中立；
❌ Conflicts：机制与该支柱冲突——这是危险信号，通常直接导致第 7 章的 No 或 Pivot 决策。

表格之后是**总体支柱契合度（Overall Pillar Fit）**结论：[Does this belong in the game?]。这一结论与创意总监的 CD-PILLARS 门评审（见 creative-director.md）对齐，形成"模板自评 → 总监复核"的双层把关。

8. 章节九：下一步行动（Next Steps）

模板按三种决策路径分别给出行动模板，这使文档不仅记录过去，还能直接驱动后续排期：

立即推进（Immediate, If Moving Forward）：

[Task 1]: "Create full design doc for this system"（创建完整设计文档）
[Task 2]: "Write ADR for technical approach"（为技术方案写 ADR）
[Task 3]: "Add to backlog for Sprint X"（加入 Sprint X 待办）

其中第 1 项对应/design-system [system-name]——按 design-system 技能规格，该技能以骨架优先方式创建包含 8 个必填章节（Overview、Player Fantasy、Detailed Rules、Formulas、Edge Cases、Dependencies、Tuning Knobs、Acceptance Criteria）的 GDD；原型概念文档中的核心循环、成败经验恰好为这些章节提供了现成素材。第 2 项对应/architecture-decision（见 CCGS Skill Testing Framework/skills/authoring/architecture-decision.md）。

生产前补强（Before Production, If Needs More Work）：

[Task 1]: "Build second prototype testing X variation"（构建第二个原型测试 X 变体）
[Task 2]: "Playtest with 5+ people"（至少 5 人试玩）
[Task 3]: "Investigate technical feasibility of Y"（调研 Y 的技术可行性）

其中第 2 项对接 /playtest-report 技能：该技能把试玩记录整理为 Feel/Accessibility、Bugs Observed、Design Feedback、Next Steps 四段式报告，多人试玩时还会标注 Majority/Minority 意见分布，可直接回填本模板第 11 章。

放弃归档（If Abandoning）：

[Task 1]: "Archive prototype with this document"（将原型与本文档一并归档）
[Task 2]: "Extract reusable code/learnings"（提取可复用代码与经验）
[Task 3]: "Update game pillars if this changed thinking"（若实验改变了认知则更新设计支柱）

第 3 项体现了闭环意识：原型实验的失败同样可能修正设计支柱本身——这正是第 6 章"玩家心理洞察"的延伸价值。

9. 章节十至十二：技术注记、试玩反馈与关联作品

9.1 技术注记（Technical Notes）

记录原型实现的技术底细，供生产团队评估：

原型实现：

Language/Engine：使用的语言/引擎；
Architecture：实现结构；
Shortcuts taken：哪些部分是 hacky 或一次性实现。

可复用代码（Reusable Code）：以文件路径清单登记：

- `[file/path 1]`: [What it does, reusability] - `[file/path 2]`: [What it does, reusability]

技术债（Technical Debt）：列出进入生产前必须重写或补正实现的部分。

9.2 试玩反馈（Playtest Feedback）

该章标注"(If prototype was playtested)"，即仅在真实试玩后填写。结构包括：

Testers: [N people, [internal/external]]（人数与内/外部来源）
Positive Feedback/Negative Feedback：引述格式"[Quote 1]" — [Tester name/role]
Suggestions：建议引述
Themes：跨测试者共识，例如[Theme 1]: [What multiple testers agreed on]

多人试玩时，可参照 /playtest-report 规格的聚合逻辑：多数意见标注 "Majority (2/3)"，少数意见标注 "Minority (1/3)"，全员复现的 Bug 标注 "All testers"。

9.3 关联作品（Related Work）

Inspired By：受哪些游戏/机制启发，借鉴了什么；
Differs From：与既有方案的不同点（独特性声明）；
Integrates With：与现有游戏系统的集成点——例如"抓钩与移动系统、战斗系统、关卡编辑器如何衔接"。

10. 章节十三与十四：开放问题与原型资产附录

10.1 开放问题（Open Questions）

把尚未定论的问题显式归档，分为设计问题与技术问题两类：

Design Questions:

[Question 1]: [What's still undecided about the design?]
[Question 2]: [What needs playtesting or iteration?]

Technical Questions: 3.[Question 3]: [What technical unknowns remain?] 4.[Question 4]: [What needs feasibility testing?]

开放问题是文档的生命力所在——它明确告诉评审者"我们知道我们不知道什么"，避免把未验证的假设伪装成结论。这些未决项应回流到第 9 章的行动清单中。

10.2 原型资产附录（Appendix: Prototype Assets）

对原型遗留物做最终盘点，分三类并各带状态标记：

Code：位置prototypes/[name]/src/；状态Archival | Partial reuse | Full reuse；
Art/Audio（若有）：位置prototypes/[name]/assets/；状态Placeholder | Production-ready | Needs replacement；
Documentation：README: [Exists | Missing]、Build instructions: [Exists | Missing]。

对照 prototype 技能规格，原型会话应已产出prototypes/[name]/findings.md（含 tested/worked/didn't-work/recommendation 四要素）；本附录负责把该 findings 文档与代码、资产、README 的完整归档状态对齐。

11. 版本历史与最终裁决

11.1 版本历史（Version History）

模板要求以表格维护文档演进记录：

Date	Author	Changes
[Date]	Claude (reverse-doc)	Initial concept doc from prototype analysis
[Date]	[User]	Clarified outcomes, added playtest feedback

首行固定署名为Claude (reverse-doc)（表明初稿由反向文档化生成），后续由用户补充澄清结论与试玩反馈——这与 docs/examples/reverse-document-workflow-example.md 中"Agent 提问澄清 → 用户修正意图 → 文档匹配现实并捕捉愿景"的协作模式完全一致。

11.2 最终裁决（Final Recommendation）

文档以三态结论收尾：

Final Recommendation: [GO | NO-GO | PIVOT]
Rationale: [1-2 sentence summary of why]

Rationale 需用 1～2 句话给出理由，并应在第 7 章评估、第 8 章支柱对齐、第 5 章经验教训之间建立明确因果链。一个高质量的裁决示例：

Final Recommendation: GORationale: 抓钩核心循环在 8 人试玩中获得 6 人"有趣"评价，技术可行性已验证（原型 60% 代码可复用），且与"垂直探索"支柱强对齐；剩余工作量集中于手感打磨与 UI，评估为 Medium。

12. 模板使用速查：从 /prototype 到概念文档的完整路径

综合以上各章，在 CCGS 中使用该模板的推荐完整路径为：

/prototype [mechanic-name] │ 构建原型（prototypes/[name]/，刻意粗糙、隔离于 src/） │ 产出 findings.md（tested/worked/didn't-work/recommendation） ▼ /reverse-document concept prototypes/[name] │ 依据本模板生成概念文档 │ 记录原型假设、成败、经验、资产 ▼ （可选）/playtest-report → 多人试玩数据回填第 11 章 ▼ 评审与决策：第 7 章 GO/NO-GO/PIVOT + 第 8 章支柱对齐 + 第 13 章开放问题 ▼ GO → /design-system [system-name] 正式化为 8 章节 GDD → /architecture-decision 记录技术方案 ADR NO/PIVOT → 归档原型与本文档，提取可复用代码，更新设计支柱

各步骤对应的仓库依据：

环节	仓库依据
模板本体	.claude/docs/templates/concept-doc-from-prototype.md
原型技能规格（构建/findings/裁决）	CCGS Skill Testing Framework/skills/utility/prototype.md
反向文档化技能规格（代码→设计文档）	CCGS Skill Testing Framework/skills/utility/reverse-document.md
反向文档化实战示例（技能树系统）	docs/examples/reverse-document-workflow-example.md
GDD 正式化技能（8 章节骨架）	CCGS Skill Testing Framework/skills/authoring/design-system.md
试玩报告技能（四段式+多数/少数意见）	CCGS Skill Testing Framework/skills/utility/playtest-report.md
概念阶段工作流（brainstorm→概念文档→闸门）	docs/WORKFLOW-GUIDE.md
协作式设计原则（提问模式与澄清协议）	docs/COLLABORATIVE-DESIGN-PRINCIPLE.md

使用注意：模板中的[占位符]全部为必填项，生成文档时逐项替换，不要保留任何[X]样式占位符；Complexity、Effort、Alignment、Reusability等字段必须使用模板给定的枚举取值，保证裁决与统计口径一致；文档生成后建议先运行/design-review校验结构完整性（对应 WORKFLOW-GUIDE 第 1.2 步），再进入正式设计流程。