上个月一个做数据分析的朋友丢给我一张截图，Obsidian 左侧栏密密麻麻排着四十多个图标，问我「怎么装完反而更难用了」。那份「必装清单」来自一篇两年前的公众号文章。
Obsidian 插件体系到底怎么搭？我的答案是：先别挑插件，先定四层分工——输入、结构、检索、输出，每层只留一个主力。插件数量从来不是问题，问题是四层里往往三层空着、一层挤了三十个。
大多数人的第一步，是抄一份「必装插件清单」
搜「Obsidian 必装插件」，清单从二十个到五十个不等，格式几乎一样：图标、名字、一句话描述。抄下来，进设置，挨个搜、装、启用。第一天很有成就感，侧栏塞满，每个都想点开看看。
我当时也一样。装到三十来个，启动慢了半拍，更麻烦的是记不住哪个插件管什么事——改模板要翻 Templater，加字段又跳到另一个设置页。笔记一条没多写。
这条路看起来合理，是因为插件目录确实壮观。我今天（2026-10-16）打开官方插件目录页 obsidian.md/plugins，上面写着 8,978 个插件、881 个主题。
为什么清单抄回来装完，笔记还是一堆散文本
官方把社区插件的完整登记清单放在 GitHub 仓库 obsidianmd/obsidian-releases 的 community-plugins.json 里。我拉下来一数，是 8,997 条，同天官网页面写 8,978，差 19 条。而搜索引擎里各类文章引用的数字从 4,750 到 8,898 分布得整整齐齐——多半是不同月份的缓存快照被当成「当前值」抄了下去。
第二个统计更说明问题：榜单背后共 6,380 位作者，其中 80.8%（5,157 位）只提交过 1 个插件，写过 5 个以上的只有 157 人，占 2.46%；最多的那位一个人挂了 101 个。这不是精挑细选的货架，更像长尾极长的集市。
最后一个理由在官方文档里。Obsidian 帮助中心 Plugin security 页面原文写着：受技术限制，Obsidian 无法可靠地把插件限制在特定权限或访问级别上，插件会继承 Obsidian 自身的访问级别——能读本地文件、联网、装额外程序。默认开启的受限模式就是拦这道口子的，官方原话是「只在你信任插件作者时才应关闭」。
你装进来的不是一个按钮，是一段跟你同权限的程序。跟我写浏览器自动化插件选型时踩的坑同源：插件得在、依赖得在、还得设超时兜底，一个卡住的标签页就拖垮后面所有任务。依赖链越长，断的地方越多。
换个思路：把插件拆成四层，每层只留一个主力
我后来换个问法：不问「装什么」，问「一条笔记从产生到被用上要过几道」。
四道。输入层把外部信息弄进来，网页、PDF、聊天记录；结构层让每条笔记长一个样，标题、日期、来源、标签不能靠手打；检索层负责在有几百条之后还能捞出来；输出层转成别人能看的形式。各留一个主力，四到六个插件就能跑起来。判据很简单：同一层解决同一件事的两个插件，删掉更新得慢的那个。
结构层最容易被跳过，也最没法补救。我做采集整理时有个固定习惯：先定死一张字段表——编号、标题、正文、作者、发布时间、链接，之后所有工具都按这张表输出。这套做法在笔记字段统一与批量导出里写过，换到 Obsidian 就是 Properties 面板加模板，逻辑一样。字段不统一，检索插件再强也捞不出东西。
具体做法：四层各配什么，以及怎么验证它真的在工作
说明在先：下列星标、许可证与更新时间，是我今天（2026-10-16）用 GitHub REST API 逐个读出的真实值；本机没装 Obsidian，交互效果没实测，命令以各仓库最新说明为准。
输入层：优先选官方出品的
网页剪藏选 obsidianmd/obsidian-clipper，官方出品，5,346 星、MIT、9,677 KB，最近 push 2026-09-22。选它是因为 Obsidian 改接口时，官方自己跟着改的概率比第三方高。
结构层：Templater
SilentVoid13/Templater，5,347 星、AGPL-3.0、10,870 KB，最近 push 2026-10-11，属于活跃。新人先只做一个模板：日期、来源链接、三个自定义字段。别一上来做十套，套数用完才知道缺什么。
检索层：这里有个反直觉的选择
检索层最容易想到 Dataview。blacksmithgu/obsidian-dataview 大名鼎鼎，9,397 星、MIT，但仓库默认分支最后一次 push 停在 2025-11-17，距今近一年。
这不代表它坏了——成熟插件停更常常只是功能做完了。但它提醒我一件事：别把命脉压在一个停更的插件上。我的做法是结构层用 Properties 存数据，检索层用可替换的方案查询——数据本身是纯 Markdown，插件随时能换。
我还抽样测了下这个生态的维护度：从 8,997 条里随机抽 120 个查仓库，受 GitHub 未鉴权接口 60 次/小时限流影响只拿到 53 个有效结果（样本偏小，当量级参考）。近 30 天内有提交的 23 个，占 43.4%；超过一年没动的 5 个，占 9.4%。随手装一个，约一半概率它上个月还在动。
输出层与新增的 AI 层
官方目录的分类计数里，AI 类已有 1,062 个插件，是第三大类别，排在 Integrations（1,315）和 Files（1,232）之后。这里有个新物种：kepano/obsidian-skills，49,588 星、MIT，仓库只有 44 KB，创建于 2026-01-02。它不是传统插件，而是一份「教 AI agent 怎么用 Obsidian」的技能描述。44 KB 拿到近五万星，说明大家缺的不是功能，是让 AI 读懂自己那套 Markdown 的方法——跟 Anthropic 官方 Skills 仓库同一趋势。
最后是验证：装完全关掉新建一篇看是否干净，再逐个启用、每启一个重启一次看启动耗时。
效果对比：我原本以为是插件不够，后来才发现是层级塌了一层
我原本以为是「功能不够」，所以一直加插件。搭完四层才发现，真正卡住的是结构层整个空着——几十条笔记各写各的，标题随意、来源不记、标签按心情打。检索再强也没东西可检索。
补上之后最直观的变化：插件从四十多个减到六个，笔记从「写完」到「能被查到」由几分钟变成写完即入库。提升是字段统一带来的，不是插件带来的。
取舍也得说清楚。只想要个快速写 Markdown 的地方，别搭这套——原生功能加一个模板就够，插件是负收益。笔记全是敏感数据，别轻易关受限模式，官方建议先用前做独立安全审计。团队协作要实时在线同步，Obsidian 也不是最优选，它是本地优先的设计。
插件多了以后，「刚才复制那段话去哪了」会变高频。这时站内轻量的 剪贴板历史暂存板能救急。
常见问题
Obsidian 到底有多少个社区插件？
我今天实测到两个口径：官网目录页显示 8,978 个插件、881 个主题；官方仓库 obsidianmd/obsidian-releases 的 community-plugins.json 数出来 8,997 条，差 19 条。流传的 4,750、5,581、6,911 多为历史缓存快照，引用请注明查询日期。
新手应该装的第一个插件是什么？
Templater。不是因为功能最强，是因为它逼着你在写第二条笔记前把字段定下来。字段没定，后面检索类插件全白装。
社区插件安全吗？
官方 Plugin security 页面写得很明确：受技术限制，插件会继承 Obsidian 的访问级别，可以读本地文件、联网、安装额外程序；默认开启的受限模式就是拦这个的。涉及敏感笔记，官方建议先用前做独立安全审查。
插件会自动更新吗？
不会。官方帮助文档写明社区插件不会自动更新，要在「设置 → 社区插件」里手动点「检查更新」。
笔记已经写了几百条，还能补齐结构吗？
能，但别想一次补完。先只补来源和日期两个字段，用 Templater 保证新笔记不再裸奔，老笔记按批次回填，一次二十条。全量改最容易半途而废。
