被官方 Bot 打回 10 次后，我终于摸清了 Obsidian 插件上架的所有“潜规则”
前段时间，我分享了 那款自认为还算优雅的排版插件。
当时它还只是个躺在我本地文件夹里的产品，大家如果想用，还得手动下载、解压、安装（或者通过 BRAT 安装）。虽然能用，但总觉得少了点什么。
就像自己亲手打磨的一件小器物，如果只能摆在自家书架上，多少有点遗憾。我希望能让全球的用户，在 Obsidian 的插件市场里搜一下 Wechat Converter，点一下就能用上它。
于是，我决定把它送进“正规军”序列：申请上架 Obsidian 官方社区插件市场（obsidian-releases）。
本以为这只是个填个表、提个申请的简单活儿，结果折腾下来，我才发现：写功能是跟代码打交道，而上架是跟规则打交道。
这中间我撞了不少次墙，也跟官方的 Bot（自动化校验脚本）反复“对线”了好几轮。为了让后来者少走点弯路，我把这次真实的踩坑记录整理了出来。
官方上架，到底在做什么？
其实核心流程只有两步：
- 给你的插件仓库发一个合规的 GitHub Release。
- 去官方仓库提一个 PR，把你的插件信息加进
community-plugins.json。
听起来很简单，对吧？但真正折腾人的，是那些隐形的校验规则。如果你没对齐它们的“强迫症”标准，官方的 Bot 会毫不留情地把你的 PR 打回。
我踩过的那些“莫名其妙”的坑
1. 版本号的“洁癖”
我习惯给 Git tag 加个 v 前缀，比如 v2.6.9。
但在 Obsidian 的世界里，这是行不通的。它的校验逻辑非常死板：manifest.json 里的版本号写的是 2.6.9，那么你的 Git tag 就必须是纯数字 2.6.9。
多了一个 v，Bot 就会告诉你：找不到对应的 Release。我为此专门发了好几个空版本，就为了把这个前缀去掉。
2. Description 的“政治正确”
这是最让我哭笑不得的一个坑。我在插件描述里写了：Convert Obsidian Markdown into...。
结果 Bot 报错说：描述里不能包含 Obsidian 字样。
我当时愣了一下，随即明白了。既然是在 Obsidian 的插件市场里，大家当然知道这是给谁用的。这种重复的冗余信息，不仅占地方，还显得不专业。
另外，描述的末尾必须带上英文标点（句号、问号或括号），差一个标点符号，校验都过不去。
3. PR 模板不是“长得像”就行
提交 PR 时，官方提供了一份模板。我一开始觉得，只要把关键信息写清楚，格式稍微动动没关系。
结果很快就被现实“教做人”了。官方的 Bot 是按固定字符串去匹配的。你不是“差不多按模板写”，而是要尽量原样不动地填空。
如果你改了某些固定句式，Bot 就会提示你没有遵循模板。
4. 触发校验的“玄学”
有时候你发现 Bot 报错了，赶紧改了 PR 描述。结果等了半天，发现报错还在那挂着。
后来我才发现，光改 PR 描述不一定能触发 Bot 重新运行。
最稳妥的办法是：对 community-plugins.json 里的代码做一点点无意义的微调，比如加个空格或者改个缩进，然后重新 push 一次。这种物理层面的代码变动，才能强制让 Bot 动起来。
顺手做的两个“小优化”
在跟 Bot 对线的过程中，我也顺便把插件的门面修整了一下。
首先是 README 英文优先
虽然这个插件主要是给国内朋友用的，但毕竟审核大权握在人家老外手里。为了不让人家因为看不懂中文而直接关掉我的 PR，我只能“被迫”把主 README.md 改成了全英文，中文说明则放到了 README.zh-CN.md 里。
其次是作者名的呈现
我把作者从单纯的「林小卫很行」改成了双语格式：DavidLam (林小卫很行)。这样既能让老外识别，也保留了自己的中文身份。
折腾完这一圈，最大的感触是：真正难的不是“写一个插件”，而是把它交付到一个严格、稳定、可分发的标准里。
当你写功能时，你面对的是自己的创造欲；而当你做上架时，你面对的是整个生态的秩序。
目前，我们的 PR 已经通过了所有的自动校验，状态变成了 Ready for review。接下来的，就是耐心等待人工审核的最终结果了。
如果你也准备提交自己的插件，不要怕那些繁琐的报错。把每一次 Bot 报错都当成一次规则补全，最后你会得到一条非常干净、专业的发布链路。
能做的事我都做了，剩下的，就交给时间吧。
