22万星和3.8万星，哪个更值得你把工作流搬上去

摘要：选开源项目的时候，几乎所有人第一眼看星标，几乎所有推荐文第一句报星标。但星标是那个页面上唯一一个只增不减的数字——项目烂掉了它也不会掉一颗。真正携带信息的是另外几栏：最后推送时间、未关问题除以星标的比值、许可证那一栏，以及版本号方案本身。这篇同一天拉了三个AI Agent仓库的接口数据做对照：22.3万星的那个有2.6万个未关问题，38.5万星的那个只有5798个，3.8万星的那个只有10个。还发现了一件几乎没人知道的事——GitHub上那个许可证标签是自动检测出来的，在标准MIT正文后面加一句无害的说明，就足以让它显示成“其他”，而合规扫描工具往往直接读那一栏。最后给一份十分钟能跑完的体检清单，判据同样适用于选插件、选主题、选采集工具。

先讲一件让我改掉习惯的小事。

年初有人推给保哥一个开源Agent框架，说“七周涨到11.3万星，2026年最快的开源项目”。这个说法是真的。三个多月后我又去看了一眼同一个仓库：22.3万星。翻了一倍。

但同一天我顺手把另外两栏也拉了下来，看到的东西和星标讲的完全不是一个故事。

星标是那一栏里唯一只会涨的数字

把GitHub仓库页面上能读到的字段排一排，你会发现它们分成两类：会随项目健康度上下浮动的，和只会单调上涨的。

最后推送时间会往回退（准确说是会停住不动），未关问题数会涨会落，发布节奏会变密变疏，许可证会改，分叉数虽然也基本只涨但涨速会明显掉档。只有星标不会——一个项目彻底死掉、作者跑路、代码三年没人碰，它的星标该是多少还是多少，甚至因为持续被老文章引用还会慢慢往上爬。

这一点在评测类内容里被放大得尤其厉害。站内那篇拆三款AI应用生成器计费机制与退出成本的横评写的时候我也踩过：三家的公开数字里，最好拿也最没用的就是融资额和用户数，真正决定你走不走得掉的全在文档细节里。

这就是问题所在：所有推荐文最爱报的那个数字，恰好是唯一一个不反映项目当前状态的数字。它测的是历史累计关注度，不是现在的健康度。而选型这件事，你需要的恰恰是后者。

而这套东西对本站读者的价值，恰恰不在于选Agent框架。站内那篇把SEO团队要用的AI工具分成五类做真实投产比对照的路线图里，最难的一步从来不是列候选，是判断某个候选半年后还在不在——而那个判断，用的就是下面这几栏。

顺带说一句，这跟做SEO时“别拿域名权重当唯一判据”是同一类错误：一个只累积不衰减的指标，用久了会让你系统性地高估老资产、低估新资产。

同一天拉三个仓库，体检报告长什么样？

下面这组数据来自2026年7月30日的接口调用，三个都是当下AI Agent方向上被提得最多的仓库。为了避免这篇变成软文，我不评价谁好谁坏，只看数字之间的关系。

这张表里有三个地方值得停下来。

第一，甲的星标是乙的1.7倍，但乙的未关问题是甲的4.5倍。比值差了将近八倍。

第二，丙的星标只有甲的十分之一，未关问题却只有10个。这个数字小到反常。

第三，甲的许可证在接口里返回的是NOASSERTION，也就是“未认定”。这一栏后面藏着这篇里最实用的一个发现，放到专门一节讲。

为什么这里全看比值，不看绝对值

有人会问：为什么不直接比“谁的未关问题多”？因为绝对值受项目规模影响太大，比出来的是体量不是健康度。

举个反直觉的例子。一个只有五百星的小工具，如果攒了三百个未关问题，那基本可以判死；而一个几十万星的项目攒了五千个，可能反而说明它运转正常——因为提问的人基数根本不在一个量级上。用绝对值排序，你会系统性地冤枉大项目、放过小项目，而后者恰恰是风险更高的那一类。

比值也不是万能的，它有一个已知的失真源：会被机器人和模板刷歪。有些项目开了自动化，依赖有更新就自动开一个问题，这类问题积压起来会把比值顶得很高，但它跟维护质量没关系。判别方法很简单——扫一眼问题列表里的作者，如果一屏里有一半是同一个机器人账号，那这个比值就得打折。

还有一栏叫“已关闭”，很多人从来没点开过

页面上问题列表默认只显示未关闭的，但那个筛选器旁边有个已关闭的入口。已关闭列表其实比未关闭列表更能说明问题：未关闭列表告诉你还欠着多少，已关闭列表告诉你这个项目还债的速度和方式。

点进去按最近关闭排序，看两件事：最近关闭的那几条是怎么关的（有真的修复提交，还是被机器人以“长期无活动”自动关掉的），以及从提出到关闭中间隔了多久。大批被自动关掉的陈旧问题，是一个比高积压更坏的信号——高积压至少说明还有人在提，自动清扫说明连提的人都不指望了。

未关问题除以星标，这个比值在说什么？

先别急着下“乙的项目质量差”这个结论。这个比值同时被三件事推动，得分开看。

它可能在说“用的人多且在真用”

问题是用户提的。一个没人真正跑起来的项目，是提不出问题的。11.65%这个比值在一定程度上是活跃度的证据，不全是负面信号——尤其当这个项目的定位是“装在你自己服务器上二十四小时跑”的时候，环境组合爆炸，问题量天然就高。

它也可能在说“进来的比处理掉的快”

这是负面的那一半。2.6万个未关问题意味着维护带宽已经明显跟不上流入速度。对你的实际影响很具体：你踩到的坑，大概率已经有人提过，但也大概率不会有人回。这不是道德问题，是算术问题。

丙的0.026%又是另一回事

10个未关问题配3.8万星，这个数字不能读成“质量高到没人提问题”。更可能的解释是项目形态不同——丙这个插件市场仓库的内容主体是一堆Markdown文件（Agent定义、技能包、命令模板），不是一个要在各种环境里跑起来的运行时。没有运行时就没有环境问题，没有环境问题就没有那类占绝大多数的issue。

三十秒读懂一个问题列表

比值只是个入口，真正有信息量的是列表本身。按最新排序之后，把前十条快速扫一遍，只做三件事：

1. 数一下有几条是“装不上”。安装类问题占比高，说明这个项目的门槛已经在往上飘，而作者没顾上。这一条对你影响最直接——你也要装。
2. 看有没有官方账号出现在回复里。不是看回复数量，是看回复里有没有维护者。二十条讨论全是用户互相猜，和三条回复里有一条来自维护者，是完全不同的两个项目状态。
3. 看最新一条和最老一条的间隔。如果前十条跨了两天，说明流入很猛；如果跨了三个月，说明这个项目已经安静下来了——安静未必是坏事，但你得知道自己在选一个什么节奏的东西。

这三件事加起来不到一分钟，得到的信息量比盯着比值算半天大得多。数字告诉你规模，内容告诉你性质，而选型需要的几乎全是性质。

所以这个比值的正确用法不是横向排名，是纵向自比：同一个仓库，半年前的比值和现在的比值哪个高？以及，看最近关闭的那几个问题，间隔是多久。后者比比值本身更硬——比值告诉你积压有多深，关闭间隔告诉你水管还通不通。

如果一定要看星标，看增速别看存量

存量是历史累计，增速是当下判断。同样是十万星，过去三个月涨了两万和过去三个月涨了两百，是两个完全不同的项目，而页面上显示的数字一模一样。

增速也没那么难拿——把同一个仓库的星标数隔一两周记两次，差值就是最粗糙但也最诚实的增速。真要做得细一点，接口里能按时间取到加星记录，画出曲线之后有三种形状值得认识：台阶形（某天突然一竖，多半是被大号推荐或者上了热榜，之后回落到平线）、斜坡形（持续缓慢上升，这是真实采用的样子）、平台形（涨到某个数就横住了，说明它的目标人群已经吃完了）。

台阶形最需要警惕，因为它对应的往往正是那些“七周涨到多少万星”的标题。一次热榜带来的星标，和一年里持续有人用出来的星标，在数字上没有任何区别，但在预测力上差着一个量级。

最后推送时间为什么比星标可靠？

因为它是唯一一个会往坏了走的公开字段。星标只涨，分叉基本只涨，问题数可以靠批量关闭做漂亮，只有“最后一次推送是什么时候”这一栏没法粉饰——要么有人在写代码，要么没有。

实际用起来有两个注意点。

这一栏还能顺手救你一次：很多推荐文里的包名、命令、配置项其实已经改过了，而文章不会自己更新。站内那篇整理最值得装的服务怎么选、真实包名与避坑清单的时候，被淘汰掉的候选里有一半就是因为包名早就换了而各处教程还在抄旧的。

第一，别把最后推送和最后提交搞混。推送时间会被一些无关操作刷新（比如只改了README、或者机器人提了个依赖升级）。所以看到“今天推送”之后还要往下走一步，翻一眼最近几次提交都在动什么文件。全是文档和依赖锁文件的，等于没动。

第二，八个月是个很有用的门槛。这不是拍脑袋——生态里的主要依赖大致每季度动一次，语言运行时每年动一到两次，八个月足够攒下一堆装不上的坑。之前研究一门课程的配套作业仓库时就撞过这个：星标接近四千，看着挺可靠，一查最后推送停在八个多月前，而课程大纲本身已经换了新版——课程官网、作业仓库、社交宣传，三处经常处在不同的时间线上。这三条时间线各走各的，谁也不等谁。

许可证那一栏，为什么显示的可能不是真的？

这一节是我这次最意外的收获。

前面表里的甲，接口返回的许可证是NOASSERTION，网页上显示成“Other”。按常识，这意味着它用了某种非标准的自定义许可证，企业采用前要走法务。

我把这个仓库的LICENSE文件拉下来看了一眼——是一字不差的标准MIT许可证。版权行、授权段、免责段，全都是模板原文。唯一的差别是文件末尾多了两行：

Third-party notices for incorporated or adapted code are recorded in THIRD_PARTY_NOTICES.md.

翻译过来就是“第三方代码的声明记在另一个文件里”。一句完全无害、甚至相当负责任的补充说明。

机制是这样的

GitHub那一栏不是人填的，是自动检测出来的。官方关于给仓库加许可证的文档写得很清楚：它用一个叫Licensee的开源Ruby包，把仓库的LICENSE文件跟一份已知许可证的短名单做比对。名单之外，或者比对不上，就归到“其他”。

文档里还有一句非常明确的官方建议：“要让你的许可证被检测到，请简化你的LICENSE文件，把复杂的部分记到别处，比如仓库的README里。”原文归因的失败原因是“多个许可证或其他复杂情况”。甲这个仓库恰好就撞在了“其他复杂情况”上——它把第三方声明的指引写进了LICENSE，而不是README。

GitHub自己在同一页上加了免责声明，说这些信息是“按现状提供”的，不做任何保证，并建议有疑问去咨询专业人士。换句话说，官方从来没说过那一栏是权威的，是我们自己默认它权威。

为什么这件事有实际后果

因为读那一栏的往往不是人，是流水线。企业里的依赖合规扫描、开源治理平台、采购审批表，很多都直接消费接口返回的许可证标识符。一个返回NOASSERTION的依赖，在这些流程里会被自动标红，然后走人工评审，然后卡两周——而它实际上就是MIT。

反过来的风险同样存在：检测通过不等于真的能用。Licensee比对的是LICENSE这一个文件，仓库里某个子目录带着完全不同的许可证、或者引入了传染性协议的代码，它都看不见。所以这一栏的正确读法是——它显示“其他”，多半是文件写法问题，不是许可证问题；它显示MIT，也只说明根目录那个文件是MIT。两个方向上都不该当结论。

最后一个可以当段子记的细节：决定这一栏怎么显示的那个Licensee项目本身，只有903颗星。几十万星的项目在页面上顶着什么许可证标签，是由一个九百星的小工具说了算的。

版本号方案一换，半年前的建议连语法都不成立了

这条是从一次打脸里学来的。

四月份有篇写得相当认真的评测，结尾给了条建议：“如果你想等更稳定的版本，建议等v0.12，预计五月中下旬。”这句话在当时完全合理，那个项目正在v0.10。

问题是，这个项目现在的发布列表里最新的标签叫v2026.7.20。往前翻是v2026.7.7.2、v2026.7.7、v2026.7.1、v2026.6.19、v2026.6.5。它已经从语义化版本整个切到了日期版本。不存在v0.12，也永远不会存在——那条建议现在连语法都不成立了。

版本号方案本身就是一个信号

这件事比“某条建议过期了”更有意思的地方在于：版本号方案的选择，本身就在告诉你这个项目怎么看待自己。

• 语义化版本（主.次.修）在承诺兼容性契约：主版本不变，你的集成就不该坏。用它的项目通常有明确的公开接口和相对稳定的用户群。
• 日期版本（年.月.日）不承诺任何兼容性，只承诺新鲜度。用它的项目通常迭代极快、接口还在动、并且默认你会一直跟着升。
• 从前者切到后者，是一个明确的表态：我们不打算再维持版本承诺了，请跟着走。

所以看到日期版本的时候，你要问的不是“哪个版本稳”，而是“我能不能接受两周一次的跟进节奏”。这两个问题的答案完全不同。

顺带看一眼发布节奏

同一份发布列表还告诉了我另外两件事：大版本大约两周一发，中间夹着修补版本（7月7日发了一个，第二天马上跟了一个7.7.2）；而几个大版本的说明文字长度分别是五万二、四万、四万五千个字符。

两周一发、每次四五万字的变更说明，这个组合读出来是：功能推进极快，但你不跟就会掉队；而且每次跟进要读的东西不少。如果你的团队没有专人盯这个，那么“它很活跃”对你来说其实是成本不是收益。

创建时间那一栏，能戳破哪些叙事？

这一栏几乎从来没人看，但它是唯一一个能对上官方叙事的字段。

回到开头那个“七周从零涨到11.3万星”的说法。这个说法把起点定在2026年2月底。而接口返回的仓库创建时间是2025年7月22日——比叙事起点早了七个月。

这中间的七个月去哪了？可能性无非几种，每一种都有对应的排查动作：

• 先私有开发，后转公开。最常见。仓库创建于私有阶段，公开那天才开始涨星。判据：翻最早的几次提交，看时间是否连续；如果最早的提交和创建时间同期、且一路密集到公开日，那就是这种情况。这不是问题，只是说明“七周从零”这个说法省略了准备期。
• 改过名或转移过。GitHub保留原仓库的创建时间，但会把旧地址重定向到新地址。判据：看主题标签里有没有别的项目名残留——这个仓库的标签里就同时挂着好几个明显是旧名字的词。这种情况要额外注意：你在网上搜到的旧名字资料，可能对应的是完全不同的一个版本。
• 从别的项目分叉出来后断开了关系。判据：接口里的分叉标记是否为假、上游字段是否为空。都为空但代码风格明显承袭另一个项目的，值得多看两眼。

不管是哪一种，结论都一样：创建时间和官方叙事起点差得越多，就说明有一段历史没被讲出来，而那段历史里往往藏着你最该知道的东西——比如它原来叫什么、原来的用户为什么走了、旧文档还有多少在网上飘着。

反过来的情况同样值得警惕：如果创建时间晚于你在网上看到的最早讨论，那多半是仓库被重建过。重建意味着历史问题、历史讨论、历史提交全都不在这儿了，你搜到的那些“已解决”的帖子可能指向一个已经不存在的地址。

分叉数和订阅数各自在测什么？

这两栏很少有人认真读，但它们测的东西不一样，而且都比星标具体。

分叉除以星标大致反映“看客里有多少人真的动了手”。前面那张表里，甲21.0%、乙19.2%、丙10.7%。丙明显低，这跟它的形态吻合——它的用法是装插件，不是改代码，所以不需要分叉。而甲和乙都在两成左右，说明这两个项目的用户里有相当比例是要自己改的。这个比值高，意味着你也大概率得改。预算要按这个来估，不是按“装上就能用”估。

订阅数（也就是关注仓库动态的人数）测的是另一件事：有多少人愿意持续接收这个项目的通知。乙的订阅数是838。相对22.3万星来说，这个数字非常小。它说明绝大多数人是点了个星就走了，并没有真的跟进。星标里有多少是“先收藏着”而不是“我在用”，这一栏给了个粗略的答案。

把这套判据搬到你真正要选的东西上

写到这里得说，我知道大部分读这篇的人不会去选AI Agent框架。但这套判据是通用的，只要目标托管在GitHub上就能用，而做独立站的人几乎天天在选这类东西。

选WordPress插件的时候

插件目录页会显示“最后更新”和“兼容到某某版本”，但那两栏是作者手填的，改一下日期就能刷新。去仓库看最后推送时间，两者对不上的时候，以仓库为准。另外一定要翻最近几条未关问题——如果最新的几条都在问“新版本装不上”而且没人回，那这个插件的实际状态跟目录页显示的不是一回事。站内那篇讲备份方案五个维度对照与真实选型的复盘里，被淘汰掉的几个候选就是栽在这一步。

选主题或建站框架的时候

重点看分叉除以星标。这个比值高，说明大家都在改它——那你也得改，别指望开箱即用。还要看许可证那一栏，主题类项目的许可证情况比插件复杂得多，因为它们经常打包了字体、图标、演示图片，而这些资产的授权跟代码本身的授权常常不是一回事。这时候接口返回“其他”反而是个有用的提醒：值得点进LICENSE文件亲眼看一遍。关于建站底座该怎么选，站内那篇从SEO角度横评几种内容管理系统的分析可以配着看。

选采集或数据类工具的时候

这一类最该看问题的关闭间隔而不是问题总数。采集工具的生命线是跟着目标站点的改版走的，目标站一改结构它就废。所以你要确认的是“坏了之后多久有人修”，而这个答案只能从最近几个已关闭问题的时间戳里读出来。星标在这里几乎没有参考价值——被采的站不会因为工具星标高就不改版。

如果它根本没有公开仓库怎么办

越来越多的AI工具是纯服务形态，没有开源仓库可查。这时候整套判据要换一批观察点，但问的还是同样三个问题。

“最后一次有人动它”的替代观察点是变更日志和文档更新时间。变更日志停更三个月以上的服务，多半已经进维护模式了。有个更隐蔽的判据：看它的文档里还在不在提已经过时的模型名或版本号——文档里挂着半年前的型号，说明没人在维护那套文档，而没人维护文档的服务，接口大概率也没人维护。

“遇到问题之后发生了什么”的替代观察点是社区渠道。看它的社群或论坛里，官方账号最近一次回复用户是什么时候，以及回复的是不是实质问题。这一步比看“有没有工单系统”有用得多。

“授权条款有没有亲眼看过”在服务形态下更重要，因为条款可以单方面改。要额外关注两件事：数据用不用于训练，以及停服之后你的数据怎么导出。这两条通常写在服务条款的中后段，而不是价格页上。

这套清单最容易被误用的地方

最后提个醒，免得走到另一个极端。这五步是排除法，不是打分法。它擅长的是快速淘汰掉那些明显不该选的，不擅长在两个都健康的候选里分出高下。

两个候选都通过体检之后，决定选哪个的因素完全在另一个维度上：它解决的是不是你真正的问题、迁走的成本有多高、你的团队会不会用。把体检指标拿来当排序依据，是这套方法最常见的误用——就像不能靠体检报告选朋友一样，体检只能告诉你谁明显不行。

一份十分钟能跑完的体检清单

把上面所有东西压成动作，一次接口调用加三次点击就够：

1. 拉一次接口。一条命令就能拿到星标、分叉、未关问题、最后推送、许可证、创建时间、订阅数、主语言全部字段，仓库接口的官方文档里写得很清楚，不需要认证也能读公开仓库。这一步比在网页上翻半天快得多，而且拿到的是结构化的。
2. 算两个比值。未关问题÷星标、分叉÷星标。前者看积压深度，后者看你要不要准备改代码。
3. 点进问题列表，按最新排序，看前五条在问什么。这一步无可替代。比值告诉你有多少积压，这五条告诉你积压的是什么性质——是功能请求还是“装不上”。
4. 点进发布列表，看版本号方案和最近三次的间隔。方案告诉你它承不承诺兼容，间隔告诉你你要付出多少跟进成本。
5. 点开LICENSE文件本身看一眼，不看那个自动检测出来的标签。三十秒的事，能省掉后面两周的合规扯皮。

还有一件值得顺手做的事：如果你选的是Agent相关的东西，先确认它的资产格式绑不绑死在某一个工具上。站内那篇写同一套Agent资产能不能跨工具搬家的实测把五家的能力差异逐行对过一遍，结论是能不能搬跟项目活不活跃是两个独立的风险，得分开评。至于托管型和自建型该怎么选，站内那篇拆官方托管智能体真实用法与避坑的文章可以配着读。

五步走完，你对这个项目的判断会比“它有多少星”准确一个数量级。而且这五步跟项目属于哪个领域完全无关——选Agent框架、选插件、选主题、选一个命令行小工具，动作一模一样。

保哥自己现在的习惯是：看到推荐文里第一句报星标的，就默认作者没做过这五步。这个启发式的准确率高得有点让人失望。

常见问题解答

星标是不是完全没用？

不是完全没用，是被严重误用了。它有一个正当用途：判断这个项目有没有过临界规模——几百星和几万星之间确实有质变，涉及到有没有中文资料、有没有人在论坛回答问题、出了事能不能搜到别人的解法。但一旦过了这个门槛，星标继续涨对你的决策就不再增加任何信息了。三万星和三十万星之间的差别，对你能不能用好它几乎没有影响。

未关问题很多的项目就不能用吗？

能用，但要调整预期。正确的心态是把它当成“社区版软件”而不是“产品”：你踩到的坑要自己解决，不要指望提问会有回音。如果你的团队有能力读源码、能自己打补丁，高积压其实不是障碍；如果你指望官方支持，那这个比值就是个很硬的否决项。

接口返回NOASSERTION，到底能不能用？

先点进LICENSE文件看一眼，多数情况下答案会在三十秒内出现。如果正文就是标准协议、只是多了几句附加说明，那基本可以按那个标准协议理解，但企业场景下建议把这个情况写进你的合规记录里，免得下次扫描又被卡。如果正文确实是自定义条款，那就得逐条读，尤其注意有没有“不得用于商业用途”“不得提供竞品服务”这类限制——这类条款在最近两年的项目里出现得越来越多。

怎么快速判断一个项目是不是快死了？

三个信号同时出现基本可以定性：最后推送超过半年、最近几条未关问题都是“装不上”且无人回复、发布列表最后一条也停在半年前。单独一个信号都可能有别的解释（比如项目已经成熟到不需要频繁改动），三个一起出现就没什么别的解释了。

一个项目星标停涨了，是不是就该换掉？

不是。星标停涨最常见的原因是这个项目的目标人群已经吃透了——需要它的人都已经知道它了，没有新增关注很正常。真正该触发换掉决定的是另外三个：最后推送停住、你提的问题没人回、以及它挡住了你要做的下一件事。前两个是它的问题，第三个是你的问题，而第三个通常才是真正的换掉理由。

为什么不看贡献者人数？

因为这一栏的噪声比信号大。贡献者列表里会混进大量只提过一次拼写修正的人，而这些人和真正在维护的人在列表里长得一模一样。想看这个维度，更可靠的读法是看最近三个月的提交里，作者一共有几个不同的人——如果九成提交出自一个人，那这个项目的实际状态是单人项目，跟贡献者列表上挂着两百人没有关系。单人项目不是不能用，但你要按单人项目的风险来准备。

这套判据对不在GitHub上的项目怎么办？

思路可以整个搬过去，只是取数的地方变了。核心永远是那三件事：最后一次有人动它是什么时候、用户遇到问题之后发生了什么、以及授权条款你有没有亲眼看过。码云、自建的代码托管、甚至一个只提供下载的官网，这三件事都能找到对应的观察点，只是要多花点时间。

做SEO和独立站，最该把这套判据用在哪儿？

用在所有会长期跑在你站上的东西上：插件、主题、缓存方案、采集工具、结构化数据生成器。判断依据的排序是——最后推送时间第一，最近问题的性质第二，许可证第三，星标最后。特别提醒一点：跟搜索引擎打交道的那类插件（站点地图、结构化数据、重定向管理）对新鲜度的要求比其他插件高一档，因为搜索引擎那边的规则一直在动，而一个半年没更新的结构化数据插件，输出的很可能已经是过时的格式了。

权威参考资料