Muốn Claude Code tự xử lý công việc mà không cần bạn ngồi canh, bạn phải cho nó cách tự kiểm tra kết quả: viết code, chạy thử, đọc output rồi lặp lại cho đến khi đạt yêu cầu.
Đây là phần năm trong loạt bài giới thiệu 50 mẹo Claude Code từ repo claude-code-tips của YK Sugi. Phần này tập trung vào năm mẹo về kiểm chứng, gồm các mẹo số 9, 26, 34, 24 và 48. Các mẹo trải dài từ cách để Claude tự kiểm tra code mình viết đến cách review một lượng code lớn mà không cần đọc từng dòng.
Càng giao nhiều việc cho Claude, bạn càng cần chú trọng khâu kiểm chứng để biết kết quả có đáng tin hay không.
Vì sao tác vụ tự động cần vòng lặp viết, chạy và kiểm tra?
Nếu không có cách kiểm tra, Claude sẽ không biết mình đã hoàn thành công việc hay chưa. Chẳng hạn, trong repo phát triển chính Claude Code, bạn phát hiện /compact đột nhiên trả về lỗi 400. Công cụ quen thuộc để tìm commit gây ra lỗi là git bisect. Bạn hoàn toàn có thể để Claude Code tự chạy bisect, miễn là nó biết cách kiểm tra từng commit.
Với những công cụ có giao diện terminal tương tác như Claude Code, bạn có thể dùng tmux để kiểm tra: mở một phiên tmux, gửi lệnh vào, chụp output rồi đối chiếu với kết quả mong đợi. Đoạn script dưới đây kiểm tra xem /context có chạy được hay không:
tmux kill-session -t test-session 2>/dev/null
tmux new-session -d -s test-session
tmux send-keys -t test-session 'claude' Enter
sleep 2
tmux send-keys -t test-session '/context' Enter
sleep 1
tmux capture-pane -t test-session -pKhi đã có bài kiểm tra như vậy, Claude Code có thể chạy git bisect, tự kiểm tra từng commit và tìm ra commit gây lỗi. Ví dụ này cũng cho thấy kiến thức về kỹ thuật phần mềm vẫn rất quan trọng. Nếu bạn biết git bisect, kiến thức đó vẫn hữu ích khi làm việc với AI, chỉ là cách áp dụng đã khác trước. Với những trường hợp phổ biến hơn, bạn có thể đơn giản yêu cầu Claude viết test cho code vừa tạo, tự chạy test rồi sửa code nếu cần. Claude không phải lúc nào cũng đi đúng hướng, nên bạn vẫn cần giám sát, nhưng khả năng tự xử lý công việc của nó có thể vượt xa những gì bạn nghĩ.
Kiểm thử web app nên dùng Playwright MCP hay /chrome?
Với phần lớn tác vụ kiểm thử web không đòi hỏi xử lý hình ảnh nhiều, Playwright MCP thường hoạt động tốt hơn tích hợp Chrome gốc của Claude thông qua /chrome. Chrome DevTools MCP cũng là một lựa chọn, nhưng tác giả repo chưa thử công cụ này. Khác biệt chính giữa hai công cụ nằm ở cách chúng đọc và tương tác với trang web:
| Tiêu chí | Playwright MCP | Tích hợp Chrome gốc (/chrome) |
|---|---|---|
| Cách đọc trang | Cây trợ năng (accessibility tree), dữ liệu có cấu trúc | Chụp màn hình, bấm theo tọa độ |
| Tốc độ, độ ổn định | Ổn định hơn | Chậm, đôi khi bấm nhầm chỗ |
| Chi phí context | Tốn nhiều context, nhưng 200k thường đủ cho một vài tác vụ | Tuỳ số ảnh chụp |
| Nên dùng khi | Hầu hết tác vụ kiểm thử web | Cần trạng thái đã đăng nhập (dùng chính profile trình duyệt của bạn) hoặc phải bấm theo vị trí trên màn hình |
Vì vậy, tác giả tắt tích hợp Chrome gốc theo mặc định và chỉ bật khi cần thông qua alias ch (đã giới thiệu ở phần một). Ngay cả khi dùng Chrome gốc, bạn vẫn có thể yêu cầu Claude xác định phần tử bằng tham chiếu trong cây trợ năng thay vì dựa vào tọa độ. Đây là đoạn cấu hình trong file CLAUDE.md của tác giả:
# Claude for Chrome
- Use `read_page` to get element refs from the accessibility tree
- Use `find` to locate elements by description
- Click/interact using `ref`, not coordinates
- NEVER take screenshots unless explicitly requested by the userTích hợp Chrome gốc còn hai vấn đề đã được báo cáo: đôi khi không chọn được trình duyệt trên máy cục bộ (issue #74667), và không thể bật từ một phiên Remote Control, chẳng hạn khi bạn làm việc bằng điện thoại (issue #74671). Để giải quyết cả hai vấn đề, tác giả phát triển Browser Bridge, một giải pháp mã nguồn mở thay thế. Nếu chưa quen với MCP, bạn có thể đọc bài MCP là gì để tìm hiểu từ đầu.
Khi môi trường test khó dựng thì làm sao?
Bạn cần tìm cách khép kín vòng kiểm tra, đồng thời để Claude Code xử lý các công việc thực thi. Ví dụ đầu tiên là khi tác giả làm việc với thư viện Python Daft, vốn có backend viết bằng Rust. Tác giả cần thử một bản build cục bộ trên Google Colab, nhưng việc build thư viện Python có kèm Rust ngay trên Colab gần như không khả thi. Giải pháp là build file wheel trên máy cá nhân rồi tải thủ công lên Colab. Trong lúc chờ wheel build xong, monkey patching (vá tạm hành vi khi chạy) giúp giải quyết vấn đề trước mắt.
Ví dụ thứ hai là kiểm tra một vấn đề trên Windows khi không có máy Windows để sử dụng. CI của repo đang lỗi do vấn đề liên quan đến Rust trên Windows, nên tác giả không có cách nào kiểm tra trực tiếp trên máy cục bộ. Giải pháp là tạo một draft PR chứa toàn bộ thay đổi, sau đó tạo thêm một draft PR với cùng thay đổi nhưng bật CI Windows cho các nhánh không phải main. Nhờ vậy, tác giả có thể kiểm tra trực tiếp trên nhánh mới. Claude Code thực hiện toàn bộ việc tạo PR và chỉnh sửa workflow theo hướng dẫn.
Trong cả hai trường hợp, con người nghĩ ra chiến lược kiểm tra, còn Claude Code đảm nhận phần thực thi thông qua quá trình trao đổi qua lại. Đây chính là lúc kinh nghiệm của bạn phát huy giá trị lớn nhất.
Có những cách nào kiểm chứng output của Claude?
Có nhiều cách hơn bạn nghĩ, và tốt nhất là kết hợp chúng. Với code, có bốn cách chính: yêu cầu Claude viết test rồi tự đánh giá xem test có hợp lý không; đọc code ngay trên giao diện Claude Code trong lúc nó viết; dùng một Git client trực quan như GitHub Desktop để xem nhanh các thay đổi (theo nhận xét của tác giả, cách này "không hoàn hảo, nhưng đủ tốt"); hoặc yêu cầu Claude tạo draft PR để bạn kiểm tra trước khi chuyển thành PR chính thức.
Một cách khác là yêu cầu Claude tự rà soát lại công việc của mình. Khi nhận được kết quả, chẳng hạn sau một đợt nghiên cứu, bạn có thể hỏi: "Bạn chắc chứ? Kiểm tra lại được không?". Prompt mà tác giả repo yêu thích, và theo tôi cũng là một trong những prompt đáng lưu lại nhất trong cả series, là:
double check everything, every single claim in what you produced and at the end make a table of what you were able to verify
Bảng ở cuối mới là phần thực sự hữu ích. Nó buộc Claude phân biệt rõ những gì đã kiểm chứng được với những gì còn chưa chắc chắn, thay vì chỉ trả lời chung chung rằng mọi thứ đều ổn.
TDD với Claude Code chạy thế nào?
Code càng nhiều thì nguy cơ phát sinh lỗi càng cao, và test càng trở nên quan trọng khi codebase lớn dần. Một số người cho rằng AI không thể tự kiểm tra công việc của mình, nhưng trên thực tế, AI làm được điều đó theo cách tương tự con người: khi viết test, bạn nhìn vấn đề từ một góc độ khác, và AI cũng có thể làm như vậy. Phát triển hướng kiểm thử (Test-Driven Development, TDD) rất phù hợp với Claude Code. Bạn có thể thực hiện theo bốn bước:
- Viết test trước.
- Đảm bảo test đang fail.
- Commit các test đó.
- Viết code cho đến khi test pass.
Viết test sao cho chúng fail trước, rồi commit test trước khi bắt tay vào viết code, giúp xác định rõ code cần đáp ứng những yêu cầu nào. Claude có mục tiêu cụ thể để hướng tới, còn bạn có thể chạy test để kiểm tra xem phần triển khai có đúng hay không. Để chắc chắn hơn, hãy tự đọc lại test và đảm bảo chúng không có những lỗi ngớ ngẩn, chẳng hạn luôn return true. Bài TDD giúp AI viết code tốt hơn giải thích kỹ hơn về cách làm này.
Review PR theo kiểu hội thoại ra sao?
Bạn có thể yêu cầu Claude Code lấy thông tin PR bằng lệnh gh, sau đó review theo cách mình muốn, từ lướt qua toàn bộ PR đến xem lần lượt từng file. Bạn chủ động quyết định tốc độ, mức độ chi tiết và độ sâu của quá trình review. Có lúc bạn chỉ cần nắm cấu trúc tổng thể, nhưng cũng có lúc muốn Claude chạy test ngay.
Điểm hay là Claude Code có thể trò chuyện với bạn trong vai trò người review, thay vì chỉ chạy một lượt rồi đưa ra kết quả cuối cùng. Một số công cụ AI làm khá tốt việc review một lần, kể cả các model GPT mới nhất, nhưng với Claude Code, bạn có thể hỏi tiếp, đào sâu vào những điểm đáng ngờ hoặc bỏ qua những phần không quan trọng.
Review code qua tài liệu TESTING.md là gì?
Khi phải review một lượng code lớn, dù đó là code do Claude Code viết, PR của đồng nghiệp hay PR từ bên ngoài, khó nhất là hiểu được toàn bộ những gì đang diễn ra và xác định xem chúng có đúng hay không. Đọc code là một cách, viết test là một cách khác. Nhưng bạn còn có thể tiếp cận ở cấp độ cao hơn: yêu cầu Claude Code kiểm thử kỹ toàn bộ phần code, ghi lại các bước kiểm tra và kết quả xác minh vào file TESTING.md, rồi review file này thay vì phải đọc hết code.
Bạn có thể yêu cầu Claude điều chỉnh định dạng cho dễ đọc hơn: nếu nội dung quá dài, hãy bảo nó rút gọn; nếu quá ngắn, hãy yêu cầu bổ sung chi tiết; nếu có thuật ngữ khó hiểu, hãy nhờ nó giải thích hoặc diễn đạt đơn giản hơn. File TESTING.md thực tế trong repo bắt đầu từ quá trình review một PR bên ngoài. Claude Code tái hiện lỗi trên một runner Windows thực trong GitHub Actions, kiểm chứng bản sửa rồi tóm tắt toàn bộ những gì đã kiểm thử.
Hiện tại, file này đã trở thành nhật ký kiểm thử được cập nhật liên tục. Mỗi lần review, Claude thêm một mục mới lên đầu file. Vì được lưu trong git, file cung cấp lịch sử về cách từng thay đổi được kiểm tra. Khi có người hỏi "làm sao biết nó chạy đúng?", bạn chỉ cần đưa họ xem file này. Theo tôi, đây là bước nâng cấp tự nhiên cho những ai đã quen dùng AI để review PR: thay vì chỉ đọc diff, bạn chuyển sang xem bằng chứng kiểm thử.
Nên bắt đầu kiểm chứng từ đâu?
Hãy bắt đầu với prompt "double check every single claim" và yêu cầu Claude lập bảng kiểm chứng ở cuối. Cách này áp dụng được ngay cho cả code lẫn nghiên cứu. Khi đã quen, bạn có thể chuyển dần sang TDD đối với những phần code quan trọng, đồng thời dùng TESTING.md cho các PR lớn đến mức bạn không thể đọc hết diff.