Bẫy hay gặp CCAO-F

Kiểu phương án sai thường gặp, gom theo topic.

• Prompt chỉ có động từ ("Tóm tắt file này") mà không nói tóm tắt cho ai, để làm gì.
• Mô tả phong cách bằng tính từ thay vì đưa ví dụ.
• Nhồi cả chục yêu cầu vào một prompt dài rồi sửa toàn bộ khi một phần sai.
• Chia nhỏ cả những việc đơn giản một bước — tốn công mà không lợi gì.
• Phản hồi chung chung kiểu "làm tốt hơn đi".
• Đổi nhiều thứ cùng lúc nên không biết thay đổi nào có tác dụng.
• Brainstorm mà bắt Claude chọn ngay phương án tốt nhất.
• Dùng cùng một mẫu prompt cho mọi loại việc.
• Đánh giá đầu ra là "đủ" vì nó viết trôi chảy, có cấu trúc đẹp.
• Nhờ Claude tự kiểm tra lại số liệu của chính nó và coi đó là đã xác minh.
• Tin trích dẫn vì nó có số hiệu và tên văn bản trông rất cụ thể.
• Gặp hai con số mâu thuẫn thì chọn con số "hợp lý hơn".
• Kiểm thử vài trích dẫn đầu, thấy đúng nên coi cả danh sách là đúng.
• Ép Claude luôn phải có câu trả lời, kể cả khi tài liệu không có.
• Nhờ Claude "kiểm tra lại trích dẫn" thay vì tự mở văn bản gốc — đó không phải kiểm chứng độc lập.
• Duyệt tay 100% mọi đầu ra thường ngày — tốn kém, không tương xứng.
• Bỏ qua duyệt vì deadline gấp với văn bản gửi khách hàng.
• Bản cho lãnh đạo "làm tròn" con số cho dễ nghe, lệch với bản cho đội kỹ thuật.
• Tạo artifact cho một câu trả lời hai dòng.
• Trả danh sách 200 khách hàng dạng đoạn văn khi người dùng cần lọc trong Excel.
• Dán lại cùng bộ tài liệu vào mỗi chat mới thay vì dùng Project.
• Dùng chat thường cho câu hỏi cần thông tin mới nhất từ nhiều nguồn.
• Ghi quy trình chuẩn của cả nhóm vào custom instructions của từng người — nên dùng Skill (Owner cấp cho tổ chức) hoặc Project chia sẻ.
• Nghĩ model đắt nhất luôn là lựa chọn đúng.
• Dùng model mạnh nhất cho hàng nghìn email phản hồi ngắn.
• Tắt hết tính năng hoặc đổi nền tảng để "tiết kiệm".
• Cho rằng chọn model không quan trọng vì Research tự chạy trên model mạnh — điều đó chỉ đúng với Research; chat thường dùng model bạn chọn.
• Tiếp tục một cuộc chat rất dài cho chủ đề hoàn toàn mới.
• Mỗi tuần dán lại toàn bộ bối cảnh dự án thay vì lưu vào Project.
• Nghĩ incognito nghĩa là dữ liệu không được lưu ở đâu cả.
• Chọn use case chỉ vì nó "ấn tượng", dù kết quả không kiểm tra được.
• Hỏi "Vì sao phương án A là tốt nhất?" — câu hỏi đã định sẵn câu trả lời.
• Áp dụng ngay kế hoạch Claude đề xuất mà không hỏi người làm thực tế.
• Đưa artifact mẫu vào dùng như phần mềm production cho cả công ty.
• Bắt cả nhóm chuyển sang quy trình hoàn toàn mới chỉ để dùng AI.
• Cho connector hoặc Cowork tự gửi email cho khách hàng mà không duyệt, "để tiết kiệm thời gian".
• Hứa "AI làm được hết, không cần kiểm tra" để dự án được duyệt.
• Tải mọi tài liệu có được vào Project "cho chắc".
• Cho mọi thành viên quyền Can edit.
• Nghĩ connector cho Claude xem được mọi file trong công ty.
• Thêm thư mục Drive vào Project chia sẻ của nhóm để "luôn đồng bộ" — Drive chỉ thêm được vào Project riêng tư.
• Tải bản sao tĩnh của tài liệu hay thay đổi rồi quên cập nhật.
• Viết chỉ dẫn toàn điều cấm mà không nói nên làm gì.
• Đặt quy tắc riêng của một dự án vào chỉ dẫn cấp tài khoản, làm ảnh hưởng mọi chat khác.
• Phát quy trình chuẩn cho cả tổ chức bằng cách nhờ từng người dán vào account instructions — dùng Skill do Owner cấp.
• Thêm bản chính sách mới nhưng vẫn giữ bản cũ trong knowledge.
• Để Claude tự quyết định duyệt hồ sơ vay mà không có người kiểm tra.
• Tải nguyên file vì "chỉ phân tích nội bộ thôi".
• Bỏ hẳn việc phân tích dù ẩn danh dữ liệu là đủ.
• Dùng incognito để tải dữ liệu bị quy định "vì không lưu lại" — incognito vẫn được lưu 30 ngày và không phải biện pháp kiểm soát của chính sách.
• "Memory không bao giờ lưu số tài khoản nên tải lên được" — quy tắc của memory không phải quản trị dữ liệu.
• Nhập dữ liệu nhạy cảm vào artifact dùng shared storage — mọi người dùng artifact đó đều thấy cùng dữ liệu.
• Dùng công cụ AI cá nhân chưa được duyệt với dữ liệu khách hàng vì "nhanh hơn".
• Tự diễn giải chính sách mơ hồ theo hướng có lợi cho deadline.
• Đăng bài phát biểu do AI viết dưới tên giám đốc mà chưa được duyệt.
• Đổ lỗi cho AI khi sản phẩm mình gửi đi có sai sót.
• Viết hoa và lặp lại chỉ dẫn nhiều lần khi nguyên nhân là dữ liệu nguồn thiếu.
• Đổi model ngay khi kết quả kém thay vì kiểm tra prompt và dữ liệu.
• Chỉ đo tốc độ, bỏ qua tỉ lệ lỗi sau khi tối ưu.
• Bỏ hẳn bước kiểm tra để quy trình nhanh hơn.