适合阶段入门适合读者刚入行或准备入行的学生、转行者以及第一次参与完整项目周期、需要理解“这个阶段该交付什么”的程序员说明里程碑的名称在业界通用但具体定义因公司、项目、合同而异。本文介绍的是最常见的含义实际以所在团队和发行合同的约定为准引子刚进项目组经常会听到这样的对话“下个月要交垂直切片战斗必须是最终品质。”“Alpha 之后不加新功能了有想法先记到下个版本。”“Beta 了现在只修 Bug改动要过评审。”“主机版已经送审这周别往 release 分支上合东西。”“二测是计费删档三测转不删档存档结构要定死了。”这些词描述的都是开发里程碑Milestone项目在某个时间点必须达到的状态。理解里程碑程序员才能知道当前阶段什么事情最重要什么时候可以大改架构什么时候必须“只修不改”自己的工作为什么会被“冻结”“评审”“打回”。这篇文章按时间顺序梳理主要里程碑再对照国内手游常用的测试叫法最后落到程序员在每个阶段的工作重点。一、里程碑全景一个典型的游戏项目从立项到上线大致经历以下阶段预制作Pre-production 制作Production 收尾Finaling 上线后 ─────────────────────────────────── ────────────────────────────── ────────────────────── ────────── 概念 → 原型 → First Playable → 垂直切片 → ……… → Alpha → ……… → Beta → RC → 黄金版 / 上线 → Day One Patch → 运营 │ │ │ │ │ │ │ │ 想法 验证玩法 能完整玩一轮 最终品质样本 功能齐全 内容齐全 候选 正式发布里程碑英文一句话含义典型问题概念Concept想清楚做什么这个游戏值得做吗原型Prototype验证核心玩法这个玩法好玩吗首个可玩版本First Playable核心循环能从头到尾跑通能完整玩一轮吗垂直切片Vertical Slice一小段内容达到最终品质成品大概是什么样做得出来吗AlphaAlpha功能齐全所有系统都实现了吗BetaBeta内容齐全专注修 Bug能发布吗还差什么候选发布版Release CandidateRC可能就是最终版本还有阻断发布的问题吗黄金版Gold Master / Gold最终发布版本——首日补丁Day One Patch上线当天的更新黄金版之后修了什么Alpha、Beta 的说法来自哪里一般认为这对术语源自早期软件工业常被追溯到 IBM的测试阶段命名后来被整个软件行业沿用。游戏行业沿用了名称但赋予了自己的含义。二、预制作阶段回答“做什么”和“做得出来吗”预制作阶段的目标是用尽量小的成本降低不确定性。这个阶段团队较小以策划、主程、主美和少量程序为主。1. 原型Prototype目的验证一个具体问题最常见的是“核心玩法是否好玩”。特点说明快以天或周为单位而不是月粗糙美术用方块、灰盒界面用默认控件一次性原型代码通常不追求质量验证完可以丢弃聚焦一个原型只回答一个或少数几个问题原型不一定只验证玩法也可以是技术原型例如“手机上能否同屏渲染 200 个单位”“这种网络同步方案在 200ms 延迟下手感如何”。常见误区把原型代码直接当作正式项目的基础。原型阶段为了速度做的妥协进入制作阶段后往往会成为技术债。业界常说的“原型要扔掉”Throwaway Prototype说的就是这个意思。2. 灰盒Greybox / Whitebox / Blockout关卡设计中常用的方法用简单几何体搭出关卡结构先验证路线、尺度、节奏和战斗空间确认后再交给美术制作正式资源。对程序而言灰盒阶段就是玩法逻辑与关卡结构对接的时机例如触发器、刷怪点、寻路网格。3. 首个可玩版本First Playable含义核心循环可以从头到尾完整跑通一次。以一款动作 RPG 为例First Playable 可能意味着进入关卡 → 战斗 → 获得掉落 → 回城强化 → 进入下一关。每个环节都很简陋但链条是完整的。它的意义在于单独看都没问题的系统串起来之后才会暴露节奏、数值和数据流上的问题。4. 垂直切片Vertical Slice这是预制作阶段最重要的里程碑也是最容易被误解的一个。含义选取游戏中的一小段内容在所有方面都做到接近最终品质。“垂直”和“水平”的区别关卡1 关卡2 关卡3 关卡4 关卡5 玩法 ███ ░░░ ░░░ ░░░ ░░░ 美术 ███ ░░░ ░░░ ░░░ ░░░ 音效 ███ ░░░ ░░░ ░░░ ░░░ UI ███ ░░░ ░░░ ░░░ ░░░ 性能 ███ ░░░ ░░░ ░░░ ░░░ ↑ 垂直切片一小块所有方面都到位 水平切片Horizontal Slice所有关卡都有但每个方面都只是粗糙版本垂直切片要回答的问题问题面向谁最终品质的游戏长什么样、好不好玩团队、发行商、投资方团队能否按这个品质稳定地生产内容制作人制作一个单位内容一个关卡、一个角色需要多少人力和时间制作人用于排期估算技术方案能否支撑最终品质的表现与性能技术团队最后两条常被忽视但恰恰是垂直切片的核心价值它是估算整个项目成本的样本。如果做一个关卡用了 3 个月而游戏需要 20 个关卡排期就有了依据。程序员要注意垂直切片需要在目标平台、目标性能下运行而不是只在开发机上流畅为演示临时写死的逻辑“演示路线上只会遇到这几个敌人”要明确标记避免被当作已完成的功能业界一直存在“为演示而做的切片”与“可量产的切片”之间的差距问题。如果切片里的效果依赖大量手工调整、无法通过管线批量生产就要在评估时如实说明。垂直切片 vs 演示Demo二者经常被混用。展会演示、宣传视频往往基于垂直切片制作但演示的目标是“展示”垂直切片的目标是“验证”。前者可以只顾效果后者必须对排期和技术负责。5. 立项评审Greenlight / Gate Review很多公司在预制作结束时设有一道评审关卡根据垂直切片的结果决定项目是否进入制作阶段、投入多少人力。结果含义通过进入制作阶段团队扩充有条件通过补充验证某些问题后再评审回到预制作方向需要调整终止项目停止这类评审在不同公司有不同叫法国内大厂常称为“立项评审”“转正评审”“过会”等。三、制作阶段从“能玩”到“完整”进入制作阶段后团队规模扩大开始批量生产内容。这一阶段持续时间最长期间最重要的两个里程碑是 Alpha 和 Beta。1. 先理解几个“Complete”业界经常用以下几个词描述完成度它们是理解 Alpha、Beta 的基础术语含义功能完成Feature Complete所有计划内的功能和系统都已实现可以使用。品质和内容量不一定到位内容完成Content Complete所有关卡、角色、剧情、道具等内容都已进入游戏可以是非最终品质代码完成Code Complete不再编写新功能代码后续只修复问题资源锁定Asset Lock / Content Lock资源不再新增或大改只做修正文本冻结String Freeze / Text Lock界面和剧情文本不再改动交付翻译2. Alpha功能齐全最常见的定义游戏达到功能完成所有系统都已实现可以从头玩到尾但内容可能有占位存在较多 Bug性能未完全优化。维度Alpha 时的典型状态功能全部实现内容大部分到位部分仍是占位资源Bug数量多但不应有阻断主流程的问题性能已知问题清单明确尚未完全达标新功能Alpha 之后原则上不再添加Alpha 之后的核心变化功能冻结。这是很多新人第一次感受到的“项目规则”想到一个好主意在 Alpha 之后通常不能直接加进去需要走变更评审或者放进后续版本。原因很简单每增加一个功能都会带来新的 Bug、新的测试工作和新的风险。常见变体有的公司把 Alpha 定义为“内容完成”有的把它与 First Playable 混用也有项目根本不设 Alpha。一定要确认团队内部的定义。3. Beta内容齐全只修不改最常见的定义游戏达到内容完成所有内容都是最终或接近最终品质工作重心完全转向修复 Bug、优化性能和打磨体验。维度Beta 时的典型状态功能冻结内容全部到位资源锁定文本冻结本地化进行中或已完成Bug持续下降无已知阻断级问题性能在目标平台达到或接近目标改动每个改动都要评估风险Beta 阶段的工作方式变化改动评审越接近发布每一次提交都可能需要主程或制作人批准修复也有风险修一个 Bug 可能引入两个新 Bug。到后期一些低优先级问题会被评估为“不修”Won’t Fix作为已知问题发布Bug 收敛团队会盯着 Bug 曲线观察新增 Bug 和修复 Bug 的数量变化判断能否如期发布。Bug 数量 │ ╱‾‾‾‾╲ ← 新开 Bug 数量Alpha 后集中测试数量冲高 │ ╱ ╲ │ ╱ ╲___ │ ╱ ‾‾‾‾╲____ │╱ ‾‾‾‾‾───___ ← 期望持续下降并收敛 └────────────────────────────────────────────→ 时间 Alpha Beta RC 黄金版注意区分这里的 Beta 是内部开发里程碑和对外的“Beta 测试”公开测试不是一回事。一款游戏可能在内部 Alpha 阶段就对外进行“封闭 Beta 测试”。后文会详细对照。4. Bug 分级里程碑能否通过通常与 Bug 的数量和级别直接挂钩。各公司的分级名称不同常见形式如下级别常见叫法含义例子阻断Blocker / A 类 / P0崩溃、无法继续、数据丢失、认证不通过进入第三关必崩存档损坏严重Critical / Major / B 类 / P1主要功能异常有绕过方法某技能伤害计算错误一般Minor / C 类 / P2体验问题不影响主流程某界面文字溢出轻微Trivial / D 类 / P3细节瑕疵某处贴图轻微接缝一个常见的里程碑验收标准示例仅为示意里程碑阻断级严重级Alpha无阻断主流程的问题有明确修复计划Beta0 个已知数量低于约定阈值RC / 黄金版0 个已知0 个或均已评估为可接受四、收尾阶段RC、黄金版与平台认证1. 候选发布版Release CandidateRC含义团队认为“如果没发现新问题这就是最终版本”的构建版本。RC 会经历完整的回归测试发现阻断级问题 → 修复 → 产出 RC2、RC3……某个 RC 通过全部测试就成为最终版本。2. 黄金版Gold Master / Gold含义最终确认发布的版本。“Going Gold”压盘、黄金版完成是游戏宣发中常见的说法意味着开发正式完成。名称的由来在光盘时代最终版本会被刻录成**母盘Master**交给工厂量产“黄金母盘”指确认无误、可以量产的那一版。此后再发现问题已经发出去的光盘无法修改。数字分发时代的黄金版主机游戏仍需要提交平台认证通过后才能上架实体版仍需生产周期由于黄金版与发售日之间常有数周间隔团队会继续修复问题在上线当天发布首日补丁Day One Patch移动和 PC 游戏的“黄金版”概念相对弱化更常说“提审包”“上线包”。首日补丁不是失败的标志它是黄金版到发售日之间这段时间的合理利用。但如果游戏严重依赖首日补丁才能正常运行对购买实体版、无法联网的玩家就是问题。3. 平台认证Certification / Submission上线前游戏需要通过平台方的检查平台认证要求业界常见叫法PlayStationTRCTechnical Requirements ChecklistXboxXRXbox RequirementsNintendoLotcheck 及相关指南App StoreApp Review依据 App Store Review GuidelinesGoogle Play应用审核依据开发者政策Steam商店页面与构建版本审核主机认证的具体条款受保密协议NDA约束不对外公开。但从公开的开发者分享来看常见的检查方向包括方向例子系统事件挂起与恢复、切换用户、断开手柄、网络断开时的正确处理存档存储空间不足、存档写入中断、存档损坏时的处理平台功能奖杯 / 成就、好友与邀请、家长控制、平台账号登录术语与界面按平台规定的术语描述按键、设备和功能稳定性无崩溃、无卡死、加载时间符合要求认证不通过需要修复后重新提交认证周期必须提前纳入排期。国内移动游戏上线还需要叠加版号、渠道审核等环节见《版号、防沉迷与适龄提示》一文。五、国内手游的测试节奏与里程碑如何对应国内手游很少对外说“Alpha”“Beta”更常见的是一系列对外测试。这些测试是运营层面的节点和内部开发里程碑并不一一对应。1. 常见的测试类型叫法含义通常的目的技术测试技测小规模、通常不收费验证稳定性、服务器承载、基础玩法反馈删档测试测试结束后清空玩家数据验证玩法、留存、数值计费删档测试开放付费结束后清档常见做法是对充值进行返还验证付费设计与付费数据不删档测试数据保留到正式上线接近正式运营公测正式上线所有玩家可进入正式运营首测、二测、三测按测试次数命名每次测试的目标不同根据前文介绍的合规要求开放付费的测试需要取得版号各渠道对测试规模、资质的要求也不同。2. 海外与 PC 的常见做法叫法含义CBTClosed Beta Test封闭测试通过招募或邀请码进入OBTOpen Beta Test公开测试任何人都可以参加软上线Soft Launch先在少数国家或地区正式上线验证留存、付费和买量数据再全球上线。常选择人口结构或市场特征有代表性、但规模较小的地区抢先体验Early Access以未完成状态在 Steam 等平台付费发售边运营边开发技术封测 / 压力测试Stress Test集中验证服务器承载能力平台提供的测试分发工具TestFlightiOS支持内部测试和最多 10,000 名外部测试员外部测试的构建版本需要经过审核每个构建版本有效期为 90 天Google Play 测试轨道提供内部测试、封闭测试、开放测试等轨道可以分阶段向不同范围的用户发布。3. 内外对照一个常见的对应关系仅为示意各项目差异很大内部里程碑: 原型 ─ 垂直切片 ─────── Alpha ─────────── Beta ───── RC ─ 上线包 │ │ │ 对外测试: 技术测试首测 删档/计费删档测试 不删档测试 ─ 公测 验证稳定性与玩法 验证留存与付费 接近正式运营对程序员的直接影响删档测试期间数据结构可以较大幅度调整必要时直接清档一旦进入不删档阶段存档和数据库结构就必须向后兼容任何改动都需要数据迁移方案。这是很多项目在程序侧最关键的“隐形里程碑”。六、里程碑是如何验收的1. 里程碑交付物在外包、发行合作中里程碑通常写入合同并约定交付物Deliverables和验收标准Acceptance Criteria。常见交付物包括类型例子可运行版本指定平台的构建包演示材料试玩路线、录屏文档功能清单、已知问题列表、技术说明数据性能报告、Bug 统计、测试数据2. 里程碑付款在发行商与研发商的合作中常见的结构是按里程碑分期付款Milestone Payments每个里程碑通过验收后发行商支付对应款项。这意味着里程碑是否通过直接影响研发团队的现金流验收标准越模糊越容易产生争议因此合同中会尽量写清楚“什么算完成”这也是里程碑前后容易出现集中加班Crunch的原因之一业界对此一直有较多讨论和反思。3. 内部项目公司内部项目同样会设置阶段评审评审结果影响人力、预算和项目去留。名称不同本质相同用可验证的成果换取下一阶段的资源。七、对程序员意味着什么1. 每个阶段的工作重点阶段程序的主要任务心态原型快速实现验证可行性速度优先代码可以扔垂直切片搭建立正式架构与生产管线在目标平台达到目标品质与性能质量与速度兼顾验证“可量产”制作期Alpha 前实现全部功能完善工具链支撑内容批量生产功能优先同时控制技术债Alpha → Beta修复 Bug、性能优化、平台功能接入、内容支持不加新功能开始收敛Beta → RC只修 Bug每个改动评估风险稳定压倒一切RC → 黄金版只修阻断级问题配合认证与提审能不改就不改上线后首日补丁、线上问题处理、后续版本开发线上稳定与持续迭代并行一个简单的判断方法越接近发布改动的门槛越高。同样一个“顺手重构”在制作期可能是好习惯在 RC 阶段就可能是事故。2. 技术债什么时候还阶段对技术债的态度原型可以随意欠但原型代码不要进入正式工程垂直切片之后是重构和夯实架构的最好时机团队还小改动成本低制作期边做边还优先还“影响内容生产效率”的债例如工具慢、导入流程繁琐Alpha 之后原则上不做大规模重构除非问题已严重影响稳定性或性能Beta 之后不还记录下来留到上线后的版本一个实用做法维护一份技术债清单记录问题、影响和预计成本。Beta 之后冒出来的“想重写”冲动先写进清单上线后再按优先级处理。3. 分支策略与代码冻结里程碑在版本控制上通常体现为分支和冻结规则。一个常见的形式如下main / trunk ──●──●──●──●──●──●──●──●──●──●──●──→ 持续开发后续版本内容 │ └─ release/1.0 ──●──●──●──●──→ RC1 → RC2 → 黄金版 只接受经过评审的修复规则说明拉出发布分支进入 Beta 或 RC 前从主干拉出发布分支发布分支只接受修复修复的流向修复通常先提交到发布分支再合回主干或反过来 Cherry-pick具体方向按团队约定但不能漏合否则下个版本问题会复现变更评审接近发布时向发布分支的提交需要经过变更评审业界常称 Change Control / CCB说明问题、修复范围、风险和测试情况冻结期提交认证或提审前后发布分支可能完全冻结任何改动都需要特批主干保持可用主干持续集成保证随时能出可运行版本避免“发布分支好了主干坏了”4. 构建与版本号里程碑的交付物是某一个具体的构建版本必须能被准确识别和复现。要点说明唯一版本号每个构建版本都有唯一编号例如1.0.0.1234其中末位是构建号对应代码提交构建号能追溯到确切的代码提交与资源版本最好在版本控制中打标签Tag游戏内可见在设置界面或角落显示版本号测试和玩家反馈问题时能准确定位持续集成由 CI 自动构建而不是“在某台开发机上手动打的包”符号文件归档保存每个发布版本的调试符号PDB、dSYM、Android 符号等否则线上崩溃日志无法还原堆栈可复现任何一个历史版本都能重新构建出来用于排查线上问题很多团队都经历过这样的事故线上崩溃激增但找不到对应版本的符号文件或者不确定线上包是从哪次提交打出来的。里程碑版本的符号与构建记录务必长期归档。5. 数据兼容不删档之后的硬约束前文提到一旦进入不删档测试或正式上线存档和数据库结构就必须向后兼容。程序需要在此之前做好准备要点说明存档带版本号每份存档、每条关键数据都记录自己的结构版本迁移脚本结构变化时提供从旧版本到新版本的迁移逻辑并逐级升级只增不改字段尽量只新增不修改含义、不复用旧字段迁移可测试保留各历史版本的样本存档作为迁移测试用例可回滚服务端数据迁移前备份迁移失败能够回退一个简化的存档迁移示意CURRENT_VERSION3defmigrate(save:dict)-dict:versionsave.get(version,1)ifversion2:# v1 → v2金币从单一字段拆分为付费与免费两类save[coin_paid]0save[coin_free]save.pop(coin,0)version2ifversion3:# v2 → v3新增设置项给出默认值save.setdefault(settings,{})[subtitle]Trueversion3save[version]versionreturnsave示例只展示“逐级迁移”的结构。真实项目还需要考虑迁移失败处理、大批量数据的分批迁移和线上灰度验证。6. 性能预算分阶段达标性能不能等到 Beta 才开始优化但也不必在原型阶段就追求极致。常见做法是为每个里程碑设定性能目标阶段性能目标示意原型能运行即可但要识别出明显的技术风险垂直切片切片范围内在目标平台达到目标帧率与内存Alpha全部内容可运行性能问题清单明确有优化计划Beta主要场景在目标平台达标内存与包体在预算内RC全部达标长时间运行无内存泄漏、无明显卡顿性能预算通常拆到各个维度帧时间CPU / GPU、内存按模块分配、包体大小、加载时间、发热与耗电移动端。预算在垂直切片阶段制定在制作期持续监控可以通过自动化性能测试在每日构建中跟踪趋势。7. 发布前要移除的东西开发期间为了方便调试会加入很多“后门”。它们必须在发布版本中被关闭或剔除内容风险作弊指令、GM 面板玩家获得不该有的能力破坏经济与公平调试菜单、跳关功能绕过正常流程测试服务器地址、内部接口暴露内部环境详细日志、敏感信息输出泄露数据影响性能服务器时间偏移等测试能力可被利用绕过时长、活动等限制未发布内容的资源被拆包泄露提前“剧透”实现建议通过编译宏、构建配置把调试代码整段排除而不是仅仅隐藏入口服务端对 GM 指令做权限校验不依赖客户端是否显示按钮在发布流程中加入自动检查扫描发布包中是否存在调试符号、测试地址、内部关键字。8. 平台认证与提审准备认证不通过往往不是因为“大 Bug”而是因为系统事件和边界情况处理不当。建议在 Alpha 之后就开始对照平台要求自查应用挂起、切后台、恢复后的状态正确网络断开与恢复时有明确提示不卡死存储空间不足、存档写入中断时不损坏数据手柄断开、切换用户主机时正确处理成就 / 奖杯在正确时机解锁界面术语符合平台规范隐私政策、账号删除、权限申请说明等满足商店要求提审账号、演示说明已准备9. 用垂直切片的数据做估算程序同样需要从垂直切片中获取估算依据问题估算方法一个新系统需要多久参考切片中同类系统的实际耗时内容量放大后性能如何以切片的性能数据为基准按内容规模推算并预留余量工具链能否支撑量产统计切片期间内容制作中因工具问题浪费的时间哪些部分是“演示专用”列出切片中写死、手工调整的部分计入后续工作量估算时最容易被低估的是“集成”和“修 Bug”的时间。单个功能开发完成只是工作的一部分。八、常见的坑问题后果正确做法原型代码直接进入正式工程技术债从第一天开始累积原型验证完成后重写或经过评审再保留垂直切片依赖大量写死逻辑高估进度量产时才发现做不出来明确标记演示专用部分计入工作量不确认团队对 Alpha、Beta 的定义不同人对“完成”理解不一致在项目初期写清楚每个里程碑的验收标准Alpha 之后继续加功能Bug 无法收敛发布延期新想法进入需求池走变更评审临近发布还做重构引入新的阻断级问题记录到技术债清单上线后再处理发布分支修复没有合回主干下个版本问题复现规定修复流向用工具检查漏合线上版本找不到符号文件崩溃无法定位每个发布版本自动归档符号不删档后才考虑存档兼容数据结构改动困难甚至被迫回档早期就为存档和数据库加版本号与迁移机制调试功能只隐藏入口被破解后滥用编译期剔除服务端校验权限认证与提审周期未纳入排期错过发售日或上线窗口提前了解平台周期预留重新提交时间混淆内部 Beta 与对外 Beta 测试沟通中产生误解明确说明“内部里程碑”还是“对外测试”九、里程碑自查清单程序视角里程碑程序侧检查项原型核心问题已验证技术风险已记录明确哪些代码要丢弃垂直切片在目标平台达到目标性能生产管线可支撑量产演示专用部分已标记性能预算已制定Alpha全部功能实现无阻断主流程的问题平台功能开始接入存档与数据结构有版本机制Beta功能与文本冻结主要场景性能达标发布分支已拉出变更评审流程已建立RC无已知阻断级问题调试功能已剔除构建可复现符号已归档平台要求已自查黄金版 / 上线认证或提审通过首日补丁计划明确线上监控与告警就绪回滚方案已演练小结里程碑核心问题关键词程序的心态原型好不好玩、做不做得出来快、粗糙、可丢弃速度优先First Playable核心循环能否跑通完整链条打通流程垂直切片成品什么样、成本多少最终品质、可量产验证架构与管线Alpha功能是否齐全功能完成、功能冻结开始收敛Beta能否发布内容完成、只修不改稳定优先RC还有没有阻断问题候选版本、回归测试能不改就不改黄金版——最终版本、认证、首日补丁做好上线准备一句话概括里程碑是项目在不同阶段对“完成”的约定。原型回答“好不好玩”垂直切片回答“做不做得出来”Alpha 回答“东西全不全”Beta 回答“能不能发”黄金版则意味着交付。对程序员来说理解里程碑最重要的意义在于知道当前阶段允许做什么、不该做什么。早期大胆试错、夯实架构中期支撑量产、控制技术债后期收敛改动、守住稳定。同样的代码改动放在不同的阶段价值和风险完全不同。参考资料Heather Maxwell Chandler《The Game Production Toolbox》《The Game Production Handbook》Clinton Keith《Agile Game Development: Build, Play, Repeat》Jason Schreier《Blood, Sweat, and Pixels》中译本《游戏开发血、汗与像素》Tynan Sylvester《Designing Games》AppleTestFlight 文档、App Store Review GuidelinesGoogleGoogle Play Console 测试轨道内部、封闭、开放测试文档ValveSteam 抢先体验Early Access说明GDC 历年制作管理Production、垂直切片与发布流程相关演讲本文对各里程碑的描述为业界常见含义。不同公司、项目和合同的定义可能不同请以团队内部约定和合同条款为准。
适合阶段入门适合读者刚入行或准备入行的学生、转行者以及第一次参与完整项目周期、需要理解“这个阶段该交付什么”的程序员说明里程碑的名称在业界通用但具体定义因公司、项目、合同而异。本文介绍的是最常见的含义实际以所在团队和发行合同的约定为准引子刚进项目组经常会听到这样的对话“下个月要交垂直切片战斗必须是最终品质。”“Alpha 之后不加新功能了有想法先记到下个版本。”“Beta 了现在只修 Bug改动要过评审。”“主机版已经送审这周别往 release 分支上合东西。”“二测是计费删档三测转不删档存档结构要定死了。”这些词描述的都是开发里程碑Milestone项目在某个时间点必须达到的状态。理解里程碑程序员才能知道当前阶段什么事情最重要什么时候可以大改架构什么时候必须“只修不改”自己的工作为什么会被“冻结”“评审”“打回”。这篇文章按时间顺序梳理主要里程碑再对照国内手游常用的测试叫法最后落到程序员在每个阶段的工作重点。一、里程碑全景一个典型的游戏项目从立项到上线大致经历以下阶段预制作Pre-production 制作Production 收尾Finaling 上线后 ─────────────────────────────────── ────────────────────────────── ────────────────────── ────────── 概念 → 原型 → First Playable → 垂直切片 → ……… → Alpha → ……… → Beta → RC → 黄金版 / 上线 → Day One Patch → 运营 │ │ │ │ │ │ │ │ 想法 验证玩法 能完整玩一轮 最终品质样本 功能齐全 内容齐全 候选 正式发布里程碑英文一句话含义典型问题概念Concept想清楚做什么这个游戏值得做吗原型Prototype验证核心玩法这个玩法好玩吗首个可玩版本First Playable核心循环能从头到尾跑通能完整玩一轮吗垂直切片Vertical Slice一小段内容达到最终品质成品大概是什么样做得出来吗AlphaAlpha功能齐全所有系统都实现了吗BetaBeta内容齐全专注修 Bug能发布吗还差什么候选发布版Release CandidateRC可能就是最终版本还有阻断发布的问题吗黄金版Gold Master / Gold最终发布版本——首日补丁Day One Patch上线当天的更新黄金版之后修了什么Alpha、Beta 的说法来自哪里一般认为这对术语源自早期软件工业常被追溯到 IBM的测试阶段命名后来被整个软件行业沿用。游戏行业沿用了名称但赋予了自己的含义。二、预制作阶段回答“做什么”和“做得出来吗”预制作阶段的目标是用尽量小的成本降低不确定性。这个阶段团队较小以策划、主程、主美和少量程序为主。1. 原型Prototype目的验证一个具体问题最常见的是“核心玩法是否好玩”。特点说明快以天或周为单位而不是月粗糙美术用方块、灰盒界面用默认控件一次性原型代码通常不追求质量验证完可以丢弃聚焦一个原型只回答一个或少数几个问题原型不一定只验证玩法也可以是技术原型例如“手机上能否同屏渲染 200 个单位”“这种网络同步方案在 200ms 延迟下手感如何”。常见误区把原型代码直接当作正式项目的基础。原型阶段为了速度做的妥协进入制作阶段后往往会成为技术债。业界常说的“原型要扔掉”Throwaway Prototype说的就是这个意思。2. 灰盒Greybox / Whitebox / Blockout关卡设计中常用的方法用简单几何体搭出关卡结构先验证路线、尺度、节奏和战斗空间确认后再交给美术制作正式资源。对程序而言灰盒阶段就是玩法逻辑与关卡结构对接的时机例如触发器、刷怪点、寻路网格。3. 首个可玩版本First Playable含义核心循环可以从头到尾完整跑通一次。以一款动作 RPG 为例First Playable 可能意味着进入关卡 → 战斗 → 获得掉落 → 回城强化 → 进入下一关。每个环节都很简陋但链条是完整的。它的意义在于单独看都没问题的系统串起来之后才会暴露节奏、数值和数据流上的问题。4. 垂直切片Vertical Slice这是预制作阶段最重要的里程碑也是最容易被误解的一个。含义选取游戏中的一小段内容在所有方面都做到接近最终品质。“垂直”和“水平”的区别关卡1 关卡2 关卡3 关卡4 关卡5 玩法 ███ ░░░ ░░░ ░░░ ░░░ 美术 ███ ░░░ ░░░ ░░░ ░░░ 音效 ███ ░░░ ░░░ ░░░ ░░░ UI ███ ░░░ ░░░ ░░░ ░░░ 性能 ███ ░░░ ░░░ ░░░ ░░░ ↑ 垂直切片一小块所有方面都到位 水平切片Horizontal Slice所有关卡都有但每个方面都只是粗糙版本垂直切片要回答的问题问题面向谁最终品质的游戏长什么样、好不好玩团队、发行商、投资方团队能否按这个品质稳定地生产内容制作人制作一个单位内容一个关卡、一个角色需要多少人力和时间制作人用于排期估算技术方案能否支撑最终品质的表现与性能技术团队最后两条常被忽视但恰恰是垂直切片的核心价值它是估算整个项目成本的样本。如果做一个关卡用了 3 个月而游戏需要 20 个关卡排期就有了依据。程序员要注意垂直切片需要在目标平台、目标性能下运行而不是只在开发机上流畅为演示临时写死的逻辑“演示路线上只会遇到这几个敌人”要明确标记避免被当作已完成的功能业界一直存在“为演示而做的切片”与“可量产的切片”之间的差距问题。如果切片里的效果依赖大量手工调整、无法通过管线批量生产就要在评估时如实说明。垂直切片 vs 演示Demo二者经常被混用。展会演示、宣传视频往往基于垂直切片制作但演示的目标是“展示”垂直切片的目标是“验证”。前者可以只顾效果后者必须对排期和技术负责。5. 立项评审Greenlight / Gate Review很多公司在预制作结束时设有一道评审关卡根据垂直切片的结果决定项目是否进入制作阶段、投入多少人力。结果含义通过进入制作阶段团队扩充有条件通过补充验证某些问题后再评审回到预制作方向需要调整终止项目停止这类评审在不同公司有不同叫法国内大厂常称为“立项评审”“转正评审”“过会”等。三、制作阶段从“能玩”到“完整”进入制作阶段后团队规模扩大开始批量生产内容。这一阶段持续时间最长期间最重要的两个里程碑是 Alpha 和 Beta。1. 先理解几个“Complete”业界经常用以下几个词描述完成度它们是理解 Alpha、Beta 的基础术语含义功能完成Feature Complete所有计划内的功能和系统都已实现可以使用。品质和内容量不一定到位内容完成Content Complete所有关卡、角色、剧情、道具等内容都已进入游戏可以是非最终品质代码完成Code Complete不再编写新功能代码后续只修复问题资源锁定Asset Lock / Content Lock资源不再新增或大改只做修正文本冻结String Freeze / Text Lock界面和剧情文本不再改动交付翻译2. Alpha功能齐全最常见的定义游戏达到功能完成所有系统都已实现可以从头玩到尾但内容可能有占位存在较多 Bug性能未完全优化。维度Alpha 时的典型状态功能全部实现内容大部分到位部分仍是占位资源Bug数量多但不应有阻断主流程的问题性能已知问题清单明确尚未完全达标新功能Alpha 之后原则上不再添加Alpha 之后的核心变化功能冻结。这是很多新人第一次感受到的“项目规则”想到一个好主意在 Alpha 之后通常不能直接加进去需要走变更评审或者放进后续版本。原因很简单每增加一个功能都会带来新的 Bug、新的测试工作和新的风险。常见变体有的公司把 Alpha 定义为“内容完成”有的把它与 First Playable 混用也有项目根本不设 Alpha。一定要确认团队内部的定义。3. Beta内容齐全只修不改最常见的定义游戏达到内容完成所有内容都是最终或接近最终品质工作重心完全转向修复 Bug、优化性能和打磨体验。维度Beta 时的典型状态功能冻结内容全部到位资源锁定文本冻结本地化进行中或已完成Bug持续下降无已知阻断级问题性能在目标平台达到或接近目标改动每个改动都要评估风险Beta 阶段的工作方式变化改动评审越接近发布每一次提交都可能需要主程或制作人批准修复也有风险修一个 Bug 可能引入两个新 Bug。到后期一些低优先级问题会被评估为“不修”Won’t Fix作为已知问题发布Bug 收敛团队会盯着 Bug 曲线观察新增 Bug 和修复 Bug 的数量变化判断能否如期发布。Bug 数量 │ ╱‾‾‾‾╲ ← 新开 Bug 数量Alpha 后集中测试数量冲高 │ ╱ ╲ │ ╱ ╲___ │ ╱ ‾‾‾‾╲____ │╱ ‾‾‾‾‾───___ ← 期望持续下降并收敛 └────────────────────────────────────────────→ 时间 Alpha Beta RC 黄金版注意区分这里的 Beta 是内部开发里程碑和对外的“Beta 测试”公开测试不是一回事。一款游戏可能在内部 Alpha 阶段就对外进行“封闭 Beta 测试”。后文会详细对照。4. Bug 分级里程碑能否通过通常与 Bug 的数量和级别直接挂钩。各公司的分级名称不同常见形式如下级别常见叫法含义例子阻断Blocker / A 类 / P0崩溃、无法继续、数据丢失、认证不通过进入第三关必崩存档损坏严重Critical / Major / B 类 / P1主要功能异常有绕过方法某技能伤害计算错误一般Minor / C 类 / P2体验问题不影响主流程某界面文字溢出轻微Trivial / D 类 / P3细节瑕疵某处贴图轻微接缝一个常见的里程碑验收标准示例仅为示意里程碑阻断级严重级Alpha无阻断主流程的问题有明确修复计划Beta0 个已知数量低于约定阈值RC / 黄金版0 个已知0 个或均已评估为可接受四、收尾阶段RC、黄金版与平台认证1. 候选发布版Release CandidateRC含义团队认为“如果没发现新问题这就是最终版本”的构建版本。RC 会经历完整的回归测试发现阻断级问题 → 修复 → 产出 RC2、RC3……某个 RC 通过全部测试就成为最终版本。2. 黄金版Gold Master / Gold含义最终确认发布的版本。“Going Gold”压盘、黄金版完成是游戏宣发中常见的说法意味着开发正式完成。名称的由来在光盘时代最终版本会被刻录成**母盘Master**交给工厂量产“黄金母盘”指确认无误、可以量产的那一版。此后再发现问题已经发出去的光盘无法修改。数字分发时代的黄金版主机游戏仍需要提交平台认证通过后才能上架实体版仍需生产周期由于黄金版与发售日之间常有数周间隔团队会继续修复问题在上线当天发布首日补丁Day One Patch移动和 PC 游戏的“黄金版”概念相对弱化更常说“提审包”“上线包”。首日补丁不是失败的标志它是黄金版到发售日之间这段时间的合理利用。但如果游戏严重依赖首日补丁才能正常运行对购买实体版、无法联网的玩家就是问题。3. 平台认证Certification / Submission上线前游戏需要通过平台方的检查平台认证要求业界常见叫法PlayStationTRCTechnical Requirements ChecklistXboxXRXbox RequirementsNintendoLotcheck 及相关指南App StoreApp Review依据 App Store Review GuidelinesGoogle Play应用审核依据开发者政策Steam商店页面与构建版本审核主机认证的具体条款受保密协议NDA约束不对外公开。但从公开的开发者分享来看常见的检查方向包括方向例子系统事件挂起与恢复、切换用户、断开手柄、网络断开时的正确处理存档存储空间不足、存档写入中断、存档损坏时的处理平台功能奖杯 / 成就、好友与邀请、家长控制、平台账号登录术语与界面按平台规定的术语描述按键、设备和功能稳定性无崩溃、无卡死、加载时间符合要求认证不通过需要修复后重新提交认证周期必须提前纳入排期。国内移动游戏上线还需要叠加版号、渠道审核等环节见《版号、防沉迷与适龄提示》一文。五、国内手游的测试节奏与里程碑如何对应国内手游很少对外说“Alpha”“Beta”更常见的是一系列对外测试。这些测试是运营层面的节点和内部开发里程碑并不一一对应。1. 常见的测试类型叫法含义通常的目的技术测试技测小规模、通常不收费验证稳定性、服务器承载、基础玩法反馈删档测试测试结束后清空玩家数据验证玩法、留存、数值计费删档测试开放付费结束后清档常见做法是对充值进行返还验证付费设计与付费数据不删档测试数据保留到正式上线接近正式运营公测正式上线所有玩家可进入正式运营首测、二测、三测按测试次数命名每次测试的目标不同根据前文介绍的合规要求开放付费的测试需要取得版号各渠道对测试规模、资质的要求也不同。2. 海外与 PC 的常见做法叫法含义CBTClosed Beta Test封闭测试通过招募或邀请码进入OBTOpen Beta Test公开测试任何人都可以参加软上线Soft Launch先在少数国家或地区正式上线验证留存、付费和买量数据再全球上线。常选择人口结构或市场特征有代表性、但规模较小的地区抢先体验Early Access以未完成状态在 Steam 等平台付费发售边运营边开发技术封测 / 压力测试Stress Test集中验证服务器承载能力平台提供的测试分发工具TestFlightiOS支持内部测试和最多 10,000 名外部测试员外部测试的构建版本需要经过审核每个构建版本有效期为 90 天Google Play 测试轨道提供内部测试、封闭测试、开放测试等轨道可以分阶段向不同范围的用户发布。3. 内外对照一个常见的对应关系仅为示意各项目差异很大内部里程碑: 原型 ─ 垂直切片 ─────── Alpha ─────────── Beta ───── RC ─ 上线包 │ │ │ 对外测试: 技术测试首测 删档/计费删档测试 不删档测试 ─ 公测 验证稳定性与玩法 验证留存与付费 接近正式运营对程序员的直接影响删档测试期间数据结构可以较大幅度调整必要时直接清档一旦进入不删档阶段存档和数据库结构就必须向后兼容任何改动都需要数据迁移方案。这是很多项目在程序侧最关键的“隐形里程碑”。六、里程碑是如何验收的1. 里程碑交付物在外包、发行合作中里程碑通常写入合同并约定交付物Deliverables和验收标准Acceptance Criteria。常见交付物包括类型例子可运行版本指定平台的构建包演示材料试玩路线、录屏文档功能清单、已知问题列表、技术说明数据性能报告、Bug 统计、测试数据2. 里程碑付款在发行商与研发商的合作中常见的结构是按里程碑分期付款Milestone Payments每个里程碑通过验收后发行商支付对应款项。这意味着里程碑是否通过直接影响研发团队的现金流验收标准越模糊越容易产生争议因此合同中会尽量写清楚“什么算完成”这也是里程碑前后容易出现集中加班Crunch的原因之一业界对此一直有较多讨论和反思。3. 内部项目公司内部项目同样会设置阶段评审评审结果影响人力、预算和项目去留。名称不同本质相同用可验证的成果换取下一阶段的资源。七、对程序员意味着什么1. 每个阶段的工作重点阶段程序的主要任务心态原型快速实现验证可行性速度优先代码可以扔垂直切片搭建立正式架构与生产管线在目标平台达到目标品质与性能质量与速度兼顾验证“可量产”制作期Alpha 前实现全部功能完善工具链支撑内容批量生产功能优先同时控制技术债Alpha → Beta修复 Bug、性能优化、平台功能接入、内容支持不加新功能开始收敛Beta → RC只修 Bug每个改动评估风险稳定压倒一切RC → 黄金版只修阻断级问题配合认证与提审能不改就不改上线后首日补丁、线上问题处理、后续版本开发线上稳定与持续迭代并行一个简单的判断方法越接近发布改动的门槛越高。同样一个“顺手重构”在制作期可能是好习惯在 RC 阶段就可能是事故。2. 技术债什么时候还阶段对技术债的态度原型可以随意欠但原型代码不要进入正式工程垂直切片之后是重构和夯实架构的最好时机团队还小改动成本低制作期边做边还优先还“影响内容生产效率”的债例如工具慢、导入流程繁琐Alpha 之后原则上不做大规模重构除非问题已严重影响稳定性或性能Beta 之后不还记录下来留到上线后的版本一个实用做法维护一份技术债清单记录问题、影响和预计成本。Beta 之后冒出来的“想重写”冲动先写进清单上线后再按优先级处理。3. 分支策略与代码冻结里程碑在版本控制上通常体现为分支和冻结规则。一个常见的形式如下main / trunk ──●──●──●──●──●──●──●──●──●──●──●──→ 持续开发后续版本内容 │ └─ release/1.0 ──●──●──●──●──→ RC1 → RC2 → 黄金版 只接受经过评审的修复规则说明拉出发布分支进入 Beta 或 RC 前从主干拉出发布分支发布分支只接受修复修复的流向修复通常先提交到发布分支再合回主干或反过来 Cherry-pick具体方向按团队约定但不能漏合否则下个版本问题会复现变更评审接近发布时向发布分支的提交需要经过变更评审业界常称 Change Control / CCB说明问题、修复范围、风险和测试情况冻结期提交认证或提审前后发布分支可能完全冻结任何改动都需要特批主干保持可用主干持续集成保证随时能出可运行版本避免“发布分支好了主干坏了”4. 构建与版本号里程碑的交付物是某一个具体的构建版本必须能被准确识别和复现。要点说明唯一版本号每个构建版本都有唯一编号例如1.0.0.1234其中末位是构建号对应代码提交构建号能追溯到确切的代码提交与资源版本最好在版本控制中打标签Tag游戏内可见在设置界面或角落显示版本号测试和玩家反馈问题时能准确定位持续集成由 CI 自动构建而不是“在某台开发机上手动打的包”符号文件归档保存每个发布版本的调试符号PDB、dSYM、Android 符号等否则线上崩溃日志无法还原堆栈可复现任何一个历史版本都能重新构建出来用于排查线上问题很多团队都经历过这样的事故线上崩溃激增但找不到对应版本的符号文件或者不确定线上包是从哪次提交打出来的。里程碑版本的符号与构建记录务必长期归档。5. 数据兼容不删档之后的硬约束前文提到一旦进入不删档测试或正式上线存档和数据库结构就必须向后兼容。程序需要在此之前做好准备要点说明存档带版本号每份存档、每条关键数据都记录自己的结构版本迁移脚本结构变化时提供从旧版本到新版本的迁移逻辑并逐级升级只增不改字段尽量只新增不修改含义、不复用旧字段迁移可测试保留各历史版本的样本存档作为迁移测试用例可回滚服务端数据迁移前备份迁移失败能够回退一个简化的存档迁移示意CURRENT_VERSION3defmigrate(save:dict)-dict:versionsave.get(version,1)ifversion2:# v1 → v2金币从单一字段拆分为付费与免费两类save[coin_paid]0save[coin_free]save.pop(coin,0)version2ifversion3:# v2 → v3新增设置项给出默认值save.setdefault(settings,{})[subtitle]Trueversion3save[version]versionreturnsave示例只展示“逐级迁移”的结构。真实项目还需要考虑迁移失败处理、大批量数据的分批迁移和线上灰度验证。6. 性能预算分阶段达标性能不能等到 Beta 才开始优化但也不必在原型阶段就追求极致。常见做法是为每个里程碑设定性能目标阶段性能目标示意原型能运行即可但要识别出明显的技术风险垂直切片切片范围内在目标平台达到目标帧率与内存Alpha全部内容可运行性能问题清单明确有优化计划Beta主要场景在目标平台达标内存与包体在预算内RC全部达标长时间运行无内存泄漏、无明显卡顿性能预算通常拆到各个维度帧时间CPU / GPU、内存按模块分配、包体大小、加载时间、发热与耗电移动端。预算在垂直切片阶段制定在制作期持续监控可以通过自动化性能测试在每日构建中跟踪趋势。7. 发布前要移除的东西开发期间为了方便调试会加入很多“后门”。它们必须在发布版本中被关闭或剔除内容风险作弊指令、GM 面板玩家获得不该有的能力破坏经济与公平调试菜单、跳关功能绕过正常流程测试服务器地址、内部接口暴露内部环境详细日志、敏感信息输出泄露数据影响性能服务器时间偏移等测试能力可被利用绕过时长、活动等限制未发布内容的资源被拆包泄露提前“剧透”实现建议通过编译宏、构建配置把调试代码整段排除而不是仅仅隐藏入口服务端对 GM 指令做权限校验不依赖客户端是否显示按钮在发布流程中加入自动检查扫描发布包中是否存在调试符号、测试地址、内部关键字。8. 平台认证与提审准备认证不通过往往不是因为“大 Bug”而是因为系统事件和边界情况处理不当。建议在 Alpha 之后就开始对照平台要求自查应用挂起、切后台、恢复后的状态正确网络断开与恢复时有明确提示不卡死存储空间不足、存档写入中断时不损坏数据手柄断开、切换用户主机时正确处理成就 / 奖杯在正确时机解锁界面术语符合平台规范隐私政策、账号删除、权限申请说明等满足商店要求提审账号、演示说明已准备9. 用垂直切片的数据做估算程序同样需要从垂直切片中获取估算依据问题估算方法一个新系统需要多久参考切片中同类系统的实际耗时内容量放大后性能如何以切片的性能数据为基准按内容规模推算并预留余量工具链能否支撑量产统计切片期间内容制作中因工具问题浪费的时间哪些部分是“演示专用”列出切片中写死、手工调整的部分计入后续工作量估算时最容易被低估的是“集成”和“修 Bug”的时间。单个功能开发完成只是工作的一部分。八、常见的坑问题后果正确做法原型代码直接进入正式工程技术债从第一天开始累积原型验证完成后重写或经过评审再保留垂直切片依赖大量写死逻辑高估进度量产时才发现做不出来明确标记演示专用部分计入工作量不确认团队对 Alpha、Beta 的定义不同人对“完成”理解不一致在项目初期写清楚每个里程碑的验收标准Alpha 之后继续加功能Bug 无法收敛发布延期新想法进入需求池走变更评审临近发布还做重构引入新的阻断级问题记录到技术债清单上线后再处理发布分支修复没有合回主干下个版本问题复现规定修复流向用工具检查漏合线上版本找不到符号文件崩溃无法定位每个发布版本自动归档符号不删档后才考虑存档兼容数据结构改动困难甚至被迫回档早期就为存档和数据库加版本号与迁移机制调试功能只隐藏入口被破解后滥用编译期剔除服务端校验权限认证与提审周期未纳入排期错过发售日或上线窗口提前了解平台周期预留重新提交时间混淆内部 Beta 与对外 Beta 测试沟通中产生误解明确说明“内部里程碑”还是“对外测试”九、里程碑自查清单程序视角里程碑程序侧检查项原型核心问题已验证技术风险已记录明确哪些代码要丢弃垂直切片在目标平台达到目标性能生产管线可支撑量产演示专用部分已标记性能预算已制定Alpha全部功能实现无阻断主流程的问题平台功能开始接入存档与数据结构有版本机制Beta功能与文本冻结主要场景性能达标发布分支已拉出变更评审流程已建立RC无已知阻断级问题调试功能已剔除构建可复现符号已归档平台要求已自查黄金版 / 上线认证或提审通过首日补丁计划明确线上监控与告警就绪回滚方案已演练小结里程碑核心问题关键词程序的心态原型好不好玩、做不做得出来快、粗糙、可丢弃速度优先First Playable核心循环能否跑通完整链条打通流程垂直切片成品什么样、成本多少最终品质、可量产验证架构与管线Alpha功能是否齐全功能完成、功能冻结开始收敛Beta能否发布内容完成、只修不改稳定优先RC还有没有阻断问题候选版本、回归测试能不改就不改黄金版——最终版本、认证、首日补丁做好上线准备一句话概括里程碑是项目在不同阶段对“完成”的约定。原型回答“好不好玩”垂直切片回答“做不做得出来”Alpha 回答“东西全不全”Beta 回答“能不能发”黄金版则意味着交付。对程序员来说理解里程碑最重要的意义在于知道当前阶段允许做什么、不该做什么。早期大胆试错、夯实架构中期支撑量产、控制技术债后期收敛改动、守住稳定。同样的代码改动放在不同的阶段价值和风险完全不同。参考资料Heather Maxwell Chandler《The Game Production Toolbox》《The Game Production Handbook》Clinton Keith《Agile Game Development: Build, Play, Repeat》Jason Schreier《Blood, Sweat, and Pixels》中译本《游戏开发血、汗与像素》Tynan Sylvester《Designing Games》AppleTestFlight 文档、App Store Review GuidelinesGoogleGoogle Play Console 测试轨道内部、封闭、开放测试文档ValveSteam 抢先体验Early Access说明GDC 历年制作管理Production、垂直切片与发布流程相关演讲本文对各里程碑的描述为业界常见含义。不同公司、项目和合同的定义可能不同请以团队内部约定和合同条款为准。
)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
