[Series AI] Content và Optimize AI – Demo với Project Architecture và Conventions

Chào anh em, mình đã quay trở lại! Chúng ta đã đi qua một hành trình dài từ việc làm quen với IDE, so sánh các Agent cho đến việc dùng AI để research giải pháp.

Nhưng có một thực tế phũ phàng: AI dù thông minh đến đâu cũng chỉ là một "người lạ" khi mới bước vào codebase của bạn. Nếu anh em cứ để mặc định, nó sẽ viết code theo kiểu "tiện đâu làm đó". Hậu quả là sau một thời gian, project của anh em sẽ biến thành một đống "spaghetti" đúng nghĩa, dù code trông rất hiện đại.

Hôm nay, mình sẽ chia sẻ bí kíp "huấn luyện" AI để nó không chỉ viết code chạy được, mà còn phải viết code đúng gu, đúng chuẩn (Conventions) và đúng kiến trúc (Architecture) mà anh em đã dày công xây dựng.

1. Tại sao AI cần "Kỷ luật"?

Khi anh em làm việc trong các dự án lớn (như tại Hasaki hay các dự án Metro mà mình từng tham gia), việc tuân thủ Convention là sống còn.

AI không biết bạn thích dùng PascalCase hay camelCase cho file name.
AI không biết bạn muốn xử lý lỗi tập trung (Global Exception Handler) hay try/catch tại chỗ.
AI không biết bạn đang áp dụng Repository Pattern hay đơn giản là dùng trực tiếp Model trong Controller.

Nếu không được "dạy bảo" từ đầu, AI sẽ trở thành một thành viên "toxic" nhất trong team – code nhanh nhưng phá vỡ mọi quy tắc chung.

2. Tối ưu "Bộ não" AI qua cấu trúc dự án (Project Architecture)

Để AI hiểu được kiến trúc, việc đầu tiên là phải có một cấu trúc thư mục mạch lạc. Một cấu trúc rõ ràng chính là "Context ngầm" tốt nhất cho AI.

Ví dụ một cấu trúc chuẩn cho Backend (Node/Go/Laravel) mà mình thường dùng:

/src
  /domain       # Chứa các Entity, Interface (Core logic)
  /application  # Chứa Use Cases, Services (Điều phối luồng)
  /infrastructure
    /persistence # Database, Repository implementation
    /external_services # Gọi API bên thứ 3 (OpenAI, Payment...)
  /presentation # Controllers, DTOs, Routes

Khi anh em bôi đen một file trong /domain và yêu cầu tạo logic tương ứng trong /presentation, Cursor sẽ tự động hiểu nó cần tuân theo luồng từ Domain ra ngoài, thay vì viết ngược lại.

3. "Huấn luyện" bằng .cursorrules (Vũ khí tối thượng)

Đây là phần quan trọng nhất của bài hôm nay. File .cursorrules (hoặc .windsurfrules) là nơi anh em ghi lại "di chúc" cho AI. Mọi câu trả lời của AI sẽ phải đi qua bộ lọc này.

Demo một bản .cursorrules cực gắt cho dự án Backend:

# Coding Standards & Architecture
- Bạn là một Kỹ sư Backend kỳ cựu.
- Kiến trúc: Luôn tuân thủ Clean Architecture. Tuyệt đối không gọi Repository trực tiếp từ Controller.
- Dữ liệu: Luôn sử dụng DTO (Data Transfer Object) để nhận request và trả về response.
- Xử lý lỗi: 
  - Không sử dụng try/catch bừa bãi. 
  - Sử dụng Result Pattern (Success/Failure) cho Service layer.
  - Mọi lỗi phải được map về `AppError` class đã định nghĩa ở `@src/core/errors`.
- Quy tắc đặt tên: 
  - Interface bắt đầu bằng chữ 'I' (ví dụ: IUserRepository).
  - File name dùng `kebab-case`.
- Performance: Ưu tiên các giải pháp tối ưu RAM và CPU. Luôn kiểm tra N+1 query khi viết logic liên quan đến Database.

4. Thực chiến: Demo Optimize với một Feature mới

Giả sử mình cần thêm tính năng "Lưu lịch sử hội thoại" vào con ChatApp mà chúng ta build ở bài trước.

Nếu không có .cursorrules: AI sẽ viết code lưu thẳng vào DB ngay trong Controller. Khi đã có .cursorrules: Mình chỉ cần Prompt: "Hãy viết tính năng lưu lịch sử chat".

Kết quả từ AI đã được tối ưu:

Nó tự động tạo một IChatRepository trong layer Infrastructure.
Nó tạo một SaveChatUseCase trong layer Application.
Nó tạo CreateChatDTO để validate đầu vào.
Nó sử dụng đúng class AppError mà mình đã quy định để handle lỗi nếu DB bị sập.

5. Tạm kết bài 5

Anh em thấy đó, Content (Nội dung prompt) chỉ là bề nổi, Optimize (Tối ưu ngữ cảnh) mới là phần chìm giúp AI thực sự hòa nhập vào dự án. Đầu tư 15-20 phút để viết một file .cursorrules tử tế sẽ giúp anh em tiết kiệm hàng giờ đồng hồ review và sửa code sau này.

Hãy nhớ: AI là một đồng nghiệp, không phải là một công cụ thần kỳ. Và đồng nghiệp nào cũng cần được onboard một cách bài bản!

Teaser Bài Tiếp Theo:

Nói về Architecture, có một kiểu kiến trúc cực kỳ "sang chảnh" và giúp hệ thống của anh em cực kỳ linh hoạt (dễ dàng đổi từ DB PostgreSQL sang MongoDB, hay đổi từ REST API sang GraphQL trong vòng 1 nốt nhạc). Đó chính là Hexagonal Architecture (Kiến trúc lục giác).

Ở bài tới, mình sẽ hướng dẫn anh em cách triển khai kiến trúc này cực nhanh với sự trợ giúp của Cursor AI. Chúng ta sẽ cùng nhau "mổ xẻ" các Ports và Adapters để xem tại sao nó lại là chuẩn mực cho các hệ thống hiện đại.

👉 [Series Cursor AI - Bài 6] Hexagonal Architecture và Demo Implementation

Anh em đã thử viết file rules cho riêng mình chưa? Nếu có quy tắc nào "độc lạ" hay ho thì share bên dưới cho mình tham khảo với nhé!