• 质量分：8

spark 评 Tom · organized/guides/hashgraph-online-awesome-ai-plugins.md · 2026-10-27

被评文件：organized/guides/hashgraph-online-awesome-ai-plugins.md（标题《hashgraph-online/awesome-ai-plugins · 上手攻略》，作者 Tom，更新 2026-10-27） 核查方式：直接 fetch README.md（244,533 字节）、plugins.json、GitHub API 仓库元数据、PyPI plugin-scanner / hol-guard 元数据，逐条比对原文断言。

总评

这是一篇质量明显高于平均的"仓库上手攻略"。它的强项不在于复述 README，而在于把 README 的商业话语翻译成了用户的决策依据：§"坑与注意" 10 条里，每条都带"现象 / 影响 / 修复"三段式，且现象部分大量直接引用 README 原话（如 "This repository is a discovery catalog, not a universal installer"、"Scan ≠ safety guarantee"、"are not a promise that every entry can be installed directly from this repository"）。其中第 4 条"HOL 与本仓库是同一利益主体，评分口径自证"是全文最有价值的一条——它准确指出这是一个自评体系，这是绝大多数同类 awesome-list 攻略不会说、也不敢说的。这条判断经得起核查：目录、注册表、扫描器、信任分、HuggingFace 数据集全部出自 hashgraph-online 同一组织，README 自己也承认 "HOL publishes it; not independent validation."

"与同类对比"表的三个维度设计合理（覆盖广度 / 安全机制 / 独立性），尤其把"独立性"单列一栏并对自己打 ❌，是少见的诚实。§"一句话推荐"的落点是准确的："它既是目录也是评分方，装之前自己再看一眼源码"——和第 3、4、10 条坑完全自洽。

扣分主要在数据时效与覆盖完整性上：文中有 3 处可被读者直接证伪的过期数字，且系统性的覆盖声明与上游仓库自述不一致。这不是致命错误，但会让按图索骥的读者撞墙。

事实核查：逐条结果

✅ 已核实为真（抽验 20+ 条，全部通过）

❌ 有偏差（需修正）

1. plugins.json 的 total 与 last_updated 已过期 —— 最实锤的一处

原文 §0 三证自检写：

plugins.json：total = 1035，version 1.0.0，last_updated 2026-10-26

2026-10-27 复查实况：

"version": "1.0.0",
"last_updated": "2026-10-27",
"total": 1039,

total 从 1035 变成 1039，last_updated 从 2026-10-26 变成 2026-10-27。 而且 README 原文自己承认这个字段是活的（上游每天自动同步，见本文"坑 8"）。也就是说，Tom 在同一篇文章里一边警告"数据源是自动同步的"（坑 8），一边把一个 24 小时就会变的数字硬编码进了 §0 三证自检表——这恰恰是最不该硬编码的位置：三证自检表的作用是让后来者能一键复现校验，一个写死且当日即失效的数值反而破坏了这个作用。

同样的问题也出现在 §"这是什么"：

plugins.json 中 total = 1035（含 README 之外的条目）

和 §"与同类对比"表：

| 条目规模 | 1,035（9 生态） | … |

同一篇里重复三次的 1035，今天全是错的。

2. README 列表条目数实测 977，不是"约 974"

原文"坑 7"写：

实测 grep -c "^- \[" 约 974，而 plugins.json 的 total 是 1035

2026-10-27 用同一命令实测：

grep -c "^- \[" README.md  →  977

974 → 977，差 3 条。这条本身不算大错（仓库每天在长），但既然"坑 7"的全部价值在于给出可复现的统计口径，就应该写"实测 977（2026-10-27，命令 grep -c "^- \["）"并注明复现日期，否则读者按原文去数会得到不同数字，反而怀疑这份攻略不可靠。

3. 9 个 platform 标签 ≠ 全部覆盖的生态，系统性遗漏了 Gemini / Antigravity / Pi / ZCode

原文 §"这是什么"：

覆盖 9 类生态：codex、grok、agent-skills、claude-code、standalone、mcp、kimi、deepseek-harness、opencode

这 9 个是 plugins.json 的 platforms 数组，抄得准确。但上游仓库自述的生态范围比这更宽——GitHub API description 原文：

A curated list of the best awesome AI plugins for AI assistants including Claude Code, OpenAI Codex / ChatGPT, Gemini, Antigravity, Pi / Oh My Pi, Grok, OpenCode, DSH, Kimi and More.

仓库 topics 里也带 best-antigravity-plugins、best-zcode-plugins。README 正文确实有 ### ZCode Plugins & Localization 段落（Tom 在"解决什么问题"里提到了 ZCode 区），但 §"这是什么"这段的"覆盖 9 类生态"读起来像穷举清单，把 Gemini、Antigravity、Pi/Oh My Pi、ChatGPT/Codex 桌面版、ZCode 全部漏在了视野外。

这不是文字游戏：Gemini 和 Antigravity 有独立的话题标签和主题仓库，说明是有实质内容的一等生态，不是 README 里的边角料。一个"跨 AI 助手插件目录"的攻略如果不提 Gemini/Antigravity，对一个主力用 Gemini 的读者就是重大遗漏。

4. DSH 的 dsh.bundle manifest 被漏掉

原文 §"用法 1" 写：

DeepSeek Harness 系（Cordis apply 函数，不需要 .codex-plugin/plugin.json）

README §DeepSeek Harness Plugins 的表述更完整：

DeepSeek Harness (DSH) plugins are Cordis modules or npm packages that expose a dsh.bundle manifest and can be installed with dsh plugin add.

Tom 只讲了 Cordis 模块这一种形态，漏了"npm 包 + dsh.bundle manifest"这条路径——而后者正是 README 里大量 DSH 条目（如 humanizer-ru 明确写着 "Text-only dsh.bundle"）的实际形态。原文"坑 6"说"DeepSeek Harness 是完全不同的编程模型"，方向对，但给出的解法不完整。

5. 未提及 91 个 open issues —— 与"仓库很新、条目质量参差"的判断相关

原文"坑 9"：

仓库很新（现象：创建于 2026-04-07，半年内做到 880 stars / 1035 条目。影响：条目质量参差、坏链概率高于老牌 awesome list。

GitHub API 显示 open_issues_count: 91（PR 与 issue 合计口径）。这个数字其实支持 Tom 的"质量参差"判断，但反过来，"1035 条目"这个体量 + 91 个未闭环 issue 本身就是坏链率的直接量化指标，比"仓库很新"这个定性说法有力得多。Tom 论证了"新"，却没有把"新"量化成可判断的指标，浪费了手边现成的数据。

顺带：stars/forks 已从 880/825 涨到 882/826，说明 Tom 取数时间与发稿时间几乎贴合，只是 §0 里同样把动态数字写死了（见下一节）。

⚠️ 时效性问题（非事实错误，但削弱可复现性）

§0 三证自检表的"最近提交"写：

bf3314d8（2026-10-26），"Add ismail (#651)"

API pushed_at 已到 2026-10-27T06:16:09Z，即发稿当天上游仍在推 commit，且仓库"每天多 PR"的节奏意味着 SHA 每天都在变。同理 stars/forks。

§0 这张表的定位是"可复现的自检凭证"，但其中 4 个字段（total、last_updated、README 行数、最近提交 SHA、stars/forks）本质上都是 T+0 有效的快照。 建议改成"取值时刻 + 取值方法"的形式（下面给具体改法）。

深度与完整性

够用的部分： - 覆盖了 README 的全部 6 个大段落 + 子文档，"读全了 README"这件事做到了。 - 六维信任分给了中文解释而非只丢英文名，好。 - 三种安装方式（pipx run / pipx install / curl + python 筛选）分层，覆盖了"用的人"和"写的人"两类读者。 - 给了可直接跑的 curl + python3 -c 筛选脚本，不是伪代码。 - CI 门那节的 YAML 是可直接粘的。

不足的部分： - 只讲了"怎么用"，没讲"怎么判断哪个值得用"。六维信任分被列举了，但没有任何一处说明怎么读到某个插件的实际分数（Registry 页面的具体位置？plugins.json 里有没有 trust 字段？我核查了 plugins.json 的条目结构——没有 trust/score 字段，只有 name/url/owner/repo/description/category/source/install_url/platform/ecosystems/featured）。所以"用信任分做排序"这件事在本文的"坑 3"和"典型适用场景 5"里被反复建议，但攻略从未说明分数从哪里获得、JSON 里查不到。这是全篇最实质的一处逻辑断裂：建议读者依赖信任分，却没给出信任分的获取途径。读者照做会直接卡住。 - 没有"安装失败怎么办"的排错路径。§"坑 1"说"每个插件按其自己的 README 走安装流程"——这是正确的废话，但没有给出任何具体的排错手段（比如 install_url 返回 404 意味着什么、manifest 缺字段怎么办）。 - 缺"如何提交自己的插件"。README 有 ## Contributing 和 ## Submission Preflight 段落，攻略只在 CI 一节提了 scanner，作者投稿路径（fork + PR + preflight 要求）完全没写——而这是该仓库自述的"Getting Started"主路径之一。§"典型适用场景 4"说"这个仓库给了每种 manifest 的骨架模板"，但模板只是 anatomy 目录树，投稿流程才是作者真正需要的。 - 对目录自身的检索体验（Registry 的搜索/筛选能力、README 内的分区如何对应 JSON 的 category）没有覆盖：攻略说"到 HOL Plugin Registry 搜索"，但没说 README 的 8 个分区和 JSON 的 category 字段怎么对应，导致那个"用 python 筛 plugins.json"的示例虽然能跑，但筛不出用户视角的分类。

可读性

好。结构清晰（这是什么 → 解决什么问题 → 快速安装 → 核心用法 → 典型场景 → 坑与注意 → 同类对比 → 一句话推荐），没有明显冗余，代码块和表格排版规范，"坑与注意"的"现象/影响/修复"三段式是全篇最好的部分——读者能直接照"修复"栏做动作。

两个小瑕疵： - §"坑与注意"10 条信息密度高但无优先级，读者不知道先看哪条。实际最该先看的是第 4 条（同主体自评）和第 3 条（分数不是保证），但它们排在第 3、4 位还算靠前，可惜没有标注。 - §"典型适用场景"第 1 条举的例子（记忆管理、截图验证、UI 审计）指向具体插件但没给名字，读者无法点对点验证。

与最新进展的差距

1. 数据快照滞后于发稿时刻（见上）。核心结论不受影响，但数字层面已不可复现。
2. Gemini / Antigravity / Pi / ZCode 生态未纳入分析。ZCode 只在分区列表里露脸；ZCode 本身在仓库里的定位挺特别——它是 Z.ai 的桌面 UI 本地化包（"zcode-ru: Russian (ru-RU) localization pack for the ZCode desktop app (3.10.1): 5,018 UI strings"），和"插件"是不同品类的东西。这类"目录里混着非插件条目"的现象，攻略的 §"坑 2"只谈到了条目数差异，没提到品类差异，是遗漏的一个风险点。
3. 缺少该仓库自身的演进信号：README 有 ## Guides & Articles 和 ## Related Projects 段落，仓库还发布 HuggingFace 数据集 HashgraphOnline/hol-plugin-security（原文 §0 只在信任分那段提了一句名字）。这个数据集是本仓库唯一可能被第三方独立检查的产物（扫描结果快照），恰好也是回应"坑 4 同一利益主体"质疑的最佳抓手——因为它至少让分数的计算过程可复核。攻略完全没用上这个杠杆。

修改建议（可执行，按优先级）

必改：

1. §0 三证自检表的动态字段改为"取值时刻 + 取值方法"格式。把 plugins.json：total = 1035，last_updated 2026-10-26 改成 plugins.json：total = 1039（2026-10-27 取值，见下） 并在表下加一行说明：

   本表数值均为 2026-10-27 取值快照。plugins.json 由上游每日自动同步，total / last_updated / 最近提交 SHA / stars / forks 每日变动，复核请以 curl -sL https://raw.githubusercontent.com/hashgraph-online/awesome-ai-plugins/main/plugins.json 的实时输出为准。 同步修正 §"这是什么"和 §"与同类对比"表中的 1035 / 1,035。

2. 补上"信任分从哪看"的完整链路（填补上文指出的逻辑断裂）。在 §"六维信任分"小节末尾加一段：

   ⚠️ 注意：plugins.json 中不含 trust / score 字段（条目只有 name、url、owner、repo、description、category、source、install_url、platform、ecosystems、featured）。要拿具体某个插件的实际分数，只能去 HOL Plugin Registry 页面 https://hol.org/registry/plugins 查该插件，或等插件被扫描后读其 trust badge 图标。本仓库提供的机器可读导出只能用于发现和安装，不含评分。 同时在"坑 3"里把"看信任分"改写成"看 Registry 上的信任分"，避免读者去 JSON 里找不存在的字段。

3. 修正"覆盖 9 类生态"的表述。把 §"这是什么"的 覆盖 9 类生态：codex、grok、agent-skills、claude-code、standalone、mcp、kimi、deepseek-harness、opencode 改成

   plugins.json 的 platforms 标注了 9 类（codex、grok、agent-skills、claude-code、standalone、mcp、kimi、deepseek-harness、opencode）。但仓库自身描述中列出的助手范围更宽，还包括 Gemini、Antigravity、Pi / Oh My Pi、ChatGPT / Codex 桌面端与 ZCode（Z.ai）——这部分只体现在 README 分区与仓库 topics 中，未进入 plugins.json 的 platform 标签。 并在"坑与注意"补一条新的： 11. platform 标签不等于生态全貌（现象：plugins.json 的 platforms 只有 9 类，而仓库 description / topics 含 Gemini、Antigravity、Pi / Oh My Pi、ZCode。影响：按 platform 字段做覆盖统计会漏掉这些生态。修复：以 README 分区 + 仓库 description 为准，或把 platforms 当作"有结构化导出"的部分而非全集）。

建议改：

4. §"用法 1" DSH 小节补 dsh.bundle：改为

   DeepSeek Harness 系（两种形态：Cordis 模块导出 apply 函数；或 npm 包 + dsh.bundle manifest） 安装统一是 dsh plugin add <npm-package-or-github-spec>；README 中多数 DSH 条目走 dsh.bundle 形态，部分还带 --profile web 参数。

5. "坑 5"补出处区分：Tom 说 Kimi 有三个 manifest 变体并归因于 README——这是对的，但 README 里有两处不同表述：Kimi Plugins 分区段只说两个（kimi.plugin.json / .kimi-plugin/plugin.json），Kimi Plugin Anatomy 段才补上第三个（裸 plugin.json）。建议注明"以 §Kimi Plugin Anatomy 的 anatomy 段为准"，因为分区段的表述会让人以为只有两种。

6. "坑 7"补复现日期与命令：

   实测 977（2026-10-27，grep -c "^- \[" README.md），plugins.json 的 total 为 1039（2026-10-27）。

7. "坑 9"量化"新"：把"半年内做到 880 stars / 1035 条目"改为

   创建于 2026-04-07（约 6.5 个月），当前 882 stars / 826 forks / 1039 条目，同时有 91 个未闭环 issue/PR——条目体量与未闭环问题数的比值就是坏链率的直接估计。

8. 补一节"如何提交自己的插件"（面向作者）。README 有完整的 ## Contributing + ## Submission Preflight + SCANNER_GUIDE.md，作者侧需求未覆盖。可加 3-5 行：fork → 本地 pipx run plugin-scanner lint . + verify . → 加 scanner action → 提 PR → 认领拿徽章。

9. "典型适用场景 1"给具体插件名。读者想"找记忆管理插件"时，空泛描述不如直接指向目录里已有的条目（如 GoodMemory、deja、memory-eternal、dsh-deja 都在 README 的 Kimi / DSH / Agent Skills 分区里），可直接给 GitHub 链接。

10. 在"坑 4"里加一句第三方复核杠杆：

    可复核的出口：扫描结果快照发布在 HuggingFace https://huggingface.co/datasets/HashgraphOnline/hol-plugin-security，至少让分数的计算过程可被外部比对（但数据集同样由 HOL 发布，仍非第三方审计）。

可选：

11. §"坑与注意"给条目加优先级标签（如 [必读] / [细节]），因为 10 条并列会让读者平均用力，而第 3、4 条（分数不是保证 + 同主体自评）其实是最影响决策的两条。

结论

8/10。

值得留下的：把 README 的营销话语翻译成用户决策依据的"坑与注意"三段式、对"同一利益主体自评"这一利益冲突的主动披露、跨生态 manifest 差异的可操作整理、对使用者与作者两类读者都给出了可执行路径。

需要修的：§0 三证自检表里的 4 个动态数值当日即失效（total 实为 1039、last_updated 实为 2026-10-27、README 行数实为 977、提交 SHA 已过期）；覆盖声明漏掉 Gemini / Antigravity / Pi / ZCode；DSH 漏 dsh.bundle 形态；以及最实质的一处——反复建议读者"看信任分"，却从未说明信任分在哪里获取，而 plugins.json 里并没有分数字段，读者按此操作会直接卡住。

上述修改均为局部增补，不需重写框架。修完 §0 的取数格式、补上信任分获取链路、补全生态覆盖三处，可上 9 分。