Bạn biết cảm giác đó. Bạn gõ một câu hỏi có vẻ rõ ràng vào AI, và câu trả lời nhận được là... gần đúng. Kỹ thuật thì liên quan, nhưng lại bỏ qua đúng điểm mấu chốt. Bạn diễn đạt lại. Thử lại. Và lại nhận được kết quả gần đúng. Sau năm vòng bạn mới có thứ gì đó có ích — nhưng mất nhiều thời gian hơn là tự làm.
Đây là điều thực sự xảy ra: mô hình chỉ có thể làm việc với những gì bạn đặt trước mặt nó. Nó không biết codebase của bạn trông như thế nào, không biết các ràng buộc của bạn, không thể thấy những gì bạn đã thử, và không có bất kỳ nền tảng nào về lý do bạn hỏi. Khi AI trả lời sai, nguyên nhân gốc rễ hầu như luôn là thiếu thông tin — không phải cách diễn đạt, không phải mẹo prompt. Đây là cốt lõi của cái mà cộng đồng AI gọi là context engineering.
Context engineering là kỹ năng thiết kế có chủ đích thông tin bạn cung cấp cho AI — vai trò, bối cảnh, nhiệm vụ, ràng buộc và định dạng đầu ra — để nó có thể tạo ra kết quả thực sự hữu ích mà không cần nhiều vòng hỏi đáp.
Context engineering thực sự là gì
Andrej Karpathy phổ biến thuật ngữ này vào năm 2025, và sự khác biệt với "prompt engineering" rất quan trọng. Prompt engineering là về lựa chọn từ ngữ. Context engineering đi sâu hơn một tầng: đó là về thông tin nào bạn cung cấp trước khi mô hình tạo ra bất cứ điều gì.
Hãy nghĩ về nó như mise en place — thực hành của đầu bếp khi chuẩn bị đầy đủ nguyên liệu trước khi bắt đầu nấu. Một đầu bếp giỏi không ứng biến với nguyên liệu thiếu giữa chừng. Context engineering là làm công việc chuẩn bị đó cho đồng nghiệp AI của bạn. Bối cảnh càng đầy đủ và có tổ chức, kết quả đầu tiên càng tốt.
Giải phẫu một context window
Mọi tương tác với AI đều xảy ra trong một "bộ nhớ làm việc" — context window chứa mọi thứ mô hình có thể "nhìn thấy" khi tạo phản hồi. Có bốn tầng riêng biệt.
System Prompt là tầng mạnh nhất và bị bỏ qua nhiều nhất. Nó thiết lập persona, mức độ chuyên môn và các quy tắc chi phối mọi phản hồi trong phiên làm việc. Một system prompt được thiết kế tốt giống như việc đưa cho mô hình một bản mô tả công việc trước khi nó bắt đầu.
Injected Context là nơi bạn cung cấp nguyên liệu thô: file code, tài liệu, log lỗi, sơ đồ database. Đây là thứ mô hình suy luận — sự khác biệt giữa "hãy sửa cái này" (không có bối cảnh) và "đây là code, lỗi, và tài liệu liên quan" (bối cảnh phong phú).
Conversation History tích lũy khi phiên làm việc tiến triển. Mỗi trao đổi được thêm vào những gì mô hình có thể thấy — hữu ích nhưng cũng tốn kém về token.
User Message là phần nổi của tảng băng: câu hỏi thực tế. Mặc dù là thứ mọi người tập trung nhất, nó thường chiếm dưới 5% tổng token trong một setup được thiết kế tốt.
Tại sao hầu hết prompt thất bại: năm khoảng trống
Bối cảnh mỏng tạo ra đầu ra chung chung. Mô hình không có cách nào biết bạn thực sự cần gì, vì vậy nó mặc định câu trả lời có xác suất thống kê cao nhất — thường quá rộng, quá mơ hồ, hoặc nhắm vào đối tượng sai. Có năm khoảng trống cụ thể gây ra điều này.
Không có role. Không có persona, mô hình mặc định là "trợ lý hữu ích chung" — không phải lúc nào cũng đúng.
Không có state. Mô hình không biết đã thử gì, ràng buộc là gì. Bạn yêu cầu nó giải câu đố trong khi giấu câu đố.
Nhiệm vụ mơ hồ. "Giúp tôi với cái này" có thể có nghĩa là hàng trăm thứ. Nhiệm vụ mơ hồ tạo ra phản hồi né tránh mọi quyết định mà mô hình không thể đưa ra.
Không có ràng buộc. Mô hình khám phá toàn bộ không gian giải pháp — và có thể gợi ý thứ bạn không thể dùng.
Định dạng không xác định. Bạn nhận được bất cứ thứ gì mô hình cho là phù hợp — bài luận 500 chữ khi bạn muốn bullet points.
Năm trụ cột của context chất lượng cao
Mỗi khoảng trống tương ứng với một trụ cột. Context engineering giỏi nghĩa là giải quyết cả năm.
Trụ cột 1: Role
Xác định mô hình nên là ai — chuyên môn, góc nhìn, phong cách giao tiếp. Thay đổi đơn này định hình từ vựng, độ sâu, và những đánh đổi nào được nhấn mạnh.
| Không có role | Có role |
|---|---|
Giải thích authentication. |
Bạn là kỹ sư backend cao cấp chuyên về bảo mật, viết cho developer junior biết JavaScript nhưng chưa triển khai auth. Giải thích JWT tập trung vào đánh đổi bảo mật và những gì có thể sai. |
Trụ cột 2: State
Cho mô hình biết những gì đã tồn tại: cấu trúc codebase, những gì đã thử, những gì không hoạt động, quyết định đã đưa ra, ràng buộc đang áp dụng.
| Không có state | Có state |
|---|---|
Sửa bug này.(chỉ paste code) |
[code] Hàm debounce này hoạt động tốt với input thông thường nhưng thất bại khi scroll nhanh — fires ngay lập tức thay vì chờ. Đã thử clearTimeout, vẫn lỗi. Stack: React 18, TypeScript. Lỗi console: [message]. |
Trụ cột 3: Task
Chỉ định chính xác bạn muốn gì, không phải một danh mục của nó. "Giúp tôi với API" là danh mục. "Viết Express middleware xác thực JWT token, trả về 401 nếu thiếu hoặc không hợp lệ, gắn user đã giải mã vào req.user" là task.
Trụ cột 4: Constraints
Nói với mô hình những gì không thể làm, những gì cần tránh. Ràng buộc nghe có vẻ hạn chế nhưng thực ra giải phóng phản hồi — chúng loại bỏ toàn bộ lớp câu trả lời "đúng kỹ thuật nhưng vô dụng trong trường hợp của tôi".
Viết ràng buộc dưới dạng câu phủ định rõ ràng: "đừng dùng", "tránh". Mô hình được huấn luyện để hữu ích và tự nhiên mở rộng phạm vi. Phủ định rõ ràng là rào cản đáng tin cậy nhất bạn có.
Trụ cột 5: Format
Chỉ định hình dạng đầu ra: độ dài, cấu trúc, mức độ chi tiết. Không có hướng dẫn định dạng, bạn nhận được bất cứ thứ gì mô hình cho là phù hợp.
Anti-pattern âm thầm phá hoại kết quả
| Anti-pattern | Tại sao thất bại | Cách sửa |
|---|---|---|
| Naked paste | Paste khối code lớn không có framing và câu hỏi mơ hồ. | Thêm tóm tắt: code làm gì, vấn đề là gì, đã thử gì. |
| Bundle request | "Review, viết tests và refactor naming" — ba task trong một tin nhắn. | Một task mỗi tin nhắn. |
| Context collapse | Hỏi câu mới phụ thuộc vào quyết định sáu trao đổi trước. | Re-inject quyết định quan trọng: "Chúng ta đã quyết định dùng Redis. Bây giờ..." |
Xây dựng context template tái sử dụng
Khi đã hiểu năm trụ cột, hãy biến chúng thành templates tái sử dụng. Đây là template kỹ thuật đa năng:
## Role
Bạn là [ROLE], chuyên về [DOMAIN].
Đối tượng là [AUDIENCE] với [BỐI CẢNH CHÍNH].
## Background state
Tech stack: [NGÔN NGỮ / FRAMEWORK / CÔNG CỤ]
Hiện trạng: [MÔ TẢ NGẮN]
Đã thử: [CÁC LỖI VÀ KẾT QUẢ]
Lỗi liên quan: [NẾU CÓ]
## Task
[MỘT CÂU CHÍNH XÁC: động từ + đối tượng + phạm vi]
## Constraints
- KHÔNG dùng [THƯ VIỆN / CÁCH TIẾP CẬN]
- Giữ [KHÍA CẠNH] dưới [GIỚI HẠN]
## Output format
[ĐỘ DÀI] — [CẤU TRÚC] — [MỨC ĐỘ CHI TIẾT]Câu hỏi về ngân sách token
Context engineering có giới hạn thực tế: mỗi token bạn đưa vào là token không dành cho thứ khác. Bối cảnh liên quan, tập trung và có cấu trúc luôn vượt trội hơn bối cảnh lớn không tập trung.
Trước khi paste bất cứ thứ gì, hỏi: điều này có giúp mô hình trả lời câu hỏi không? Nếu là "phòng trường hợp", hãy bỏ qua. Sự chú ý của mô hình loãng ra trên mọi thứ trước mặt nó.
Điểm chính cần nhớ
- Context engineering > prompt engineering: thông tin bạn cung cấp quan trọng hơn từ ngữ bạn chọn. Input tốt hơn = output tốt hơn.
- Bốn tầng, một ngân sách: system prompt, injected context, conversation history, user message — mỗi cái có mục đích khác nhau và cùng cạnh tranh token.
- Năm trụ cột, năm khoảng trống: Role, State, Task, Constraints, Format. Bao quát cả năm và số vòng hỏi đáp giảm mạnh.
- Xây dựng templates tái sử dụng: một template code review tốt đáng để xây dựng một lần và dùng hàng trăm lần.
- Chất lượng hơn số lượng: bối cảnh tập trung, liên quan luôn thắng bối cảnh lớn không có trọng tâm.
Context engineering là thói quen tư duy: trước khi gửi prompt, dừng lại và hỏi bạn cần giải thích gì cho đồng nghiệp mới thông minh để task này hoàn chỉnh. Thêm điều đó. Bỏ những gì không liên quan. Bạn sẽ ít thời gian lặp đi lặp lại hơn và nhiều thời gian thực sự sử dụng kết quả hơn.