Tối 11/10/2026, máy đăng bài tự động của tôi báo chạy xong, mã thoát 0, nghĩa là không có lỗi. Mở web ra thì không có bài nào. Máy đã gọi sai đường dẫn tới chương trình, không làm gì cả, rồi vẫn ghi vào nhật ký là thành công.
Đó là một trong tám sự cố của hệ thống tôi dựng để AI tự viết blog, tự đăng lên hai website và tự dựng clip mỗi ngày, chỉ tính trong hai ngày đầu [8]. Tám lỗi đó không có gì lạ. Ai để AI làm việc lặp lại mỗi ngày rồi cũng sẽ gặp. Điều đáng hỏi là: làm sao để mỗi lỗi chỉ xảy ra một lần?
AI sai theo hai kiểu, nhắc nhở không chữa được kiểu nào
Kiểu thứ nhất là sai lặp lại. Hai ngày liền, bản nháp đầu tiên đều dài quá giới hạn. Kiểu thứ hai là sai im lặng: máy báo xong nhưng thực ra không làm, như tối 11/10.
Phản xạ đầu tiên của nhiều người là viết thêm một câu nhắc vào lời dặn AI. Cách đó đỡ được vài hôm. Lời dặn dài dần, AI đọc sót, lỗi cũ quay lại dưới dạng khác.
Lean Six Sigma có sẵn bộ công cụ cho đúng chuyện này, vốn sinh ra để chữa lỗi lặp trong nhà máy. Tôi rà lại 10 công cụ trong chương trình Green Belt, chấm theo năm tiêu chí: AI tự làm được không, chặn lỗi lặp tốt không, rẻ không, hệ thống đã có sẵn dữ liệu chưa, đội không chuyên có hiểu không. Năm công cụ đứng đầu nối với nhau thành một vòng, theo đúng tinh thần của chu trình PDCA (lập kế hoạch, làm, kiểm tra, điều chỉnh) [5].
flowchart TD A[Ghi lỗi vào sổ] --> B[Xếp lỗi theo nhóm] B --> C[Hỏi tại sao tới gốc] C --> D[Chặn lỗi bằng máy] D --> E[Viết thành chuẩn] E --> A
Bước 1 và 2: ghi lỗi, rồi xếp lỗi
Công cụ đầu tiên, rẻ nhất mà hay bị bỏ qua nhất, là phiếu kiểm tra (check sheet). Đó là một mẫu ghi dữ liệu dựng sẵn, dùng khi cần đếm một sự việc lặp đi lặp lại [1]. Với AI, phiếu kiểm tra là một cái sổ: mỗi lần làm xong một việc, AI ghi một dòng cho mỗi lỗi gặp phải, chọn nhóm lỗi trong một danh mục cố định. Không có sổ thì mọi buổi họp cải tiến chỉ dựa vào trí nhớ, và trí nhớ thường nhớ lỗi gần nhất chứ không nhớ lỗi hay gặp nhất.
Có sổ rồi thì đếm. Biểu đồ Pareto xếp các nhóm lỗi từ nhiều tới ít, để thấy nhóm nào đáng sửa trước [2][7]. Tám sự cố của hệ thống tôi xếp ra thế này:
| Số sự cố | |
|---|---|
| Hạ tầng chạy tự động | 4 |
| Nội dung | 2 |
| Hiển thị | 2 |
Tôi đã nghĩ chất lượng chữ AI viết là chỗ yếu nhất. Sổ cho thấy một nửa số sự cố nằm ở phần máy chạy tự động: gọi sai đường dẫn chương trình, máy hẹn giờ không đọc được thông tin đăng nhập GitHub, kho mã còn file chưa ghi lại (chưa commit) nên lượt đăng bị bỏ qua. Tám dòng chưa đủ để kết luận, nhưng đủ để tôi kiểm phần máy chạy trước, thay vì dồn sức sửa câu chữ.
Lời dặn cho AI ở bước này nên ngắn và cứng:
Lời dặn mẫu cho AI: “Mỗi lỗi ghi một dòng: ngày, việc, nhóm lỗi, mô tả ngắn, ai phát hiện, phút tốn thêm. Cuối tuần đếm theo nhóm, chỉ chọn tối đa hai nhóm lớn nhất để sửa. Dưới mười dòng thì ghi rõ là chưa đủ dữ liệu.”
Bước 3: hỏi tại sao cho tới khi gặp quy trình
Chọn được nhóm lỗi rồi, đừng sửa ngay. Hỏi tại sao trước. Phương pháp 5 Why hỏi “tại sao” liên tiếp tới khi chạm nguyên nhân gốc, và con số 5 không phải luật: dừng khi câu trả lời là một chính sách, một quy trình, một hệ thống hay một nhu cầu đào tạo [3].
Trưa 12/10, máy dựng clip dừng giữa chừng. Hỏi tại sao: chữ ở cảnh thứ hai tràn khung 296 điểm ảnh. Tại sao tràn: cảnh kiểu “con số lớn” vẽ tiêu đề rất to, mà tiêu đề lại là cả một câu dài. Tại sao viết câu dài: AI viết kịch bản không biết giới hạn của máy dựng. Tại sao không biết: bước viết và bước dựng không dùng chung một bộ kiểm. Tới đây là gốc, nằm ở quy trình.
Nếu dừng ở câu thứ ba, cách sửa sẽ là dặn AI viết tiêu đề ngắn. Dừng ở câu cuối thì cách sửa khác hẳn: làm một bộ kiểm dùng chung. Vì vậy quy tắc tôi đặt cho AI ở bước này là cấm dừng ở câu “AI viết sai”.
Bước 4: chặn bằng máy, đừng bắt AI phải nhớ
Poka-yoke (chống lỗi, nghĩa đen là tránh sơ suất) là mọi thiết bị hay cách làm khiến lỗi không thể xảy ra, hoặc lỗi lộ ra ngay khi vừa xảy ra [4]. Với AI, đó là một đoạn kiểm tự động chạy trước bước kế tiếp. Lỗi thì dừng, nói rõ lỗi gì, ở đâu, sửa thế nào.
Trong hệ thống của tôi, lời đọc clip có chữ số sẽ bị từ chối ngay, vì giọng đọc tiếng Việt hay đọc sai số. Kịch bản phải qua một công cụ đo chữ tràn khung trước khi được duyệt. Máy đăng bài giờ kiểm đường dẫn chương trình trước khi chạy, sai thì gửi email cảnh báo chứ không ghi “thành công” nữa. Không ai phải nhớ ba chuyện đó nữa.
Thứ tự ưu tiên khi chặn lỗi giống trong nhà máy: bỏ được bước gây lỗi thì bỏ; không bỏ được thì thay bằng cách làm ít lỗi hơn, hoặc làm cho không thể sai; không được nữa thì phát hiện ngay [4]. Chỉ khi cả ba cách đều không được mới viết thành lời dặn cho AI nhớ. Tháng 4/2026 tôi từng viết về cách AI giúp con người chống lỗi trong bài AI và Poka Yoke. Lần này chiều ngược lại: dùng chống lỗi để giữ cho chính AI không sai.
Bước 5: viết thành chuẩn, và cho chuẩn có ngày hết hạn
Cách sửa nào đã chứng minh có tác dụng thì ghi vào quy trình chuẩn mà AI đọc trước mỗi lần làm. Danh sách kiểm (checklist) và vòng SDCA (chuẩn hóa, làm, kiểm tra, điều chỉnh) giữ cho cái đã sửa không trôi mất [1][5]. Câu chuẩn phải là bước làm hoặc câu hỏi có hay không. Ví dụ với tin mồi, tức tin thời sự dùng để mở bài: “tin mồi phải đăng trong 12 giờ trước giờ chạy” là chuẩn, còn “nên chọn tin mới” chỉ là lời khuyên. Chuẩn này ra đời sau sự cố chọn tin cũ kể ở phần dưới.
Có người sẽ nói: cứ thêm quy tắc mãi thì AI thành cứng nhắc, hết sáng tạo. Điều đó đúng. Chính tôi đã mắc: sau sự cố clip, tôi đặt luôn quy tắc chặn cả chuyện tiêu đề quá 8 chữ, chặn quá tay. Cách tôi sửa là chia quy tắc làm ba tầng. Tầng cứng chỉ chặn sai sự thật và lỗi kỹ thuật. Tầng mềm chỉ cảnh báo, AI được giữ nếu có lý do. Tầng gợi ý thì không kiểm. Mỗi quy tắc mềm có ngày xem lại, sau hai tuần không có số liệu chứng minh tác dụng thì bỏ, để quy trình chuẩn gọn đi theo thời gian.
Ba công cụ để dành cho lúc cần
Biểu đồ xương cá (fishbone) xếp nguyên nhân theo nhóm, hợp khi một lỗi có nhiều nguyên nhân đan nhau [6]. Sáng 12/10, hệ thống chọn một tin đã cũ bốn ngày làm tin mồi cho bài blog. May là bài được giữ lại trước giờ đăng. Xếp ra xương cá thì thấy nguyên nhân ở cả sáu nhánh: quy trình, dữ liệu vào, đo lường, công cụ, con người, môi trường. Nhưng AI rất thích liệt kê, xương cá có thể thành danh sách dài vô tận. Tôi buộc nó chọn một nhánh có bằng chứng rõ nhất rồi mới hỏi 5 Why. Lần đó là nhánh đo lường: điểm “độ hot” 3,9 được ghi mà không có phiếu chấm nào làm bằng chứng.
Phân tích dạng lỗi và tác động (FMEA) liệt kê trước mọi cách một quy trình có thể hỏng [6]. Nó tốn công, nên dùng một lần trước khi bật mỗi quy trình tự động mới. Nhìn lại, tôi nghĩ phần lớn sự cố hạ tầng của mình đã có thể lường trước nếu làm bước này trước khi bật máy chạy tự động. Còn biểu đồ kiểm soát (control chart) theo dõi một chỉ số theo thời gian, có hai đường giới hạn để biết lúc nào bất thường. Cần khoảng 20 điểm đầu tiên mới tính được giới hạn tạm thời, có thêm dữ liệu thì tính lại [6]. Hệ thống mới chạy vài ngày, nên tôi chỉ ghi điểm và chờ.
Khi nào nên nhờ người ngoài
Dựng sổ lỗi và vòng năm bước cho một quy trình AI không khó, một trưởng nhóm làm được trong một buổi. Khó là duy trì: ai đếm sổ mỗi tuần, ai duyệt quy tắc mới, khi nào bỏ quy tắc cũ. Nếu đội anh chị dùng AI hằng ngày mà gặp ít nhất hai trong ba dấu hiệu sau, nên có thêm một góc nhìn độc lập: cùng một lỗi quay lại sau khi đã dặn AI; lời dặn AI dài tới mức không ai đọc hết; không ai trả lời được tuần trước AI sai bao nhiêu lần. FranchiseVN có dịch vụ cải tiến vận hành để dựng vòng cải tiến này cho từng quy trình. Nếu chưa chắc mình cần gì, anh chị có thể bắt đầu bằng bảng đánh giá nhu cầu khoảng 4 phút.
Việc làm ngay
- Tạo một file sổ lỗi với 6 cột: ngày, việc, nhóm lỗi, mô tả, ai phát hiện, phút tốn thêm.
- Dặn AI ghi một dòng cho mỗi lỗi, kể cả lỗi nó tự sửa được.
- Cuối tuần đếm theo nhóm, chọn một nhóm lớn nhất, hỏi tại sao tới khi gặp quy trình.
- Với nguyên nhân tìm được, thử viết một đoạn kiểm tự động trước khi viết thêm lời dặn.
- Mỗi quy tắc mới ghi ngày xem lại sau hai tuần.
Tám sự cố trong hai ngày đầu nghe có vẻ nhiều. Bốn lỗi đã có bước kiểm tự động, số còn lại nằm trong sổ chờ vòng tuần sau. Tuần này, AI của anh chị sai bao nhiêu lần, và anh chị có biết con số đó không?
Nguồn tham khảo
- Nancy R. Tague, The Quality Toolbox, bản 3, mục Check Sheet (tr. 140) và Checklist (tr. 138 đến 139).
- Nancy R. Tague, The Quality Toolbox, bản 3, mục Pareto Chart (tr. 399 đến 400).
- Nancy R. Tague, The Quality Toolbox, bản 3, mục Five Whys (tr. 255 đến 256).
- Nancy R. Tague, The Quality Toolbox, bản 3, mục Mistake-Proofing (tr. 370 đến 373); The ASQ Certified Six Sigma Green Belt Handbook, bản 3, chương 2.
- Nancy R. Tague, The Quality Toolbox, bản 3, mục PDCA (tr. 414 đến 415) và SDCA (tr. 416); The ASQ Certified Six Sigma Green Belt Handbook, bản 3, chương 7.
- Nancy R. Tague, The Quality Toolbox, bản 3, mục Fishbone Diagram (tr. 246 đến 247), FMEA (tr. 236 đến 241), Control Chart (tr. 153 đến 158).
- The ASQ Certified Six Sigma Green Belt Handbook, bản 3, chương 10 (Pareto chart).
- Nhật ký vận hành hệ thống blog và clip tự động của hocvienx5.com và franchisevn.com, ngày 11 và 12/10/2026.
Bài viết mang tính tham khảo, không phải khuyến nghị đầu tư.
Ghi chú minh bạch: Bài được soạn với sự hỗ trợ của AI (Claude) theo quy trình biên tập của tác giả. Tám sự cố là số liệu thật của hệ thống trong hai ngày, cỡ mẫu nhỏ, chỉ dùng để minh họa cách làm.
Bài viết được đăng lần đầu trên blog Học viện X5.
Bài viết mang tính thông tin, không phải lời khuyên đầu tư, pháp lý hay tư vấn cho trường hợp cụ thể. Điều khoản sử dụng
Sao chép link để gửi qua Zalo hoặc tin nhắn.