企业官网建设流程全解析

接手一个被前同事称为“石螺母的烂摊子”的遗留游戏项目，是很多开发者的噩梦。项目代号写的是《责任的电话6：红肠战争2》，听起来像恶搞，可当你打开代码仓库那一刻，才发现“烂摊子”三个字一点都没夸张：几百个无注释的脚本、散落一地的模型贴图、构建脚本只能在一台特定电脑上跑通，版本管理乱到没人敢合并主干分支。更麻烦的是，下个版本还排了上线日期。

这篇文章想说的不是某个具体游戏引擎的炫技操作，而是关于“如何承接一个混乱的、历史包袱很重的游戏项目”的工程方法论。无论你做 Unity、Unreal 还是 Godot，只要项目里有别人留下的老旧代码，你就会遇到同样的困境。我会从评估现状、搭建安全网、梳理仓库、管理资源、建立自动化测试与构建流水线这几个角度，一步步拆解怎么把“烂摊子”收拾成可以继续迭代的项目。

1. 接手遗留游戏项目，首先别急着重写

很多有经验的开发者接手乱项目时，第一反应是“推倒重来”。这个想法非常诱人，因为重写意味着你可以用自己喜欢的技术栈、干净的目录结构、舒适的设计模式。但我见过太多团队因为“重构”拖垮了项目，原因很简单：游戏项目不仅仅是代码，还包括大量美术资源、动画状态机、关卡配置、UI 预制体、音频混合组。这些资产往往与代码深度耦合，你根本不知道哪些能被删除，哪些还在被某些隐藏逻辑引用。

真正的目标不是“把代码变漂亮”，而是“把风险控制住”。也就是说，要在不影响玩法逻辑和内容产出的前提下，把项目恢复到可观察、可回滚、可验证的状态。

说得直白一点：接手烂项目的核心动作是把它从“只有原作者能跑”变成“团队里任何人都能跑”。这句话听起来简单，做起来却涉及很多具体工作，包括依赖锁定、环境统一、构建脚本化、自动化测试和清理无用资产。每一步都不需要天才级别的技术能力，但需要足够耐心和清晰的优先级。

这篇文章适合的人群是：

• 刚被安排接手遗留游戏项目的开发人员；
• 想给个人项目做一次工程化梳理的独立开发者；
• 负责团队架构和构建流程的技术负责人。

读完你可以得到一套可以直接复用的处理思路，包括如何做现状盘点、如何建立版本安全网、如何设计资源完整性检查脚本，以及上线前如何验证重构没有破坏功能。

2. 游戏项目“烂摊子”的典型症状与评估方法

在动手之前，先回答一个问题：什么样的项目算“烂摊子”？不同团队标准不同，但以下四类症状非常常见，如果你在仓库里发现其中两三个，就说明接手后的主要任务不是写新功能，而是做工程治理。

2.1 代码层的症状

脚本文件命名混乱，test_final2.unity3d、renamed_old、backup_0412随处可见；同一段逻辑在两三个脚本里重复实现，但行为略有差异；某个全局单例管理器承载了所有职责，任何功能都往里塞；注释不是没有就是过时，甚至说明和实际逻辑完全相反。

最典型的一点是：代码里充斥大量魔法数字和字符串，比如用if (stage == 7)这样的判断表示某个关卡状态，没有人说得清 7 代表什么。这导致修改一个玩法逻辑就可能引发连锁反应，因为所有地方都在硬编码。

2.2 资源层的症状

美术资源、音频资源没有统一的目录规范，模型和贴图分开存放，命名靠拼音缩写；Assets目录下存在大量未被任何场景引用的资源，但没人敢删；同一个材质球复制了十几个副本，只是颜色参数不同；预制体引用了被移动过的资源文件，导致 prefab 在打开时出现 Missing Reference。

资源问题在大型项目中比代码问题更棘手。代码有编译错误还能定位，而一个丢失引用的预制体可能只在运行时某个特定时刻凭空报空引用，查起来非常费时间。

2.3 构建与依赖层的问题

构建脚本存在个人电脑的本地路径里，换个机器就无法执行；依赖的第三方插件版本没有记录，升级引擎后插件直接罢工；SDK 版本混用，Android 端和 iOS 端各自为政。更常见的是，项目没有做依赖锁定，团队成员各自装最新版插件，提交到仓库后引发一堆莫名冲突。

2.4 版本控制的混乱

长期使用单一主干分支，所有功能直接往 master 上堆；提交信息写的是“fix”“update”“111”；仓库体积巨大，因为历史里躺着几十个上百 MB 的二进制包；合并冲突时有人直接使用git checkout --theirs暴力覆盖，导致别人的改动无声无息地消失。

拿到一个这样的项目，先不要急着改任何东西。第一步是给现状打分，把问题分到代码、资源、构建、版本控制这四类里，然后按“导致构建失败”“影响开发效率”“影响运行稳定性”三个级别评估优先级。

可以做一个简单的健康度检查表：

做这个评估的价值在于：它决定了你后续是把重点放在重构代码上，还是先把构建脚本化，又或者是优先清理仓库体积。我的建议永远是先解决“构建不能复现”的问题，因为只要构建能稳定复现，后续修改就有验证依据；如果构建都依赖某台电脑，你做什么都像在悬崖边走路。

3. 环境准备与前置条件：先给项目装上安全网

接手任何遗留项目的第一原则就三个字：先备份。不管你觉得项目有多烂，它都是前团队投入了大量时间的结果。没有备份之前，任何清理、重构、依赖升级都是不负责任的。这里的备份不只是复制一份文件夹，而是建立一套可持续的版本控制安全网。

3.1 建立仓库备份分支

假设项目已经用 Git 管理，第一步是在当前状态上打一个标签，再创建一个备份分支。这个标签用来标记“接手时的初始状态”，一旦后续操作把你带进死胡同，可以随时回到这里。

# 先确认当前仓库状态，不要带未提交的改动操作 git status # 创建备份分支 git checkout -b archive/legacy-backup # 打一个接手时间点的标签 git tag project-handover-2025 # 切回原来的开发分支 git checkout main

如果项目之前没有用 Git，甚至没有版本控制，那第一件事是初始化仓库并提交一份完整快照，然后把这份快照额外拷贝到移动硬盘或内网存储。不要嫌多余，这一步会在后面救你很多次。

3.2 明确引擎和运行环境版本

很多遗留项目最大的问题是“谁能跑，只有谁电脑能跑”。表面原因千奇百怪，本质都是环境差异。尽可能从项目文档、旧提交记录、CI 配置里找出当时使用的引擎版本和第三方插件版本。找不到时，就去看引擎工程文件里的版本号字段，例如 Unity 工程根目录下ProjectVersion.txt就记录了 Unity 版本。

版本统一原则是：先对齐到项目历史使用的版本，而不是升级最新的引擎。因为升级引擎是另一个高风险动作，不应该和清理工作混在一起做。等项目的构建、资源、代码都稳定下来了，再单独安排一次引擎升级。

3.3 准备一套可复现的构建环境

理想状态是，执行一条命令就能从最新代码构建出可运行版本。这个目标通常要用两部分实现：本地的构建脚本和持续集成流水线。本地脚本解决的是“不用记住一长串命令”的问题，CI 解决的是“任何人任何机器都能构建”的问题。

在搭建构建环境时，建议采用最小化原则：先跑通当前代码，再考虑优化构建速度。不要一开始就引入复杂的缓存方案、分布式构建、增量编译优化，这些是后续迭代的事。先把构建从“手动打开编辑器点按钮”变成“命令行执行脚本”，已经是一个巨大进步。

4. 代码仓库梳理：从目录结构到依赖管理

环境安全网搭好后，才正式进入仓库治理。这一阶段的目标不是重写代码，而是让仓库变得可理解、可构建、可维护。重点做三件事：整理忽略规则、锁定依赖、实现构建脚本化。

4.1 使用 .gitignore 拦截无用文件

游戏项目最容易把大量生成文件、缓存文件和本地配置误提交进仓库。仓库里如果混着临时文件，体积会快速膨胀，团队成员拉取代码会越来越慢，而且很容易出现“我本地没问题，你拉下来就报错”的怪问题。

以 Unity 项目为例，一份合理的.gitignore至少应该忽略以下内容：

# 文件路径：.gitignore # 临时文件和系统文件 .DS_Store Thumbs.db # IDE 和编辑器配置（个人配置不要入库） .idea/ .vs/ .vscode/ *.csproj *.sln *.user *.pidb *.booproj *.svd *.pdb *.mdb # Unity 生成目录 [Ll]ibrary/ [Tt]emp/ [Oo]bj/ [Bb]uild/ [Bb]uilds/ [Ll]ogs/ [Uu]serSettings/ gradle-app-jni/ google-services.json # 依赖缓存 node_modules/ packages/ # 大文件备份和崩溃日志 *.orig *.unitypackage *.crashreport

注意，*.pdb和*.mdb是调试符号文件，不需要入库；UserSettings里保存的是每个开发者的编辑器布局，入库只会制造冲突。团队里应该约定项目级配置入库，个人级配置 gitignore。

真正的核心是：保证一个新成员 clone 仓库后，依赖声明都能从版本库或包管理器还原，而不是靠某个同事手动拷贝。

4.2 锁定依赖版本

游戏项目常见的依赖问题是“没有锁版本”。比如使用 npm 管理前端构建工具时，package.json里写"webpack": "^5.0.0"，意味着每次安装依赖都可能拿到当时的最新小版本。本次构建和上次构建用了不完全相同的依赖，这是莫名其妙的构建失败的一个高发源头。

解决办法很简单：使用依赖锁定文件。npm 提交package-lock.json，yarn 提交yarn.lock，NuGet 提交packages.lock.json。Unity 的 UPM 包依赖记录在Packages/manifest.json里，同时用Packages/packages-lock.json记录解析结果。

对第三方插件更稳妥的做法是：把插件压缩包上传到团队内部制品仓库，而不是直接引用个人网盘或引擎商店的最新版。这样即使上游插件下架或改版，你的项目仍然可以还原到可用版本。这一点在游戏行业尤其重要，因为很多美术插件和资源商店插件的更新频率并不稳定。

4.3 构建脚本化

构建脚本化是所有工程治理动作里收益最明显的一步。哪怕只是写一个 20 行的批处理脚本，把原来需要手点的 10 个编辑器操作变成一条命令，都能极大提升团队的稳定性和安全感。

以下是一个 Windows 环境下的 Unity 命令行构建示例，核心思路是调用 Unity 编辑器以批处理模式执行构建接口：

# 文件路径：build/windows_build.bat @echo off chcp 65001 >nul set UNITY_PATH=C:\Program Files\Unity\Hub\Editor\2021.3.20f1\Editor\Unity.exe set PROJECT_PATH=%~dp0.. set BUILD_METHOD=BuildScript.PerformWindowsBuild set LOG_FILE=%~dp0..\build\build_log.txt echo [INFO] Start Windows Build... "%UNITY_PATH%" -batchmode -nographics -quit -projectPath "%PROJECT_PATH%" -executeMethod "%BUILD_METHOD%" -logFile "%LOG_FILE%" if errorlevel 1 ( echo [ERROR] Build Failed. Please check build_log.txt exit /b 1 ) echo [INFO] Build Success.

配合一个编辑器脚本文件：

// 文件路径：Assets/Editor/BuildScript.cs using UnityEditor; using UnityEditor.Build.Reporting; public class BuildScript { public static void PerformWindowsBuild() { BuildPlayerOptions buildPlayerOptions = new BuildPlayerOptions(); buildPlayerOptions.scenes = new[] { "Assets/Scenes/MainMenu.unity", "Assets/Scenes/Gameplay.unity" }; buildPlayerOptions.locationPathName = "build/windows/game.exe"; buildPlayerOptions.target = BuildTarget.StandaloneWindows64; buildPlayerOptions.options = BuildOptions.None; BuildReport report = BuildPipeline.BuildPlayer(buildPlayerOptions); if (report.summary.result != BuildResult.Succeeded) { throw new System.Exception("Build failed with result: " + report.summary.result); } } }

这份代码的核心逻辑是：把场景列表、输出路径、目标平台参数化后调用BuildPipeline.BuildPlayer，再把构建结果输出到日志。此前手动在编辑器里操作时，切换场景和导出步骤经常漏掉，脚本化之后整个流程变得稳定。真正容易踩坑的地方在BuildPlayerOptions里的场景数组：如果列表里的场景路径写错了，构建不会失败，但打出来的包可能缺少某个核心关卡。所以脚本里的场景列表一定要和游戏真正进入流程所需的场景保持一致。

5. 场景与资源资产管理：定位“找不到资源”的根源

代码逻辑问题影响的是功能，资源管理问题影响的是整个项目的产出效率。在游戏项目中，美术同学和策划同学每天都在产生新资源，如果缺失一套清晰的规范，库内就会逐渐堆满各种“仅供参考”的文件夹。

5.1 统一资源目录规范

常见的资源目录分区方式是按资源类型划分，例如：

Assets/ Art/ Models/ Textures/ Materials/ Animations/ VFX/ Audio/ Music/ SFX/ Prefabs/ Scripts/ Scenes/ Configs/

但这只是第一层规范。真正决定资源能否被长期管理的是命名。强制推行的优先级：能用英文命名就不用拼音，能描述“功能+类型”就不要用日期和人名。例如player_running_loop.fbx优于跑步.fbx或player_013_final_v2.fbx。

同样的资源如果被多个场景引用，建议做成资源包或 Prefab 统一管理，而不是让每个场景都复制一份实例。游戏项目的很多内存问题就出在“同一个模型被复制了十几份”。

5.2 检测丢失引用和未使用资源

清理项目的第一步不是删东西，而是先找出「正在被引用」和「没有被引用」的资源。否则你删掉一个看起没用的文件夹，可能全项目报错。

资源引用图检查是一项非常机械的工作，适合用脚本完成。下面以 Godot 项目为例，写一个极简的资源完整性检查脚本，用来自动找出 .tscn 场景里引用但找不到对应文件的情况。这个脚本的思路同样适用于 Unity 的 YAML 资产检查，本质都是“读取文本引用，校验文件是否存在”。

# 文件路径：tools/check_resource_refs.py import os import re import sys PROJECT_ROOT = os.path.abspath(os.path.join(os.path.dirname(__file__), "..")) # 需要检查的资源类型 RESOURCE_EXTS = {".tscn", ".tres", ".gd", ".gdshader"} # Godot 场景文件中 ext_resource 的引用格式 # 例如：ext_resource type="Texture2D" path="res://assets/textures/icon.png" id="1" REF_PATTERN = re.compile(r'path="res://([^"]+)"') def is_ignored(path): ignore_dirs = {".git", "build", "logs", ".import"} parts = path.split(os.sep) return any(part in ignore_dirs for part in parts) def main(): missing = [] checked = 0 for root, _, files in os.walk(PROJECT_ROOT): if is_ignored(root): continue for name in files: ext = os.path.splitext(name)[1] if ext not in RESOURCE_EXTS: continue filepath = os.path.join(root, name) checked += 1 try: with open(filepath, "r", encoding="utf-8") as f: content = f.read() except UnicodeDecodeError: continue for match in REF_PATTERN.findall(content): # 解析 res:// 路径，转成绝对路径 ref_path = match.split("?")[0].replace("res://", "") abs_ref = os.path.abspath(os.path.join(PROJECT_ROOT, ref_path)) if not os.path.exists(abs_ref): missing.append((filepath, ref_path)) if not missing: print(f"[OK] checked {checked} files, no missing references.") return 0 print(f"[WARN] found {len(missing)} missing references in {checked} files:") for src, ref in missing[:100]: print(f" {src} -> {ref}") return 1 if __name__ == "__main__": sys.exit(main())

运行方式很简单：

python tools/check_resource_refs.py

脚本会遍历项目中的场景、资源和脚本文件，提取res://形式的相对引用并检查文件是否存在。输出结果中出现的每一行，都代表某处引用了磁盘上不存在的资源，这是导致场景打开报错或运行时一片空白的典型原因。

这类检查脚本的价值不在“能跑”，而在于它可以固化下来成为仓库里的标准工具。以后任何人移动了资源路径，都可以跑一遍脚本快速找出所有受影响的引用点。这种“低成本发现风险”的能力，正是烂项目团队最缺的。

5.3 清理资源的先后顺序

清理资源有一个不可违背的顺序：先从代码和场景中确认引用，再决定删除。稳妥的清理工作流是：

• 先跑资源引用检查脚本，列出所有未被引用的资源；
• 把未被引用的资源移动到一个_trash目录，而不是直接删除；
• 让项目运行几个核心关卡，确认没有报错；
• 一段时间（比如两个版本周期）后，再真正从版本库中删除。

直接删除是不可取的，因为很多资源名义上没被引用，实际是运行时通过字符串路径加载的。例如代码里通过load("res://cutscenes/opening/final_v2.tscn")动态加载的场景，静态引用扫描发现不了。把资源移入回收目录，相当于留了一层缓冲。

6. 建立自动化测试与构建流水线

很多游戏团队觉得自动化测试不重要，理由是“玩法没法自动化验证”。这个判断对一半：视觉表现确实难以自动测试，但游戏里的核心逻辑，比如数值计算、状态机切换、背包数据结构、存档读写、网络协议解析，都是可以用单元测试覆盖的。对遗留项目来说，自动化测试首要价值不是保证正确性，而是给未来的改动兜底。

6.1 先补冒烟测试

接手阶段不建议追求 100% 覆盖率，重点应放在“冒烟测试”：项目启动后，能否顺利走到主菜单、加载关卡、进入核心玩法。这一类测试可以通过场景加载断言来完成。

以 Unity 为例，使用 Unity Test Framework 写一个简单的冒烟测试：

// 文件路径：Assets/Tests/SmokeTests.cs using System.Collections; using NUnit.Framework; using UnityEngine; using UnityEngine.SceneManagement; using UnityEngine.TestTools; public class SmokeTests { [UnityTest] public IEnumerator MainMenuScene_Should_Load_Without_Errors() { try { AsyncOperation op = SceneManager.LoadSceneAsync("MainMenu"); while (!op.isDone) { yield return null; } LogAssert.NoUnexpectedReceived(); Assert.AreEqual("MainMenu", SceneManager.GetActiveScene().name); } catch (System.Exception ex) { Assert.Fail("MainMenu failed to load: " + ex.Message); } } }

这个测试的作用非常直接：如果某次改动破坏了主菜单场景，测试会在构建前失败，把你从“运行到一半黑屏”的尴尬境地中救出来。因为是遗留项目，测试不通过时，第一步先看场景里是否有 Missing Script，大多数冒烟测试失败都是以下几个原因：场景引用的脚本丢失、启动场景路径写错、某个静态初始化代码报了异常。

6.2 搭建一条最简 CI 流水线

流水线的目标不是做成大而全的智能平台，而是满足一个核心诉求：代码推送到远端之后，能自动执行构建和测试，并且把失败原因清晰反馈到提交记录里。以下是一条基于 GitHub Actions 的 Unity 构建最小示例：

# 文件路径：.github/workflows/build.yml name: Unity Build and Test on: push: branches: [ main, develop ] pull_request: branches: [ main ] jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: lfs: true - name: Restore Project uses: actions/cache@v3 with: path: Library key: Library-${{ hashFiles('Assets/**', 'Packages/**', 'ProjectSettings/**') }} restore-keys: | Library- - name: Run Tests uses: game-ci/unity-test-runner@v4 env: UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }} with: projectPath: . testMode: playmode - name: Build Windows uses: game-ci/unity-builder@v4 env: UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }} with: projectPath: . targetPlatform: StandaloneWindows64

这条流水线里有几个细节值得注意。actions/cache缓存Library目录，是因为 Unity 每次构建都要生成庞大的中间文件，缓存能大幅缩短构建时间，但缓存 key 变化时仍然能够重建，不会影响正确性。UNITY_LICENSE通过 Secret 注入，避免在仓库里暴露许可证信息。整个流水线执行顺序是：拉代码、恢复缓存、跑测试、构建 Windows 包，任何一个环节失败都会在 PR 页面直接标红。

这套做法对遗留项目的意义在于：以后任何人在任何分支上修改代码，都能得到“是否破坏构建”的及时反馈，而不需要等很久之后才在某个人的电脑上暴露问题。

6.3 本地快速验证流程

CI 适合做最终的守门员，但开发过程中你不可能每次修改都推送到远端等流水线。所以本地也要有一套快速验证流程。推荐的做法是写一个 Makefile 或简单的脚本文件，把常用命令集中管理，节省记忆成本：

# 文件路径：Makefile .PHONY: test build run clean test: python tools/check_resource_refs.py python -m pytest tests/unit build: ./build/windows_build.bat run: ./build/windows/game.exe clean: rm -rf Library Temp Logs

这样一个项目成员只需要执行make test、make build就可以完成日常验证。对比“先打开编辑器、再跑场景、再手动点击 Build”的方式，脚本化直接把开发者的认知负担降到最低。

7. 运行结果与效果验证：怎么判断治理是否成功

工程治理不是“改完代码能运行”就算成功，而是要求可度量。整理一个遗留项目前后，建议记录一组关键指标，用来证明改动确实起到了效果，也方便向团队汇报进展。

建议统计以下指标：

验证是否成功的操作步骤，建议按以下顺序执行：

第一步，从远端重新 clone 一份全新的仓库副本，不要使用你本地已经缓存的副本，因为这样最容易暴露依赖缺失和提交遗漏。第二步，按照项目 README 里的说明执行构建命令，观察是否一次通过。第三步，登录一个平时不参与开发测试的同事账号，把新拉取的副本交给对方运行，确认构建步骤足够清晰，不需要口述补充。第四步，跑一遍资源引用检查脚本和自动化测试，确认没有 0 之外的新增输出。

如果前三步任何一步失败，说明项目还处于“只能在你电脑上跑”的状态，继续写新功能就是在错误的地基上盖楼。先修好这一步，再谈后续迭代。

真正容易判断失误的地方在于“运行成功”这个标准。很多人看到游戏能启动就认为项目没问题，但遗留项目里隐藏的很多缺陷，比如极端输入导致的数组越界、增删背包物品时的资源泄漏，并不会在启动阶段暴露。所以更稳健的做法是，梳理出一份核心玩法清单，每修改一个模块，就按清单走一遍关键路径。这份清单应该存在仓库文档里，而不是某个人脑子里。

8. 常见问题与排查思路

治理遗留项目过程中，几乎每个团队都会遇到以下几类问题。踩过之后把这些经验沉淀成排查文档，能帮后来者节省大量时间。

其中仓库大体积文件的问题在游戏项目中特别常见。很多团队早期直接提交了数个 GB 的模型源文件或贴图源文件，导致后续每个人 clone 都痛苦不堪。处理方案是用 Git LFS 管理大文件，或从历史中移除误提的大文件。后者属于重写历史，一定要在团队约定好备份切点之后再执行，并且通知所有成员重新 clone，否则会出现本地历史与远端不一致的新混乱。

排查这类问题有个通用思路：永远先看日志，再看依赖，最后猜代码。很多游戏团队习惯一报错就怀疑业务逻辑写得不对，但大量问题其实出在资源导入或依赖还原阶段。构建日志底部如果有明显的红色错误信息，直接看那一段，不要从日志开头逐行读，因为 Unity 或 Godot 的日志经常包含很多无害警告。搜索关键字error、failed、missing比人眼扫描日志快得多。

9. 最佳实践与工程建议

完成一次遗留项目治理并不是终点，而是把团队从“不断救火”切换到“可以正常迭代”的过程。以下几条工程建议，是在做过多个类似治理项目之后总结出来的，也是我认为最值得沉淀下来的经验。

9.1 治理阶段绝对不要混入功能开发

接手烂摊子期间，产品经理大概率仍然会提新需求。这时候团队最容易犯的错误是边清理边开发，导致你的重构和别人的新代码纠缠在一起，出现问题时根本说不清是重构引入的还是新功能引入的。更稳妥的安排是：短期停掉非紧急新功能，集中一到两个迭代周期做工程治理；如果新功能无法暂停，至少要把清理工作限制在独立分支上，不和业务功能合并到一起。

9.2 建立“当前可用版本”概念

每完成一个阶段的治理，就应该打一个 tag 并产出一个可运行的版本包。这个版本包不一定要有完整新内容，但必须能覆盖核心玩法路径。它的作用就像一个锚点：后续任何改动，都拿这个版本包做对比。这个习惯比任何测试都实用，因为它保证了“如果新改动有问题，团队永远有一个可回退的版本可以继续做演示和发行”。

9.3 用文档固化隐性知识

遗留项目最危险的地方不在代码，而在那些“没说出口的约定”。比如某个关卡必须从某个特定的入口加载才能触发剧情，否则状态机走不到正确流程；某个打包步骤必须提前清空本地缓存，否则资源进入包里就是旧版本。这类知识如果只存在于前开发者的脑子里，他就变成团队的瓶颈。接手治理时，应该请前开发者或熟悉旧逻辑的人逐条口述这些特殊规则，然后把它们沉淀到项目文档和脚本中。宁可文档写了 100 条规则只有 80 条有用，也不要让 20 条关键规则随着某人离开而失传。

9.4 权限和操作边界要提前约定

治理项目经常会做一些有破坏性的操作，比如清理资源、重写历史、删除备份分支。这些操作一旦执行很难撤销。上线之前，团队内应当约定清楚：哪些命令需要在备份分支上执行，哪些操作需要至少两人确认，哪些操作只能在低峰期进行。权限上坚持最小原则，落地到实际就是普通开发者没有 force push 权限，清理仓库历史只有技术负责人执行。这不是不信任团队成员，而是避免“手一滑”造成一连串不可逆的后果。

9.5 不要追求“一步到位”的完美结构

很多开发者在整理项目时容易陷入完美主义的旋涡，觉得要先把架构改成某种理想形态再写新功能。这个想法在遗留项目里尤其危险，因为游戏项目的开发是高度迭代的，你理想中的架构很可能在下一次玩法调整时再度作废。更务实的目标是把项目改造成“可持续演进”的状态：构建稳定、测试可跑、资源不丢、提交可查。只要这四点扎实，项目的结构可以在后续多个版本里逐步演进，不需要毕其功于一役。

9.6 版本控制习惯决定长期稳定性

治理项目的尾声，一定要统一团队的 Git 协作规范。包括但不限于：功能分支从 develop 或 main 拉出，合并前必须通过 CI；提交信息使用统一的格式，例如feat(module): 描述、fix(module): 描述；不把本地生成文件提交进仓库；场景和资源修改尽量小颗粒度提交，避免一个几十 MB 的 prefab 改动把所有人的历史搞乱。

这些规范不需要一步到位，要么先挑最重要的两三条强制执行，比如“PR 必须过 CI”和“合并代码前必须跑冒烟测试”。等团队养成习惯后，再逐步增加更多约束。

看到一个小时的构建变绿，我第一次意识到：烂摊子不是靠一次勇敢的重写解决的，而是靠一次次小心的验证、备份、记录和协作把它磨出来的。真正难的不是技术，而是愿意在一堆混乱中保持耐心，把安全网一遍遍加固，直到团队里的每一个人都可以放心地在这个项目里改东西。如果你手里正抱着一个“石螺母的烂摊子”，不要把目标定成写出完美的代码，先把构建点亮，把测试跑通，把回滚的路留好，后面的事就只是时间问题。