1. 問網站名字，AI 卻幫它創造漫畫角色
有個小網站持續用 AI 製作文章，內容包括拿《吉伊卡哇》角色比喻個性，以及分析小八貓（Hachiware）。有人拿網站形象的名字去問另一個 AI，對方卻問：「你說的是《吉伊卡哇》裡那個『麻煩的小八貓』嗎？」
等一下，那位到底是誰啦？
原創的網站形象就這樣被調去別人的作品上班。沒有履歷、沒有面試，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 也不是保證可以免費使用的容量。
如果儲存庫太大或操作太密集，影響平台效能，GitHub 可能要求改善。所以「超過 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；反過來，Git 儲存庫低於 5GB，也不代表其他額度足夠。
7. 為什麼儲存庫可能比文章數更快變胖
Git 除了目前的檔案，也保留修改歷史。每小時重新產生一次大型索引，即使最新版本看起來只有一份，舊版仍可能留在歷史紀錄。再加上修稿、重做翻譯、加入檢查結果、重複儲存產物，容量就不會跟文章數同步成長。
但 Git 會壓縮資料，也能有效保存相似版本。修改一次不代表容量一定翻倍。 主要原因仍須實際檢查。
需要追蹤版本的原稿與程式適合留在 Git；不斷重新產生的資料與大型媒體檔，則可依情況放到 Git 之外的儲存空間。
8. 可能先出事的不是容量，而是多人同時修改
多個 AI 幾乎同時寫入同一份資料，容易互相衝突。一項修正成功，另一項工作卻還拿著過期的發佈清單；文章完成了，正式網站仍顯示舊版。
不能一出事就說是「GitHub 放滿了」。檔案大小、修改頻率、同時寫入和發佈一致性，是不同問題。
檢查順序可以是：最新版原稿在不在？檢查通過了嗎？部署成功了嗎？正式網頁真的顯示新內容嗎？等第四關過了，再替「修復完成！」的報告鼓掌。
9. 讓免費運作更持久的四件事
先量測，別急著刪。 除了總容量，還要查看大檔案與歷史紀錄。GitHub 也介紹了 git-sizer 這類分析工具。
把一次性產物放在適當位置。 大量自動產生的清單、暫時的執行紀錄、圖片與音訊，不一定要全部永久留在 Git 裡。
降低沒必要的重寫。 無關的小修改，不應讓整份大型共用清單重做。遇到衝突先重新讀取目前狀態，再確認真正完成的結果。
不要隨便改寫歷史。 從最新版本刪除檔案，過去的提交紀錄可能仍有副本。改寫歷史可能破壞共同編輯者的參照，必須先備份與評估影響。
10. 比文章數重要的，是讀者真正讀到什麼
幾千篇原稿、幾萬個翻譯頁面，並不會自動換來讀者。能搜尋到嗎？資訊正確嗎？各語言自然嗎？是不是只是一直換句話說？
Google 官方建議重視對讀者有幫助、具有原創價值的內容，也反對主要為操弄搜尋排名而大量製作低價值頁面。問題不是「用了 AI」，而是大量生產卻沒有提供價值。
至於被 AI 自行創造出來的「麻煩小八貓」，那是提醒我們：好笑的 AI 回答可以當笑話，不能直接當官方設定。
文章工廠：「我要增加文章。」
GitHub：「那我增加歷史版本。」
檢查員：「我負責減少錯誤。」
搜尋 AI：「我再增加一個角色！」
大家：「這個不用增加！」
最後：5GB 不是 GitHub 免費方案的收費牆。容量、上線結果、內容品質與 AI 誤判，都要分開檢查。真正的成果不是儲存了多少資料，而是有多少可靠內容送到了讀者面前。
