想给手头的小工具接一个免费数据源，多数人的第一反应都是去 GitHub 搜一份「免费 API 清单」。搜来搜去，基本都会落到同一个仓库：public-apis。近 49 万 Star，2016 年建仓，十年攒下两千多条接口。我把它拷进隔离沙箱翻了一遍，也跑了它自带的检查工具，撞见一处很难忽略的矛盾——这个仓库给自己配了一套格式检查器（也就是专门挑毛病的自动脚本），而这套脚本在仓库自己的主文件上，已经连续红了快一年。
清单就是产品，写代码的地方只有 23 个文件
先说清楚它是个什么。public-apis 不是软件，你没法安装它、也没有一个程序在后台运行。它的全部产品就是一个 Markdown 文件（README.md），一本两千多行的接口黄页。你想找天气、汇率、星座、公开财报、机场信息，翻这本黄页，按分类找到对应的接口，点进它给的官方文档。
去掉版本历史，整个仓库只有 23 个被跟踪的文件。绝大多数是图片和说明文档，真正算「代码」的只有四样：
| 组成 | 数量 | 干什么的 |
|---|---|---|
| 主清单 README.md | 1 个，31.5 万字节、2679 行 | 就是那本黄页，52 个分类、2185 行表格条目 |
| 格式检查器 | 2 个脚本 | 检查每一条写得合不合规矩 |
| 自动检查的配置 | 3 个 | 让 GitHub 每次提交都自动跑一遍上面的脚本 |
| 脚本自测 | 2 个文件、31 条用例 | 验证检查器本身没写坏 |
所以它是一个「靠规矩维持的清单」。它给每条接口定了硬要求：分类内按字母排序、描述不超过 100 个字符、一次提交只能加一个链接、提交前先搜一遍有没有重复。这些规矩写在给贡献者的说明里，也写成脚本让机器执行。
这套机器分两层。上游是检查脚本，下游是 GitHub 的自动检查服务（CI，也就是每次有人提交代码，服务器自动跑一遍检查并把结果打回提交页）。过去十年，这个仓库的贡献者大多是路过的开发者，改一行加个链接就走。要维持两千条不出错，靠人盯是不现实的，只能靠机器。这是个很聪明的设计——省下的人工编辑，变成了两段脚本。
问题也恰好出在这里。
我跑了它的检查器：624 条报错，91% 跟清单内容无关
在沙箱里，我照着它的配置跑了一遍格式检查，结果是退出码 1，也就是「不通过」：全文件报出 624 条错误，分布在 129 行上。
六百多条听起来很吓人。但我把这 624 条按「报错落在文件的哪一段」摊开之后，结论完全变了：
| 报错落在哪 | 条数 | 占比 | 是什么 |
|---|---|---|---|
| 表格分隔行的写法 | 507 | 81% | 机器没跟上清单的新写法 |
| 表头行、MCP 段、赞助段的表结构 | 62 | 10% | 机器只认一种表格 |
| 主清单的条目行 | 55 | 9% | 这才是清单正文 |
624 条里，只有 55 条落在清单正文上（9%）；其余 569 条（91%）是检查器与清单格式演进之间的脱节。那 55 条也不是都白报——里面 30 条是「分类没按字母序」，真正要改条目文字的只有 25 条：12 条描述写超了 100 字上限，剩下是标题、标点、单元格空格这类小毛病，摊在两千多条里，属于正常磨损。
最能说明问题的是那 507 条，也就是占比八成的最大一块。Markdown 表格的分隔行有两种合法写法：|---| 和 |:---|（后者表示文字靠左排，渲染出来更整齐）。这个仓库近年把分隔行统一改成了带冒号的写法，而检查脚本里负责「跳过分隔行」的那一行判断，认的还是老写法。于是整整 47 行分隔行被当成了数据行去检查，每一行都报 5 条错，507 条错误就这么攒出来了。
中间那 62 条同理：仓库后来加了两张结构不同的表——放 MCP（简称，全称 Model Context Protocol，也就是让 AI 助手直接调用外部工具的一套通用接法）服务器的那张有五列（传输方式、安装入口），开头 APILayer 赞助区那张只有三列——而检查脚本只会按五列的规格去量每张表，量不了的就一路报错。
我做了个对照实验：只把 47 行分隔行改回老写法，其余一个字都不动，再跑一遍检查，报错从 624 条掉到 117 条，一下少了 81%。
顺便说一句，这不是检查器坏了。同一天我跑了它自带的单元测试——31 条全过。也就是说，工具本身的逻辑是好的，只是它对接的清单先演进了一步，脚本没跟着更新。
更值得说的：这个红叉，挂了快一年
一个检查常年失败的项目，为什么没人管？我去看了它的运行记录。
结果是：在 GitHub 的自动检查页面上，这个格式检查在仓库主分支上已经找不到一次成功记录。我把能翻到的记录都拉了一遍——838 次由提交触发的运行，失败 838 次，成功 0 次。GitHub 只保留最近约一年的记录，最早一条失败可回溯到 2025 年 11 月 4 日，更早的已经查不到。
对比之下，同一个仓库的单元测试在那段时间里全绿。
按常理，一个仓库的自动检查挂了，提交就该被拦住。但这里没有。我抽查了最近三个被合并的贡献（编号 #8000、#7999、#7998），合并的那一刻，检查结果全是红叉——红叉并没有挡住任何人。
原因不难猜：这两条检查被设成了「参考」，而不是「必须通过」。对维护者来说，红叉早就成了一种背景噪音，大家心照不宣地绕过去。
这就是整件事最有意思的地方：一套为了「用机器代替人工编辑」而写的检查器，最后变成了一个所有人都在忽略的摆设。它没有失效——它还在每天准点运行，还在输出结果——只是输出了快一年，没人再读。
它还值得用吗？值，但要会用
评价这类清单项目，得把「清单」和「清单的维护机器」分开看。
清单本身依然好用。两千多条里真正有问题的只有二十几条，不到 1.5%。按分类翻找、看有没有认证要求、支不支持 HTTPS 和跨域调用，这些列都在，省下的摸索时间是真的。它也是这套玩法的鼻祖——今天满大街的「Awesome 某某」清单，多半参考过它的表格格式和贡献规矩。
但它是「索引」，不是「保证」。清单只负责告诉你「有这个接口」，接口能不能用、要不要付费、限额多少，它一概不管。链接失效由另一个每天定时跑的脚本负责扫，和上面那个格式检查是两回事。
适合谁：想快速找一批候选数据源、做原型、写 Demo 的开发者；做技术选型时想先看全景的人。
不适合谁：想要「拿来就能上线」的稳定数据源的人——黄页只给电话簿，不保证对方一定接电话。用它找入口，用之前一定自己打一次。
顺着这个思路，站内还有几篇同样「把清单和证据分开看」的评测可以对照：想看成批技能的横评，可以翻 实测 12 款大模型能力增强 Skills；想看清单类内容怎么挑，可以翻 2026 年 8 月最热门 AI Skill 精选；关心成本和额度怎么算的，实测 9 款 Token 节省工具 那篇更直接。
结论：放进你的收藏夹，别放进你的依赖清单。它当好一本地图就够了，指路是它的本分，走路还得你自己迈腿。至于那个挂了快一年的红叉——它真正提醒的是另一件事：任何靠机器执行、靠人忽略的检查，最后都会变成没人读的噪音；检查要么能拦住发布，要么迟早沦为装饰。
关注 AI商业快讯，每天一篇 AI 热点深度解读。
