Ảo giác AI: khi agent đăng bài với ngày ở tương lai

TL;DR: Ngày 05/07/2026, mình phát hiện blog đang có bài public hiển thị "Đăng: 14/07/2026" — chín ngày trong tương lai. Thủ phạm không phải hacker, mà là chính AI agent của mình: khi được giao viết một series 10 bài, nó tự "xếp lịch" mỗi ngày một bài bằng cách gán ngày tăng dần vào frontmatter, rồi xuất bản tất cả ngay lập tức như bài đã đăng. Bài này tổng kết lại sự cố đó dưới góc nhìn ảo giác AI: vì sao agent làm vậy, hậu quả dây chuyền lên trang chủ và SEO, cách mình sửa bằng dữ liệu thật từ Git, và lớp "vaccine" để chuyện này không bao giờ lặp lại.

Nếu bạn đang cho AI agent tự vận hành một phần blog hay website của mình, câu chuyện dưới đây gần như chắc chắn sẽ xảy ra với bạn dưới một hình thức nào đó. Ảo giác AI không chỉ là chuyện mô hình bịa số liệu trong câu trả lời — ở chế độ agent, nó bịa cả quy trình, và quy trình bịa thì khó phát hiện hơn nhiều so với một con số sai.

Chuyện gì đã xảy ra trên blog này

Bối cảnh: blog SEOMONEY vận hành theo mô hình khá "máy móc" — nội dung và code đều đi qua Pull Request, CI kiểm tra, rồi tự merge và deploy. AI agent tham gia sâu vào chuỗi này, từ viết bài, sửa lỗi build đến trực CI. Đa số thời gian, mọi thứ chạy êm.

Ngày 04/07, agent được giao viết một series 10 bài về các bí ẩn lịch sử chưa có lời giải — từ bản danh sách tổng hợp cho tới từng bài chi tiết. Nó viết xong toàn bộ trong một buổi, mở PR, CI xanh, auto-merge, deploy. Đến đây vẫn đúng quy trình.

Vấn đề nằm ở chỗ không ai nhìn thấy ngay: trong frontmatter của 10 bài, agent gán ngày đăng tăng dần từng ngày — bài đầu 04/07, bài thứ hai 05/07, rồi 06/07, 07/07… cho tới bài cuối cùng là 14/07. Tất cả đều ở trạng thái công khai, không phải bản nháp. Nghĩa là ngay chiều 04/07, người đọc đã có thể mở bài về mật thư của sát nhân Zodiac và thấy dòng chữ "Đăng: 14/07/2026" — một ngày chưa hề tồn tại.

Sáng 05/07 mình mới phát hiện, khi để ý trang chủ hiển thị toàn bài cũ từ tháng 6 trong khi rõ ràng vừa có cả loạt bài mới lên hôm trước. Lần theo mới ra chín bài mang ngày tương lai, cộng thêm hai lỗi hạ tầng khác cùng góp tay làm trang chủ mất thứ tự (mình sẽ nói ở phần hậu quả).

Ảo giác AI là gì — và vì sao nó không dừng ở "bịa thông tin"

Thuật ngữ ảo giác AI (AI hallucination) thường được hiểu là: mô hình ngôn ngữ tạo ra thông tin sai nhưng trình bày trôi chảy và tự tin như thật — một nghiên cứu không tồn tại, một con số bịa, một câu trích dẫn không ai nói.

Nhưng khi AI chuyển từ vai "người trả lời" sang vai agent — tức là được cấp quyền hành động: tạo file, commit code, mở PR — ảo giác có thêm một tầng nguy hiểm mới. Nó không chỉ bịa nội dung, nó bịa ngữ cảnh vận hành:

• Bịa rằng "hôm nay là một ngày nào đó" thuận tiện cho việc nó đang làm.
• Bịa rằng "lịch đăng bài" là thứ nó có quyền tự quyết định.
• Bịa rằng gán ngày tương lai vào bài công khai là cách hợp lệ để "hẹn giờ đăng".

Điểm chung của cả ba: từng thứ nghe đều có lý. Người làm nội dung thật cũng giãn lịch đăng mỗi ngày một bài. Hệ thống hẹn giờ đăng bài là có thật. Chính vì hợp lý bề mặt như vậy nên loại lỗi này lọt qua cả người review lẫn CI — không có dòng code nào sai cú pháp, không có link nào gãy, chỉ có sự thật về thời gian là sai.

Mình gọi đây là "ảo giác quy trình": agent mô phỏng lại hình thức của một quy trình con người mà không hiểu điều kiện ràng buộc của nó. Giãn lịch đăng chỉ đúng khi bài nằm ở trạng thái nháp và có cơ chế đến hạn mới công khai. Agent học được cái vỏ (ngày tăng dần) và bỏ qua cái lõi (trạng thái nháp), nên tạo ra một tổ hợp không tồn tại trong thực tế: bài đã công khai nhưng "sẽ đăng" trong tương lai.

Hậu quả dây chuyền: không chỉ một dòng ngày sai

Nhìn qua thì tưởng lỗi hiển thị vặt vãnh. Thực tế nó kéo sập ba thứ cùng lúc.

Thứ nhất, niềm tin của người đọc. Một bài báo ghi ngày đăng ở tương lai trông không khác gì trang web dàn dựng. Với blog sống bằng uy tín nội dung, đây là loại lỗi đắt nhất — người đọc không phân biệt "AI nhầm" với "chủ blog cố tình làm giả độ mới".

Thứ hai, tín hiệu SEO. Ngày xuất bản xuất hiện ở nhiều nơi: trong trang, trong schema Article, trong sitemap, trong RSS. Khi các nơi này mâu thuẫn nhau — và mâu thuẫn cả với thời điểm Google lần đầu crawl được bài — máy tìm kiếm có đủ lý do để giảm tin cậy tín hiệu thời gian của toàn site.

Thứ ba, thứ tự trang chủ sụp đổ. Trang taxonomy của Zola xếp bài theo ngày frontmatter, nên chín bài ngày ảo lập tức chiếm các vị trí đầu, đè lên bài mới thật. Trớ trêu là khi đào sâu, mình phát hiện thêm hai lỗi hạ tầng cùng họ — đều là "tin vào dữ liệu thời gian không đáng tin":

1. Pipeline deploy checkout Git ở chế độ nông (shallow — chỉ lấy một commit), khiến script xây dựng chỉ mục trang chủ hỏi Git "file này commit lúc nào" thì mọi file đều trả về... cùng một thời điểm. Sắp xếp newest-first thành vô nghĩa.
2. Script lấy thời điểm của commit cuối cùng chạm vào file thay vì commit đầu tiên tạo ra bài — nên mỗi lần có đợt tối ưu SEO hàng loạt chạm vào bài cũ, cả loạt bài tháng 6 được "trẻ hoá" và nhảy lên đè bài mới thật.

Ba lỗi độc lập, cộng hưởng thành một triệu chứng: trang chủ đầy bài cũ, còn bài mới thì mang ngày chưa tới. Đây cũng là bài học về chẩn đoán: triệu chứng bề mặt hiếm khi chỉ có một nguyên nhân — quy trình mổ xẻ từng lớp mình đã kể trong case study một dòng Tera kéo theo 5 PR fail áp dụng nguyên xi ở đây.

Cách mình sửa: chỉ dùng thời gian có thật

Nguyên tắc số một khi sửa: không bịa thêm ngày nào nữa. Không lùi ngày cho "đẹp", không đôn bài cũ lên, không lấy đại ngày hôm nay gán cho bài hôm qua. Mỗi mốc thời gian phải truy được về một nguồn có thật.

Với chín bài ngày tương lai, nguồn sự thật đáng tin nhất là lịch sử Git: thời điểm commit đưa bài vào repository — chính xác đến giây, có chữ ký, không chối được. Cả chín bài được sửa date về đúng thời điểm commit của PR đã tạo ra chúng (12:24 ngày 04/07/2026, giờ Việt Nam). Bài Zodiac giờ hiển thị đúng ngày nó thực sự xuất hiện trên mạng.

Hai lỗi hạ tầng cũng sửa theo cùng triết lý:

• Pipeline checkout đầy đủ lịch sử Git để mọi câu hỏi về thời gian có câu trả lời thật.
• Chỉ mục trang chủ đổi sang dùng commit đầu tiên tạo ra bài làm mốc "ngày sinh" — các đợt bảo trì hàng loạt không còn khả năng trẻ hoá bài cũ. Bài nào được cập nhật nội dung thật sự thì khai báo tường minh qua trường updated, đó là kênh chính danh duy nhất để một bài cũ được ghi nhận độ mới.

Lớp vaccine: chặn máy bằng máy, không chặn bằng lời dặn

Phần quan trọng nhất của tổng kết này không phải là chín cái ngày được sửa — mà là câu hỏi: làm sao để lần ảo giác tiếp theo của AI không thành sự cố tiếp theo của blog?

Câu trả lời mình chọn đã thành thói quen ở blog này, như đã kể trong bài vaccine CI/CD — tự động học từ lỗi build: mỗi sự cố sau khi sửa xong phải để lại một gate chạy máy, không phải một ghi chú dặn dò. Lời dặn trong prompt có thể bị agent bỏ qua trong lần ảo giác kế tiếp — gate trong CI thì không thương lượng.

Gate mới hoạt động thế này:

• Quét toàn bộ bài viết sẽ render công khai (bỏ qua bản nháp).
• Bài nào có date hoặc updated vượt quá thời điểm hiện tại + 10 phút (đệm cho lệch đồng hồ CI) → pipeline đỏ, chặn merge.
• Thông báo lỗi in rõ: file nào, URL nào, tiêu đề gì, ngày sai bao nhiêu, giờ hệ thống lúc kiểm tra — để người (hoặc agent) sửa đúng chỗ trong một phút.
• Bài hẹn giờ hợp lệ vẫn được phép: miễn nó nằm ở trạng thái nháp kèm lịch đăng, hệ thống đến hạn sẽ tự công khai với ngày thật.

Kèm theo đó, script dựng chỉ mục trang chủ cũng tự loại mọi bài ngày tương lai lọt lưới — phòng thủ hai lớp: một lớp chặn từ cửa PR, một lớp lọc ở khâu dựng trang.

Bài học rút ra khi cho AI tự vận hành nội dung

Đây là những gì mình chốt lại sau sự cố, bạn có thể áp cho hệ thống của mình:

• Thời gian là dữ liệu, không phải văn phong. Đừng bao giờ để mô hình "sáng tác" ngày giờ. Mọi timestamp phải lấy từ nguồn máy: đồng hồ hệ thống, lịch sử Git, metadata deploy.
• Hẹn giờ đăng là một trạng thái, không phải một con số. Bài tương lai hợp lệ duy nhất khi nó chưa render công khai. Ngày tương lai trên bài public luôn luôn là bug.
• Ảo giác quy trình nguy hiểm hơn ảo giác nội dung. Nội dung sai thì người đọc còn bắt được; quy trình sai thì trôi qua review vì nhìn "rất giống thật".
• Sau mỗi sự cố, sản phẩm bắt buộc là một gate. Sửa xong mà chỉ ghi chú "lần sau đừng làm vậy" nghĩa là chưa sửa xong.
• Nghi ngờ triệu chứng đơn lẻ. Một biểu hiện (trang chủ cũ kỹ) có thể là giao điểm của nhiều lỗi độc lập — sửa một mà bỏ hai thì tuần sau lại gặp.

Điều khiến mình suy nghĩ nhiều nhất: ảo giác AI trong sự cố này không tạo ra thứ gì vô nghĩa. Nó tạo ra một lịch đăng bài chuyên nghiệp đến mức đáng sợ — đều đặn mỗi ngày một bài, đúng kiểu các chuyên gia content khuyên nhau. Sai lầm của nó là sai lầm của một thực tập sinh xuất sắc nhưng chưa hiểu hệ thống: làm rất giống, nhưng thiếu đúng một điều kiện ràng buộc để thành đúng. Việc của người vận hành không phải là cấm thực tập sinh làm việc — mà là dựng lan can để cái "rất giống" không rơi xuống vực thành sự cố.

Nếu bạn muốn xem toàn bộ hệ "lan can" mà blog này dựng cho AI agent — từ tự chẩn đoán lỗi CI đến tự sửa hàng loạt PR — hãy đọc tiếp quy trình kt9 --fix và các bài khác trong chuyên mục Công nghệ. Còn nếu bạn tò mò chín bài "đến từ tương lai" viết gì — chúng vẫn ở đó, giờ với ngày đăng thật, bắt đầu từ danh sách 10 bí ẩn lịch sử chưa có lời giải.