Prompt cho lập trình: cách viết prompt để AI code đúng ý

Bạn gõ "viết cho tôi hàm xử lý đăng nhập", AI trả về một hàm trông rất gọn. Bạn dán vào dự án, nó báo lỗi, không khớp convention, thiếu mất trường hợp token hết hạn. Bạn lại gõ tiếp, sửa tới sửa lui năm bảy lần. Cuối buổi bạn kết luận: "AI này cũng thường thôi."

Vấn đề thường không nằm ở AI, mà ở prompt. Cùng một mô hình, người mô tả rõ ràng nhận về code chạy được ngay, người mô tả mơ hồ nhận về một bản nháp phải viết lại. Đây là lý do prompt lập trình đang trở thành kỹ năng nền của dev thời AI, ngang hàng với đọc code và debug.

Bài này tổng hợp nguyên tắc viết prompt code dựa trên tài liệu chính thống của Anthropic (Claude / Claude Code) và Cursor, kèm ví dụ prompt tệ và prompt tốt để bạn áp dụng được ngay. Nếu bạn muốn nhìn bức tranh rộng hơn về cách làm việc với AI, đọc trước bài trụ Lập trình với AI 2026.

Vì sao prompt quyết định chất lượng code AI

Mô hình ngôn ngữ không đọc được suy nghĩ của bạn. Anthropic nói thẳng trong docs: hãy coi Claude như "một nhân viên giỏi nhưng mới, chưa nắm quy ước và quy trình của bạn". Nó chỉ biết những gì bạn đưa vào prompt, cộng với những gì nó tự tìm được trong codebase. Cái gì bạn không nói, nó phải đoán. Và khi nó đoán, nó đoán theo "mặc định phổ biến nhất" chứ không phải theo dự án của bạn.

Với code, hậu quả của việc đoán rất cụ thể: sai convention, dùng thư viện bạn không dùng, bỏ qua edge case, hoặc giải đúng bài nhưng sai đề. Tài liệu Claude Code có một quy tắc đáng nhớ: prompt mơ hồ thì có ích khi bạn đang dò đường và sẵn sàng chỉnh lại; còn khi bạn đã biết mình cần gì thì "càng cụ thể, bạn càng ít phải sửa".

Nói cách khác, thời gian bạn bỏ ra viết prompt cho tử tế gần như luôn rẻ hơn thời gian sửa output sai. Đó là một khoản đầu tư, không phải thủ tục.

Nguyên tắc viết prompt tốt cho code

Không có "câu thần chú" nào cả. Viết prompt tốt là kỹ năng diễn đạt, và nó gói gọn trong vài nguyên tắc dưới đây.

Cụ thể, không mơ hồ

Quy tắc vàng của Anthropic: đưa prompt cho một đồng nghiệp ít ngữ cảnh đọc thử, nếu họ thấy khó hiểu thì AI cũng vậy. Hãy nói rõ output mong muốn, định dạng, và các bước nếu thứ tự quan trọng.

Thay vì "thêm test cho foo.py", hãy viết "viết test cho foo.py, tập trung trường hợp user đã đăng xuất, không dùng mock". Câu sau khoanh vùng file, kịch bản, và cả phong cách test.

Cho đủ ngữ cảnh và lý do

AI làm tốt hơn khi hiểu vì sao. Anthropic khuyến nghị nêu động cơ đằng sau yêu cầu, vì mô hình đủ thông minh để suy rộng từ lời giải thích. "Sửa hàm này cho nhanh hơn vì nó chạy trong vòng lặp render mỗi frame" sẽ cho kết quả sát hơn là "tối ưu hàm này".

Ngữ cảnh quan trọng nhất với code là codebase của bạn. Hãy trỏ thẳng tới file, hoặc tới một mẫu có sẵn để AI bắt chước: "xem cách các widget hiện có viết ở trang chủ, HotDogWidget.php là ví dụ tốt, làm theo pattern đó". Cả Cursor lẫn Claude Code đều cho phép tham chiếu file bằng cú pháp @ thay vì mô tả chay vị trí code.

Nêu ràng buộc và edge case

AI sẽ vui vẻ bỏ qua những gì bạn không nhắc. Hãy liệt kê ràng buộc ngay từ đầu: "chỉ dùng các thư viện đã có trong dự án, đừng thêm dependency mới", "không sửa file migration", "phải xử lý trường hợp mảng rỗng và input null".

Một mẹo từ docs Anthropic về cả định dạng lẫn hành vi: nói cho AI biết nên làm gì, thay vì chỉ cấm. "Trả về prose liền mạch" hiệu quả hơn "đừng dùng markdown". Với code cũng vậy: "validate ở biên hệ thống (input người dùng, API ngoài), tin tưởng code nội bộ" rõ hơn là "đừng viết defensive code lung tung".

Chia nhỏ task

Một agent làm một việc rõ ràng sẽ chính xác hơn nhiều so với một đề bài khổng lồ mơ hồ. Thay vì "làm cho tôi tính năng thanh toán", hãy tách: tạo schema đơn hàng, viết hàm tạo link thanh toán, xử lý webhook, gửi email xác nhận. Sau mỗi phần, chạy thử rồi mới đi tiếp.

Lý do kỹ thuật: context window của AI đầy lên rất nhanh, và càng đầy thì chất lượng càng giảm, mô hình bắt đầu "quên" chỉ dẫn ban đầu. Tài liệu Claude Code coi đây là ràng buộc lớn nhất khi làm việc với agent. Task nhỏ giữ context sạch và dễ kiểm soát.

Dùng ví dụ và cho AI cách tự kiểm tra

Ví dụ là một trong những cách lái output ổn định nhất. Anthropic gọi đây là few-shot / multishot: vài ví dụ sát thực tế giúp AI bám đúng format và phong cách.

Quan trọng không kém với code: cho AI một cách tự xác minh kết quả. Đây có lẽ là mẹo bị bỏ qua nhiều nhất. Thay vì "viết hàm validateEmail", hãy viết "viết hàm validateEmail, ví dụ: user@example.com trả true, invalid trả false, user@.com trả false; chạy test sau khi viết". Khi có một bài kiểm tra trả về pass/fail, AI tự chạy, tự đọc kết quả và tự sửa cho tới khi đạt, thay vì để bạn làm vòng lặp kiểm tra thủ công.

Prompt tệ vs prompt tốt: ví dụ thực tế

Bốn cặp dưới đây phỏng theo bảng đối chiếu trong docs Claude Code, dịch sang tình huống quen thuộc.

Khoanh vùng task

• Tệ: "thêm test cho foo.py"
• Tốt: "viết test cho foo.py, phủ trường hợp user đã đăng xuất, tránh dùng mock"

Trỏ tới nguồn

• Tệ: "tại sao ExecutionFactory có cái API kỳ vậy?"
• Tốt: "đọc git history của ExecutionFactory và tóm tắt API của nó hình thành thế nào"

Bám pattern có sẵn

• Tệ: "thêm một calendar widget"
• Tốt: "xem các widget hiện có ở trang chủ để hiểu pattern, HotDogWidget.php là ví dụ tốt; làm theo để tạo calendar widget cho phép chọn tháng và phân trang qua lại theo năm; chỉ dùng thư viện đã có trong dự án"

Mô tả triệu chứng, không mô tả mệnh lệnh trống

• Tệ: "sửa bug đăng nhập"
• Tốt: "user báo đăng nhập lỗi sau khi session timeout; kiểm tra luồng auth ở src/auth/, đặc biệt phần refresh token; viết một test fail tái hiện lỗi, rồi sửa"

Điểm chung của cột bên phải: có địa chỉ cụ thể, có ràng buộc, và có tiêu chí biết khi nào là xong.

Mẹo cho Cursor và Claude Code

Hai công cụ phổ biến nhất hiện nay có vài thói quen riêng đáng tập. Nếu bạn chưa quen, đọc Cursor là gì và Claude Code là gì trước.

Tách "explore, plan, code" ra khỏi nhau. Đừng để AI nhảy thẳng vào code, dễ giải sai bài. Quy trình Anthropic gợi ý: cho AI đọc file và trả lời câu hỏi trước (plan mode), rồi yêu cầu lập kế hoạch chi tiết, bạn duyệt kế hoạch, sau đó mới cho code. Sửa một kế hoạch sai rẻ hơn sửa code sai nhiều. Với việc nhỏ một câu mô tả được cái diff thì cứ làm thẳng, khỏi cần plan.

Đưa context vào file rules. Cả hai đều có file ghi nhớ ngữ cảnh dùng lại: Claude Code đọc CLAUDE.md ở đầu mỗi phiên; Cursor dùng .cursor/rules (hoặc AGENTS.md). Đặt vào đó những thứ AI không tự đoán được: lệnh build, code style khác mặc định, quy ước đặt tên branch. Lời khuyên chung từ cả hai: giữ ngắn. Cursor khuyên rule dưới 500 dòng và "chỉ thêm khi thấy agent lặp lại cùng một lỗi"; Anthropic cảnh báo file quá dài khiến AI bỏ sót chính những quy tắc quan trọng.

Sửa sớm, và reset khi cần. Thấy AI đi sai hướng thì dừng và chỉnh ngay, đừng để nó đi xa. Nếu đã sửa cùng một lỗi quá hai lần trong một phiên, context đã rối vì những cách tiếp cận thất bại; tốt hơn là /clear và viết lại một prompt rõ hơn dựa trên điều vừa học. Một phiên sạch với prompt tốt gần như luôn thắng một phiên dài đầy chỉnh sửa chồng chất.

Sai lầm thường gặp

• Prompt mơ hồ rồi mong AI đoán đúng. "Làm cho đẹp hơn", "tối ưu cái này" không cho AI đủ thông tin. Mơ hồ chỉ hợp lúc thăm dò.
• Nhồi quá nhiều vào một prompt. Giao cả tính năng lớn trong một câu thường cho code rời rạc. Chia nhỏ sẽ tốt hơn.
• Không cho cách xác minh. Code "trông như xong" nhưng không ai kiểm tra là cái bẫy phổ biến nhất. Có test, script hoặc screenshot để AI tự đối chiếu thì kết quả đáng tin hơn hẳn.
• Để context phình to. Hỏi việc A rồi nhảy sang việc B không liên quan trong cùng phiên khiến AI lẫn. Reset giữa các task khác nhau.
• Tin output mà không đọc diff. Đây là sai lầm nguy hiểm nhất. Prompt tốt đến đâu, bạn vẫn phải đọc và chịu trách nhiệm cho từng dòng code mình merge. AI viết hộ, nhưng đó là code của bạn.

Một lưu ý cân bằng: prompt không phải lúc nào cũng càng chi tiết càng tốt. Khi bạn đang khám phá một codebase lạ hoặc muốn xem AI hiểu vấn đề ra sao, một câu hỏi mở như "bạn sẽ cải thiện gì ở file này?" lại đúng hơn. Kỹ năng thật sự là biết khi nào cần cụ thể và khi nào nên để ngỏ.

### Prompt giỏi bắt đầu từ nền tảng vững >Để ý kỹ các prompt tốt ở trên: chúng đòi bạn biết gọi tên thứ mình muốn, biết file nào liên quan, biết edge case nào cần phủ, và biết đọc diff để xác nhận AI làm đúng. Tất cả đều dựa trên kiến thức nền, không phải mẹo viết câu. >Đó là lý do người có nền tảng vững ra prompt chuẩn hơn, và review được output thay vì tin vào may rủi:- Khóa React PRO của HoleTex: xây nền frontend đủ chắc để bạn mô tả đúng thứ cần làm và làm chủ mọi đoạn code AI sinh ra. >Nền càng vững, prompt của bạn càng sắc, và AI càng là đòn bẩy chứ không phải cái bẫy.

Bài liên quan

• Lập trình với AI 2026: bản đồ toàn cảnh cho dev Việt
• Cursor là gì và dùng sao cho hiệu quả
• Claude Code là gì và workflow terminal-first
• Vibe coding là gì và khi nào nên dùng
• Cursor vs Copilot vs Claude Code: chọn cái nào

Nguồn tham khảo: Prompt engineering overview (Anthropic / Claude docs), Prompting best practices (Anthropic / Claude docs), Best practices for Claude Code (code.claude.com), Cursor Rules (cursor.com/docs). Cập nhật 2026-06-07.