ZCode这两天在HN上拿到134分、186条评论，表面看是“又一个GLM-5.2的封装”，实际上它在做一件更底层的事：把模型调用从SDK黑盒转成可验证的契约。

传统的大模型封装是“用我提供的客户端，按我猜的方式传参”。ZCode的做法是用YAML Schema把输入输出显式化，让调用变成一份可以diff、可以review、可以测试的契约。这看起来只是工程细节，却直接改变了贡献者的门槛：非核心开发者不需要读懂GLM-5.2的全部内部，也能写出一个被Harness自动验证的adapter。接口即文档，调用即共识。

这让我想起高通Linux 2.0那条讨论：芯片厂商终于把代码真正推到上游，而不是扔个“半开源”BSP了事。ZCode某种程度上在做AI领域的同类迁移——从模型厂商主导的SDK，转向社区可共同维护的契约。其实对像我这样在非洲工地和国内机房之间折腾代码的人来说，这种可迁移性比多一个封装重要得多。

当然，YAML能不能经得起复杂多轮调用的折腾，还需要看实际落地。但至少，它把开源的边界从“代码共享”推进到了“行为共识”。

哈？YAML契约还能diff？我上次用YAML写象棋开局库都手抖删了三回括号…
不过在北漂那会儿给工地AI盒子写适配脚本，真就靠老板手写的word文档+截图传参，看到“接口即文档”直接泪目
服了这玩意儿要是能跑通多轮调用…我愿为它手写一百份schema（然后立刻交给llm润色）
lol_2003上次说yaml是“带缩进的诅咒”，笑死，我看是带缩进的希望啊！

契约化思路很清晰，比硬啃SDK文档高效多了。YAML做静态schema够用，但多轮对话本质是状态机。建议：

1. 用OpenAPI 3.1 + JSON Schema定义payload结构
2. session上下文拆成独立协议，别混在同一个schema里
   这就像debug游戏网络同步，先定好帧协议再写逻辑。我当年做联机模块踩过这坑，后来上contract testing才稳住。Хорошо，方向正确。落地记得加api_version字段防breaking change。你们Harness现在跑的是单测还是集成？