Cursor có 5 lớp cấu hình: bạn đang dùng đúng một lớp

Bạn dán rule vào Cursor, rồi đầu mỗi session vẫn phải giải thích lại project từ đầu. Bạn viết lại rule lần thứ năm, vẫn vậy — vì rule chỉ là một trong năm lớp cấu hình, và bốn lớp còn lại đang không làm gì cả.

Một dev vừa công bố kết quả sau khi set đủ cả năm lớp trên một production Go codebase — service kéo vị thế Trading212 lúc mở và đóng phiên, giữ rolling snapshot trong Upstash Redis, ghi lịch sử vào Airtable. Đây là thứ tự các lớp và lý do nó là thứ tự chứ không phải menu.

Chuỗi năm lớp

Tác giả mô tả chuỗi là rules → hooks → skills → agents → MCP, mỗi lớp giả định lớp trước đã tồn tại:

• Rules ràng buộc thứ được viết ra.
• Hooks cưỡng chế ở thời điểm commit đúng thứ mà rule yêu cầu ở thời điểm viết.
• Skills là workflow bạn chủ động gọi.
• Agents sở hữu một đầu việc và mang permission riêng.
• MCP là cách bất kỳ lớp nào ở trên chạm được ra ngoài editor.

Bỏ một lớp thì lớp phía trên rò. Theo tác giả: agent không có rule sẽ sinh code vi phạm convention nhanh hơn tốc độ bạn review; rule không có hook chỉ là gợi ý; skill không được scope sẽ biến thành rule bắn liên tục rồi bị bỏ qua.

Vì sao rule của bạn không giữ được gì

Tác giả gọi thẳng lỗi mình mắc suốt nhiều tháng: viết rule như một wishlist. "Write clean code." "Handle errors properly." Không có gì cưỡng chế được, và mọi thứ đều bỏ qua được.

Thứ chạy được là rule hẹp và kiểm tra được. Trong repo đó, rule nói: chiều phụ thuộc giữ nguyên — domain không bao giờ import infrastructure; error phải được wrap kèm operation context; không nuốt error im lặng; HTTP client phải khai báo timeout tường minh; lỗi 5xx tạm thời retry đúng một lần trước khi nổi lên.

Khác biệt rất rõ: mỗi câu trên đều có thể trả lời đúng/sai khi đọc diff. "Clean code" thì không.

Phần cơ học: frontmatter quyết định lúc nào rule nạp

Rule nằm trong .cursor/rules/ dưới dạng file .mdc với YAML frontmatter, và chính frontmatter quyết định khi nào chúng được nạp:

---
description: "Go API design and error handling"
globs: infrastructure/**/*.go, domain/**/*.go
alwaysApply: false
---

Đây là chỗ nhiều team VN mất công vô ích. Suy ra từ chính field này: nếu bạn để mọi rule alwaysApply: true, model nhận cùng một khối text ở mọi request — kể cả khi đang sửa file không liên quan. Dùng globs để rule Go chỉ nạp khi chạm file Go là cách giảm nhiễu mà không phải rút ngắn nội dung rule.

Áp dụng theo thứ tự

Nếu team bạn đang ở lớp một, phần phân tích ở đây là: đừng nhảy thẳng lên agent hay MCP. Viết lại rule theo dạng kiểm tra được trước, vì đó là lớp mà bốn lớp còn lại dựa vào. Sau đó thêm hook để những rule đó không còn là gợi ý. Chỉ khi hai lớp này giữ được thì skill và agent mới đáng dựng.

Việc cần theo dõi: sau khi bật globs, kiểm tra xem session mới còn phải nghe bạn giải thích lại project không. Nếu vẫn phải, vấn đề nằm ở nội dung rule chứ không còn ở lớp nạp nữa.