从原型到概念文档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-StudiosCCGS中通过快速原型验证游戏机制的开发者与设计团队。本文以.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 PrototypePrototype Path原型在仓库中的存放路径prototypes/[name]/Date文档创建日期2026-09-12Creator创建者[User name]Outcome原型总体结论Success \| Partial Success \| Failed \| Needs More Testing1.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/避免污染生产代码。耗时与复杂度DurationTime spentX 小时/天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 Didnt Work同样分为机制失败与技术失败但每条必须回答根因与可修复性❌ [Failure 1]: [What didnt 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 4PROTOTYPE ABANDONED 场景当机制被证实不可行时findings.md必须记录具体的失败原因而非模糊描述例如输出不连贯、玩家困惑、技术复杂度过高并建议替代方向如用精选对话替代程序化生成。本模板第 4 章与第 9 章Next Steps正是承接这一要求的正式落点第 4 章记录失败第 9 章据此给出归档或转向的行动清单。5. 章节五与六待打磨项与关键经验5.1 需要打磨什么What Needs Refinement该章针对有潜力但不成熟的元素每条记录三要素⚠️ [Element 1]: [What showed promise but needs work] - **Issue**: [Whats 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 InsightsImplication 指向架构或实现指引——例如事件总线在原型中的高频事件下性能可接受但生产环境应改用批处理。玩家心理洞察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 | LargePrototype reusability: [X%] of code can be kept原型代码可保留比例From-scratch effort: [X hours/days to production-ready]从零重写耗时若 No——说明原因模板提供三个典型否决理由方向Fun but doesnt 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 概念阶段定义 35 条不可妥协的设计价值见 WORKFLOW-GUIDE 的 concept document 清单。本章以表格形式逐一评估原型机制与每条支柱的关系PillarAlignmentNotes[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 WorkInspired By受哪些游戏/机制启发借鉴了什么Differs From与既有方案的不同点独特性声明Integrates With与现有游戏系统的集成点——例如抓钩与移动系统、战斗系统、关卡编辑器如何衔接。10. 章节十三与十四开放问题与原型资产附录10.1 开放问题Open Questions把尚未定论的问题显式归档分为设计问题与技术问题两类Design Questions:[Question 1]: [Whats 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 reuseArt/Audio若有位置prototypes/[name]/assets/状态Placeholder | Production-ready | Needs replacementDocumentationREADME: [Exists | Missing]、Build instructions: [Exists | Missing]。对照 prototype 技能规格原型会话应已产出prototypes/[name]/findings.md含 tested/worked/didnt-work/recommendation 四要素本附录负责把该 findings 文档与代码、资产、README 的完整归档状态对齐。11. 版本历史与最终裁决11.1 版本历史Version History模板要求以表格维护文档演进记录DateAuthorChanges[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 需用 12 句话给出理由并应在第 7 章评估、第 8 章支柱对齐、第 5 章经验教训之间建立明确因果链。一个高质量的裁决示例Final Recommendation: GORationale: 抓钩核心循环在 8 人试玩中获得 6 人有趣评价技术可行性已验证原型 60% 代码可复用且与垂直探索支柱强对齐剩余工作量集中于手感打磨与 UI评估为 Medium。12. 模板使用速查从 /prototype 到概念文档的完整路径综合以上各章在 CCGS 中使用该模板的推荐完整路径为/prototype [mechanic-name] │ 构建原型prototypes/[name]/刻意粗糙、隔离于 src/ │ 产出 findings.mdtested/worked/didnt-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.mdGDD 正式化技能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 步再进入正式设计流程。【免费下载链接】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），仅供参考 从原型到概念文档：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-StudiosCCGS中通过快速原型验证游戏机制的开发者与设计团队。本文以.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 PrototypePrototype Path原型在仓库中的存放路径prototypes/[name]/Date文档创建日期2026-09-12Creator创建者[User name]Outcome原型总体结论Success \| Partial Success \| Failed \| Needs More Testing1.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/避免污染生产代码。耗时与复杂度DurationTime spentX 小时/天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 Didnt Work同样分为机制失败与技术失败但每条必须回答根因与可修复性❌ [Failure 1]: [What didnt 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 4PROTOTYPE ABANDONED 场景当机制被证实不可行时findings.md必须记录具体的失败原因而非模糊描述例如输出不连贯、玩家困惑、技术复杂度过高并建议替代方向如用精选对话替代程序化生成。本模板第 4 章与第 9 章Next Steps正是承接这一要求的正式落点第 4 章记录失败第 9 章据此给出归档或转向的行动清单。5. 章节五与六待打磨项与关键经验5.1 需要打磨什么What Needs Refinement该章针对有潜力但不成熟的元素每条记录三要素⚠️ [Element 1]: [What showed promise but needs work] - **Issue**: [Whats 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 InsightsImplication 指向架构或实现指引——例如事件总线在原型中的高频事件下性能可接受但生产环境应改用批处理。玩家心理洞察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 | LargePrototype reusability: [X%] of code can be kept原型代码可保留比例From-scratch effort: [X hours/days to production-ready]从零重写耗时若 No——说明原因模板提供三个典型否决理由方向Fun but doesnt 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 概念阶段定义 35 条不可妥协的设计价值见 WORKFLOW-GUIDE 的 concept document 清单。本章以表格形式逐一评估原型机制与每条支柱的关系PillarAlignmentNotes[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 WorkInspired By受哪些游戏/机制启发借鉴了什么Differs From与既有方案的不同点独特性声明Integrates With与现有游戏系统的集成点——例如抓钩与移动系统、战斗系统、关卡编辑器如何衔接。10. 章节十三与十四开放问题与原型资产附录10.1 开放问题Open Questions把尚未定论的问题显式归档分为设计问题与技术问题两类Design Questions:[Question 1]: [Whats 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 reuseArt/Audio若有位置prototypes/[name]/assets/状态Placeholder | Production-ready | Needs replacementDocumentationREADME: [Exists | Missing]、Build instructions: [Exists | Missing]。对照 prototype 技能规格原型会话应已产出prototypes/[name]/findings.md含 tested/worked/didnt-work/recommendation 四要素本附录负责把该 findings 文档与代码、资产、README 的完整归档状态对齐。11. 版本历史与最终裁决11.1 版本历史Version History模板要求以表格维护文档演进记录DateAuthorChanges[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 需用 12 句话给出理由并应在第 7 章评估、第 8 章支柱对齐、第 5 章经验教训之间建立明确因果链。一个高质量的裁决示例Final Recommendation: GORationale: 抓钩核心循环在 8 人试玩中获得 6 人有趣评价技术可行性已验证原型 60% 代码可复用且与垂直探索支柱强对齐剩余工作量集中于手感打磨与 UI评估为 Medium。12. 模板使用速查从 /prototype 到概念文档的完整路径综合以上各章在 CCGS 中使用该模板的推荐完整路径为/prototype [mechanic-name] │ 构建原型prototypes/[name]/刻意粗糙、隔离于 src/ │ 产出 findings.mdtested/worked/didnt-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.mdGDD 正式化技能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 步再进入正式设计流程。【免费下载链接】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），仅供参考