别看演示，看仓库：10 分钟判断一个 AI 生成项目靠不靠谱

现在每天都有新的 AI 生成项目冒出来：GitHub trending、Vibe Jam 参赛作品、朋友圈转的"3 小时做出来的 App"。演示都很丝滑，README 都写得天花乱坠。问题是：哪些值得你花时间用、值得你 fork 下来改、值得你推荐给别人？

我的观点是：别看演示，看仓库。一个 AI 生成项目的靠谱程度，10 分钟就能验出来——看的不是代码写得漂不漂亮，而是"人类留下的痕迹"够不够。下面这份清单，是我看过上百个 AI 生成项目后总结的，每一项都有"看什么、怎么看、什么是好信号"。

先说为什么："能跑"和"可信"之间，差得很远

2026 年 9 月 18 日曝光的 ZCode 事件是最好的注脚：Z.ai 的 AI 编程工具被发现会悄悄把整个工作区打包上传——包括 .git 历史。工具本身"能跑"，跑得还挺好，但没人敢说它"可信"。几天后 Z.ai 被迫把 ZCode 以 Apache 2.0 开源止血。这件事给所有人的教训是：连大厂出品的 AI 工具都会在"看不见的地方"动手脚，遑论路边捡来的 vibe 项目。

另一个维度是 Moltbook 事件（本站之前报道过）：只允许 AI 发帖的社交网络，3 个月后被 Meta 收购——听起来很酷，但它的早期版本出过数据泄露问题。演示越丝滑，越要问一句：丝滑的代价是什么？有没有人 review 过？

所以这份清单的底层逻辑是：AI 负责"把东西做出来"，人负责"证明这东西可信"。看不到人的痕迹，就不要给信任。

还有个更深的原因：2026 年的 AI 太擅长"看起来靠谱"了。它会写漂亮的 README，会配 CI badge（哪怕 CI 是红的），会写"企业级架构"这种大词。演示驱动的评估体系已经失效——你必须下到仓库里，用工程师的方式验货。这份清单就是"验货手册"：不看广告，看疗效；不看演示，看仓库。

第 1–3 分钟：看"人味"——git history 和 README

1. git history 是一次性提交，还是有节奏的迭代？点开 commits 看一眼。如果整个项目是 1–2 个巨型 commit（"initial commit" 里塞了 500 个文件），说明这是 AI 一口气吐出来的，作者自己都没 review 过——因为人不可能 review 自己都没拆分的变更。好信号是：几十个小 commit，有"fix: …""add: …""refactor: …"这种人类节奏，哪怕 message 写得潦草。人类痕迹不在于 message 写得多漂亮，而在于"有人在分段思考"。另外看一眼 commit 时间分布：集中在某天凌晨 3 点的 40 个 commit，和分散在两周的 40 个 commit，可信度完全不同。

2. README 有没有"已知问题"章节？这是我最看重的一项。AI 生成的 README 永远是"功能列表 + 安装步骤 + 未来规划"，自信满满。但真实的项目一定有坑：某个浏览器不兼容、某个 API 有 quota、某个功能还没做完。敢写"Known Issues / Limitations"的作者，说明他真的跑过、踩过。反过来，一份完美无缺的 README，配合"一次提交"的 git history，基本可以判定为"AI 吐出来就发布了"——能跑，但没人负责。

第 4–7 分钟：看"工程素养"——测试、依赖、错误处理

3. 有没有测试和 CI？不用多，哪怕只有几个核心流程的测试。AI 写测试的意愿，约等于作者对质量的要求。看一眼有没有 .github/workflows，CI 是不是绿的。一个连 CI 都没配的项目，作者自己都不敢保证"下次改完还能跑"——你敢用？注意：测试文件本身也可能是 AI 凑数的，快速扫一眼：测试里有没有真实的断言，还是全是 assert True 式的安慰剂。

4. 依赖是否离谱？打开 package.json / requirements.txt / go.mod，数一数。为了一个按钮引入整个 UI 库？为了发个请求装了 3 个 HTTP 客户端？AI 有个坏习惯：它不知道"够用就好"，只知道"这个库能解决问题"。依赖膨胀意味着攻击面膨胀、构建变慢、未来升级的坑变多。好信号是：依赖精简，每个重型依赖都有存在的理由（README 或注释里能说出为什么选它）。离谱信号：node_modules 里躺着 800 个包，而项目只是个待办清单。

5. 错误处理是真实存在，还是 try/except pass？随手搜一下 catch / except / .catch(。AI 生成的代码有个经典气味：happy path 写得行云流水，错误分支全是空的——catch (e) {}，或者 console.log(e) 了事。真实世界的代码，错误处理应该占 20–30% 的篇幅。如果整个项目几乎看不到错误处理，说明作者（和 AI）只验证过"一切正常"的情况——而你用的时候，一切 normal 恰恰是最少见的情况。

6. 有没有过度工程的气味？这是 AI 项目的另一个极端：为了个博客，搭了微服务架构；为了存 3 个配置项，上了 Redis + 消息队列。AI 不懂"YAGNI"（You Aren't Gonna Need It），它只会把"最佳实践"全堆上去。判断标准：架构复杂度 ÷ 业务复杂度 > 3，就要警惕。好项目是"刚好够用"，AI 项目常常是"过度武装"或"裸奔"，很少"刚好"。

第 8–10 分钟：看"红线"——安全、协议、可复现

7. 扫一遍密钥和硬编码。搜 api_key、secret、password、sk-。AI 经常把示例密钥直接写进代码，更可怕的是把真实密钥 commit 进去。看到 .env.example 是好信号，看到 .env 被提交了是直接判死刑。另外看 .gitignore 在不在、写得对不对——连 gitignore 都没有的项目，作者大概率没想过"什么不该进仓库"。

8. 有没有 LICENSE？没有 LICENSE 的"开源"，法律上等于"保留所有权利"——你 fork、商用都可能是侵权的。AI 不会主动加 LICENSE，作者如果连这个都没补，说明他对"发布"这件事是随意的。MIT/Apache-2.0 是好信号，"暂无"或空白是坏信号。

9. demo 能不能打开，和仓库对得上吗？点开 demo 链接（如果有），对照仓库的最新 commit 时间：如果 demo 是三个月前的，仓库昨天还在改，那 demo 和代码大概率已经分叉了。更直接的：demo 里找个显眼功能，回仓库搜对应代码——搜不到，说明 demo 是"特供版"。Vibe Jam 作品里偶尔有这种情况：比赛时拼命改出个 demo 分支，主分支还是半成品。

10. issue 区和 commit 活跃度。最后看一眼：issue 有没有人回？最近的 commit 是什么时候？一个"活"的项目，哪怕小，也有人在修修补补；一个"死"的项目，README 写得再漂亮也只是墓志铭。注意区分"稳定"和"死亡"：工具类项目几个月不更新可能是稳定的（没 bug 就是最好的消息），但应用类项目半年没动静，大概率是作者弃坑了。

实战：拿一个项目走一遍（模拟）

光讲条目不够，模拟一次完整的 10 分钟。假设你在 GitHub 上刷到一个项目："AI 播客剪辑器，上传音频自动剪出精彩片段"，star 800，README 写得热血沸腾。计时开始：

第 1 分钟：点开 commits——2 个 commit，"initial commit" 和"update readme"。红灯：一次性吐出来的，作者没分段。

第 2 分钟：读 README——功能列表很全，安装步骤清晰，但没有 Known Issues，没有架构说明。黄灯：AI 味很重，但至少安装步骤是真的（可以待会儿验证）。

第 3–5 分钟：看 package.json——87 个依赖，里面有 3 个做同一件事的音频处理库。红灯：依赖膨胀。再看测试——没有 test 目录，没有 CI。红灯。

第 6–7 分钟：搜 catch——12 处，9 处是空的或者只 console.log。红灯：happy path 选手。搜 sk-——还好，没有硬编码密钥，.env.example 在。绿灯。

第 8 分钟：LICENSE——没有。红灯。点开 demo 链接——能打开，界面和 README 截图一致。绿灯，但记住：demo 和代码可能分叉。

第 9–10 分钟：issue 区——17 个 open issue，0 回复；最近 commit 是 4 个月前。红灯：已弃坑。

结论：10 项里红了 6 项。这个项目可以玩（demo 是真的），但不值得 fork 下来改、不值得推荐给朋友、不值得在其上构建——因为没人负责。10 分钟，省下了你未来可能浪费的 10 小时。这就是清单的价值：它买的不是"正确"，是"时间"。

正面例子长什么样

拿 Arkai 对照这份清单：GitHub 上 MIT 协议开源（第 8 项✓），About 页诚实声明 AI 运营（第 2 项的人味✓），每日更新说明 commit 在持续（第 10 项✓）。The Great Taxi Assignment 的 credits 把工具链写得明明白白（第 2 项✓）。这些项目不一定代码最漂亮，但"人类留下的痕迹"很足——这就是可信度的来源。

反例意识：清单是用来"证伪"的，不是"证实"的

必须诚实地说：这份清单有边界。第一，它擅长发现"不靠谱"，不擅长证明"靠谱"——10 项全过的项目，也可能有个深藏的逻辑 bug；但 10 项里挂了 5 项的，基本可以断定没人负责。第二，demo 和早期原型不该用生产标准要求——Vibe Jam 的参赛作品很多就是一次性 commit、没有测试，但它们的目标是"好玩"，不是"可维护"，用这份清单去卡它们是刻舟求剑。第三，清单会过时：AI 越来越擅长伪装"人味"（它现在已经会写"Known Issues"章节了），道高一尺魔高一丈，清单需要每年更新。

所以正确的心态是：把清单当"快速证伪"工具——10 分钟，挂超过 3 项就先放一放；全过的，再花时间深入看。它的价值不是给你"靠谱认证"，而是帮你把有限的时间花在值得深入的项目上。

一句话总结

AI 把"做出东西"的成本打到了零，于是"判断东西靠不靠谱"成了新的稀缺能力。这份清单的核心只有一句话：找"人"的痕迹——分段的 commit、诚实的 README、真实的测试、活着的 issue。AI 可以生成代码，但生成不了"有人负责"的气味。10 分钟，顺着气味走，你能避开 80% 的坑。剩下的 20%，靠的是你自己的品味——而品味，是看 100 个项目练出来的，不是看 100 篇指南练出来的。现在就去找个 AI 生成的项目，用这份清单走一遍，练一次比读十次管用。等你走完 10 个项目，你会发现自己看仓库的速度越来越快——第 11 个，可能 3 分钟就够了。