一行YAML毁掉14个AI技能，Anthropic工程师用200

一个缺失的name字段，让14个Claude技能集体"隐身"一周。用户以为是AI变笨了，其实是配置文件在搞鬼。这种静默失败在YAML世界里太常见——文件还在，逻辑全丢。

这是Anthropic工程师Michael在维护团队共享技能库时的真实遭遇。他们40多个Claude Code技能文件，有人改了一处多行描述的缩进，代码审查时diff看起来人畜无害，结果上线后14个技能直接失效。git blame找到元凶只用了几秒，排查却花了两小时。

他后来做了个叫pulser的工具，专门给Claude技能文件做体检。本地跑一遍不到200毫秒，CI集成后第一周就拦下23个问题——全是那种"能合并、能部署、就是不能用"的隐形bug。

Claude技能的"薛定谔"困境

Claude Code的技能系统设计上很简洁：Markdown文件+YAML前置元数据。但简单结构遇上静默失败，就成了运维噩梦。

name字段缺失=技能不存在。Claude直接跳过加载，没有报错，没有日志，就像那个文件从未提交过。用户只会觉得"Claude怎么突然不会这个了"。

description写得模糊=技能永不被触发。如果你写"useful for various tasks"，Claude接收到的信号噪声比太高，根本不知道什么场景该调用。技能文件躺在仓库里吃灰，用户却以为功能被砍了。

YAML语法错误=前置元数据蒸发。少一个闭合的`---`、用了tab而非空格、值里冒号没加引号——整个YAML块被解析器丢弃，技能正文变成普通Markdown，Claude完全看不到指令。

Michael的团队当时就是第三种情况。多行描述里的换行符处理不当，YAML解析失败，连锁反应波及14个文件。最讽刺的是，这些问题在代码审查阶段完全不可见——人类看diff觉得没问题，机器执行时却炸了。

pulser eval的 five-check 机制

pulser的核心是一个零依赖的CLI，针对Claude技能文件的特性做了五层检查。设计上追求"快"和"准"：40多个技能文件，200毫秒内出结果，返回码直接给CI用。

第一层是YAML解析器。不是通用的那种，而是专门处理Claude技能文件的边界情况——多行字符串、特殊字符转义、缩进一致性。能定位到具体哪一行哪个字符导致解析失败。

第二层校验必填字段。name和description必须存在且非空，这个规则写死，没有"可选"的灰色地带。

第三层最有意思：description质量评分。Michael发现很多技能失效不是因为语法，而是因为描述太泛。系统会标记像"helps with tasks"这种对Claude毫无信息量的描述，提示重写。

第四层检查文件结构。空技能体、命名规范违规、孤儿文件（有引用无定义）都在扫描范围内。

第五层做交叉引用验证。技能之间可以互相调用，pulsar会检查这些引用是否指向真实存在的文件。

从"肉眼审查"到"自动拦截"的迁移成本

团队原来的工作流是：提交PR→人工看diff→合并→祈祷。现在变成：本地pulser eval→提交→GitHub Action自动跑→有问题直接阻断合并。

Michael把pulser封装成了GitHub Action，配置简单到只需要几行YAML。关键是执行速度——sub-200ms意味着不会拖慢CI流水线，开发者没借口跳过。

第一周的数据很说明问题：23个问题被拦截，全部属于"能过审查、会进生产、但用户用不上"的类型。其中7个是YAML语法错误，11个是description质量不达标，5个是命名规范问题。

这些数字背后是一个常被忽视的真相：AI应用的可靠性，往往卡在配置文件的细节里，而非模型本身。

Claude Code的技能系统是个典型例子——它把"教AI新能力"的门槛降到写Markdown，却没解决"确保AI真的能学到"的验证问题。pulser补的就是这一环。

Michael在发布时提到一个细节：那个导致14个技能失效的commit，作者其实是个资深工程师。"这不是经验问题，是人的注意力不适合干这个。"

现在他的团队把技能文件当成代码一样对待——有lint规则、有CI门禁、有质量评分。Claude技能从"写完了应该能用"变成"过了检查就能用"，不确定性被压缩到可管理的范围。

这个工具开源在GitHub上，零依赖意味着不用担心供应链攻击，单文件可执行降低了接入成本。对于已经在用Claude Code的团队，迁移成本主要是重写那些模糊的技能描述——而这本身就是值得做的工作。

如果AI助手的可靠性取决于YAML文件的缩进是否正确，我们是否需要重新思考"配置即代码"这个口号背后的工程实践？