Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa thuê được một nhân viên cực kỳ thông minh, đọc qua gần như toàn bộ Internet, nhưng lại có một đặc điểm kỳ lạ: anh ta chỉ làm đúng những gì bạn nói, theo cách bạn nói, và sẽ "đoán" phần còn lại nếu bạn nói mơ hồ. Đó chính xác là bản chất của việc làm việc với một mô hình ngôn ngữ lớn (LLM). Chất lượng đầu ra không phụ thuộc vào việc mô hình "giỏi" tới đâu, mà phụ thuộc rất lớn vào cách bạn ra đề bài. Kỹ năng ra đề bài đó gọi là prompt engineering — kỹ thuật thiết kế câu lệnh đầu vào để mô hình trả về kết quả đúng ý, ổn định và đáng tin cậy.
Với một AI Product Manager, đây không phải là kỹ năng "biết thì tốt" mà là kỹ năng nền tảng. Trong rất nhiều sản phẩm AI hiện nay, prompt chính là phần logic nghiệp vụ cốt lõi — nó quyết định trợ lý chăm sóc khách hàng trả lời lịch sự hay cộc lốc, công cụ tóm tắt hợp đồng có bỏ sót điều khoản quan trọng hay không, chatbot có tự bịa ra thông tin sai lệch hay không. Khi bạn chưa có ngân sách fine-tune mô hình, prompt là "vô lăng" duy nhất bạn có để lái hành vi sản phẩm. Một PM hiểu prompt engineering sẽ ước lượng được tính khả thi của tính năng nhanh hơn, viết được spec rõ ràng hơn cho đội kỹ thuật, và quan trọng nhất: tự mình thử nghiệm được ý tưởng trong vài phút thay vì chờ một sprint.
Bài này tập trung vào nền tảng — giải phẫu một prompt tốt và các nguyên tắc cốt lõi. Những kỹ thuật nâng cao như chain-of-thought, few-shot phức tạp hay các pattern đặc thù sẽ được bàn ở Bài 15. Mục tiêu hôm nay là giúp bạn viết được những prompt vững chắc, có cấu trúc, mà đội của bạn có thể dùng ngay trong sản phẩm thật.
Khái niệm cốt lõi
Prompt là gì và vì sao cấu trúc lại quan trọng
Prompt đơn giản là đoạn văn bản bạn gửi cho mô hình. Nhưng đừng nhầm "đơn giản" với "tùy tiện". LLM hoạt động bằng cách dự đoán phần văn bản tiếp theo dựa trên toàn bộ phần đã có. Vì vậy, mỗi từ bạn đặt vào prompt đều là một tín hiệu định hướng. Một prompt được cấu trúc rõ ràng giúp mô hình thu hẹp không gian "đoán", từ đó cho kết quả ổn định và đúng ý hơn. Một prompt lan man, thiếu ngữ cảnh sẽ khiến mô hình phải tự lấp đầy khoảng trống — và đó là lúc nó hay "sáng tác".
Giải phẫu một prompt tốt: 5 thành phần
Một prompt chất lượng trong môi trường sản phẩm thường gồm năm khối. Bạn không bắt buộc dùng đủ cả năm trong mọi trường hợp, nhưng hiểu rõ từng khối giúp bạn biết mình đang thiếu gì khi kết quả chưa đạt.
1. Role (Vai trò). Bạn gán cho mô hình một danh tính: "Bạn là một chuyên gia tư vấn thuế tại Việt Nam, am hiểu Luật Thuế thu nhập cá nhân hiện hành." Việc gán vai trò không phải là "diễn kịch" cho vui — nó kích hoạt vùng kiến thức và văn phong phù hợp, đồng thời đặt ra một chuẩn mực chất lượng. Một mô hình được bảo "bạn là chuyên gia tư vấn thuế" sẽ trả lời cẩn trọng và dùng thuật ngữ chính xác hơn so với khi không có vai trò.
2. Task (Nhiệm vụ). Đây là yêu cầu cụ thể, dùng động từ rõ ràng: "Hãy giải thích cách tính thuế thu nhập cá nhân cho khoản thưởng Tết." Task cần đơn nghĩa. "Phân tích đoạn này" là task mơ hồ; "Liệt kê ba rủi ro pháp lý trong đoạn hợp đồng này" là task rõ ràng.
3. Context (Ngữ cảnh). Đây là phần dữ liệu nền mà mô hình cần để làm đúng nhiệm vụ: thông tin về khách hàng, đoạn văn bản cần xử lý, các ràng buộc nghiệp vụ. Ví dụ: "Khách hàng có thu nhập 25 triệu/tháng, đã có một người phụ thuộc." Context là nơi bạn "nạp" thực tế cụ thể vào, để mô hình không trả lời chung chung.
4. Format (Định dạng đầu ra). Bạn mô tả chính xác hình dạng kết quả mong muốn: "Trả về dưới dạng JSON với các trường thue_phai_nop, cach_tinh, luu_y." Trong sản phẩm thật, đây là khối quan trọng bậc nhất, vì đầu ra của LLM thường được đưa thẳng vào một hệ thống khác để xử lý tiếp. Đầu ra sai định dạng sẽ làm vỡ luồng xử lý.
5. Constraints (Ràng buộc). Các giới hạn và quy tắc an toàn: "Chỉ trả lời dựa trên thông tin được cung cấp. Nếu không đủ dữ liệu, hãy nói 'Tôi chưa đủ thông tin để trả lời' thay vì phỏng đoán. Trả lời ngắn gọn, tối đa 150 từ." Ràng buộc giúp bạn kiểm soát rủi ro, đặc biệt là rủi ro mô hình bịa thông tin.
System prompt và user prompt
Hầu hết các API hiện đại (OpenAI, Anthropic, Google) phân tách prompt thành hai vai: system prompt chứa các hướng dẫn cố định, lâu dài — thường là Role, Format và Constraints; còn user prompt chứa nội dung thay đổi theo từng lượt — thường là Task và Context cụ thể. Là PM, bạn nên nghĩ về điều này như tách "chính sách của sản phẩm" (system) ra khỏi "câu hỏi của người dùng" (user). Cách tách này giúp prompt dễ bảo trì và an toàn hơn, vì người dùng cuối không dễ ghi đè các quy tắc nằm trong system prompt.
Nguyên tắc cụ thể đánh bại nguyên tắc thông minh
Một hiểu lầm phổ biến là phải viết prompt thật "khéo", thật văn hoa. Thực tế ngược lại: prompt tốt là prompt cụ thể và rõ ràng. Thay vì "viết một cách chuyên nghiệp", hãy nói "dùng giọng trang trọng, xưng 'chúng tôi', không dùng tiếng lóng, mỗi câu không quá 20 từ". Mô hình không đọc được suy nghĩ của bạn — nó chỉ làm theo những gì được viết ra.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán phân loại đánh giá sản phẩm
Giả sử đội sản phẩm của một sàn thương mại điện tử lớn như Tiki muốn tự động phân loại hàng chục nghìn đánh giá (review) mỗi ngày để đẩy nhanh việc xử lý khiếu nại. Phiên bản prompt đầu tiên mà một bạn dev viết là: "Đọc review này và cho biết nó tích cực hay tiêu cực."
Kết quả là một mớ hỗn độn. Có lúc mô hình trả lời "Đánh giá này khá tích cực, người dùng hài lòng về...", có lúc lại trả về "Tiêu cực". Khi review nói "giao hàng nhanh nhưng sản phẩm bị móp", mô hình trả lời dài dòng và không nhất quán. Đội kỹ thuật không thể đưa output này vào hệ thống tự động.
Sau khi áp dụng giải phẫu prompt, họ viết lại: gán Role "Bạn là hệ thống phân loại cảm xúc đánh giá sản phẩm"; Task "Phân loại đánh giá sau"; Constraints "Chỉ chọn một trong ba nhãn: TICH_CUC, TIEU_CUC, TRUNG_TINH"; và Format "Trả về JSON: {\"nhan\": \"...\", \"ly_do\": \"<tối đa 15 từ>\", \"can_xu_ly\": true/false}". Trường can_xu_ly được dùng để gắn cờ những review cần nhân viên xem ngay.
Bài học: chính các khối Constraints (giới hạn nhãn) và Format (JSON cố định) đã biến một đầu ra "không dùng được" thành một thành phần đáng tin trong pipeline. Tính cụ thể, chứ không phải sự thông minh của câu chữ, là thứ tạo ra giá trị.
Ví dụ 2 — Phòng khám tư và trợ lý đặt lịch biết "thú nhận khi không biết"
Một chuỗi phòng khám tư ở TP.HCM xây chatbot trả lời câu hỏi của bệnh nhân về dịch vụ và lịch khám. Trong giai đoạn thử nghiệm, chatbot mắc một lỗi nguy hiểm: khi được hỏi "Bác sĩ có kê thuốc kháng sinh nào cho viêm họng không?", nó tự tin đưa ra tên thuốc và liều lượng — hoàn toàn bịa ra. Đây là rủi ro pháp lý và y tế nghiêm trọng.
Vấn đề nằm ở chỗ prompt ban đầu chỉ có Role và Task, thiếu hẳn Constraints. Đội PM thêm vào hai ràng buộc bản lề: "Bạn TUYỆT ĐỐI không được tư vấn thuốc, liều lượng hay chẩn đoán y khoa. Với những câu hỏi như vậy, hãy trả lời: 'Nội dung này cần bác sĩ tư vấn trực tiếp, bạn vui lòng đặt lịch khám.' Bạn chỉ trả lời dựa trên thông tin về dịch vụ, giá và lịch khám được cung cấp dưới đây." Họ cũng thêm Context là danh sách dịch vụ và bảng giá thực tế.
Sau thay đổi, chatbot từ chối lịch sự đúng những câu nằm ngoài phạm vi an toàn và bám sát dữ liệu được nạp. Bài học: với sản phẩm AI trong lĩnh vực nhạy cảm, Constraints không phải là "phần thêm" mà là thành phần quyết định việc sản phẩm có được phép ra mắt hay không. Một PM giỏi luôn hỏi: "Mô hình nên làm gì khi nó không biết?"
Ví dụ 3 — Startup SaaS và sức mạnh của một ví dụ mẫu
Một startup SaaS làm công cụ viết email bán hàng cho đội sales ở Đông Nam Á gặp tình trạng email do AI tạo ra "đúng nhưng nhạt", không khớp giọng điệu thương hiệu. Họ đã mô tả rất kỹ trong prompt: "giọng thân thiện, chuyên nghiệp, có lời kêu gọi hành động"... nhưng kết quả vẫn chung chung.
Bước ngoặt đến khi họ thêm vào prompt một ví dụ mẫu (one-shot): dán nguyên một email mẫu mà đội sales tâm đắc, kèm dòng "Hãy viết theo đúng phong cách, độ dài và cấu trúc của ví dụ sau." Lập tức chất lượng nhảy vọt — mô hình bắt chước được nhịp câu, cách mở đầu, cách chốt mà không cần mô tả dài dòng.
Bài học: đôi khi cho mô hình xem một ví dụ hiệu quả hơn nhiều so với mô tả bằng lời. Đây là nguyên lý nền của few-shot prompting. Một ví dụ tốt mang theo vô số chi tiết ngầm mà ngôn ngữ khó diễn đạt hết.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng để xây và tinh chỉnh một prompt cho sản phẩm.
Bước 1 — Viết rõ mục tiêu trước khi viết prompt. Trả lời một câu: "Đầu ra hoàn hảo trông như thế nào?" Nếu chính bạn còn mơ hồ, mô hình chắc chắn sẽ mơ hồ. Hãy viết tay 2–3 ví dụ output lý tưởng làm chuẩn đối chiếu.
Bước 2 — Dựng khung 5 thành phần. Lần lượt điền Role, Task, Context, Format, Constraints. Nếu một khối không cần thiết, hãy bỏ qua một cách có chủ đích, không phải vì quên.
Bước 3 — Đặt phần hướng dẫn và phần dữ liệu tách bạch. Dùng dấu phân cách rõ ràng (ví dụ """ hoặc thẻ như <review>...</review>) để mô hình biết đâu là chỉ dẫn, đâu là dữ liệu cần xử lý. Điều này cũng giảm rủi ro người dùng "tiêm" lệnh vào.
Bước 4 — Chỉ định format đầu ra thật chặt. Nếu output sẽ được máy xử lý, hãy yêu cầu JSON và mô tả từng trường. Nếu cho người đọc, hãy nêu rõ độ dài, giọng văn, có hay không dùng gạch đầu dòng.
Bước 5 — Thêm hành vi dự phòng. Luôn chỉ rõ mô hình phải làm gì khi thiếu thông tin hoặc gặp câu hỏi ngoài phạm vi. Đây là tấm lưới an toàn quan trọng nhất.
Bước 6 — Kiểm thử với các trường hợp khó (edge case). Đừng chỉ thử input "đẹp". Hãy thử input trống, input mơ hồ, input cố tình gây nhiễu. Một prompt chỉ tốt khi nó bền trước input xấu.
Bước 7 — Lặp và phiên bản hóa. Sửa một yếu tố mỗi lần, ghi lại thay đổi và kết quả. Coi prompt như code: cần được lưu version, review và kiểm thử, không phải sửa tùy hứng trong production.
Lỗi thường gặp & mẹo
Lỗi 1: Prompt mơ hồ rồi trách mô hình "ngu". Phần lớn kết quả tệ đến từ đề bài tệ. Trước khi kết luận mô hình không làm được, hãy hỏi: liệu một người mới vào nghề đọc đúng prompt này có làm đúng không?
Lỗi 2: Nhồi quá nhiều nhiệm vụ vào một prompt. Yêu cầu mô hình vừa dịch, vừa tóm tắt, vừa phân loại, vừa chấm điểm trong một lượt thường cho kết quả kém ở mọi mặt. Hãy tách thành các bước riêng khi có thể.
Lỗi 3: Quên hành vi khi "không biết". Mô hình mặc định thích trả lời hơn là từ chối. Nếu bạn không ra lệnh "hãy nói không biết khi thiếu dữ liệu", nó sẽ bịa.
Lỗi 4: Dùng phủ định mơ hồ. "Đừng viết dài" yếu hơn nhiều so với "viết tối đa 3 câu". Hãy ưu tiên chỉ dẫn khẳng định, định lượng được.
Mẹo 1: Đặt chỉ dẫn quan trọng nhất ở đầu và nhắc lại ở cuối với prompt dài, vì mô hình chú ý mạnh hơn ở hai đầu.
Mẹo 2: Cho mô hình "lý do" để cẩn thận. Câu như "Đây là tư vấn pháp lý, sai sót có thể gây hậu quả nghiêm trọng" giúp mô hình thận trọng hơn.
Mẹo 3: Xây một bộ test prompt. Giữ 10–20 input đại diện và chạy lại mỗi khi sửa prompt, để biết thay đổi của mình cải thiện hay phá vỡ những gì đang chạy tốt.
Bài tập thực hành
- Giải phẫu một prompt tệ. Lấy prompt: "Tóm tắt cái này giúp tôi." Hãy chỉ ra nó thiếu thành phần nào trong 5 khối, rồi viết lại thành một prompt hoàn chỉnh để tóm tắt một bài báo cho bản tin nội bộ công ty (xác định rõ độ dài, đối tượng đọc, định dạng).
- Viết prompt phân loại có format chặt. Thiết kế một prompt phân loại email hỗ trợ khách hàng thành 4 nhãn (KHIEU_NAI, HOI_DAP, GOP_Y, KHAC), trả về JSON, có trường mức độ ưu tiên và hành vi dự phòng cho email không rõ nội dung.
- Thêm lưới an toàn. Viết phần Constraints cho một chatbot tư vấn sản phẩm mỹ phẩm, đảm bảo nó không đưa ra lời khuyên y khoa và biết từ chối khi được hỏi ngoài phạm vi.
- Thử nghiệm one-shot. Chọn một tác vụ viết (ví dụ caption Facebook cho cửa hàng), chạy thử có và không có ví dụ mẫu, rồi so sánh sự khác biệt về chất lượng đầu ra.
Tóm tắt
Prompt engineering là kỹ năng nền tảng của AI Product Manager vì trong nhiều sản phẩm AI hiện nay, prompt chính là phần logic nghiệp vụ cốt lõi và là "vô lăng" để lái hành vi mô hình. Một prompt tốt được dựng từ năm thành phần: Role (vai trò), Task (nhiệm vụ), Context (ngữ cảnh), Format (định dạng đầu ra) và Constraints (ràng buộc). Trong đó, Format và Constraints thường là yếu tố quyết định một đầu ra có dùng được trong sản phẩm thật hay không. Nguyên tắc xuyên suốt là cụ thể đánh bại thông minh: chỉ dẫn càng rõ ràng, định lượng được, càng cho kết quả ổn định. Hãy luôn chỉ định hành vi dự phòng khi mô hình không biết, tách bạch chỉ dẫn với dữ liệu, và đối xử với prompt như code — cần phiên bản hóa và kiểm thử. Nắm vững nền tảng này, bạn đã sẵn sàng bước sang các pattern nâng cao ở Bài 15.