二十八万颗星，六成五来自一个微软项目
二十八万颗星，六成五来自一个微软项目
GitHub 新晋 AI 项目周榜 · 2026 年 9 月 14 日 — 9 月 20 日
本期五个仓库合计 282,974 颗星。这个数字看着吓人，但它是被一个项目撑起来的：第一名 markitdown 单独拿了 185,100 颗，占六成五。
剩下四个加起来 97,874 颗。所以这期的正确读法是：把第一名当成一个现象看，把后四名当成可以用的东西看。
本期速览
| # | 项目 | 它是什么 | 星数 |
|---|---|---|---|
| 1 | markitdown | 把任何文件转成 Markdown 喂模型 | +185,100 |
| 2 | colibri | 纯 C 单文件引擎，在磁盘上跑万亿参数 | +35,603 |
| 3 | tinycast | 一个快捷键装下四个 macOS 小工具 | +22,101 |
| 4 | open-code-review | 阿里内部用了两年的 AI 代码审查 | +21,240 |
| 5 | WeKnora | 腾讯开源的文档理解框架 | +18,930 |
本周三个信号
一、五个里三个是大厂，而且都不是 demo。
微软的 markitdown、阿里的 open-code-review、腾讯的 WeKnora。阿里那个在内部沉淀了两年才开源，腾讯那个直接标了「企业级、可私有化部署」。开源对大厂来说早不是善意，是渠道。
二、剩下两个走反方向：一个文件，一个快捷键。
colibri 是纯 C 写的单文件推理引擎，依赖压到最少；tinycast 把启动器、剪贴板、计算器、窗口管理塞进一个快捷键，常驻内存压在 100MB 以内。大厂拼工程厚度，独立作者拼「你能一眼看完」。
三、同一张榜，装起来的难度差三个量级。
markitdown 一行 pip，colibri 要自己编译，tinycast 要求 macOS 26 以上。星数高的往往最好装，因为好装本身就是它星数高的原因之一——所以别看见数字大就默认适合自己。
1. markitdown：把任何文件变成能喂给模型的 Markdown
做检索或者喂资料给模型的人，一半时间花在格式上。PDF 里的表格、PPT 的排版、Word 的标题层级，抄进提示词就全散了。
markitdown 干的就是这一步：PDF、PPT、Word、Excel、图片、音频，甚至一个 YouTube 链接，全转成 Markdown。一行 pip 装，一条命令转，输出就是一个 md 文件。
它不聪明，但它把脏活标准化了。这类工具的价值在稳定——你不需要它每次都对，你需要它每次都一样。
要点
- 格式覆盖最全：PDF、PPT、Word、图片、音频
- YouTube 链接直接吃字幕，不用先下载
- 一行命令，没有配置文件要改
代价：转换质量完全取决于原文件。扫描版 PDF 出来是空白，图片里的字要看 OCR 有没有接对。它是转换器不是理解器，别指望它把一张复杂表格还原成结构。
上手
pip install markitdown
markitdown report.pdf > out.md
2. colibri：把万亿参数的专家放磁盘上，用哪个加载哪个
本地跑大模型的瓶颈一直是显存。主流做法是压模型，colibri 换了个思路：不压，改存哪儿。
它把 MoE 的专家放在磁盘上，按需流式加载，于是万亿参数也能在自己机器上跑起来。纯 C 写的单文件引擎，依赖极少。作者强调量化过程可测、结果可复现，不会为了跑得快偷偷改精度，仓库里有完整的解码速度表格和各平台快速开始文档。
「单文件 + 纯 C」是个立场：让模型推理这件事回到一个人能读完的代码量。现在这个领域动辄几千个文件，能把核心装进一页纸的项目越来越少。
要点
- 纯 C 单文件引擎，依赖极少
- 专家放磁盘按需流式加载，显存不再是上限
- 量化可测、结果可复现，附解码速度表
代价：用磁盘换显存，代价落在速度上——瓶颈从显存挪到了硬盘，机械盘基本别想。装也不轻松，得自己编译，没有 pip 那条路。
上手
./colibri -m trillion-moe -p "hello"
3. tinycast：一个快捷键，装下四个小工具
启动器、剪贴板历史、计算器、窗口管理，通常要装四个 App。四个都常驻，四个都在偷内存，四个都有自己的快捷键要记。
tinycast 把它们塞进一个快捷键，常驻内存压在 100MB 以内。对一个天天开着的东西来说，这个数字比功能表重要。
这类工具没有护城河，只有手感和资源占用。谁的常驻内存少一半，谁就赢，功能抄起来太容易了。
要点
- 一个快捷键，启动器、剪贴板、计算器全在里面
- 常驻内存控制在 100MB 以内
- 比装四个独立工具干净，不抢快捷键
代价：要求 macOS 26 以上，老系统直接用不了。这条会筛掉不少机器，也说明作者是奔着新 API 去的，不做兼容。
上手
brew install --cask tinycast
4. open-code-review：阿里内部用了两年的代码审查，开源了
代码审查类 AI 工具的通病是「评分玄学」：它说你这段有问题，你问为什么，它给你一段更玄学的解释。
阿里这套走的是「确定性工程 × Agent」：能确定的规则用工程手段钉死，Agent 只负责不确定的部分，所以结果是可复现的。仓库自带 ACR 评测集，可以直接拿自己的仓库跑一遍对分。
从真实用了两年的内部系统里带出来的东西，和从 demo 长出来的东西，差别就在评测集上。前者必须证明自己有效，后者只需要看起来有效。
要点
- 内部实践两年，不是演示项目
- 确定性工程配 Agent，结果可复现
- 自带 ACR 评测集，能用自己的仓库验
代价：确定性的另一面是覆盖窄。工程规则管得住格式、命名、常见缺陷，管不住业务逻辑——这几类问题它要么漏，要么按规则误报。它更像一个严格的资深工程师，不是全知的。
上手
ocr review --repo . --base main
5. WeKnora：把公司文档变成一个能推理的知识库
企业搭知识库，最烦的从来不是模型，是地基：文档怎么切块、向量库选哪个、权限怎么控、IM 怎么接。每一件都要试错。
腾讯这个把 RAG、Agent、知识库三件事做在一起，可完全私有化部署，数据不出内网。向量库是可插拔的，从 pgvector 到 Milvus 都能换；模型接入、IM 通道、权限也都是配置项。
它的卖点不是效果最好，是「不用从零搭地基」。对要自建知识库的团队，省下的不是钱，是排期。
要点
- RAG、Agent、知识库三位一体
- 向量库从 pgvector 到 Milvus 可插拔
- 支持私有化部署，数据不出内网
代价：可插拔的反面是配置项多。docker compose 能把服务起来，但要调到能用，得先搞清它这套切块假设和权限模型——企业级框架的复杂度不会消失，只会换个地方出现。
上手
docker compose up -d weknora
最后
六成五的星来自一个微软的格式转换工具。剩下四个才是这期需要人筛的部分：一个大厂把内部系统开源，一个大厂交出知识库地基，一个用磁盘换显存，一个用一个快捷键干掉四个 App。
下周继续筛。
—— Oraink
星数为仓库创建至今的累计数；因这五个仓库都是本周新建，等同于创建以来累计。本期表格按星数从高到低排列，合计 282,974。数据抓取于 2026-09-24。
浙公网安备 33010602011771号