star 曲线不该出现在选型评分表里：从一款短爆式增长的逆向工具说起
一、事情是怎么开始的
2026 年 10 月的一篇博客园文章介绍了 REA（原文给的仓库是 morluto/rea），一个用 TypeScript 写的 MCP 服务，作者把它的热度当作主要卖点——原文提到的量级是”一个月内涨到 15W+ star”。
我们复述这句不是为了引用它，恰恰相反：这是唯一一个我们明确拒绝当作证据的输入。star 数会随营销投放、榜单曝光，以及平台对异常账号的批量清理而波动，不同时间抓到的值很可能不一样。把它写进选型记录，等于把一个不可复现的数字固化成长期决策的依据。更麻烦的是，一个不进评分表的指标只要出现在汇报材料里，最后总会变成事实上的评分项。
倒是原文里那些可以核实的功能性信息，是有用的输入，我们记下来：REA 的口号是 “Reverse Engineer Anything”，面向二进制、APK、JS、.NET、WASM、固件这些目标；工作方式是透过 MCP 让 AI 代理去驱动 Ghidra、IDA、Hopper 这些已经存在的逆向工具；它本身不打包这些工具，需要本地先装好；入口是一条 npx 打头的 setup 命令，分析动作对应 rea analyze；许可证是 MIT；作者明确写了用途限定——「只用于合法研究、教育、互操作和自有或授权软件的分析」。原文还给过两个提醒：更新节奏快、文档跟不上增长，以及本地数据会被送到模型服务端。
最后这一条对我们来说，比 star 曲线重要得多。
二、短爆式增长通常对应什么
我们先说机制，再下结论。增长形态大致分四种：
- 热点搬运。 某个新协议或新能力被集中报道，同名工具成批出现，第一波 star 来自”先收藏再说”的人，和有没有真的用过无关。
- 投放。 通过社群、日报、聚合账号集中曝光。信号是 star 曲线陡，但 fork 和 issue 曲线几乎是平的。
- 账号侧异常。 批量账号带来的上涨，在平台清理之后会回落。这类曲线最典型的特征是斜率过于整齐，几乎看不出自然传播的抖动。
- 真实的口碑扩散。 曲线相对平缓，但 issue 区里有非作者参与的技术讨论，而且时间跨度拉得比较长。
我们的判断标准只有一句话：看结构和比率，不看总量。 star 与 fork 的比值、star 与”提过有意义 issue 的人数”的比值，以及这两个比值在暴涨前后是否保持稳定，比任何一个绝对值都更可信。一个工具从一千 star 涨到十万 star 而提有效 issue 的人数还是那十几个，这件事本身就说明上涨的不是使用量。
三、真正能取证的那几项
提交结构。 不看提交数，看形状。commit 信息是否成体系，有没有小步迭代和回滚的痕迹，是否出现过”一次提交上万行”。一次性大提交加上陡峭的增长曲线，最常见的解释是既有代码搬家，而不是这个项目在快速成长。对逆向类工具这点尤其要紧：把若干外部二进制搬进仓库的项目，star 涨得快和它有质量之间没有因果关系。
测试可复现性。 不看徽章，自己动手。能不能在隔离环境里按 README 一条命令跑起来，有没有针对已知样本的回归集。逆向和安全类工具的样本管理是硬功夫——缺样本集意味着每一次改动都靠人肉验证，这种项目的回归风险随功能增加而上升，不会下降。
issue 响应质量。 不看响应速度，看内容。要区分”已修复，见某次提交”和”关闭，请重述问题”这两类。前者说明维护者真的在处理，后者说明有人在值守但没在干活。我们的动作是抽 20 条已关闭的 issue 逐条看，半小时能得出结论。
维护者集中度。 在一个固定的抽样窗口里统计主要作者的提交占比。单维护者项目我们不做”禁止”处理，这太苛刻也不现实，但会强制要求一条退出预案：负责人失联时，我们能不能自己接管这个 fork 并继续构建。答不上来就是风险未闭环。
许可与分发方式。 宽松许可证解决的是源码使用义务，不代表仓库里每个组件都服从同一条款。二进制分发要额外看两件事：安装过程是否要求下载闭源可执行文件，以及是否存在自动更新。自动更新等于把我们的一次审计变成永久的信任——这条我们在准入清单里是直接标成否决项的。
回到 REA：按上面这几项看，真正值得写进我们记录的只有两行——MIT 许可、不自带二进制而是驱动本地已有工具；以及”本地数据会送到模型服务端”这一条。对逆向场景来说，被分析的目标文件往往就是最敏感的资产，可能是客户的固件、内部的私有协议实现。数据流向和用途授权这两项，恰好是准入清单里最硬的那两栏。至于 star 涨了多少，那行我们已经在模板里删掉了。
四、我们给内部技术委员会的准入清单
这张表用于新依赖引入和对外交付前的组件复核，逆向与安全类工具按最严档执行。
| 维度 | 取证方式 | 通过标准 | 一票否决 |
|---|---|---|---|
| 增长形态 | 只看 star 与 fork、活跃贡献者、有效 issue 的比率随时间变化 | 比率稳定；存在跨越多月的非作者技术讨论 | ——（不作为通过项，也不作为否决项） |
| 提交结构 | 读抽样窗口内的 commit 图与提交信息 | 有小步提交与回滚痕迹 | 一次性导入全部代码且无历史 |
| 测试可复现 | 在隔离环境按 README 实跑一次 | 一条命令可跑；有样本回归集 | 无法在离线或沙箱环境跑通 |
| issue 质量 | 抽 20 条已关闭 issue 逐条看 | 带具体提交引用的修复占多数 | 长期无人回复，或全部以”无法复现”关闭 |
| 维护者集中度 | 统计主要作者提交占比 | 有第二维护者，或已备好 fork 接管预案 | 单维护者且无接管预案 |
| 许可证 | 读 LICENSE 原文并存档，扫描依赖树 | 各组件条款均可商用且义务清晰 | 出现条款不明或需付费的间接依赖 |
| 分发方式 | 检查安装脚本与更新机制 | 源码构建，或可校验的固定制品 | 安装需执行无法审计的远程脚本；存在静默自动更新 |
| 数据流向 | 读代码并抓包确认外发内容 | 默认不外发；外发可显式关闭 | 把用户输入文件或其片段默认发往远端服务 |
| 用途合规 | 确认使用场景与授权链 | 有书面授权或对象为自有资产 | 用于未经授权的第三方目标 |
| 退出成本 | 检查接口是否被业务直接依赖 | 有适配层包住，存在可替换实现 | API 直接渗入业务代码且无替代方案 |
一票否决只留了三条，因为它们会造成不可逆的后果：无法审计的远程脚本、默认外发数据、无授权的第三方目标。前两条是技术与合规风险，第三条是法律风险。其余维度都是”降级使用”，不是”禁止使用”。
五、这张表怎么用
- star 数不进表。 我们试过给它一栏”参考”，结果它每次都变成讨论的第一句话。现在模板里干脆没有这一栏。
- 通过标准必须是自己在机器上做过的动作。 任何来自 README、榜单、文章或模型输出的描述都不算取证。这一条听起来苛刻，但它是这张表日后能被别人复核的唯一保证。
- 热度唯一的作用是提醒你去看一眼。 看完之后走同一张表，不给任何捷径。
还有一点关于”用 MCP 把工具能力包起来”这件事本身。原文的落点是把它当作对模型输出的约束——模型只能调用真实存在的动作，这确实能压掉一部分凭空编造。方向我们认同，但要再加一层：模型能读到哪些内容，应该当成一个配置项来管理，而不是当成库的默认行为。上面那张表里”数据流向”这一栏，针对的正是默认行为——大多数人踩坑不是踩在功能上，而是踩在自己没关的那个默认值上。