Bài 2 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 1: chọn cửa vào và cài đặt.
Tôi chưa từng viết một dòng code nào. Nên khi bắt đầu dùng Claude Code, tôi không có cách nào kiểm tra công việc của nó theo kiểu lập trình viên — đọc code thì tôi không hiểu, mà tin tưởng hoàn toàn thì tôi không dám.
Cách tôi tìm ra là cách của một người quản lý: không cần biết nhân viên làm việc thế nào, nhưng phải biết giao việc rõ ràng, đặt điểm kiểm soát đúng chỗ, và nghiệm thu bằng kết quả cuối.
Bài này là quy trình phiên làm việc đầu tiên theo đúng tinh thần đó.
Nguyên tắc số một: bắt nó lập kế hoạch trước khi cho phép làm
Claude Code có một chế độ tên là Plan mode. Ở chế độ này, nó chỉ được đọc và phân tích — không sửa được file nào, không chạy được lệnh gây thay đổi nào. Nó đọc dự án, suy nghĩ, rồi trình cho bạn một bản kế hoạch: định làm gì, sửa những đâu, theo thứ tự nào.
Bật chế độ này rất đơn giản: trong terminal nhấn Shift+Tab, hoặc gõ /plan trước yêu cầu; trong VS Code và app Desktop có sẵn lựa chọn Plan ngay trên giao diện.
Với người không đọc được code, đây là công cụ quản lý quan trọng nhất. Bạn không hiểu code, nhưng bạn hoàn toàn hiểu được một bản kế hoạch viết bằng lời thường. Kế hoạch nghe hợp lý thì duyệt cho làm. Kế hoạch có chỗ mơ hồ thì hỏi lại, yêu cầu sửa, rồi mới duyệt. Giống hệt cách bạn duyệt đề xuất của một nhân viên mới: chưa cần tin tay nghề, chỉ cần thấy được suy nghĩ.
Nguyên tắc số hai: tuần đầu, duyệt tay từng bước
Sau khi kế hoạch được duyệt, Claude Code bắt đầu làm — và ở chế độ mặc định, nó dừng lại xin phép trước mỗi hành động đáng kể: sửa file này được không, chạy lệnh kia được không. Mỗi lần hỏi, nó hiện rõ tên file và nội dung định thay đổi.
Sẽ có lúc bạn thấy phiền và muốn bấm "always allow" cho nhanh. Tuần đầu tiên, đừng. Từng cái gật đầu thủ công chính là buổi học việc của cả hai phía: nó học cách bạn muốn làm việc, còn bạn học được nó thường đụng vào những đâu. Khi đã nắm được nếp làm của nó rồi, nới quyền dần cũng chưa muộn.
Nguyên tắc số ba: việc đầu tiên phải là việc nhỏ, thấy được, hỏng cũng không sao
Đừng mở màn bằng "làm cho tôi một website bán hàng". Mở màn bằng một việc mà bạn tự nghiệm thu được bằng mắt thường trong vài phút.
Việc đầu tiên tôi thật sự giao cho Claude Code không phải là làm ra một tính năng nào cả, mà là viết bộ quy tắc làm việc cho chính nó. Một file hướng dẫn nằm trong dự án, nói rõ tôi muốn nó làm việc theo lối nào: hiểu tổng quan trước rồi mới đi vào chi tiết, giữ một mạch logic thống nhất, gặp cùng một kiểu việc thì làm theo cùng một cách.
Tôi chọn việc đó mở màn vì nó không đụng vào thứ gì đang chạy — sai thì xóa đi viết lại, mất vài phút. Và tôi nghiệm thu được ngay: giao tiếp cho nó một việc nhỏ có thể nhìn thấy kết quả, thêm phần tải tài liệu vào một bài viết trên web, rồi ngồi xem nó có đi đúng thứ tự tôi vừa dặn không, hay lao thẳng vào sửa file đầu tiên nó gặp.
Việc thử tốt có ba đặc điểm: phạm vi nhỏ, kết quả nhìn thấy được, và sai thì xóa đi làm lại không tiếc. Một trang giới thiệu đơn giản, một chỉnh sửa trên trang có sẵn, một file tổng hợp dữ liệu — đều đạt. Còn dự án thật đang chạy thì chưa phải chỗ cho buổi thử việc.
Nghiệm thu khi không đọc được code
Đây là câu tôi bị hỏi nhiều nhất: không biết code thì kiểm tra kiểu gì? Tôi làm ba lớp.
Lớp một, chạy thử sản phẩm như một người dùng: bấm từng nút, thử từng luồng, cố tình làm sai xem nó phản ứng ra sao. Sản phẩm chạy đúng là tín hiệu quan trọng nhất, và lớp này không cần một chữ code nào.
Lớp hai, hỏi lại chính nó: "liệt kê mọi file vừa thay đổi và giải thích từng thay đổi bằng lời thường". Rồi hỏi tiếp câu tôi luôn hỏi: "thay đổi này có ảnh hưởng gì đến bảo mật hay dữ liệu người dùng không?". Nó giải thích được rành mạch thì yên tâm hơn; nó trả lời vòng vo thì đó chính là chỗ cần đào tiếp.
Lớp ba, audit định kỳ bằng một phiên riêng: mở một phiên mới, yêu cầu nó rà lại toàn bộ dự án dưới góc nhìn bảo mật như thể code đó do người khác viết. Phiên mới không bị dính vào mạch suy nghĩ cũ, nên soi ra được những thứ phiên cũ tự bỏ qua. Đây là thói quen tôi giữ đều đặn, và nó đã nhiều lần bắt được vấn đề trước khi người dùng của tôi kịp gặp.
Ba lớp này không thay được một chuyên gia bảo mật. Nhưng nó đưa bạn từ "tin mù quáng" sang "tin có kiểm soát" — và với phần lớn sản phẩm nhỏ, khoảng cách đó là khoảng cách sống còn.
Nếu nó đang làm mà bạn thấy sai hướng
Nhấn Esc. Nó dừng ngay, không tự ái, không cãi. Bạn nói lại yêu cầu rồi đi tiếp. Quyền dừng bất cứ lúc nào là quyền của người quản lý — dùng thường xuyên vào, đừng ngồi xem nó đi sai đến cuối rồi mới sửa.
Cheatsheet tải về
Tôi gom quy trình trên thành một trang: 5 bước của một phiên làm việc chuẩn, bảng các chế độ xin phép và khi nào dùng chế độ nào, cùng bộ câu hỏi nghiệm thu tôi dùng sau mỗi phiên. In ra để cạnh máy được.
📥 Tải miễn phí
Cheatsheet Phiên Làm Việc Với Claude Code
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.
Điều tôi nhận ra
Phiên làm việc đầu tiên không phải để xem AI giỏi đến đâu. Nó là để hai bên học cách làm việc với nhau: nó học yêu cầu của bạn, bạn học giới hạn của nó, và cả hai cùng xây một nếp làm việc mà về sau mọi dự án đều chạy trên đó.
Nếp đó, hóa ra, có thể viết hẳn ra thành một file để nó đọc lại mỗi lần bắt đầu — file đó tên là CLAUDE.md, và là chuyện của bài sau.
