1. 问一个网站的名字，AI 却发明了漫画人物
有个小网站利用 AI 不断写文章，其中包括用《吉伊卡哇》（Chiikawa）里的角色比喻性格，以及分析哈奇喵（Hachiware）的文章。有人把网站形象的名字拿去问另一个 AI，得到的答案居然是：你说的是《吉伊卡哇》里的“麻烦哈奇喵”吗？
等等，这位哪来的？
网站原创形象忽然被安排进了别人的作品。没有简历，没有面试，AI 直接办理了入职手续。
已知事实只是：那个 AI 确实给出了这种回答。它是否读过相关文章、是否从名字产生联想，目前无法证明；也没有证据表明这种称呼是作品的官方角色。回答很流畅，不代表回答是真的。
2. 另一边，文章工厂每天都在忙
写初稿，改成容易阅读的文字，制作十二种完整语言版本，检查，发布，再通过搜索和社交渠道送到读者面前。一旦发布停住，就调查原因、修复、再次确认。
慢慢地，进度报告比文章还有戏剧性。
AI甲：“发布功能修好了。”
AI乙：“检查全部通过。”
AI丙：“发现另一种停止原因。”
主管：“再安排一个修理人员。”
读者：“你们是不是准备把进度报告出版成小说？”
笑归笑，关键区别不能忘：代码修好了，不等于线上页面已经恢复正常。 内容工厂也可能变成维修工厂。
3. “有 1,900 篇文章？”先问清楚数的是什么
“文章数量”往往混合了五种东西：
- 原创文章：不同主题或独立内容的原稿。
- 不同语言页面：同一篇文章的多语言版本。
- 完成但未发布：正在等待检查或上线的文章。
- 已发布页面：读者真正能打开的内容。
- 网站路径：还可能包括导航页、应用页面等。
假设有 1,000 篇原创文章，各自发布十二种语言，最多会形成 12,000 个语言页面，并不等于有 12,000 个独立观点。
某次系统记录显示共有 15,862 条网站路径，但这不是“15,862 篇日文原创文章”。面对“好像有 1,900 篇了”这种说法，必须先确定日期、统计单位和发布状态。不然统计表只会越来越壮观，意义却越来越模糊。
4. GitHub 仓库居然长到了约 2.46GB
一个匿名化案例的 GitHub 数据报告了 2,400,972KiB，约等于 2.29GiB，即十进制约 2.46GB。记录日期为 2026 年 10 月 8 日。
“文章不是文字吗？怎么这么大？”
因为仓库可能还有程序、翻译数据、发布索引、检查结果、图片、音频和历史版本。但只凭总容量无法确定谁占了多少，要进一步检查才能知道。GitHub 报告的数字，也不等于电脑上某个文件夹的实际大小。
文章：“我只有几 KB。”
历史记录：“你的旧版本我都留着。”
翻译：“我们另外来了十一个。”
仓库：“你们到底带了多少行李？”
5. 结论：免费版并不是“仓库总共 5GB，超过就收费”
GitHub 没有为普通 Git 仓库公布一个适用于免费版的统一“总共几 GB，超过自动收费”门槛。5GB 是强烈建议的仓库大小，不是收费起点。
官方建议仓库最好小于 1GB，并强烈建议小于 5GB。另一份限制文档将压缩后的 Git 历史数据的磁盘占用建议上限设为 10GB。这也不代表承诺免费提供 10GB。
如果仓库体积或操作负担过大，平台可能要求改善。于是“超过 5GB 就付费”和“免费就能无限存”都不准确。没有统一收费线，不等于可以无成本、无限制地占用资源。
6. 不同容量限制分属不同项目
| 项目 | 限制或免费额度 |
|---|---|
| 普通 Git 仓库整体 | 没有统一的免费总 GB 收费线；理想小于 1GB，强烈建议小于 5GB |
| Git 历史数据的磁盘大小 | 建议不超过 10GB，不是收费门槛 |
| 单个普通文件 | 超过 50MiB 提示警告，超过 100MiB 被拒绝；浏览器上传最多 25MiB |
| 单次推送 | 2GiB 限制 |
| Git LFS 大文件服务 | 免费版包含 10GiB 存储和 10GiB 传输额度，与普通 Git 分开 |
| GitHub Actions 运行产物 | 免费版包含 500MB 产物存储，以及通常每月 2,000 分钟的执行额度 |
这些不是同一个容量账户。 Git LFS、Actions 等超额后的收费或停止行为取决于各自的规则和预算设置。普通仓库有 2.46GB，不等于已经耗尽 Actions 的 500MB；普通仓库低于 5GB，也不保证其他额度没用完。
7. 为什么仓库增长速度可能超过文章数量
Git 不只保存现在的文件，还保存变化过程。一个巨大的目录索引每小时重新生成，最新版看起来仍只有一个文件，旧版本却可能留在历史里。文章修订、翻译更新、检查记录和重复产物叠加以后，空间增长不会与文章数量严格同步。
但 Git 也会压缩并高效保存相似内容。修改一次不代表体积必然翻倍。 真正占空间的部分必须检查。
有长期维护价值的原稿和代码适合放在 Git；频繁再生成的产物、巨大的媒体文件可以考虑放在仓库以外的存储系统。
8. 先出问题的可能不是容量，而是并发写入
多个 AI 同时修改同一份数据，可能发生冲突。一个修复成功，另一个任务还在使用过期的发布清单；文章已经准备好，网站却仍显示旧版本。
不要一出错就断言“GitHub 满了”。文件大小、修改频率、同时写入和发布状态是不同问题。
可以依次确认：最新原稿是否存在；是否通过检查；是否真正部署；公开页面是否显示对应的新内容。等第四步成立，再为“修复完成”的长篇报告鼓掌。
9. 免费长期运行的四种维护方法
先测量再清理。 不只看仓库总容量，还要检查大文件和历史记录。GitHub 官方也介绍了 git-sizer 这类分析工具。
把一次性产物放对地方。 大型自动生成清单、临时运行记录、图片和音频不必全部永久留在 Git 历史中。
减少无意义的重写。 一处无关的调整不应引发整个巨大索引的重新生成。遇到冲突时先读取最新状态，再验证实际结果。
不要随意重写历史。 删除最新版中的文件，不一定能清除旧提交中的内容。修改历史可能破坏协作者的引用和副本，需要先备份并评估影响。
10. 比文章数量更重要的是读者能得到什么
数千篇原稿和数万个翻译页面，不会自动带来读者。页面能被找到吗？事实准确吗？翻译自然吗？是不是只在换一种说法重复已有内容？
Google 的公开指南强调对读者有帮助、有独创价值的内容，并反对主要为操纵搜索排名而大量制造缺乏价值的页面。问题不在于用了 AI，而在于大量生产的页面没有真正帮助读者。
至于那个被 AI 擅自命名的“麻烦哈奇喵”，它提醒我们：有趣的 AI 回答可以当笑话，不能直接当作品设定。
文章工厂：“我要增加文章。”
GitHub：“我来增加历史版本。”
检查员：“我来减少错误。”
搜索 AI：“那我增加一个角色！”
众人：“这个不用增加！”
总结：5GB 不是 GitHub 免费版的收费墙。容量、发布结果、文章质量和 AI 误判应分别检查。真正的成绩不是保存了多少文件，而是多少可靠内容最终送达读者。
