Bài 6 — Ma trận so sánh & khung chọn công cụ theo tình huống

Đã đọc 0/12 mục · còn khoảng 4 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Bài này gom mọi thứ thành một khung ra quyết định dùng được ngay. Không có công cụ "tốt nhất" — chỉ có công cụ đúng cho tình huống.

Ma trận nhanh theo 5 tiêu chí

Công cụ	Hình thái	Mức tự chủ	Ngữ cảnh codebase	Điểm mạnh nhất
Copilot	Plugin IDE	Thấp	Cục bộ quanh con trỏ	Autocomplete khi gõ
Cursor	IDE	Trung–cao	Toàn dự án (index + @)	Edit đa file trong IDE
Windsurf	IDE	Trung–cao	Toàn dự án (Cascade)	Agent mượt, tự theo ngữ cảnh
Claude Code	CLI	Cao	Toàn dự án + chạy lệnh	Task agentic đa bước, tự lặp
Aider	CLI	Cao	File thêm vào phiên	Minh bạch, commit từng bước, chọn model
Devin	Sandbox	Rất cao	Repo trong môi trường riêng	Chạy nền tự chủ ra PR

Khung quyết định 4 câu hỏi

Phạm vi? Một dòng/hàm -> Copilot. Nhiều file -> Cursor/Windsurf/Claude Code/Aider. Cả một task issue -> Devin.
Bạn muốn ngồi đâu? Editor -> Copilot; IDE AI-first -> Cursor/Windsurf; terminal -> Claude Code/Aider; ngoài cuộc -> Devin.
Cần minh bạch/kiểm soát tới đâu? Commit từng bước -> Aider; review diff trong IDE -> Cursor/Windsurf; giao trọn + review PR -> Devin.
Ràng buộc chi phí/bảo mật? Thuê bao cố định -> Copilot/Cursor/Windsurf; trả theo token, chọn/tự host model -> Aider; ngân sách cao cho task nền -> Devin.

Ví dụ áp dụng khung

"Viết CRUD cho một entity mới, gõ nhanh" -> Copilot (hoặc autocomplete của Cursor).
"Refactor tên biến xuyên 12 file" -> Cursor/Windsurf (xem diff) hoặc Claude Code.
"Sửa bug cần chạy test lặp lại" -> Claude Code hoặc Aider.
"Cần lịch sử commit sạch để audit" -> Aider.
"Nâng cấp thư viện toàn repo, chạy nền" -> Devin.
"Code nội bộ nhạy cảm, muốn tự host model" -> Aider.

Chiến lược kết hợp (stack thực tế)

Nhiều đội không chọn một, mà kết hợp:

Autocomplete khi gõ:     Copilot (hoặc autocomplete của IDE)
Refactor / task vừa:     Cursor hoặc Windsurf
Task agentic đa bước:    Claude Code hoặc Aider
Task nền tự chủ:         Devin (chọn lọc)

Checklist ra quyết định cuối

[ ] Đã trả lời 4 câu hỏi khung ở trên chưa?
[ ] Đã cân nhắc chi phí chuyển đổi (đổi IDE, đào tạo team) chưa?
[ ] Đã kiểm tra chính sách dữ liệu/bảo mật của công cụ chưa?
[ ] Có cách kiểm chứng chất lượng output (test/review) chưa?

Sai lầm thường gặp

Tìm "một công cụ cho mọi việc": dẫn tới ép công cụ làm việc không hợp.
Chọn theo hype/benchmark thay vì tình huống thật của bạn.
Quên chi phí ẩn: đào tạo, đổi IDE, thời gian review đều là chi phí.
Bỏ qua bảo mật: công cụ mạnh nhất mà vi phạm chính sách dữ liệu là không dùng được.

Khung chọn theo ba câu hỏi, không theo bảng

Bảng ma trận ở trên hữu ích nhưng sẽ lỗi thời. Khung ba câu thì không:

Câu 1 — Việc này có tiêu chí xong kiểm được bằng máy không? Có → agent CLI hoặc agent mode. Không → chat/edit trong IDE, để bạn phán đoán từng bước.

Câu 2 — Tôi có biết code cần sửa ở đâu không? Biết → chỉ file trực tiếp, dùng chat/edit. Không biết → dùng công cụ có ngữ cảnh toàn dự án để hỏi trước, rồi mới sửa.

Câu 3 — Nếu nó làm sai, tôi phát hiện bằng cách nào? Có test → tự chủ cao được. Không có cách kiểm tự động → bạn phải ngồi xem từng bước, nên chọn công cụ trong luồng.

Ba câu này chọn đúng công cụ cho mọi tình huống, kể cả với công cụ chưa ra mắt.

Chọn stack: hai công cụ là đủ

Đừng dùng năm công cụ. Cấu hình phổ biến và đủ dùng:

Thành phần	Việc gì	Vì sao cần
Một công cụ trong luồng (autocomplete + chat)	80% thời gian gõ code	Nhanh, rủi ro thấp
Một agent có thể chạy lệnh	Việc nhiều bước có tiêu chí kiểm	Vòng phản hồi

Thêm công cụ thứ ba chỉ có nghĩa khi nó làm được việc hai công cụ trên không làm được — không phải khi nó làm cùng việc theo cách khác.

Chi phí ẩn của stack phức tạp: mỗi công cụ có cấu hình ngữ cảnh riêng. Dùng ba IDE nghĩa là duy trì ba bộ cấu hình, và chúng sẽ lệch nhau.

Cái bẫy "công cụ tốt nhất"

Trong thử nghiệm thật, khác biệt giữa hai công cụ hàng đầu thường nhỏ hơn khác biệt do:

Chất lượng test của dự án bạn
Chất lượng file hướng dẫn ngữ cảnh bạn viết
Cách bạn viết yêu cầu
Việc bạn chọn giao cho nó

Bốn yếu tố này đều nằm ở phía bạn, và đều cải thiện được. Đầu tư vào chúng cho lợi tức cao hơn nhiều so với việc đổi công cụ.

Đo năng suất thật, không đo cảm giác

Cảm giác "nhanh hơn" khi dùng AI rất mạnh và không đáng tin. Đo bốn thứ trong hai tuần:

Thước đo	Dấu hiệu tốt
Thời gian từ bắt đầu đến merge	Giảm
Số lỗi phát hiện sau merge	Không tăng
Số dòng bạn phải sửa lại sau khi AI viết	Giảm theo thời gian
Bạn hiểu code trong dự án ở mức nào	Không giảm

Dòng thứ hai là dòng quan trọng nhất. Viết code nhanh gấp đôi mà lỗi sản xuất tăng gấp ba là lùi, không phải tiến.

Làm ngay

Áp ba câu hỏi ở trên cho ba việc tiếp theo trong danh sách của bạn, và ghi lại công cụ mà khung chỉ ra. Nếu cả ba đều chỉ về cùng một công cụ, stack của bạn có thể đơn giản hơn bạn tưởng.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi