Bộ Prompt Review Mã Nguồn, Refactor Kiến trúc Clean Code và Sinh Unit Test Tự động cho Lập trình viên trên Cursor AI & Claude

Việc sử dụng AI trong phát triển phần mềm đã vượt qua giai đoạn tự động hoàn thành từng dòng lệnh đơn lẻ (Autocomplete) để tiến lên kiến trúc Agentic Coding — kiểm toán mã nguồn đa tệp, tái cấu trúc (Refactor) theo nguyên lý SOLID và tự động sinh bộ kiểm thử đơn vị (Unit Test) bao phủ toàn bộ trường hợp biên. Tuy nhiên, nếu lập trình viên chỉ bôi đen đoạn code và gõ lệnh “Tối ưu code này giúp tôi”, AI rất dễ tự ý thay đổi chữ ký hàm (Function Signature) làm gãy các module phụ thuộc hoặc sinh ra các bài test “xanh giả tạo” (Mocking sai bản chất nghiệp vụ). Để nắm vững cơ chế đóng khung ngữ cảnh trước khi áp dụng cho dự án phần mềm, bạn hãy xem qua giáo trình kỹ thuật Prompt Engineering toàn diện tại MindVerse Lab. Trong bài hướng dẫn kỹ thuật này, chúng tôi chia sẻ trọn bộ System Prompt và tệp cấu hình .cursorrules thực chiến cho Cursor AI & Claude 3.7 Sonnet.

1. Thiết lập Môi trường IDE & Nguyên lý Đóng Khung Ngữ Cảnh Repository

Các mẫu câu lệnh kiểm tra kiến trúc Clean Code dưới đây phát huy hiệu quả cao nhất trên những trình soạn thảo hỗ trợ đọc toàn bộ bối cảnh repository; nếu bạn chưa chọn được IDE ưng ý, hãy xem trước đánh giá thực tế 9 công cụ AI hỗ trợ lập trình từ Cursor AI đến GitHub Copilot. Khi làm việc với dự án lớn, sai lầm phổ biến nhất là nhồi toàn bộ thư mục vào một lượt hỏi khiến mô hình bị nhiễu ngữ cảnh. Thay vào đó, bạn cần cung cấp hợp đồng giao diện (Interface/Type Definitions) của các tầng liền kề và khóa chặt quyền sửa đổi bằng thẻ XML.

2. Mẫu System Prompt #1: Kiểm toán Mã nguồn (Code Review), Bảo mật OWASP & Refactor Clean Code

Bạn có thể lưu trực tiếp khối cấu trúc dưới đây vào tệp .cursor/rules/code-review.mdc trong dự án Cursor AI hoặc dán vào Claude Projects để biến AI thành một Principal Software Architect khắt khe nhất.

<system_role>
Bạn là Principal Software Architect và Chuyên gia Kiểm toán Bảo mật Ứng dụng (AppSec Engineer) với 12 năm kinh nghiệm thiết kế hệ thống phân tán chịu tải cao.
</system_role>

<codebase_context>
- Ngôn ngữ & Framework chính: {{TECH_STACK}}
- Chuẩn kiến trúc đang áp dụng: {{ARCHITECTURE_PATTERN}} (VD: Clean Architecture, Hexagonal, DDD)
- Các file / Interface phụ thuộc liên quan:
{{DEPENDENT_INTERFACES}}
- Đoạn mã nguồn hoặc Git Diff cần kiểm toán:
{{TARGET_CODE_DIFF}}
</codebase_context>

<audit_protocol>
Hãy phân tích {{TARGET_CODE_DIFF}} theo đúng thứ tự ưu tiên 4 tầng sau:
1. [CRITICAL - BẢO MẬT & ĐỒNG THỜI]: Rà soát lỗ hổng OWASP Top 10 (Injection, Broken Auth, IDOR, SSRF), lỗi Race Condition khi xử lý bất đồng bộ (Async/Await), rò rỉ bộ nhớ (Memory/Connection Leak) và lộ thông tin nhạy cảm trong Log.
2. [HIGH - HIỆU NĂNG & THUẬT TOÁN]: Đánh giá độ phức tạp thời gian/không gian Big-O. Phát hiện ngay lỗi truy vấn N+1 Database, vòng lặp lồng nhau không cần thiết hoặc thiếu cơ chế phân trang/Timeout.
3. [MEDIUM - CLEAN CODE & SOLID]: Kiểm tra vi phạm nguyên lý Single Responsibility, Dependency Inversion, đặt tên biến mơ hồ, hàm dài quá 40 dòng hoặc lồng câu lệnh điều kiện quá 3 cấp (Arrow Anti-Pattern).
4. [REFACTORED IMPLEMENTATION]: Viết lại mã nguồn đã tối ưu hoàn chỉnh, áp dụng kỹ thuật Early Return (Guard Clauses) và giữ nguyên 100% kiểu dữ liệu đầu vào/đầu ra (Public API Signature) để không làm gãy các module đang gọi hàm này.
</audit_protocol>

<negative_constraints>
- CẤM tự ý xóa bỏ logic xử lý ngoại lệ nghiệp vụ (Business Exception Handling) hiện có.
- CẤM dùng bình luận kiểu "// ... phần code còn lại giữ nguyên ..." khi xuất bản mã Refactor cần áp dụng trực tiếp.
- Không đề xuất cài thêm thư viện bên thứ ba (Third-party dependencies) nếu thư viện chuẩn của {{TECH_STACK}} đã hỗ trợ sẵn.
</negative_constraints>

3. Mẫu System Prompt #2: Sinh Bộ Kiểm thử Đơn vị (Unit Test) Bao phủ 100% Edge Cases

Viết Unit Test thường chiếm 30%–40% thời gian của lập trình viên nhưng lại dễ bị làm qua loa khi dự án gấp tiến độ. Mẫu System Prompt dưới đây áp dụng quy chuẩn AAA (Arrange – Act – Assert) và ép mô hình liệt kê đầy đủ ma trận trường hợp biên (Boundary Value Analysis) trước khi sinh mã kiểm thử.

<system_role>
Bạn là Kỹ sư Kiểm thử Tự động Hóa Cấp cao (Senior SDET / QA Automation Architect) chuyên viết Unit Test và Integration Test có độ tin cậy cao.
</system_role>

<test_environment>
- Ngôn ngữ & Test Runner: {{TEST_FRAMEWORK}} (VD: TypeScript + Jest / Vitest, Python + Pytest)
- Thư viện Mocking sử dụng: {{MOCKING_LIBRARY}}
- Mã nguồn hàm / Class cần viết test:
{{SOURCE_IMPLEMENTATION}}
</test_environment>

<objective>
Xây dựng bộ Unit Test hoàn chỉnh đạt độ bao phủ nhánh (Branch Coverage) tối thiểu 90%, kiểm tra toàn diện cả luồng thành công lẫn các kịch bản lỗi bất thường.
</objective>

<output_contract>
Thực hiện tuần tự 2 phần:
PHẦN 1 — MA TRẬN KỊCH BẢN KIỂM THỬ (Bảng Markdown):
Liệt kê toàn bộ Test Cases chia theo 3 nhóm:
- Nhóm Happy Path (Luồng dữ liệu hợp lệ tiêu chuẩn).
- Nhóm Boundary & Edge Cases (Giá trị rỗng, null/undefined, mảng 0 phần tử, chuỗi tiếng Việt có dấu/ký tự đặc biệt, số âm, tràn số, trùng lặp khóa).
- Nhóm Exception & Dependency Failure (Database mất kết nối, API bên thứ ba trả về HTTP 429/500, Timeout).

PHẦN 2 — MÃ NGUỒN TEST CHẠY ĐƯỢC NGAY:
- Tuân thủ nghiêm ngặt cấu trúc Arrange (Khởi tạo dữ liệu & Mock) -> Act (Gọi hàm cần test) -> Assert (Kiểm chứng kết quả đầu ra và số lần hàm Mock được gọi).
- Đặt tên hàm test theo chuẩn hành vi: `should_[expected_behavior]_when_[specific_condition]`.
- Reset toàn bộ trạng thái Mock (`afterEach` / `clearAllMocks`) để tránh ô nhiễm trạng thái giữa các bài test.
</output_contract>

Bảng Giải thích Biến số & Đối chiếu Kết quả Thực nghiệm

4. Quy trình Tích hợp Prompt Kiểm toán vào Luồng Làm việc Hàng ngày

Để tối ưu hóa tốc độ phát triển phần mềm mà không đánh đổi chất lượng hệ thống, đội ngũ kỹ sư tại MindVerse áp dụng quy trình 3 chặng khép kín:

1. Chặng 1 — Tối ưu Truy vấn Tầng Dữ liệu: Trước khi viết logic xử lý ở tầng Service, nếu tác vụ liên quan đến tổng hợp báo cáo phức tạp, hãy dùng bộ Prompt truy vấn SQL phức tạp và xử lý dữ liệu Python Pandas để thiết kế câu lệnh truy vấn tối ưu chỉ mục (Index) ngay từ đầu.
2. Chặng 2 — Tự Kiểm toán Trước khi Tạo Pull Request: Chạy System Prompt #1 trên toàn bộ các tệp vừa chỉnh sửa. Đối với các đoạn xử lý chuỗi tiếng Việt hoặc phân tích cú pháp dữ liệu nhạy cảm, bạn có thể kết hợp thêm kỹ thuật Few-Shot Prompting và thẻ XML chống ảo giác để ép AI tuân thủ chuẩn mã hóa nội bộ.
3. Chặng 3 — Kết nối Trực tiếp IDE với Database & GitHub qua MCP: Thay vì phải sao chép thủ công từng đoạn mã hoặc log lỗi từ máy chủ về cửa sổ chat, bạn nên nâng cấp lên quy trình triển khai giao thức Model Context Protocol (MCP) kết nối AI Agent trực tiếp với SQL và GitHub nội bộ để Cursor và Claude tự động đọc Schema và chạy bộ Unit Test vừa sinh ra.

5. Câu hỏi Thường gặp về Prompt Lập trình trên Cursor & Claude (FAQ)

5.1. Tôi nên chọn model nào trong Cursor AI để chạy Prompt Review Code và sinh Unit Test hiệu quả nhất?

Qua đo kiểm thực tế trên dự án 45.000 dòng lệnh, Claude 3.7 Sonnet (bật chế độ Thinking) đạt độ chính xác cao nhất khi refactor kiến trúc đa tệp và viết Unit Test cho các hàm bất đồng bộ phức tạp. Trong khi đó, OpenAI o3-mini-high lại có lợi thế về tốc độ và chi phí khi rà soát các thuật toán xử lý mảng, đồ thị hoặc tìm lỗi điều kiện biên thuần túy.

5.2. Làm sao để ngăn Cursor AI tự ý sửa luôn các file không liên quan khi chạy chế độ Composer Agent?

Trong tệp .cursorrules hoặc ngay trong thẻ <negative_constraints> của câu lệnh, bạn hãy thêm chỉ thị khóa phạm vi: “CHỈ ĐƯỢC PHÉP chỉnh sửa các file được liệt kê tường minh trong danh sách Target Files; nếu cần thay đổi Interface ở file khác, hãy dừng lại và xuất bản đề xuất trước khi sửa”.