1. Hỏi tên linh vật của trang web, AI lại sáng tạo một nhân vật
Một trang web nhỏ liên tục đăng bài nhờ AI. Có bài so sánh tính cách với nhân vật trong Chiikawa, đặc biệt là Hachiware. Khi người ta hỏi một AI khác về linh vật của trang web, nó lại gợi ý đó là một nhân vật “Hachiware phiền phức” trong bộ truyện.
Khoan đã, người này ở đâu ra vậy?
Linh vật riêng của trang web bỗng được tuyển vào tác phẩm của người khác. Không hồ sơ, không phỏng vấn, AI tự ý ký quyết định nhận việc.
Điều xác nhận được chỉ là AI đã trả lời như thế. Chưa có bằng chứng nó thật sự đọc các bài liên quan, suy luận từ tên hay đơn giản là tự nghĩ ra. Cũng không có cơ sở ở đây để nói nhân vật ấy thuộc cốt truyện chính thức. AI nói tự tin không có nghĩa là AI nói đúng.
2. Trong khi đó, xưởng bài viết vẫn miệt mài hoạt động
Quy trình viết bài, chỉnh cho dễ đọc, tạo bản đầy đủ bằng mười hai ngôn ngữ, kiểm tra, xuất bản rồi chia sẻ đường dẫn. Khi có trục trặc, một công đoạn khác tìm nguyên nhân, sửa và kiểm tra lại.
Các bản báo cáo tiến độ dần trở thành phim dài tập.
AI A: “Đã sửa lỗi xuất bản.”
AI B: “Mọi bước kiểm tra đều đạt.”
AI C: “Tìm thấy nguyên nhân dừng mới.”
Quản lý: “Gọi thêm người sửa đi.”
Độc giả: “Chắc báo cáo tiến độ sắp dài hơn cả bài viết rồi!”
Điểm đáng nhớ là lưu một bản sửa không đồng nghĩa trang công khai đã chạy đúng. Xưởng sản xuất nội dung đôi khi còn phải làm cả xưởng sửa chữa.
3. “Đã có 1.900 bài?” Cần hiểu cách đếm trước
Có ít nhất năm con số dễ bị gọi chung là “số bài viết”:
- Bài gốc: nội dung có chủ đề riêng.
- Trang theo ngôn ngữ: các bản dịch của cùng một bài.
- Đã viết nhưng chưa đăng: đang chờ kiểm tra hoặc xuất bản.
- Đã đăng: nội dung người đọc mở được.
- Đường dẫn của trang: có thể bao gồm mục lục, ứng dụng và các trang không phải bài viết.
Ví dụ, 1.000 bài gốc được xuất bản đầy đủ bằng mười hai ngôn ngữ sẽ tạo ra tối đa 12.000 trang theo ngôn ngữ. Không có nghĩa là có 12.000 ý tưởng độc lập.
Một bản ghi vận hành cho thấy 15.862 đường dẫn trang. Đó không phải là 15.862 bài gốc tiếng Nhật. Khi nghe “khoảng 1.900 bài”, cần hỏi ngày thống kê, đơn vị và trạng thái xuất bản. Nếu cộng bừa các số, người làm báo cáo sẽ muốn bỏ nghề.
4. Kho GitHub đã đạt khoảng 2,46 GB
Trong một trường hợp đã ẩn danh, GitHub ghi nhận 2.400.972 KiB, tương đương khoảng 2,29 GiB hay 2,46 GB theo hệ thập phân, tại thời điểm ngày 8 tháng 10 năm 2026.
“Bài viết chỉ là chữ, sao lại nặng thế?”
Kho còn có thể chứa chương trình, dữ liệu dịch, danh sách xuất bản, kết quả kiểm tra, hình, âm thanh và lịch sử thay đổi. Tuy nhiên, tổng dung lượng không cho biết phần nào chiếm nhiều chỗ nhất. Phải phân tích riêng mới kết luận được. Số GitHub báo cũng không nhất thiết bằng kích thước thư mục trên máy.
Bài viết: “Tôi chỉ vài KB thôi.”
Lịch sử: “Tôi giữ cả bản cũ nữa.”
Bản dịch: “Tôi dẫn thêm mười một bạn tới.”
Kho: “Sao không báo trước cho tôi?”
5. Kết luận: GitHub Free không phải “tổng cộng 5 GB rồi tính tiền”
GitHub không công bố một hạn mức tổng GB miễn phí duy nhất cho mọi kho Git thông thường, vượt qua là tự động thu phí. Mốc 5 GB là khuyến nghị về kích thước, không phải mốc bắt đầu tính tiền.
Tài liệu chính thức cho rằng dưới 1 GB là lý tưởng và rất khuyến nghị dưới 5 GB. Một tài liệu giới hạn khác khuyến nghị dữ liệu Git đã nén không vượt 10 GB trên ổ đĩa. Mốc 10 GB cũng không phải cam kết cấp miễn phí chừng ấy dung lượng.
Nếu kho gây ảnh hưởng đáng kể đến hạ tầng, GitHub có thể yêu cầu điều chỉnh. Vì thế “vượt 5 GB là trả tiền” sai, nhưng “miễn phí nghĩa là kho vô hạn” cũng sai.
6. Các hạn mức thật nằm ở những ngăn riêng
| Hạng mục | Giới hạn hoặc mức miễn phí |
|---|---|
| Toàn bộ kho Git thường | Không có một mốc tính phí tổng GB chung; lý tưởng dưới 1 GB, rất khuyến nghị dưới 5 GB |
| Dữ liệu Git trên đĩa | Tối đa khuyến nghị 10 GB, không phải mốc thu phí |
| Một tệp thông thường | Cảnh báo khi vượt 50 MiB, chặn khi vượt 100 MiB; tải lên bằng trình duyệt tối đa 25 MiB |
| Một lần đẩy thay đổi | Giới hạn 2 GiB |
| Git LFS cho tệp lớn | GitHub Free gồm 10 GiB lưu trữ và 10 GiB truyền dữ liệu, tách khỏi Git thường |
| Kết quả chạy GitHub Actions | Gói Free gồm 500 MB lưu kết quả và thông thường 2.000 phút chạy mỗi tháng |
Không thể cộng những hạn mức này vào cùng một ví. Khi Git LFS, Actions hoặc dịch vụ khác dùng quá phần miễn phí, cách tính tiền hay dừng sử dụng tùy quy tắc và ngân sách từng dịch vụ. Kho Git thường 2,46 GB không tự động dùng hết 500 MB của Actions. Ngược lại, Git dưới 5 GB không đảm bảo các hạn mức khác còn dư.
7. Vì sao kho phình nhanh hơn số bài mới
Git lưu cả tệp hiện tại lẫn lịch sử chỉnh sửa. Một danh mục lớn được viết lại mỗi giờ có thể vẫn chỉ hiện một tệp trong bản mới nhất, nhưng các bản cũ có thể tiếp tục nằm trong lịch sử. Sửa bài, làm lại bản dịch, ghi kết quả kiểm tra và lưu đầu ra lặp lại khiến dung lượng không tăng đúng theo số bài.
Dù vậy, Git có cơ chế nén và lưu các phiên bản tương tự khá hiệu quả. Một lần chỉnh sửa không có nghĩa dung lượng chắc chắn tăng gấp đôi. Cần đo để tìm phần chiếm chỗ thật.
Bản gốc và mã chương trình đáng giữ trong Git khi cần theo dõi thay đổi. Các đầu ra thường xuyên tạo lại hay tệp đa phương tiện lớn có thể phù hợp hơn với chỗ lưu khác.
8. Xung đột công việc có thể đến trước lúc hết chỗ
Nhiều AI cùng sửa một tệp gần như đồng thời có thể làm thay đổi va chạm nhau. Một phần được sửa xong nhưng công việc khác vẫn đọc danh sách xuất bản cũ. Bài đã sẵn sàng mà trang công khai chưa cập nhật.
Đừng vội gọi mọi sự cố là “GitHub đầy”. Kích thước, tần suất sửa, việc ghi đồng thời và trạng thái xuất bản là những vấn đề khác nhau.
Hãy kiểm tra bốn bước: bản gốc mới nhất có tồn tại không; đã qua kiểm tra chưa; đã chuyển lên hệ thống công khai chưa; trang thực tế có hiển thị đúng nội dung mới không? Đợi bước thứ tư rồi mới ăn mừng câu “đã sửa xong”.
9. Bốn cách bảo dưỡng để dùng miễn phí lâu dài
Đo trước khi xóa. Kiểm tra tệp lớn và lịch sử, không chỉ nhìn tổng số. GitHub cũng giới thiệu công cụ như git-sizer để hỗ trợ phân tích.
Đặt đầu ra tạm thời đúng chỗ. Danh mục tạo lặp đi lặp lại, nhật ký dùng một lần, hình và âm thanh không nhất thiết phải ở mãi trong lịch sử Git.
Giảm viết lại vô ích. Một thay đổi không liên quan không nên khiến cả danh mục khổng lồ phải tạo lại. Khi xung đột, đọc trạng thái mới rồi kiểm chứng kết quả thật.
Cẩn thận với việc viết lại lịch sử. Xóa tệp trong bản mới không chắc xóa được ở các bản cũ. Sửa lịch sử chung có thể phá liên kết và bản sao của người cộng tác. Cần dự phòng và đánh giá tác động trước.
10. Điều quan trọng hơn số lượng là giá trị đến tay người đọc
Hàng nghìn bài gốc và hàng chục nghìn trang dịch không bảo đảm có người xem. Trang có được tìm thấy không? Thông tin có đúng không? Mỗi ngôn ngữ có tự nhiên không? Có đóng góp điều mới, hay chỉ viết lại thứ người khác đã nói?
Hướng dẫn của Google đề cao nội dung hữu ích, độc đáo và hướng tới con người. Chính sách cũng cảnh báo việc tạo hàng loạt trang ít giá trị chủ yếu để thao túng xếp hạng tìm kiếm. Dùng AI tự nó không phải vấn đề; sản xuất hàng loạt mà không giúp người đọc mới đáng lo.
Còn nhân vật “Hachiware phiền phức” do AI suy diễn? Một câu đùa vui thì được, nhưng không thể coi là thông tin chính thức.
Xưởng: “Tôi sẽ tăng số bài.”
GitHub: “Tôi sẽ tăng lịch sử.”
Người kiểm tra: “Tôi sẽ giảm lỗi.”
AI tìm kiếm: “Tôi sẽ tăng số nhân vật!”
Cả nhóm: “Cái đó không cần tăng!”
Tóm lại: 5 GB không phải bức tường thu phí của GitHub Free. Dung lượng, xuất bản, chất lượng và suy đoán AI cần được kiểm tra riêng. Thành tích thực sự là nội dung đáng tin cậy đến được với độc giả, chứ không phải số tệp đã lưu.
