Vibe Code
Giáo trình/Phụ lục

Bộ prompt mẫu

Hai mươi đề bài copy-dán, nhóm theo việc. Sửa phần trong ngoặc vuông rồi dùng ngay.

Tra cứutra cứu

Mỗi mẫu dưới đây đã có sẵn phần ràng buộc — phần mà người mới hay quên và là phần tạo ra khác biệt. Sửa phần [trong ngoặc] rồi dùng.

Nhóm 1 — Dựng mới

1.1 Trang một file

Tạo file duy nhất index.html: [mô tả trang].

- Một file, không thư viện ngoài, CSS và JS nhúng trong file.
- Tiếng Việt có dấu, lang="vi", charset UTF-8, có meta viewport.
- Các phần: [liệt kê cụ thể].
- Nền trắng, chữ #17191f, một màu nhấn duy nhất [mã màu].
  Không gradient, không bóng đổ, không viền trái màu.
- Mobile: chữ tối thiểu 16px, nút cao tối thiểu 44px, không cuộn ngang.
- Font hệ thống, không tải font ngoài.

Nội dung cứ điền mẫu hợp lý, tôi sẽ sửa sau.

1.2 Worker có API

Dựng Cloudflare Worker trong thư mục này:
- Phục vụ web tĩnh từ ./public qua binding ASSETS.
- API dưới tiền tố /api/: [liệt kê đường và method].
- Bọc try/catch cả nhánh API; lỗi trả JSON {loi:"..."}, không lộ
  chi tiết nội bộ. Mọi response JSON có charset=utf-8.
- wrangler.toml đầy đủ.

Xong rồi chạy wrangler dev và tự kiểm bằng curl từng đường,
báo cho tôi KẾT QUẢ THẬT.

1.3 Bảng dữ liệu mới

Thêm bảng [tên] qua migration MỚI trong migrations/
(KHÔNG sửa file migration cũ đã chạy).

- Cột: [liệt kê]. Tiền dùng INTEGER đơn vị đồng. Thời gian lưu UTC.
- Luôn có tao_luc, tao_boi.
- UNIQUE trên [cột] để chống trùng ở tầng cơ sở dữ liệu.
- Index cho cột hay lọc/sắp xếp.
- Mọi truy vấn dùng .bind(). Danh sách phải có LIMIT + phân trang,
  chỉ trả cột được vẽ ra màn hình.

Chạy migration ở --local, chèn 3 dòng mẫu, tự kiểm bằng
wrangler d1 execute và báo kết quả thật.

Nhóm 2 — Sửa và thêm

2.1 Thêm tính năng (dùng nhiều nhất)

Thêm [tính năng] vào [file].

- Giữ nguyên MỌI hành vi hiện tại — mặc định phải giống bây giờ.
- Dùng đúng màu, cỡ chữ, cách đặt tên đang có. Không thêm phong cách mới.
- Chỉ sửa phần cần sửa, KHÔNG viết lại cả file.

Xong rồi liệt kê những gì có thể hỏng vì thay đổi này.

2.2 Sửa lỗi

Lỗi:
1. TÔI LÀM GÌ: [thao tác]
2. TÔI MONG: [kết quả mong đợi]
3. THỰC TẾ: [cái xảy ra]
4. CONSOLE báo nguyên văn: [chép y nguyên]

Trước khi sửa: nói nguyên nhân gốc trong 2 dòng.
Rồi sửa ở chỗ NHỎ NHẤT có thể, đừng tái cấu trúc.
Xong rồi nói tôi phải bấm thử gì để biết đã hết lỗi.

2.3 Việc rủi ro (đụng dữ liệu, đăng nhập, thanh toán)

[Mô tả việc].

TRƯỚC KHI SỬA: nói cho tôi biết bạn định sửa ở đâu, vì sao, và
có thể hỏng gì. Rồi DỪNG LẠI chờ tôi đồng ý.

Nếu có chỗ nào trong yêu cầu của tôi chưa rõ, hỏi lại. Đừng tự đoán.

2.4 Hiểu mã lạ

Đọc [file] và giải thích cho người không chuyên: dữ liệu vào từ đâu,
biến đổi ở đâu, ra đâu. Tối đa 10 dòng, dùng tên biến thật trong file.
CHỈ ĐỌC, không sửa gì.

Nhóm 3 — Rà soát

3.1 Review thay đổi trước khi merge

Đọc git diff main...HEAD và review như một người khó tính, theo thứ tự:
1. ĐÚNG SAI: dữ liệu rỗng, null, ngày trống, tên có dấu, số 0, số âm?
2. MẤT DỮ LIỆU: có đường nào ghi đè hoặc xóa mất dữ liệu cũ?
3. PHÁ LUỒNG CŨ: có đổi hành vi mặc định mà tôi không yêu cầu?
4. ĐƠN GIẢN HƠN: chỗ nào phức tạp quá mức cần thiết?

Mỗi vấn đề: file, dòng, hậu quả cụ thể, cách sửa nhỏ nhất.
Không có vấn đề thật thì nói "không có" — đừng bịa để có cái nói.

3.2 Rà API theo 7 luật → xem Thiết kế API tiết kiệm

3.3 Rà bảo mật 10 mục → xem Bảo mật & rate limit

3.4 Rà bí mật bị lộ

Rà project này, liệt kê mọi chỗ có thể là bí mật bị lộ:
khóa API / mật khẩu gán cứng; số điện thoại, email, họ tên người thật;
file dữ liệu thật (.xlsx, .csv, .db, ảnh người); bí mật trong [vars]
của wrangler.toml.

Kiểm cả lịch sử Git:
git log --all --name-only | grep -Ei "\.env|\.dev\.vars|\.xlsx|\.csv|\.pem"

Mỗi chỗ: file, dòng, loại rủi ro. Chỉ đọc, đừng sửa.

3.5 Rà theo sổ tay bẫy → xem Sổ tay 40 bẫy

Nhóm 4 — Test

4.1 Viết script test tự động

Viết script Node (không thư viện ngoài) kiểm app tại [url]:

P0: GET / → 200; GET /api/bootstrap không cookie → 401, dưới 1 giây
P1 (tài khoản test GHI ĐƯỢC từ biến môi trường):
    đăng nhập → tạo bản ghi CÓ DẤU TIẾNG VIỆT → đọc lại thấy đúng,
    chữ không bị mất dấu
    gửi thiếu trường bắt buộc → 400 (không phải 500)
    gửi trùng mã → 409
P2: ?moi_trang=999999 → số dòng trả về <= 100

In bảng: tên phép | mong đợi | thực tế | ĐẠT/HỎNG.
Thoát mã khác 0 nếu có phép hỏng, để CI chặn được.
Dữ liệu tiếng Việt ghi ra file tạm rồi gửi, không nhét vào dòng lệnh.

4.2 Tự kiểm giao diện ở khổ nhỏ

Mở [url] ở khổ 375px và liệt kê bằng SỐ:
1. Mọi nút/liên kết có vùng chạm nhỏ hơn 44x44px
   (dùng getBoundingClientRect)
2. Mọi nhãn nút bị bẻ dòng (đếm getClientRects của NÚT VĂN BẢN,
   KHÔNG so chiều cao phần tử)
3. Mọi phần tử chọc ra ngoài màn hình
4. Mọi lỗi trong console

Chờ hơn 2 giây sau khi trang tải xong rồi mới đo (app có thể hoãn vẽ lại).
Rồi làm lại ở khổ 1280px.

Nhóm 5 — Deploy và vận hành

5.1 Deploy đủ quy trình → xem Quy trình deploy

5.2 Điều tra sự cố

App [triệu chứng] từ khoảng [giờ]. TỰ ĐIỀU TRA, chỉ đọc và chạy
lệnh đọc, CHƯA được sửa gì:
1. wrangler deployments list — có bản nào deploy gần giờ đó không?
2. wrangler tail --status=error trong 2 phút
3. Truy vấn nhật ký: việc nền chạy lần cuối lúc nào, có lỗi không
4. curl -w đo thời gian thật của đường chính

Rồi nói: nguyên nhân khả dĩ nhất kèm BẰNG CHỨNG từ bước nào,
cách khôi phục nhanh nhất, cách sửa gốc.
Đừng sửa gì cho tới khi tôi đồng ý.

5.3 Ước lượng chi phí → xem Chi phí thật

5.4 Bảng kê hạ tầng → xem Nhiều app một tài khoản

Nhóm 6 — Tài liệu và sản phẩm

6.1 Viết README

Đọc toàn bộ project rồi viết README.md gồm 5 mục: chạy thử tại máy,
deploy, cấu trúc file, quy ước riêng, việc còn treo.
Ngắn gọn, tiếng Việt.
CHỈ viết những gì bạn ĐỌC ĐƯỢC trong mã. Không biết thì ghi
"chưa rõ", đừng đoán.

6.2 Khởi tạo CLAUDE.md → xem Claude Code nâng cao

6.3 Hồ sơ sản phẩm (báo giá, hỗ trợ, hướng dẫn) → xem Từ app thành sản phẩm

6.4 Rút luật từ lịch sử → xem Biến kinh nghiệm thành luật

Bảy câu dán vào cuối mọi đề

1. Chỉ sửa phần cần sửa, không viết lại cả file.
2. Trước khi sửa, nói bạn định sửa ở đâu và vì sao, rồi chờ tôi đồng ý.
3. Chỗ nào chưa rõ thì hỏi lại trước khi làm. Đừng tự đoán.
4. Dùng đúng màu, cỡ chữ, cách đặt tên đang có. Không thêm phong cách mới.
5. Liệt kê những gì có thể hỏng vì thay đổi này.
6. Đừng khen, đừng mở đầu bằng lời tóm lại. Vào thẳng việc.
7. Việc này tôi làm được bằng cách đơn giản hơn không?
Ba câu tạo ra khác biệt lớn nhấtchuyên gia insight & case thực tế

Nếu chỉ nhớ được ba câu trong cả bài:

"Chỉ sửa phần cần sửa, không viết lại cả file." Chống mất công sức đã làm — rủi ro lớn nhất của Vibe Code.

"Báo cho tôi KẾT QUẢ THẬT, đừng nói đã xong." Biến AI từ người sinh mã thành người tự kiểm chứng. Đây là khác biệt thật giữa Claude Code và chép-dán từ web.

"Chỉ ghi những gì bạn ĐỌC ĐƯỢC. Không biết thì ghi 'chưa rõ'." Chống bịa. Dùng cho mọi việc đọc-và-báo-cáo: viết tài liệu, rà soát, điều tra sự cố. Thiếu câu này là bạn nhận về một báo cáo nghe rất chuyên nghiệp với những chi tiết không tồn tại.

Tôi để file này mở suốtngười dùng bình thường góp ý

Tôi không thuộc được mấy cái đề này, và tôi cũng không cần. Tôi mở trang này ở một tab riêng, cần cái nào thì chép cái đó, sửa phần trong ngoặc.

Sau vài tuần thì ba bốn mẫu hay dùng tự vào đầu. Phần còn lại vẫn tra, và không sao cả.

Mẹo nhỏ của tôi: tôi copy cả file này vào một ghi chú trên điện thoại, vì nhiều lúc tôi nghĩ ra việc cần làm lúc đang đi đường.

Chốt review bài nàychuyên gia review
  • Đủ: 20 mẫu phủ 6 nhóm việc, bảy câu dán cuối đề, chỉ dẫn sang mẫu dài nằm trong các bài chuyên sâu.
  • Cố ý không gom hết mẫu dài vào đây: một mẫu tách khỏi bối cảnh của nó thì dễ dùng sai. Mẫu dài nằm trong bài có giải thích vì sao từng ràng buộc tồn tại.
  • Rủi ro còn lại: mẫu là điểm xuất phát, không phải công thức. Mẫu tốt nhất là mẫu bạn sửa lại theo project của mình — và phần bạn sửa thêm vào thường chính là kinh nghiệm riêng của bạn.