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.
Làm sao để nó biết mình đã làm xong?
Đâ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ộ kiểm tra, một lệnh dựng sản phẩm, 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.
Vào ngày 23 tháng 8 năm 2026, tôi giao bốn gói việc cùng lúc cho một model nhanh trên dự án này. Ba gói là công việc code và xử lý dữ liệu — và cả ba đều qua. Gói đầu tiên, đầu ra khớp với bản mô tả từng dòng và vượt qua 8 trên 8 hạng mục kiểm tra, không kéo thêm thư viện nào ngoài dự án, và file khai báo phụ thuộc thay đổi đúng hai dòng như bản mô tả đã viết trước. Gói thứ hai đối chiếu 26 trên 27 phiên làm việc so với một nguồn đếm độc lập — phiên duy nhất chênh là phiên đang chạy trong lúc đếm, còn đang lớn thêm.
Điều ba gói đó có chung nhau: bản mô tả ghi sẵn đáp án mong đợi. Không phải để bắt nó gian — mà vì "trông như đã xong" là tín hiệu duy nhất nó có. Đưa cho nó đáp án mong đợi nghĩa là đưa cho nó một cách tự kiểm tra mà không cần bạn ngồi xem. Và cuối mọi yêu cầu nên có thêm một câu: bắt nó trưng bằng chứng thay vì chỉ báo xong — kết quả kiểm tra, lệnh nó đã chạy kèm kết quả, ảnh màn hình.
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.
Sau lần giao việc ngày 23 tháng 8 năm 2026, tôi rút ra hai luật ghi vào mọi bản mô tả từ đó về sau. Thứ nhất: đầu vào liệt kê bằng đường dẫn file chính xác, không bao giờ viết "đọc tài liệu dự án" hay "xem codebase". Thứ hai: một gói việc đọc tối đa ba file đầu vào — việc cần đọc nhiều hơn thì phải tách làm hai gói. Cả hai luật đó không phải từ lý thuyết mà từ những lần bản mô tả phá vỡ chúng và sinh ra việc phải làm lại.
Lý do thực tế rất đơn giản: khi bạn viết "đọc tài liệu dự án", nó không biết nên đọc file nào, đọc bao nhiêu, dừng ở đâu. Nó tự quyết — và nó quyết theo hướng tốn ít nhất cho mình, không phải hướng đúng nhất cho bạn. Trỏ thẳng vào file thì phạm vi cố định: một đường dẫn là một điểm dừng, không phải một cánh cửa mở.
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. Lỗi thì dán cả khối lỗi, đừng tả lại bằng lời.
Vì sao phải cho phép nó nói "không biết"
Gói việc thứ tư ngày hôm đó là tra cứu mở: tìm danh sách model AI đang bán kèm bảng giá. Kết quả trả về là một dàn model cũ khoảng mười tám tháng — những model thế hệ hiện tại mà bản mô tả nhắc đích danh thì không có mặt. Bảng giá không phải số bịa: đó là mức giá thật, nhưng gắn vào tên model khác. Loại sai đó khó phát hiện hơn số bịa rất nhiều, vì nhìn vào thấy có vẻ quen.
Phần nguy hiểm hơn không phải nội dung mà là cách gắn nhãn: chín trên chín câu trả lời được đánh dấu là "sự thật chính thức", và không câu nào được gắn nhãn "không biết" — dù bản mô tả ghi rõ rằng "không biết" là một đáp án đúng.
Cơ chế ở đây rất cụ thể: model trả lời từ bộ nhớ trước, rồi đính kèm đường link nguồn phía sau. Nó không phân biệt đáng tin cậy được "tôi vừa đọc cái này trên trang" với "tôi biết cái này". Hệ quả thực tế là không bao giờ nên gửi một tra cứu mở về giá, phiên bản hay tình trạng phát hành cho một model nhanh — đó chính xác là nơi bộ nhớ cũ của nó đang nằm sẵn, và nó sẽ dùng bộ nhớ đó rất tự tin.
Và thêm một dấu hiệu cần ghi nhớ: kết quả không có lần nào "không biết" phải được coi là dấu hiệu hỏng, không phải dấu hiệu tốt. Người làm tra cứu thật sự đều gặp câu hỏi không có đáp án — model nào tự tin một trăm phần trăm trên toàn bộ câu hỏi thì đang trả lời từ bộ nhớ, không phải từ dữ liệu.
Điều còn lại đã kìm hãm được thiệt hại ngày hôm đó: bản mô tả giới hạn phạm vi ghi ra một thư mục duy nhất, nên dữ liệu hỏng không đi vào code được.
Khi nào nên tự làm thay vì giao đi?
Viết một bản mô tả tốn công thật — và nó chỉ có lãi khi phần việc được giao lớn hơn bản mô tả đủ nhiều. Đo đạc trên dự án này cho thấy các bản mô tả chạy từ 251 tới 361 dòng. Ngày 28 tháng 8 năm 2026, có hai gói việc cần quyết định: một bộ kit tổng hợp ước tính ra khoảng 300 dòng kết quả so với bản mô tả khoảng 250 dòng — gần một đổi một, và nó đã được tự làm thay vì giao. Ngay bên cạnh là một việc đóng gói tốn khoảng 15 dòng kết quả so với bản mô tả 50 dòng — tỉ lệ khoảng 3,5 đổi 1 chiều kia, và nó đã được giao.
Quy tắc rút ra từ đó không phức tạp: hai bên xấp xỉ nhau thì tự làm nhanh hơn, phần việc lớn gấp ba tới bốn lần bản mô tả thì mới đáng bỏ công viết mô tả để giao.
Những con số này đến từ một người đo trên vài chục lần giao việc — đủ để rút ra một quy tắc làm việc được, chưa đủ để gọi là chuẩn ngành. Dự án của bạn có thể có nhịp khác, tùy vào độ phức tạp của việc và tốc độ bạn viết bản mô tả. Điều đáng làm là đo lại lần đầu tiên bạn thấy mình đang viết một bản mô tả dài hơn cần thiết.
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.
Bao nhiêu dòng một bản mô tả cần để xứng đáng giao, và khi nào nó thôi còn có lãi, tôi đo chi tiết trong cách viết một bản mô tả việc chặt.
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. Những con số tôi dẫn ở trên — 251 tới 361 dòng cho một bản mô tả, tỉ lệ ba-bốn đổi một để việc giao đi có lãi, chín trên chín câu bị đánh dấu sai — đến từ một dự án, đo trong vài tháng đầu. Đủ để rút ra quy tắc làm việc, chưa đủ để coi là chuẩn chung của ngành.
Đế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 dễ hơn bạn tưởng — nhưng cũng là lúc phải cho người lạ nói vào tai nó, chuyện tôi kể trong bài về MCP.
