12 luật vàng
Rút ra từ bộ đề gốc; giải được phần lớn câu bằng cách loại đáp án.
01 · Đuôi tự thú = loại
Phương án sai thường tự khai hệ quả xấu ở cuối: "chấp nhận rằng…", "coi X là trade-off đã biết", "để downstream tự xử lý", "dựa vào người dùng báo cáo". Quét đuôi câu trước khi đọc đầu câu.
02 · Chẩn đoán trước, sửa sau
Có phương án nào nói "xem trace / log / đo trước khi khuyến nghị" thì gần như chắc chắn đó là đáp án (Q35, Q43, Q48, Q93). Mọi cách sửa đưa ra trước khi biết nguyên nhân đều sai.
03 · Prompt không phải cơ chế cưỡng chế
Cần chặn thật thì dùng hooks, output filter, schema validation, permission — không dùng chỉ dẫn trong system prompt (Q37, Q44, Q61, Q85).
04 · Tăng context window không bao giờ là đáp án
Vấn đề ngữ cảnh luôn được giải bằng compaction, pruning, summarization hoặc chunking (Q3, Q17, Q21, Q49, Q91).
05 · Chọn cái nhỏ nhất đủ dùng
Model nhẹ cho task đơn giản · workflow cho bước cố định · SDK trực tiếp khi không có nhu cầu đa provider · STDIO cho MCP cục bộ · Batch cho việc không tương tác.
06 · Ràng buộc cứng là điều kiện loại
Data residency, hợp đồng bắt buộc qua Bedrock, downstream từ chối JSON sai dạng — tuân thủ trước, tối ưu sau. Không "ship rồi review compliance sau" (Q72, Q75).
07 · Cấu hình là code
Prompt, CLAUDE.md, settings.json, phiên bản plugin đều phải version-control cùng repo và đi qua review (Q40, Q53, Q54, Q65, Q69, Q38).
08 · Bẫy "thiếu đúng một thành phần"
Hai phương án gần giống nhau, phương án sai bị cắt đúng một mắt: bỏ validation (Q26 D), review là tuỳ chọn (Q40 C), hoãn error handling (Q57 D), bỏ output token (Q97 C). Đọc song song hai phương án dài nhất.
09 · Lỗi phải là error path được công nhận
Validation fail hay JSON sai dạng ⇒ retry / repair / fallback. Không phải lỗi kết thúc, không phải tắt validation, không phải retry mù (Q10, Q47, Q68, Q87).
10 · Đúng cơ chế cho đúng phạm vi
built-in tool → custom tool → Skill → MCP server, chọn theo phạm vi, nhu cầu tái sử dụng và ngữ cảnh tích hợp (Q20, Q25, Q67, Q84).
11 · Đáp án hai mệnh đề thường đúng
Dạng "giải thích đúng bản chất + rồi xử lý bằng cách phù hợp" hay "làm A, rồi kiểm chứng bằng B" thường là đáp án (Q4, Q21, Q52, Q73). Phương án chỉ đổi một tham số thường sai.
12 · Học nội dung, không học chữ cái
Có 2 cặp trùng nội dung đã đảo đáp án: 21≡22 (D→B) và 45≡95 (D→A). Nhớ chữ cái là mất điểm.
Bảng tra 60 giây
Ngữ cảnh phình · ISOLATION (subagent) → COMPACTION (tóm tắt phần cũ) → PRUNING (bỏ tool output hết dùng) → SUMMARIZATION / CHUNKING (vượt window). Prompt caching giảm CHI PHÍ, không giải phóng window.
Chọn API / cơ chế phát output
- Messages
- tương tác, real-time
- Streaming
- hiển thị dần cho người dùng thấy ngay
- Batch
- không tương tác, cửa sổ hoàn thành linh hoạt
- Prompt caching
- phần tĩnh lặp lại; không cache output model
- Rate limit
- thiết kế nằm trong giới hạn + exponential backoff
Model options
- model nhẹ
- phân loại khối lượng lớn, latency chặt, chi phí/request
- extended thinking
- suy luận nhiều bước, cần bộc lộ bước trung gian
- 3 chiều
- quality + latency + cost xét ĐỒNG THỜI, không tuần tự
- thiếu target
- làm rõ mục tiêu trước, đừng đoán "best results"
- đổi version
- adapt prompt → re-eval → feature flag + revert
Cơ chế mở rộng
- built-in tool
- đã có sẵn, xét mở rộng trước khi tự xây
- custom tool
- schema rõ + description khi nào gọi + error handling
- Skill
- package prompt + script + data, model nạp như một khối
- MCP server
- phơi resource/tool/prompt qua interface chuẩn; tái dùng liên nhóm
- STDIO / HTTP
- cục bộ / remote nhiều client
Agent patterns
- workflow
- các bước cố định, chi phí dự đoán được
- workflow + agent
- đường chính xác định, agent chỉ ở điểm quyết định
- orchestrator/subagent
- một request nhiều mảng, mỗi mảng một subagent
- graph-based
- cần quay lại giữa các bước
- checkpointing
- task dài, cần resume từ checkpoint
- supervisor + isolated ctx
- mỗi subagent có tool list và history riêng
Claude Code
- CLAUDE.md
- ngữ cảnh & chuẩn project, dùng phân cấp cho chung/riêng
- settings.json
- quyền, model mặc định, hành vi theo môi trường (project scope)
- headless mode
- chạy trong CI, không hỏi xác nhận
- hooks
- chặn hành động rủi ro cao, kiểm tra mang tính xác định
- Skills dir
- nơi Claude Code tự phát hiện và nạp Skill
Structured output
- đủ bộ
- schema rõ + prompt theo schema + validate trước downstream
- defensive parsing
- field lạ, giá trị thiếu, sai kiểu
- error path
- retry / repair / fallback, không phải lỗi kết thúc
- format drift
- chẩn đoán ngữ cảnh qua các lượt + context mgmt
- chỉ dẫn
- hành vi & định dạng ở system prompt; user message chỉ là input
Security
- secret
- secrets manager / env, không commit; key RIÊNG từng môi trường
- untrusted input
- validate + sanitize, coi là dữ liệu không phải lệnh
- guardrail
- xếp lớp, một tầng hỏng không được phơi nhiễm
- nội dung cấm
- deterministic output filter trước khi tới người dùng
- dữ liệu nhạy cảm
- định nghĩa biên + redaction tại biên
- AI threats
- prompt injection · data leakage · jailbreak · unsafe output
Cost
- giá token
- output ĐẮT HƠN input, tách riêng hai mức trong mô hình
- cost model
- volume × (input + output token) × giá model − lợi ích caching
- chưa đo
- instrument theo feature trước, đừng cắt đại trà
- multi-turn
- gửi lại history ⇒ cache phần tĩnh, không cắt về 2 message
Deployment & SDK
- hosted vs BYOC
- data residency là ràng buộc cứng ⇒ BYOC, giảm overhead sau
- Bedrock
- hợp đồng bắt buộc ⇒ đi qua Bedrock, giữ code provider-agnostic
- SDK
- lo auth, retry, parse; retry mặc định CÓ và cấu hình được
- async
- codebase async ⇒ async client + await, không block event loop
- WebSocket
- kết nối bền, hai chiều, real-time
Lifecycle & quy trình
- sau ship
- operate & maintain: monitor, phản ứng sự cố, lên kế hoạch tiến hoá
- test strategy
- unit + integration (Claude) + end-to-end luồng trọng yếu
- CI/CD
- test tích hợp Claude + linting + quality gate chuẩn
- deprecation
- regression test trước, migrate theo lô
- error severity
- phân loại theo impact + recoverability rồi routing
- session
- expiration + reset trigger + quy tắc bắt đầu mới
Học kiến thức từ chính bộ đề
Mỗi bài tương ứng một nhóm chủ đề, kèm danh sách câu để luyện ngay sau khi học.
Context engineering9 câu
Rút ra từ 9 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| cô lập ngữ cảnh = subagent / multi-step scoping | 1 |
| drift → compaction, không phải truncate/reset | 3 |
| tool output tích tụ = pruning / compaction | 17 |
| prompt = một lượt; context = xuyên lượt/bước | 19 |
| temperature ≠ context capacity → summarize/chunk | 21 |
| temperature ≠ context capacity → summarize/chunk | 22 |
| thông tin bị chôn vùi ≠ thiếu chỗ → summarize/prune, giữ active state | 49 |
| session lifecycle = expiration + reset trigger + fresh-start rules | 81 |
| output hết hạn dùng = pruning (caching không giải phóng context) | 91 |
Bẫy đã gặp trong nhóm này
- A và B làm ngược yêu cầu (nhồi toàn bộ history). C dùng một prompt chung, không cô lập được gì. 1
- A và B cắt/xoá sạch làm mất trạng thái cần thiết. D tăng context window chỉ khiến nội dung cũ tồn tại lâu hơn. 3
- C tăng context window không sửa việc thông tin bị chôn vùi; B khởi động lại làm mất trạng thái; D bỏ tool calling là bỏ luôn năng lực. 17
- A coi đây là chuyện thay tên gọi; C gộp hai khái niệm; D định nghĩa sai cả hai (response vs input). 19
- Câu này trùng nội dung với Q22 nhưng ĐẢO chữ cái (D ở đây, B ở Q22). Học nội dung, không học chữ cái. 21
- Bằng chứng rõ nhất rằng bộ đề đảo chữ cái giữa các Practice Set: cùng câu, đáp án là B ở đây và D ở Q21. 22
- D tăng thêm context window là làm nặng chính vấn đề chôn vùi (đề đã nói window đủ lớn). B gộp tool thành tool đa mục đích làm giảm độ chính xác chọn tool. A đổi framework. 49
- A chỉ có timeout; B chỉ có trigger reset mà không có hết hạn; D có hết hạn nhưng phó thác việc reset cho người dùng. Mỗi phương án sai thiếu đúng một thành phần. 81
- C dùng prompt caching cho nội dung tích tụ — caching giảm chi phí nhưng KHÔNG giải phóng context window. A giữ mọi thứ; B đổi model nhỏ hơn. 91
Agent patterns & architecture9 câu
Rút ra từ 9 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| mục tiêu khác nhau = prompt/call riêng | 2 |
| điều phối + history riêng mỗi subagent = supervisor, isolated context | 13 |
| phần xác định = workflow, chỉ điểm quyết định mới cần agent | 15 |
| lỗi phối hợp → siết management layer: budget + schema + handoff contract | 32 |
| cần vòng lặp giữa các bước = graph-based, không phải linear chain | 39 |
| resume = checkpointing (persist + reload state) | 41 |
| một request nhiều mảng = orchestrator + subagent theo mảng | 45 |
| phân rã + giao subagent + hợp nhất = orchestrator pattern | 82 |
| một request nhiều mảng = orchestrator + subagent theo mảng | 95 |
Bẫy đã gặp trong nhóm này
- C lấy lý do 'một call luôn rẻ hơn' — chi phí không phải tiêu chí quyết định ở đây. D dựng multi-agent thừa cho một bài toán hai bước. 2
- B khác đúng một chi tiết: 'shared context'. Đề đã nói history không chia sẻ ⇒ loại. Luôn đọc kỹ mệnh đề phân biệt. 13
- D và B dùng agent cho toàn bộ luồng vốn xác định được — đắt và khó dự đoán. C nhồi mọi thứ vào một prompt. 15
- B chỉ thêm retry và trace — phát hiện sau khi đã xảy ra, không ngăn được. C cho subagent đọc chéo nhau làm mất tính cô lập và không có ai phân xử. A đập bỏ kiến trúc. 32
- D là chuỗi tuyến tính không có đường quay lại — mâu thuẫn trực tiếp với yêu cầu iteration. A gộp mọi tool vào một loop, mất tiêu chí riêng từng bước. 39
- C khởi động lại từ đầu là bỏ yêu cầu; D tăng timeout không giải quyết việc bị ngắt; B chạy song song hai bản là bội chi. 41
- A dùng prompting để 'nhắc agent tự theo dõi' — không phải thay đổi kiến trúc. B ép trình tự cố định làm mất tính linh hoạt. C tăng context window không sửa việc mất dấu trạng thái. Trùng nội dung với Q95 (đảo chữ cái). 45
- B một loop chứa mọi tool là ngược với việc chuyên biệt hoá; A và D là kỹ thuật quản lý ngữ cảnh/bộ nhớ, không phải pattern phân rã task. 82
- Đây là cặp trùng với Q45 nhưng đảo chữ cái (D ở Q45 → A ở đây). Đúng lý do phải học nội dung chứ không học chữ cái. 95
API, SDK & integration11 câu
Rút ra từ 11 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| biến động cách diễn đạt = bản chất generation, không phải bug | 4 |
| rate limit = design within limits + exponential backoff | 6 |
| hiển thị dần = streaming; chờ lâu, không tương tác = Batch | 23 |
| persistent + bidirectional + real-time = WebSocket | 46 |
| non-determinism do sampling + cách ứng dụng xử lý | 52 |
| SDK: có retry mặc định + cấu hình được | 59 |
| không tương tác + cửa sổ linh hoạt = Batch API | 63 |
| có SDK chính thức thì dùng SDK | 66 |
| ràng buộc hợp đồng = tuân thủ ngay + giữ code provider-agnostic | 75 |
| không có nhu cầu thật thì không thêm abstraction | 78 |
| codebase async = async client + await | 96 |
Bẫy đã gặp trong nhóm này
- B, C, D đều khẳng định có bug hoặc quy cho phiên bản model / prompt khác nhau mà không có bằng chứng. 4
- A, B, C là các tối ưu phụ (san traffic, streaming, gộp payload) nhưng không nêu cơ chế backoff — phần cốt lõi của câu hỏi. 6
- D (Batch API) ngược hoàn toàn về độ trễ; C (prompt caching) ảnh hưởng chi phí chứ không phải cách phát output. 23
- A (long-poll giữ mở vô hạn), C (qua file), D (polling ngắn liên tục) đều là cách né WebSocket và đều kém hơn ở đúng yêu cầu đã nêu. 46
- A nhận là bug; B quy cho network latency; C quy cho việc Anthropic cập nhật liên tục và hứa fixed snapshot sẽ triệt tiêu hoàn toàn biến động (không đúng). 52
- B nói không cấu hình được; A nói rate-limit không được retry; D nói SDK chỉ log rồi chạy tiếp. 59
- A và D dùng Messages API real-time cho việc không cần real-time (đắt hơn); C dùng streaming cho việc không có người xem. 63
- D gọi REST thô là tự viết lại những gì SDK đã làm; C gọi qua shell là kỳ dị; B dùng SDK của provider khác rồi dịch. 66
- B phớt lờ ràng buộc hợp đồng; C hoãn sang bản sau; D dựng hai implementation song song. 75
- C dùng lý lẽ 'linh hoạt lâu dài luôn có giá trị' bất chấp bằng chứng ngược lại; A tự xây abstraction; D chạy song song hai đường. 78
- D block event loop; B đổi cả service sang synchronous; C đẩy sang thread pool riêng là phức tạp không cần thiết khi đã có async client. 96
Model selection & options8 câu
Rút ra từ 8 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| đổi version → adapt prompt + re-evaluate rồi mới upgrade | 5 |
| suy luận nhiều bước, cần bước trung gian = extended thinking | 7 |
| phân loại khối lượng lớn = model nhỏ nhất đạt yêu cầu | 9 |
| ba chiều xét đồng thời, không tuần tự | 50 |
| có ví dụ nhãn = few-shot trong prompt | 62 |
| upgrade = adapt prompt + re-eval + feature flag + revert path | 73 |
| thiếu target = làm rõ target trước, đừng đoán | 83 |
| có ví dụ nhãn = multi-shot trong prompt | 90 |
Bẫy đã gặp trong nhóm này
- B che triệu chứng bằng validation downstream; D bỏ qua lỗi vì con số lợi ích lớn hơn; C đóng băng vĩnh viễn. 5
- A, C đi ngược yêu cầu (thu nhỏ năng lực, ưu tiên latency). B không phải một model option. 7
- A chọn theo mặc định chứ không theo yêu cầu; C tối đa chất lượng bất chấp ràng buộc; B xếp nhiều model nối tiếp là bội chi. 9
- A, C, D đều xét tuần tự, cố định một chiều trước rồi mới xem các chiều khác — đúng cái bẫy 'tách rời trade-off'. 50
- A train custom model là leo thang lớn (và Claude không fine-tune theo cách này trong bối cảnh đề); D nhúng vào database mà không nói cách dùng ở inference; C đẩy sang người dùng. 62
- D đổi model identifier rồi 'chờ lỗi lộ ra' trong production; A đóng băng vĩnh viễn; C chỉ sửa tầng parsing mà không xử lý nguyên nhân định dạng. 73
- A, C, D đều chọn model dựa trên phỏng đoán về nghĩa của 'kết quả tốt nhất' hoặc trên một benchmark chung chung không gắn với use case. 83
- B dùng zero-shot dù đã có ví dụ tốt; A train model riêng; C nhúng vào database làm 'tài liệu tham khảo cho nhóm' chứ không đưa vào prompt. 90
Tools, Skills & MCP13 câu
Rút ra từ 13 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| MCP cục bộ = STDIO; remote/nhiều client = HTTP | 8 |
| tái sử dụng liên nhóm = Skill hoặc MCP server | 20 |
| chọn theo scope + reuse + integration context | 25 |
| tool description = tín hiệu để model chọn tool | 29 |
| đã chọn SDK thì dùng cả loop/dispatch/history của SDK | 30 |
| custom tool = schema rõ + description khi nào gọi + error handling | 42 |
| so sánh: mở rộng built-in vs custom, rồi chọn | 67 |
| MCP dùng chung = định nghĩa rõ + chọn transport + hosting truy cập được | 71 |
| chọn sai tool = gộp/bỏ/làm rõ description | 74 |
| Skill = package model nạp; MCP = interface chuẩn phơi resource/tool | 84 |
| tool arg sai = schema nghiêm + validate + structured error để retry | 85 |
| validate tool_use args trước dispatch, coi lỗi là error path | 87 |
| Skill = thư mục Skills được Claude Code nhận biết | 92 |
Bẫy đã gặp trong nhóm này
- A dùng lý lẽ tuyệt đối ('HTTP luôn tốt hơn'); D chạy song song hai pattern là phức tạp vô ích. 8
- A và D bắt mỗi nhóm copy code hoặc tự bảo trì library — sinh drift. C bọc built-in tool không giải quyết bài toán tái sử dụng. 20
- A, C, D đều là tiêu chí về phía nhóm phát triển chứ không phải về bài toán. 25
- A tách description ra file tài liệu là bỏ nó khỏi tầm nhìn của model. D coi example call thay thế hoàn toàn phần mô tả. 29
- B và C vẫn tự viết lại phần mà SDK đã làm — đi ngược quyết định đã có. A bỏ tool calling có cấu trúc. 30
- A, B, C mỗi cái bỏ đúng một trong ba yếu tố đó (bỏ description, bỏ error handling, schema lỏng). 42
- A chỉ xét một nhánh (custom tool); D chỉ xét nhánh kia (built-in nguyên trạng); B chọn theo tiền lệ nội bộ. Chỉ C so sánh cả hai nhánh theo đúng câu hỏi. 67
- A deploy chỉ trên máy developer; C scope theo ứng dụng đầu tiên rồi mở rộng dần (drift); D bỏ MCP đi nhúng trực tiếp vào từng app. 71
- C thêm tool cho mọi biến thể làm vấn đề tệ hơn; D chỉ thêm ví dụ mà giữ nguyên sự chồng lấn; A bỏ hết tool. 74
- B so sánh bằng 'nạp hiệu quả hơn' (không phải điểm phân biệt); C nói hai thứ tương đương; D nói cũ/mới. 84
- C là chính đề xuất sai của đồng nghiệp (nới schema); B bỏ schema và phó thác cho downstream; A dùng chỉ dẫn prompt làm cơ chế chính. 85
- C chỉ log rồi vẫn dispatch; A retry mù; D bỏ tool calling. Cùng nguyên tắc với Q85 nhưng câu này hỏi ở phía code ứng dụng. 87
- A đặt ở thư mục nháp cá nhân rồi nạp thủ công; C biến Skill thành library gọi từ code ứng dụng (sai đối tượng dùng); D nhét inline vào mọi CLAUDE.md. 92
Structured output & errors8 câu
Rút ra từ 8 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| validation fail = recognized error path (retry/repair/fallback) | 10 |
| schema rõ + prompt theo schema + validate trước downstream | 26 |
| malformed JSON = validate + recognized error path (retry/fallback) | 47 |
| format drift = chẩn đoán ngữ cảnh + context mgmt/validation | 51 |
| prompt phải nêu schema tường minh + 'chỉ output theo schema' | 55 |
| hành vi/định dạng ở system prompt; user message chỉ là input | 64 |
| downstream an toàn = defensive parsing (extra/missing/type) | 68 |
| tự tin ≠ đúng → validation + sourcing + calibration | 80 |
Bẫy đã gặp trong nhóm này
- D tắt validation là bỏ kiểm soát; B đẩy output lỗi xuống downstream; A đẩy việc kiểm tra sang người dùng. 10
- D giống A nhưng đẩy validation sang downstream — thiếu đúng bước then chốt. B mô tả schema bằng văn xuôi. 26
- D chỉ retry mù cho tới khi may mắn; A đưa người vào mọi request; B bỏ luôn JSON. 47
- A cắt phản hồi rồi validate phần bị cắt là vô nghĩa; B đổi model nhỏ hơn không liên quan nguyên nhân; D restart mỗi lượt là bỏ hội thoại nhiều lượt. 51
- B phó thác cho post-processing; A và D cho model tự chọn định dạng. 55
- A làm ngược (dồn hết vào user message); C lặp lại ở cả hai nơi tạo nguồn mâu thuẫn; B giữ nguyên sự tuỳ tiện. 64
- D âm thầm drop output là mất dữ liệu không dấu vết; B crash rồi phục hồi thủ công; C hoãn việc cưỡng chế schema. 68
- A dùng disclaimer làm cơ chế chính; C hạ temperature để 'nghe bớt tự tin' (không đổi độ chính xác); B bắt người review mọi phản hồi. 80
Security & guardrails9 câu
Rút ra từ 9 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| API key → secrets manager / env, nạp lúc runtime | 11 |
| untrusted input = validate/sanitize + coi là dữ liệu, không phải lệnh | 27 |
| một guardrail hỏng không được phơi nhiễm ⇒ layered guardrails | 28 |
| deterministic control = hooks chặn trước khi thực thi | 37 |
| 'không bao giờ' = deterministic output filter, không phải prompt | 44 |
| hook chỉ ở hành động rủi ro cao | 61 |
| dữ liệu nhạy cảm = định nghĩa biên + redaction tại biên | 76 |
| mỗi môi trường một key riêng (blast radius) | 86 |
| AI threats = injection + data leakage + jailbreak + unsafe output | 94 |
Bẫy đã gặp trong nhóm này
- B, C, D là ba kiểu làm rò secret: dùng chung một key, gửi qua email, commit vào repo. 11
- B coi mọi input như nhau; D chặn hết là bỏ luôn use case hợp lệ; A chuyển sang một app 'lỏng hơn' là nghịch lý bảo mật. 27
- A, B, D đều là 'chỉ một tầng' (model level only / output level only / một system prompt duy nhất) — chính điều đề bài muốn tránh. 28
- D dùng chỉ dẫn prompt — không xác định. A đổi model, B giới hạn giờ làm việc: cả hai không phải kiểm soát kỹ thuật. 37
- D nghe rất thuyết phục (prompt chi tiết kèm ví dụ) nhưng vẫn coi prompt là cơ chế cưỡng chế CHÍNH — prompt không phải cơ chế cưỡng chế. C đẩy việc phát hiện sang người dùng sau khi đã xảy ra. 44
- B tắt hết hook tạo cửa sổ không được bảo vệ; D thay hook bằng chỉ dẫn prompt (mất tính xác định); A tắt agent theo giờ. 61
- C chỉ lọc các pattern 'thường thấy' rồi mở rộng dần dựa trên production — tức để dữ liệu nhạy cảm lọt trước rồi mới học. B dùng chỉ dẫn prompt (dữ liệu đã tới model rồi). A chỉ log để review sau. 76
- A và C dùng chung một key rồi coi việc lan truyền là 'trade-off đã biết'; D xoay vòng cùng một key ở các khoảng ngẫu nhiên không tạo ra bất kỳ sự cô lập nào. 86
- A và C liệt kê đe doạ web/hạ tầng truyền thống (đề nói đồng nghiệp đã có sẵn); D thu hẹp về một điểm duy nhất là supply chain của SDK. 94
Config, CI/CD & lifecycle19 câu
Rút ra từ 19 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| CI = headless mode + permissions trong settings.json | 12 |
| prompt phình = audit + refactor, không đắp thêm | 14 |
| đánh giá từng cái theo lý do gốc + năng lực SDK hiện tại | 18 |
| severity theo impact + recoverability, rồi routing | 31 |
| deprecation = regression test trước, migrate theo lô | 33 |
| regression do plugin = version tracking + pin | 38 |
| prompt = code: single source of truth + version control + review | 40 |
| config Claude Code = version control cùng code + PR review | 53 |
| đa môi trường = config version-controlled, ghim theo từng env | 54 |
| đổi prompt ảnh hưởng nhiều consumer = impact assessment trước | 56 |
| thiếu 3 thứ thì yêu cầu sửa cả 3, không hoãn phần nào | 57 |
| chuẩn chung + riêng repo = CLAUDE.md hierarchy | 58 |
| ngữ cảnh project dùng chung = CLAUDE.md ở gốc repo | 65 |
| cấu hình cấp project = settings.json (project scope) | 69 |
| feature khó thêm dần = refactor trước, không đắp thêm | 70 |
| data residency = ràng buộc cứng → BYOC, giảm overhead sau | 72 |
| test strategy = unit + integration + e2e, nhất quán | 79 |
| sau ship = operate & maintain (monitor, respond, evolve) | 88 |
| CI = test tích hợp Claude + linting + quality gate chuẩn | 89 |
Bẫy đã gặp trong nhóm này
- D tắt confirmation prompt trên MỌI môi trường là mở rộng rủi ro ra ngoài CI. B đưa người vào vòng lặp tự động. 12
- B chỉ sửa một phần; C chia nhỏ prompt không giải quyết mâu thuẫn; D thêm chỉ dẫn để 'đè' lên chỉ dẫn cũ, làm prompt càng rối. 14
- B và D là hai thái cực 'giữ hết' / 'bỏ hết'; C bỏ SDK đi xây lại là leo thang không cần thiết. 18
- A page mọi lỗi gây alert fatigue; B giữ nguyên hiện trạng; D bỏ luôn log cho lỗi không page. 31
- A và C đều là 'một cú lớn' (ngay lập tức hoặc sát deadline) không có lưới an toàn; B chỉ bọc wrapper nhưng vẫn giữ tham số sắp bị bỏ. 33
- B phó thác cho tác giả plugin; C upgrade liên tục không giải quyết việc không biết version nào từng chạy tốt; D bỏ plugin là quá khích. 38
- C giống A nhưng để review là tuỳ chọn — đúng phần lỗi mà đề bài nêu (thay đổi đi ra mà không qua review). B, D làm mất kiểm soát hoàn toàn. 40
- B và D tách cấu hình sang repo khác làm mất liên kết với code; C nhân bản nhiều nơi là phá vỡ nguồn chân lý duy nhất. 53
- B ép ba môi trường giống nhau là xoá bỏ mục đích của staging/dev; A bỏ ghim version; D hardcode vào code. 54
- A coi kết quả staging là đủ; B chỉ thông báo mà không đánh giá; D giới hạn rollout nhưng vẫn không đánh giá tác động. 56
- D giống C nhưng đẩy error handling sang bản phát hành sau — cố tình bỏ một trong ba. A, B đều approve. 57
- B dùng một repo làm nguồn rồi link từ các repo khác — vẫn là trùng lặp thủ công, không phải cơ chế phân cấp. A và D bỏ CLAUDE.md. 58
- A, B đặt ở wiki/README — Claude Code không tự nạp làm ngữ cảnh; C dùng biến môi trường từng máy tạo drift. 65
- A dựa vào việc mỗi developer tự dán system prompt; C dùng bảng tính; D dùng biến môi trường từng máy — cả ba đều không nhất quán và không đi cùng repo. 69
- B refactor 'kèm theo' mỗi ticket feature nghe hợp lý nhưng không giải quyết được phần tangled control flow xuyên nhiều module; A hoãn hai chu kỳ; C gộp vào một function lớn là làm tệ hơn. 70
- A và D đều ship trước rồi xử lý compliance sau; C pilot bằng BYOC nhưng để ngỏ việc chuyển sang hosted — vẫn chưa tôn trọng ràng buộc như một điều kiện. 72
- B chỉ dùng một tầng (end-to-end); C giữ nguyên ad-hoc; D nói về TDD (quy trình viết test) chứ không phải cấu trúc chiến lược test. 79
- D nói ship là giai đoạn cuối (sai về chu kỳ sống); B chuyển giao hoàn toàn cho nhóm ops độc lập; C coi post-deployment review là điều kiện chặn mọi việc khác. 88
- A đẩy integration test sang kiểm tra thủ công; C bỏ linting khỏi CI; D deploy production ở mọi pull request. 89
Cost & caching5 câu
Rút ra từ 5 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| output token đắt hơn input token | 16 |
| cache phần tĩnh lặp lại, không cache output | 34 |
| chưa đo thì chưa cắt — instrument theo feature trước | 43 |
| gửi lại history nhiều lượt = prompt caching phần tĩnh | 77 |
| cost model = volume × (input + output token) × giá model − caching | 97 |
Bẫy đã gặp trong nhóm này
- B (không tính output), C (bằng nhau, là lỗi billing), D (output rẻ hơn) đều sai về hướng. 16
- D là chính đề xuất sai của đồng nghiệp — prompt caching không cache output của model. B cache phần biến động nhất là vô nghĩa. 34
- C và D cắt đại trà mà không đo; A đầu hàng. Nguyên tắc: đo trước, cắt sau. 43
- B cắt về hai message cuối và C tóm tắt sau mỗi lượt đều đánh đổi độ chính xác (đề nói có cách hiệu quả hơn); A dùng Batch API cho hội thoại tương tác. 77
- C bỏ output token; A coi input/output là biến sẽ ước lượng sau khi launch; B ngoại suy từ một ứng dụng cũ khác. 97
Debugging & troubleshooting4 câu
Rút ra từ 4 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| đừng tin giả định — xem trace để phân loại failure mode trước | 35 |
| cải tiến prompt = iterate + validate bằng eval | 36 |
| debug = full trace + so sánh lần chạy tốt vs lỗi | 48 |
| bước đầu tiên luôn là xem trace, chưa sửa gì | 93 |
Bẫy đã gặp trong nhóm này
- A, B, C đều là biện pháp sửa cho MỘT giả định chưa được kiểm chứng. 35
- A đánh đổi mất hiệu năng ca thường; B tách ra một app riêng làm phân mảnh; D đẩy vấn đề sang người dùng. 36
- D hạ temperature là thử một cách sửa trước khi hiểu; B retry và log không cô lập biến; C chấp nhận và đóng hồ sơ. 48
- B và C là các phân tích hẹp hơn dựa trên log/so sánh, tức là các bước SAU khi đã có trace; D nhảy thẳng sang thử sửa ('những chỉ dẫn đó') khi còn chưa biết chỉ dẫn nào. 93
Requirements & scoping2 câu
Rút ra từ 2 câu của nhóm này: mỗi dòng là nguyên tắc nhận diện của một câu. Học bảng trước, rồi bấm số câu để luyện.
| Nguyên tắc / từ khoá nhận diện | Câu |
|---|---|
| chưa có tiêu chí ưu tiên → xác định yêu cầu trước rồi validate | 24 |
| business goal → diễn giải functional + infrastructure requirements | 60 |
Bẫy đã gặp trong nhóm này
Dấu hiệu trong đề → đáp án
Mỗi dòng là từ khoá nhận diện của một câu; bấm số câu để mở câu đó.
| Từ khoá nhận diện | Đáp án | Câu |
|---|---|---|
| cô lập ngữ cảnh = subagent / multi-step scoping | D | 1 |
| mục tiêu khác nhau = prompt/call riêng | B | 2 |
| drift → compaction, không phải truncate/reset | C | 3 |
| biến động cách diễn đạt = bản chất generation, không phải bug | A | 4 |
| đổi version → adapt prompt + re-evaluate rồi mới upgrade | A | 5 |
| rate limit = design within limits + exponential backoff | D | 6 |
| suy luận nhiều bước, cần bước trung gian = extended thinking | D | 7 |
| MCP cục bộ = STDIO; remote/nhiều client = HTTP | C | 8 |
| phân loại khối lượng lớn = model nhỏ nhất đạt yêu cầu | D | 9 |
| validation fail = recognized error path (retry/repair/fallback) | C | 10 |
| API key → secrets manager / env, nạp lúc runtime | A | 11 |
| CI = headless mode + permissions trong settings.json | C | 12 |
| điều phối + history riêng mỗi subagent = supervisor, isolated context | D | 13 |
| prompt phình = audit + refactor, không đắp thêm | A | 14 |
| phần xác định = workflow, chỉ điểm quyết định mới cần agent | A | 15 |
| output token đắt hơn input token | A | 16 |
| tool output tích tụ = pruning / compaction | A | 17 |
| đánh giá từng cái theo lý do gốc + năng lực SDK hiện tại | A | 18 |
| prompt = một lượt; context = xuyên lượt/bước | B | 19 |
| tái sử dụng liên nhóm = Skill hoặc MCP server | B | 20 |
| temperature ≠ context capacity → summarize/chunk | D | 21 |
| temperature ≠ context capacity → summarize/chunk | B | 22 |
| hiển thị dần = streaming; chờ lâu, không tương tác = Batch | B | 23 |
| chưa có tiêu chí ưu tiên → xác định yêu cầu trước rồi validate | A | 24 |
| chọn theo scope + reuse + integration context | B | 25 |
| schema rõ + prompt theo schema + validate trước downstream | A | 26 |
| untrusted input = validate/sanitize + coi là dữ liệu, không phải lệnh | C | 27 |
| một guardrail hỏng không được phơi nhiễm ⇒ layered guardrails | C | 28 |
| tool description = tín hiệu để model chọn tool | B | 29 |
| đã chọn SDK thì dùng cả loop/dispatch/history của SDK | D | 30 |
| severity theo impact + recoverability, rồi routing | C | 31 |
| lỗi phối hợp → siết management layer: budget + schema + handoff contract | D | 32 |
| deprecation = regression test trước, migrate theo lô | D | 33 |
| cache phần tĩnh lặp lại, không cache output | C | 34 |
| đừng tin giả định — xem trace để phân loại failure mode trước | D | 35 |
| cải tiến prompt = iterate + validate bằng eval | C | 36 |
| deterministic control = hooks chặn trước khi thực thi | C | 37 |
| regression do plugin = version tracking + pin | A | 38 |
| cần vòng lặp giữa các bước = graph-based, không phải linear chain | C | 39 |
| prompt = code: single source of truth + version control + review | A | 40 |
| resume = checkpointing (persist + reload state) | A | 41 |
| custom tool = schema rõ + description khi nào gọi + error handling | D | 42 |
| chưa đo thì chưa cắt — instrument theo feature trước | B | 43 |
| 'không bao giờ' = deterministic output filter, không phải prompt | B | 44 |
| một request nhiều mảng = orchestrator + subagent theo mảng | D | 45 |
| persistent + bidirectional + real-time = WebSocket | B | 46 |
| malformed JSON = validate + recognized error path (retry/fallback) | C | 47 |
| debug = full trace + so sánh lần chạy tốt vs lỗi | A | 48 |
| thông tin bị chôn vùi ≠ thiếu chỗ → summarize/prune, giữ active state | C | 49 |
| ba chiều xét đồng thời, không tuần tự | B | 50 |
| format drift = chẩn đoán ngữ cảnh + context mgmt/validation | C | 51 |
| non-determinism do sampling + cách ứng dụng xử lý | D | 52 |
| config Claude Code = version control cùng code + PR review | A | 53 |
| đa môi trường = config version-controlled, ghim theo từng env | C | 54 |
| prompt phải nêu schema tường minh + 'chỉ output theo schema' | C | 55 |
| đổi prompt ảnh hưởng nhiều consumer = impact assessment trước | C | 56 |
| thiếu 3 thứ thì yêu cầu sửa cả 3, không hoãn phần nào | C | 57 |
| chuẩn chung + riêng repo = CLAUDE.md hierarchy | C | 58 |
| SDK: có retry mặc định + cấu hình được | C | 59 |
| business goal → diễn giải functional + infrastructure requirements | D | 60 |
| hook chỉ ở hành động rủi ro cao | C | 61 |
| có ví dụ nhãn = few-shot trong prompt | B | 62 |
| không tương tác + cửa sổ linh hoạt = Batch API | B | 63 |
| hành vi/định dạng ở system prompt; user message chỉ là input | D | 64 |
| ngữ cảnh project dùng chung = CLAUDE.md ở gốc repo | D | 65 |
| có SDK chính thức thì dùng SDK | A | 66 |
| so sánh: mở rộng built-in vs custom, rồi chọn | C | 67 |
| downstream an toàn = defensive parsing (extra/missing/type) | A | 68 |
| cấu hình cấp project = settings.json (project scope) | B | 69 |
| feature khó thêm dần = refactor trước, không đắp thêm | D | 70 |
| MCP dùng chung = định nghĩa rõ + chọn transport + hosting truy cập được | B | 71 |
| data residency = ràng buộc cứng → BYOC, giảm overhead sau | B | 72 |
| upgrade = adapt prompt + re-eval + feature flag + revert path | B | 73 |
| chọn sai tool = gộp/bỏ/làm rõ description | B | 74 |
| ràng buộc hợp đồng = tuân thủ ngay + giữ code provider-agnostic | A | 75 |
| dữ liệu nhạy cảm = định nghĩa biên + redaction tại biên | D | 76 |
| gửi lại history nhiều lượt = prompt caching phần tĩnh | D | 77 |
| không có nhu cầu thật thì không thêm abstraction | B | 78 |
| test strategy = unit + integration + e2e, nhất quán | A | 79 |
| tự tin ≠ đúng → validation + sourcing + calibration | D | 80 |
| session lifecycle = expiration + reset trigger + fresh-start rules | C | 81 |
| phân rã + giao subagent + hợp nhất = orchestrator pattern | C | 82 |
| thiếu target = làm rõ target trước, đừng đoán | B | 83 |
| Skill = package model nạp; MCP = interface chuẩn phơi resource/tool | A | 84 |
| tool arg sai = schema nghiêm + validate + structured error để retry | D | 85 |
| mỗi môi trường một key riêng (blast radius) | B | 86 |
| validate tool_use args trước dispatch, coi lỗi là error path | B | 87 |
| sau ship = operate & maintain (monitor, respond, evolve) | A | 88 |
| CI = test tích hợp Claude + linting + quality gate chuẩn | B | 89 |
| có ví dụ nhãn = multi-shot trong prompt | D | 90 |
| output hết hạn dùng = pruning (caching không giải phóng context) | D | 91 |
| Skill = thư mục Skills được Claude Code nhận biết | B | 92 |
| bước đầu tiên luôn là xem trace, chưa sửa gì | A | 93 |
| AI threats = injection + data leakage + jailbreak + unsafe output | B | 94 |
| một request nhiều mảng = orchestrator + subagent theo mảng | A | 95 |
| codebase async = async client + await | A | 96 |
| cost model = volume × (input + output token) × giá model − caching | D | 97 |
Câu trùng lặp và nhóm câu cùng ý
Đề lặp lại nhưng đổi vị trí đáp án. Học một lần, dùng cho cả cặp.
| Câu | Đáp án chung | Lưu ý |
|---|---|---|
| 21 ≡ 22 | Cùng nội dung, đã đảo thứ tự đáp án. | Câu 21: D; câu 22: B. |
| 45 ≡ 95 | Cùng nội dung, đã đảo thứ tự đáp án. | Câu 45: D; câu 95: A. |
| Đánh dấu “trùng” trong file gốc | 21, 22, 45, 95 | Học theo nội dung lựa chọn, không theo chữ cái. |