把自研监控工具发到开发者作品展览馆：一次发布踩过的三个坑

手里有个自研的小工具：一套轻量服务器监控，探针常驻在每台机器上每 10 秒上报一次心跳，中心端汇总十几台机器的在线状态，一屏展示，掉线就推送告警。工具本身跑了很久，这次把它整理成作品发到开发者作品展览馆，发布过程踩了三个坑，记录一下。

坑一：两种鉴权根本不相通

发布流程里要过两道授权：一道是代码托管平台的 OAuth，一道是云厂商账号的鉴权。直觉上以为“登录都通过了就能发”，实际不是：代码仓库是公开的，读它根本不需要授权；真正卡在发布接口的那道，是云账号那条鉴权链路。

教训是：授权失败时先分清到底是哪条链路缺凭证，别在已经通过的那条上反复重试。我的解法也很简单——换到自己本人已登录云账号的浏览器环境里再跑一遍发布，鉴权链路自己就通了。

坑二：场景分类要按工具性质选，别按第一印象选

一开始我选了“产业场景”，结果它的分类全是具体行业（内容电商、智能制造之类），没有一项跟运维监控沾边。退回来改选“通用场景 → 开发工具”，才跟工具性质对上。

选分类时别急着点第一个看着顺眼的，先翻一遍子分类里有没有真正匹配的项，错一次就要重新走一遍流程。

坑三：Skill 包的名称一致性校验很严

首次上传被拒，原因很具体：包目录名和 frontmatter 里的 name 字段不一致。把目录统一成同一个名字后，一次通过。

这类校验失败时，报错信息往往只说“不一致”，不会告诉你是哪两个地方对不上——对照检查目录名、frontmatter name、作品名这三处是否完全一致，基本就能定位。

结果

作品最终以上架：通用场景 / 开发工具分类，1.0.0 版本。整个发布本身不难，难的是把“哪一步卡在哪条链路上”先分清楚；分清楚之后，剩下的都是体力活。

（本文为个人发布实践记录，流程以平台最新指引为准。）