写了个命令行工具:写代码前先搜一遍开源方案,顺便打个分(MCP Server)

skyzt 2026-09-07 10:43 1

最近在用 Claude Code 的时候注意到一个现象:让它实现一个功能,比如限流中间件,它会立刻开始写代码。一个 Map 加时间戳的玩具实现,转眼就出来了。但它不会提 express-rate-limit 已经存在了,3.3k star ,MIT 协议,接入只要 30 秒。


我自己也差不多,业务一赶,第一反应从来不是"先搜搜有没有现成的"。


GitHub 全站 star 排名前几名,build-your-own-x 、awesome 、public-apis ,加起来一百多万 star ,全是在教人"先找现成的"。但真正在动手之前去查一遍的流程,一直没有被工具化——尤其是对 AI Agent 来说。


所以写了个东西,叫 wheel-hub:



  • GitHub: https://github.com/skyzhao1223/wheel-hub

  • npm: @wheel-hub/mcp ( MCP Server )、 @wheel-hub/cli (命令行)


它做什么


三个能力:



  1. 按功能关键词搜索 GitHub 现成方案

  2. 给单个仓库打 0-100 分,附结论

  3. 同类方案横向对比,排出推荐


打分逻辑是四个维度加权:



  • Popularity ( 30%):star 数量级,对数尺度

  • Momentum ( 25%):日均涨星 + 最近提交时间

  • Maintenance ( 30%):提交新鲜度 + issue 积压率

  • Trust ( 15%):许可证宽松度、是否归档


结论分四档:>=75 建议直接用,>=55 可以改造用,>=35 值得看看,再低或者已归档就别碰。


举两个实际输出。ollama 打了 96 分( ADOPT )。比较有意思的是 torvalds/linux:24 万+ star 。有个细节:内核的 GPL-2.0 是通过 COPYING 文件声明的,GitHub 的自动识别没法把它归类成标准许可证( license 字段返回 NOASSERTION ),于是 Trust 维度如实只给了 20 分,总分 86 。引擎只认数据源,不看 star 脸色。


接入方式


MCP ( Claude Code 示例,其他客户端同理):


claude mcp add wheel-hub --env GITHUB_TOKEN=ghp_xxx -- npx -y @wheel-hub/mcp

不带 token 也能用,匿名 60 次/小时;带 GitHub token 是 5000 次/小时。


命令行:


npm i -g @wheel-hub/cli
wheel-hub find "SSO login" --lang typescript
wheel-hub evaluate ollama/ollama

实现上的一些细节


TypeScript monorepo ,三个包。打分引擎是零依赖纯函数:输入 GitHub 元数据,输出分数和理由数组。以后想接 npm 、PyPI 或者 OSSInsight 的历史数据,评分逻辑不用动。


写的过程中踩了几个坑,记一下:



  1. MCP 客户端只透传白名单环境变量,GITHUB_TOKEN 必须显式写进客户端配置的 env 里,否则 Server 会静默跑在匿名限流上,很隐蔽

  2. npm 的防 typosquatting 规则会拦截和已有包"过于相似"的名字,wheel-hub 这个名字就因为和已有的 wheelhub 包相似被拒了,最后 CLI 包用了 @wheel-hub/cli 、命令名保留 wheel-hub 的组合

  3. npm 新包发布后,公共 CDN 会有几分钟的 404 缓存窗口,第一次发布时容易误以为失败


现状


刚发 0.1.2 ,功能上还不完整。路线图里有几件事:挖 awesome 列表做第二数据源、接 OSSInsight 的 star 历史让增速评估更准、做一个依赖停止维护的提醒功能,以及给识别不出许可证的仓库加一层文件原文解析,减少误报。


欢迎试用,也欢迎拍砖——尤其是打分权重这块,popularity/momentum/maintenance/trust 的比例是我拍的,如果有更合理的定法希望聊聊。

最新回复 (1)
  • KingGaruda 09-07 12:16
    1
    写代码前先搜一遍开源方案。。怎么衡量 开源方案 和你代码实际需求的匹配度的? 你做这个工具的时候有借鉴什么开源方案么。
* 帖子来源V2EX
返回