Khi chúng ta giao phó nhiều nhiệm vụ phức tạp hơn cho Claude, việc nó có thể tự kiểm tra công việc của mình ngày càng trở nên quan trọng.
Càng có khả năng tự kiểm tra, Claude sẽ:
- làm việc độc lập hơn trong các tác vụ kéo dài
- đem lại kết quả cuối cùng có chất lượng tốt hơn
- giảm số lần phải qua lại để đạt được kết quả
Khi các bước kiểm tra phụ thuộc vào bạn, các phiên lập trình trở thành một trò chơi theo lượt, và bạn đánh mất thứ làm nên giá trị của các tác nhân: tính tự động.
Tin tốt là Claude đã có thể tự kiểm tra dựa trên các tín hiệu xác định như lỗi kiểu dữ liệu, lỗi lint, các bài kiểm tra thất bại và lỗi runtime. Và khi các mô hình ngày càng cải thiện, điều này sẽ chỉ trở nên tốt hơn.
Điều Claude không phải lúc nào cũng suy luận được là các bước kiểm tra thủ công bạn chạy sau khi nó phản hồi, và sau đó, trước khi bạn hợp nhất mã nguồn vào môi trường sản phẩm.
Bạn càng mã hóa được nhiều bước kiểm tra đó, thì phản hồi đầu tiên của Claude càng gần với kết quả cuối cùng bạn mong muốn.
Bạn dành ít thời gian giám sát hơn, và Claude có thể tiếp tục làm việc trong khi bạn làm việc khác.
Viết ra quy trình của bạn
Một điểm khởi đầu tốt là viết ra phiên bản thực hành tốt nhất của những gì bạn hoặc nhóm của bạn đã làm.
Đối với giao diện người dùng (frontend), đó thường là: chạy máy chủ phát triển (dev server), mở trình duyệt, kiểm tra bảng điều khiển (console) xem có lỗi không, nhấp xung quanh như người dùng sẽ làm và để ý những thứ như thay đổi bố cục (layout shift) hoặc điều hướng chậm (slow navigations).
Mỗi lĩnh vực đều có phiên bản riêng. Đối với mỗi bước đó, thường có một công cụ Claude có thể sử dụng để xác minh:
Mã hóa quy trình của bạn thành một kỹ năng (skill)
Khi quy trình đã rõ ràng, hãy mã hóa càng nhiều càng tốt thành một kỹ năng. Cài đặt plugin \skill-creator\, sau đó yêu cầu Claude phỏng vấn bạn:
1/skill-creator Tạo một kỹ năng để xác minh các thay đổi giao diện người dùng (frontend) từ đầu đến cuối (end-to-end). Hãy phỏng vấn tôi về quy trình làm việc của tôi.
Nếu bạn gặp khó khăn trong việc diễn đạt quy trình của mình, hãy yêu cầu Claude cung cấp các thực hành tốt nhất cho lĩnh vực đó trước và để nó chỉ cho bạn thấy một luồng xác minh từ đầu đến cuối (end-to-end) có thể trông như thế nào.
Cảm quan và khả năng phán đoán rất khó để hệ thống hóa, nhưng nhiều bước kiểm tra có các tiêu chí Claude có thể đo lường dựa trên: ngân sách hiệu suất (performance budget), danh sách kiểm tra khả năng tiếp cận (accessibility checklist), quy tắc hệ thống thiết kế (design system rules), các ví dụ tốt và xấu.
Ví dụ: một kỹ năng giao diện người dùng (frontend) có thể bao gồm hướng dẫn chụp dấu vết hiệu suất (performance trace) thông qua Chrome DevTools MCP hoặc Agent browser.
1---2name: frontend-verify3description: Xác minh các thay đổi giao diện người dùng (frontend) trong trình duyệt. Chạy bất cứ khi nào thực hiện thay đổi giao diện người dùng (UI) (trang, thành phần, kiểu chữ, kiểu CSS).4---56# Xác minh giao diện người dùng (frontend)78- Chạy một lượt xác minh hai bước trong trình duyệt thực tế.9- Sửa lỗi và xác minh lại trước khi phản hồi người dùng.1011## Bước 1 — Xác minh thay đổi hoạt động như mong đợi12131. Mở URL trong trình duyệt:14 - Trong ứng dụng desktop Claude Code, sử dụng chế độ xem trước (preview) được nhúng.15 - Trong CLI, sử dụng Chrome DevTools MCP.162. Tương tác với phần tử mới và xác nhận nó hiển thị và hoạt động như mong đợi.1718## Bước 2 — Xác minh thay đổi vượt qua kiểm tra di động19201. Mở URL trong một trang mới qua Chrome DevTools MCP212. Chạy một bản ghi dấu vết hiệu suất (performance trace) và kiểm tra Core Web Vitals
Các bước kiểm tra khác mang tính định tính hơn là đậu/rớt, như so sánh dữ liệu với các chỉ tiêu lịch sử. Đối với những trường hợp này, bạn có thể làm việc với Claude để thiết lập một tiêu chí đánh giá (rubric) cho đầu ra.
Xem lại mã nguồn trước khi hợp nhất với một tác nhân thứ hai
Mọi thứ ở trên đều diễn ra bên trong vòng lặp tác nhân (agentic loop). Có một bước xác minh thứ hai, ngay trước khi bạn hợp nhất, nơi bạn có thể yêu cầu một tác nhân khác xem xét lại.
Một tác nhân mới sẽ không mang cùng những thiên kiến (biases) như tác nhân đã viết mã nguồn. Nó có ngữ cảnh riêng của nó và không bị ảnh hưởng bởi cuộc trò chuyện trước đó. Sự cô lập này giúp việc xem xét trở nên trung thực hơn và phát hiện ra những điều mà tác nhân đầu tiên có thể đã bỏ sót.
Một vài lựa chọn, từ thủ công đến tự động:
- /review (kỹ năng tích hợp sẵn) - đọc nhanh một lượt một Pull Request (PR) trong terminal của bạn.
- /code-review (plugin có thể cài đặt) - khởi chạy song song nhiều tác nhản phụ, mỗi tác nhân đọc bản diff từ một góc nhìn khác nhau, chấm điểm các phát hiện dựa trên độ tin cậy và đăng kết quả lên PR.
- Claude Code Review - một dịch vụ được quản lý, tự động chạy trên mỗi PR thông qua GitHub, dành cho các gói Team và Enterprise.
Dù bạn chọn cách nào, việc có một lớp phòng thủ cuối cùng trước khi hợp nhất vào môi trường sản phẩm là rất hữu ích.
Tổng hợp lại
Bây giờ bạn có hai lớp:
- xác minh diễn ra trong khi Claude đang xây dựng
- xem xét trước khi hợp nhất từ một tác nhân không viết mã nguồn.
Cả hai đều thuộc cùng một vòng đời phát triển. Hãy nghĩ về các bước thủ công hiện tại của bạn: bạn thực hiện một thay đổi, dọn dẹp nó, xác nhận nó hoạt động, commit, mở một PR, được xem xét và theo dõi CI.
Bạn có thể kết hợp tất cả các bước đó thành một quy trình làm việc duy nhất bằng cách viết một kỹ năng gọi các kỹ năng khác. Ví dụ, nhóm Claude Code có một kỹ năng họ chạy khi làm việc trên các tính năng, nó kết hợp:
- Kỹ năng \
/simplify\để dọn dẹp bản diff - Một kỹ năng \
/verify\tùy chỉnh để xác nhận thay đổi hoạt động từ đầu đến cuối (end-to-end) - Một kiểm tra thiết kế nếu bản diff ảnh hưởng đến giao diện người dùng (UI)
- Một bước để mở và theo dõi một PR
- Một kỹ năng để theo dõi CI và sửa lỗi khi chúng xảy ra
Mặc dù quy trình làm việc của bạn có thể khác, việc tạo ra các vòng phản hồi và kết hợp các kỹ năng cho phép Claude xác minh và thực hiện nhiều công việc hơn từ đầu đến cuối (end-to-end).
