Một đồng đội nhờ bạn giúp giữa buổi chiều bận rộn: "Xem giúp cái này được không?" Bạn mở file, nhưng không có context. Bạn không biết code đáng lẽ làm gì, cái gì vừa đổi, lỗi gì xảy ra, đã thử gì rồi, hay họ muốn một ý kiến nhanh hay review kỹ. Dù có kinh nghiệm, bạn cũng phải hỏi thêm hoặc đoán. AI model trong khoảnh khắc đó không khác nhiều.
Prompt engineering nghe đôi khi như một nghề bí mật, đầy công thức và câu chữ thông minh. Một vài pattern đúng là hữu ích. Nhưng kỹ năng sâu hơn bình thường hơn nhiều: giao tiếp đủ rõ để một trí thông minh khác, là người hay máy, có thể làm việc hữu ích mà không phải tự bịa phần tình huống bị thiếu.
Một prompt tốt bắt đầu bằng context. Hệ thống là gì? Người đọc là ai? Chuyện gì đã xảy ra? Ràng buộc nào quan trọng nhất? Khi bỏ qua phần này, ta không thật sự tiết kiệm thời gian. Ta chỉ chuyển chi phí sang câu trả lời tiếp theo. Model phải lấp khoảng trống bằng giả định chung chung, và giả định chung chung là nơi nhiều câu trả lời thất vọng bắt đầu.
Prompt tốt cũng gọi tên nhiệm vụ. "Cải thiện cái này" là một mong muốn. "Viết lại summary này cho product manager không chuyên kỹ thuật, dưới 120 từ, giữ rủi ro và bỏ jargon" là công việc có thể làm. Verb, object và boundary càng rõ, càng ít năng lượng bị phí vào việc thương lượng thành công nghĩa là gì.
Ràng buộc không giới hạn sáng tạo. Nó nhắm sáng tạo đúng hướng. Không thêm dependency mới. Giữ tone bình tĩnh. Bảo toàn public API. Giải thích tradeoff trước khi code. Tránh giọng marketing. Những câu này thu hẹp không gian giải pháp để model tập trung vào câu trả lời hợp với thực tế của bạn.
Ví dụ giúp vì cùng lý do nó giúp con người. Nếu bạn cho thấy before và after, style mong muốn, failing test, hay một output nhỏ đã đúng, model có thể căn theo hình dạng bạn muốn. Đây không phải mẹo. Nó giống việc senior engineer nói: "Đây là kiểu PR description team mình thấy hữu ích."
Feedback cũng quan trọng. Nhiều người xem câu trả lời đầu tiên của AI như phán quyết tool có tốt hay không. Tốt hơn là xem nó như draft đầu trong một cuộc đối thoại. "Quá trừu tượng, làm cụ thể hơn." "Giữ cấu trúc, nhưng làm tone mềm hơn." "Câu này bỏ sót ràng buộc database." Đây không phải dấu hiệu thất bại. Đây là tín hiệu cộng tác bình thường.
Rủi ro là prompt rõ có thể làm suy nghĩ yếu nhìn có vẻ bóng bẩy. Một prompt viết đẹp không cứu được quyết định mơ hồ. Nếu mục tiêu chưa rõ, output chỉ là sự mơ hồ được viết trôi chảy. Vì vậy prompt engineering tốt nhất buộc ta chậm lại trước khi hỏi: mình thật sự cần gì, mình biết gì, cái gì không được đổi, và câu trả lời tốt sẽ giúp mình làm gì tiếp theo?
Bởi vậy mình thấy cụm "prompt engineering" vừa hữu ích vừa hơi dễ hiểu lầm. Nó không chỉ là prompt, và không chỉ là engineering. Nó là giao tiếp trong ràng buộc. Những thói quen tạo ra ticket tốt, code review tốt, design brief tốt hay handoff tốt cũng tạo ra prompt tốt: context, ý định, boundary, ví dụ và feedback.
Nếu làm việc với AI dạy mình điều gì thực tế, đó là giao tiếp mơ hồ trở nên đắt rất nhanh. Model phản chiếu độ rõ mà ta đưa vào. Trước khi tìm một câu thần chú hay hơn, ta thường có thể hỏi câu đơn giản hơn: mình cần nói gì với một đồng nghiệp tử tế để họ giúp mình tốt?
Mình muốn nghe prompt của bạn đã thay đổi thế nào khi bạn ngừng xem nó như mệnh lệnh và bắt đầu xem nó như cộng tác.