扫描13个热门AI应用脚手架，6个存在同一生产级Bug

我为流行的 AI 应用启动仓库做了一次小范围的确定性扫描，检测那些不会让 demo 停下来、但会在生产环境里把你坑惨的失败模式。

然后我把它对准了一组流行的开源启动模板和 AI 应用仓库的语料库——因为大量" vibe-coded"项目实际上就是基于这些仓库构建的。如果这个失败是框架发给用户的默认值，那它就应该会出现在维护良好、星标众多的仓库里。

测量时间：2026-09-16，使用 vibecheck——一个针对 AI 构建应用的生产失败模式的确定性静态分析器。

语料库：13 个流行的开源启动/应用仓库（浅克隆，默认分支）。

有一个仓库被排除在逐项目统计之外：Anil-matcha/awesome-generative-ai-apps 是一个包含多个子项目的目录，因此其计数无法与单个应用进行比较。

扫描器：vibecheck.py（仅用标准库、确定性、无网络、默认跳过 test/fixture 路径）。在发布时的代码树上运行，未做任何修改。

13 个仓库中有 4 个扫描结果干净（31%）。

其余仓库共发现 101 个问题：50 个严重、18 个高危、33 个中危。

仅这一个被排除的目录仓库就产生了另外 269 个发现——这提示了当大量小型 AI 构建项目组合在一起时会积累什么问题。

失败的实际形态

逐仓库结果（匿名化）

项目已做匿名化处理：计数是静态分析输出，模式只是进一步排查的线索，而非可利用性的证明。在未经核实的数据上点名具体项目对维护者不公平，因此上面的汇总表和规则表携带了发现结果，原始数据保留供验证。

静态分析。它报告模式，模式只是进一步排查的线索，而非可利用性的证明。有些被标记的路由可能是故意公开的。

这些仓库都是热门、维护良好的项目——这意味着这些模式在维护者称职且代码公开可见的情况下依然存在。这正是关键所在：失败在于框架或生成器发给你的那个默认值。

"干净"意味着"这些规则没有发现"，而非"安全"。

原始逐仓库 JSON：results.jsonl。用 python3 scan_corpus.py 复现。

如果你想在继续阅读之前在自己项目上跑一下，它是免费开源的：vibechecksai/vibecheck。零依赖，仅用标准库，大约一秒跑完。

我一直在回想的一件事：这些都不是什么稀奇的 bug。它们就是那种无聊的"我稍后再修"的默认值——未鉴权的路由、带公开前缀的密钥、未转义的 HTML。AI 写出了能用的那 80%。剩下那 20% 是没人会主动提示的部分。