AI's Asumption: Vì sao thiết kế rất ổn nhưng lại fail khi làm thực tế?

Vì sao thiết kế rất ổn nhưng lại fail khi làm thực tế?

Ở bài trước về Tính bất biến của hệ thống, mình có đưa ra một ví dụ thực tế: Yêu cầu AI thiết kế tài liệu đặc tả hoàn chỉnh cho tính năng "Cập nhật địa chỉ giao hàng sau khi đặt hàng thành công".

Kết quả là AI tạo ra một bản tài liệu rất dài và cực kỳ bài bản, có đủ sơ đồ luồng, bảng dữ liệu, API contract cho đến cấu hình khóa phân tán Redis. Nhưng khi đưa vào rà soát kỹ thuật, giải pháp đó lại dính hàng loạt lỗi vận hành nghiêm trọng như: giao dịch bị hết hạn sau 10s khi khách đang mở app ngân hàng quét mã QR trả thêm cước, đơn hàng mất luôn quyền giữ hàng ở cả hai kho khi đổi kho xuất hàng, ghi vào cơ sở dữ liệu xong gửi thông báo sang đơn vị vận chuyển bị rớt mạng làm thông tin lệch nhau, và tham số chống trùng lặp chỉ để làm cảnh trên API mà không có chốt chặn dưới cơ sở dữ liệu...

Nhiều bạn làm sản phẩm hay lập trình sẽ thắc mắc: Tại sao AI trông có vẻ rất thông minh, viết tài liệu bài bản như vậy, mà khi giải quyết bài toán thực tế lại hay tạo ra những giải pháp dễ toang như thế?

Bên cạnh những hạn chế kỹ thuật mà chúng ta hay nhắc tới — như giới hạn về ngữ cảnh (context window), hiện tượng trôi thông tin khi trao đổi dài (context drift), hay khả năng lưu trữ trí nhớ giữa các phiên làm việc (memory)... thì còn một nguyên nhân nữa dẫn đến tình trạng này là giả định (assumptions) của AI.

Tức là khi đưa ra bất kỳ giải pháp nào, AI sẽ mặc định hệ thống đang chạy trong một môi trường lý tưởng: các module tự động hiểu nhau, người dùng thao tác theo tuần tự nhất định, dữ liệu đầu vào luôn chuẩn chỉnh, và không bị conflict về tài nguyên, dữ liệu...

Hay nói cách khác, AI chỉ nhìn thấy và ưu tiên luồng thuận (happy path). Thực tế thì, nếu người làm BA, Product hay Developer không chủ động bóc tách/phân tích những giả định đó của AI, chúng ta sẽ rất dễ mang một giải pháp chỉ chạy được trên giấy vào áp dụng cho một hệ thống vận hành thực tế.

---

1. AI đang ngầm giả định những gì?

Kinh nghiệm của mình khi làm việc với AI, những giả định ngầm của AI thường xoay quanh 3 nhóm rất phổ biến:

1: Giả định về mối liên kết giữa các layer của hệ thống:

Khi làm việc với AI qua từng câu lệnh (prompt), AI thường xử lý một chiều:

• Thiên lệch làm Backend trước hoặc Frontend trước: AI rất hay tập trung viết logic Backend trước rồi bỏ qua hoặc làm với assumption là Frontend sẽ mặc định khớp, hoặc vẽ giao diện đổi địa chỉ trên web nhưng lại quên thiết kế cơ chế cảnh báo cho người dùng biết đơn hàng đang bị tạm dừng đóng gói để chờ trả phụ thu cước.
• Bỏ quên mắt xích giữa các module trong cùng hệ thống: Thiết kế xong chức năng đổi địa chỉ ở module Đơn hàng (Order), AI bỏ quên hoặc giả định rằng các tính năng của module Kho (WMS) và module Vận chuyển (TMS) sẽ tự động khớp với những gì vừa sửa.
• Lệch pha về cấu trúc dữ liệu: Module A trả về một kiểu dữ liệu nhưng Module B lại cần các trường thông tin khác, AI ngầm giả định dữ liệu giữa các tầng luôn ăn khớp mà không định nghĩa rõ ràng Schema ràng buộc hai bên.

2: Giả định về hành vi người dùng và dữ liệu đầu vào

AI nhìn nhận tương tác của con người rất đơn giản:

• Người dùng luôn nhập đúng định dạng, không bao giờ bỏ trống hoặc không gõ ký tự lạ.
• Khách hàng luôn thao tác tuần tự: bấm nút một lần, kiên nhẫn đợi server xử lý xong xuôi rồi mới làm tiếp bước sau.
• Không tính đến việc người dùng sốt ruột bấm gửi 2–3 lần liên tiếp, hoặc khách thoát app giữa chừng khi đang quét mã thanh toán...
• Điều này dẫn đến việc thiết kế của AI sẽ lờ đi rất nhiều các exception case mà đáng nhẽ phải có.

3: Giả định về tài nguyên dùng chung và ràng buộc nghiệp vụ

• AI hay xem tài nguyên trong hệ thống (như hàng tồn kho, chỗ ngồi, số dư) là dữ liệu tĩnh của riêng một người dùng, quên mất việc cùng một tích tắc đó có hàng chục người khác cũng đang bấm mua món hàng cuối cùng.
• AI thường bỏ qua các quy tắc nghiệp vụ liên đới hoặc tính liên kết giữa các dữ liệu: Ví dụ nghĩ đơn giản cước đổi địa chỉ là phí mới - phí cũ, mà quên mất đơn hàng gốc có thể đang được sàn tài trợ voucher freeship (đổi địa chỉ làm mất quyền lợi trợ giá), hoặc phát sinh chênh lệch tiền cước thì phải xuất lại hóa đơn GTGT điện tử (E-Invoice) theo quy định thuế chẳng hạn.

---

2. Case study Đổi địa chỉ giao hàng: AI đã ngầm giả định sai điều gì?

Quay lại tính năng đổi địa chỉ ở bài trước, khi bóc tách chi tiết từng thiết kế của AI, các bạn sẽ thấy rõ những giả định ngầm mà AI coi là hiển nhiên:

1. Khóa Redis 10 giây khi phát sinh phụ thu cước

• Giả định: Việc khách trả tiền chênh lệch cước diễn ra tức thì trong vài giây, hoặc khách thao tác liên tục không rời mắt khỏi màn hình.
• Có thể thực tế là: Khách phải chuyển qua ứng dụng ngân hàng, quét mã QR, xác thực sinh trắc học hoặc OTP. Quá trình này thường mất 1 đến 2 phút.
• Hậu quả: Giao dịch bị hết hạn sau 10s trước khi khách hàng kịp xử lý cước phụ thu.

2. Kiểm tra kho mới rồi mới hủy giữ hàng ở kho cũ

• Giả định: Kho hàng chỉ phục vụ riêng cho đơn hàng này, không có ai khác mua hàng cùng lúc.
• Có thể thực tế là: Đang trong khung giờ bán hàng cao điểm, kho mới chỉ còn đúng 1 sản phẩm cuối cùng. Hệ thống vừa hủy giữ hàng ở kho cũ xong thì một khách khác bấm mua mất sản phẩm tại kho mới.
• Hậu quả: Đơn hàng mất luôn quyền giữ hàng ở cả 2 kho, rơi vào tình trạng thiếu hàng không thể xuất xưởng.

3. Lưu dữ liệu xong gọi thẳng sang hệ thống tin nhắn

• Giả định: Lưu địa chỉ mới vào database xong thì việc gửi thông báo sang đơn vị vận chuyển kiểu gì cũng thành công 100%.
• Có thể thực tế là: Cơ sở dữ liệu vừa lưu xong địa chỉ mới (Hà Nội) thì API sang hệ thống vận chuyển gặp bug mà k có luồng fallback/backup hay các cơ chế khoá (ví dụ khoá tính năng xác nhận giao hàng cho bên vận chuyển ở hệ thống hiện tại cho đến khi API gửi thông tin giao vận cập nhật thành công qua hệ thống của bên vận chuyển chẳng hạn). Tin nhắn thông báo bị rớt giữa chừng.
• Hậu quả: Trên web nội bộ hiển thị địa chỉ mới, nhưng kho và bên vận chuyển vẫn in nhãn dán giao về địa chỉ cũ (Đà Nẵng).

4. Xử lý chống trùng lặp chỉ nằm trên API

• Giả định: Mỗi yêu cầu chỉ được gửi đến máy chủ đúng một lần duy nhất, code ứng dụng tự kiểm soát được.
• Có thể thực tế là: Mạng chập chờn, khách sốt ruột bấm gửi 2 lần liên tiếp, hoặc trình duyệt tự động gửi lại yêu cầu khi chưa nhận được phản hồi.
• Hậu quả: Trong cơ sở dữ liệu không cài đặt chỉ mục duy nhất (Unique Index), dẫn đến việc hệ thống ghi nhận 2 lần phụ thu cước và trừ tiền của khách 2 lần.

---

3. Rèn luyện tư duy phản biện khi làm việc với AI qua I/O Flow

Nhiều bạn mới làm việc với AI thường hỏi mình: "Làm sao để biết AI đang giả định sai ở đâu mà hỏi vặn lại nó, khi bản thân mình chưa có kinh nghiệm hoặc kiến thức về hệ thống và nghiệp vụ?"

Kinh nghiệm của mình là: Hãy rèn luyện tư duy phản biện bằng cách phân rã tính năng theo luồng I/O Flow (Input -> Process -> Output) cho từng bước.

Khi đã bẻ nhỏ bài toán thành từng mắt xích cụ thể, bất kỳ ai cũng có thể rà soát và bóc tách giả định của AI theo 2 bước sau:

Bước 1: Yêu cầu AI phân rã luồng xử lý thành các bước rõ ràng

Mỗi bước trong quy trình phải chỉ rõ:

• Input: Bước này nhận dữ liệu gì, do ai gửi đến, từ module nào?
• Process: Kiểm tra điều kiện gì, tính toán ra sao, cần gọi sang module nào khác?
• Output: Trả về kết quả gì, lưu dữ liệu vào đâu, và chuyển tiếp thông tin cho module nào tiếp theo?

Bước 2: Dùng Critical Thinking ở mỗi bước bằng câu hỏi What-If

Khi đã có từng bước qua I/O Flow, các bạn chỉ cần đặt 3 câu hỏi kiểm chứng tại mỗi bước. Ví dụ:

1. Input: "Nếu đầu vào bị thiếu, sai định dạng, hoặc người dùng bấm gửi liên tiếp 2 lần do mạng chậm thì bước này xử lý ra sao?"

   • Theo case study: Câu hỏi này buộc AI phải đưa chốt chặn xuống đúng nơi cần đặt: Lưu mã giao dịch vào bảng dữ liệu với loại là unique, thay vì chỉ để tham số cho có trên API.

2. Process: "Bước này có phụ thuộc vào module khác không? Nếu có nhiều user cùng thao tác thì sao?"

   • Theo case study: Câu hỏi này buộc AI phải sửa đổi cách điều phối kho: Phải giữ chỗ thành công tại kho mới trước (Reserve first), khóa chắc chắn 1 sản phẩm rồi mới nhả hàng ở kho cũ. Không bao giờ để đơn hàng rơi vào tình trạng mất hàng ở cả hai nơi.

3. Output: "Dữ liệu trả về sẽ được dùng ở đâu? Ai dùng? Có khớp với API Contract của module tiếp theo không?..."

   • Theo case study: Thay vì dùng khóa Redis 10 giây, câu hỏi này buộc AI phải thiết kế một trạng thái nghiệp vụ rõ ràng: Chuyển đơn sang trạng thái CHỜ_THANH_TOÁN_PHỤ_THU trong 15 phút và thông báo rõ ràng cho cả module Kho lẫn giao diện người dùng.

---

4. Mẫu prompt thực tế các bạn có thể dùng ngay

Khi yêu cầu AI thiết kế một tính năng hay viết một đoạn xử lý, thay vì chỉ mô tả nghiệp vụ một chiều, các bạn nên kèm theo một đoạn rà soát theo I/O Flow như sau:

"Với tính năng bạn vừa đề xuất, hãy thực hiện rà soát theo 2 bước:1. Hãy phân rã luồng xử lý thành từng bước cụ thể theo I/O Flow (chỉ rõ Đầu vào - Xử lý - Đầu ra cho từng module liên quan).2. Tại MỖI BƯỚC, hãy tự phản biện bằng ít nhất 3 câu hỏi. Ví dụ như:

• Đầu vào: Nếu người dùng bấm gửi 2 lần liên tiếp hoặc thoát app giữa chừng thì sao?*
• Xử lý: Nếu module phụ thuộc phản hồi chậm hoặc có tranh chấp tài nguyên đồng thời thì sao?*
• Đầu ra: Dữ liệu gửi sang module tiếp theo có đảm bảo không bị thất lạc nếu rớt mạng không?* Hãy chỉ rõ các điểm hệ thống có thể bị toang và bổ sung phương án chốt chặn tương ứng."

Chỉ cần một prompt định hướng theo I/O Flow như vậy, AI sẽ bị kéo ra khỏi luồng êm đẹp trên giấy và chỉ ra cho các bạn chính xác những điểm cần gia cố.

---

5. Lời kết

Thực tế thì, AI chỉ xử lý thông tin dựa trên những gì chúng ta cung cấp và luôn có xu hướng chọn kịch bản thuận lợi nhất. Nó không thể tự lường trước các va vấp ngoài đời thực nếu chúng ta không chủ động đặt ra các điều kiện kiểm soát.

Bản chất vấn đề là: Một bản thiết kế tốt không chỉ dừng lại ở việc mô tả hệ thống chạy thế nào khi mọi thứ đều đúng, mà quan trọng là kiểm soát được hệ thống khi có lỗi xảy ra.

Kinh nghiệm của mình là khi làm việc với AI, các bạn nên tập thói quen bóc tách từng bước theo I/O Flow và liên tục đặt câu hỏi phản biện. Khi đó, AI sẽ trở thành một trợ thủ đắc lực giúp bạn rà soát các trường hợp ngoại lệ, thay vì để lại những lỗ hổng kỹ thuật cho hệ thống sau này.

Hy vọng góc nhìn này sẽ hữu ích cho các bạn khi cộng tác cùng AI trong các dự án thực tế!