Kết luận trong 5 giây: Không thể chứng minh được rằng "càng đến đoạn nguy hiểm thì thầy Nagano càng vẽ nhanh". Nhưng đúng là có những giai đoạn khoảng cách giữa các bài đăng trên X đột ngột ngắn lại, ở những arc dài nặng nề hoặc những cao trào. Vậy thì có thể làm một bot không chính thức, theo dõi tốc độ đăng bài như một chuỗi thời gian và chỉ hiện "chỉ số nguy hiểm của Chiikawa" khi tốc độ nhanh bất thường so với trước đây. Hơn nữa, tính đến tháng 9/2026, API của X tính phí theo mức dùng, nên nếu chỉ theo dõi một tài khoản thì bạn có thể bắt đầu với quy mô nhỏ.
🍣. Hôm sau cũng 🍣. Hôm sau nữa vẫn có cập nhật.
Đến lúc này, chuông báo động vang lên trong đầu độc giả hầu như giống hệt nhau.
"Thầy Nagano dạo này cập nhật hơi nhanh nhỉ?"
Và mỗi khi thấy Chiikawa cập nhật nhanh, không hiểu sao ý nghĩ tiếp theo luôn là "có khi nào ai đó nên chạy trốn không?"
Bài viết này biến cái linh cảm sơ sài nhưng kỳ lạ là không nỡ bỏ của độc giả thành con số. Rồi đi từ một cái máy chưa cài cả Python, đến phân tích dữ liệu quá khứ, chạy thử không đăng thật (dry run), tự động đăng lên X, và vận hành 24 giờ bằng GitHub Actions. Bạn không cần giải mã bên trong file ZIP nào cả. Chỉ cần sao chép nguyên 7 file ở cuối bài rồi dán vào là xong.
Có thật là "càng nguy hiểm thì cập nhật càng nhanh"?
Nhìn vào lịch sử đăng bài công khai, có khá nhiều lý do để cảm thấy như vậy. Ở đoạn cuối arc Nàng tiên cá biển (Seiren) hồi tháng 11/2023, theo ghi chép công khai có bài đăng 5 ngày liên tiếp từ 5 đến 9/11, 6 ngày liên tiếp từ 13 đến 18/11 và 6 ngày liên tiếp từ 21 đến 26/11. Ngày 26/11 thậm chí còn có nhiều bài trong cùng một ngày.
Phần đầu arc Thế giới song song hồi tháng 3/2024 cũng đăng mỗi ngày từ 1 đến 8/3, ngày 8 có 2 bài.
Tuy nhiên, từ đó chỉ có thể nói rằng "tốc độ công bố đã tăng". Chưa chắc tác giả vẽ ngay trong ngày hôm đó. Có thể là đăng liền một loạt bản vẽ đã tích trữ, hoặc vì là arc dài nên việc công bố dồn lại một chỗ mà thôi.
Vì vậy câu hỏi của bot được thu hẹp lại.
Không phải dự đoán tình tiết nguy hiểm, mà là phát hiện tốc độ công bố hiện tại bất thường đến mức nào so với chính quá khứ của Chiikawa.
Đây không phải phòng nghiên cứu. Đây là chuông báo động của Chiikawa.
Chỉ số nguy hiểm xem những gì?
Về cơ bản chỉ có ba thứ.
- Số bài đăng trong 3 ngày gần nhất
- Số bài đăng trong 7 ngày gần nhất
- Đã đăng liên tiếp bao nhiêu ngày
Mỗi thứ được so với phân bố của toàn bộ quá khứ rồi đổi thành phân vị: "nằm ở phía trên bao nhiêu trong lịch sử". Trọng số ban đầu là 35% cho số bài 3 ngày, 45% cho số bài 7 ngày và 20% cho số ngày đăng liên tiếp. Ngoài ra, nếu cùng một nội dung ngắn hoặc cùng một emoji được đăng liên tục như 🍣🍣, mỗi lần lặp thêm sẽ được cộng +5 điểm "chỉnh cho vui", tối đa +15.
Con số +5 này không có cơ sở khoa học nào. Nó hoàn toàn là việc lập trình hóa cảm giác "sushi cứ xuất hiện liên tục thì hơi rợn".
Các mức hiển thị ban đầu như sau.
- 0-54: 🟢 Bình thường
- 55-69: 🟡 Đang tăng tốc
- 70-84: 🟠 Cảnh giác
- 85-100: 🚨 Nhanh bất thường
API của X tốn bao nhiêu tiền?
Theo trang giá chính thức (Pricing) tính đến ngày 3/9/2026, các mức giá chính hiện hành như sau.
| Thao tác | Giá hiện hành |
|---|---|
| Post Read | $0.005 / bài lấy về |
| Counts: Recent | $0.005 / yêu cầu |
| Counts: All | $0.010 / yêu cầu |
| Content Create | $0.015 / bài đăng |
| Content Create (có URL) | $0.200 / bài đăng |
Để phân tích quá khứ, ta không đọc nội dung hàng nghìn bài mà chỉ lấy số lượng theo từng khung giờ bằng Post Counts. Counts của toàn bộ kho lưu trữ được phân trang theo từng 31 ngày, nên từ 1/1/2020 đến 3/9/2026, khoảng 2,437 ngày, sẽ cần khoảng 79 yêu cầu, tức khoảng $0.79. Không phải "mỗi yêu cầu 1 xu nên cả lịch sử chỉ tốn 1 xu". Đây là cái bẫy nhỏ.
Việc theo dõi trực tiếp dùng Recent Search kèm since_id và chỉ đọc những bài mới hơn lần trước. Nếu có 30 bài mới, phí đọc khoảng $0.15. Nếu mỗi tháng phát 10 cảnh báo không có URL, phí ghi cũng khoảng $0.15. Ngược lại, bài đăng có URL hiện là $0.200, nên cấu hình ban đầu để INCLUDE_SOURCE_URL=0. Nếu vì tốt bụng mà lần nào cũng gắn URL, hóa đơn sẽ bỗng nhiên thành trùm cuối.
Giá có thể thay đổi. Trước khi chạy thật, hãy kiểm tra lại Pricing chính thức và đặt Spending limit (hạn mức chi tiêu) trong Developer Console.
Nếu hoàn toàn không có máy tính thì bắt đầu từ đâu?
Bạn cần máy tính Windows hoặc macOS, tài khoản X, X Developer App, tài khoản GitHub nếu muốn chạy 24 giờ, và Python. Không bắt buộc phải cài Git trên máy.
Windows
- Cài Python từ trang chính thức. Windows hiện nay cũng có thể dùng Python Install Manager.
- Mở PowerShell.
- Gõ
py --versionđể xác nhận Python chạy được. - Tạo thư mục
chiikawa-danger-bot. - Dùng Notepad hoặc VS Code, lưu 7 file ở cuối bài đúng nguyên tên. Nếu dùng Notepad, cẩn thận đừng để nó thành
bot.py.txt.
macOS
- Cài bản macOS từ trang chính thức của Python.
- Mở Terminal.
- Kiểm tra bằng
python3 --version. - Tạo thư mục
chiikawa-danger-bot. - Lưu 7 file bằng VS Code, TextEdit ở chế độ văn bản thuần, hoặc
nano.
Thiết lập X Developer như thế nào?
Vào console.x.com bằng tài khoản X, xem Developer Agreement (thỏa thuận nhà phát triển) rồi tạo App. Thông tin xác thực hiện ra lúc tạo App có thể sẽ không hiện lại, nên hãy lưu ở nơi an toàn.
Để đọc dữ liệu dùng Bearer Token. Vì bot tự đăng bài, cách triển khai này còn dùng cả OAuth 1.0a User Context. Đặt App permissions là Read and write.
Cần có năm giá trị.
X_BEARER_TOKENX_API_KEYX_API_SECRETX_ACCESS_TOKENX_ACCESS_TOKEN_SECRET
Nếu bạn đổi từ Read only sang Read and write, hãy tạo lại Access Token / Secret sau khi đổi. Dùng token từ trước lúc đổi quyền sẽ gây ra lỗi 403.
Giá trị thật chỉ được đặt trong .env và GitHub Actions Secrets. Tuyệt đối không dán vào bài viết, GitHub công khai hay ảnh chụp màn hình.
Chạy phân tích dữ liệu quá khứ như thế nào?
Sau khi lưu xong 7 file ở cuối bài, trên Windows hãy chạy các lệnh sau trong PowerShell.
py -m venv .venv
.\.venv\Scripts\python.exe -m pip install -r requirements.txt
mkdir data
copy danger_periods.example.csv data\danger_periods.csv
copy .env.example .env
notepad .env
Trên macOS thì như sau.
python3 -m venv .venv
./.venv/bin/python -m pip install -r requirements.txt
mkdir -p data
cp danger_periods.example.csv data/danger_periods.csv
cp .env.example .env
nano .env
Dán Bearer Token thật vào bên phải X_BEARER_TOKEN= trong .env. Tiếp theo, trên Windows chạy
.\.venv\Scripts\python.exe history_analysis.py
còn trên macOS chạy
./.venv/bin/python history_analysis.py
Màn hình sẽ hiện page=1... chạy dần, và nếu tạo ra data/history_features.csv là thành công. File CSV này là chuẩn tham chiếu lịch sử của chỉ số nguy hiểm.
Trong danger_periods.example.csv, mình đã đưa vào đoạn cuối arc Nàng tiên cá biển và đoạn đầu arc Thế giới song song để kiểm tra giả thuyết. Đây không phải "nhãn đáp án đúng về nguy hiểm", mà là nhãn làm thủ công để xem chỉ số giữa giai đoạn nguy hiểm và giai đoạn bình thường có thật sự khác nhau hay không.
Làm sao để không bị đăng lên X ngay lập tức?
Dù đã điền 4 thông tin xác thực còn lại vào .env, lúc đầu hãy giữ nguyên BOT_DRY_RUN=1.
Windows:
.\.venv\Scripts\python.exe bot.py
macOS:
./.venv/bin/python bot.py
Lần đầu bot chỉ đọc khoảng 7 ngày gần nhất và tạo data/state.json, tuyệt đối không đăng bài. Ví dụ màn hình sẽ hiện thế này.
Chỉ số nguy hiểm Chiikawa 82/100 🟠 Cảnh giác
3 ngày gần nhất 3 bài / 7 ngày 6 bài / đăng liên tiếp 3 ngày
Dấu hiệu giống nhau "🍣" lặp 2 lần liên tiếp +5
* Không chính thức. Đây là chỉ số cho vui, tạo ra từ tần suất cập nhật.
Thế là hoàn thành cách đọc Chiikawa kỹ thuật một cách thừa thãi: thầy Nagano đăng liên tục → Python: "chuỗi thời gian bất thường" → độc giả: "chạy đi".
Chạy 24 giờ bằng GitHub Actions như thế nào?
Tạo một GitHub Repository mới trên trình duyệt rồi tải lên những file sau.
bot.pyhistory_analysis.pyrequirements.txt.env.example.gitignoredata/history_features.csv- Nếu cần thì thêm
data/danger_periods.csv
Tuyệt đối không tải .env lên.
Trong Settings → Secrets and variables → Actions → New repository secret của Repository, đăng ký cả năm thông tin xác thực với đúng tên như trên.
Tiếp theo, dùng Add file → Create new file để tạo .github/workflows/chiikawa-danger.yml và dán đoạn YAML ở cuối bài. Giá trị ban đầu là BOT_DRY_RUN: "1". Hãy chạy thủ công từ màn hình Actions và xác nhận nó kết thúc bình thường.
Chỉ đổi sang BOT_DRY_RUN: "0" khi chuyển sang chạy thật. Với POST_MODE: "alert", bot chỉ đăng khi mức nguy hiểm tăng lên một bậc. Còn every đăng mỗi khi có bài mới, nên cả chi phí lẫn độ "làm phiền" trên dòng thời gian đều tăng.
Là bot tự động thì cần tuân thủ những gì?
Automation Rules của X yêu cầu tránh spam và các hình thức tự động hóa lặp lại. Tài khoản tự động có thể gắn Automated account label (nhãn tài khoản tự động) để nêu rõ mối liên hệ với tài khoản do con người quản lý.
Trong hồ sơ, hãy ghi rõ "bot fan không chính thức" và "chỉ số cho vui tạo từ tần suất cập nhật", đồng thời không bắt chước tài khoản chính thức. Ví dụ này không tự động thích, không tự động theo dõi và không trả lời hàng loạt.
Ngoài ra, "chỉ số nguy hiểm" không khẳng định điều gì về sức khỏe của tác giả, tốc độ vẽ thực tế, điều kiện lao động hay diễn biến tương lai. Thứ được quan sát chỉ là quy luật thời gian của các bài đăng công khai.
Muốn độ chế thêm nữa thì sao?
Bạn còn có thể thêm hiệu chỉnh theo thứ trong tuần, phân loại thông báo và tập truyện, dùng đặc trưng hình ảnh, huấn luyện bằng nhãn do người gắn, làm backtest (kiểm tra lại bằng dữ liệu quá khứ) xem sau cảnh báo bao nhiêu ngày thì có tập nặng nề xuất hiện, hay tìm các giai đoạn tương tự như "kiểu cuối arc Nàng tiên cá biển" và "kiểu Thế giới song song". Có điều lượng dữ liệu và chi phí sẽ tăng.
Lúc đầu chỉ cần giờ đăng bài là đủ. Một con bot làm cho vui mà lại thành phát hiện bất thường chuỗi thời gian thì đã đủ kỳ cục rồi.
Rốt cuộc là dự đoán cái gì?
Không phải "lần tới ai sẽ gặp xui xẻo".
Tốc độ cập nhật hiện tại bất thường đến mức nào so với Chiikawa của quá khứ.
Chỉ có vậy thôi.
Nhưng vì đoạn cuối arc Nàng tiên cá biển và đoạn đầu arc Thế giới song song thực sự có bài đăng dồn dập, nên cũng đủ thú vị để tự động hóa cái linh cảm của độc giả: "lại bắt đầu nhanh rồi kìa".
Chỉ số 85 điểm.
Máy: "Thuộc nhóm cao nhất trong lịch sử."
Độc giả: "Ai đó chạy đi!"
