Bài 4 — Claude Code & Aider: agent trong terminal

Đã đọc 0/13 mục · còn khoảng 5 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.

Khi công việc là "giao nhiệm vụ đa bước" chứ không phải "gõ từng dòng", agent CLI tỏa sáng. Bài này đi sâu Claude Code và Aider.

Claude Code — agent terminal đa năng

Điểm mạnh: đọc/sửa nhiều file, chạy lệnh (test, build, git), tự lặp vòng phản hồi cho tới khi đạt tiêu chí, và hiểu ngữ cảnh dự án qua file hướng dẫn. Nó không ràng buộc IDE — chạy ở bất kỳ terminal nào, dễ đưa vào script/CI.

Khi nào dùng: sửa bug xuyên nhiều file, viết feature kèm test, chạy tác vụ có bước kiểm chứng ("làm cho tới khi test pass"), hoặc tự động hóa quy trình lặp.

Các bước bắt đầu

Cài Claude Code CLI và xác thực tài khoản.
cd vào thư mục dự án (đã là git repo).
Tạo file hướng dẫn dự án để agent luôn nắm quy ước.
Giao nhiệm vụ có tiêu chí thành công rõ ràng.

Dự án dùng pytest, black để format, và Conventional Commits.
Hãy thêm endpoint POST /login (JWT), viết test, chạy test cho pass,
rồi format lại bằng black.

Mẹo: đặt "tiêu chí thành công" ở cuối lệnh ("test pass", "lint sạch") để agent có mốc dừng.

Aider — agent CLI gắn chặt git

Điểm mạnh: mỗi thay đổi là một commit git, cực kỳ minh bạch và dễ rollback; cho chọn model tùy ý (kể cả tự host), tối ưu chi phí token; và cách thêm file vào phiên làm việc rất rõ ràng.

Khi nào dùng: bạn muốn kiểm soát chi phí và model, cần lịch sử commit sạch để review, hoặc làm việc trên máy cần minh bạch tuyệt đối.

Các bước dùng Aider

Cài Aider và đặt API key của nhà cung cấp model bạn chọn.
Trong repo git, chạy aider và thêm đúng file cần sửa vào phiên.
Ra lệnh; xem Aider sửa và tự tạo commit.
Dùng git diff/git log để review; hoàn tác dễ dàng nếu cần.

aider services/payment.py tests/test_payment.py
# > "Thêm retry 3 lần cho gọi cổng thanh toán, kèm test"
# Aider sửa + commit: "feat: add retry to payment gateway call"

Khung tư duy: Vòng lặp Giao – Chạy – Kiểm – Sửa

Giao: mô tả task + tiêu chí thành công.
Chạy: agent sửa và chạy lệnh.
Kiểm: agent đọc kết quả (lỗi test, lint).
Sửa: lặp lại tới khi đạt. Vai trò của bạn là review kết quả cuối, không phải gõ từng dòng.

Checklist trước khi giao việc cho agent CLI

[ ] Repo đã là git và sạch (không kẹt thay đổi chưa commit)?
[ ] Có lệnh kiểm chứng tự động (test/lint) không?
[ ] Đã nêu tiêu chí thành công rõ ràng?
[ ] Chỉ thêm đúng file liên quan vào ngữ cảnh (đặc biệt với Aider)?

Sai lầm thường gặp

Chạy agent trên repo bẩn: khó phân biệt thay đổi của bạn và của agent; luôn commit trước.
Không có tiêu chí dừng: agent không biết khi nào là xong, dễ sửa lan man.
Đưa cả trăm file vào ngữ cảnh Aider: tốn token và làm loãng ngữ cảnh; chỉ thêm file cần thiết.
Bỏ qua review diff: minh bạch chỉ có giá trị nếu bạn thật sự đọc git diff trước khi push.

Vì sao agent CLI mạnh: vòng phản hồi

Điểm mạnh thật sự của agent terminal không phải "sửa nhiều file" — mà là nó chạy được lệnh và đọc được kết quả. Điều đó biến quá trình từ đoán thành thử:

Đọc code, sửa.
Chạy test.
Đọc lỗi.
Sửa lại.
Lặp cho tới khi pass.

Một agent làm được vòng này tự phát hiện sai sót của mình. Một agent chỉ sinh văn bản thì không — nó đưa bạn code trông đúng và để bạn tìm ra chỗ sai.

Hệ quả quan trọng: giá trị của agent CLI tỉ lệ thuận với chất lượng test của bạn. Dự án không có test thì agent mất vòng phản hồi và trở về mức "đoán có ngữ cảnh". Nếu bạn muốn dùng agent hiệu quả, đầu tư vào test có lợi tức cao hơn đầu tư vào gói cao cấp hơn.

Viết yêu cầu cho agent: bốn phần

Yêu cầu tốt cho agent khác yêu cầu cho chat. Nó cần bốn phần:

Phần	Ví dụ
Mục tiêu	"Thêm endpoint đăng nhập bằng email + mật khẩu"
Tiêu chí xong	"Test `tests/auth_test.py` pass, không sửa file nào trong `legacy/`"
Khuôn mẫu	"Làm theo cùng cấu trúc với `api/register.py`"
Ràng buộc	"Không thêm thư viện mới; dùng thư viện đã có trong requirements"

Phần "tiêu chí xong" là phần quyết định. Không có nó, agent tự quyết định lúc nào dừng — và nó thường dừng sớm (code chạy được nhưng thiếu ca biên) hoặc quá muộn (sửa cả những thứ bạn không nhờ).

Phần "ràng buộc" chặn hành vi tốn kém nhất: agent thêm một thư viện mới để giải một việc nhỏ.

Ba chỗ agent hay đi chệch

Hành vi	Biểu hiện	Cách chặn
Sửa test thay vì sửa code	Test pass nhưng logic vẫn sai	Ghi rõ: "không được sửa file test"
Mở rộng phạm vi	Nhân tiện refactor 5 file khác	Ghi rõ vùng được phép sửa
Thêm phụ thuộc mới	Cài thư viện cho một việc 20 dòng	Ràng buộc trong yêu cầu

Hàng đầu là hành vi nguy hiểm nhất và dễ bỏ qua nhất: bạn thấy "test pass" và tin là xong, trong khi agent đã nới lỏng chính bài kiểm tra.

An toàn khi agent chạy được lệnh

Agent chạy lệnh nghĩa là nó có thể xoá file, đổi nhánh git, gọi mạng. Ba rào tối thiểu:

Làm việc trên nhánh riêng, luôn luôn. Mọi thay đổi thấy được qua diff, hoàn tác bằng một lệnh.
Commit trước khi giao việc. Đây là cách hoàn tác đáng tin duy nhất.
Không đưa khoá bí mật vào môi trường agent nếu không cần. Nếu cần, dùng khoá phạm vi hẹp, không phải khoá production.

Làm ngay

Lấy một việc nhỏ và viết yêu cầu cho agent theo bốn phần ở trên, đặc biệt là "tiêu chí xong". Sau khi agent báo xong, kiểm riêng một điều: file test có bị sửa không? Đó là kiểm tra nhanh nhất để biết "pass" có nghĩa gì.

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