Prompt engineering
Prompt engineering là việc thiết kế đầu vào cho model để có đầu ra mong muốn. Với model thế hệ 2025–2026, nhiều kỹ thuật kinh điển đã trở nên không còn cần thiết - và một số thậm chí gây hại. Trang này phân biệt cái nào còn dùng.
Các thành phần của một prompt
Phần tiêu đề “Các thành phần của một prompt”| Thành phần | Vai trò | Trong Claude Code |
|---|---|---|
| System prompt | Định nghĩa vai, quy tắc, giới hạn. Đứng đầu, ổn định qua các lượt | Do harness đặt; bạn bổ sung qua CLAUDE.md, --append-system-prompt |
| User message | Yêu cầu cụ thể của lượt này | Những gì bạn gõ |
| Tool definition | Danh sách tool + mô tả khi nào dùng | Tool có sẵn + MCP |
| Assistant message | Lượt trả lời trước của model (lịch sử hội thoại) | Lịch sử phiên |
Thứ tự nạp cố định: tools → system → messages. Điều này quan trọng cho prompt caching: thứ ổn định phải đứng trước thứ hay đổi.
Những kỹ thuật vẫn hiệu quả
Phần tiêu đề “Những kỹ thuật vẫn hiệu quả”1. Cụ thể và kiểm chứng được
Phần tiêu đề “1. Cụ thể và kiểm chứng được”Kỹ thuật hiệu quả nhất, và cũng rẻ nhất. Không phải “viết code cho đẹp” mà “dùng thụt lề 2 dấu cách”. Không phải “test kỹ” mà “chạy npm test và sửa các test fail”.
Một chỉ dẫn tốt phải trả lời được: “làm sao biết model đã làm đúng?”
2. Few-shot (đưa ví dụ)
Phần tiêu đề “2. Few-shot (đưa ví dụ)”Đưa 2–5 ví dụ input→output thay vì mô tả quy tắc bằng lời. Đặc biệt mạnh cho:
- Định dạng đầu ra khó diễn đạt bằng lời.
- Văn phong, giọng điệu (“đọc các bài trong
blog/để học văn phong, rồi viết một bài mới về X”). - Phân loại với các nhãn có ranh giới mờ.
3. Trỏ tới nguồn thay vì mô tả nguồn
Phần tiêu đề “3. Trỏ tới nguồn thay vì mô tả nguồn”@src/auth/session.ts tốt hơn “file xử lý session ở đâu đó trong src”. @build.log tốt hơn bản mô tả lỗi của bạn. Model đọc nguồn chính xác hơn đọc bản tóm tắt của bạn về nguồn.
4. Structured output (đầu ra có cấu trúc)
Phần tiêu đề “4. Structured output (đầu ra có cấu trúc)”Khi bạn cần JSON đúng schema, đừng “xin” model trả về JSON - hãy ràng buộc nó. API Claude có output_config.format với JSON Schema, và strict: true trên tool definition; cả hai đảm bảo output khớp schema ở tầng API, không phụ thuộc việc model có nhớ hay không.
5. Nêu ràng buộc mà model đã bỏ sót
Phần tiêu đề “5. Nêu ràng buộc mà model đã bỏ sót”Khi model làm sai, nói vì sao sai thay vì chỉ nói “sai”: “chưa đúng: chữ ký hàm phải giữ tương thích ngược. Thử cách khác.” Model cần một ràng buộc cụ thể để thoả mãn ở lần thử lại.
Những kỹ thuật đã lỗi thời
Phần tiêu đề “Những kỹ thuật đã lỗi thời”“Hãy suy nghĩ từng bước” (chain-of-thought thủ công)
Phần tiêu đề ““Hãy suy nghĩ từng bước” (chain-of-thought thủ công)”Model hiện đại có extended/adaptive thinking tích hợp - chúng tự suy luận trước khi trả lời, và bạn điều khiển độ sâu bằng tham số effort chứ không bằng câu thần chú trong prompt. Thêm “think step by step” giờ hầu như không tác dụng.
Đe doạ và nhấn mạnh quá mức
Phần tiêu đề “Đe doạ và nhấn mạnh quá mức”CRITICAL: YOU MUST use this tool từng cần thiết để vượt qua sự do dự của model cũ. Với model hiện tại nó gây overtrigger - model dùng tool cả khi không cần. Hãy viết Use this tool when... và mô tả điều kiện.
Ngoại lệ: một vài chỗ thật sự quan trọng thì IMPORTANT vẫn tăng độ tuân thủ. Vấn đề là nếu mọi dòng đều CRITICAL thì không dòng nào là critical.
Prefill (mồi lời model)
Phần tiêu đề “Prefill (mồi lời model)”Kỹ thuật cũ: kết thúc messages bằng một lượt assistant dở dang để buộc model tiếp tục theo định dạng đó. Trên các model Claude hiện tại (họ 4.6 trở lên) việc này trả về lỗi 400. Thay bằng structured output hoặc chỉ dẫn trong system prompt.
Prompt quá chi tiết cho model mạnh
Phần tiêu đề “Prompt quá chi tiết cho model mạnh”Nghịch lý: prompt viết cho model cũ, liệt kê từng bước một, thường làm giảm chất lượng đầu ra của model mới. Model mới lập kế hoạch tốt hơn cái kế hoạch bạn áp lên nó. Hãy nêu mục tiêu và ràng buộc, đừng liệt kê các bước.
Tương tự: chỉ dẫn “hãy tự kiểm tra lại kết quả” - vốn là best practice kinh điển - nay gây over-verification trên model mới, vốn đã tự kiểm chứng. Xoá đi thường tốt hơn giữ lại.
Prompt engineering vs context engineering
Phần tiêu đề “Prompt engineering vs context engineering”Hai thứ dễ lẫn:
- Prompt engineering - nội dung bạn viết trong một lượt: câu chữ, ví dụ, ràng buộc.
- Context engineering - quản lý toàn bộ ngữ cảnh qua nhiều lượt: cái gì được nạp, cái gì bị nén, cái gì đẩy sang subagent.
Với ứng dụng một lần gọi, prompt engineering là gần như toàn bộ công việc. Với agent, context engineering quan trọng hơn - một prompt hoàn hảo trong một ngữ cảnh đã nhiễu 150K token vẫn cho kết quả tệ.
Đọc thêm
Phần tiêu đề “Đọc thêm”- Thư viện prompt - các prompt cụ thể dùng được ngay.
- Context engineering
- Bộ nhớ với CLAUDE.md - nơi đặt chỉ dẫn bền qua các phiên.