26上半年流水账

1~3月

年初在杨老师的东汉书院历经了两个月，学习了他的Nanite课程。学习自觉还是蛮认真的，跟着他的讲课，一行一行地把代码打出来。但学完之后就空落落的，只是知道他课程讲了一些代码，而且这些代码距离真正的Nanite工程落地还有很多缺失，例如没有软光栅处理小三角形，没有page loader实现真正的虚拟几何体，也没有之前课上提到要讲的关于针对低级API的适配的内容。问了一下他，他给了一些代码，但我也没去看。然后我打开虚幻的源码，还是一面懵逼，关联不到课上代码。

我寻思是不是我对图形API不熟悉，基础不好？于是我又开始看DX12的龙书，为每章节写读书笔记。这时（3月份）公司已经开始连续单休加班。学习的时间并不多，我把龙书从第四章推到第十章。

4~6月

这时公司内部开始推广AI编程。我写笔记下来，也觉得从飞书复制粘贴到博客园效率很低，于是就试了试让Trae写个博客发布工具。当时刚刚了解到什么SDD，Spec。也是在B站看到一个潮汕大专生不同代码却通过AI开发出一个班级管理网页软件，在小学班主任中卖爆，财富自由的小故事。印象最深刻的是他说他不知道如何编程，就是口述给AI，让一个AI写代码另一个AI检查。一开始我还小心翼翼地用Trae，参考他的方式，让Trae中的所有模型（mm27、glm5.1、kimi2.6、qwen3.5）根据我的需求“将飞书文档发布到博客园”，各自出一份spec，我还煞有介事看了所有spec。各个模型给出的都是云端方案，弄了一段时间，最后我让glm5.1开始编程。代码很快就生成出来，但配置老是不行，先是给出的云服务商是海外，需要**才能申请账号。账号好了token有不对，token有了又到海外云服务商连通不了国内飞书，转国内云服务商，又发现没有免费（其实海外应该也不是免费）。最后一拍大腿，TMD，出的啥方案，谁说要云端了，我本地把飞书文档内容（主要是图片）下载下来再提交博客园不就完了吗。（AI大模型：那不是你需求不清晰嘛~~~）然后按这个方案，代码很快生成。提交上去的代码有些bug，markdown解析不正确，我让AI自己看看自己解析飞书文档的结果，与cloud document converter的对比一下，AI很快就修复。我也没写过一行代码，甚至没看过代码，工具就成了。于是我把DX12龙书的第十一章内容通过这个工具发布到博客园。

接下来就是工具顺畅了，就是博文大爆发了吗？噢不，反而是停滞了，现在龙书第十二章还停留在第一节。加班，特别是赶二测版本，已经占去大部分时间。剩余的时间和精力，都被AI吸引走。这段时间试过搭建Comfy UI，我是AMD显卡，也是几经波折，搭好了环境，但生成出来的图距离想象中差太远有点失望，估计是需要进一步调整，配置更多模型，估计也得等后续有时间再继续研究。

7~8月

更多的精力和时间，投入到AI编程。我希望将UE的功能，移植到Godot，通过这样，来体现自己对UE的精通。以便在游戏上线后，能找到更好的工作。

2D小游戏

第一个项目，是模仿lines of battle做一个2d的游戏，于是兴冲冲开干。先让AI参考游戏出个策划案，列出游戏流程；策划案有各种配置，好的，弄个配置表系统吧，让AI开发godot插件做导出工具将xlsx生成为pb文件；接着业务逻辑，嗯，搞ECS，lua做可热更逻辑，让AI编码。输出了一些代码，嗯，但想了想，其实我不想在做战斗，做业务逻辑了。还是搞点别的吧。

Godot Insight

好的，第二个项目，我想做做性能方向的工作。Godot的性能检查工具好像不咋地，把UE的Insight移植过去。这个主意不错，开干，Trae你用GLM5.1给我出个调研方案。哦，Godot主要是用Tracy哦，这是个外部工具，用起来不方便。不如把Tracy整合进Godot，并且把Godot缺的桩给补上。好，就按这个做。这个项目工作量比较大，Trae和GLM5.1给出的方案非常不错，有个实施路径，把工作划分为6个phase。就按照这个计划一步一步实现。先第一个phase，让Trae生成spec文档，略微过了一下，行了，开干。很快完成，tasks和checklist全部打钩。spec文档归档，下一个phase，启动，归档下一个phase启动....等等，都没啥效果可以看，嗯，phase加入单元测试。phase4，有编辑器界面了，可以看到内容，编译看看，哦，确实有个界面，但还没有数据，要等下一个phase。好，下一个phase，启动。这数据不太对啊。先把后续剩余的两个phase跑完吧。 ......这insight编辑器界面不太对啊，要跟着色编辑器一样的，嗯，phase7。呃，为何有个自制gitray文件，不是读tracy文件吗？啊，搞错需求了，为了方便读取自己能了个文件格式，要转换才能转换出tracy！不是，我要的是把Tracy整合进Godot，Trae你给我重新出个方案，把Tracy的源码拉过来塞到Godot里面，把实时录制性能数据做了，phase8。但展示出来的数据，就是一竖，或者一个条子，不是火焰图啊！我试试原装的Tracy录制的数据是怎样的，是正确的火焰图啊。那实现读取tracy文件在之前的编辑器把火焰图展示出来，phase9。呃，读取原装tracy文件，图还是奇奇怪怪，不是正常的火焰图。累了，毁灭吧...

Godot Nanite

开新坑！第三个项目，把nanite移植到Godot。回到年初的课程，不过年初课程内容基本上忘干净了，毕竟学习只是照课程机械输入代码，还没来得及巩固。还是开干吧。

我先让Trae使用GLM5.2查看Godot的渲染管线，调研了nanite的实现方案。根据Godot的插件开发方式，得出一个初步的设计方案。Godot nanite有三种模式，当处于插件模式，它通过Composite Effect方式接入编译好的引擎，这样它可以独立分发；当处于C++ Module模式，它的shadow渲染时也可以使用nanite，而不用像插件模式那样只能使用粗lod作为shadow mesh，虽然它需要编译引擎，但所有代码都集中在module内部，不需要修改引擎，还是便于集成的；最后是引擎核心模式，它嵌入到Godot的渲染管线，需要修改引擎代码，但能把Godot的所有功能（shadow/ssao/...）都用上。三种模式共用一套核心代码，nanite实现是一条独立渲染管线；三种模式通过桥接层实现。这样设计，除了现在的三种模式，以后我想在ai的辅助下重写Godot的渲染管线，实现类似unity的srp的方式。具体而言，是多年之前紫龙的总监在UWA Day上分享的BlackJack Render Pipeline。这样可以把nanite的渲染再拆成一个或过多个节点，放到渲染管线图中进行连线。

有了这个初步的构想，Trae，启动，给我做一个总体设计。首先第一步是从mesh中生成nanite mesh，然后是三个阶段，共四个spec。很快，我开始spec推进。阶段0，离线导出nanite数据，很快完成。我已经在spec明示要加强单元测试，spec最终也给所有项目打钩了。但又出现问题了，这个阶段没有东西可以看，虽然有个预览窗口，但渲染方法起码要等下一个phase。好吧，开始phase1。完成了，但没有预览结果可以看。这个时候就有点混乱了，不知道是数据不对，还是渲染不对。向Trae查问了一下，它说之前多次对话，修改了phase1的spec文档，phase1只跑通渲染管线，真正的渲染延后到phase2了。God, damn it，真实渲染要在phase1实现，改过来。Trae：好了，但没有没有地方挂接这条nanite渲染管线，有几个方案，吧啦吧啦。我再想了一下，发现阶段0就没做好，预览器不能显示nanite，但应该以普通mesh的方式显示nanite mesh并且能画出它的cluster。退回上一个阶段把这块补一下，先确定nanite数据的正确性吧。回到phase0开始补上这个nanite cluster预览。发现只要细查，bug不是一般多啊，先是AI给出的模型简化，并不是根据cluster-partition的局部简化，而是对整个模型整体进行简化，呃；接着是高阶lod会出现断裂的，拓扑不联通的cluster；后续是如何选cluster合并成partition。这些问题都是靠我给预览器下新的需求，然后发现的，可能有更多没想到的bug根本没有发现。最终，阶段0算是完成。再次开启阶段1，这次mesh能渲染出来，但显示效果是比较诡异：nanite mesh盖住其他不透明mesh；mesh会随摄像机移动而转动和缩放；mesh会透视出天空盒，编辑器网格。就随摄像机移动而转动缩放的问题，我试了好几次对话，无法修复。当前的想法，还是需要人去看代码。所以又回到年初的课程，先把nanite的绘制流程搞到非常通透，再去看看当前AI生成的代码有什么问题。

总结

• AI做vibe coding，完全不看代码，是可行的。但还是要给出稍微具体的技术方案（如只是一个本地工具，还是使用云服务器的BS架构），一句话直出代码是不可能的。要通过技术方案等加一些约束。这是某种harness？

• 我在工作中也有用AI生成代码，但用法是制定在某个文件中加某些代码，调用那个类的那个参数，生成什么类/结构体。都是已经在大脑中做好设计，AI只是最后一公里把代码写出来，顺带把指针判空什么的都做好。即使不那么具体，也是给出具体的类，调用逻辑，让AI给一个设计方案我看看，再去生成代码。代码生成后，我还是需要看着代码心里跑一遍，以确认这个设计达成我想要的目标。这样操作，生成的代码都是基本OK的。
  工作中要求我们不能vibe coding，要对代码负责。对比起我在godot做的那三个项目。我感觉也是更有可控感。生成的代码不会出乱子。

• 我自己总结下来，游戏逻辑开发，还有渲染，它比较复杂，不像之前的博文发布器，能一句话说清楚。这种情况下，不能vibe coding，还是需要人参与。两种方式让AI加入：

  • 已经有框架，负责检查的人也非常熟悉，这样人可以设计好AI的代码写在哪里，然后让AI具体输出。输出完成后人再去逐行代码去看，逻辑是否正确。

  • 从零开始，没有框架，那就得AI先把框架代码输出，然后人去了解这个框架，人熟悉了，框架验证通过了。再去做下一步的细化，让AI再去生成。就是：AI生成--人理解代码--验证代码这样小步迭代进行。切忌让AI一下子生成大段代码，这样超越人脑理解能力宕机就无法保证开发最终能达到目标了

  上述两个方法都有违让AI执行长程任务，挣脱人力限制束缚，提升效率的方向。但个人觉得稳比快更重要。或许后续我会找到更好的方式？