Bạn đã bao giờ hỏi một mô hình ngôn ngữ lớn (LLM) cách sửa lỗi, nhận về một đoạn code trông rất hợp lý, chạy thử thì hỏng ngay? Phần lớn trường hợp, vấn đề không nằm ở mô hình mà ở cách chúng ta đặt câu hỏi. Prompt engineering không phải "phép thuật" hay những câu thần chú bí ẩn, mà đơn giản là kỹ năng giao tiếp rõ ràng với một cộng sự rất giỏi nhưng hoàn toàn không biết gì về dự án của bạn. Bài viết này tổng hợp những nguyên tắc thực tế nhất, dựa trên hướng dẫn chính thức của các nhà cung cấp mô hình, để lập trình viên viết prompt hiệu quả hơn mỗi ngày.

Hãy coi mô hình như một đồng nghiệp mới

Một mẹo hữu ích là tưởng tượng bạn đang giao việc cho một kỹ sư giỏi vừa vào công ty hôm nay. Người đó thông minh nhưng không biết bạn dùng framework nào, coding convention ra sao, hay ràng buộc nghiệp vụ là gì. Nếu bạn chỉ nói "sửa hàm này giúp tôi", họ sẽ phải đoán. Mô hình cũng vậy.

Vì thế, một prompt tốt thường trả lời được các câu hỏi:

  • Bối cảnh: dự án dùng ngôn ngữ, phiên bản, thư viện nào?
  • Mục tiêu: bạn muốn đạt được điều gì, và tại sao?
  • Ràng buộc: điều gì không được thay đổi, chuẩn code nào phải tuân theo?
  • Định dạng đầu ra: chỉ cần code, cần giải thích, hay cần diff?

Năm nguyên tắc cốt lõi

1. Cụ thể thay vì chung chung

So sánh hai prompt: "Viết hàm validate email" và "Viết hàm TypeScript isValidEmail(input: string): boolean, không dùng thư viện ngoài, trả về false với chuỗi rỗng, kèm 5 test case bằng Vitest". Prompt thứ hai loại bỏ gần hết sự mơ hồ và giúp bạn nhận được kết quả có thể dùng ngay.

2. Cung cấp ví dụ (few-shot)

Khi muốn đầu ra theo một khuôn mẫu cố định, hãy đưa vào một hoặc vài ví dụ. Ví dụ đặc biệt hiệu quả khi sinh dữ liệu test, viết commit message theo chuẩn của team hay chuyển đổi định dạng dữ liệu. Lưu ý chọn ví dụ đa dạng để mô hình không bắt chước quá sát một trường hợp duy nhất.

3. Tách rõ chỉ dẫn và dữ liệu

Khi dán log, code hoặc tài liệu vào prompt, hãy bao chúng bằng dấu phân cách rõ ràng như thẻ XML hoặc khối code. Cách này giúp mô hình phân biệt đâu là yêu cầu của bạn, đâu là nội dung cần xử lý.

Hãy tìm nguyên nhân lỗi trong log dưới đây và đề xuất cách sửa.
Chỉ trả lời bằng tiếng Việt, tối đa 5 gạch đầu dòng.
 
<log>
TypeError: Cannot read properties of undefined (reading 'map')
    at ProductList (ProductList.tsx:42)
</log>

4. Cho mô hình "thời gian suy nghĩ"

Với bài toán phức tạp như thiết kế thuật toán hay debug nhiều bước, hãy yêu cầu mô hình phân tích từng bước trước khi đưa ra đáp án. Hướng dẫn của cả OpenAI và Anthropic đều nhắc đến kỹ thuật này. Nhiều mô hình hiện đại đã có chế độ suy luận riêng, nhưng việc yêu cầu "liệt kê giả thuyết trước, sau đó kiểm tra từng giả thuyết" vẫn giúp câu trả lời có cấu trúc hơn.

5. Chia nhỏ tác vụ lớn

Thay vì yêu cầu "xây toàn bộ module thanh toán", hãy đi theo chuỗi: thiết kế interface, viết từng hàm, viết test, rồi review. Mỗi bước nhỏ dễ kiểm chứng hơn và bạn có thể sửa hướng sớm nếu kết quả đi lệch.

Mẫu prompt hữu ích cho công việc hằng ngày

Dưới đây là một khung prompt mà bạn có thể tái sử dụng cho hầu hết tác vụ lập trình:

Vai trò: Bạn là senior backend engineer quen với Node.js và PostgreSQL.
Bối cảnh: API Express, dùng Prisma ORM, chạy trên Node 20.
Nhiệm vụ: Tối ưu truy vấn lấy danh sách đơn hàng kèm khách hàng.
Ràng buộc: Không đổi schema, giữ nguyên format response.
Đầu ra: Code đã sửa + giải thích ngắn lý do + rủi ro cần lưu ý.

Một vài tình huống áp dụng thường gặp:

  • Giải thích code cũ: dán đoạn code và hỏi "đoạn này làm gì, có edge case nào dễ gây lỗi?".
  • Viết test: cung cấp hàm cùng framework test đang dùng, yêu cầu liệt kê case trước rồi mới viết code.
  • Review: yêu cầu mô hình đóng vai reviewer khó tính, chỉ ra vấn đề theo mức độ nghiêm trọng.
  • Viết tài liệu: đưa vào code và yêu cầu README theo cấu trúc cố định của team.

Những lỗi thường gặp

  • Prompt quá ngắn: thiếu bối cảnh khiến mô hình phải đoán, dẫn đến câu trả lời chung chung.
  • Nhồi quá nhiều yêu cầu mâu thuẫn: "ngắn gọn nhưng giải thích thật chi tiết" khiến kết quả không như mong đợi.
  • Tin tuyệt đối vào đầu ra: mô hình có thể bịa ra API không tồn tại. Luôn chạy thử, đọc tài liệu chính thức và viết test.
  • Dán dữ liệu nhạy cảm: không đưa mật khẩu, khóa API hay dữ liệu khách hàng vào công cụ AI khi chưa được công ty cho phép.

Lặp lại và đo lường

Prompt engineering là một quá trình thử nghiệm. Khi xây tính năng AI trong sản phẩm, hãy lưu các prompt dưới dạng file có quản lý phiên bản, chuẩn bị một bộ input mẫu và so sánh đầu ra mỗi khi chỉnh sửa. Đây chính là tư duy "test" quen thuộc của lập trình viên, chỉ áp dụng cho ngôn ngữ tự nhiên.

Kết luận

Viết prompt hiệu quả xoay quanh một điều: giao tiếp rõ ràng. Hãy cung cấp bối cảnh, nêu mục tiêu cụ thể, tách bạch chỉ dẫn với dữ liệu, đưa ví dụ khi cần và chia nhỏ bài toán. Quan trọng nhất, luôn giữ vai trò người kiểm duyệt cuối cùng: AI giúp bạn đi nhanh hơn, nhưng trách nhiệm về chất lượng code vẫn thuộc về bạn.

Nguồn tham khảo