3 游戏项目生命周期

文档信息

目标读者： 制作人、项目经理、团队核心成员

阅读收益： 理解游戏项目分阶段管理的核心方法，掌握六个阶段划分标准，学会根据团队规模裁剪流程

在游戏项目管理中，项目生命周期是基础概念，指将游戏项目从启动到上线的主要工作划分成几个界限明确的阶段，如概念探索、预制作、全面制作、打磨与上线等。

各阶段之间设置关键评审点。公司管理层、制作人在评审点验收阶段成果，评估版本质量、设计完成度和开发进度，决定项目能否进入下一阶段。

分阶段管理的目的是在关键节点暴露问题，减少后期返工，降低项目风险。

评审点为开发过程提供决策依据。团队与决策者基于评审结果，判断项目应该继续推进还是暂停调整。

评审决策的三种结果

返回修改：针对问题进行调整，重新发起评审

补充验证：补充数据或原型，再次验证后评审

项目终止：仅在核心玩法验证失败、商业模型不可行等根本性问题时考虑

成功的游戏项目需要依次通过多个里程碑评审。品质在评审过程中得到验证和提升，最终达到上线标准。

早期决策影响

早期阶段（概念探索与预制作）的决策影响深远，几乎决定项目生死。游戏核心概念、目标用户、核心玩法、美术风格及技术选型等根本性决策一旦确定，其影响贯穿整个开发流程，直至游戏上线和后续运营。

将开发目标拆分为可控的阶段，是把复杂系统工程转化为更易管理的小模块。负责人在每个阶段投入可控资源，基于交付物和考核指标评估成果，控制进度、成本与风险。

宏观阶段划分总结

1 宏观阶段一：可行性评估

• • 阶段一：概念探索

2 宏观阶段二：方案论证

• • 阶段二：预制作

3 宏观阶段三：游戏开发和运营

• • 阶段三：全面制作
• • 阶段四：打磨与上线
• • 阶段五：运营
• • 阶段六：停服收尾

宏观阶段划分说明

游戏生命周期的定义规范

游戏项目生命周期通常划分为六个阶段：1. 概念探索2. 预制作3. 全面制作4. 打磨与上线5. 运营6. 停服收尾不同规模团队可根据实际情况裁剪。

游戏生命周期示意图

图3.0-1 游戏项目生命周期，明确了各阶段的关键决策点和评审点。![[游戏项目生命周期评审点.jpg]]

• • 图3.0-1 游戏项目生命周期示意图

阶段一：概念探索

核心目标：克服"白纸问题"，从无到有地产生、筛选并确定游戏的核心创意，为项目确立明确的方向。

关键任务：

1. 1. 创意发散与筛选：通过头脑风暴、竞品分析、趋势研究等方式产生创意，并建立筛选标准。
2. 2. 深度调研：通过文献调研、竞品分析、实地考察、用户访谈等方式为创意寻找依据。
3. 3. 早期原型设计：快速制作简单的趣味原型、实物原型或局部数字原型，验证核心玩法的可行性。
4. 4. 核心创意提炼：定义游戏的核心幻想（Core Fantasy），围绕"为玩家提供何种独特体验"来构建。

关键交付物：

• • 项目目标（体验目标与设计目标）
• • 创意文档初稿（项目蓝图、游戏设计文档等）
• • 早期原型

评审通过标准：

• • 核心创意明确，能回答"这款游戏为谁提供什么独特体验"
• • 项目目标获得决策层认可

阶段二：预制作

核心目标：将核心想法转化为可玩原型（垂直切片），通过快速循环验证核心玩法的可行性。

关键任务：

1. 1. 目标驱动的原型制作：针对具体问题制作原型。实物原型侧重验证规则，成本低；数字原型侧重验证操作和技术可行性。
2. 2. 频繁的试玩测试：让目标玩家尽早试玩，观察其行为而不加干预，收集真实反馈。
3. 3. 快速评估与迭代：基于测试反馈，决定对原型进行保留、修改或舍弃，并迅速进入下一个"制作-测试"循环。
4. 4. 技术风险识别：评估关键技术点的可行性，识别技术瓶颈和风险。
5. 5. 市场营销预热：发布概念预告、开发日志，开始社区建设，积累早期种子用户。
6. 6. 版号申请：准备并提交版号申请所需的游戏版本。

关键交付物：

• • 垂直切片
• • 详细设计文档（技术设计文档、系统设计文档等）
• • 基于验证结果确定的项目目标
• • 技术风险评估报告

评审通过标准：

• • 垂直切片通过绿灯评审，核心玩法验证通过
• • 技术风险已识别并有应对方案

阶段三：全面制作

核心目标：将已验证的游戏设计转化为功能完整的游戏产品。

关键任务：

1. 1. 大规模内容生产：包括程序开发、美术资产制作、音频创作、关卡构建和叙事内容整合。通常采用同心开发策略——从核心玩法层向外围内容层逐层扩展，先完成核心机制的闭环，再逐步添加外围系统。
2. 2. 系统集成与持续验证：将独立开发的模块整合到统一版本中，进行日常自动化测试或定期用户测试。
3. 3. 试玩测试：验证核心循环（Core Loop）是否成立，主要功能是否可用。识别玩家在核心玩法中的困惑点。
4. 4. 里程碑评审：在关键节点向资方、发行方等相关方展示版本，获取反馈与认可。
5. 5. 市场营销活动：定期发布开发日志、玩法展示、媒体合作，持续对外传递项目进展。

关键交付物：

• • Alpha版本（内部可玩版本）：核心功能全部实现并可完整试玩

评审通过标准：

• • Alpha版本功能完备（Feature Complete），核心循环可从头到尾跑通
• • 无阻断性Bug阻塞主流程

阶段四：打磨与上线

核心目标：验证体验、确保质量、完成发布准备，将游戏稳定交付给目标平台和市场。

关键任务：

1. 1. 全面测试：Beta里程碑后，进行多轮测试，发现并修复缺陷。
• • 试玩测试：验证完整体验的流畅度，收集对打磨和平衡性的反馈
• • 质量保证测试：系统性地发现和报告程序错误（Bug）、性能问题
• • 兼容性与认证测试：确保游戏在目标硬件或平台上稳定运行，满足平台方技术规范
2. 2. 性能优化：针对帧率、内存、加载时间等进行专项优化，确保目标平台流畅运行。
3. 3. 版本定稿与认证：完成最终打包，通过各平台的官方认证，处理内容分级审核，构建发布候选版本。
4. 4. 市场定位与营销：制定市场定位和定价策略，开展发售前宣传活动。
5. 5. 渠道上架：准备商店页素材，完成各平台商店页面部署。
6. 6. 发布支持：准备首日补丁，启动客服与社区管理，服务器部署。
7. 7. 应急预案：准备服务器扩容方案、回滚机制、紧急修复流程，应对上线首日的突发问题。
8. 8. 项目复盘：进行项目事后回顾，总结经验教训。

关键交付物：

• • Beta版本（内容完整版本）：所有计划功能均已实现，内容齐全
• • Bug数据库与测试报告
• • 试玩测试反馈分析报告
• • 性能优化报告
• • 发布候选版本（Release Candidate）
• • 最终版游戏文件（各平台适配的构建版本）
• • 平台认证证书与内容分级证明
• • 平台商店资料包
• • 营销与新闻资料包
• • 发布计划与检查清单
• • 应急预案文档
• • 项目总结报告

评审通过标准：

• • Beta版本内容完备（Content Complete），性能达标
• • 平台认证通过，发布候选版本就绪

阶段五：运营

核心目标：维持并延长游戏的生命周期，服务现有玩家、优化体验并实现持续的商业成功。

关键任务：

1. 1. 用户洞察：基于数据分析，理解玩家需求和行为，识别用户流失原因。
2. 2. 内容与版本更新：规划并制作新的玩法、角色、活动等长线内容，维持玩家活跃度。
3. 3. 运营活动设计：设计并执行游戏内的限时活动、促销等，平衡活跃度与收入。
4. 4. 商业化运营：监控和优化付费点设计，提升游戏的持续收入能力。
5. 5. 数据分析监控：收集分析核心指标（DAU、留存率、ARPU、LTV等），驱动决策。
6. 6. 质量维护：进行兼容性、性能测试，发布补丁修复问题。
7. 7. 社区管理与支持：与玩家社区互动，收集反馈并提供支持。

关键交付物：

• • 持续的版本更新（游戏补丁与资料片）
• • 稳定的线上服务
• • 运营活动成果
• • 数据分析报告

阶段六：停服收尾

核心目标：安全结束服务，妥善处理玩家数据与项目资产，完成知识沉淀。

关键任务：

1. 1. 终止计划公示：提前公告停服时间，停止内购充值，制定老玩家补偿方案。
2. 2. 社区情绪管理：根据游戏类型选择合适的方案（离线模式、数据导出、服务器代码开源、玩家数据迁移等）。
3. 3. 服务器拆除与数据脱敏：安全关闭服务器集群，对玩家数据进行符合法规的处理。
4. 4. 法律合规：处理GDPR等数据合规下的玩家数据留存/删除策略。
5. 5. 资产与代码归档：将项目源码、美术工程、开发文档进入企业知识库。
6. 6. 项目终极复盘：总结整个生命周期的盈亏、流程得失。

关键交付物：

• • 停服方案公告
• • 项目最终归档报告
• • 全周期财务结算表
• • 项目总结报告

不同规模团队的适用性

生命周期的灵活调整

不同项目类型需要针对性的生命周期调整：

调整原则

1. 1. 保留关键评审点
2. 2. 根据项目风险调整阶段长度
3. 3. 确保每个阶段都有明确的交付物
4. 4. 灵活应对市场变化

不同项目类型的调整

附录：7 Gates 评审法

Gate 0: Concept / Pitch - 概念准入

• • 目标： 确定"核心玩法"和"市场定位"。
• • 评审形式： 概念文档（Pitch Document）演示，回答"这款游戏是什么、为谁做、凭什么赚钱"。

Gate 1: First Playable - 原型评审

• • 目标： 验证核心玩法循环（Core Loop）。
• • 评审形式： 可玩原型演示，美术允许使用占位资源（行业俗称"方块人"）。评审重点：核心循环是否成立、操作手感是否对、玩家能否理解规则。

Gate 2: Vertical Slice - 垂直纵切 —— 最关键的评审点

• • 目标： 在极小范围内达到"最终出街质量"。
• • 评审形式： 一个达到最终品质的完整游戏片段（通常为一个关卡或一个区域）演示。
• • 评审重点： 美术是否达到目标品质、玩法是否有足够深度、技术管线能否支撑量产、完整体验是否成立。通过即"绿灯"（Greenlight），公司据此决定是否投入预算进入大规模量产。

Gate 3: Pre-Production Exit - 预研结束

• • 目标： 确认管线、工具、文档全部就绪，可以承载数百人规模的并行开发。

Gate 4: Alpha - 功能完备

• • 目标： 游戏从头到尾可以玩通，所有核心系统已实装。
• • 评审形式： 完整通关演示（Full Playthrough），从启动到结局连续走完全流程。
• • 评审重点： 所有承诺功能是否已实装、系统之间联动是否正常、流程是否连贯、是否存在阻断性 Bug。

Gate 5: Beta - 内容完备

• • 目标： 资源全部进场（Content Complete），不再增加新功能。
• • 评审形式： 全量内容巡查，逐模块核对接档清单与实际交付。
• • 评审重点： 所有关卡/角色/剧情/音效是否到位、资源是否达到目标品质、是否存在占位资源遗漏、功能锁定（Feature Lock）是否严格执行。

Gate 6: Certification / Gold - 送审/金盘

• • 目标： 通过主机平台（Sony/Microsoft/Nintendo）的各项准入测试。

附录：12 Gates 评审法

第一阶段：概念与启动 (Concept & Initiation)

• • Gate 1: Concept Approval（概念通过）
• • 评审内容： 确定“我们要传达什么体验”。包括核心玩法（High-level Pitch）、目标受众、预期市场表现。
• • Gate 2: Project Kick-off（项目启动）
• • 评审内容： 建立核心团队（骨干力量），明确预算范围，开始进行早期的艺术风格探索和技术调研。
• • Gate 3: Feasibility Study（可行性研究）
• • 评审内容： 验证技术难点。例如：引擎是否能支持超大规模地图？AI 系统是否能实现预想的复杂度？

第二阶段：预制作 (Pre-Production)

• • Gate 4: Prototype Completion（原型完成）
• • 评审内容：最重要的节点之一。 必须有一个“可玩的原型”（First Playable）。验证核心循环（Core Loop）是否真的好玩。
• • Gate 5: Vertical Slice（纵向切片）
• • 评审内容： 制作一段达到最终上市品质的游戏片段（通常 10-15 分钟）。它代表了游戏的“最高品质标准”，用于向总部申请进入正式的大规模量产。
• • Gate 6: Full Production Readiness（量产准备就绪）
• • 评审内容： 确认管线（Pipeline）已打通。所有工具、资源包、外包渠道都已就绪，团队准备好从几十人扩张到几百人。

第三阶段：正式量产 (Production)

• • Gate 7: Mid-Production Review（量产中进度审核）
• • 评审内容： 检查内容产出速度。是否能按时完成所有关卡？资源消耗是否在预算内？
• • Gate 8: Alpha Ready（Alpha 版准备）
• • 评审内容：功能完备（Feature Complete）。 游戏从头到尾可以跑通，虽然还有很多 Bug，贴图可能也是占位符，但所有系统都已经实装。
• • Gate 9: Beta Ready（Beta 版准备）
• • 评审内容：内容完备（Content Complete）。 美术资源全部进场，开始进入高强度的 Debug 和平衡性调整阶段。

第四阶段：收尾与发布 (Closing & Launch)

• • Gate 10: Submission Readiness（送审准备）
• • 评审内容： 针对平台方（Sony, Microsoft, PC）的准入标准进行测试。确保没有会导致死机或违规的致命错误。
• • Gate 11: Gold Master（金盘/发售版）
• • 评审内容： 最终版本锁定。准备压盘或上传服务器。同时确定“首日补丁”（Day 1 Patch）的内容。
• • Gate 12: Post-Mortem & Live Operations（复盘与线上运营）
• • 评审内容： 团队总结经验教训。对于像《全境封锁》或《彩虹六号》这类服务型游戏，此节点也标志着进入长期内容更新阶段。

两种体系对比

附录：各阶段常见问题与建议

在项目生命周期的每个阶段，都可能遇到典型问题。以下是各阶段的常见误区与建议做法：

概念探索阶段

预制作阶段

全面制作阶段

打磨与上线阶段

运营阶段

停服收尾阶段

3.1 项目规划和论证

文档信息

写给谁：制作人、项目负责人、技术负责人、管理层

阅读收益：掌握项目规划与论证的完整流程，学会根据项目规模裁剪工作，降低立项风险

在规划与论证阶段，团队需要回答两个问题：这个项目能不能做？值不值得做？通过分析和验证确认项目可行性，避免"先上马再说"导致的后期浪费。

规划工作的启动方式因团队规模而异：

大型公司：决策部门（如总办）下达授权文件，批准负责人（制作人、创意总监、项目总监等）启动规划工作，输出正式的项目规划说明书（详见第3节工作清单），由系统架构师负责技术规划。

中型团队：由制作人或项目负责人发起，经管理层确认后启动，输出项目规划文档（详见第3节工作清单），技术负责人主导技术方案。

小团队/独立开发者：由开发者自己决定启动，可以简化文档形式（如一页纸的规划清单），自己或与合作伙伴讨论确认。

不同体量的游戏分类

规划与论证的深度取决于项目体量。本节先对游戏体量进行分类，下一节再对比各类项目的规划差异。

小型游戏/独立游戏

以玩法实验性和独特艺术风格为核心，主要成本为开发者的生活开支。团队通常1-5人，开发周期6-18个月。

代表作品：《空洞骑士》、《星露谷物语》、《小丑牌》、《传说之下》

中型游戏

由经验较丰富的团队开发，在玩法创新和艺术表达上追求较高完成度（常被称为"精品独立游戏"）。团队通常5-20人，开发周期1-2年。

代表作品：《师父》、《茧》、《河洛群侠传》

2A游戏

中等预算，在特定维度（玩法创新、故事深度或艺术风格）追求突破。团队通常20-80人，开发周期2-4年。

代表作品：《双人成行》、《地狱之刃》

3A游戏

高预算、大规模、高品质。追求极致视听效果、庞大世界观与电影化叙事，通常伴随高额营销投入。团队通常100人以上，开发周期3-7年。

代表作品：《GTA5》、《艾尔登法环》、《黑神话：悟空》

分类说明以上分类仅供参考，实际项目存在边界模糊的情况。关键是理解不同体量项目的核心特点，而不是纠结于具体作品的分类。

不同体量项目的规划与论证差异

调整原则：

• • 核心玩法验证和成本估算——所有项目都必须做，不可裁剪
• • 商业可行性——根据商业模式的复杂度调整深度
• • 技术预研——根据技术风险调整深度
• • 评审流程——根据项目规模调整严格程度和参与人员

游戏规划与论证工作清单

目的

确保游戏商业模式成立，并符合公司及管理层的目标。

论证阶段主要事务

核心事务（所有项目都必须做）

• • 明确需求方与目标玩家

  1. 操作方法：明确出资方（公司/发行商/自己）的期望，通过用户画像、市场调研、竞品分析确定目标玩家  2. 输出：目标用户画像文档（1-2页）

• • 基于玩家需求进行游戏设计

  1. 操作方法：从用户需求反推设计目标，避免凭直觉设计  2. 输出：核心体验目标（3-5条）

• • 核心玩法验证

  1. 操作方法：通过原型测试、试玩测试等方式验证核心玩法的趣味性和技术可行性  2. 输出：可玩的灰盒原型或纸面原型

• • 初始成本估算

  1. 操作方法：核心玩法验证通过后，基于验证结果和功能清单估算人力和时间成本  2. 输出：成本估算表（含人力、时间、外包等）

重要事务（根据项目规模决定）

• • 识别项目风险并分类

  1. 操作方法：梳理项目面临的技术风险、市场风险、政策风险，与管理层确认风险等级  2. 输出：风险分类清单

• • 确定游戏商业模式

  1. 操作方法：分析同类产品的收入结构和盈利路径，确认与公司战略一致  2. 输出：商业模式说明（1页）

• • 制定游戏开发管线建设方案

  1. 操作方法：评估现有管线能否支撑项目需求，列出需要新建或改造的环节  2. 输出：管线建设清单

• • 开展必要的技术探索与可行性论证

  1. 操作方法：针对识别出的技术风险点，进行原型验证或技术选型对比  2. 输出：技术可行性报告

• • 将启动条件与判定准则文档化

  1. 操作方法：将启动条件和判定标准写入正式文档，作为后续阶段的验收依据  2. 输出：启动条件检查表

可选事务（大型项目推荐做）

• • 启动关联技术的预研与开发

  1. 操作方法：对需要长期投入的技术模块提前启动研发  2. 输出：预研成果演示或技术验证报告

• • 预估运营阶段收益

  1. 操作方法：预估首年收入、月流水、回本周期等关键财务指标，写入项目规划说明书  2. 输出：收益预期表（含乐观/中性/悲观三种情景）

• • 裁剪原则：

  1. 小团队可以简化文档形式，但不能省略核心思考  2. 评审可以非正式，但必须有决策记录

需进行的评审

规划与论证的目标是帮助团队做出正确决策。如果分析结果不可行，应调整或终止，而不是粉饰数据强行通过。

阶段退出条件

满足以下条件，项目可进入预制作阶段：

• • 核心玩法验证通过（原型测试获得目标玩家正面反馈）
• • 成本估算完成并获批
• • 关键技术风险已有应对方案
• • 商业模式获得管理层认可
• • 评审全部通过，决策记录归档

规划关键要素游戏规划与论证阶段的核心在于：

1. 1. 目标与需求对齐（明确谁来玩、怎么玩）
2. 2. 核心玩法验证（确认好玩且能做）
3. 3. 成本与收益估算（确认值得做）
4. 4. 风险识别与管理（知道哪里可能出问题）
5. 5. 评审与决策（通过正式流程做出判断）

附录：规划与论证案例

案例：某独立游戏项目的规划与论证

项目背景：8人团队，动作类独立游戏，目标开发周期12个月

一、启动方式

制作人发起，与公司管理层确认后启动规划工作。

二、核心事务执行

三、评审结果

• • 初始构想评审：通过，核心概念清晰
• • 玩法设计评审：修改后通过，核心战斗节奏调整了2次
• • 玩法定义评审：通过，进入预制作阶段

四、关键经验

• • 核心玩法验证花费6周，在试玩测试中发现3个关键设计问题，原型阶段每个问题的修复成本不到1天；如果推迟到全面制作阶段修复，单个问题预计需要数周
• • 成本估算识别出2个预算盲区（外包动画的返工成本、多平台适配的额外工期），在规划阶段就补充了应对方案

教训：6周的原型验证投入，换来了3个设计问题的早期修复和2个预算盲区的提前识别。

案例：某团队跳过原型验证的失败教训

项目背景：5人团队，策略类独立游戏，目标开发周期8个月

问题：团队对核心玩法充满信心，跳过了原型验证，直接进入全面制作。4个月后进行首次外部测试，发现核心循环存在致命问题——玩家在30分钟后失去兴趣，策略深度不够，决策反馈太弱。

后果：

• • 推翻核心循环，重新设计策略系统和反馈机制，浪费4个月
• • 实际开发周期从8个月延长到14个月
• • 团队士气严重下降，1名成员中途退出

教训：4个月的开发成果被推翻，项目周期延长75%。如果在规划阶段用2-4周做原型验证，这些问题在第一周就能暴露。

附录：常见误区与避坑指南

误区：为了过审而写虚假的可行性报告

后果： 后期发现问题时，返工成本远超前期节省的时间

避坑： 把可行性分析当作真正的决策工具，而不是应付评审的材料。如果分析结果不可行，应调整或终止，而不是粉饰太平。

行业现象：部分项目在立项时明知风险，仍虚报预期收入、低估开发成本，只为获得管理层批准。项目进入全面制作后才发现预算严重不足，被迫砍功能、缩规模或追加投资。

误区：跳过核心玩法验证

后果： 开发数月后发现核心循环不成立，被迫推翻重做

避坑：

• • 哪怕是最简单的方块原型，也要先验证核心玩法
• • 原型验证的时间投入与项目规模正相关（独立游戏1-3周，中型项目1-2个月，大型项目3-6个月）
• • 原型测试要找目标玩家，不要只在自己团队内部测试

行业现象：很多团队在纸上设计时认为玩法成立，但实际做出来发现玩家不买账。核心循环的问题越早发现，修复成本越低。

误区：过度乐观，低估外部风险

后果： 预算超支、延期、质量下降

避坑：

• • 做最坏情况的预算（在预期基础上增加20-30%）
• • 预留缓冲时间（开发周期的15-20%）
• • 识别Top 5风险点，制定应对预案

行业现象：团队并非有意隐瞒风险，而是真心相信"能做到"，结果低估了美术外包的迭代成本、平台审核周期、政策变化等外部不确定性。某中型项目初期预算200万，最终花费380万，超支90%。

误区：高估团队能力

后果： 目标超出团队实现能力，项目延期或质量不达标

避坑：

• • 实事求是评估团队的技术能力和产能
• • 根据团队能力调整项目范围，而不是先定目标再压团队执行
• • 如果团队缺乏某方面能力，要么提前培养，要么外包

行业现象：新成立的团队常以成熟团队的速度估算工期，忽略了磨合期的效率损失。实际产能通常只有预估的60-70%。

误区：小团队觉得"系统工程不适合我们"

后果： 重复犯别人已经犯过的错误

避坑：

• • 系统工程不是复杂的流程，而是科学的决策方法
• • 小团队可以简化形式（一页纸清单、团队讨论记录），但不能省略核心思考
• • 参考同规模成功项目的经验，避免重复踩坑

行业现象：很多独立开发者认为"流程"是大公司的事，结果在原型验证、成本估算等环节跳步，导致后期反复推翻重做——这些问题用一页纸的清单就能避免。

3.2 游戏开发阶段评审

文档信息

写给谁：制作人、项目负责人、技术负责人、管理层、QA

阅读收益：掌握不同规模游戏的阶段评审机制，学会组织评审流程、准备评审材料、处理评审不通过情况

评审概述与类型定义

管理团队在项目各阶段设置评审点，评估项目方向、质量与进度。

评审按触发方式分为两类：常规进度评审（按固定频率执行）和里程碑评审（在关键节点触发，如Alpha、Beta、上线前）。

按评审目的分为三类：

分阶段评审的目的是让问题及早暴露、及早解决。游戏开发周期长、投入大，缺少阶段性检查，后期发现问题的修复成本呈数量级增长。

项目负责人必须明确项目体量类型（独立/小型、中型、2A/AA或3A），体量类型决定管理流程、评审频率与评估标准。具体对应关系见"不同规模游戏的检查机制"。

独立/小型项目的参与人员独立开发者自行完成评审，无需正式参与人员。小型团队（3-5人）全员参与即可，不区分主持人/必须/可选。

不同规模游戏的检查机制

独立/小型游戏

• • 评审形式：自我审视或与合作伙伴讨论
• • 评审频率：根据开发节奏灵活调整，建议每周或每两周一次
• • 评审类型：以进展情况评审为主，里程碑节点（如原型完成、Demo发布）时做落地情况评审
• • 评审重点：
• • 本周完成了什么？下周计划做什么？
• • 当前卡在哪里？需要什么帮助？
• • 核心玩法是否仍然有趣？
• • 预算与时间是否充足？
• • 记录方式：简单笔记或清单即可，不需要正式文档

独立开发者与小团队的区别单人独立开发者没有团队交叉验证，全靠自我判断，建议使用结构化自检清单（参见 附录_评审检查清单模板）。小型团队（3-5人）可在每日站会后做简短进度同步，替代正式评审。

中型游戏

• • 评审频率：根据项目阶段调整
• • 概念探索与预制作阶段：每周1次（快速迭代、频繁对齐）
• • 全面制作阶段：每周1次（常规进度同步）
• • 运营阶段：每两周1次（节奏放缓）
• • 评审类型：进展情况评审（按频率执行）+ 落地情况评审（关键特性完成后）+ 阶段性评审（阶段转换时）
• • 评审重点：进度检查与需求实现状态核对，识别风险与问题

中型游戏的评审频率为什么比2A/AA更高？中型团队（10-30人）结构扁平，沟通成本低，高频评审的执行成本低、收益高。2A/AA项目规模大，评审准备成本高，因此频率降低但深度增加。

2A/AA游戏

2A/AA项目结构复杂、周期长，需要结构化评审体系。

• • 概念探索与预制作阶段：
• • 评审频率：每两周一次
• • 评审类型：以进展情况评审和落地情况评审为主
• • 评审重点：核心玩法可行性（原型是否达到设计意图）、初步资源评估、技术选型风险
• • 全面制作阶段（Alpha后）：
• • 评审频率：每两周或每月一次
• • 评审类型：三类评审均执行
• • 评审重点：项目进展状况与核心特性的落地情况
• • 评审结论作为版本规划与资源投入的决策依据

3A游戏

• • 公司级联动：评审与公司级大型项目评审流程联动，确保本项目融入更大产品生态或系列规划
• • 概念探索与预制作阶段：
• • 评审频率：每两周一次\每月一次（根据团队规模评审分规模拆分）
• • 评审重点：核心玩法验证、技术架构决策、管线搭建、团队组建计划
• • 全面制作阶段后（Alpha后）：
• • 评审频率：每一个月或每季度一次综合性评审
• • 评审内容：进展状况、落地情况及关键决策点（技术选型、内容规模、市场定位等）
• • 评审目的：全面评估项目表现，批准下一阶段详细计划与资源预算

评审流程与交付物

以下流程适用于中型及以上项目。独立/小型项目可简化为自检清单（参见 附录_评审检查清单模板）。

评审前准备

评审后产出

评审不通过处理

适用于落地情况评审和阶段性评审（进展情况评审无通过/不通过结论，发现问题直接转为行动项）。

落地情况评审或阶段性评审结论为"不通过"时，按以下流程处理：

1. 1. 记录不通过原因：明确哪些指标未达标、哪些风险未解决
2. 2. 制定整改计划：指定负责人、整改措施、整改期限（不超过2周）
3. 3. 整改验收：整改期限到达后进行复审
4. 4. 升级处理：连续两次不通过，升级至更高层级决策

连续不通过是预警信号连续两次评审不通过，通常意味着项目存在深层问题（需求不清、资源不足、技术方案有误），需要管理层介入重新评估项目可行性。

附录：评审检查清单模板

以下清单按正文定义的三种评审类型组织。每个检查项标注项目规模适用性（全部\中型及以上\2A/AA及以上）。

进展情况评审检查清单

进展情况评审无"通过/不通过"结论，以下检查项用于识别风险和行动项。

关于"达成率预设值"不同项目阶段和体量的目标达成率标准不同，建议在项目启动时由制作人根据历史数据设定。通常首次设定后不再调整。

落地情况评审检查清单

落地情况评审有"通过/有条件通过/不通过"结论。

关于Bug阈值和性能基线Bug阈值和性能基线应在项目启动时由技术负责人和QA共同定义，不同体量项目标准不同。独立游戏可简化为"核心功能可玩"。

阶段性评审检查清单

阶段性评审有"通过/有条件通过/不通过"结论，用于阶段转换决策。

附录：评审常见问题与解决方案

判断评审频率是否合适的信号频率过高：每次内容重复无新信息、团队抱怨评审占用开发时间、行动项完成率>95%无逾期频率过低：每次堆积大量问题无法充分讨论、团队抱怨问题迟迟得不到决策、行动项完成率<60%大量逾期

不同评审类型的会议结构建议：