开放插件目录之前，先把审核运营算清楚

直接答案

开放插件目录，真正的成本不在「做一个提交表单」，而在接手一条不会自己消失的队列：有人提交、有人被拒、有人申诉、有人上传了带恶意代码的更新，还有人两年不维护却仍挂在目录里。这些事都得有人做决定。

所以在开放之前，先回答三个问题，顺序不能反：

1. 审核范围：只审第一次提交，还是每个版本都审？
2. 人工与自动的分工：哪些检查交给脚本，哪些必须由人看？
3. 对外时限：以你现在的人力，能稳定守住几天？

三个问题里最容易搞反的是第二个。「上了自动审核」不等于「不用人审」——下面五个公开样本里，有四个明确把人工留在流程内，只是把人工挪到了更高风险的位置。

五个目录的公开规则，先摆在一张表里

下表只写各家官方页面写明的口径，访问日期均为 2026-10-23。

目录	审核方式（官方口径）	官方给的时限	队列／规模数字	复审与下架
Obsidian	自动扫描每个版本 + 人工继续审「热门、精选、被社区举报」的项目	提交后通常几分钟出结果；通过后 24 小时内可搜索下载	几天内处理完 2,300 多条积压提交	每个新版本都扫；某版本不通过，24 小时内从搜索移除
Chrome Web Store	「manual and automated systems」组合	多数几天，可能到几周；超过三周可联系开发者支持	未公布队列数	现有条目周期性复审；违规、用户举报会触发复审
Figma Community	人工审核，按质量、信任安全、商业、法律四组规则	「Approval times vary depending on current volume and the team’s availability」	未公布	实质性更新重新审；核心功能大改要另开新条目；可随时移除
WordPress.org	人工队列，审核团队「100% volunteers」	初审 4 周内；回复 10 个工作日内；3 个月未完成会被拒	「more than 3500 people mid-review」	3 个月规则用于保持队列可维护；可重新提交续审（一般一次一个，百万安装以上最多 10 个）
Raycast Store	Pull Request 代码评审 + GitHub 自动检查	合并 PR 可能「several days」	未公布	每次改动走 PR；Keychain 权限、默认图标会被拒

这张表最该被注意的不是数字，而是五家对「审什么」的定义完全不同：Obsidian 审的是每个版本的代码安全与规范，Chrome 审的是权限与政策合规，Figma 审的是产品完成度、隐藏功能与商业合理性，WordPress 审的是仓库规范与安全，Raycast 审的是 PR 里的代码与元数据。你要开放的目录属于哪一种，决定了你该招什么人、写什么规则。

一、先分清两个轴：谁在审、什么时候审

「人工审核」和「自动审核」不是二选一，它们是两个独立的轴：

• 谁在审：机器、人，还是机器先筛、人再看；
• 什么时候审：只在首次提交时审，还是每个版本都审、再叠加周期性复审。

Obsidian 的改版把这条讲得最清楚。它在 2026-05-12 的公告里写：

Until today, initial submissions were manually reviewed and approved by our small team to ensure they follow the Developer Policies. However, as Obsidian has grown in popularity we struggled to keep pace with submissions, and subsequent versions were not reviewed.

也就是说，旧模式的问题不是「没人审」，而是只审了第一次，后续版本没人看。新模式的解法是两条腿：

With this transition we are introducing automated reviews for all community projects. The new automated review system scans every version for security and code quality, not just the initial submission.

Importantly, manual reviews will continue. The new system allows us to shift our efforts towards plugins that require deeper inspection such as popular plugins, featured plugins, and issues flagged by the community.

自动扫描接管的是「每一版都看一遍」这种重复劳动，人工被挪到高影响、高风险的少数项目上。 这不是裁员式的替代，而是重新分配注意力。

Chrome 的写法更直接：

The review process uses a combination of manual and automated systems. All submissions go through the same review system, regardless of the tenure of the developer or number of active users.

这句话还顺带说明了一件事：大开发者没有快速通道。同一套系统、同样的复审，区别只在信号——新开发者、新扩展、危险权限请求、大改动，都会被看得更仔细。

Figma 则几乎全压在人工判断上：完成度、隐藏功能、是否未经用户明确知情就读取或修改文件、是否在「poor taste」地变现、是否重造了 Figma 自己的功能。这些都不是静态扫描能给出结论的。

二、队列数字不能横向比较

最容易写错的一段，是把不同目录的队列数字放在一起算吞吐。

• Obsidian 说：「With the new system we were able to process over 2,300 queued submissions in the last few days.」——这是几天内处理完的积压量。
• WordPress 说：「At any point in time, we have more than 3500 people mid-review.」——这是某一时刻仍在审核中的人数。

一个是「已完成」，一个是「在队列里」，单位、时点、目录规模都不同。把 2,300 和 3,500 相除，或者据此推算「每家每次审核几分钟」，都是错的。 五家的公开页面都没有公布单次审核耗时或审核成本；你能查到的只有规则、时限和这几个特定口径的数字。

对一人公司更有用的做法，是量自己的队列，而不是借别人的数字：

• 每周新增提交数、每周能处理的提交数；
• 首次响应时间的中位数与最长值；
• 补件后到再次裁决的时间；
• 被拒后的申诉率与翻案率；
• 同一项目一年内被重新审几次。

这些数字不需要对外公布，但它们决定你第 3 个问题（能承诺几天）的答案。

三、哪些环节必须留给人

把五家的规则并排看，需要人做判断的环节高度重合，可以归成六类：

1. 身份与所有权。 WordPress 要求官方插件必须用组织账号提交，并明确说「We cannot accept plugins that act in name of an organization submitted by individual developer accounts」；Figma 要求发布者确保自己有代表组织的权限，且账号与所有权不能私自转让；Obsidian 目前只有 GitHub 仓库 owner 能编辑项目。这些都不是脚本能裁决的。

2. 权限与数据访问。 Chrome 把「broad host permissions」「sensitive execution permissions」「a lot of code or hard-to-review code」列为拉长审核的因素；Figma 会拒绝「read or modify a Figma file without a user’s explicit awareness and consent」的插件；Raycast 直接写「Extensions requesting Keychain Access will be rejected due to security concerns」。

3. 描述与行为是否一致。 Figma 的原话是「Your plugin or widget should operate as described … so that the users will not be surprised by any hidden functionality」，并明确会拒绝崩溃或有明显 bug 的提交。「隐藏功能」只能靠人对照描述与实际行为，扫描器不知道你承诺了什么。

4. 二进制与审核后可替换性。 Raycast 的规则值得抄进任何目录的条款：如果扩展在后台下载可执行文件，必须来自「a server that you don’t have access to」，否则「we cannot guarantee that you won’t replace the binary with malicious code after the review」。这条规则的本质是：审核通过之后，作者不能单方面换掉被审过的东西。

5. 商业与生态判断。 Figma 不允许插件展示广告，保留拒绝「monetize in poor taste」的权利，也不批准重造 Figma 自身功能（包括通用 AI 聊天界面、绕过官方 MCP server 的访问）。这类判断没有客观阈值，只能由人定规则并解释。

6. 下架、封禁与申诉。 Chrome 对已发布条目的复审列了四类结果，违规可能触发对已发布版本的复审；Figma 对利用 API 造假、抄袭、操纵用户文件的行为「will result in immediate removal」，并禁止未来发布；Obsidian 对不通过新审核的旧项目先给临时豁免，最终会「phased out」。这些决定都会影响别人的生计，必须有具名的人负责，而不是一个自动开关。

四、自动化能接走什么

自动化的价值不在「替代裁决」，而在把明显不合格的提交挡在人前面，以及把每一版都过一遍。五家里能直接抄的做法：

• 提交前自检：Obsidian 提供 eslint 插件，让作者在本地按官方规范检查；Raycast 要求作者先跑 npm run build 与 npm run lint，并说明这些检查「will later also run via automated GitHub checks」。
• 提交后预扫描：Obsidian 的开发者面板可以对任意 branch、tag、commit 跑 preview scan，作者在正式发版前就能看到问题。
• 每版安全与代码质量扫描：Obsidian 写明扫描覆盖「security and code quality」，包括「malware scanning to detect potentially malicious additions」。
• 评分卡与状态可见：Obsidian 用 scorecard 展示自动检查结果，并说未来会把披露、隐私标签、构建来源证明、人工审核结果都并进去。
• 队列状态与自动邮件：WordPress 在提交后先发确认邮件，再进队列；发现问题时用固定主题行 [WordPress Plugin Directory] Review in Progress: {Your plugin name} 通知，减少「到底收到没有」的追问。
• 一般一次只允许一个提交（百万安装以上的作者最多 10 个）：WordPress 明确说，放开并行提交后「Errors were regularly found in all the plugins, resulting in the same emails being sent multiple times」，改成一次一个后混乱显著下降。这是一个用流程约束换审核产能的例子。

但自动化一定有误报。Obsidian 自己就写：「Scorecards are new and can contain errors. You may find false positives and false negatives.」所以申诉通道不是等出事再加的功能，而是自动审核上线的前提。没有申诉入口，误报就会变成开发者在公开渠道里的抱怨，最后由你一个人收拾。

五、对外时限怎么写

先看五家怎么承诺，注意它们都没有承诺一个精确数字：

• Obsidian：「Typically, you will see the results of your review within a few minutes.」通过后「available to search and download in the app within 24 hours」。这只有在自动扫描兜住绝大多数提交时才敢写。
• Chrome：「For most extensions, review is completed within a few days, but it can take up to a few weeks.」并给了升级路径：「If your extension is pending review for more than three weeks, please contact developer support to request assistance.」
• WordPress：初审「within four weeks」，回复「within ten (10) business days」，3 个月未完成会被拒；并且提前解释人力结构——「the review team is made up of 100% volunteers, all of whom have full time day jobs」。小插件且代码无问题的情况，它另给了一个更具体的口径：「approved within fourteen days of initial review」。
• Figma：不给数字，只说随时长与团队可用性变化。
• Raycast：合并 PR「can take several days (depending on the review comments, etc.)」。

可抄的承诺结构是四段，而不是一个数：

1. 初审区间：X–Y 个工作日（写工作日，写时区，写节假日怎么算）；
2. 补件回复：Z 个工作日内（WordPress 的 10 个工作日就是个可执行的值）；
3. 超时升级：超过 Y 个工作日，去哪里查、找谁（Chrome 的三周支持入口）；
4. 兜底规则：超过多久未完成会关单或拒绝，以及能不能续审（WordPress 的 3 个月 + 可重新提交）。

不要承诺 24 小时，除非你每天都值班。 一个人做审核，周末、生病、出门都会发生；承诺一个守不住的数，比承诺 4 周更伤信任。WordPress 甚至专门写了「If it’s been two days, like over a weekend or a holiday, then you should not reasonably expect a reply」——把不可抗力提前写进预期，是一种负责任。

还有一条容易被忽略：时限要写清「从什么时候开始算」。是提交那一刻，还是材料齐全之后？WordPress 的 3 个月未完成会拒绝，期间只要作者在改就保持打开；页面没有写这 3 个月从哪一天起算——这正是目录方该自己定义、作者一定会问的细节。

六、开放前的八项检查

• 写清审核范围：只审首次提交，还是每个版本都审？每个版本都审的话，谁来跑、跑失败怎么办？
• 写清分级规则：哪些信号必须人工看（新开发者、危险权限、大改动、被举报、热门项目、涉及支付或账号）？
• 先有扫描，再有队列：静态检查、构建、类型检查、恶意代码扫描，至少能自动挡掉明显不合格的提交。
• 先有申诉，再有自动拒绝：误报怎么报、多久回、谁来翻案。
• 算得出自己的时限：按过去四周的实际处理量，给一个区间，而不是拍一个「24 小时」。
• 写清下架与复审：什么情况立即移除，什么情况先豁免再限期整改（Obsidian 对旧项目就是先给例外、再逐步淘汰）。
• 写清二进制与外部下载：审核后被替换的路径必须堵死；下载源不能由作者控制。
• 写清身份与所有权：组织账号、仓库 owner、转让规则；否则商标和冒充问题会落到你头上。

七、什么情况下宁可不开放目录

不是所有产品都该有目录。出现下面任意两条，建议先做「官方精选」或「私有目录」，而不是开放提交：

1. 没有稳定值班能力：无法保证 4 周内给出第一次裁决，也无法在出现恶意更新时 24 小时内下架。
2. 没有技术手段执行下架：目录、下载、自动更新是一条链，任何一环你关不掉，审核就只是装饰。
3. 没有申诉通道：自动扫描的误报会直接伤害开发者，而你只有一个人，解释成本会滚雪球。
4. 无法承担法律审查：商标、隐私政策、数据处理、未成年人内容——Figma 明确要求处理用户数据的插件必须有隐私政策，并把法律合规的责任写回开发者，但这不意味着平台没有责任。
5. 目录只服务内部团队：Figma 的建议是走私有插件，而不是占用公共目录的审核资源。
6. 核心产品还没稳定：审核会成为第二份全职工作，而且是最难外包的那一份。

三种最常见的误读

1. 「上了自动扫描就不用人工了。」 Obsidian 在自动扫描之外明确保留人工，用于热门、精选与被举报项目；Chrome 是 manual + automated 组合；WordPress 的队列是 100% 志愿者。自动化改变的是人工看什么，不是要不要人。
2. 「2,300 和 3,500 可以拿来算审核速度。」 前者是几天内处理完的积压量，后者是某一时刻在审的人数；单位不同、目录不同、时点不同。五家都没公布单次审核耗时，别替它们补。
3. 「时限越短越显得专业。」 一个守不住的 24 小时，不如一个能守住的 4 周。Chrome 敢写「几天到几周」，WordPress 敢写「4 周 + 10 个工作日 + 3 个月」，是因为它们把人力结构一起写清楚了。

来源

本文所有引用均来自下列公开页面，访问日期均为 2026-10-23，发布前逐条重新验证为 HTTP 200：

1. The future of Obsidian plugins核查于 2026/10/23（2026-05-12）：旧模式只审首次提交、新系统扫描每个版本、人工继续审热门／精选／被举报项目、几天内处理 2,300 多条积压、通过后 24 小时内可搜索、失败版本 24 小时内移除、scorecard 可能有误报与漏报、暂不接受新的闭源插件。
2. Chrome Web Store review process核查于 2026/10/23：manual + automated 组合、所有提交同一套系统不看资历与用户数、多数几天到几周、超过三周联系支持、新开发者／新扩展／危险权限／大改动会拉长审核、现有条目周期性复审。
3. Plugin and widget review guidelines – Figma Learn：审批时长随提交量与团队可用性变化、实质性更新重审、核心功能大改另开新条目、拒绝崩溃与明显 bug、隐藏功能、未经明确知情读取或修改文件、广告与不当变现、处理用户数据需隐私政策。
4. Plugin Developer FAQ – WordPress Plugin Handbook核查于 2026/10/23：审核团队 100% 志愿者、3,500+ 人处于审核中、初审 4 周内、回复 10 个工作日内、3 个月未完成拒绝以保持队列可维护、一次只允许一个提交、安全或法律问题之外不允许插队、官方插件须用组织账号。
5. Prepare an Extension for Store – Raycast API核查于 2026/10/23：PR 合并可能数天、GitHub 自动检查、默认图标与 Keychain 权限会被拒、后台下载二进制必须来自作者无权修改的服务器并加哈希校验。
6. Plugin and widget review guidelines – Figma Learn核查于 2026/10/23