Nguyên tắc viết Prompt hiệu quả dành cho lập trình viên
Nếu bạn đã dùng Claude, ChatGPT hay Copilot để hỗ trợ code được vài tháng, chắc bạn từng gặp cảnh: hỏi một câu, nhận về một đoạn code “gần đúng” — chạy được nhưng sai logic, thiếu edge case, hoặc không đúng ý mình muốn. Vấn đề thường không nằm ở model, mà nằm ở prompt.
Với dân kỹ thuật, viết prompt cũng nên được tiếp cận giống như viết spec hay viết test case: càng cụ thể, càng có cấu trúc, kết quả càng ổn định. Bài này tổng hợp những nguyên tắc mình thấy hiệu quả nhất khi dùng AI trong công việc lập trình hàng ngày.
1. Rõ ràng và cụ thể (Clarity & Specificity)
Đây là nguyên tắc nền tảng nhất. Model không đọc được suy nghĩ của bạn — nó chỉ có đúng những gì bạn viết ra.
Prompt mơ hồ:
Viết function xử lý user input
Prompt cụ thể:
Viết function TypeScript tên `parseUserAge(input: string): number | null`.
- Input là chuỗi người dùng nhập từ form.
- Trả về number nếu parse được và nằm trong khoảng 0–150.
- Trả về null nếu input rỗng, không phải số, hoặc ngoài khoảng.
- Không throw exception.
Prompt thứ hai loại bỏ gần như toàn bộ khoảng trống để model “đoán”. Càng ít phải đoán, output càng ít sai lệch.
Một mẹo nhỏ: hãy viết prompt như thể bạn đang giao task cho một dev mới vào team, chưa biết gì về codebase của bạn. Điều gì bạn thấy “hiển nhiên” thì với model lại không hề hiển nhiên.
2. Cung cấp context đúng và đủ
Context ở đây không phải là dán cả file 2000 dòng vào prompt. Context hiệu quả là:
- Role/persona: “Bạn là senior backend engineer chuyên về hệ thống distributed, ưu tiên tính đúng đắn hơn tốc độ viết code.”
- Ràng buộc kỹ thuật: ngôn ngữ, version, framework, style guide đang dùng trong team.
- Business logic liên quan: tại sao cần function này, nó nằm ở đâu trong flow lớn hơn.
Ví dụ với task DevOps/IaC:
Context: Team đang dùng Terraform 1.9.8, quản lý 3 môi trường
dev/test/prod qua workspace riêng biệt, state lưu trên S3 + DynamoDB lock.
Task: Viết module aws_rds hỗ trợ multi-AZ cho prod, single-AZ cho dev/test,
biến số điều khiển qua variable `environment`.
Không có context này, model rất dễ đề xuất một cấu trúc Terraform “chuẩn sách giáo khoa” nhưng không khớp với kiến trúc thật của bạn.
3. Dùng ví dụ (few-shot prompting) — cả đúng lẫn sai
Khi output cần theo một format hoặc convention riêng, mô tả bằng lời thường không đủ chính xác bằng cho ví dụ trực tiếp.
Đây là style commit message team mình dùng:
Đúng:
feat(auth): add rate limiting to login endpoint
fix(billing): correct rounding error in invoice total
Sai (không dùng):
Fixed bug
update code
Hãy viết commit message cho thay đổi: thêm retry logic cho API call đến payment gateway.
Cho cả ví dụ đúng và ví dụ sai giúp model hiểu ranh giới rõ hơn là chỉ cho một chiều. Đây cũng là kỹ thuật rất hiệu quả khi bạn muốn AI review code theo đúng coding convention của team thay vì convention “chung chung” mà nó học được.
4. Yêu cầu suy luận từng bước cho bài toán phức tạp
Với các task chỉ cần output ngắn (viết một regex, sửa một dòng bug), yêu cầu model suy nghĩ từng bước là thừa. Nhưng với các task có logic phức tạp — thiết kế schema, debug race condition, review security — việc yêu cầu model trình bày quá trình suy luận trước khi đưa kết luận thường cho ra kết quả chính xác hơn.
Trước khi đưa ra fix, hãy:
1. Liệt kê các nguyên nhân có thể gây ra race condition này.
2. Với mỗi nguyên nhân, giải thích tại sao có/không khớp với log đính kèm.
3. Chỉ sau đó mới đề xuất fix cụ thể.
Cách này còn có lợi ích phụ: bạn dễ dàng phát hiện chỗ model suy luận sai trước khi nó ảnh hưởng đến code thật, thay vì chỉ nhận một đáp án “đóng hộp” mà không biết đúng sai ở đâu.
5. Định dạng output rõ ràng
Nếu bạn định parse output bằng code, hoặc chỉ đơn giản muốn output dễ đọc, hãy nói rõ format ngay trong prompt — đừng để model tự chọn.
Trả lời CHỈ dưới dạng JSON, không có text nào khác, theo schema:
{
"severity": "low" | "medium" | "high" | "critical",
"root_cause": string,
"suggested_fix": string
}
Với các task dài hơn (viết doc, review nhiều file), dùng XML tag để phân vùng nội dung cũng giúp model tổ chức output tốt hơn và giúp bạn dễ trích xuất từng phần:
Hãy phân tích đoạn log này và trả lời trong các tag sau:
<summary>...</summary>
<affected_components>...</affected_components>
<recommended_action>...</recommended_action>
6. Giới hạn phạm vi thay vì hỏi chung chung
“Review giúp mình đoạn code này” là một prompt hợp lệ nhưng lười. Model sẽ review đủ thứ: style, performance, security, naming… dàn trải và hời hợt.
Cụ thể hóa phạm vi:
Review đoạn code này CHỈ tập trung vào:
1. Lỗ hổng bảo mật (injection, race condition, exposed secrets)
2. Xử lý lỗi (có catch hết exception cần thiết không)
Không cần góp ý về style hay naming.
Khi bạn giới hạn phạm vi, model có “ngân sách chú ý” tập trung hơn vào đúng thứ bạn cần, thay vì rải đều cho mọi khía cạnh có thể.
7. Prompt cũng cần được lặp lại và tinh chỉnh (iterate)
Prompt tốt hiếm khi đúng ngay từ lần đầu — giống như code, nó cần refactor. Một quy trình thực tế:
- Viết prompt đầu tiên, chạy thử.
- Xem output sai ở đâu — sai vì thiếu context, hay vì mô tả mơ hồ, hay vì thiếu ví dụ?
- Sửa đúng chỗ đó, không sửa lan man.
- Nếu một task lặp lại thường xuyên (ví dụ: review PR, viết test case theo pattern cố định), hãy lưu lại prompt đó thành template dùng chung cho cả team.
8. Một vài lưu ý riêng cho dev
- Đừng dán nguyên codebase nếu không cần. Trích đúng phần liên quan + mô tả phần còn lại. Context dư thừa làm loãng sự chú ý của model vào phần quan trọng.
- Cẩn trọng với prompt injection nếu bạn xây dựng tool có AI xử lý input từ bên ngoài (file upload, API response, nội dung web) — nội dung đó có thể chứa chỉ dẫn giả mạo. Luôn tách rõ “dữ liệu” và “chỉ dẫn” trong prompt.
- Không tin tuyệt đối vào output, đặc biệt với các task liên quan đến bảo mật hoặc infrastructure production. AI có thể tự tin nhưng sai — luôn verify lại bằng kiến thức chuyên môn của bạn, đặc biệt với các câu trả lời liên quan đến log, alert, hoặc hành vi hệ thống thật.
Tổng kết
Viết prompt hiệu quả, xét cho cùng, là một dạng kỹ năng giao tiếp kỹ thuật — không khác gì viết một spec rõ ràng cho đồng nghiệp. Bốn nguyên tắc cốt lõi:
- Rõ ràng, cụ thể — loại bỏ khoảng trống để model đoán.
- Context đúng — role, ràng buộc kỹ thuật, business logic liên quan.
- Ví dụ cụ thể — đặc biệt khi cần theo convention riêng.
- Cấu trúc suy luận + format output — cho task phức tạp và khi cần parse kết quả.
Prompt tốt không làm bạn giỏi hơn về domain, nhưng nó giúp bạn khai thác đúng năng lực model đang có — tiết kiệm thời gian sửa lại output sai, thay vì phải đoán mò tại sao AI “không hiểu ý mình”.
Tác giả: Nguyễn Mai Trang – Data Analyst tại MCNA Technology School
📞 Hotline: 0939.866.825 (Mr. Minh Khang)
🌐 Website: mcna.vn
📍 Hà Nội: 30 Trung Liệt, Đống Đa | Liền kề 44B TT2 Văn Quán, Hà Đông
📍 TP.HCM: 50B Phan Tây Hồ, Cầu Kiệu
