事情是这样的。在我平时用 Obsidian 做笔记时越用越觉得官方插件不够用。

为了补齐自己的需求，我前前后后开发了三款 Obsidian 插件，踩了一堆「没人明说、但一踩就翻车」的坑。

后来我把这些踩坑经历，总结成了一份 AI 技能包，让 AI 从需求分析一路帮我干到插件上架。如果你也想用 AI 搞 Obsidian 插件，这篇文章值得认真看完。

一、从三个插件到一份 AI 技能包

我折腾 Obsidian 插件，起因其实特别小。最开始用的 墨光批注，在移动端样式出了毛病，我起了个念头，让 AI 来帮我修修看。

修完这个，又发现读书进度没法同步，于是 fork 了 gitee sync 项目，新写了个 gitee-sync-plus 专门同步读书进度。再后来翻遍市场没找到顺手的思维导图工具，又自己写了款 Mindmap Xmind。

三款插件做下来，踩过的坑、试出来的规矩实在太多了。我一想，这些经验不能白费，干脆把它们沉淀成一份 skill 技能包，以后开发插件少走弯路。

这份 skill 已经开发完成，而且我马上就用它开搞第四个插件了——一个 Obsidian AI 插件，叫 vault-mind，目前项目正在推进，后续会单独写成文章分享给大家。项目地址：https://github.com/hellokunzai/vault-mind，感兴趣的朋友可以先关注起来。

二、六道工序：从想法到上架的完整流水线

这份 skill 的核心，是 六道工序，把插件开发从想法到上架串成一条流水线。我用开餐厅来类比，你一下就懂：

• 需求分析
  ：客人点菜前先定菜单。AI 判断插件类型，评估可行性，给出功能清单和技术方案
• 代码开发
  ：后厨开火。搭脚手架、写逻辑、做界面，按模块一步步来
• 代码修改
  ：改菜。修 Bug、加功能，版本号怎么升、三文件怎么同步都有规矩
• 项目验证
  ：上桌前试菜。构建、安全扫描、合规检查一条条自动跑
• 代码发布
  ：开店营业。Git 提交、打 tag、建 Release 一条命令搞定
• 代码上架
  ：进大众点评。提交到官方仓库，等审核通过，全世界用户都能搜到

三、最值钱的设计：让 AI 学会停下来

如果你以为这份 skill 的价值在于流程，那就想简单了。它最值钱的，是教会了 AI 先停下来，等你拍板再动手。

很多人怕 AI 写代码不靠谱，其实是怕它一口气跑到底，功能全凭猜、UI 全凭想，最后做出来根本不是你要的东西。

这份 skill 里写死了一个 交互协议，两个硬检查点，AI 必须停下来等你确认：

• 检查点一
  ：需求分析做完后，AI 把功能清单和技术方案摆到你面前，你不说确认，它不写一行代码
• 检查点二
  ：项目验证通过后，AI 告诉你开发完成、问你要不要手动验证、把产物目录说清楚，你点头它才往发布走

而且它会退。手动验证时发现 Bug 或想加功能，有专门的回退路由：说有问题就退回修改环节修完重验；想加功能就退回需求环节只分析新的，不推翻已确认的部分。

核心总结

：AI 干活很猛，但得有人给它定规矩、做决策。拍板的人，只能是你自己。

四、两道落地保障：强制 i18n 与六个脚本

光有流程还不够，这份 skill 还上了两道硬保险，确保产出的插件能过审、能出海。

第一道，强制 i18n 国际化。所有插件必须做，界面上每一个字都不能硬编码，必须从翻译函数 t() 里取。中文用户看到中文，英文用户看到英文，将来加日语往表里加一列就行，业务代码一行不用动。

第二道，六个自动化脚本。把「不难但特别容易出错」的体力活全包了：

• plugin-init
  ：一句话生成整个项目骨架，不用手动 clone 模板
• version-bump
  ：升版本号，三个文件自动同步，再也不怕改漏
• security-scan
  ：扫构建产物，检查有没有踩审核红线
• version-check
  ：核对三个文件版本号一致
• pre-release-check
  ：一键全量检查，全绿才允许发布
• create-release
  ：检查、提交、打 tag、推送、建 Release 一条命令搞定

📝 五、实操步骤：用 skill 开发一个插件

想试试？跟我走一遍完整流程，从一句话需求到上架：

1. 第一步
   ：跟 AI 说「帮我写个 XX 插件」，AI 进入需求分析，有不清楚的地方立刻问你
2. 第二步
   ：你确认方案，AI 自动搭脚手架、按模块写代码，自己跑通编译
3. 第三步
   ：AI 自动做项目验证，发现问题就退回修改、修完再验（最多三轮）
4. 第四步
   ：验证通过，AI 问你是否手动验证，并把构建产物的具体目录告诉你
5. 第五步
   ：你确认无误，AI 一键发布到 GitHub，再带你走提交社区市场 PR 的流程

❓ 六、常见问题与避坑指南

开发 Obsidian 插件，审核规则没人明说，这里把最常踩的坑一次讲清：

• Q：manifest 里的 author 填什么？
   A：必须和你的 GitHub 用户名完全一致，填昵称会被打回
• Q：description 有什么要求？
   A：必须英文、250 字符以内、以句号结尾
• Q：打 tag 要注意什么？
   A：不能加 v 前缀，版本 1.0.0 对应的 tag 就是 1.0.0
• Q：能用 jszip 做压缩吗？
   A：不能，它实现里带 new Function，审核会挂，换成 fflate
• Q：手动验证时想加功能怎么办？
   A：走回退路由，退回需求环节分析新需求，增量开发后重新验证

📋 全文总结

回头看，这份 skill 说到底，就是把一个人踩过的坑，直接变成 AI 的默认动作。

六道工序覆盖了从想法到上架的整条链路，交互协议拦着 AI 不乱来，强制 i18n 让插件能面向海外，六个脚本把那些容易出错的体力活交给机器。

我甚至觉得，这套思路已经不限于做 Obsidian 插件了。它本质上是把项目管理的常识翻译成 AI 能执行的语言，让 AI 干靠谱的活。

💬 互动结尾

看完今天的分享，你有什么想法或者收获吗？

欢迎在评论区留言交流，一起探讨学习、共同成长～

喜欢本期内容，别忘了点赞、在看、转发，你的支持就是持续更新的最大动力！