Bẫy thi thường gặp
Đề CCAR-F hiếm khi đưa đáp án sai lộ liễu. Bốn phương án thường đều “nghe hợp lý”; cái sai là sai vì nó chữa triệu chứng, đổ lỗi sai khâu, hoặc dùng cơ chế xác suất cho yêu cầu tất định. Trang này liệt kê đúng những cặp đó.
Bốn mẫu bẫy xuyên suốt
Phần tiêu đề “Bốn mẫu bẫy xuyên suốt”- “Dùng model mạnh hơn / context window to hơn” — gần như luôn sai. Attention dilution và context degradation là vấn đề kiến trúc, không phải dung lượng.
- “Viết prompt rõ hơn” cho yêu cầu bắt buộc — prompt là xác suất (~90–95%), không bao giờ đạt 100%. Đáp án là hook hoặc code gate.
- “Dựa vào điểm confidence của model” — LLM hiệu chỉnh confidence rất kém; chỉ dùng được sau khi hiệu chỉnh bằng tập có nhãn.
- Đổ lỗi cho khâu cuối cùng — báo cáo thiếu chủ đề thì lỗi ở khâu phân rã; mất trích dẫn thì lỗi ở khâu truyền context. Luôn truy về điểm phát sinh.
Domain 1 — Kiến trúc Agentic & Điều phối
Phần tiêu đề “Domain 1 — Kiến trúc Agentic & Điều phối”| Bẫy | Đáp án đúng |
|---|---|
| Dùng sự hiện diện của text để kết luận agent đã xong | Đọc stop_reason; Claude trả text cùng lúc với block tool_use |
| Coi iteration cap là logic dừng chính | stop_reason là cơ chế chính; cap chỉ là chốt an toàn |
| “Tăng iteration cap” để chữa kết thúc sớm | Cap không quyết định thời điểm Claude dừng |
| Bắt các cụm từ như “I have finished” | Parse ngôn ngữ tự nhiên luôn mơ hồ |
Ép tool_choice: "any" để chặn model trả text |
Tạo vòng lặp vô hạn |
| Đổ lỗi cho subagent khi báo cáo thiếu phạm vi | Nguyên nhân gốc là khâu phân rã của coordinator |
| Cho rằng subagent kế thừa context / chia sẻ bộ nhớ | Mỗi lần gọi subagent là độc lập, phải truyền tường minh |
| Cho subagent nói chuyện trực tiếp với nhau | Phá vỡ observability; mọi thứ qua coordinator |
| Thêm subagent để chữa phân rã hẹp | Subagent mới cũng nhận phần việc hẹp y hệt |
| Đổ lỗi mất trích dẫn cho agent tổng hợp | Coordinator đã bỏ metadata khi truyền |
| Gọi subagent tuần tự cho các việc độc lập | Spawn song song trong một response |
Nhầm fork_session với --resume |
Fork để rẽ nhánh phân kỳ; resume để đi tiếp mạch cũ |
| “Prompt mạnh hơn” để đạt tuân thủ 100% | Prerequisite gate ở tầng code |
| Few-shot là đủ cho yêu cầu tuân thủ | Vẫn là xác suất |
| Dùng classifier định tuyến để cưỡng chế quy trình | Classifier giải bài toán định tuyến, không phải cưỡng chế |
| Bản bàn giao thiếu customer ID / hành động đề xuất | Người nhận không đọc được transcript, bản tóm tắt phải tự chứa |
Dùng PostToolUse để chặn hành động |
Chỉ PreToolUse mới ngăn được; Post chạy sau khi đã thực thi |
| Để model tự chuẩn hoá dữ liệu khác định dạng | PostToolUse chuẩn hoá trước khi model nhìn thấy |
| “Model mạnh hơn / context to hơn” chữa attention dilution | Kiến trúc multi-pass: lượt theo từng file + lượt tích hợp |
| Prompt tốt hơn thay được multi-pass | Prompt nâng chất lượng trung bình, không đổi cách phân bổ chú ý |
| Chia lô mà bỏ lượt tích hợp | Bỏ sót vấn đề xuyên lô |
| Quét lại toàn bộ codebase khi chỉ vài file đổi | Phân tích lại có trọng điểm |
--resume sau khi file đã bị sửa |
Phiên mới + summary injection |
Dùng fork_session để chữa stale context |
Fork kế thừa luôn context lỗi thời |
Domain 2 — Thiết kế Tool & MCP
Phần tiêu đề “Domain 2 — Thiết kế Tool & MCP”| Bẫy | Đáp án đúng |
|---|---|
| Dùng few-shot để chữa chọn nhầm tool | Mở rộng mô tả tool trước |
| Dựng classifier định tuyến ngay từ đầu | Quá mức cần thiết |
| Gộp tool như bước đầu tiên | Đúng về dài hạn nhưng tốn công; sửa mô tả trước |
| Bỏ qua xung đột với system prompt | System prompt có thể âm thầm ghi đè mô tả tool |
| Retry khi truy vấn thành công nhưng trả 0 kết quả | Kết quả rỗng là câu trả lời hợp lệ |
| Trả thông báo lỗi chung chung | Kèm errorCategory, isRetryable, description |
| Coi lỗi nghiệp vụ (business) là retry được | isRetryable: false; đi luồng khác hoặc leo thang |
Hiểu isRetryable: false là “bỏ nhiệm vụ” |
Nghĩa là “gọi y hệt sẽ hỏng y hệt” |
| Nuốt lỗi subagent bằng cách trả rỗng và báo thành công | Lan truyền lỗi có cấu trúc |
| Kỳ vọng 18 tool trong một agent vẫn ổn định | 4–5 tool mỗi agent |
Dùng tool_choice: auto khi cần structured output bảo đảm |
any hoặc forced |
Tưởng any ép gọi đúng một tool cụ thể |
any chỉ ép có gọi tool; forced mới chỉ đích danh |
| Tưởng chia nhiều MCP server làm giảm số tool | Client thấy tất cả như một danh sách phẳng |
| Tự xây MCP server cho tích hợp tiêu chuẩn | Khảo sát server cộng đồng trước |
Đặt server dùng chung vào ~/.claude.json |
Phải nằm trong .mcp.json |
| Commit credential trực tiếp | Dùng ${BIẾN_MÔI_TRƯỜNG} |
| Để mô tả tool MCP sơ sài | 3–5 câu, nếu không tool tích hợp sẵn sẽ được ưu tiên |
| Dùng Glob để tìm nơi gọi hàm | Glob khớp đường dẫn; dùng Grep |
| Dùng Grep để tìm theo phần mở rộng file | Glob mới dành cho đường dẫn |
| Đọc hết mọi file ngay từ đầu | Grep → Read → Grep → Read |
| Mặc định Read + Write để sửa file | Edit; nếu trùng khớp thì mở rộng neo hoặc replace_all |
Domain 3 — Cấu hình & Quy trình Claude Code
Phần tiêu đề “Domain 3 — Cấu hình & Quy trình Claude Code”| Bẫy | Đáp án đúng |
|---|---|
| Thành viên mới không nhận quy ước dù cùng repo | Quy ước nằm ở ~/.claude/CLAUDE.md; chuyển sang cấp dự án |
/memory kích hoạt việc nạp cấu hình |
Chỉ chẩn đoán; cấu hình tự nạp theo vị trí |
| “Phạm vi hẹp hơn thì thắng” / “user ghi đè project” | Các file nối chuỗi; mâu thuẫn giải quyết tuỳ ý |
Dùng CLAUDE.md thư mục con cho quy ước trải nhiều thư mục |
.claude/rules/ + glob |
Tưởng @ import giảm context mỗi phiên |
Chỉ giúp dễ bảo trì; rules có paths: mới giảm thật |
Tạo file .md phẳng trong .claude/skills/ |
Skill phải là thư mục có SKILL.md |
Đặt command dùng chung vào ~/.claude/ |
Đặt trong .claude/ của dự án |
| Coi skill như hướng dẫn luôn bật | Skill nạp theo nhu cầu; CLAUDE.md mới luôn bật |
Bỏ context: fork cho tác vụ sinh output dài |
Ô nhiễm context chính |
| Coi hook là guardrail dạng prompt | Hook là code tất định |
| Mặc định thực thi thẳng cho thay đổi nhiều file | Plan mode trước, rồi execute |
| Lập kế hoạch quá mức cho bug một file | Thực thi thẳng |
| Gọt thêm văn xuôi khi output không nhất quán | Chuyển sang ví dụ cụ thể |
| Lẫn interview pattern với kỹ thuật ví dụ | Interview cho lĩnh vực lạ; ví dụ cho diễn giải không nhất quán |
| CI treo vì chờ input | Cờ -p; CLAUDE_HEADLESS và --batch không tồn tại |
Tưởng -p bật plan mode |
-p là chế độ không tương tác |
Tưởng --append-system-prompt thay prompt |
Nó chỉ nối thêm; --system-prompt mới thay |
| Review code ngay trong phiên đã viết code | Phiên độc lập, không chia sẻ lập luận |
| Bỏ qua phát hiện của lần review trước | Truyền vào và yêu cầu chỉ báo cái mới / chưa sửa |
| Dùng Batch API cho kiểm tra chặn merge | Batch không có SLA độ trễ |
Domain 4 — Prompt Engineering & Structured Output
Phần tiêu đề “Domain 4 — Prompt Engineering & Structured Output”| Bẫy | Đáp án đúng |
|---|---|
| Chọn cải thiện mơ hồ kiểu “hãy thận trọng hơn” | Tiêu chí phân loại tường minh |
| Tưởng ngưỡng confidence chữa được false positive | Confidence tự báo hiệu chỉnh kém |
| Giữ mọi hạng mục bật trong lúc sửa hạng mục lỗi | Tắt tạm hạng mục đang lỗi để giữ niềm tin |
| Định nghĩa severity bằng văn xuôi | Dùng ví dụ code cụ thể |
| “Thêm chỉ dẫn” khi output không nhất quán | 2–4 ví dụ few-shot |
| Đưa 10+ ví dụ few-shot | Lợi ích giảm dần sau 4 ví dụ |
| Ví dụ không kèm lý do | Không có lý do thì model chỉ khớp mẫu máy móc |
Tưởng tool_use ngăn mọi lỗi trích xuất |
Chỉ ngăn lỗi cú pháp, không ngăn lỗi ngữ nghĩa |
| Đặt mọi trường là bắt buộc | Chính điều đó ép model bịa; dùng optional/nullable |
| Dùng JSON theo prompt trong production | Không có cơ chế cưỡng chế; dùng tool_use + schema |
| Retry với thông điệp “thử lại đi” | Kèm tài liệu gốc + output lỗi + lỗi cụ thể |
| Tin rằng mọi lỗi trích xuất đều retry được | Thiếu thông tin trong nguồn thì retry vô ích |
| Coi Pydantic là thừa khi đã có schema | Schema lo cấu trúc; validator lo ngữ nghĩa |
| Chuyển hết workload sang Batch để tiết kiệm | Luồng blocking phải dùng đồng bộ |
| Thiết kế dựa trên việc “batch thường trả nhanh” | Không có SLA; phải tính theo 24 giờ |
| Tự review trong cùng phiên | Instance độc lập |
| Một lượt review cho nhiều file | Lượt theo file + lượt tích hợp |
| Định tuyến tự động theo confidence chưa hiệu chỉnh | Hiệu chỉnh bằng tập validation có nhãn trước |
Domain 5 — Quản lý Context & Độ tin cậy
Phần tiêu đề “Domain 5 — Quản lý Context & Độ tin cậy”| Bẫy | Đáp án đúng |
|---|---|
| “Tóm tắt hội thoại để tiết kiệm context” | Khối dữ kiện bền vững, chép nguyên văn |
| Cắt xén chọn lọc lịch sử hội thoại | Tách dữ kiện ra khối riêng ngoài vùng tóm tắt |
| Tưởng prompt chữa được lost in the middle | Đặt thông tin then chốt ở đầu / cuối input |
| Để tool result phình rồi mới dọn | Cắt gọn bằng PostToolUse ngay từ đầu |
| Leo thang theo cảm xúc khách hàng | Bực bội không tương quan với độ phức tạp |
| Leo thang theo confidence tự báo | Không đáng tin |
| Cố giải quyết trước khi khách đòi gặp người thật | Tôn trọng yêu cầu ngay lập tức |
| Nhầm policy violation với policy gap | Gap ⇒ leo thang; violation ⇒ từ chối kèm giải thích |
| Chọn bản ghi “mới nhất” khi khớp nhiều khách hàng | Hỏi thêm định danh |
| Trả rỗng và báo thành công khi thực chất timeout | Structured error context |
| Dừng cả pipeline khi một subagent lỗi | Phục hồi có trọng điểm, giữ kết quả một phần |
| “Tăng context window” chữa context degradation | Vấn đề là chất lượng chú ý; dùng scratchpad |
| Cho rằng subagent có lợi chủ yếu vì chạy nhanh | Lợi ích chính là cô lập context |
| Khởi động lại mà chưa lưu trạng thái | Scratchpad hoặc state manifest |
Coi /compact là biện pháp cuối cùng |
Dùng chủ động, phòng ngừa |
| “97% độ chính xác tổng ⇒ đáng tin” | Bóc tách theo loại tài liệu và theo trường |
| Chỉ lấy mẫu nhóm confidence thấp | Lấy mẫu phân tầng gồm cả nhóm confidence cao |
| Hàng đợi review theo thứ tự thời gian | Sắp xếp động theo mức bất định |
| Chọn nguồn mới nhất khi các nguồn mâu thuẫn | Giữ cả hai kèm nguồn và ngày |
| Coi số liệu khác thời điểm là mâu thuẫn | Ngày tháng biến chúng thành xu hướng |
| Trích dẫn nội tuyến là đủ cho production | Claim-source mapping có cấu trúc |
| Ép mọi nội dung vào một định dạng | Bảng cho số liệu, văn xuôi cho diễn biến, danh sách cho thông số |