Bỏ qua tới nội dung
← Tất cả bài viếtLộ trình · Chặng 05: Xây sản phẩm nhỏ với AI

Viết bản mô tả sản phẩm cho AI: để AI làm đúng ý ngay từ đầu

Trước khi nhờ AI làm trang web hay app, hãy viết một bản mô tả ngắn: mục tiêu, người dùng, tính năng, giới hạn và cách kiểm tra. Có mẫu điền sẵn để chép.

Hướng dẫn5 phút đọc

Mục lục

Nhắn cho AI "làm cho tôi trang web đặt bánh" thì bạn sẽ nhận được một trang đặt bánh, nhưng hiếm khi là trang bạn hình dung. AI phải tự đoán quá nhiều. Đọc xong bài này, bạn sẽ biết cách viết một bản mô tả sản phẩm ngắn gọn (khoảng một trang) để công cụ như Lovable, Bolt, v0, Replit hay Claude Code làm đúng ý ngay từ những lần đầu, kèm mẫu điền sẵn để chép.

Vì sao cần viết trước?

Tài liệu hướng dẫn Claude Code của Anthropic nói gọn: AI "can infer intent, but it can't read your mind", tức đoán được ý định nhưng không đọc được suy nghĩ của bạn. Hướng dẫn viết prompt của v0 cũng cảnh báo: thiếu bối cảnh thì AI sẽ tự đoán.

Mỗi chỗ AI đoán sai là một vòng sửa. Vài vòng sửa chồng lên nhau là app bắt đầu rối. Viết trước 15 phút thường tiết kiệm cả buổi sửa sau.

Bản mô tả này có tên gọi trong nghề là spec (đặc tả) hay PRD (tài liệu yêu cầu sản phẩm). Bạn không cần viết dài hay đúng chuẩn nào cả, chỉ cần đủ ý.

Một bản mô tả tốt có những phần nào?

Tổng hợp từ hướng dẫn của GitHub (Spec Kit), Lovable, v0 và Anthropic, một bản mô tả nên có các phần sau:

  1. Mục tiêuLàm gì, giải quyết chuyện gì, vì sao cần.
  2. Người dùng và việc chínhAi dùng, họ cần làm được một việc gì.
  3. Tính năng cần cóVài tính năng bắt buộc, xếp theo thứ tự ưu tiên.
  4. Chưa làmNhững thứ để sau, AI không tự thêm vào.
  5. Giao diện và dữ liệuPhong cách, màu, thiết bị; cần lưu thông tin gì.
  6. Cách kiểm traLàm sao biết là đã xong và chạy đúng.

= Một trang mô tả, AI ít phải đoán

Sáu phần ghép thành một bản mô tả đủ rõ để AI làm đúng ý. Ví dụ: trang đặt bánh của một tiệm nhỏ.

Vài lưu ý cho từng phần:

  • Mục tiêu và người dùng trước, công nghệ sau. Hướng dẫn Spec Kit của GitHub tách rõ: bản mô tả nói làm gì và vì sao, còn chọn công nghệ nào để ở bước lập kế hoạch. Người không biết code thì cứ để AI đề xuất công nghệ.
  • Bản đầu tiên thật nhỏ. Tài liệu Lovable gợi ý phiên bản đầu chỉ cần "một người dùng, một việc, một kết quả". Thanh toán, nhắc lịch, lịch xem tháng… để sau.
  • Ghi rõ phần "chưa làm". Hướng dẫn của Anthropic khuyên bản mô tả tốt nên nói rõ cái gì nằm ngoài phạm vi. Không ghi, AI có thể "nhiệt tình" thêm tính năng bạn không cần.
  • Giao diện: cho xem hơn là tả. v0, Replit và Claude Code đều nhận ảnh. Một ảnh chụp trang bạn thích hay một bản vẽ tay chụp lại thường rõ hơn ba đoạn mô tả.
  • Cách kiểm tra: viết thành câu "Khi… thì…". Ví dụ: Khi khách đặt bánh xong, thì chủ tiệm thấy đơn mới trong danh sách. Spec Kit dùng kiểu câu tương tự để làm tiêu chí nghiệm thu.

Mẫu điền sẵn

Chép mẫu dưới đây, điền vào chỗ trống, rồi dán vào ô chat đầu tiên của công cụ bạn dùng.

Mẫu bản mô tả sản phẩm
Văn bản
TÊN: Trang đặt bánh của tiệm Mây
 
1. MỤC TIÊU
Khách quen đặt bánh trước qua điện thoại hay Zalo, chủ tiệm hay ghi nhầm.
Cần một trang để khách tự đặt, chủ tiệm xem đơn ở một chỗ.
 
2. NGƯỜI DÙNG VÀ VIỆC CHÍNH
- Khách: chọn bánh, chọn ngày nhận, để lại tên và số điện thoại.
- Chủ tiệm: xem danh sách đơn theo ngày.
Việc chính của bản đầu: khách đặt được một đơn.
 
3. TÍNH NĂNG CẦN CÓ (theo thứ tự ưu tiên)
1) Danh sách 6 loại bánh, có ảnh và giá.
2) Form đặt: loại bánh, số lượng, ngày nhận, tên, số điện thoại.
3) Trang cho chủ tiệm xem đơn, có mật khẩu.
 
4. CHƯA LÀM (đừng thêm)
Thanh toán online, tài khoản cho khách, gửi tin nhắn tự động.
 
5. GIAO DIỆN VÀ DỮ LIỆU
- Nền trắng, chữ đen, màu nhấn nâu nhạt. Dùng tốt trên điện thoại.
- Lưu: đơn đặt (loại bánh, số lượng, ngày nhận, tên, số điện thoại).
- Số điện thoại khách chỉ chủ tiệm xem được.
 
6. CÁCH KIỂM TRA
- Khi khách gửi form đủ thông tin, thì đơn hiện trong trang chủ tiệm.
- Khi khách bỏ trống số điện thoại, thì form báo lỗi, không gửi được.
- Người không có mật khẩu không xem được danh sách đơn.
 
Trước khi làm, hãy hỏi tôi những điểm còn chưa rõ, rồi đưa kế hoạch các bước để tôi duyệt.

Câu cuối của mẫu rất đáng giữ. Hướng dẫn Claude Code gợi ý để AI phỏng vấn bạn trước rồi mới viết đặc tả, còn Lovable khuyên dùng chế độ lập kế hoạch (Plan mode) cho mọi thay đổi lớn hơn một chỉnh sửa nhỏ.

Từ bản mô tả tới sản phẩm chạy được

  1. Viết mô tảDùng mẫu ở trên
  2. AI lập kế hoạchHỏi lại chỗ chưa rõ, chia bước
  3. Làm từng phầnMỗi lần một thay đổi
  4. Kiểm traThử như người dùng thật
  5. Đưa lên mạngSau khi quét bảo mật
Các công cụ đều khuyên cùng một nhịp: lên kế hoạch trước, làm từng phần nhỏ, kiểm tra mỗi bước.
  1. Lưu bản mô tả làm "trí nhớ" của dự án. Nhiều công cụ có chỗ lưu thông tin dùng cho mọi lần nhắn: Knowledge trong Lovable và Bolt, tệp CLAUDE.md trong Claude Code. Lovable khuyên viết phần này như một trang tóm tắt, không phải cả cuốn sách.
  2. Mỗi lần nhắn một thay đổi. Lovable, Bolt và Replit đều khuyên vậy: đổi một chỗ, xem trước, ổn rồi mới làm tiếp. Nói rõ cả phần không được đụng tới.
  3. Lưu điểm khôi phục. Replit gợi ý lưu checkpoint sau mỗi bước chạy được. v0 khuyên: hai lần nhắn liên tiếp không tiến bộ thì quay lại bản trước.
  4. Kiểm tra theo mục 6 của bản mô tả trước khi chuyển sang tính năng mới.
  5. Trước khi công khai: chạy quét bảo mật, cho một người dùng thật thử trước khi giới thiệu rộng rãi (Lovable gợi ý cả hai). Đọc thêm phần rủi ro trong bài Vibe coding là gì?.

Bản mô tả cũng là một prompt

Bản mô tả thực chất là một prompt dài và có cấu trúc. Những gì bạn đã biết ở công thức viết prompt 4 phần vẫn đúng: bối cảnh càng rõ, kết quả càng sát. Điểm khác là bản mô tả được dùng lại suốt dự án, nên đáng bỏ công viết cẩn thận một lần.

Nguồn tham khảo

Kiểm tra ngày 14/10/2026.

Viết bởi Thế cho AI247. Thấy hữu ích? Hãy chia sẻ cho người cần.

FacebookX