Prompt hay chưa đủ: Muốn AI làm việc đáng tin, hãy thiết kế “bàn làm việc” cho nó
Một học sinh năm thứ 3 và một nhân viên mới có một năm kinh nghiệm cùng mở một mô hình AI, cùng gõ một câu hỏi, thậm chí cùng dùng một prompt mẫu.
Kết quả vẫn có thể khác nhau một trời một vực.
Không nhất thiết vì người này “biết prompt” hơn người kia. Khác biệt lớn hơn thường nằm ở phần AI được nhìn thấy trước khi trả lời: mục tiêu, dữ liệu, lịch sử trao đổi, quy tắc, ví dụ, công cụ và giới hạn của công việc.
Phần đó gọi là context — ngữ cảnh.
Và việc chủ động quyết định thông tin nào cần được ghi lại, đưa vào, rút gọn hay tách riêng chính là context engineering — kỹ thuật thiết kế ngữ cảnh.
Đây là một thay đổi quan trọng trong cách doanh nghiệp nên nghĩ về AI. Một hệ thống AI tốt không chỉ là “model mạnh + prompt hay”. Nó là một môi trường làm việc được thiết kế đúng quanh model. Nếu muốn thấy tư duy này ở cấp độ kiến trúc, bạn có thể đọc thêm bản thiết kế bốn tầng biến Claude Code từ chatbot thành hệ thống làm việc.
Một phép thử rất đơn giản
Hãy tưởng tượng bạn tuyển một nhân sự rất thông minh vào công ty.
Ngày đầu tiên, bạn chỉ nói:
Hãy phân tích tình hình kinh doanh và đề xuất kế hoạch tốt nhất.
Người đó sẽ phải hỏi lại ngay:
Phân tích đơn vị nào?
Mục tiêu quý này là tăng doanh thu hay giữ biên lợi nhuận?
Số liệu nào là bản mới nhất?
Sản phẩm nào đang được ưu tiên?
Những phương án nào đã thử và thất bại?
Người nhận bản phân tích là CEO hay trưởng nhóm vận hành?
Họ được phép đọc dữ liệu nào và hành động đến đâu?
Nếu không trả lời những câu hỏi này, ta không thể kết luận nhân sự “kém” chỉ vì bản kế hoạch chung chung.
Nhưng với AI, nhiều đội ngũ lại đang làm đúng như vậy: đưa một yêu cầu mơ hồ, không kèm bối cảnh, rồi đổi model hoặc sửa câu chữ của prompt khi kết quả không đạt.
Prompt là lời giao việc. Context là toàn bộ bàn làm việc.
Trên bàn đó có hồ sơ khách hàng, số liệu, quy trình, các quyết định trước đây, tiêu chuẩn đầu ra và những công cụ cần dùng. Lời giao việc có rõ đến đâu mà bàn làm việc trống trơn thì AI vẫn phải đoán.
Context đến từ đâu?
Trong một tác vụ thật, ngữ cảnh thường được ghép từ nhiều nguồn:
Chỉ dẫn của hệ thống: AI đóng vai trò gì, mục tiêu nào cần tối ưu, điều gì không được làm.
Yêu cầu hiện tại của người dùng: việc cụ thể cần hoàn thành trong phiên này.
Tri thức của tổ chức: sản phẩm, quy trình, chính sách, dữ liệu, cách gọi nội bộ.
Lịch sử làm việc: những gì hai bên đã thống nhất, phản hồi cũ, lỗi đã sửa.
Kết quả từ công cụ: dữ liệu lấy từ CRM, email, kho tài liệu, bảng tính hay phần mềm nội bộ.
Trạng thái hiện tại: hồ sơ nào đang mở, bước nào đã xong, việc gì còn chờ xác nhận.
Vấn đề là lượng thông tin này chỉ có tăng.
Một agent làm việc nhiều bước sẽ gọi công cụ, nhận kết quả, thử một hướng, gặp lỗi, sửa lại rồi tiếp tục. Tất cả đều có thể chảy vào cửa sổ ngữ cảnh. Nếu cứ chất mọi thứ vào, chi phí và độ trễ tăng lên, trong khi chất lượng chưa chắc tăng.
Thậm chí còn có thể giảm.
Ngữ cảnh quá dài và thiếu tổ chức tạo ra ba kiểu lỗi rất thực tế:
Nhiễm độc ngữ cảnh: một kết luận sai lọt vào lịch sử rồi tiếp tục ảnh hưởng các bước sau.
Nhiễu ngữ cảnh: thông tin không liên quan giành mất sự chú ý khỏi nhiệm vụ hiện tại.
Xung đột ngữ cảnh: hai tài liệu hoặc hai chỉ dẫn nói những điều trái nhau mà không có quy tắc ưu tiên.
Vậy nên mục tiêu không phải là cho AI nhiều thông tin nhất. Mục tiêu là cho AI đúng thông tin, đúng lúc, đúng phạm vi.
Hai người dùng cùng một AI, hai kết quả khác nhau
Ví dụ 1: Một học sinh năm thứ 3
Minh là học sinh năm thứ 3 ngành kinh doanh. Tuần sau Minh phải thuyết trình đề án mở rộng cho một thương hiệu cà phê tưởng tượng.
Cách dùng AI đầu tiên của Minh là:
Viết cho tôi một kế hoạch mở rộng thương hiệu cà phê thật chuyên nghiệp.
AI trả về một bản kế hoạch nhìn rất “đúng bài”: nghiên cứu thị trường, xác định khách hàng mục tiêu, mở thêm cửa hàng, chạy quảng cáo mạng xã hội. Nhưng gần như nhóm nào trong lớp cũng có thể nhận được một câu trả lời tương tự.
Minh thử lại. Lần này, bạn tạo một gói ngữ cảnh ngắn gồm:
yêu cầu chấm điểm của giảng viên;
chân dung thương hiệu và mức giá;
dữ liệu khảo sát 60 sinh viên;
giới hạn ngân sách giả định;
hai địa điểm nhóm đang cân nhắc;
ba nhận xét giảng viên đã góp ý ở buổi trước;
định dạng đầu ra: 8 slide, mỗi slide một luận điểm và một bằng chứng.
Prompt cuối cùng của Minh không hề “thần thánh”:
Dựa trên gói thông tin này, hãy đề xuất cấu trúc 8 slide. Nếu dữ liệu chưa đủ để kết luận, đánh dấu giả định thay vì tự bịa thêm.
Kết quả tốt hơn không phải vì AI bỗng thông minh hơn. Minh đã biến một yêu cầu chung chung thành một môi trường ra quyết định có dữ liệu, ranh giới và tiêu chuẩn.
Đó đã là context engineering, dù Minh không viết một dòng code nào.
Ví dụ 2: Một nhân viên mới có một năm kinh nghiệm
Lan làm ở bộ phận chăm sóc khách hàng được một năm. Công ty muốn dùng AI để soạn câu trả lời cho các khiếu nại giao hàng.
Ở bản thử nghiệm đầu, đội dự án đưa toàn bộ sổ tay vận hành, hàng trăm email cũ và mọi chính sách vào một cuộc hội thoại dài. Câu trả lời lúc đúng, lúc sai. Có lúc AI trích chính sách đã hết hiệu lực. Có lúc nó đề nghị hoàn tiền vượt quá thẩm quyền của Lan.
Lan không phải kỹ sư AI, nhưng bạn biết công việc thật diễn ra thế nào. Lan đề nghị tách bộ ngữ cảnh thành:
chính sách hiện hành đã được duyệt;
bảng quyền hạn theo vai trò;
thông tin đơn hàng được truy xuất khi có mã;
năm ví dụ trả lời tốt đã ẩn dữ liệu cá nhân;
quy tắc bắt buộc chuyển cho con người nếu liên quan pháp lý, sức khỏe hoặc khoản điều chỉnh vượt hạn mức.
Mỗi khi có yêu cầu, hệ thống chỉ lấy phần liên quan đến loại khiếu nại đó. Lịch sử dài được tóm tắt thành vài quyết định quan trọng. Hồ sơ của khách hàng này không lẫn sang khách hàng khác.
Lan không “train model”. Bạn thiết kế đường đi của ngữ cảnh.
Đây cũng là lý do người hiểu nghiệp vụ có vai trò rất lớn trong dự án AI. Kỹ sư có thể xây đường ống, nhưng người làm việc thật mới biết dữ liệu nào đáng tin, ngoại lệ nào nguy hiểm và lúc nào phải dừng để hỏi con người.
Bốn động tác cốt lõi: Ghi, Chọn, Nén, Tách
Một cách dễ nhớ để thiết kế ngữ cảnh là dùng bốn động tác: Write, Select, Compress, Isolate.
1. Ghi lại: Điều gì cần tồn tại sau phiên chat này?
Không phải thông tin nào cũng nên biến mất khi đóng cửa sổ.
Một số thứ cần được lưu bền vững:
kiến trúc và tiêu chuẩn của dự án;
định nghĩa chỉ số;
giọng văn thương hiệu;
quy trình đã được phê duyệt;
sở thích làm việc ổn định của người dùng;
bài học từ những lỗi đã xảy ra.
Nhưng “ghi lại” không có nghĩa là chép toàn bộ cuộc trò chuyện vào một file khổng lồ. Bộ nhớ tốt cần có chủ sở hữu, ngày cập nhật, phạm vi áp dụng và quy tắc tránh trùng lặp.
Một nguyên tắc thực dụng:
Chỉ ghi vào bộ nhớ dài hạn những gì có khả năng thay đổi cách AI xử lý nhiều nhiệm vụ trong tương lai.
Một yêu cầu tạm thời cho báo cáo chiều nay không nên trở thành luật chung của cả công ty.
2. Chọn lọc: Tác vụ này thật sự cần biết gì?
Khi nhân viên xử lý một đơn hàng, họ không cần mở toàn bộ kho tài liệu của doanh nghiệp. AI cũng vậy.
Hệ thống nên lựa chọn ngữ cảnh theo:
loại nhiệm vụ;
vai trò của người yêu cầu;
khách hàng hoặc dự án đang xử lý;
công cụ sắp được dùng;
mức độ mới và độ tin cậy của dữ liệu.
Ví dụ, trước khi sửa một file, coding agent cần xem cấu trúc code và quy ước liên quan. Trước khi chạy lệnh, nó cần biết đường dẫn có tồn tại không và dự án đã có script phù hợp chưa. Cùng một agent, nhưng mỗi hành động cần một gói ngữ cảnh khác.
Trong doanh nghiệp, lớp chọn lọc này thường quan trọng hơn việc nhồi thêm tài liệu. Cùng một nguyên tắc cũng xuất hiện trong thiết kế trải nghiệm số: context chỉ có ích khi giúp người dùng tìm đúng đường, không phải khi nó biến thành một kho thông tin không có thứ tự.
3. Nén gọn: Giữ quyết định, bỏ tiếng ồn
Sau 30 lượt trao đổi, không phải câu nào cũng còn giá trị như nhau.
Ta có thể nén lịch sử thành:
mục tiêu hiện tại;
các quyết định đã chốt;
giả định đang dùng;
dữ liệu nguồn quan trọng;
việc đã thử nhưng thất bại;
câu hỏi còn mở.
Nén không phải là cắt bớt ngẫu nhiên. Nếu bản tóm tắt làm mất một ràng buộc quan trọng, AI có thể lặp lại lỗi cũ. Vì vậy, doanh nghiệp nên xác định rõ loại thông tin nào bắt buộc phải sống sót qua quá trình tóm tắt.
4. Tách riêng: Đừng bắt một ngữ cảnh làm mọi việc
Một agent vừa nghiên cứu, vừa viết, vừa kiểm tra bảo mật, vừa duyệt chính sách trong cùng một lịch sử dài rất dễ bị lẫn vai trò.
Cách tốt hơn là chia thành các phạm vi:
agent nghiên cứu chỉ thu thập và đánh giá nguồn;
agent soạn thảo chỉ làm việc với brief đã duyệt;
agent kiểm tra tập trung vào rủi ro và tiêu chuẩn;
agent điều phối giữ trạng thái chung và chuyển giao kết quả cần thiết.
Mỗi phần có cửa sổ ngữ cảnh riêng. Chúng không cần thừa kế toàn bộ “hành lý” của nhau.
Tách riêng không đồng nghĩa với dựng 15 agent ngay ngày đầu. Nếu một quy trình với một agent còn chưa ổn định, nhân nó lên chỉ tạo ra 15 nguồn lỗi. Hãy bắt đầu bằng một tác vụ thật, đo kết quả, rồi chỉ tách khi phạm vi đã đủ rõ.
System prompt vẫn quan trọng — nhưng đừng biến nó thành kho chứa
Context engineering không làm system prompt mất giá trị.
System prompt vẫn là nơi xác định:
danh tính và phạm vi của agent;
mục tiêu ưu tiên;
cách tiếp cận chung;
ranh giới an toàn;
điều kiện chuyển việc cho con người.
Sai lầm phổ biến nằm ở hai cực.
Ở cực thứ nhất, prompt quá chi tiết, cố viết sẵn mọi nhánh “nếu… thì…”. Agent bị đối xử như một cỗ máy trạng thái, quy tắc chồng chéo và trường hợp mới xuất hiện là hệ thống gãy.
Ở cực thứ hai, prompt quá mơ hồ:
Hãy hỗ trợ khách hàng đúng tinh thần thương hiệu và chuyển cho con người khi cần.
“Tinh thần thương hiệu” là gì? “Khi cần” là khi nào? AI không thể đọc suy nghĩ của tổ chức.
Vùng ở giữa hiệu quả hơn: nêu rõ vai trò, mục tiêu, một khung xử lý, các nguyên tắc ra quyết định và vài ranh giới không được vượt qua. Chẳng hạn:
Hiểu vấn đề cốt lõi.
Dùng công cụ để xác minh dữ liệu liên quan.
Đề xuất bước tiếp theo rõ ràng.
Xác nhận người dùng hiểu cách xử lý.
Chuyển cho con người nếu có rủi ro pháp lý, sức khỏe hoặc tài chính vượt thẩm quyền.
Đây là khung suy luận, không phải một sơ đồ cứng cho mọi tình huống.
Một “context brief” có thể dùng ngay
Trước khi giao một việc quan trọng cho AI, hãy chuẩn bị một brief ngắn theo mẫu sau:
1. Mục tiêu
Kết quả nào cần đạt? Ai sẽ dùng kết quả đó? Họ sẽ dùng để làm gì?
2. Dữ liệu được phép dùng
Tài liệu nào là nguồn chuẩn? Phiên bản nào mới nhất? Có dữ liệu nào không được đưa vào không?
3. Trạng thái hiện tại
Việc gì đã làm? Quyết định nào đã chốt? Điểm nào còn chưa chắc chắn?
4. Ràng buộc
Thời gian, ngân sách, thẩm quyền, định dạng, chính sách và các điều cấm.
5. Ví dụ
Một hoặc hai đầu ra tốt; nếu có, thêm một ví dụ sai và giải thích vì sao sai.
6. Công cụ
AI có thể đọc, tìm, tính toán hay cập nhật ở đâu? Công cụ nào chỉ được dùng sau khi con người xác nhận?
7. Tiêu chí hoàn thành
Điều gì phải được kiểm tra trước khi báo “xong”? Phần nào cần ghi rõ là giả định?
Brief này không cần dài. Với nhiều tác vụ, một trang được cập nhật cẩn thận tốt hơn 50 trang tài liệu ném vào cùng lúc.
Nếu đang triển khai AI trong doanh nghiệp, hãy bắt đầu ở đâu?
Đừng bắt đầu bằng câu hỏi: “Chúng ta nên dùng model nào?”
Hãy chọn một quy trình có đầu vào và đầu ra đủ rõ, rồi quan sát cách một nhân viên giỏi làm thật:
Họ mở những tài liệu nào?
Họ bỏ qua những tài liệu nào?
Họ kiểm tra dữ liệu ở đâu?
Họ dựa vào kinh nghiệm ngầm nào?
Khi nào họ dừng và hỏi người khác?
Họ biết công việc đã xong bằng cách nào?
Sau đó, thiết kế luồng ngữ cảnh quanh sáu câu trả lời ấy.
Phiên bản đầu tiên có thể rất nhỏ: một prompt rõ vai trò, một thư mục tài liệu đã duyệt, một bước lấy dữ liệu đúng lúc và một checklist kiểm tra đầu ra. Đo độ chính xác, thời gian xử lý, số lần phải làm lại và số trường hợp cần chuyển cho người. Khi bài toán bắt đầu phụ thuộc vào dữ liệu lớn và dự báo, hãy tách riêng câu hỏi “có dữ liệu gì” khỏi câu hỏi “AI có thể dự đoán điều gì xảy ra tiếp theo?”.
Khi quy trình chạy ổn, mới thêm bộ nhớ, tự động truy xuất, nén lịch sử hay các agent chuyên biệt.
Đó là cách biến AI từ màn trình diễn thành hạ tầng làm việc.
Điều cần nhớ
Model có thể ngày càng mạnh, nhưng nó vẫn không đọc được suy nghĩ của bạn.
Khi AI trả lời kém, đừng vội hỏi “prompt nào hay hơn?”. Hãy kiểm tra bốn việc:
Có điều quan trọng nào chưa được ghi lại?
Có thông tin nào cần chọn đúng lúc thay vì tải tất cả?
Lịch sử đã đủ dài để cần nén chưa?
Có nhiệm vụ hoặc dữ liệu nào cần tách sang phạm vi riêng không?
Ghi. Chọn. Nén. Tách.
Đó là bốn động tác đơn giản để bắt đầu context engineering.
Và có lẽ đây là khoảng cách thật sự giữa hai cách dùng AI: một bên liên tục nghĩ ra câu lệnh mới; bên còn lại xây một môi trường để AI có thể làm đúng việc, với đúng dữ liệu, trong đúng giới hạn.
Bạn đang có quy trình nào mà AI lúc làm đúng, lúc làm sai dù prompt gần như không đổi? Hãy thử nhìn lại “bàn làm việc” mà bạn đã đưa cho nó trước khi đổi model.