Bảng tóm tắt CCAR-F

Trang này gom ý chính của 30 bài vào một chỗ để bạn ôn trước khi thi. Mỗi ý chỉ nói ngắn; muốn hiểu vì sao thì mở bài tương ứng (số bài ghi trong ngoặc).

Đề thi gồm những gì

Sáu kịch bản

Mỗi kịch bản là một bối cảnh sản phẩm, kèm một nhóm câu hỏi. Biết kịch bản nào hay hỏi domain nào giúp bạn đoán nhanh câu hỏi đang nhắm vào đâu.

Đề nghĩ thế nào

Các câu hỏi mẫu Anthropic công bố cho thấy vài quy tắc lặp đi lặp lại. Khi phân vân giữa các đáp án, thử áp các quy tắc này:

• Sửa đúng gốc, bằng cách nhẹ nhất trước. Tool bị chọn nhầm vì mô tả sơ sài thì viết lại mô tả, chưa cần lớp định tuyến hay gộp tool (2.1).
• Việc bắt buộc tuyệt đối thì dùng code, không dùng prompt. Thứ tự gọi tool có hậu quả về tiền, quy định không được vi phạm: chọn hook hoặc điều kiện chặn trong code (1.4, 1.5).
• Không dựa vào mức tự tin model tự báo hay mức độ bực bội của khách để quyết định chuyển cho người. Viết tiêu chí rõ ràng kèm ví dụ (5.2).
• Cẩn thận với đáp án "làm to": thêm classifier riêng, thêm model phân tích cảm xúc, đổi sang model lớn hơn hay context dài hơn. Thường đó là làm quá tay khi cách đơn giản chưa thử, hoặc không giải quyết đúng vấn đề (4.6, 5.1).
• Không chọn đáp án đẩy việc cho người dùng hay dev, như bắt dev tự chia nhỏ PR (4.6).
• Không chọn tính năng không tồn tại: biến CLAUDE_HEADLESS, cờ --batch, file .claude/config.json có mảng commands (3.2, 3.6).
• Tìm đúng chỗ hỏng. Subagent làm đúng việc được giao mà kết quả vẫn thiếu thì lỗi nằm ở chỗ giao việc của agent điều phối (1.2).
• Đề đã nói việc phức tạp thì đừng chọn "cứ làm, gặp khó mới đổi cách". Độ phức tạp đã biết từ đầu (3.4).

Domain 1: Agentic Architecture & Orchestration

• Vòng lặp agent chạy tiếp khi stop_reason là tool_use, dừng khi là end_turn. Không dừng theo nội dung chữ hay theo số vòng cố định (1.1).
• Agent điều phối chia việc, giao cho subagent, gộp kết quả. Subagent không tự thấy lịch sử của agent điều phối: mọi thứ nó cần phải ghi trong lời giao việc (1.2, 1.3).
• Muốn chạy song song nhiều subagent: gọi nhiều subagent trong cùng một câu trả lời (1.3).
• Agent điều phối mô tả việc giao mà không có subagent nào chạy: danh sách tool được phép thiếu tool gọi subagent, đề gọi là Task (1.3).
• Chuyển cho người phải kèm bản tóm tắt đủ để người nhận làm tiếp mà không đọc lại cuộc trò chuyện (1.4).
• Tiếp tục phiên cũ thì --resume; muốn thử hai hướng từ cùng một điểm thì fork phiên (1.7).

1. Bước này sai thì có hậu quả không thể chấp nhận?Chặn bằng code hoặc hook
2. Các bước biết trước, cố định?Viết sẵn thứ tự trong code
3. Mỗi bước phụ thuộc điều vừa tìm ra?Để Claude tự quyết bước tiếp theo
4. Còn lạiDặn trong prompt là đủ

Domain 2: Tool Design & MCP Integration

• Claude chọn tool chủ yếu dựa vào mô tả tool. Mô tả tốt nói làm gì, đầu vào ra sao, khi nào dùng, khi nào không dùng (2.1).
• Tool đa năng một tên nhiều việc thì tách thành tool có đầu vào, đầu ra rõ ràng (2.1).
• Lỗi khi chạy tool trả về với isError: true, kèm loại lỗi, có nên thử lại không, và lời giải thích (2.2).
• Mỗi subagent chỉ có đúng bộ tool nó cần. Việc nhỏ hay gặp thì cho thêm một tool hẹp, việc phức tạp vẫn đi qua agent điều phối (2.3).
• MCP server dùng chung cho nhóm khai báo trong .mcp.json ở repo, khoá bí mật để trong biến môi trường ${VAR}; server riêng để trong ~/.claude.json (2.4).
• Grep tìm nội dung trong file, Glob tìm file theo tên. Edit không tìm được chỗ duy nhất thì Read cả file rồi Write lại (2.5).

1. Tool không kết nối được nguồn?isError, loại transient, cho thử lại
2. Đầu vào sai định dạng?isError, loại validation, nói rõ cần sửa gì
3. Vi phạm quy định hoặc thiếu quyền?isError, không thử lại, nói cách khác để làm
4. Truy vấn chạy được nhưng không có gì khớp?Trả danh sách rỗng, không phải lỗi
5. Còn lạiTrả kết quả bình thường

Domain 3: Claude Code Configuration & Workflows

• CLAUDE.md cấp user (~/.claude/CLAUDE.md) chỉ có trên máy bạn; cấp project nằm trong repo cho cả nhóm. Các file được nối lại, không file nào ghi đè file nào (3.1).
• @import giúp chia file chứ không giảm context. Rule trong .claude/rules/ có paths mới chỉ nạp khi cần (3.1, 3.3).
• Lệnh và skill dùng chung để trong .claude/commands/ hoặc .claude/skills/ của repo; bản riêng để trong thư mục home, đặt tên khác (3.2).
• context: fork chạy skill trong subagent riêng, chỉ kết quả cuối quay về. argument-hint gợi ý tham số. Đề chấm allowed-tools là cách giới hạn tool của skill (3.2).
• CI: -p để không treo, --output-format json kèm --json-schema để có kết quả máy đọc được, CLAUDE.md để đưa quy ước dự án (3.6).

1. Thay đổi lan ra nhiều file, nhiều module?Plan mode
2. Có nhiều cách làm, cần chọn?Plan mode
3. Ảnh hưởng kiến trúc hay hạ tầng?Plan mode
4. Khảo sát in ra nhiều, sợ đầy context?Giao cho subagent Explore
5. Còn lạiViệc nhỏ, rõ chỗ sửa: làm ngay

Domain 4: Prompt Engineering & Structured Output

• Tiêu chí cụ thể (báo gì, bỏ qua gì) hiệu quả hơn "hãy thận trọng" hay "chỉ báo khi chắc chắn" (4.1).
• Một loại comment báo sai nhiều làm dev mất tin cả hệ thống: tạm tắt loại đó, sửa prompt rồi mới bật lại (4.1).
• Hướng dẫn chi tiết vẫn cho kết quả không đều: thêm 2–4 ví dụ few-shot nhắm vào ca mập mờ, kèm lý do (4.2).
• Đầu ra đúng schema: định nghĩa tool có JSON schema, lấy dữ liệu từ tool_use; thêm strict: true khi làm thật. Schema không chặn được lỗi về nghĩa (4.3).
• Trường tài liệu có thể không có thì cho phép null; enum thiếu giá trị thì thêm other kèm trường mô tả, và unclear cho ca mập mờ (4.3).
• Phiên viết code không nên tự review; dùng một phiên độc lập. PR nhiều file: lượt theo từng file cộng lượt tích hợp (4.6).

1. Kết quả sai định dạng hoặc sai cấu trúc?Thử lại kèm tài liệu gốc, kết quả sai và lỗi cụ thể
2. Thông tin chỉ có trong tài liệu khác không gửi kèm?Đừng thử lại, để null và chuyển người
3. Các số tự mâu thuẫn trong tài liệu?So stated_total với calculated_total, đánh dấu để người kiểm
4. Còn lạiKết quả đạt, đi tiếp

1. Có người hoặc quy trình đang chờ kết quả?Gọi trực tiếp Messages API
2. Cần agent gọi tool của bạn nhiều vòng?Gọi trực tiếp
3. Có cam kết thời gian?Batch, khoảng cách giữa hai lô cộng 24 giờ phải nhỏ hơn cam kết
4. Còn lạiBatch, rẻ một nửa

Domain 5: Context Management & Reliability

• Tóm tắt dần làm mất số tiền, ngày, mã đơn: giữ chúng trong một khối sự thật riêng gửi kèm mỗi lượt (5.1).
• Kết quả tool có quá nhiều trường: cắt bớt trước khi vào context. Đầu vào dài: tóm tắt ở đầu, chia mục rõ (5.1).
• Ba trường hợp chuyển cho người: khách đòi gặp người, chính sách không quy định hoặc cần ngoại lệ, không tiến triển được. Nhiều khách khớp tên thì hỏi thêm thông tin, không tự chọn (5.2).
• Subagent báo lỗi kèm loại lỗi, đã thử gì, kết quả từng phần, cách khác. Không giấu lỗi, không dừng cả quy trình (5.3).
• Phiên khám phá dài trả lời chung chung: file ghi chú, hoặc tóm tắt rồi giao subagent. Sự cố giữa chừng: manifest. Context đầy: /compact (5.4).
• Độ chính xác tổng có thể che lỗi ở một nhóm: kiểm theo loại tài liệu và theo trường trước khi bớt người duyệt; lấy mẫu ngẫu nhiên theo nhóm để tiếp tục đo (5.5).
• Giữ cặp nhận định và nguồn qua các bước tổng hợp; nguồn đáng tin nói khác nhau thì ghi cả hai; kèm ngày của số liệu (5.6).

1. Khách nói rõ muốn gặp nhân viên?Chuyển ngay, không cố giải quyết trước
2. Chính sách không quy định hoặc cần ngoại lệ?Chuyển, kèm tóm tắt
3. Đã thử mà không tiến triển được?Chuyển, kèm những gì đã thử
4. Khách chỉ bực, việc trong khả năng?Ghi nhận, đề nghị giải quyết; khách nhắc lại thì chuyển
5. Còn lạiTự giải quyết

Tên trong đề và tên hiện nay

Đề thi được soạn từ tháng 07/2026, nên vài tên trong đề đã cũ. Khi luyện và khi thi, chọn theo tên trong đề.