Trả lời nhanh: Cursor rules là các file luật trong thư mục .cursor/rules của dự án: mô tả quy ước code, stack, điều cấm, AI đọc trước khi làm bất cứ gì, thay cho việc bạn lặp lại cùng một dặn dò mỗi phiên chat. Rules tốt = ngắn, cụ thể, có ví dụ; kèm khả năng gắn rule theo loại file (chỉ áp cho *.tsx chẳng hạn). Cùng triết lý với CLAUDE.md bên Claude Code, viết một lần, đội và AI cùng theo.
Ai dùng Cursor đủ lâu đều gặp cảnh này: dặn AI dùng Tailwind đừng viết CSS thuần ở phiên sáng, chiều mở phiên mới nó lại quên. Cursor rules, từ khóa tăng 10 lần trong 4 năm, là câu trả lời chính thống: luật của dự án nằm trong repo, AI nào mở dự án cũng phải đọc. Bài này viết bộ rules đầu tiên đúng cách, các mẫu chép được cho dự án Việt, và ranh giới giữa rules hữu ích với rules rác.
- Rules sống trong
.cursor/rules/dạng file .mdc, commit vào repo, cả đội hưởng chung - Cấu trúc một rule: mô tả khi nào áp dụng + nội dung luật + (tùy chọn) glob giới hạn loại file
- Luật tốt: cụ thể và có ví dụ đúng/sai; luật rác: chung chung kiểu 'viết code sạch'
- Bộ tứ khởi điểm: stack & quy ước · cấm kỵ · cấu trúc thư mục · giọng comment/tên biến
- Cùng họ với CLAUDE.md, dùng cả hai công cụ thì giữ nội dung nhất quán
Rules nằm đâu và Cursor đọc thế nào
Cấu trúc hiện hành: thư mục .cursor/rules/ trong repo, mỗi luật một file .mdc (Markdown kèm phần đầu khai metadata). Mỗi rule có mô tả để Cursor quyết khi nào nạp: rule áp dụng luôn (always), rule theo glob (chỉ nạp khi đụng file khớp mẫu, ví dụ luật React chỉ áp cho **/*.tsx), hoặc rule để agent tự chọn theo mô tả. File .cursorrules đơn lẻ ở gốc repo là định dạng cũ vẫn chạy, dự án mới nên theo thư mục rules để tách luật theo chủ đề. Điều quan trọng nhất: commit vào git, rules là tài sản của đội, không phải cấu hình cá nhân.
Viết luật cho AI: khác viết cho người ở đâu
Ba nguyên tắc rút từ thực chiến: (1) Cụ thể thắng chung chung, code sạch, dễ maintain là luật rác (model vốn nghĩ nó đang làm vậy); dùng date-fns, không dùng moment mới là luật. (2) Ví dụ đúng/sai đáng giá hơn mô tả, một cặp đoạn code ✅/❌ dạy model nhanh hơn ba đoạn văn. (3) Ngắn, rules quá dài loãng sự chú ý của model, giữ mỗi file dưới vài chục dòng, tổng thể chỉ những luật đã từng bị vi phạm thật. Cách xây bộ luật bền: mỗi lần AI làm sai điều gì đáng nhớ, thêm một dòng luật; sau một tháng bạn có bộ rules đắt giá hơn mọi template trên mạng.
Bộ tứ khởi điểm cho dự án Việt
# .cursor/rules/stack.mdc, luon ap dung
Dự án: Next.js App Router + TypeScript + Tailwind + Drizzle/Postgres.
Dùng: date-fns, zod, shadcn/ui. KHÔNG dùng: moment, CSS module mới.
Text hiển thị cho người dùng: tiếng Việt có dấu, xưng hô trung tính.
# .cursor/rules/cam-ky.mdc, luon ap dung
- Không hardcode secret/API key, luôn qua biến môi trường
- Không any trong TypeScript trừ khi có comment giải thích
- Không tự thêm thư viện mới khi chưa hỏi
- Migration database: chỉ tạo file, KHÔNG tự chạy
# .cursor/rules/react.mdc, glob: **/*.tsx
- Server Component mặc định; "use client" chỉ khi cần tương tác
- Component đặt tên PascalCase, file kebab-caseCộng file thứ tư về cấu trúc thư mục của chính dự án bạn (nơi đặt component, api route, util). Bốn file này chặn được phần lớn các pha AI tự tung tự tác gây bực nhất.
Rules và CLAUDE.md: một triết lý, hai mái nhà
Nếu đội bạn dùng song song Cursor và Claude Code (cặp đôi phổ biến, đã so ở bài Cursor vs Claude Code): CLAUDE.md của Claude Code đóng đúng vai này. Đừng duy trì hai bộ luật lệch nhau, mẹo thực dụng: nội dung luật viết một nơi (ví dụ file docs/conventions.md làm nguồn), rồi .cursor/rules và CLAUDE.md cùng trỏ/trích từ đó; hoặc tối thiểu là mỗi lần thêm luật thì thêm cả hai. AI nào vào dự án, Cursor, Claude Code, hay agent chạy trên VPS qua tmux, cũng chung một hiến pháp.
Giới hạn thật: rules không phải phép màu
Nói thẳng để kỳ vọng đúng: rules là ưu tiên mạnh, không phải xiềng xích, model thi thoảng vẫn trượt luật, nhất là phiên dài hoặc ngữ cảnh lớn; nhắc một câu là nó tuân lại. Rules cũng không thay được review: luật cấm hardcode secret không miễn cho bạn việc soi diff trước khi merge. Và đừng nhồi kiến thức nghiệp vụ dài vào rules, đó là việc của tài liệu dự án mà AI đọc khi cần; rules chỉ giữ quy ước hành xử. Giữ đúng vai đó, bộ rules vài chục dòng tiết kiệm cho đội hàng giờ sửa đi sửa lại mỗi tuần, tỷ lệ đầu tư/lợi nhuận tốt nhất trong mọi thứ bạn viết cho AI.
Bộ luật khởi điểm, viết cụ thể chứ đừng chung chung
# Luat TOT: cu the, kiem chung duoc - Moi ham xu ly tien phai dung kieu so nguyen theo don vi dong, khong dung so thuc - Moi truy van co so du lieu phai dung tham so, khong noi chuoi - Moi ham public phai co kieu tra ve tuong minh - Khong tao file moi khi co the sua file san co trong cung thu muc - Comment viet bang tieng Viet khong dau hoac tieng Anh, khong tron ca hai # Luat KEM: chung chung, khong kiem chung duoc - Viet code sach <- sach la the nao - Tuan thu best practice <- cua ai - Toi uu hieu nang <- toi uu cai gi, den muc nao
Nguyên tắc: một luật tốt là luật mà bạn đọc một đoạn mã và nói được ngay là có tuân thủ hay không. Luật không kiểm chứng được thì trợ lý cũng không áp dụng được, và nó chỉ chiếm chỗ trong phần mô tả bối cảnh.
Bốn nhóm luật nên có cho dự án Việt Nam
| Nhóm | Ví dụ luật cụ thể |
|---|---|
| Tiền và số | Lưu tiền bằng số nguyên đơn vị đồng; định dạng hiển thị dùng dấu chấm phân cách nghìn |
| Ngày giờ | Lưu theo giờ chuẩn quốc tế, hiển thị theo múi giờ Việt Nam; định dạng ngày tháng năm |
| Chuỗi tiếng Việt | Chuẩn hóa dấu trước khi so sánh; không dùng hàm cắt chuỗi theo byte |
| Cấu trúc dự án | Nói rõ thư mục nào chứa gì, và nơi đặt tệp mới |
Giới hạn thật: luật không phải phép màu
- Luật càng dài càng loãng. Giữ dưới khoảng 30 dòng cho phần dùng chung. Danh sách 200 dòng thì trợ lý bỏ qua phần lớn.
- Luật không thay được việc kiểm tự động. Thứ thật sự bắt buộc phải nằm trong công cụ kiểm định dạng và kiểm kiểu, không phải trong tệp luật.
- Luật mâu thuẫn nhau thì trợ lý chọn ngẫu nhiên. Rà lại khi thêm luật mới.
- Vẫn phải đọc mã trước khi ghép vào nhánh chính. Luật giảm số lần phải sửa, không loại bỏ việc rà soát.
Cách bắt đầu thực dụng: mỗi lần bạn phải sửa cùng một loại lỗi lần thứ ba, viết nó thành một luật. Danh sách luật xây theo cách này luôn hữu ích hơn danh sách chép từ nơi khác.
Câu hỏi thường gặp
Rules có làm tốn thêm token/chi phí không?
Có, rules được nạp vào ngữ cảnh nên tính token, thêm một lý do giữ chúng ngắn. Rule gắn glob chỉ nạp khi đụng đúng loại file là cơ chế tiết kiệm sẵn có: tận dụng thay vì để mọi luật always.
Có template rules tốt trên mạng, cứ chép về dùng?
Tham khảo được cấu trúc, nhưng giá trị thật nằm ở luật riêng của dự án bạn, template chung chung dễ thành nhiễu. Cách tốt hơn: bắt đầu từ bộ tứ trong bài, bồi luật từ lỗi thật của chính AI trong dự án mình.
Một rule dài bao nhiêu là quá dài?
Quá vài chục dòng là nên tách hoặc cắt. Ngửi mùi: nếu rule đọc như tài liệu hướng dẫn thì nó là tài liệu, không phải luật, chuyển vào docs và để rule chỉ ghi 'đọc docs/x.md trước khi đụng module này'.
Làm dự án khách (agency) thì rules để đâu?
Vẫn trong repo từng dự án, mỗi khách một bộ luật theo stack của họ, đi theo repo khi bàn giao. Bộ luật 'gu chung' của agency thì giữ template riêng và chép vào lúc khởi tạo dự án.
