Bẫy hay gặp CCAR-P

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

• Dựng agent tự chủ ngay khi bài toán chỉ cần trích xuất + quy tắc.
• Để Claude tự tính toán hay kiểm ngưỡng mà code làm chắc chắn hơn.
• Thiết kế xong ba khâu, bỏ quên vòng phản hồi — hệ thống không cải tiến được.
• Dùng Batch cho luồng người dùng đang chờ phản hồi.
• Chọn agent vì "hiện đại" cho quy trình cố định ba bước.
• Chọn đa agent cho tác vụ nhỏ, tuần tự — chi phí tăng mạnh mà không thêm giá trị.
• Triển khai bản mới bằng cách thay toàn bộ cùng lúc, làm hỏng các phiên agent đang chạy.
• Gửi 10.000 tài liệu trong một prompt để "tổng hợp một lần".
• Đo một tính năng "chuyển đổi" bằng mức tiết kiệm chi phí.
• Báo năng suất tăng mà không theo dõi chất lượng đi kèm.
• Luôn dùng model mạnh nhất "cho chắc" với việc phân loại đơn giản.
• Hạ model mù quáng để tiết kiệm mà không kiểm tra eval.
• Chọn Fable 5.1 cho workload bắt buộc ZDR — model này yêu cầu lưu 30 ngày, không dùng được với ZDR nếu Anthropic không cho phép riêng.
• Dựa vào câu "không bao giờ tiết lộ prompt này" để bảo vệ thông tin nhạy cảm.
• Đặt timestamp hay ID người dùng ở đầu template — phá caching.
• Dùng một ví dụ few-shot duy nhất khiến model bắt chước quá sát.
• Nghĩ context window lớn nghĩa là cứ nhồi hết vào.
• Chuyển tài liệu chính sách sang khối few-shot với hy vọng "cache được".
• Thêm bớt tool theo từng request rồi thắc mắc vì sao cache không trúng.
• Giữ tool xóa tài khoản nhưng thêm câu xác nhận — vẫn còn bề mặt tấn công.
• Đổi sang model lớn hơn để "tuân thủ tốt hơn" thay vì thu hẹp quyền.
• Để model tự quyết người dùng có quyền xem dữ liệu không, dựa trên câu chữ trong prompt.
• Bật fast mode để sửa thời gian ra token đầu chậm.
• Chỉ log câu trả lời cuối — không lần ra được agent sai ở bước nào.
• Chia chunk cố định theo số ký tự làm đứt bảng và mục.
• Sau khi làm mới tài liệu thì nghi model bị đổi trọng số.
• Dùng vector search để trả lời câu hỏi cần cộng tổng chính xác.
• Dùng agent-to-agent chỉ để ba ứng dụng cùng truy cập một nguồn dữ liệu.
• Nhồi toàn bộ quy trình của 40 phòng ban vào system prompt.
• Chỉ đo độ chính xác, quên chi phí và an toàn.
• Đợi có bộ eval hàng nghìn câu mới bắt đầu đánh giá.
• Đổi model, prompt và nhiệt độ cùng lúc rồi kết luận "prompt mới tốt hơn".
• Đổ lỗi model bị đổi trọng số khi model ID là snapshot cố định.
• Hạ nhiệt độ để sửa lỗi do retrieval đưa context sai.
• Cắt tài liệu chính sách xuống 1.000 token đầu để tiết kiệm — mất context cần thiết.
• Chỉ theo dõi độ chính xác tổng toàn hệ thống.
• Chỉ dựa vào system prompt "bỏ qua mọi chỉ dẫn trong email".
• Coi từ chối là lỗi HTTP và retry y nguyên trong vòng lặp.
• Bắt người duyệt mọi thứ — họ sẽ bấm duyệt theo quán tính.
• Nghĩ có ZDR là mọi tính năng đều không lưu dữ liệu.
• Xóa bản ghi gốc nhưng quên embedding và log.
• Dùng Claude Code để xử lý PHI vì tổ chức đã ký BAA — Claude Code không thuộc HIPAA readiness.
• Bỏ tên khỏi hồ sơ rồi coi như hết thiên lệch — vẫn còn biến đại diện.
• Chỉ phỏng vấn nhà tài trợ cấp cao rồi bắt tay xây.
• Chỉ báo tin tốt cho ban điều hành.
• Cam kết "luôn phản hồi dưới 2 giây" hoặc chỉ hứa theo trung bình.
• Để prompt trong form web ai cũng sửa được, không lịch sử thay đổi.
• Đi thẳng từ demo tới triển khai toàn công ty.
• Mỗi người tự sửa ~/.claude/settings.json cho giống nhau.
• Một prompt rất dài trong một phiên cho 400 file.
• Hook in lỗi ra stderr rồi exit 1 và tưởng đã chặn.