1. 从“摔车”说起：为什么我把自己的开发方式推倒重来
“摔车”这个词，是我对自己早期做游戏开发状态的一个比喻。不是真的骑摩托摔了，而是那种一路猛冲、突然翻车、爬起来发现车也坏了、路也走错了的感觉。我最早做游戏，靠的是一股蛮劲：想到一个玩法，打开引擎就开干，场景搭一半觉得不对，又回头改代码，代码改到一半发现美术资源规格不对，再回头调导入设置。一个两周能做完的小Demo，我硬是拖了两个月，最后还烂尾了。那段时间我最大的问题不是不会写代码，而是没有一套稳定的做事流程。每次开新项目，都像第一次做游戏一样，从零开始踩坑。
后来我读到一本讲技术扩散的书，里面提到一个叫“chasm”的概念，中文一般叫“鸿沟理论”。它把采用新技术的人分成几类：创新者、早期采用者、早期大众、晚期大众、落后者。我对照了一下自己，发现我在“游戏开发方法论”这件事上，妥妥属于laggards那一群人。别人已经在用成熟的SOP管理项目、用skill蒸馏的方式沉淀经验，我还在靠记忆和临时反应硬撑。承认这一点挺难受的，但也是转折点。因为我意识到，做游戏不是拼谁灵感多，而是拼谁的系统更稳。
这篇文章我想聊的，就是我怎么从一个“摔车型”开发者，慢慢摸索出一套属于自己的skill蒸馏方法，把零散的经验变成可复用的SOP。关键词里提到了游戏开发、SOP、chasm理论、laggards，还有godot、unity、微信小程序游戏这些具体方向。我会把这些串起来讲，不搞虚的，全是自己踩过的坑和后来验证有效的做法。如果你也是那种“每次做项目都像重新投胎”的人，这篇应该能帮你少走几年弯路。
2. chasm理论照进游戏开发：laggards的典型症状与破局点
2.1 我在chasm曲线上的真实位置
chasm理论原本讲的是高科技产品如何跨越从早期市场到主流市场的鸿沟。但我觉得它用来描述个人技能 adoption也特别贴切。创新者是那些自己造引擎、写渲染管线的人；早期采用者是第一批用godot做商业项目的人；早期大众是等unity教程满天飞了才开始学的人；晚期大众是等微信小程序游戏火了两三年才入场的人；而laggards，是直到旧方法彻底跑不通了，才被迫换方式的人。
我早期就是laggards。具体表现是：我明明知道有更好的项目管理方式，但总觉得“我这个项目特殊”“等我做完这个再说”。结果每个项目都特殊，每个项目都烂尾。真正的破局点不是学会某个新引擎，而是承认自己的旧习惯已经失效。这句话听起来像鸡汤，但如果你做过三个以上半途而废的游戏项目，你会懂我在说什么。
2.2 摔车现场复盘：三个让我彻底醒悟的瞬间
第一个瞬间，是我做一个2D平台跳跃游戏时，角色手感调了整整三周。每次改完参数，我都觉得“这次对了”，第二天打开又觉得不对。后来我发现，我根本没有记录每次调整的参数和对应的感受。我在用随机试错代替系统调参。第二个瞬间，是我用godot做一个解谜Demo，场景切换逻辑写了五遍，每次都是重新写，因为我没有把之前的逻辑抽象成可复用的节点或脚本。第三个瞬间，是我准备面试unity开发岗位时，面试官问我“你上一个项目里，资源热更新的流程是怎样的”，我答不上来，因为我根本没做过热更新，甚至没想过这个问题。
这三个瞬间让我明白，laggards的问题不是懒，而是没有把经验变成资产。每次项目结束，经验就随风飘散，下一个项目又从零开始。所谓skill蒸馏，就是把那些飘散的经验，通过一套流程，浓缩成可复用的SOP。
2.3 蒸馏的核心逻辑：从“我会做”到“谁都能照着做”
蒸馏这个词很形象。原酒经过蒸馏，去掉杂质，留下高浓度的精华。游戏开发里的skill蒸馏，就是把你做项目时的隐性知识，变成显性的步骤和检查清单。比如“角色跳跃手感好”是隐性知识，“跳跃初速度设为12，重力加速度设为30，落地缓冲帧数为4”就是显性SOP。前者只有你自己懂，后者换个人也能复现。
我后来给自己定了一个规矩：任何操作，如果我要做第二遍，就必须在第一次做的时候留下记录。这个记录不是写日记，而是写成“如果……那么……”的格式。如果角色跳跃高度不够，那么优先调初速度而不是重力。如果godot场景加载卡顿，那么先检查资源是否在_ready里同步加载。这些规则积累多了，就变成了我自己的SOP库。
3. skill蒸馏的具体操作：把踩过的坑变成可执行的SOP
3.1 第一步：建立“摔车日志”，而不是成功日记
大多数人喜欢记录成功经验，但我觉得失败记录更有蒸馏价值。因为成功往往有运气成分，失败却通常有结构性的原因。我建了一个简单的Markdown文件，每次项目遇到卡点，就记下三件事：当时在做什么、期望结果是什么、实际发生了什么。比如“我在unity里用Animator做攻击动画，期望动画播完自动切回Idle，实际动画播完卡在最后一帧”。这个记录本身不解决问题，但它让我后来能快速定位同类问题。
这个日志我建议用obsidian来管理，因为双链功能可以把相关坑连起来。比如“动画卡帧”和“状态机切换”可以互相链接，下次遇到类似问题，顺着链接就能找到之前的排查路径。关键词里提到了obsidian搭建知识体系SOP模板，我觉得核心不是模板多漂亮，而是你愿不愿意在每次摔车后花五分钟记录。
3.2 第二步：把重复操作提炼成“检查清单”
摔车日志积累到二三十条后，你会发现有些坑反复出现。比如“导入美术资源后忘记设置过滤模式”“打包前忘记切换平台”“微信小程序游戏发布前忘记压缩纹理”。这些坑的共同点是：你知道怎么做，但你就是忘了。对付遗忘，最好的工具不是记忆力，是检查清单。
我现在的检查清单分三类：开项目前检查、每日提交前检查、打包发布前检查。开项目前检查包括：引擎版本确认、渲染管线选择、输入系统方案、资源命名规范。每日提交前检查包括：是否有未保存场景、是否有编译错误、是否有临时调试代码没删。打包发布前检查包括：图标是否替换、权限是否配置、包体是否超标。这些清单看起来琐碎，但每次帮我省下的返工时间，至少是写清单时间的十倍。
3.3 第三步：用“如果-那么”规则替代模糊经验
模糊经验是SOP的天敌。比如“手感要跟手”就是模糊经验，“跟手”到底是什么意思？我后来把它翻译成可执行的规则：输入延迟不超过2帧，加速度曲线在前0.1秒达到峰值，松开按键后减速时间不超过0.15秒。这样调参时就有明确目标，而不是凭感觉来回试。
再比如godot里做UI适配，模糊经验是“要适配不同分辨率”，可执行规则是“使用CanvasLayer加锚点预设，根节点用MarginContainer，所有文本用DynamicFont并设置最小字号”。这些规则写进SOP后，下次做新项目直接复制节点结构，十分钟搞定适配，而不是花两天调布局。
3.4 第四步：定期“蒸馏回炉”，淘汰过时SOP
SOP不是写完就完了。引擎版本更新、平台政策变化、团队人员变动，都会让旧SOP失效。我每季度会花半天时间，把SOP库过一遍，标记出“已过时”“需验证”“仍有效”三类。已过时的直接删掉或归档，需验证的找个小Demo快速测试，仍有效的保持不动。这个习惯让我避免了很多“照着旧教程操作结果报错”的尴尬。
提示：蒸馏回炉时，优先检查那些依赖外部服务的SOP，比如微信小程序游戏的登录流程、unity的包管理配置。这些最容易因为平台更新而失效。
4. 不同引擎下的SOP落地：godot、unity与微信小程序游戏的差异
4.1 godot：节点化思维让SOP更轻量
godot的节点系统天然适合SOP化。因为每个节点职责单一，你可以把常用组合保存为场景模板。比如我做一个“可交互物体”模板，包含Sprite2D、CollisionShape2D、AnimationPlayer和一个自定义脚本，脚本里暴露交互信号。下次做新项目，直接实例化这个模板，改改贴图和信号连接就行。这比unity的Prefab更轻量，因为godot场景文件是文本格式，方便版本管理。
但godot也有坑。比如它的资源导入设置不像unity那样集中管理，每个纹理的过滤模式要在导入时单独设。我的SOP是：所有像素风资源统一用Nearest过滤，所有高清资源统一用Linear加Mipmaps。这条规则写进项目启动清单，省得每次导入都纠结。
4.2 unity：用Editor脚本把SOP自动化
unity的强项是编辑器扩展。我后来把很多检查清单做成了Editor脚本。比如一个“提交前检查”按钮，点击后自动扫描场景里是否有MissingReference、是否有未压缩的纹理、是否有重复的材质。这些检查手动做要十分钟，脚本跑一遍只要三秒。这就是SOP的进阶形态：从文档变成工具。
unity的另一个SOP重点是资源命名和目录结构。我见过太多项目因为资源乱放导致打包出错。我的规则很简单：Assets下只留六个文件夹：Scenes、Scripts、Prefabs、Art、Audio、Settings。所有资源按类型归位，子文件夹按功能划分。这条规则看起来死板，但换人接手时，找东西的时间能减少一半以上。
4.3 微信小程序游戏：包体与性能的硬约束SOP
微信小程序游戏和原生游戏最大的区别是包体限制和运行环境限制。首包不能超过4MB，总包不能超过20MB，这对美术资源是硬约束。我的SOP是：所有纹理必须压缩，优先用ASTC格式；所有音频用低采样率MP3；所有字体用位图字体而不是TTF。这些规则在项目启动时就定好，而不是等到打包超了再回头压。
另一个坑是微信小程序的运行环境。它不支持某些WebGL扩展，也不支持动态代码执行。我的检查清单里有一条：所有第三方库必须确认支持微信小程序环境。这条帮我避免了好几次“本地跑得好好的，上传就白屏”的事故。
| 引擎/平台 | SOP重点 | 常见坑 | 蒸馏后的规则 |
|---|---|---|---|
| godot | 节点模板、导入设置 | 过滤模式遗漏、信号连接断裂 | 像素资源统一Nearest，交互物体保存为场景模板 |
| unity | 目录结构、Editor检查 | 资源乱放、MissingReference | 六文件夹规则，提交前跑Editor脚本 |
| 微信小程序游戏 | 包体压缩、环境兼容 | 首包超标、API不支持 | ASTC压缩、位图字体、第三方库白名单 |
5. 从laggards到SOP实践者：我的心态转变与长期维护
5.1 接受“慢就是快”，放弃一次性完美
laggards最大的心理障碍是总想一步到位。我以前总觉得，等我技术再强一点，就能一次性写出完美的代码和设计。后来发现，完美主义是SOP的敌人。因为追求完美，你会不断推翻重来，永远沉淀不下东西。我现在的做法是：先做一个能跑的版本，然后立刻记录SOP，再迭代优化。哪怕这个SOP很粗糙，也比没有强。粗糙的SOP可以改进，没有SOP只能重复摔车。
5.2 把SOP当成“开发日志”而不是“教科书”
很多人一听SOP就觉得是给团队用的正式文档，个人开发者没必要。但我觉得，个人开发者比团队更需要SOP。因为团队里有人可以问，个人只能靠自己。我的SOP写得很随意，有时候就是几句话加一张截图，但关键是我自己能看懂，下次能照着做。它不是教科书，是开发日志。日志不需要文采，只需要准确。
5.3 定期回顾：每完成一个项目，更新一次SOP库
我现在每完成一个项目，不管大小，都会花一个小时做复盘。复盘只问三个问题：哪些SOP帮了我？哪些坑SOP没覆盖？哪些SOP需要修改？然后把答案更新到SOP库里。这个习惯坚持了两年后，我的SOP库从最初的几页变成了几十页，覆盖了从项目立项到打包发布的全流程。更重要的是，我做新项目的启动时间从两周缩短到了两天。
注意：SOP库不要追求大而全，要追求“用得上”。我见过有人整理了几百页SOP，结果自己从来不看。我的原则是：每条SOP都必须对应一个真实踩过的坑，没有坑就不写。
5.4 给还在鸿沟另一边的你：从今天开始记录第一条
如果你读到这里，觉得自己也是laggards，我想说：没关系，我也是。但laggards有一个优势，就是可以看着前面的人怎么走，然后选一条最稳的路。你不需要自己发明SOP，只需要把别人验证过的方法，结合自己的项目，变成自己的规则。今天就可以开始：打开你的项目，找一个你反复调整的参数，把它记下来，写成“如果……那么……”的格式。这就是你的第一条SOP。别小看这一条，一年后它会变成一百条，而你会从摔车的人，变成修路的人。
我自己的体会是，做游戏开发最爽的时刻，不是做出某个炫酷效果，而是打开新项目，发现所有基础工作都有现成流程，你可以把全部精力放在玩法创意上。那种感觉，就像从泥巴路开上了高速公路。SOP就是你的高速公路，而skill蒸馏，就是修路的过程。
