Hướng dẫn viết Prompt từ OpenAI: Bí quyết tối ưu cho Chat, Công việc và Codex

Hướng dẫn viết prompt mới nhất từ OpenAI, bao gồm ba ngữ cảnh: Chat, ChatGPT Work và Codex https://learn.chatgpt.com/docs/prompting

Tác giả là @pvncher, người tạo ra @RepoPrompt, hiện cũng đang làm việc trong đội ngũ OpenAI Codex DX!

Ngay phần mở đầu, tài liệu đã đính chính một quan điểm: Prompt có cần "công thức" không? Không cần! Tài liệu đưa ra khung 4 yếu tố tùy chọn, nhưng nhấn mạnh nhiều lần rằng "chỉ sử dụng những phần hữu ích": • Mục tiêu (Goal): Muốn ChatGPT làm gì • Bối cảnh (Context): Những thông tin hoặc nguồn nào hữu ích • Đầu ra (Output): Cần định dạng, độ dài, mức độ chi tiết như thế nào • Ranh giới (Boundaries): Những gì bắt buộc phải giữ nguyên, những gì cần hỏi xác nhận trước

Sự thay đổi về phương pháp luận đằng sau điều này rất đáng chú ý: Chuyển từ "kiểm soát quy trình" sang "mô tả kết quả". Tài liệu khuyến nghị rõ ràng nên nêu kết quả bạn muốn trước, thay vì liệt kê các bước—chỉ mô tả quy trình khi bản thân quy trình đó quan trọng, còn lại hãy để mô hình tự tìm kiếm, so sánh và điều chỉnh.

Một vài nguyên tắc quan trọng dễ bị bỏ qua: 1. Ranh giới cần "ít nhưng chuẩn". Định nghĩa về ranh giới trong tài liệu rất tiết chế: chỉ viết một hoặc hai chỉ dẫn để ngăn chặn các vấn đề thực tế, ví dụ: "giữ nguyên ngày tháng và số liệu ngân sách đã được phê duyệt", "chỉ sử dụng các nguồn được cung cấp, nếu thiếu thông tin thì đánh dấu thay vì đoán", "viết dưới dạng bản nháp, không gửi đi". Không cần kiểm soát từng bước—quá nhiều ràng buộc ngược lại sẽ làm giảm hiệu quả. 2. Bối cảnh là "chắt lọc" chứ không phải "chồng chất". Chỉ đính kèm các nguồn thực sự ảnh hưởng đến kết quả và giải thích cần lấy gì từ mỗi nguồn. Khi sử dụng các nguồn dữ liệu được kết nối (Drive, Slack, v.v.), chỉ cần chỉ rõ tìm ở đâu, tìm cái gì, không cần mô tả chi tiết mỗi lần tìm kiếm. 3. Giải thích mục đích, không chỉ là định dạng. "Để cấp trên lướt nhanh trong một trang trước cuộc họp", "chuyển thành email theo dõi có người phụ trách và thời hạn"—hãy cho mô hình biết kết quả sẽ được sử dụng như thế nào, nó mới có thể chọn độ dài và cách tổ chức phù hợp. 4. Prompt đầu tiên không cần phải hoàn hảo. Hãy dùng các câu hỏi tiếp nối để điều chỉnh hướng đi, bổ sung nguồn, thay đổi độ chi tiết, không cần phải làm lại từ đầu. Cơ chế hỗ trợ là Steering (chèn vào quá trình đang chạy, thay đổi hướng ngay lập tức) và Queuing (xếp hàng cho lượt tiếp theo), trong Codex CLI tương ứng với phím Enter và Tab. 5. Với công việc quan trọng, hãy yêu cầu "tự kiểm tra + con người rà soát lại". Yêu cầu mô hình xác nhận trước khi kết thúc rằng "mỗi mục hành động đều có người phụ trách và ngày tháng", đánh dấu những thông tin không thể xác minh, sau đó bạn hãy xem lại một lần nữa.

Phân công cho ba ngữ cảnh: Chat: Hỏi đáp nhanh, viết lại, động não (brainstorming), bản nháp nhẹ nhàng. Các ví dụ đều rất ngắn—giải thích lãi suất kép, viết email từ chối khéo, so sánh gói cước điện thoại, lên kế hoạch bữa tối trong tuần. Work: Các tác vụ liên quan đến nhiều nguồn, nhiều bước, tạo ra tài liệu (như tạo bản tóm tắt và slide từ báo cáo quý, nghiên cứu quyết định mua sắm, điều phối ra mắt sản phẩm). Vì tiêu tốn hạn mức, tài liệu nhấn mạnh chiến lược hiệu quả: mỗi lần chỉ yêu cầu một kết quả có thể xem xét, phân biệt giữa cái cần thiết và cái tùy chọn, nếu phương pháp quan trọng thì hãy yêu cầu kế hoạch trước, cần bạn phê duyệt trước khi xuất bản, nếu đi chệch hướng thì kịp thời thu hẹp phạm vi. Sau khi chạy ổn định, có thể biến quy trình làm việc thành tác vụ định kỳ để tái sử dụng. Codex: Các tác vụ liên quan đến mã nguồn. Một prompt Codex tốt cần chứa bốn yếu tố—hành vi mong muốn, mã nguồn liên quan hoặc các bước tái hiện, các ràng buộc bắt buộc phải giữ, và cách xác minh.

Các điểm thực hành cho phần Codex: Đây là phần dài nhất và mang tính kỹ thuật nhất của tài liệu, đưa ra nhiều mẫu quy trình làm việc, với mô hình chung là cấu trúc ba phần "Bối cảnh + Ràng buộc + Xác minh": • Nguồn bối cảnh khác nhau: Tiện ích mở rộng IDE tự động bao gồm các tệp đang mở; CLI cần đính kèm rõ ràng bằng @đường_dẫn hoặc /mention. Đây là cơ sở quan trọng để chọn phạm vi làm việc. • Thực tiễn tốt nhất để sửa lỗi (Bug) là đưa ra các bước tái hiện có thể thực thi (hữu ích hơn nhiều so với mô tả cấp cao) + ràng buộc ("không thay đổi cấu trúc API, giảm thiểu thay đổi") + yêu cầu tái hiện trước rồi mới sửa, sửa xong chạy lại phần tái hiện và tập kiểm thử tối thiểu. • Tạo nguyên mẫu từ ảnh chụp màn hình: Hình ảnh cung cấp yêu cầu về giao diện, nhưng ngăn xếp công nghệ (tech stack), định tuyến (routing), các hành vi không nhìn thấy trên ảnh (hover, kiểm tra, tương tác bàn phím) vẫn cần mô tả bằng văn bản. • Ủy quyền tái cấu trúc lên đám mây: Ở máy cục bộ (có đầy đủ bối cảnh mã nguồn), trước tiên hãy dùng /plan để lập kế hoạch và thảo luận thay đổi, sau đó chia nhỏ thành các cột mốc để ủy quyền lên đám mây thực thi song song, xem xét từng diff. Lưu ý rằng giai đoạn agent trên đám mây mặc định không có mạng. • Lặp lại UI: Mở terminal khác để chạy dev server, dùng các prompt nhỏ và cụ thể để sửa dần; nếu bạn tự tay hoàn tác một thay đổi nào đó, hãy nói cho Codex biết để tránh bị ghi đè ở lượt tiếp theo. • Kiểm tra mã (Code review): Dùng /review tại máy cục bộ (có thể thêm chỉ dẫn tập trung), trên GitHub PR thì dùng @codex review để kích hoạt bình luận.

“eric provencher: Với 5.6 Sol, rất nhiều người vẫn đang viết prompt cho mô hình y hệt như cách họ làm với 5.5. Điều quan trọng cần lưu ý là 5.6 Sol kiên trì và kỹ lưỡng hơn rất nhiều so với...”