Những mẫu prompt sống sót khi gặp người dùng thật

Viết phần từ chối trước phần trả lời

Thứ đầu tiên cần quy định là mô hình phải làm gì khi không trả lời được: câu nào, bằng ngôn ngữ nào, và có nên đề xuất bước tiếp theo không. Các đội thường viết phần này sau cùng, và đó là lý do lần bịa thông tin đầu tiên trên production luôn gây bất ngờ.

Tách chỉ dẫn khỏi dữ liệu

Văn bản của người dùng không bao giờ được nối thẳng vào chỉ dẫn của bạn như thể nó là một phần của chỉ dẫn. Hãy giữ chỉ dẫn ở vai trò hệ thống và phân định rõ ràng phần nội dung người dùng. Nếu không, một khách gõ "bỏ qua phần trên" đang chạy prompt của bạn, chứ không phải bạn.

Yêu cầu cấu trúc khi có hệ thống đọc kết quả

Nếu có hệ thống phía sau phân tích đầu ra, hãy yêu cầu một hình dạng chặt chẽ và kiểm tra trước khi dùng. Xử lý trường hợp không hợp lệ một cách tường minh; thử lại kèm chính thông báo lỗi kiểm tra thường là khôi phục được. Hy vọng định dạng luôn đúng không phải là một chiến lược khi lưu lượng lớn.

Đưa ví dụ cho ca khó, không phải ca dễ

Ví dụ trong prompt là ngữ cảnh đắt tiền. Hãy tiêu chúng vào những ca mô hình làm sai: yêu cầu mơ hồ, câu hỏi ngoài phạm vi, đầu vào sai ngôn ngữ. Ví dụ dễ chẳng dạy nó điều gì mà nó chưa làm được.

Đưa prompt vào quản lý phiên bản

Prompt là logic chương trình. Nó phải được review, đánh phiên bản, và gắn với lần chạy đánh giá đã biện minh cho thay đổi đó. Prompt sửa trực tiếp trên dashboard là cách một tính năng âm thầm tụt chất lượng mà không ai nói được đã thay đổi cái gì.