1. 从“摔车”到“SOP”一个laggards的自白先坦白一件事在chasm理论那套技术采用生命周期模型里我属于laggards那一群人。不是early adopter不是early majority甚至连late majority都算不上。新技术出来我通常是最后一个上车的。别人已经在用各种新工具跑通全流程了我还在用最笨的办法手动折腾。摔过车翻过沟踩过的坑能填满一个中型停车场。但恰恰是这种“摔车”经历逼着我琢磨出一套自己的skill蒸馏大法——把游戏开发中那些零散的、靠感觉的、每次都要重新想一遍的操作蒸馏成可复用的SOP。这套方法不依赖某个特定引擎Godot也好Unity也好甚至微信小程序游戏开发那套东西底层逻辑是通的。它解决的核心问题是如何把“我会做”变成“我知道我怎么做出来的并且下次能更快做出来”。这篇文章适合谁看如果你是刚入行的游戏开发新手被各种教程和工具链搞得头晕这篇能帮你建立一套自己的知识蒸馏框架。如果你是有几年经验的开发者但总觉得效率卡在某个瓶颈上做东西全靠肌肉记忆和临时搜索这篇能帮你把隐性经验显性化。如果你是对skill、SOP、知识管理这些概念感兴趣想看看一个laggards怎么用笨办法追上来的那更对味了。我不打算讲什么高深理论就讲我怎么从一次次摔车里把游戏开发这件事拆成能重复执行的步骤怎么用Obsidian搭知识体系怎么把AI工具当成蒸馏加速器而不是替代品。全程大白话能抄作业的地方直接给模板。2. 为什么我选择“蒸馏”而不是“堆料”2.1 chasm理论里的laggards到底在怕什么chasm理论讲的是技术产品从早期市场跨越到主流市场之间那道鸿沟。early adopter愿意为不成熟的东西买单因为他们要的是先发优势。early majority要的是完整方案late majority要的是标配laggards要的是——别让我改。我属于laggards核心恐惧就一条改变现有工作流的成本太高。新引擎出来我要重新学一套API新AI工具出来我要重新配环境、调参数、试错。每次切换都意味着我手头正在做的项目要停摆。所以我本能地抗拒“为了新而新”的东西。但游戏开发这个领域技术迭代速度又特别快。Unity3D一年一个大版本Godot从3.x到4.x几乎重写了一遍渲染管线微信小程序游戏开发那套东西更是跟着平台政策变。你不可能永远不动。laggards的生存策略不是拒绝变化而是等变化稳定下来之后用最低成本把变化吸收进自己的体系。蒸馏就是我的吸收方式。我不追新工具的全部功能我只提取对我当前工作流有增量价值的那部分把它蒸馏成一个skill嵌入我已有的SOP里。这样每次技术更新我的体系不会崩只是多了一个可调用的模块。2.2 skill蒸馏和普通记笔记的本质区别很多人记笔记是“堆料”看到一篇好文章收藏看到一个好工具截图看到一个好技巧复制粘贴。结果笔记库越来越大但真到用的时候还是靠搜索和记忆。这不是蒸馏这是仓库。蒸馏的核心动作是提纯和固化。提纯意味着去掉上下文依赖把“在某个特定项目里用某个特定版本引擎解决某个特定bug”这件事抽象成“当遇到某类问题时按什么顺序检查什么参数”。固化意味着把它写成一个可执行的步骤序列下次遇到同类问题不需要重新思考直接跑SOP。举个例子。我在Godot里做角色移动一开始每次都要重新想用CharacterBody2D还是RigidBody2Dmove_and_slide的参数怎么调重力怎么设碰撞层怎么配每次都要翻文档、搜教程、试错。后来我把它蒸馏成一个SOP“2D平台跳跃角色移动标准配置”里面固定了节点结构、脚本模板、参数默认值、常见问题排查清单。下次开新项目直接复制这个SOP五分钟搞定基础移动把时间留给关卡设计和手感调优。这就是蒸馏的价值把重复决策变成默认执行。你的大脑带宽是有限的省下来的认知资源才能投入到真正需要创造力的地方。2.3 为什么是“大法”而不是“方法”叫“大法”有点戏谑但也确实因为它不是单一技巧而是一套组合拳。我的skill蒸馏大法包含四个环节摔车记录、模式识别、SOP编写、体系嵌入。这四个环节循环迭代每摔一次车体系就厚一层。摔车记录是原始素材。每次遇到bug、每次卡住、每次发现一个更优解立刻记下来。不追求格式不追求完整先记下来再说。我用Obsidian的每日笔记功能随手记打标签。模式识别是定期回顾。每周或每两周翻一遍摔车记录看哪些问题是重复出现的哪些解决方案是可以泛化的。重复出现三次以上的问题就值得蒸馏成SOP。SOP编写是固化。把识别出的模式写成步骤清单包含触发条件、操作步骤、预期结果、异常处理。写的时候要假设读者是三个月后的自己——已经忘了当时上下文只能靠这份SOP复现。体系嵌入是最后一步。把新SOP挂到已有的知识体系里建立索引和关联。下次遇到相关场景能通过标签或链接快速找到。这四个环节里最容易被忽略的是模式识别。很多人记了笔记就完了从来不回顾。结果笔记是死的体系是空的。我强迫自己每周花半小时做这件事收益远超投入。3. 核心细节skill蒸馏的四个关键操作3.1 摔车记录怎么记才能让未来的自己看懂摔车记录最大的坑是“记了等于没记”。当时觉得“这个bug我知道怎么回事了”随手写一句“碰撞检测有问题已解决”。三个月后翻到这条完全想不起来是什么碰撞检测、什么问题、怎么解决的。我的做法是强制自己写四要素现象、环境、排查过程、最终解。现象要具体到能复现环境要精确到引擎版本和插件版本排查过程要记录试过哪些方向、哪些排除了最终解要写清楚改了哪个文件哪一行。比如有一次在Unity里做技能指示器skill attack indicators角色释放范围技能时指示器显示的范围和实际伤害范围对不上。我的记录是这样的现象技能指示器显示半径3米实际伤害判定半径约2.5米边缘敌人不受伤害。 环境Unity 2022.3.10f1URP使用Decal Projector做地面指示器。 排查先检查Decal Projector的size参数确认是3。再检查伤害判定代码发现用的是OverlapSphere半径参数写的是2.5。但为什么视觉和逻辑不一致继续查发现Decal Projector的size是直径不是半径我设了3实际半径是1.5。但视觉上看起来像3米半径是因为Decal的缩放和相机透视有偏差。 最终解统一用半径参数驱动两者。Decal Projector的size设为半径×2OverlapSphere半径设为同一个变量。在Inspector里暴露一个radius字段两边都读这个值。这条记录后来被我蒸馏成了“技能指示器视觉与逻辑一致性检查SOP”包含三个检查点参数单位是否统一、视觉表现是否受相机影响、逻辑判定是否用了同一数据源。提示摔车记录不要追求文采追求可检索性。关键词、版本号、文件路径这些才是未来能救你的东西。3.2 模式识别怎么从一堆碎碎念里找到值得蒸馏的skill摔车记录攒到几十条之后就需要做模式识别。我的方法是用Obsidian的标签系统做粗筛再用Dataview插件做聚合。给每条记录打上领域标签比如#godot、#unity、#ui、#性能、#ai工具。每周回顾时用Dataview查询某个标签下的所有记录看重复模式。重复模式有三种典型形态第一种是同类问题反复出现。比如“Godot里信号连接忘记断开导致内存泄漏”出现了五次那就值得写一个SOP“Godot信号连接与断开标准流程”。第二种是同类操作反复执行。比如每次开新项目都要配一遍输入映射、音频总线、场景切换管理器。那就蒸馏成“Godot新项目初始化SOP”。第三种是同类决策反复纠结。比如“这个功能用信号还是直接调用”“这个数据放资源里还是放脚本里”。那就蒸馏成“Godot架构决策速查表”列出常见场景的推荐方案和理由。模式识别的关键是不要过度蒸馏。只出现一两次的问题记着就行不值得写成SOP。SOP太多会变成负担你根本记不住有哪些SOP更别说用了。我的经验是保持核心SOP在20条以内覆盖80%的重复场景。其他的作为“参考笔记”存在不纳入SOP体系。3.3 SOP编写让步骤可执行、可验证、可迭代SOP不是文档是操作手册。我写SOP遵循一个模板包含六个部分触发条件什么情况下用这个SOP。写得越具体越好比如“当需要在Godot中创建一个可交互的2D角色时”而不是“做角色的时候”。前置检查执行前需要确认什么。比如“确认项目已安装Godot 4.x确认已创建2D场景”。操作步骤编号列表每步一个动作。动作要具体到“点击哪个菜单”“输入什么值”“保存为什么文件名”。避免“配置好参数”这种模糊表述。验证方法怎么确认操作成功了。比如“运行场景按方向键角色应移动松开应停止”。异常处理常见错误和解决方法。比如“如果角色不移动检查Input Map是否配置了move_left/move_right”。关联SOP这个SOP和其他哪些SOP有关联。比如“角色移动SOP关联到动画状态机SOP和碰撞层配置SOP”。这个模板的好处是它强迫你把隐性知识显性化。很多老手觉得“这还用写”的东西恰恰是新手最需要的。而且写的过程本身就是在检验你的理解是否完整——如果你写不出验证方法说明你其实没完全搞懂。注意SOP要定期更新。引擎版本升级、API变更、发现更优方案都要回头改SOP。我每个月会抽时间过一遍核心SOP确保它们和当前实践一致。过期的SOP比没有SOP更危险。3.4 体系嵌入让SOP在需要的时候自动浮现SOP写完了放在文件夹里下次遇到场景想不起来用等于白写。所以最后一步是体系嵌入让SOP在正确的时机自动出现在你面前。我的做法是用Obsidian的MOCMap of Content结构。建几个顶层MOC比如“游戏开发MOC”“AI工具MOC”“知识管理MOC”。每个MOC下面链接相关的SOP和笔记。然后利用Obsidian的模板功能在每日笔记里自动插入当天的“SOP回顾”区块随机推荐一条SOP。这样每天花一分钟扫一眼保持对SOP体系的熟悉度。另一个技巧是场景化索引。不按技术分类按使用场景分类。比如“开新项目时看哪些SOP”“做UI时看哪些SOP”“性能优化时看哪些SOP”。这样你不需要记住SOP的名字只需要知道当前在做什么场景就能找到对应的SOP集合。我还把核心SOP导出成PDF放在手机里通勤时翻一翻。听起来很土但有效。很多SOP你写的时候觉得理所当然过段时间就忘了细节。定期重温才能保持肌肉记忆。4. 实操过程从零搭建一套游戏开发SOP体系4.1 环境准备Obsidian配置和插件选型工欲善其事必先利其器。我用Obsidian作为SOP体系的载体原因有三本地存储、双向链接、插件生态。本地存储意味着数据完全在我手里不怕服务停运。双向链接让SOP之间的关联自然生长。插件生态提供了Dataview、Templater、QuickAdd这些自动化工具。核心插件清单插件名用途必装理由Dataview查询和聚合笔记自动生成SOP索引和回顾列表Templater模板自动化新建SOP时自动填充模板结构QuickAdd快速捕获一键记录摔车笔记不打断心流Tag Wrangler标签管理批量重命名和合并标签Calendar日记导航快速跳转到某天的摔车记录配置上我建了四个文件夹00-Inbox放临时笔记10-SOP放正式SOP20-Reference放参考笔记30-MOC放索引。Inbox里的笔记每周清理一次有价值的蒸馏成SOP或Reference没价值的删掉。Templater模板我设了两个一个用于摔车记录一个用于SOP。摔车记录模板包含日期、现象、环境、排查、解决五个字段。SOP模板包含触发条件、前置检查、操作步骤、验证方法、异常处理、关联SOP六个字段。提示不要一开始就追求完美体系。先跑起来用着用着再调整。我第一版Obsidian库只有三个文件夹后来才慢慢细化。体系是长出来的不是设计出来的。4.2 从摔车到SOP的完整案例Godot角色移动拿一个具体案例走一遍全流程。假设我在Godot里做2D平台跳跃角色移动一直调不好摔了几次车。第一次摔车角色移动时穿墙。记录现象是角色在高速移动时穿过碰撞体环境是Godot 4.2CharacterBody2Dmove_and_slide。排查发现是移动速度太快物理帧间隔内位移超过了碰撞体厚度。解决是把移动逻辑放到_physics_process里并开启move_and_slide的safe_margin。第二次摔车角色在斜坡上滑动。记录现象是角色站在斜坡上会缓慢下滑环境同上。排查发现是重力应用方式不对在斜坡上重力分量导致滑动。解决是设置floor_max_angle并调整floor_snap_length。第三次摔车角色跳跃手感不对。记录现象是跳跃感觉“飘”不够干脆。排查发现是跳跃速度、重力加速度、下落重力倍率三个参数没配合好。解决是参考经典平台跳跃参数跳跃初速-400上升重力980下落重力1960短跳倍率0.5。三次摔车记录之后模式识别发现都是CharacterBody2D移动相关。于是蒸馏成SOP“Godot 2D平台跳跃角色移动标准配置”。SOP内容如下触发条件在Godot 4.x中创建2D平台跳跃角色。前置检查确认项目使用Godot 4.x确认已创建CharacterBody2D节点。操作步骤节点结构CharacterBody2D → CollisionShape2D胶囊形 Sprite2D AnimationPlayer。碰撞层设置角色层为1环境层为2角色检测环境层。脚本模板使用以下参数作为起点——速度300跳跃初速-400上升重力980下落重力1960短跳倍率0.5floor_max_angle 45度floor_snap_length 8像素。移动逻辑放在_physics_process中使用move_and_slide。跳跃逻辑使用is_on_floor判断配合 coyote time 和 jump buffer。验证方法运行场景角色应能左右移动、跳跃、站在斜坡上不滑动、高速撞墙不穿透。异常处理如果角色穿墙检查移动速度是否过高尝试降低速度或增大碰撞体。如果斜坡滑动检查floor_max_angle和floor_snap_length。如果跳跃手感不对调整重力和跳跃初速的比值。关联SOP关联“Godot输入映射SOP”“Godot动画状态机SOP”。这条SOP写完之后我把它嵌入到“Godot开发MOC”里并在每日笔记的SOP回顾区块中定期出现。下次开新项目直接调出这条SOP五分钟配好角色移动把时间花在关卡设计上。4.3 AI工具在蒸馏流程中的角色定位现在AI工具很多Claude Code、Cursor、Codex、DeepSeek Harness还有各种skill插件和agent skill。我的定位很明确AI是蒸馏加速器不是替代品。具体怎么用三个场景。第一个场景是摔车记录的初步整理。我随手记的摔车笔记往往很乱语法不通、逻辑跳跃。我把原始笔记丢给AI让它帮我整理成结构化的四要素格式。AI整理完我再人工校对确保技术细节没被曲解。第二个场景是SOP的初稿生成。我把几条相关的摔车记录给AI让它提取共同模式生成SOP初稿。AI生成的初稿通常比较泛缺少具体参数和验证方法。我在此基础上补充实操细节把它变成可执行的SOP。第三个场景是SOP的交叉检查。我把自己写的SOP给AI让它扮演一个完全不懂的新手按SOP操作看哪里会卡住。AI会指出“这一步缺少前置条件”“这个参数没有说明取值范围”之类的问题。这比我自己反复读有效得多。但AI不能替代的是模式识别的判断。哪些问题值得蒸馏哪些不值得这个决策需要你对自身工作流的深刻理解。AI不知道你上周已经写过类似的SOP不知道你当前项目的优先级不知道你的认知负荷上限。这些只有你自己清楚。注意不要把AI生成的SOP直接当成最终版。AI倾向于生成“正确但无用”的泛泛之谈。真正的价值在于你补充的那些具体参数、踩坑经验和验证方法。AI是骨架你是血肉。4.4 微信小程序游戏开发和Godot的SOP差异微信小程序游戏开发和Godot游戏开发虽然都是游戏开发但SOP的侧重点完全不同。微信小程序游戏开发的SOP更偏向平台适配和性能约束。包体大小限制、内存限制、渲染批次限制这些是硬约束。SOP里必须包含“包体检查”“内存监控”“渲染批次优化”这些步骤。而且微信开发者工具本身的更新频率高SOP要跟着平台政策走。Godot的SOP更偏向引擎特性和工作流。节点结构、信号连接、资源管理、导出配置这些是核心。Godot版本升级时SOP需要检查API变更。我的做法是建两套独立的SOP体系共享底层的“游戏开发通用SOP”比如“游戏循环设计SOP”“输入处理SOP”但在平台特定层分开。这样既避免了重复又保证了针对性。5. 常见问题与排查技巧实录5.1 SOP写了不用怎么办这是最常见的问题。写了SOP但实际开发时还是靠本能和搜索。原因通常有三个SOP太多找不到、SOP太泛用不上、SOP过时不敢用。针对“找不到”我的解法是场景化索引。不按技术分类按“我正在做什么”分类。比如“开新项目”“做UI”“调性能”“修bug”每个场景下列出相关SOP。这样你不需要记住SOP名字只需要知道当前场景。针对“用不上”我的解法是SOP要具体到参数。不要写“配置好移动参数”要写“速度设为300跳跃初速-400”。具体的参数让SOP有可操作性你照着填就行不需要二次思考。针对“不敢用”我的解法是定期更新。每月过一遍核心SOP标记过期的更新变更的。过期的SOP直接归档不要留在活跃体系里。5.2 怎么判断一个skill值不值得蒸馏我的判断标准是“三次原则”同一个问题出现三次以上或者同一个操作执行三次以上就值得蒸馏。出现一两次的记在Reference里就行。另一个标准是“认知负荷”如果某个操作每次都要你停下来想“这个参数设多少来着”那就值得蒸馏。如果某个操作你已经肌肉记忆了闭着眼睛都能做那就不急。还有一个标准是“错误成本”如果做错了会导致严重后果比如数据丢失、项目崩溃那即使只出现一次也值得蒸馏。错误成本高的操作容错率低需要SOP来保证一致性。5.3 常见问题速查表问题现象可能原因排查步骤解决方案SOP写了但想不起来用索引不场景化检查MOC结构按使用场景重建索引SOP步骤执行后结果不对参数过时或环境变更对比SOP编写时的环境版本更新SOP参数标注适用版本摔车记录记了但从不回顾回顾机制缺失检查是否有定期回顾流程设置每周固定回顾时间用Dataview自动聚合AI生成的SOP太泛缺少具体参数和验证检查SOP是否包含可执行参数人工补充参数、验证方法、异常处理SOP体系越来越臃肿过度蒸馏统计SOP数量和实际使用频率归档低频SOP保持核心20条以内跨引擎SOP混淆没有分层检查SOP是否标注适用引擎建立通用层平台层双层结构5.4 独家避坑技巧第一个技巧SOP里一定要写“为什么”。不要只写“速度设为300”要写“速度设为300因为这是经过测试后手感最接近经典平台跳跃的值低于200会感觉迟钝高于400会难以控制”。知道为什么才能在特殊情况下灵活调整。第二个技巧给SOP打上“置信度”标签。有些SOP是经过多次验证的置信度高有些是初次编写置信度低。置信度低的SOP在使用时要多留个心眼用完后回来更新。第三个技巧SOP之间建立双向链接。比如“角色移动SOP”链接到“动画状态机SOP”反之亦然。这样你在执行一个SOP时能自然发现关联的SOP避免遗漏步骤。第四个技巧用AI做SOP的“红队测试”。把SOP给AI让它故意找茬哪里模糊、哪里缺少前置条件、哪里可能出错。AI找出的问题往往是你自己看不见的盲区。第五个技巧SOP要包含“回滚方案”。如果按SOP操作后结果不对怎么恢复到操作前的状态这个在涉及数据修改、配置变更的SOP里尤其重要。没有回滚方案的SOP执行起来心理压力大容易犹豫不决。6. 从laggards到体系化我的个人体会我到现在也不觉得自己是什么early adopter。新工具出来我还是会等一等看别人踩完坑再上车。但我不再焦虑了因为我有自己的蒸馏体系。新工具来了我不需要全盘接受只需要提取对我有用的部分蒸馏成skill嵌入现有SOP。体系在我就不慌。这套方法最大的收益不是效率提升——虽然效率确实提升了——而是心理安全感。以前每次遇到问题都觉得是新的、未知的、需要从零解决的。现在遇到问题第一反应是“这属于哪类问题有没有相关SOP”。有SOP就按SOP走没有就记录摔车攒够了再蒸馏。问题从“威胁”变成了“素材”。如果你也是laggards不用强迫自己变成early adopter。找到适合自己的吸收节奏用蒸馏代替追赶用SOP代替记忆用体系代替焦虑。摔车不可怕摔了记下来下次绕过去就是进步。 从摔车到SOP：游戏开发者的Skill蒸馏与知识管理实战
1. 从“摔车”到“SOP”一个laggards的自白先坦白一件事在chasm理论那套技术采用生命周期模型里我属于laggards那一群人。不是early adopter不是early majority甚至连late majority都算不上。新技术出来我通常是最后一个上车的。别人已经在用各种新工具跑通全流程了我还在用最笨的办法手动折腾。摔过车翻过沟踩过的坑能填满一个中型停车场。但恰恰是这种“摔车”经历逼着我琢磨出一套自己的skill蒸馏大法——把游戏开发中那些零散的、靠感觉的、每次都要重新想一遍的操作蒸馏成可复用的SOP。这套方法不依赖某个特定引擎Godot也好Unity也好甚至微信小程序游戏开发那套东西底层逻辑是通的。它解决的核心问题是如何把“我会做”变成“我知道我怎么做出来的并且下次能更快做出来”。这篇文章适合谁看如果你是刚入行的游戏开发新手被各种教程和工具链搞得头晕这篇能帮你建立一套自己的知识蒸馏框架。如果你是有几年经验的开发者但总觉得效率卡在某个瓶颈上做东西全靠肌肉记忆和临时搜索这篇能帮你把隐性经验显性化。如果你是对skill、SOP、知识管理这些概念感兴趣想看看一个laggards怎么用笨办法追上来的那更对味了。我不打算讲什么高深理论就讲我怎么从一次次摔车里把游戏开发这件事拆成能重复执行的步骤怎么用Obsidian搭知识体系怎么把AI工具当成蒸馏加速器而不是替代品。全程大白话能抄作业的地方直接给模板。2. 为什么我选择“蒸馏”而不是“堆料”2.1 chasm理论里的laggards到底在怕什么chasm理论讲的是技术产品从早期市场跨越到主流市场之间那道鸿沟。early adopter愿意为不成熟的东西买单因为他们要的是先发优势。early majority要的是完整方案late majority要的是标配laggards要的是——别让我改。我属于laggards核心恐惧就一条改变现有工作流的成本太高。新引擎出来我要重新学一套API新AI工具出来我要重新配环境、调参数、试错。每次切换都意味着我手头正在做的项目要停摆。所以我本能地抗拒“为了新而新”的东西。但游戏开发这个领域技术迭代速度又特别快。Unity3D一年一个大版本Godot从3.x到4.x几乎重写了一遍渲染管线微信小程序游戏开发那套东西更是跟着平台政策变。你不可能永远不动。laggards的生存策略不是拒绝变化而是等变化稳定下来之后用最低成本把变化吸收进自己的体系。蒸馏就是我的吸收方式。我不追新工具的全部功能我只提取对我当前工作流有增量价值的那部分把它蒸馏成一个skill嵌入我已有的SOP里。这样每次技术更新我的体系不会崩只是多了一个可调用的模块。2.2 skill蒸馏和普通记笔记的本质区别很多人记笔记是“堆料”看到一篇好文章收藏看到一个好工具截图看到一个好技巧复制粘贴。结果笔记库越来越大但真到用的时候还是靠搜索和记忆。这不是蒸馏这是仓库。蒸馏的核心动作是提纯和固化。提纯意味着去掉上下文依赖把“在某个特定项目里用某个特定版本引擎解决某个特定bug”这件事抽象成“当遇到某类问题时按什么顺序检查什么参数”。固化意味着把它写成一个可执行的步骤序列下次遇到同类问题不需要重新思考直接跑SOP。举个例子。我在Godot里做角色移动一开始每次都要重新想用CharacterBody2D还是RigidBody2Dmove_and_slide的参数怎么调重力怎么设碰撞层怎么配每次都要翻文档、搜教程、试错。后来我把它蒸馏成一个SOP“2D平台跳跃角色移动标准配置”里面固定了节点结构、脚本模板、参数默认值、常见问题排查清单。下次开新项目直接复制这个SOP五分钟搞定基础移动把时间留给关卡设计和手感调优。这就是蒸馏的价值把重复决策变成默认执行。你的大脑带宽是有限的省下来的认知资源才能投入到真正需要创造力的地方。2.3 为什么是“大法”而不是“方法”叫“大法”有点戏谑但也确实因为它不是单一技巧而是一套组合拳。我的skill蒸馏大法包含四个环节摔车记录、模式识别、SOP编写、体系嵌入。这四个环节循环迭代每摔一次车体系就厚一层。摔车记录是原始素材。每次遇到bug、每次卡住、每次发现一个更优解立刻记下来。不追求格式不追求完整先记下来再说。我用Obsidian的每日笔记功能随手记打标签。模式识别是定期回顾。每周或每两周翻一遍摔车记录看哪些问题是重复出现的哪些解决方案是可以泛化的。重复出现三次以上的问题就值得蒸馏成SOP。SOP编写是固化。把识别出的模式写成步骤清单包含触发条件、操作步骤、预期结果、异常处理。写的时候要假设读者是三个月后的自己——已经忘了当时上下文只能靠这份SOP复现。体系嵌入是最后一步。把新SOP挂到已有的知识体系里建立索引和关联。下次遇到相关场景能通过标签或链接快速找到。这四个环节里最容易被忽略的是模式识别。很多人记了笔记就完了从来不回顾。结果笔记是死的体系是空的。我强迫自己每周花半小时做这件事收益远超投入。3. 核心细节skill蒸馏的四个关键操作3.1 摔车记录怎么记才能让未来的自己看懂摔车记录最大的坑是“记了等于没记”。当时觉得“这个bug我知道怎么回事了”随手写一句“碰撞检测有问题已解决”。三个月后翻到这条完全想不起来是什么碰撞检测、什么问题、怎么解决的。我的做法是强制自己写四要素现象、环境、排查过程、最终解。现象要具体到能复现环境要精确到引擎版本和插件版本排查过程要记录试过哪些方向、哪些排除了最终解要写清楚改了哪个文件哪一行。比如有一次在Unity里做技能指示器skill attack indicators角色释放范围技能时指示器显示的范围和实际伤害范围对不上。我的记录是这样的现象技能指示器显示半径3米实际伤害判定半径约2.5米边缘敌人不受伤害。 环境Unity 2022.3.10f1URP使用Decal Projector做地面指示器。 排查先检查Decal Projector的size参数确认是3。再检查伤害判定代码发现用的是OverlapSphere半径参数写的是2.5。但为什么视觉和逻辑不一致继续查发现Decal Projector的size是直径不是半径我设了3实际半径是1.5。但视觉上看起来像3米半径是因为Decal的缩放和相机透视有偏差。 最终解统一用半径参数驱动两者。Decal Projector的size设为半径×2OverlapSphere半径设为同一个变量。在Inspector里暴露一个radius字段两边都读这个值。这条记录后来被我蒸馏成了“技能指示器视觉与逻辑一致性检查SOP”包含三个检查点参数单位是否统一、视觉表现是否受相机影响、逻辑判定是否用了同一数据源。提示摔车记录不要追求文采追求可检索性。关键词、版本号、文件路径这些才是未来能救你的东西。3.2 模式识别怎么从一堆碎碎念里找到值得蒸馏的skill摔车记录攒到几十条之后就需要做模式识别。我的方法是用Obsidian的标签系统做粗筛再用Dataview插件做聚合。给每条记录打上领域标签比如#godot、#unity、#ui、#性能、#ai工具。每周回顾时用Dataview查询某个标签下的所有记录看重复模式。重复模式有三种典型形态第一种是同类问题反复出现。比如“Godot里信号连接忘记断开导致内存泄漏”出现了五次那就值得写一个SOP“Godot信号连接与断开标准流程”。第二种是同类操作反复执行。比如每次开新项目都要配一遍输入映射、音频总线、场景切换管理器。那就蒸馏成“Godot新项目初始化SOP”。第三种是同类决策反复纠结。比如“这个功能用信号还是直接调用”“这个数据放资源里还是放脚本里”。那就蒸馏成“Godot架构决策速查表”列出常见场景的推荐方案和理由。模式识别的关键是不要过度蒸馏。只出现一两次的问题记着就行不值得写成SOP。SOP太多会变成负担你根本记不住有哪些SOP更别说用了。我的经验是保持核心SOP在20条以内覆盖80%的重复场景。其他的作为“参考笔记”存在不纳入SOP体系。3.3 SOP编写让步骤可执行、可验证、可迭代SOP不是文档是操作手册。我写SOP遵循一个模板包含六个部分触发条件什么情况下用这个SOP。写得越具体越好比如“当需要在Godot中创建一个可交互的2D角色时”而不是“做角色的时候”。前置检查执行前需要确认什么。比如“确认项目已安装Godot 4.x确认已创建2D场景”。操作步骤编号列表每步一个动作。动作要具体到“点击哪个菜单”“输入什么值”“保存为什么文件名”。避免“配置好参数”这种模糊表述。验证方法怎么确认操作成功了。比如“运行场景按方向键角色应移动松开应停止”。异常处理常见错误和解决方法。比如“如果角色不移动检查Input Map是否配置了move_left/move_right”。关联SOP这个SOP和其他哪些SOP有关联。比如“角色移动SOP关联到动画状态机SOP和碰撞层配置SOP”。这个模板的好处是它强迫你把隐性知识显性化。很多老手觉得“这还用写”的东西恰恰是新手最需要的。而且写的过程本身就是在检验你的理解是否完整——如果你写不出验证方法说明你其实没完全搞懂。注意SOP要定期更新。引擎版本升级、API变更、发现更优方案都要回头改SOP。我每个月会抽时间过一遍核心SOP确保它们和当前实践一致。过期的SOP比没有SOP更危险。3.4 体系嵌入让SOP在需要的时候自动浮现SOP写完了放在文件夹里下次遇到场景想不起来用等于白写。所以最后一步是体系嵌入让SOP在正确的时机自动出现在你面前。我的做法是用Obsidian的MOCMap of Content结构。建几个顶层MOC比如“游戏开发MOC”“AI工具MOC”“知识管理MOC”。每个MOC下面链接相关的SOP和笔记。然后利用Obsidian的模板功能在每日笔记里自动插入当天的“SOP回顾”区块随机推荐一条SOP。这样每天花一分钟扫一眼保持对SOP体系的熟悉度。另一个技巧是场景化索引。不按技术分类按使用场景分类。比如“开新项目时看哪些SOP”“做UI时看哪些SOP”“性能优化时看哪些SOP”。这样你不需要记住SOP的名字只需要知道当前在做什么场景就能找到对应的SOP集合。我还把核心SOP导出成PDF放在手机里通勤时翻一翻。听起来很土但有效。很多SOP你写的时候觉得理所当然过段时间就忘了细节。定期重温才能保持肌肉记忆。4. 实操过程从零搭建一套游戏开发SOP体系4.1 环境准备Obsidian配置和插件选型工欲善其事必先利其器。我用Obsidian作为SOP体系的载体原因有三本地存储、双向链接、插件生态。本地存储意味着数据完全在我手里不怕服务停运。双向链接让SOP之间的关联自然生长。插件生态提供了Dataview、Templater、QuickAdd这些自动化工具。核心插件清单插件名用途必装理由Dataview查询和聚合笔记自动生成SOP索引和回顾列表Templater模板自动化新建SOP时自动填充模板结构QuickAdd快速捕获一键记录摔车笔记不打断心流Tag Wrangler标签管理批量重命名和合并标签Calendar日记导航快速跳转到某天的摔车记录配置上我建了四个文件夹00-Inbox放临时笔记10-SOP放正式SOP20-Reference放参考笔记30-MOC放索引。Inbox里的笔记每周清理一次有价值的蒸馏成SOP或Reference没价值的删掉。Templater模板我设了两个一个用于摔车记录一个用于SOP。摔车记录模板包含日期、现象、环境、排查、解决五个字段。SOP模板包含触发条件、前置检查、操作步骤、验证方法、异常处理、关联SOP六个字段。提示不要一开始就追求完美体系。先跑起来用着用着再调整。我第一版Obsidian库只有三个文件夹后来才慢慢细化。体系是长出来的不是设计出来的。4.2 从摔车到SOP的完整案例Godot角色移动拿一个具体案例走一遍全流程。假设我在Godot里做2D平台跳跃角色移动一直调不好摔了几次车。第一次摔车角色移动时穿墙。记录现象是角色在高速移动时穿过碰撞体环境是Godot 4.2CharacterBody2Dmove_and_slide。排查发现是移动速度太快物理帧间隔内位移超过了碰撞体厚度。解决是把移动逻辑放到_physics_process里并开启move_and_slide的safe_margin。第二次摔车角色在斜坡上滑动。记录现象是角色站在斜坡上会缓慢下滑环境同上。排查发现是重力应用方式不对在斜坡上重力分量导致滑动。解决是设置floor_max_angle并调整floor_snap_length。第三次摔车角色跳跃手感不对。记录现象是跳跃感觉“飘”不够干脆。排查发现是跳跃速度、重力加速度、下落重力倍率三个参数没配合好。解决是参考经典平台跳跃参数跳跃初速-400上升重力980下落重力1960短跳倍率0.5。三次摔车记录之后模式识别发现都是CharacterBody2D移动相关。于是蒸馏成SOP“Godot 2D平台跳跃角色移动标准配置”。SOP内容如下触发条件在Godot 4.x中创建2D平台跳跃角色。前置检查确认项目使用Godot 4.x确认已创建CharacterBody2D节点。操作步骤节点结构CharacterBody2D → CollisionShape2D胶囊形 Sprite2D AnimationPlayer。碰撞层设置角色层为1环境层为2角色检测环境层。脚本模板使用以下参数作为起点——速度300跳跃初速-400上升重力980下落重力1960短跳倍率0.5floor_max_angle 45度floor_snap_length 8像素。移动逻辑放在_physics_process中使用move_and_slide。跳跃逻辑使用is_on_floor判断配合 coyote time 和 jump buffer。验证方法运行场景角色应能左右移动、跳跃、站在斜坡上不滑动、高速撞墙不穿透。异常处理如果角色穿墙检查移动速度是否过高尝试降低速度或增大碰撞体。如果斜坡滑动检查floor_max_angle和floor_snap_length。如果跳跃手感不对调整重力和跳跃初速的比值。关联SOP关联“Godot输入映射SOP”“Godot动画状态机SOP”。这条SOP写完之后我把它嵌入到“Godot开发MOC”里并在每日笔记的SOP回顾区块中定期出现。下次开新项目直接调出这条SOP五分钟配好角色移动把时间花在关卡设计上。4.3 AI工具在蒸馏流程中的角色定位现在AI工具很多Claude Code、Cursor、Codex、DeepSeek Harness还有各种skill插件和agent skill。我的定位很明确AI是蒸馏加速器不是替代品。具体怎么用三个场景。第一个场景是摔车记录的初步整理。我随手记的摔车笔记往往很乱语法不通、逻辑跳跃。我把原始笔记丢给AI让它帮我整理成结构化的四要素格式。AI整理完我再人工校对确保技术细节没被曲解。第二个场景是SOP的初稿生成。我把几条相关的摔车记录给AI让它提取共同模式生成SOP初稿。AI生成的初稿通常比较泛缺少具体参数和验证方法。我在此基础上补充实操细节把它变成可执行的SOP。第三个场景是SOP的交叉检查。我把自己写的SOP给AI让它扮演一个完全不懂的新手按SOP操作看哪里会卡住。AI会指出“这一步缺少前置条件”“这个参数没有说明取值范围”之类的问题。这比我自己反复读有效得多。但AI不能替代的是模式识别的判断。哪些问题值得蒸馏哪些不值得这个决策需要你对自身工作流的深刻理解。AI不知道你上周已经写过类似的SOP不知道你当前项目的优先级不知道你的认知负荷上限。这些只有你自己清楚。注意不要把AI生成的SOP直接当成最终版。AI倾向于生成“正确但无用”的泛泛之谈。真正的价值在于你补充的那些具体参数、踩坑经验和验证方法。AI是骨架你是血肉。4.4 微信小程序游戏开发和Godot的SOP差异微信小程序游戏开发和Godot游戏开发虽然都是游戏开发但SOP的侧重点完全不同。微信小程序游戏开发的SOP更偏向平台适配和性能约束。包体大小限制、内存限制、渲染批次限制这些是硬约束。SOP里必须包含“包体检查”“内存监控”“渲染批次优化”这些步骤。而且微信开发者工具本身的更新频率高SOP要跟着平台政策走。Godot的SOP更偏向引擎特性和工作流。节点结构、信号连接、资源管理、导出配置这些是核心。Godot版本升级时SOP需要检查API变更。我的做法是建两套独立的SOP体系共享底层的“游戏开发通用SOP”比如“游戏循环设计SOP”“输入处理SOP”但在平台特定层分开。这样既避免了重复又保证了针对性。5. 常见问题与排查技巧实录5.1 SOP写了不用怎么办这是最常见的问题。写了SOP但实际开发时还是靠本能和搜索。原因通常有三个SOP太多找不到、SOP太泛用不上、SOP过时不敢用。针对“找不到”我的解法是场景化索引。不按技术分类按“我正在做什么”分类。比如“开新项目”“做UI”“调性能”“修bug”每个场景下列出相关SOP。这样你不需要记住SOP名字只需要知道当前场景。针对“用不上”我的解法是SOP要具体到参数。不要写“配置好移动参数”要写“速度设为300跳跃初速-400”。具体的参数让SOP有可操作性你照着填就行不需要二次思考。针对“不敢用”我的解法是定期更新。每月过一遍核心SOP标记过期的更新变更的。过期的SOP直接归档不要留在活跃体系里。5.2 怎么判断一个skill值不值得蒸馏我的判断标准是“三次原则”同一个问题出现三次以上或者同一个操作执行三次以上就值得蒸馏。出现一两次的记在Reference里就行。另一个标准是“认知负荷”如果某个操作每次都要你停下来想“这个参数设多少来着”那就值得蒸馏。如果某个操作你已经肌肉记忆了闭着眼睛都能做那就不急。还有一个标准是“错误成本”如果做错了会导致严重后果比如数据丢失、项目崩溃那即使只出现一次也值得蒸馏。错误成本高的操作容错率低需要SOP来保证一致性。5.3 常见问题速查表问题现象可能原因排查步骤解决方案SOP写了但想不起来用索引不场景化检查MOC结构按使用场景重建索引SOP步骤执行后结果不对参数过时或环境变更对比SOP编写时的环境版本更新SOP参数标注适用版本摔车记录记了但从不回顾回顾机制缺失检查是否有定期回顾流程设置每周固定回顾时间用Dataview自动聚合AI生成的SOP太泛缺少具体参数和验证检查SOP是否包含可执行参数人工补充参数、验证方法、异常处理SOP体系越来越臃肿过度蒸馏统计SOP数量和实际使用频率归档低频SOP保持核心20条以内跨引擎SOP混淆没有分层检查SOP是否标注适用引擎建立通用层平台层双层结构5.4 独家避坑技巧第一个技巧SOP里一定要写“为什么”。不要只写“速度设为300”要写“速度设为300因为这是经过测试后手感最接近经典平台跳跃的值低于200会感觉迟钝高于400会难以控制”。知道为什么才能在特殊情况下灵活调整。第二个技巧给SOP打上“置信度”标签。有些SOP是经过多次验证的置信度高有些是初次编写置信度低。置信度低的SOP在使用时要多留个心眼用完后回来更新。第三个技巧SOP之间建立双向链接。比如“角色移动SOP”链接到“动画状态机SOP”反之亦然。这样你在执行一个SOP时能自然发现关联的SOP避免遗漏步骤。第四个技巧用AI做SOP的“红队测试”。把SOP给AI让它故意找茬哪里模糊、哪里缺少前置条件、哪里可能出错。AI找出的问题往往是你自己看不见的盲区。第五个技巧SOP要包含“回滚方案”。如果按SOP操作后结果不对怎么恢复到操作前的状态这个在涉及数据修改、配置变更的SOP里尤其重要。没有回滚方案的SOP执行起来心理压力大容易犹豫不决。6. 从laggards到体系化我的个人体会我到现在也不觉得自己是什么early adopter。新工具出来我还是会等一等看别人踩完坑再上车。但我不再焦虑了因为我有自己的蒸馏体系。新工具来了我不需要全盘接受只需要提取对我有用的部分蒸馏成skill嵌入现有SOP。体系在我就不慌。这套方法最大的收益不是效率提升——虽然效率确实提升了——而是心理安全感。以前每次遇到问题都觉得是新的、未知的、需要从零解决的。现在遇到问题第一反应是“这属于哪类问题有没有相关SOP”。有SOP就按SOP走没有就记录摔车攒够了再蒸馏。问题从“威胁”变成了“素材”。如果你也是laggards不用强迫自己变成early adopter。找到适合自己的吸收节奏用蒸馏代替追赶用SOP代替记忆用体系代替焦虑。摔车不可怕摔了记下来下次绕过去就是进步。