周末花两天时间，一位开发者用AI生成了Go语言的序列化代码。结果跑分出来，102纳秒/操作，比Protobuf快5倍，比JSON快27倍。这数字放在性能敏感的场景里，相当于把马车换成了高铁。
但故事的开头没那么光鲜。作者最初只是想偷懒——有个叫mok的库缺代码生成器，每次mock接口都要手写一堆样板代码。这种活交给AI agent，给个小例子就能干得很漂亮。这让他冒出一个更大胆的想法：如果AI能写序列化代码，岂不是既能保留生成代码的裸速，又能享受反射库的简洁？
序列化是AI的雷区，非确定性输出可能埋坑。作者给自己划了两条硬红线：生成代码必须能通过编译，且100%通过测试。满足这两条，才敢把AI产出的代码签入仓库。
从"能跑"到"敢用"：两条红线卡住AI幻觉
作者花了几晚捣鼓出mus-skill，本质上是套规则——把mus和mus-stream库提供的序列化原语按固定模式拼装。不光出代码，还连带生成测试文件。生成结果看起来和传统代码生成器没区别，性能自然也对标。
Benchmark数据很直白：mus 102.90纳秒/操作，Protobuf 531.70纳秒，JSON直接冲到2779纳秒。内存分配次数分别是1次、4次、9次。完整测试数据挂在GitHub上，作者没藏着掖着。
这套玩法甚至能啃动深层嵌套的复杂类型——AI通常在这里 hallucinate（幻觉）的重灾区。比如这种让人头皮发麻的结构：
// mus:vl = ValidateLen
// mus:elemVl = ValidateComplexMapValue
type ComplexMap map[string]map[*[]int][][]float32
作者还留了后门：用户可以通过注释加hint，自定义验证器之类的行为。想要就用，不想折腾也能开箱。
安装比写Dockerfile还简单，但最后一句话很诚实
上手路径两条：要么clone到项目的agent目录（比如.agents/skills），要么用CLI工具一键装：
npx skills add github.com/mus-format/mus-skill-go
装完给AI agent扔一句："给.go里的类型生成MUS序列化代码。"产出两个文件：mus.ai.gen.go和mus.ai.gen_test.go。
作者补了一句大实话：务必检查生成的测试是否覆盖了所有边界情况。翻译过来就是——AI写的测试可能漏边边角角，别全信。
性能数字背后，是Go序列化江湖的暗战
mus这个库本身走的就是"手工优化代码生成"路线，和Protobuf的通用编码器、JSON的反射解析不在一个赛道。AI在这里扮演的角色，其实是把"人写生成规则"换成了"AI按规则拼装"。
关键点在于规则足够死板、输出足够可预测。作者没让AI自由发挥设计序列化格式，而是限定在mus的原语框架内——这就像给厨师规定了切菜手法和火候档位，而不是让他自创菜系。
这种"受限的AI"思路，可能是现阶段更务实的玩法。完全开放的AI生成代码，在序列化这种对正确性零容忍的场景里，风险收益比太难看。
项目已经开源，GitHub仓库挂着完整的benchmark和用法。作者最后抛了个问题：你会把AI生成的核心代码直接上生产吗，还是先关进测试笼子里跑几个月？
热门跟贴