244 个像素特效，没有一张图片文件：pixelfx 把美术做成代码，agent 也能接着写

10 月 30 日上线的 pixelfx，两天内冲上 GitHub 趋势：一天内先过 1100 星，11 月 1 日第三方盘点读到 1.7k 星、日增 1243。作者 Patch 把它定位得很清楚：244 个像素风游戏特效，每一个都是一小段代码，不是图片文件。火焰、爆炸、闪电、天气、魔法、受击火花、拾取、界面转场，全是运行时算出来的；换一套配色 ramp，整批特效跟着换色；导出能给 Phaser、Godot、Unity 做 sprite sheet。MIT 协议，装法也直接：npm i github:patch-gg/pixelfx。

它真正对 vibe-coding 友好的地方，是附带的 Claude Code 技能：/plugin marketplace add patch-gg/pixelfx 装上后，模型能按同一套风格接着写新特效，走“渲染—检查—打磨”的循环，还能出 contact sheet、指出接缝和随机性不一致的问题。这个思路两天前刚有人写成方法：Sprite Fusion 的作者 Hugo Duprez 10 月 28 日发文说，图片精灵太 rigid，代码更适合做像素特效——pixelfx 就是把这篇方法做成了一个现成库。一个小细节能看出它长得有多快：仓库描述还写着 232 个，README 已经数到 244 个，两处数字对不上不是错误，是更新速度超过了描述。

我的判断：独立游戏或小团队先别整库接入，先挑一个你游戏里最常用、现在最丑的特效替换掉——比如受击火花或爆炸——跑在真机或目标帧率下看一眼，再决定要不要扩到一整套。代码生成的特效省的是美术量产时间，不是美术判断：配色、节奏、打击感还是得人来定，agent 写出来的第一版只当草稿。反过来，如果你的游戏美术方向就是手绘质感、每一帧都要手工修，那程序化特效自带的那股“算出来的味道”反而会拖后腿，别硬套。

什么情况下这篇结论不成立：你的引擎管线不吃 sprite sheet 导出，或者项目根本不是像素风，那这 244 个特效再多也与你无关；另外，README 数与描述数不一致提醒了一件事：用之前先以你装到的版本实测为准，别抄文章里的数字当规格。