Bài 4 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 3: CLAUDE.md, bộ não của dự án.
Câu trên là của tài liệu chính thức, và tôi đọc nó ba lần mới thấy hết sức nặng.
Claude trên web trả lời rồi chờ bạn. Claude Code thì làm — và trong lúc làm, nó phải tự quyết định một chuyện mà chat không bao giờ phải quyết: khi nào thì xong. Không có cách nào kiểm tra, "trông như đã xong" là tín hiệu duy nhất nó có. Lúc đó người đóng vai máy kiểm tra chính là bạn, và mọi lỗi đều phải chờ bạn tự phát hiện ra.
Đây là chỗ prompt cho agent tách khỏi prompt cho chat. Viết prompt chat là nghệ thuật diễn đạt cho rõ. Viết prompt cho agent là việc khác: giao đúng phạm vi, chỉ đúng chỗ để nó tự đọc, và đưa cho nó một phép thử để nó tự biết mình đã sai.
Thêm một phép thử vào mọi yêu cầu
Đây là thay đổi nhỏ nhất mang lại khác biệt lớn nhất, và người không biết code hoàn toàn làm được.
Phép thử là bất cứ thứ gì cho ra kết quả đúng-sai mà chính nó đọc được: một bộ test, một lệnh build, một ảnh chụp màn hình để đối chiếu với bản thiết kế. Có phép thử rồi, vòng lặp tự đóng lại: nó làm, nó chạy thử, nó đọc kết quả, nó sửa, rồi lặp cho tới lúc qua.
Ba ví dụ, lấy từ tài liệu chính thức, đọc cặp trước-sau là thấy ngay khoảng cách:
- "Viết hàm kiểm tra email" → "Viết hàm kiểm tra email. Các trường hợp cần đúng: `user@example.com` hợp lệ, `invalid` không hợp lệ, `user@.com` không hợp lệ. Làm xong thì chạy thử."
- "Làm cái dashboard trông đẹp hơn" → "[dán ảnh thiết kế] Làm theo thiết kế này. Xong thì chụp lại màn hình, so với ảnh gốc, liệt kê chỗ khác nhau rồi sửa."
- "Build đang lỗi" → "Build lỗi với thông báo này: [dán lỗi]. Sửa và xác nhận build chạy được. Sửa vào gốc vấn đề, đừng chặn thông báo lỗi lại cho êm."
Câu cuối của ví dụ thứ ba là chỗ đáng để ý. Không dặn, agent hoàn toàn có thể chọn cách làm cho thông báo lỗi biến mất thay vì cho lỗi biến mất — nhanh hơn, và trông y như đã xong.
Và một câu nên gắn vào cuối mọi yêu cầu: bắt nó trưng bằng chứng, đừng nhận là xong. Kết quả test, lệnh nó đã chạy kèm output, ảnh màn hình. Đọc bằng chứng nhanh hơn tự đi kiểm tra lại, và nó cứu bạn ở đúng những phiên bạn không ngồi xem.
Trỏ, đừng tả
Agent đọc được dự án của bạn. Nên thay vì tả bằng lời "cái chỗ xử lý đăng nhập ấy", hãy trỏ thẳng vào file, vào ví dụ có sẵn, vào chỗ nó nên bắt chước.
Cặp trước-sau rõ nhất trong tài liệu là ví dụ này:
- "Thêm cái widget lịch" →
- "Xem cách các widget hiện có trên trang chủ được viết để nắm quy ước — `HotDogWidget.php` là ví dụ tốt. Theo đúng quy ước đó, làm một widget lịch cho phép chọn tháng và lật qua lại để chọn năm. Viết từ đầu, không dùng thư viện nào ngoài những thư viện dự án đã có."
Câu sau dài hơn thật. Nhưng nó chứa ba thứ câu trước không có: một chỗ để bắt chước, một phạm vi rõ ràng, và một giới hạn về công cụ. Ba thứ đó cắt hẳn ba vòng sửa lưng về sau.
Trong terminal, gõ dấu `@` rồi tên file là nó nạp luôn nội dung file đó vào yêu cầu, không cần chờ nó tự đi tìm. Ảnh thì dán trực tiếp hoặc kéo vào thả. Lỗi thì dán cả khối lỗi, đừng tả lại bằng lời.
Context là ngân sách, không phải cái thùng
Chỗ này là thứ tôi thấy ít người mới biết, mà nó giải thích gần hết những lần "sao hôm nay nó ngu thế".
Toàn bộ cuộc hội thoại — mọi câu bạn viết, mọi file nó đọc, mọi kết quả lệnh nó chạy — nằm chung trong một khoảng nhớ có hạn gọi là context. Tài liệu nói thẳng: khoảng đó đầy rất nhanh, và năng lực giảm dần khi nó đầy lên. Sắp đầy thì Claude bắt đầu "quên" những lời dặn từ đầu phiên và mắc lỗi nhiều hơn.
Hệ quả thực tế, ba việc nên làm:
Xóa context giữa hai việc không liên quan. Gõ `/clear`. Làm xong việc A rồi hỏi sang việc B trong cùng phiên là cách nhanh nhất để nhồi rác vào ngân sách của mình.
Luật hai lần. Sửa lưng nó hai lần cùng một chỗ mà vẫn sai thì đừng sửa lần thứ ba. Lúc đó context đã đầy những phương án thất bại, và nó đang bị chính những phương án đó dẫn đi tiếp. Gõ `/clear`, viết lại yêu cầu từ đầu, lần này gói cả những gì bạn vừa học được vào. Tài liệu nói rõ: một phiên sạch với prompt tốt hơn gần như luôn thắng một phiên dài đầy vết sửa.
Khoanh vùng việc đào. Bảo nó "điều tra xem" mà không khoanh vùng thì nó đọc vài trăm file, và ngân sách hết trước khi tới phần làm việc.
Sai hướng thì nhấn `Esc` để dừng. Muốn quay ngược cả thay đổi trên file thì nhấn `Esc` hai lần hoặc gõ `/rewind`, chọn mốc để lùi về. Có một giới hạn cần biết thật: mốc lùi chỉ theo dấu những gì Claude sửa bằng công cụ sửa file của nó — thay đổi do lệnh terminal gây ra thì không, nên nó không thay được git.
Việc lớn: để nó phỏng vấn bạn trước
Với một tính năng lớn, cái khó không phải viết prompt. Cái khó là bạn chưa nghĩ hết những thứ cần nghĩ, và không biết mình chưa nghĩ tới cái gì.
Cách chữa nằm trong tài liệu chính thức và nó đảo hẳn thế chủ động: bảo nó phỏng vấn bạn.
"Tôi muốn làm [mô tả ngắn]. Hãy phỏng vấn tôi thật kỹ. Hỏi về cách triển khai, giao diện, các trường hợp biên, những chỗ đánh đổi. Đừng hỏi những câu hiển nhiên — đào vào phần khó mà tôi có thể chưa nghĩ tới. Phỏng vấn cho tới khi đủ, rồi viết bản đặc tả đầy đủ ra file SPEC.md."
Nó hỏi, bạn trả lời, và cuối buổi bạn có một bản đặc tả viết ra file. Sau đó — chi tiết này quan trọng — mở một phiên hoàn toàn mới để làm. Phiên mới có context sạch, chỉ tập trung vào việc thi công, và có bản đặc tả để đối chiếu.
Bản đặc tả tốt có ba đặc điểm: gọi tên đúng các file liên quan, nói rõ cái gì không thuộc phạm vi, và kết bằng một bước kiểm tra đầu-cuối chứng minh tính năng chạy thật. Thời gian bỏ ra làm cho bản đặc tả chính xác đáng giá hơn thời gian ngồi xem nó thi công.
Prompt pack tải về
Tôi gói lại năm file prompt tôi dùng thật, viết bằng tiếng Anh theo dạng brief thực thi: một brief cho tính năng mới với đầy đủ luật cứng và giai đoạn hỏi trước khi làm, một brief sửa lỗi, một prompt phỏng vấn để ra đặc tả, một prompt bắt phiên khác soi lại việc vừa làm, và bộ câu hỏi nghiệm thu cuối phiên. Chép vào dự án, sửa vài chỗ trong ngoặc vuông là chạy được.
📥 Tải miễn phí
Prompt Pack Cho 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. 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ĩ đằng sau việc giao việc và nghiệm thu thì nằm ở phần nền trong khóa AI Fluency.
Điều tôi nhận ra
Tôi từng nghĩ viết prompt giỏi là tả cho hay. Sau một thời gian làm việc với agent, tôi thấy nó gần với viết một bản giao việc: nói rõ mục tiêu, khoanh rõ phạm vi, và định trước cách nghiệm thu.
Cả ba việc đó, người quản lý nào cũng làm được mà không cần biết code. Đó là tin tốt. Tin còn lại là chúng không tự làm hộ mình: mọi thứ bạn không nói rõ, agent sẽ tự quyết — và nó quyết theo hướng công việc trông như đã xong.
Đến đây thì nó đã đọc được dự án của bạn và hiểu được cách bạn giao việc. Nhưng nó vẫn ngồi trong một cái hộp: không xem được thiết kế bạn để trên Figma, không đọc được dữ liệu trong database, không biết trang web vừa deploy có đang lỗi hay không. Mở cái hộp đó ra là chuyện của bài sau.
Tư duy làm việc với AI ở tầm chuyên gia — AI Fluency