Viết prompt - chỉ dẫn rõ, ví dụ mẫu, đặt đúng chỗ, ràng buộc đầu ra, sửa có đo

Prompt là phần dễ sửa nhất của một ứng dụng dùng Claude, nên cũng dễ bị sửa lung tung nhất: mỗi người thêm một dòng, chỉ dẫn rải khắp system prompt và tin nhắn, sửa xong không ai đo xem tốt hơn hay tệ đi.

Bài này giúp bạn trả lời: viết prompt thế nào cho Claude hiểu đúng, đặt chỉ dẫn ở đâu, và sửa prompt ra sao để chắc chắn là tốt lên?

Ví dụ xuyên suốt: trợ lý soạn kịch bản tiệc cưới

Một công ty tổ chức tiệc cưới dùng Claude soạn bản đề xuất kịch bản tiệc từ phiếu thông tin của cô dâu chú rể: số khách, phong cách, tiết mục mong muốn, ngân sách. Sau một năm:

• System prompt đã dài khoảng 350 dòng, có chỗ chồng chéo và mâu thuẫn: dòng 40 bảo "trả lời ngắn gọn", dòng 210 bảo "mô tả chi tiết từng tiết mục".
• Một số chỉ dẫn định dạng nằm trong system prompt, một số khác được code chèn vào tin nhắn user, có cái lặp lại hai lần.
• Đề xuất cho tiệc cưới kết hợp hai văn hoá (số lượng tăng gấp ba năm nay) thường thiếu nghi lễ của một bên.
• Đội có sẵn 6 bản đề xuất mẫu được trưởng phòng chấm đạt.

Chỉ dẫn rõ ràng, có lý do

Docs prompting best practices khuyên coi Claude như một nhân viên mới rất giỏi nhưng chưa biết quy ước của bạn. Phép thử: đưa prompt cho một đồng nghiệp không biết gì về việc này; nếu họ bối rối thì Claude cũng sẽ bối rối. Đề thi gọi đây là độ rõ của chỉ dẫn (instruction clarity). Cụ thể:

• Nói rõ định dạng và ràng buộc của đầu ra.
• Khi thứ tự hay sự đầy đủ của các bước quan trọng, viết thành danh sách đánh số.
• Kèm lý do: giải thích vì sao một hành vi quan trọng giúp Claude hiểu mục tiêu và làm đúng hơn.
• Nói điều cần làm thay vì điều không được làm: thay "đừng dùng gạch đầu dòng" bằng "viết thành các đoạn văn liền mạch".

Soạn đề xuất kịch bản tiệc theo đúng thứ tự:
1. Đón khách và nghi lễ của từng bên gia đình
2. Tiết mục chính, mỗi tiết mục ghi rõ thời lượng
3. Tổng thời gian, không vượt quá giờ thuê sảnh
Lý do: sảnh tính phí theo giờ, quá giờ là phát sinh chi phí cho khách.

Đặt chỉ dẫn đúng chỗ

Đề thi hỏi về đặt chỉ dẫn ở system hay user (system versus user placement). Quy tắc gọn:

Chỉ dẫn rải rác và lặp lại chính là lý do định dạng đầu ra không đều trong ví dụ. Gom mọi chỉ dẫn hành vi và định dạng về system prompt, để lượt user chỉ chứa phiếu thông tin.

Ví dụ mẫu: zero-shot hay few-shot

Prompt không có ví dụ là zero-shot; có vài ví dụ là few-shot (multi-shot). Docs nói ví dụ là một trong những cách chắc nhất để điều khiển định dạng, giọng và cấu trúc, và khuyên 3–5 ví dụ:

• Sát việc thật: giống đầu vào sẽ gặp.
• Đa dạng: phủ cả trường hợp khó, đủ khác nhau để Claude không bắt chước nét không cố ý.
• Có cấu trúc: bọc trong <example>, nhiều ví dụ thì trong <examples>.

Trong ví dụ, đội chọn 4 trong 6 bản đề xuất mẫu, cố ý lấy 2 bản tiệc hai văn hoá, vì đó đúng là chỗ đang yếu.

Ràng buộc định dạng đầu ra

Đề thi gọi đây là ràng buộc đầu ra (output constraints). Docs nêu vài cách hiệu quả:

• Mô tả rõ schema bắt buộc và yêu cầu chỉ trả đúng schema đó.
• Dùng thẻ XML làm chỉ báo định dạng, ví dụ yêu cầu viết phần tóm tắt trong <tom_tat>.
• Viết prompt theo đúng phong cách muốn nhận lại: prompt toàn gạch đầu dòng thì dễ nhận lại gạch đầu dòng.

Một kỹ thuật cũ đã không còn dùng được: điền sẵn phần đầu câu trả lời của assistant (prefill), ví dụ điền { để ép JSON. Từ các model Claude 4.6, yêu cầu có prefill ở lượt assistant cuối bị lỗi 400. Docs khuyên dùng structured outputs nếu cần đúng schema, hoặc chỉ dẫn trong system prompt.

Làm sạch đầu vào

Đề thi nhắc làm sạch đầu vào (input sanitization). Docs về chống jailbreak gợi ý hai lớp trước khi đầu vào tới cuộc hội thoại chính:

• Sàng lọc bằng model nhẹ: một lần gọi Haiku 5.5 kiểm đầu vào có hại hay có dấu hiệu lách luật không, trả kết quả dạng có cấu trúc để code đọc.
• Kiểm đầu vào: lọc các mẫu tấn công đã biết.

Nội dung không do người dùng viết (email, trang web, file) thì đi vào tool_result và mã hoá JSON (bài 2.5, bài 7.1).

Sửa prompt có đo, từng thay đổi một

Trang tổng quan prompt engineering nói trước khi chỉnh prompt cần ba thứ: tiêu chí thành công rõ ràng, cách kiểm thực nghiệm theo tiêu chí đó, và một bản prompt nháp. Bản đầu tiên chỉ là bản nháp. Cách sửa:

1. Lấy các ca đang hỏng từ eval (trong ví dụ: tiệc hai văn hoá).
2. Đổi một thứ mỗi lần: thêm ví dụ, thêm một bước, làm rõ một câu.
3. Chạy lại eval trên cả ca hỏng lẫn ca thông thường, để sửa chỗ này không làm hỏng chỗ khác.

Với system prompt 350 dòng của ví dụ, việc đầu tiên là dọn: tìm chỗ chồng chéo, mâu thuẫn, lỗi thời, rồi viết lại để mỗi chỉ dẫn rõ, còn hiệu lực, không trùng. Docs về CLAUDE.md có một nhận xét cũng đúng ở đây: hai chỉ dẫn mâu thuẫn thì Claude có thể chọn một cái tuỳ ý, chứ không chắc theo cái mới hơn.