Câu trả lời của AI hữu ích, nhưng nó bỏ qua phần nó đã đoán. Nó assume endpoint là internal, user đã authenticated, data đã tenant-scoped, và test fixture giống production shape. Không assumption nào lạ. Chính vì vậy chúng cần được gọi tên.
Language model lấp khoảng trống. Đó là một phần khiến chúng hữu ích. Chúng có thể tiếp tục khi câu hỏi của con người chưa đầy đủ. Nhưng khoảng trống được lấp có thể nguy hiểm khi nó trông như knowledge thay vì assumption.
Một thói quen đơn giản giúp nhiều: yêu cầu model gọi tên những điều nó đang assume. Không phải sau final answer, mà là một phần của answer. Assumption list trở thành bản đồ cho verification tiếp theo.
Với code, assumption thường ẩn quanh runtime behavior. Đây là server-side hay client-side? Data có trusted không? Function có thể retry không? Caller đã có authorization chưa? Database có guarantee uniqueness không? Đây không phải chi tiết nhỏ. Chúng thường là khác biệt giữa suggestion sạch và bug.
Với product writing, assumption ẩn quanh audience và intent. Reader có technical không? Mình đang persuade, explain, warn hay document? Wording cần calm, formal, local hay operational? Draft tốt phụ thuộc vào những câu trả lời đó.
Khi assumption visible, con người có thể decide. Một số assumption an toàn. Một số cần source check. Một số sai. Một số cho thấy request ban đầu thiếu context quan trọng nhất.
Điều này cũng làm collaboration bớt bí ẩn. Thay vì tranh luận với AI answer bóng bẩy, team có thể inspect scaffolding bên dưới nó. Conversation chuyển từ model có thông minh không sang assumptions có khớp reality không.
Trước khi chấp nhận AI suggestion, hãy hỏi assumption list. Rồi verify những assumption load-bearing. Answer vẫn có thể cần sửa, nhưng sẽ rõ hơn rất nhiều responsibility nằm ở đâu.