Spec là bản mô tả yêu cầu bạn đưa cho AI trước khi nó viết code. Một spec dùng được cần sáu mục: mục tiêu sản phẩm, danh sách màn hình, luồng người dùng, ràng buộc kỹ thuật, cách kiếm tiền, và — quan trọng nhất — danh sách những thứ KHÔNG được làm. Cùng một công cụ, spec tốt cho ra sản phẩm dùng được, spec sơ sài cho ra thứ chạy được nhưng vô dụng.
Đây là khâu quyết định chất lượng nhiều nhất mà gần như không bài tiếng Việt nào viết kỹ. Người ta viết nhiều về công cụ — Claude Code, Antigravity, Lovable — nhưng rất ít người nói rằng chênh lệch giữa người dùng giỏi và người dùng kém không nằm ở công cụ, mà nằm ở cái họ đưa vào công cụ.
Vì sao cùng một công cụ, người ra app người không
Thử so hai yêu cầu:
Yêu cầu A: “Làm cho tôi một app máy tính.”
Yêu cầu B: “Làm app máy tính cho người bán hàng online tính tiền ship. Một màn hình. Nhập: khối lượng, tỉnh đi, tỉnh đến. Hiện: giá của 3 hãng vận chuyển. Dùng Kotlin + Jetpack Compose, target SDK 36. Không thêm tính năng nào khác.”
Cả hai đều cho ra app chạy được. Nhưng A cho ra một máy tính bỏ túi giống hệt hàng nghìn cái đã có, còn B cho ra thứ có người thật cần.
Khác biệt không nằm ở AI. Nó nằm ở chỗ bạn đã nghĩ xong chưa trước khi gõ.
Đây cũng là lý do nhiều người thất vọng với vibe coding: họ đổ lỗi cho công cụ trong khi vấn đề là họ chưa biết mình muốn gì.
Sáu mục bắt buộc của một spec dùng được
1. Mục tiêu sản phẩm
Một đoạn ngắn: sản phẩm giải quyết việc gì, cho ai. Không quá ba câu.
Nếu bạn không viết nổi ba câu này, đó là tín hiệu bạn chưa nghĩ xong — và không công cụ nào cứu được.
2. Danh sách màn hình
Liệt kê từng màn hình: tên, hiển thị gì, có nút gì.
Viết đơn giản thôi, kiểu: “Màn 1 — Trang chủ: ô nhập khối lượng, 2 ô chọn tỉnh, nút Tính. Màn 2 — Kết quả: bảng 3 hãng với giá và thời gian giao.”
3. Luồng người dùng
Mở app → thấy gì → bấm gì → đi đâu → kết thúc thế nào.
Mục này bắt bạn nghĩ như người dùng thay vì như người làm. Rất nhiều lỗi thiết kế bị phát hiện ngay ở bước viết mục này.
4. Ràng buộc kỹ thuật
- Ngôn ngữ hoặc framework
- Phiên bản tối thiểu / mục tiêu
- Thư viện được dùng
- Thư viện không được dùng
Mục thư viện quan trọng hơn vẻ ngoài của nó: AI hay đề xuất thư viện lỗi thời, và ghi rõ ở đây chặn được phần lớn lỗi build.
5. Cách kiếm tiền
Đặt quảng cáo ở đâu, loại gì. Hoặc: bán gì, thanh toán qua đâu.
Viết mục này ngay từ đầu, đừng để đến cuối mới thêm. Gắn phần kiếm tiền vào một app đã hoàn thiện khó hơn nhiều so với tính từ đầu.
6. Những thứ KHÔNG làm
Đây là mục quan trọng nhất, và là mục hay bị bỏ nhất.
AI có xu hướng “giúp thêm” — tự thêm tính năng bạn không yêu cầu, tự đổi thư viện, tự sửa file không liên quan. Phần giúp thêm đó thường là nguồn gây lỗi.
Mẫu nội dung:
KHÔNG làm những việc sau:
- Không tự thêm tính năng ngoài danh sách màn hình ở trên
- Không đổi thư viện đã chọn
- Không xoá hoặc đổi tên file mà chưa hỏi
- Không thêm màn hình cài đặt, giới thiệu, đăng nhập nếu chưa yêu cầu
- Không dùng dữ liệu giả trong bản cuối
Riêng mục này thường cắt được một nửa số lần phải sửa qua lại.
Mẫu spec cho Mobile App
Copy dùng ngay, thay phần trong ngoặc:
# SPEC — [Tên app]
## 1. MỤC TIÊU
App giúp [ai] làm được [việc gì].
Vấn đề đang gặp: [mô tả ngắn].
## 2. MÀN HÌNH
- Màn 1 — [tên]: hiển thị [...], có nút [...]
- Màn 2 — [tên]: hiển thị [...], có nút [...]
## 3. LUỒNG NGƯỜI DÙNG
Mở app → [...] → bấm [...] → [...] → kết thúc.
## 4. RÀNG BUỘC KỸ THUẬT
- Ngôn ngữ: Kotlin
- Giao diện: Jetpack Compose
- Min SDK: [..] · Target SDK: 36
- Thư viện được dùng: [...]
- Thư viện KHÔNG dùng: [...]
## 5. KIẾM TIỀN
- AdMob: banner ở đáy màn 1, interstitial sau khi xem kết quả
- Bắt buộc có luồng UMP consent trước khi gọi quảng cáo
- Dùng ID test trong lúc phát triển
## 6. KHÔNG LÀM
- Không tự thêm tính năng ngoài mục 2
- Không đổi thư viện đã chọn
- Không xoá file mà chưa hỏi
- Không đặt quảng cáo gần nút thao tác
Mẫu spec cho Web App
# SPEC — [Tên sản phẩm]
## 1. MỤC TIÊU
Web app giúp [ai] làm được [việc gì].
Người dùng trả tiền vì [lý do].
## 2. TRANG
- Trang chủ: [...]
- Trang [...]: [...]
- Khu vực thành viên: [...]
## 3. LUỒNG NGƯỜI DÙNG
Vào web → [...] → đăng ký → thanh toán → [...]
## 4. DỮ LIỆU CẦN LƯU
- Người dùng: email, tên, trạng thái thanh toán
- [Bảng khác]: [...]
## 5. KIẾM TIỀN
- Mô hình: [bán một lần / thuê bao]
- Cổng thanh toán: [...]
- Nội dung chỉ mở sau khi thanh toán: [...]
## 6. KHÔNG LÀM
- Không thêm trang ngoài danh sách mục 2
- Không tự đổi cấu trúc dữ liệu
- Không dùng dữ liệu mẫu trong bản cuối
🎓 Spec là bước đầu. Phần khó là ghép nó thành sản phẩm thật có doanh thu. Khoá Vibe Coding tạo Mobile App đi từ spec tới app trên Play Store có AdMob; Khoá Vibe Coding tạo Web-App đi từ spec tới web app có thanh toán.
Nạp spec làm ngữ cảnh thường trực
Viết spec xong rồi dán vào ô chat là cách dùng lãng phí nhất. Sau vài lượt trao đổi AI sẽ quên.
Cách đúng: lưu spec thành file trong thư mục dự án. Nhiều công cụ đọc file này mỗi lần làm việc — với Claude Code thì đặt tên CLAUDE.md ở thư mục gốc. Công cụ khác có cơ chế tương tự, kiểm tra tài liệu của công cụ bạn dùng.
Khi spec nằm trong file:
- AI nhớ ràng buộc ở mọi lượt trao đổi, không cần nhắc lại
- Bạn sửa spec một chỗ, mọi yêu cầu sau đều theo bản mới
- Dự án sau copy lại file này, chỉnh vài dòng là xong
Việc này mất 5 phút và tiết kiệm hàng giờ.
Trước và sau — cùng một yêu cầu
Spec sơ sài: “Làm app đếm ngày.”
Kết quả điển hình: app đếm ngày có sẵn ba tính năng bạn không cần, dùng thư viện lạ, giao diện mặc định, không có chỗ đặt quảng cáo, và khi bạn muốn thêm AdMob thì phải sửa lại cấu trúc.
Spec đầy đủ: mô tả rõ một màn hình, một chức năng, thư viện cụ thể, vị trí quảng cáo tính từ đầu, kèm danh sách không làm.
Kết quả: app đúng thứ bạn cần, ít lỗi hơn, và phần kiếm tiền đã nằm đúng chỗ ngay từ bản đầu.
Chênh lệch thời gian: viết spec đầy đủ mất khoảng 20–30 phút. Sửa một app dựng từ spec sơ sài thường mất vài giờ. Đây là khoản đầu tư có tỷ suất tốt nhất trong toàn bộ quy trình vibe coding.
Câu hỏi thường gặp
Spec là gì trong vibe coding?
Là bản mô tả yêu cầu bạn đưa cho AI trước khi nó viết code — gồm mục tiêu, màn hình, luồng người dùng, ràng buộc kỹ thuật, cách kiếm tiền và danh sách những thứ không được làm.
Viết spec mất bao lâu?
Khoảng 20–30 phút cho sản phẩm đầu tiên. Từ sản phẩm thứ hai trở đi chỉ mất 10 phút vì bạn copy lại mẫu và chỉnh vài dòng.
Không viết spec có được không?
Được, nhưng bạn sẽ mất nhiều thời gian hơn ở khâu sửa. Với sản phẩm chỉ một màn hình thì có thể bỏ qua; từ ba màn hình trở lên thì nên có.
Mục “không làm” có thật sự cần thiết không?
Rất cần. AI có xu hướng tự thêm tính năng ngoài yêu cầu, và đó là nguồn gây lỗi phổ biến. Riêng mục này thường cắt được một nửa số lần sửa qua lại.
Spec có cần viết bằng tiếng Anh không?
Không. Viết tiếng Việt cũng được, các công cụ AI hiện nay hiểu tốt. Riêng tên thư viện, tên hàm và thuật ngữ kỹ thuật thì giữ nguyên tiếng Anh.
File CLAUDE.md dùng cho công cụ khác được không?
Tên file là quy ước riêng của Claude Code. Các công cụ khác có cơ chế ngữ cảnh thường trực tương tự nhưng tên khác — kiểm tra tài liệu của công cụ bạn dùng.
Bước tiếp theo
Chưa chọn công cụ thì đọc Claude Code hay Antigravity nếu làm mobile, hoặc Lovable cho web app nếu làm web. Muốn biết trước AI hay sai ở đâu để đưa vào mục “không làm” — đọc 7 thứ vibe coding không làm được.
🎓 Học bài bản: Khoá Vibe Coding tạo Mobile App — xem khoá học · Khoá Vibe Coding tạo Web-App — xem khoá học
