Bốn thành phần và công thức RTF
Đã hiểu vì sao cần nói rõ, giờ ta cần một bộ khung để biết nói rõ những gì. Khung đầu tiên, đơn giản và dùng được ngay, là bốn thành phần cơ bản (basic components). Một prompt đầy đủ thường gồm bốn phần, không nhất thiết đủ cả bốn trong mọi tình huống, nhưng càng đủ thì kết quả càng đáng tin.
Hãy bắt đầu từ một cảnh quen thuộc. Đêm trước hạn nộp, bạn gõ vào ô chat: "làm đồ án quản lý thư viện". Mô hình trả về một dàn ý chung chung, không ngôn ngữ nào cụ thể, không biết bạn đang mắc ở đâu. Sau hai mươi phút bạn kết luận "AI cũng thường thôi" rồi tự làm. Chẩn đoán rất đơn giản: mô hình không dở, lời nhắc mới dở. Bạn đưa cho nó bốn chữ và chờ nó biết bạn học môn gì, dùng ngôn ngữ nào, thầy yêu cầu ra sao. Bài này cho bạn một bộ khung để chuyển cái nằm trong đầu thành chữ trên màn hình, một cách có hệ thống.
Thử ngay: prompt yếu và prompt mạnh cho cùng một việc
Trước khi vào bộ khung, hãy nhìn khoảng cách nó tạo ra trên một tình huống cụ thể: nhờ AI giải thích con trỏ trong C. Đây là chỗ sinh viên hay bí, và cũng là chỗ một prompt cẩu thả cho kết quả vô dụng. Bấm từng nút bên dưới để thấy prompt mạnh đã nói rõ thêm những gì mà prompt yếu để mô hình phải đoán.
giải thích con trỏ
# role
Bạn là trợ giảng môn Lập trình C, giảng cho sinh viên năm nhất
lần đầu gặp khái niệm con trỏ. Giọng kiên nhẫn, tránh thuật ngữ
tiếng Anh nâng cao; nếu buộc phải dùng thì giải thích ngay.
# task
Giải thích con trỏ trong C: nó lưu cái gì, vì sao cần nó, và sự
khác nhau giữa biến thường với con trỏ tới biến đó. Dùng phép so
sánh "địa chỉ nhà" để minh hoạ.
# format
Trả về theo thứ tự:
1) một đoạn 3 đến 4 câu giải thích ý chính;
2) một sơ đồ bộ nhớ đơn giản bằng chữ (ô nhớ + địa chỉ + giá trị);
3) một đoạn code C khoảng 8 dòng, chú thích trong code bằng tiếng Anh;
4) một lỗi thường gặp của người mới và cách tránh.Cùng một mô hình, cùng chủ đề, nhưng lời nhắc thứ hai khoá chặt vai trò, trình độ người đọc, phép so sánh cụ thể và cấu trúc đầu ra. Kết quả gần như chắc chắn dùng được ngay, không phải hỏi đi hỏi lại.
Bạn để ý: prompt mạnh không hề "thông minh" hơn, nó chỉ nói rõ hơn. Toàn bộ phần thêm vào đều là những điều bạn vốn đã ngầm mong đợi; điểm khác biệt là bạn đã viết chúng ra thay vì bắt mô hình đoán.
Bốn thành phần cơ bản
- Chỉ dẫn (instruction): việc bạn muốn mô hình làm. Đây là phần bắt buộc.
- Ngữ cảnh (context): thông tin nền giúp mô hình trả lời đúng tình huống của bạn (bạn là ai, dùng để làm gì, ràng buộc gì).
- Dữ liệu vào (input data): đối tượng cụ thể cần xử lý (đoạn code, thông báo lỗi, văn bản cần tóm tắt).
- Chỉ báo định dạng đầu ra (output indicator): bạn muốn câu trả lời trông như thế nào (gạch đầu dòng, bảng, đoạn văn ngắn, đoạn code có chú thích).
Bốn mảnh này ghép lại thành một lời nhắc hoàn chỉnh rồi đi qua mô hình để ra kết quả. Hãy xem chúng hoạt động trên một việc rất quen thuộc: nhờ AI tóm tắt một đoạn mô tả thuật toán.
# instruction
Tóm tắt đoạn mô tả thuật toán dưới đây.
# context
Người đọc là sinh viên năm hai mới học cấu trúc dữ liệu,
chưa quen thuật ngữ tiếng Anh nâng cao.
# input data
"""
Thuật toán sắp xếp nổi bọt duyệt qua mảng nhiều lượt, mỗi lượt
so sánh từng cặp phần tử kề nhau và đổi chỗ nếu chúng sai thứ tự,
cho tới khi không còn cặp nào cần đổi.
"""
# output indicator
Trả về 3 gạch đầu dòng ngắn, mỗi dòng tối đa 20 từ,
bằng tiếng Việt đơn giản.
Bốn nhãn trong ví dụ chỉ để bạn thấy ranh giới giữa các phần. Khi đã quen, bạn không cần ghi rõ nhãn; chỉ cần đảm bảo bốn loại thông tin đó đều có mặt.
Đó là ngữ cảnh và chỉ báo định dạng.
- Thiếu ngữ cảnh: mô hình trả lời cho "người chung chung".
- Thiếu định dạng: nhận về đoạn văn dài, lại mất công cắt gọt.
Thêm hai phần này gần như luôn cải thiện kết quả.
Đi sâu từng thành phần
Chỉ dẫn hay bị viết hỏng theo một kiểu kín đáo: mơ hồ mà tưởng là đã rõ. "Về sắp xếp nổi bọt" không phải chỉ dẫn, đó là chủ đề. "Nói về sắp xếp nổi bọt" có động từ, nhưng không giới hạn gì, bạn sẽ nhận về một bài lan man. "So sánh sắp xếp nổi bọt với sắp xếp chèn theo số phép so sánh và số phép đổi chỗ, trên mảng đã gần sắp xếp" mới là chỉ dẫn: một động từ rõ, một phạm vi rõ, một điều kiện rõ. Mẹo tự kiểm: đọc lại và hỏi "có bao nhiêu cách hiểu?". Nếu nhiều hơn một, hãy chốt lại.
Ngữ cảnh trả lời câu hỏi "việc này làm cho ai". Cùng yêu cầu "giải thích đệ quy", câu trả lời phải rất khác nhau tùy bạn là sinh viên năm nhất chưa biết ngăn xếp hay bạn đang ôn phỏng vấn. Mô hình không đoán được bạn thuộc nhóm nào nên nó rơi vào mức trung bình, tức là không hợp với ai cả. Ngữ cảnh nên gồm trình độ, mục đích, ràng buộc bắt buộc (đề cấm đệ quy, chỉ được dùng thư viện chuẩn), và cái bạn đã thử mà thất bại.
Dữ liệu vào là phần hay bị bỏ nhất: sinh viên tả lỗi bằng lời ("hàm của em chạy sai") thay vì dán hàm và thông báo lỗi. Khi dán, hãy rào dữ liệu bằng ranh giới rõ để mô hình không nhầm nội dung dữ liệu thành mệnh lệnh.
Chỉ báo định dạng rẻ nhất để viết mà tiết kiệm nhiều công nhất. Một dòng "trả về bảng ba cột: tên hàm, việc nó làm, độ phức tạp" giúp bạn khỏi ngồi cắt gọt một đoạn văn dài. Nên nêu cả hình thức, độ dài lẫn ngôn ngữ, vì cả ba đều là chỗ mô hình hay tự quyết.
- Việc nhanh, quen thuộc, tự kiểm được ngay (đổi định dạng, sửa chính tả): chỉ dẫn là đủ.
- Việc có một đối tượng cụ thể (gỡ lỗi, tóm tắt, viết lại): bắt buộc thêm dữ liệu vào.
- Việc mà đúng sai phụ thuộc người đọc hoặc ràng buộc môn học: bắt buộc thêm ngữ cảnh.
- Kết quả dán thẳng vào báo cáo, slide hoặc code: bắt buộc thêm chỉ báo định dạng.
Thiếu thành phần nào thì hỏng theo kiểu nào
Biết bốn thành phần là một chuyện, nhận ra mình đang thiếu cái nào lại là chuyện khác. May là mỗi thành phần khi vắng mặt đều để lại một dấu vết riêng.
Thiếu chỉ dẫn thì câu trả lời lan man theo chủ đề. Bạn gõ "vòng lặp trong C" và nhận về một bài tổng quan có đủ mọi thứ trừ cái bạn cần: đọc xong thấy đúng hết mà chẳng dùng được gì. Bạn đưa một chủ đề chứ không đưa một việc, nên mô hình tự chọn việc, và nó chọn cái phổ biến nhất.
Thiếu ngữ cảnh thì câu trả lời đúng nhưng lệch người đọc và lệch ràng buộc: mô hình dùng thuật ngữ bạn chưa học, gợi ý thư viện mà đề bài cấm, hoặc bày lại đúng cách bạn vừa thử và đã thất bại. Đây là loại thiếu tốn thời gian nhất, vì phải đọc hết rồi mới biết không dùng được.
Thiếu dữ liệu vào thì mô hình phải đoán đối tượng. Dấu vết dễ nhận nhất là câu phòng thủ kiểu "nếu code của bạn có dạng như sau", theo sau là một đoạn code nó tự nghĩ ra rồi phân tích chính đoạn ấy. Nó đang gỡ lỗi một chương trình tưởng tượng.
Thiếu chỉ báo định dạng thì bạn nhận đúng nội dung nhưng sai bao bì: một đoạn văn dài có mở bài kết bài, trong khi bạn chỉ cần ba dòng dán thẳng vào slide. Thiệt hại nằm ở công cắt gọt, mà công đó phải trả lại mỗi lần dùng.
Bốn dấu vết này biến việc sửa prompt từ mò mẫm thành có phương pháp: đọc câu trả lời hỏng, nhận dạng dấu vết, bổ sung đúng thành phần đang thiếu, chạy lại.
Thứ tự đặt các thành phần
Không có luật cứng, nhưng một thứ tự chạy tốt trong đa số trường hợp là: vai trò và ngữ cảnh trước, chỉ dẫn kế tiếp, dữ liệu vào ở giữa, chỉ báo định dạng ở cuối.
Lý do nằm ở cách mô hình sinh chữ. Nó đọc toàn bộ lời nhắc rồi mới viết, và những gì đặt ở đầu khoá giọng cho mọi thứ đọc sau đó: đặt "bạn đang giảng cho sinh viên năm nhất" ở dòng đầu thì cả phần dữ liệu phía dưới cũng được đọc dưới lăng kính ấy. Ngược lại, chỉ báo định dạng nên nằm sát cuối vì đó là thứ cuối cùng mô hình đọc trước khi viết, nên ít bị bỏ sót nhất.
Với lời nhắc dài, hãy rào dữ liệu vào bằng ranh giới rõ ràng, chẳng hạn ba dấu nháy, và nói rõ đó là dữ liệu chứ không phải mệnh lệnh: nếu đoạn bạn dán tình cờ có câu mệnh lệnh, mô hình rất dễ hiểu nhầm đó là yêu cầu của bạn. Với lời nhắc rất dài, nhắc lại yêu cầu then chốt ngay sau khối dữ liệu, vì một dòng nhắc lại rẻ hơn nhiều so với một lượt hỏi lại.
Công thức RTF: vai trò, nhiệm vụ, định dạng
Bốn thành phần là khung đầy đủ nhưng đôi khi hơi dài cho những việc nhanh. Có một công thức gọn hơn, dễ nhớ hơn, rất hợp để bắt đầu: công thức RTF, viết tắt của ba từ tiếng Anh Role, Task, Format.
- Vai trò (Role): bảo mô hình "đóng vai" ai. Ví dụ: một giảng viên lập trình kiên nhẫn, một người rà soát code khó tính.
- Nhiệm vụ (Task): nói rõ việc cần làm và làm cho ai, kèm ràng buộc nếu có.
- Định dạng (Format): nêu hình thức đầu ra mong muốn.
Vì sao gán vai trò lại hữu ích? Nhớ lại trò đoán chữ tiếp theo. Khi bạn mở đầu bằng "Bạn là một giảng viên lập trình kiên nhẫn", bạn đang kéo mô hình về vùng văn bản mang giọng giảng dạy, chậm rãi, có ví dụ. Vai trò không phải phép thuật; nó là một cách ngắn gọn để đặt giọng và mức độ chi tiết cho toàn bộ câu trả lời.
RTF và bốn thành phần không mâu thuẫn nhau. RTF là một cách sắp gọn: "vai trò" gói phần lớn ngữ cảnh, "nhiệm vụ" chính là chỉ dẫn cộng dữ liệu vào, "định dạng" chính là chỉ báo đầu ra. Bạn dùng RTF cho yêu cầu nhanh, dùng bốn thành phần khi việc phức tạp và cần tách bạch dữ liệu.
Ví dụ thứ hai: nhờ AI gỡ một lỗi
Ví dụ con trỏ ở trên là việc giải thích. Hãy thử việc bạn làm nhiều nhất: gỡ lỗi. Đa số sinh viên gửi đi một lời nhắc kiểu "code em bị lỗi, xem giúp với", trong khi mô hình không có code, không có lỗi, không biết ngôn ngữ. Đây là bản đủ bốn thành phần.
# chỉ dẫn
Tìm nguyên nhân khiến hàm dưới đây lặp vô hạn và chỉ ra dòng gây lỗi.
Đừng viết lại cả chương trình.
# ngữ cảnh
Tôi là sinh viên năm nhất, môn Lập trình C, đề bài cấm dùng thư viện
ngoài. Tôi đã thử đổi điều kiện while thành i <= n nhưng vẫn treo.
# dữ liệu vào
"""
int tong(int n) {
int i = 1, s = 0;
while (i <= n) {
s += i;
}
return s;
}
"""
# định dạng
Trả về đúng ba phần:
1) một câu nêu nguyên nhân;
2) dòng code cần sửa và bản sửa;
3) một mẹo để lần sau tự phát hiện loại lỗi này.
Mỗi thành phần mua về cho bạn một thứ. Chỉ dẫn "đừng viết lại cả chương trình" chặn thói quen quăng ra một bản code mới toanh mà bạn không hiểu. Ngữ cảnh "đề cấm thư viện ngoài" chặn những gợi ý bạn không được phép dùng, còn "tôi đã thử đổi điều kiện while" chặn việc mô hình gợi ý lại đúng cái bạn vừa thử. Dữ liệu vào cho nó thứ duy nhất có thể phân tích.
Điểm mấu chốt: bản mạnh không dài hơn vì màu mè. Mỗi câu thêm vào đều loại bỏ một cách hiểu sai. Viết prompt tốt về bản chất là thu hẹp không gian câu trả lời cho tới khi chỉ còn lại thứ bạn thật sự cần.
Nói cái muốn, đừng chỉ nói cái không muốn
Có một chi tiết nhỏ nhưng đổi kết quả rất nhiều: ràng buộc phủ định thường yếu hơn ràng buộc khẳng định. Câu "đừng viết dài dòng" hoạt động kém hơn hẳn câu "viết tối đa năm câu"; "đừng dùng thuật ngữ khó" kém hơn "chỉ dùng từ mà sinh viên năm nhất đã học".
Vì sao? Mô hình sinh chữ bằng cách nối tiếp những gì đang có, mà một câu cấm vẫn phải nêu ra chính cái bị cấm. Khi bạn viết "đừng nhắc tới đệ quy", chữ "đệ quy" nằm chình ình trong ngữ cảnh và kéo mô hình về đúng vùng văn bản nói về đệ quy. Câu cấm chỉ ra vùng cần tránh nhưng không chỉ cho mô hình biết đi đâu, trong khi nó bắt buộc phải đi đâu đó. Ràng buộc khẳng định vừa loại bỏ cái sai vừa chỉ luôn cái đúng.
Vậy nên hãy tập phản xạ dịch: mỗi khi định viết một câu cấm, hỏi "nếu không làm thế thì làm gì?" rồi viết câu trả lời đó ra. "Đừng viết code dài" dịch thành "chỉ đưa phần cần sửa, tối đa mười dòng". Câu cấm không vô dụng, và vài câu rất đáng giữ, chẳng hạn "không suy đoán thông tin ngoài tài liệu tôi cung cấp", nhưng nó nên là lớp rào bổ sung chứ không phải toàn bộ mô tả thứ bạn muốn.
Cho ví dụ mẫu: cách nâng chất lượng nhanh nhất
Khi yêu cầu khó tả bằng lời, có một cách rất mạnh: đưa vài ví dụ mẫu. Kỹ thuật này tiếng Anh gọi là few-shot, tức cho mô hình xem một vài cặp đầu vào và đầu ra mong muốn trước khi giao việc thật.
Chuyển mỗi dòng nhật ký lỗi thành một dòng tóm tắt cho báo cáo.
Làm theo đúng mẫu dưới đây.
Ví dụ 1
Vào: segmentation fault tại dòng 42 khi mảng rỗng
Ra: Truy cập mảng rỗng, cần kiểm tra kích thước trước khi đọc.
Ví dụ 2
Vào: vòng lặp while không bao giờ thoát khi n âm
Ra: Điều kiện dừng sai với n âm, cần chặn đầu vào âm.
Bây giờ xử lý dòng sau:
Vào: chia cho biến d chưa được gán giá trị
Ra:
Vì sao cách này hiệu quả? Vì mô hình đang chơi trò nối tiếp văn bản: khi ngữ cảnh đã có hai cặp theo đúng một khuôn, tiếp nối tự nhiên nhất của cặp thứ ba là một dòng cùng khuôn ấy, cùng độ dài, cùng giọng, cùng cách mở đầu. Bạn đã dùng chính cơ chế đoán chữ để ép định dạng.
Ví dụ mẫu tốn token nên đừng lạm dụng cho việc đơn giản; hai tới ba ví dụ thường là đủ.
Điều tối kỵ là các ví dụ không nhất quán với nhau: nếu ví dụ một dài một dòng còn ví dụ
hai dài năm dòng, bạn vừa dạy mô hình rằng độ dài không quan trọng, và nó sẽ tự do chọn.
Nêu tiêu chí thành công
Còn một thứ ít người dùng mà lợi ích rất lớn: nói cho mô hình biết thế nào là làm xong tốt. Đây không phải định dạng, cũng không phải chỉ dẫn, mà là thước đo để tự chấm.
Một yêu cầu tóm tắt có thể dừng ở "tóm tắt bài này thành ba gạch đầu dòng", hoặc thêm một dòng: "bản tóm tắt được coi là đạt nếu người chưa đọc bài gốc vẫn nêu được vấn đề, cách giải quyết và kết quả". Bản thứ hai cho mô hình một đích để nhắm, và nó sẽ tự loại những gạch đầu dòng chỉ nhắc lại tiêu đề. Với việc viết code, tiêu chí có thể là "chạy đúng với mảng rỗng và mảng một phần tử".
Mẹo thực dụng: tiêu chí thành công chính là cách bạn sẽ kiểm tra kết quả. Viết ra được thì dán luôn vào prompt; không viết ra được thì đó là dấu hiệu chính bạn cũng chưa rõ mình muốn gì, và không lời nhắc nào cứu được điều đó.
- Nhồi vai trò cho oai. "Chuyên gia hàng đầu thế giới với ba mươi năm kinh nghiệm" không làm mô hình giỏi hơn. Vai trò chỉ có tác dụng khi nó khoá được giọng văn và mức độ chi tiết.
- Tả dữ liệu thay vì dán dữ liệu. "Code em đại khái là một vòng lặp cộng dồn" là vô dụng. Hãy dán code thật và nguyên văn thông báo lỗi.
- Ràng buộc mâu thuẫn. "Giải thích thật sâu" đi cùng "tối đa ba dòng" thì mô hình buộc phải hy sinh một trong hai, và nó sẽ chọn thay bạn.
- Định dạng mơ hồ. "Trả lời ngắn gọn" là mơ hồ. "Tối đa năm gạch đầu dòng" là rõ.
Tư duy nền: giao việc rõ như cho người mới
Tất cả những gì ở trên quy về một thói quen tư duy duy nhất. Nếu chỉ mang theo một điều khỏi buổi học này, hãy mang theo điều này: viết prompt như giao việc cho người mới vào nhóm, rất giỏi nhưng không biết bối cảnh riêng của bạn và không hỏi lại. Cái gì bạn không nói rõ, người đó sẽ tự đoán, mà đoán thì dễ sai.
Tư duy này dẫn tới ba câu hỏi tự kiểm bạn nên đặt ra mỗi khi viết prompt:
- Một người lạ đọc đúng lời nhắc này (không biết gì thêm về tôi) có làm đúng việc tôi cần không?
- Tôi đã đưa hết dữ liệu cần thiết vào lời nhắc chưa, hay còn để mô hình phải đoán?
- Tôi đã nói rõ muốn câu trả lời trông như thế nào chưa?
Bài tập nhỏ
Bài tập: thiếu thành phần nào?
Với mỗi lời nhắc dưới đây, hãy chỉ ra thành phần còn thiếu và hậu quả. (a) "Tóm tắt bài báo này thành ba gạch đầu dòng cho sinh viên năm nhất." (b) "Bạn là chuyên gia bảo mật. Đoạn code sau có lỗ hổng gì?" kèm code dán vào. (c) "Giải thích cây nhị phân tìm kiếm cho sinh viên năm hai, có ví dụ."
Lời giải. (a) Thiếu dữ liệu vào: người viết nói "bài báo này" nhưng không dán bài báo, mô hình sẽ hỏi lại hoặc bịa ra một bài. (b) Thiếu chỉ báo định dạng: bạn sẽ nhận về một bài phân tích dài lê thê; nên yêu cầu một bảng gồm lỗ hổng, dòng code, mức nghiêm trọng, cách sửa. (c) Thiếu chỉ báo định dạng và một phần ngữ cảnh: không rõ giải thích để thi hay để hiểu, dài bao nhiêu, có cần code hay không.
Bài tập: dịch câu cấm thành câu khẳng định
Một bạn viết lời nhắc sau để nhờ AI ôn tập: "Giải thích cây nhị phân tìm kiếm. Đừng viết dài dòng. Đừng dùng thuật ngữ khó. Đừng đưa code phức tạp. Đừng lan man sang cây cân bằng." Nhiệm vụ: chỉ ra vấn đề của lối viết này, rồi viết lại thành một lời nhắc dùng ràng buộc khẳng định, có đủ bốn thành phần và có tiêu chí thành công.
Lời giải. Vấn đề: cả bốn câu đều là ràng buộc phủ định, nêu ra bốn vùng cần tránh mà không chỉ cho mô hình biết phải đi đâu; tệ hơn, cụm "cây cân bằng" nằm ngay trong ngữ cảnh nên vẫn kéo mô hình về phía chủ đề đó. Lời nhắc cũng thiếu ngữ cảnh người đọc và thiếu chỉ báo định dạng; "dài dòng" và "thuật ngữ khó" đều không đo được. Bản viết lại, dịch từng câu cấm thành một yêu cầu khẳng định:
# vai trò và ngữ cảnh
Bạn là trợ giảng môn Cấu trúc dữ liệu. Người đọc là sinh viên năm
hai đã biết mảng và con trỏ, chưa học cây cân bằng.
# nhiệm vụ
Giải thích cây nhị phân tìm kiếm: quy tắc sắp xếp các nút, và cách
tìm một khoá. Chỉ nói về cây nhị phân tìm kiếm cơ bản.
# định dạng
Tối đa tám câu, cộng một sơ đồ cây bằng chữ có bảy nút, cộng một hàm
tìm kiếm trong C tối đa mười dòng, chú thích trong code bằng tiếng Anh.
Mọi thuật ngữ tiếng Anh dùng lần đầu phải kèm giải thích trong ngoặc.
# tiêu chí thành công
Đạt nếu một bạn chưa từng học cây vẫn nói được vì sao tìm kiếm trên
cây này nhanh hơn duyệt mảng tuần tự.
Chú ý cách dịch: "đừng dài dòng" thành "tối đa tám câu"; "đừng thuật ngữ khó" thành "thuật ngữ dùng lần đầu phải kèm giải thích"; "đừng code phức tạp" thành "hàm tối đa mười dòng"; "đừng lan man sang cây cân bằng" thành "chỉ nói về cây nhị phân tìm kiếm cơ bản", đồng thời đưa việc chưa học cây cân bằng vào phần ngữ cảnh cho đúng chỗ. Mỗi câu mơ hồ đã thành một con số hoặc một mệnh lệnh kiểm được.
Câu hỏi tự kiểm
- 1Vì sao "viết tối đa năm câu" thường hiệu quả hơn "đừng viết dài dòng"?
- 2Câu trả lời có dấu vết "nếu code của bạn có dạng như sau" rồi tự bịa ra một đoạn code để phân tích là dấu hiệu thiếu thành phần nào?
- 3Gán vai trò (Role) cho mô hình có tác dụng gì?
- 4Tiêu chí thành công trong prompt là gì?
Tóm tắt
Cả bài chỉ nói một điều: mô hình không đọc được ý bạn, nó chỉ đọc được chữ bạn gõ, nên chất lượng câu trả lời bị chặn trên bởi lượng thông tin bạn chịu viết ra. Bốn thành phần là danh sách kiểm để không bỏ sót, RTF là bản rút gọn cho việc nhanh. Trên nền đó là ba kỹ thuật rẻ mà nâng chất lượng rõ rệt: xếp vai trò và ngữ cảnh lên đầu, dữ liệu vào ở giữa có rào ngăn cách, định dạng xuống cuối; dịch mọi câu cấm thành câu khẳng định đo được; và khi việc khó tả bằng lời thì đưa hai tới ba ví dụ mẫu nhất quán. Cuối cùng, thêm một dòng tiêu chí thành công, nó vừa cho mô hình đích để nhắm vừa buộc chính bạn làm rõ mình đang muốn gì.
- Bốn thành phần: chỉ dẫn + ngữ cảnh + dữ liệu vào + chỉ báo định dạng. Chỉ dẫn là bắt buộc; hai phần hay bị quên nhất là ngữ cảnh và định dạng.
- RTF (vai trò, nhiệm vụ, định dạng) là bản gọn cho việc nhanh; dùng bốn thành phần khi việc phức tạp và có dữ liệu cần tách bạch.
- Vai trò không phải phép thuật, nó chỉ khoá giọng văn và mức độ chi tiết.
- Ràng buộc khẳng định mạnh hơn ràng buộc phủ định: nói cái muốn, đừng chỉ nói cái không muốn.
- Việc khó tả bằng lời thì đưa hai tới ba ví dụ mẫu nhất quán, và thêm một dòng tiêu chí thành công để mô hình có đích nhắm.
- Mỗi câu thêm vào prompt nên loại bỏ một cách hiểu sai. Nếu không, nó là chữ thừa.