Prompt đầu tiên: viết app brief để AI không build sai sản phẩm

Prompt đầu tiên trong vibe coding không nên là một câu thần chú. Nó nên là app brief. Nếu bạn viết “build me a beautiful dashboard”, AI sẽ build một thứ giống dashboard. Có card, chart, sidebar, màu đẹp, data mẫu. Nhưng nó có thể không giúp ai làm việc gì cụ thể. Lỗi không nằm ở model. Lỗi nằm ở đầu vào quá mơ hồ.

App brief tốt không cần dài. Nó cần đủ rõ để AI biết sản phẩm phục vụ ai, flow nào quan trọng, ranh giới bản đầu ở đâu, điều gì không được tự ý thêm, và kết quả cần test bằng cách nào. Vibe coding càng nhanh thì brief càng quan trọng. Không có brief, bạn chỉ đang tăng tốc đi sai hướng.

Đừng bắt đầu bằng UI, hãy bắt đầu bằng job

Người mới thường prompt theo hình ảnh trong đầu:

Build a clean modern app for managing bookings.

AI nghe được “clean modern” và “bookings”, nhưng không biết booking của ai. Nhà hàng khác studio chụp ảnh. Phòng khám khác lớp học yoga. Tour du lịch khác meeting room nội bộ. Cùng là booking, nhưng data, permission, reminder, payment, cancellation, timezone đều khác.

Prompt đầu tiên nên trả lời ba câu:

• Ai dùng app này?
• Họ cần hoàn thành việc gì?
• Bản đầu chỉ cần chứng minh flow nào?

Ví dụ:

Build a prototype for a small photography studio owner.
The owner needs to track upcoming shoot bookings and deposit status.
First version only needs the daily booking workflow: view bookings, add booking, edit deposit status, filter by date.

Đây vẫn chưa đủ để ship, nhưng đủ để tránh AI dựng một CRM tổng quát với analytics, campaign, invoice, staff schedule trong khi người dùng chỉ cần biết tuần này ai đã cọc.

Template app brief

Bạn có thể dùng template này cho prompt đầu tiên:

Build a [type of app] prototype.

Audience:
- [Who uses it]
- [Their skill level or context]

Main job-to-be-done:
- [The one job this app must help them do]

Core flows for version 1:
1. [Flow 1]
2. [Flow 2]
3. [Flow 3]

Data:
- Use [sample data / existing API / uploaded CSV].
- If using sample data, label it clearly and list what must become real later.

Constraints:
- [Device, language, timezone, accessibility, business rules]
- [Do not use mock auth / do not add payment / do not change existing files]

Visual direction:
- [Simple, dense dashboard, mobile-first, brand colors, reference screenshot]

Defer:
- [Things not in version 1]

After building:
- Tell me what is implemented.
- Tell me what is mock.
- Tell me what I should test manually.

Template này không làm prompt “pro” hơn theo kiểu prompt engineering. Nó làm scope rõ hơn. AI ít phải đoán. Bạn dễ review hơn vì biết mình đã yêu cầu gì.

Audience: nói rõ người dùng thật

Audience không chỉ là persona trang trí. Nó quyết định UI và workflow.

“Admin user” quá chung. “Chủ studio chụp ảnh, dùng laptop ban ngày và điện thoại khi ở ngoài location” cụ thể hơn nhiều. “PM nội bộ muốn track vendor invoice, không biết SQL, cần export CSV cho kế toán” sẽ dẫn tới app khác hoàn toàn so với “developer muốn debug API latency”.

Audience tốt nên có ba lớp:

• Vai trò: founder, PM, designer, owner, operator, customer.
• Bối cảnh: đang ở văn phòng, ngoài hiện trường, trên mobile, trong cuộc gọi, xử lý gấp.
• Trình độ kỹ thuật: không code, biết Excel, biết GitHub, developer.

Ví dụ:

Audience:
- A non-technical clinic receptionist.
- Uses the app on a desktop during patient check-in.
- Needs clear labels and low typing effort.

Từ đó AI sẽ có lý do để ưu tiên form rõ, table dễ scan, button ít mơ hồ. Nếu không nói, nó có thể dựng một UI “SaaS dashboard” nhìn đẹp nhưng không hợp người dùng.

Core flows: ít nhưng phải test được

Đừng liệt kê 20 feature trong prompt đầu tiên. Vibe coding mạnh vì nhanh, nhưng review của bạn vẫn có giới hạn. Một bản đầu có 3 flow test được tốt hơn một bản đầu có 15 feature nhìn như đầy đủ nhưng chẳng cái nào chắc.

Core flow nên viết bằng hành động:

Core flows:
1. Create a booking with customer name, phone, date, package, deposit status.
2. View bookings in a table sorted by upcoming date.
3. Filter by deposit status and shoot date.
4. Edit note and deposit status.

Không viết:

Features:
- Booking management
- Customer module
- Calendar
- Dashboard

“Booking management” nghe đúng nhưng không test được. “Create a booking with customer name, phone, date…” thì mở app lên test được ngay. Nếu AI build thiếu phone, bạn biết sai. Nếu filter không hoạt động, bạn biết sai.

Constraints: phần giúp AI không tự mở rộng scope

AI rất thích lấp khoảng trống. Bạn nói app booking, nó thêm login. Bạn nói dashboard, nó thêm chart. Bạn nói customer, nó thêm email campaign. Nhiều khi nhìn vui, nhưng làm rối bản đầu.

Hãy ghi rõ constraint:

Constraints:
- Do not add payment in version 1.
- Do not add staff management.
- Do not add email automation.
- Keep all labels in Vietnamese.
- Mobile layout must be usable at 390px width.

Constraint không phải để làm AI yếu đi. Nó giúp AI dùng năng lực đúng chỗ. Nếu bản đầu cần chứng minh flow booking, payment là nhiễu. Nếu đang prototype cho non-tech owner, multi-tenant role system là nhiễu. Sau này cần thì thêm lát riêng.

Defer list: chống “đẹp nhưng lệch”

Defer list là danh sách những thứ có vẻ liên quan nhưng chưa làm. Nó rất quan trọng vì AI thường đoán feature theo pattern phổ biến.

Ví dụ app quản lý lớp học:

Defer for later:
- Online payment
- Parent messaging
- Teacher payroll
- Attendance analytics
- Multi-branch management

Không có defer list, AI có thể thêm đủ thứ để app trông “complete”. Nhưng mỗi thứ thêm vào là một bề mặt review mới. Bạn phải kiểm tra UI, state, data, edge case. Một prototype nhiều feature giả tạo cảm giác tiến nhanh, nhưng nợ review tăng rất nhanh.

Visual direction: đủ để định hướng, không micromanage

Bạn nên nói visual direction, nhưng đừng biến prompt đầu thành spec pixel-perfect. Mục tiêu là định hướng gu và mật độ thông tin.

Tốt:

Visual direction:
- Work-focused dashboard, not a marketing landing page.
- Dense but readable table.
- Neutral background, clear status colors.
- Mobile first for quick checks.

Không tốt:

Make it beautiful, modern, stunning, premium, Apple-like.

Những chữ như stunning, premium, beautiful thường kéo AI về hero lớn, gradient, card nhiều, animation thừa. Với app vận hành, người dùng cần scan nhanh hơn là trầm trồ. Nếu bạn có screenshot hoặc brand reference, đưa vào context pack ở vòng sau.

Do-not-change: khi làm trên repo thật

Nếu bạn vibe coding trong repo đã có sẵn, prompt đầu tiên phải có do-not-change. Đây là khác biệt giữa prototype playground và codebase thật.

Ví dụ:

Do not change:
- Existing API routes.
- Existing auth logic.
- Database schema.
- Shared UI components.
- Package dependencies unless you ask first.

Nếu không có rule này, AI có thể sửa “cho tiện”: đổi schema, thêm endpoint, cài package mới, sửa global CSS. Với app mới trống, có thể chấp nhận. Với repo thật, đây là rủi ro.

Một prompt tốt trong repo thật cũng nên yêu cầu AI đọc trước:

Before editing, inspect existing hooks and API clients. Reuse them. If you cannot find a real endpoint, stop and tell me what is missing. Do not create mock data as a replacement.

Bad prompt vs improved prompt

Bad prompt:

Build a CRM for my travel business. Make it modern and include customers, bookings, payments, dashboard, invoices, reminders, and admin.

Prompt này quá rộng. AI có thể tạo app nhiều màn hình, nhưng hầu hết là giả. Bạn sẽ mất thời gian review những thứ chưa cần. Nếu dùng để demo nội bộ, mọi người dễ tranh luận về màu card thay vì flow bán tour.

Improved prompt:

Build a version 1 prototype for a small travel consultant who sells private tours.

Audience:
- Non-technical owner.
- Uses laptop during customer calls.

Main job-to-be-done:
- Track leads from first inquiry to confirmed tour.

Core flows:
1. Add a lead with customer name, WhatsApp, destination, travel date, group size, budget, status, note.
2. View leads in a table grouped by status: new, contacted, quoted, confirmed, lost.
3. Open a lead detail panel and update status and note.
4. Filter leads by travel month and status.

Data:
- Use clearly labeled sample data for this prototype.
- After building, list exactly what data is fake and what real API/database would be needed.

Constraints:
- Do not add payment, invoice, email automation, or staff roles yet.
- UI language is Vietnamese.
- Must be usable on desktop and mobile.

Visual direction:
- Practical operator dashboard.
- Compact table, clear status colors, no marketing hero.

After building:
- Give me a manual test checklist for the four core flows.

Prompt này vẫn để AI tự thiết kế nhiều chi tiết, nhưng sản phẩm có biên. Nếu kết quả sai, bạn biết sai ở đâu.

Checklist cho prompt đầu tiên

• Có nói rõ app phục vụ ai không?
• Có một main job-to-be-done không?
• Có tối đa 3-5 core flows cho version 1 không?
• Mỗi flow có thể click test được không?
• Có nói rõ dùng sample data hay real API không?
• Có defer list không?
• Có constraint về mobile, ngôn ngữ, auth, data, visual direction không?
• Có do not change nếu làm trong repo thật không?
• Có yêu cầu AI báo phần mock sau khi build không?

Nếu prompt của bạn không trả lời được các câu này, đừng gửi vội. Sửa prompt rẻ hơn sửa một app sai hướng.

Chốt lại

Prompt đầu tiên không phải câu mở khóa phép màu. Nó là app brief. Viết brief tốt giúp AI build ít lệch hơn, giúp bạn review ít mệt hơn, và giúp prototype giữ đúng việc cần chứng minh. Vibe coding không bắt đầu bằng “làm app đẹp”. Nó bắt đầu bằng “ai cần làm việc gì, trong bản đầu cần test flow nào, và AI không được tự ý thêm gì”.