如何系统化积累游戏开发经验

Category

industry / methodology 子树。节点定位：经验按问题域组织、复盘写约束不写剧情、让经验进入日常流程——从「踩过坑」到「可复用」的完整路径。

Definition

游戏开发最稀缺的不是“踩过坑的人”，而是能把坑讲清楚、复用出去的人。很多团队明明做过多个项目，遇到新问题时仍然像第一次碰见，原因通常不是没有经验，而是经验一直停留在个人记忆和口头印象里。

Problem

经验停留在个人记忆里，新项目照旧像第一次踩坑：讲不清楚（不可复用）、没进流程（不可执行）、按技术名词组织（不可检索）。经验管理的产出是组织能力，不是个人成长笔记。

为什么经验会失效

经验失效常见有三种原因：

• 只记结果，不记前提。比如记住“帧同步好”，却没记住它依赖严格确定性和较稳定网络。
• 只记方案，不记代价。比如记住“拆服务可以扩展”，却不记得当时也付出了链路排障和一致性成本。
• 只记事故，不记触发条件。事后知道出过问题，但说不清为什么会在那个阶段、那个规模下爆出来。

没有上下文的经验，很容易变成口号。

应该沉淀什么

比起写“某技术介绍”，更有价值的是把一次判断拆成固定结构：

• 当时面对的核心问题是什么。
• 项目的玩法类型、平台、阶段和团队条件是什么。
• 可选方案有哪些，为什么排除了其他方案。
• 最后方案带来了哪些收益，又引入了哪些新成本。
• 上线后哪些现象证明判断是对的，哪些现象说明原判断需要修正。

这种写法的价值在于，后来的人能判断自己是否处在相似条件下，而不是机械照搬结论。

经验要按问题域组织

如果经验文档按人、按时间、按项目散落，复用效率会很低。更好的组织方式通常是按问题域沉淀：

• 网络与同步类问题放在一起。
• 房间与战斗状态类问题放在一起。
• 配置、数据、版本、运营类问题放在一起。
• 安全、风控、审计、合规类问题放在一起。

这样做的好处是，新项目可以直接按问题来检索，而不是去猜“这件事是不是某个老项目当年碰到过”。

复盘不该只写事故经过

真正有用的复盘，至少要回答四件事：

• 为什么事前没有发现。
• 为什么现有机制没有拦住。
• 如果再来一次，最应该前移的防线是什么。
• 这个问题是个案，还是一类系统性问题的表现。

如果复盘只停留在时间线和责任归属，它对未来项目帮助有限。复盘应该沉淀判断框架和防呆机制，而不只是记录一次事故。

让经验进入日常流程

经验库只有在进入日常流程时才有价值。比较有效的做法包括：

• 方案评审时要求引用已有案例和边界条件。
• 事故复盘后要求补充到对应问题域，而不是单独散落一篇。
• 新人培养不只看技术名词，而是看典型问题与取舍案例。
• 版本上线前用问题清单做走查，而不是完全依赖个人记忆。

这样经验才会从“文档资产”变成“决策输入”。

常见错误

• 沉淀大量概念总结，却没有真实项目条件和代价描述。
• 文档只讲成功经验，不讲失败和回滚过程。
• 经验库长期不维护，旧结论和现有技术栈、组织结构已经脱节。
• 把经验沉淀当成某个架构师的个人工作，而不是团队协作机制的一部分。

系统化积累经验的目标，不是把团队变成文档工厂，而是让每次付出的成本都能在后续项目里减少一次重复犯错。

Used By

团队知识库组织；复盘制度设计；技术分享的选题与结构。

Related

关系链：经验失效 → 沉淀什么 → 按问题域组织 → 复盘写法 → 进流程。上游：methodology/06（阶段间传递）。下游：production/retro/04（失败案例分析）、production/retro/05（个人自检）。

Reference

本页为工程经验归纳。