Bài 7 trong loạt Vibe Code A to Z — hướng dẫn vibe code bằng Claude Code cho người Việt. Bài 6: skills dạy Claude cách làm việc của mình.
Claude Code chạy xong, báo đã sửa tám file. Trên màn hình là một khối chữ xanh đỏ trôi qua nhanh hơn tốc độ bạn đọc. Bạn không viết dòng nào trong đó, và nói thật thì bạn cũng không đọc hiểu hết.
Phản xạ tự nhiên là gõ một câu: *"Code này ổn chưa?"*
Nó trả lời ổn. Tất nhiên là ổn. Bạn vừa đưa bài cho chính người làm bài chấm, và người đó thì luôn muốn làm bạn hài lòng.
Đây là chỗ tôi thấy nhiều người mới bị kẹt lâu nhất. Không phải vì thiếu công cụ. Vì đặt sai câu hỏi ngay từ đầu.
Bạn không cần đọc hiểu code. Bạn cần kiểm chứng ba thứ khác
Đổi mục tiêu trước đã. Mục tiêu không phải hiểu từng dòng — người viết code chuyên nghiệp duyệt code của đồng nghiệp cũng không đọc hiểu từng dòng. Mục tiêu là thu hẹp vùng có thể gây hại.
Ba thứ đáng nhìn, và cả ba đều không đòi bạn biết lập trình.
Một: nó đụng vào những file nào. Bạn nhờ đổi màu cái nút, mà danh sách file đổi có tên nghe như cấu hình, thanh toán, hoặc đăng nhập — thì dừng lại hỏi. Không phải vì nó chắc chắn sai, mà vì phạm vi thay đổi rộng hơn phạm vi yêu cầu, và đó luôn là câu hỏi hợp lệ.
Hai: nó có thêm thư viện ngoài nào không. Mỗi thư viện thêm vào là một mẩu code của người lạ chạy trong sản phẩm của bạn, mãi mãi, và bạn không kiểm soát được nó cập nhật cái gì ở lần sau. Câu hỏi đúng là: *"việc này có làm được bằng thứ dự án đã có sẵn không?"* Rất nhiều lần câu trả lời là có.
Ba: dữ liệu nhạy cảm đi đâu. Khóa truy cập, mật khẩu, thông tin người dùng. Chúng phải nằm trong biến môi trường, không được nằm thẳng trong code, và không được lọt vào phần ghi nhật ký. Bạn không cần đọc code để hỏi câu này — bạn hỏi thẳng, và bắt nó chỉ đúng dòng.
Bốn câu hỏi thay cho "code này ổn chưa"
Điểm chung của bốn câu dưới đây: chúng buộc nó phải chỉ ra một thứ cụ thể, thay vì cho phép nó gật đầu.
"Liệt kê các file anh vừa đổi và mỗi file đổi vì lý do gì." Câu này lộ ra ngay chuyện nó có làm rộng hơn yêu cầu hay không. Một file không giải thích được lý do là một file đáng hỏi tiếp.
"Chỗ nào trong thay đổi này dễ hỏng nhất, và hỏng thì biểu hiện ra sao?" Đây là câu tôi dùng nhiều nhất. Nó chuyển nó từ vai người bảo vệ sang vai người mổ xẻ. Trả lời "không có chỗ nào dễ hỏng" là một câu trả lời đáng nghi, không phải một câu trả lời tốt.
"Có thư viện nào mới không, và vì sao không dùng thứ có sẵn?" Buộc nó biện minh cho phần phụ thuộc thêm.
"Cho tôi cách tự kiểm chứng việc này đã chạy đúng — bằng thao tác tôi tự làm được." Câu quan trọng nhất trong bốn câu. Nó biến một lời khẳng định thành một thứ bạn tự bấm được: mở trang này, điền số kia, phải thấy kết quả nọ. Bạn không đọc code, nhưng bạn kiểm chứng được hành vi — và hành vi mới là thứ người dùng của bạn gặp.
Cho nó một người phản biện không có ký ức
Có một mẹo đơn giản mà hiệu quả đến mức hơi bất ngờ: mở một phiên hoàn toàn mới, rồi bảo nó soát lại phần vừa làm.
Phiên mới không nhớ cuộc trò chuyện cũ. Nó không biết bạn đã gật đầu với hướng nào, không có cái đà "mình vừa làm cái này xong nên chắc là ổn", không mang theo mấy giả định đã được thống nhất ngầm ở giữa buổi. Nó nhìn code như người ngoài nhìn vào.
Cách hỏi cũng phải khác. Đừng nhờ nó xác nhận, hãy giao cho nó một vai:
Đây là thay đổi vừa được thực hiện. Anh vào vai người soát code khó tính, không phải người đã viết ra nó. Chỉ ra ba chỗ có khả năng hỏng cao nhất, mỗi chỗ nói rõ hỏng trong tình huống nào. Nếu không tìm ra chỗ nào đáng lo thì nói thẳng là không có, đừng bịa ra cho đủ ba.
Vế cuối quan trọng. Không có nó thì bạn sẽ nhận đủ ba mục, kể cả khi chẳng có gì đáng nói — và ba mục bịa ra thì tệ hơn là không có mục nào, vì nó dạy bạn quen với việc bỏ qua cảnh báo.
Claude Code cũng có sẵn hai lệnh cho việc này. `/code-review` soát phần vừa thay đổi để tìm lỗi và chỗ dọn được. `/security-review` soát riêng phần an toàn. Dùng chúng làm lượt quét đầu, rồi mới đến lượt hỏi tay của bạn — thứ tự đó tiết kiệm thời gian hơn làm ngược lại.
Thứ duy nhất không phụ thuộc vào thiện chí
Mọi thứ ở trên đều là hỏi và đáp. Chúng hữu ích, nhưng chúng có chung một điểm yếu: đều dựa vào việc Claude chịu hợp tác và bạn nhớ hỏi.
Có một loại chốt khác, không dựa vào ai cả.
Trong dự án website của tôi có một lệnh kiểm tra chạy tự động trước mỗi lần đóng gói sản phẩm. Nó soát kiểu dữ liệu, soát quy ước code, và soát nội dung — link nội bộ trỏ vào bài không tồn tại thì nó báo lỗi và chặn luôn, không cho đóng gói. Không phải cảnh báo, không phải gợi ý. Chặn.
Cái hay của loại chốt này là nó không quan tâm hôm nay ai viết code, viết lúc mấy giờ, có vội hay không. Nó chỉ có hai kết quả: qua hoặc không qua.
Claude Code còn cho bạn dựng chốt ở tầng sâu hơn nữa, gọi là hook — một đoạn kịch bản tự chạy vào những thời điểm định sẵn. Nó chạy trước mỗi lần Claude định dùng một công cụ, sau khi công cụ chạy xong, hoặc lúc Claude vừa trả lời xong. Đặt đúng chỗ, hook chặn được thẳng tay: cấm chạy lệnh xóa, cấm đụng vào file cấu hình sản phẩm thật, bắt chạy kiểm tra trước khi commit.
Tôi để phần cấu hình chi tiết trong tài liệu tải về, vì nó dài. Nhưng nguyên tắc thì gói gọn trong một câu, và tôi nghĩ đây là câu đáng nhớ nhất của cả bài này: việc nào sai một lần là hỏng thì đừng viết thành lời dặn, hãy dựng thành cái chặn. Lời dặn có thể bị bỏ sót — kể cả bởi bạn.
Chỗ tôi từng tin nhầm
Có một dạng sai mà tôi mất khá lâu mới nhận ra, và nó không nằm trong code.
Claude báo đã áp dụng xong một thay đổi vào cơ sở dữ liệu. Commit ghi rõ ràng như vậy. Tài liệu dự án của tôi cũng ghi lại như vậy. Ba nguồn khớp nhau, nghe rất chắc chắn.
Vấn đề là cả ba nguồn đó đều bắt nguồn từ cùng một câu nói, không nguồn nào trong số đó đi kiểm tra cơ sở dữ liệu thật.
Sau lần đó tôi viết hẳn một dòng vào tài liệu dự án, và nó vẫn nằm nguyên ở đó tới hôm nay: trạng thái phải xác minh bằng thực tế, không tin commit message. Muốn biết một thay đổi đã áp lên cơ sở dữ liệu chưa thì mở cơ sở dữ liệu ra xem. Muốn biết một biến môi trường đã đặt trên máy chủ chưa thì mở bảng cấu hình máy chủ ra xem.
Nói cách khác: báo cáo không phải là bằng chứng. Đây là điều đúng với mọi người làm việc dưới quyền bạn, không riêng gì AI. Chỉ có điều AI báo cáo trôi chảy hơn, tự tin hơn, và không bao giờ ngập ngừng — nên nó dễ được tin hơn.
Tài liệu tải về
Tôi gom lại thành một checklist một trang, in ra dán cạnh màn hình là dùng được: bốn câu hỏi thay cho "code này ổn chưa", ba thứ phải nhìn trong mỗi lần thay đổi, mẫu câu giao vai người phản biện cho phiên mới, danh sách dấu hiệu đáng dừng lại, và phần cấu hình hook chặn cứng kèm giải thích từng dòng cho người chưa từng đụng tới.
📥 Tải miễn phí
Checklist Review Code AI
Tài liệu do tôi biên soạn từ trải nghiệm thật, tham khảo tài liệu chính thức của Anthropic tại code.claude.com/docs. Công cụ này thay đổi rất nhanh — khi có nghi ngờ, bản gốc tiếng Anh luôn là nguồn đúng nhất. Còn cách nghĩ về việc nào nên giao cho công cụ, việc nào không, nằm ở phần nền trong khóa AI Fluency.
Điều tôi nhận ra
Thời gian đầu tôi duyệt code theo kiểu cố đọc cho hiểu. Mở file ra, dò từng dòng, gặp chỗ không hiểu thì hỏi, nghe giải thích xong thì gật. Mất rất nhiều thời gian, và tôi vẫn không yên tâm hơn được bao nhiêu.
Thứ thay đổi được tình hình không phải là tôi đọc code giỏi lên. Là tôi đổi câu hỏi.
Người quản lý giỏi không phải người làm được mọi việc của nhân viên. Là người biết hỏi câu nào để lộ ra chỗ chưa chắc, và biết dựng chốt kiểm ở đâu để chỗ chưa chắc đó không kịp gây hại. Cái nghề đó tôi học được từ mười năm đi làm với con người, và hóa ra nó chuyển sang làm việc với AI gần như nguyên vẹn.
Đến đây thì bạn đã có một sản phẩm chạy được trên máy mình, và đã có cách kiểm tra nó ở mức yên tâm. Còn một khoảng cách nữa, khoảng cách mà tôi thấy nhiều người dừng lại luôn ở đó: từ "chạy được trên máy tôi" đến "người khác mở link ra là dùng được". Đó là chuyện của bài sau.
