Mở đầu — vì sao bài này quan trọng
Trong suốt khóa học, chúng ta đã học rất nhiều kỹ thuật riêng lẻ: zero-shot, few-shot, chain-of-thought, structured output, prompt chaining, tool use, RAG... Mỗi kỹ thuật giống như một viên gạch. Nhưng người mới học thường mắc một lỗi tâm lý: họ tưởng phải thành thạo hết toàn bộ mới dám bắt tay làm sản phẩm thật. Kết quả là họ học mãi mà không ship được gì.
Bài học hôm nay là liều thuốc giải cho tâm lý đó. Chúng ta sẽ theo chân Mai — một founder solo, không phải developer — trong hành trình 30 ngày biến một ý tưởng trong đầu thành một MVP (Minimum Viable Product — sản phẩm khả dụng tối thiểu) có người dùng thật và doanh thu thật. Điều đặc biệt: Mai không viết code truyền thống theo kiểu ngồi gõ từng dòng. Cô dùng prompt engineering làm "đòn bẩy" trung tâm — vừa để AI viết code, vừa để AI trở thành tính năng lõi của sản phẩm.
Vì sao case study này quan trọng với bạn? Vì nó cho thấy prompt engineering không phải một kỹ năng học thuật. Nó là một lợi thế cạnh tranh có thể nén thời gian phát triển sản phẩm từ 6 tháng xuống còn 1 tháng, và từ một đội 5 người xuống còn một người. Nếu bạn đang ấp ủ một ý tưởng, đây chính là bản đồ để bạn đi từ số 0 đến sản phẩm đầu tiên.
Khái niệm cốt lõi
MVP dưới góc nhìn của prompt engineering
MVP truyền thống được định nghĩa là phiên bản nhỏ nhất của sản phẩm đủ để kiểm chứng một giả thuyết kinh doanh. Với một solo founder không biết code, rào cản lớn nhất luôn là kỹ thuật: ai sẽ dựng backend, ai viết frontend, ai xử lý database?
Prompt engineering thay đổi cuộc chơi ở hai vai trò tách biệt mà bạn cần phân biệt rõ:
- Prompt để xây dựng sản phẩm (build-time): Bạn dùng AI như một lập trình viên. Prompt chính là ngôn ngữ bạn "thuê" AI viết code, dựng giao diện, sinh schema database, viết test. Đây là lúc bạn áp dụng các kỹ thuật đã học để yêu cầu output có cấu trúc, ràng buộc rõ ràng, và lặp lại nhiều vòng.
- Prompt là tính năng của sản phẩm (run-time): Sản phẩm của bạn có một tính năng thông minh — ví dụ tự động phân loại email khách hàng, tóm tắt phản hồi, sinh mô tả. Tính năng đó chạy bằng một prompt được nhúng trong code. Prompt này phải ổn định, rẻ và an toàn vì nó chạy với dữ liệu người dùng thật.
Nguyên tắc "vertical slice" — cắt lát dọc thay vì lát ngang
Sai lầm kinh điển khi làm MVP là xây từng tầng ngang: xong toàn bộ database rồi mới làm backend, xong backend mới làm giao diện. Cách này khiến bạn không thấy sản phẩm chạy được cho tới tận cuối. Nguyên tắc đúng là vertical slice — chọn MỘT luồng người dùng quan trọng nhất (ví dụ: tạo một sự kiện và bán vé), rồi làm trọn vẹn luồng đó từ giao diện xuống database. Có một luồng chạy thật còn hơn có mười tính năng dở dang.
Ràng buộc phạm vi bằng chính prompt
Khi dùng AI viết code, prompt của bạn cũng chính là công cụ kiểm soát phạm vi. Nếu bạn mô tả mông lung, AI sẽ sinh ra một hệ thống phình to. Nếu bạn ràng buộc chặt ("chỉ dùng một file HTML, một bảng dữ liệu, không cần đăng nhập phức tạp"), AI sẽ giữ đúng ngân sách kỹ thuật. Đây là lúc kỹ thuật constraint prompting mà bạn đã học phát huy tác dụng ngoài đời thật.
Tình huống thực tế
Ví dụ 1 — Mai và "TicketLite": từ ý tưởng đến bản demo trong 7 ngày
Bối cảnh. Mai từng làm marketing cho các sự kiện âm nhạc ở TP.HCM. Cô liên tục thấy các nhà tổ chức nhỏ — quán cà phê acoustic, workshop gốm, standup comedy — phải quản lý vé bằng Google Form cộng file Excel, dẫn tới bán trùng chỗ và không biết ai đã check-in. Ý tưởng của cô: TicketLite, một SaaS quản lý vé sự kiện gọn nhẹ cho thị trường Việt. Vấn đề: Mai không biết lập trình.
Diễn giải. Thay vì đi thuê agency với báo giá 80–120 triệu đồng, Mai quyết định tự dựng MVP bằng AI. Cô bắt đầu bằng một prompt "kiến trúc" rất ràng buộc:
> "Bạn là một senior full-stack developer. Hãy đề xuất kiến trúc đơn giản nhất cho MVP quản lý vé sự kiện, chỉ phục vụ tối đa 100 sự kiện và 5.000 vé. Ràng buộc: một người dùng tự triển khai được, không cần DevOps, chi phí dưới 500.000đ/tháng. Trả về dưới dạng: (1) stack đề xuất, (2) 3 bảng database chính với cột, (3) 4 màn hình cốt lõi. Không giải thích dài dòng."
AI đề xuất một stack nhẹ (một app web đơn giản + database dạng hosted). Điều quan trọng là Mai đã ép AI trả lời trong ngân sách và quy mô thực tế, thay vì để nó vẽ ra một hệ thống microservices hoành tráng. Trong 7 ngày, bằng cách chia nhỏ từng màn hình và yêu cầu AI viết từng phần (prompt chaining ở tầng build-time), cô có một bản demo tạo được sự kiện và sinh mã QR cho vé.
Bài học rút ra. Prompt đầu tiên của một MVP không nên là "viết code" mà là "ràng buộc phạm vi". Người điều khiển AI giỏi là người biết nói "không" với những gì AI muốn thêm vào.
Ví dụ 2 — Tính năng lõi chạy bằng prompt: tự động phân loại yêu cầu hỗ trợ
Bối cảnh. Sau khi có 12 nhà tổ chức dùng thử, Mai nhận ra điểm đau lớn nhất không phải bán vé, mà là hỗ trợ người mua vé: người mua nhắn tin hỏi đủ thứ — "đổi được vé không?", "sự kiện hoãn thì sao?", "chưa nhận được QR". Mai một mình không trả lời xuể.
Diễn giải. Đây là lúc prompt trở thành tính năng sản phẩm, không còn là công cụ build. Mai nhúng một prompt phân loại vào TicketLite để tự động gắn nhãn mỗi tin nhắn đến:
> "Phân loại tin nhắn của người mua vé vào đúng một nhãn: [HOÀN_VÉ, ĐỔI_VÉ, KHÔNG_NHẬN_ĐƯỢC_VÉ, HỎI_THÔNG_TIN_SỰ_KIỆN, KHÁC]. Trả về JSON: {\"nhan\": \"...\", \"do_khan\": \"cao|trung_binh|thap\"}. Chỉ trả JSON, không giải thích."
Những tin nhãn KHÔNG_NHẬN_ĐƯỢC_VÉ và độ khẩn "cao" được đẩy lên đầu hàng đợi. Nhờ output có cấu trúc JSON, Mai kết nối thẳng kết quả vào bảng điều khiển mà không cần xử lý ngôn ngữ phức tạp. Cô ước tính việc này cắt được khoảng 60% thời gian đọc và sắp xếp tin nhắn thủ công.
Điểm tinh tế: ở tầng run-time này, Mai phải thêm một câu ràng buộc an toàn — nếu tin nhắn không rõ, mặc định gắn nhãn KHÁC thay vì đoán bừa. Prompt production khác prompt thử nghiệm ở chỗ nó phải có hành vi mặc định an toàn khi gặp trường hợp lạ.
Bài học rút ra. MVP không nhất thiết phải "thông minh toàn diện". Chỉ cần một prompt phân loại đặt đúng chỗ đau nhất cũng đủ tạo ra giá trị cảm nhận rõ rệt cho người dùng.
Ví dụ 3 — Solo founder ở Đông Nam Á: bài học từ một cú vấp
Bối cảnh. Hãy đối chiếu với Tuấn, một founder ở Đà Nẵng cùng thời điểm cũng dựng MVP bằng AI — một công cụ sinh mô tả sản phẩm cho các shop bán hàng online. Anh ship nhanh hơn Mai, chỉ 18 ngày. Nhưng sang tháng thứ hai, hóa đơn API của anh vọt lên gần 9 triệu đồng vì mỗi lần người dùng bấm nút, anh gửi cả một prompt dài 3.000 token kèm 8 ví dụ few-shot cho mọi yêu cầu, kể cả yêu cầu đơn giản.
Diễn giải. Tuấn đã bỏ qua bước tính toán token economy (bài về context window và cost optimization trong khóa này). MVP của anh chạy được nhưng không bền về chi phí. Anh phải dừng lại, rút gọn số ví dụ few-shot, và chỉ dùng prompt "nặng" cho các trường hợp thật sự cần. Sau khi tối ưu, chi phí giảm hơn một nửa mà chất lượng gần như không đổi.
Bài học rút ra. Với solo founder, ship nhanh là cần thiết nhưng "ship nhanh mà không kiểm soát chi phí prompt run-time" là một cái bẫy. MVP thành công là MVP vừa chạy được vừa không đốt cạn túi tiền của bạn trước khi kịp có doanh thu.
Hướng dẫn từng bước
Đây là lộ trình 30 ngày mà bạn có thể áp dụng, chưng cất từ cách Mai đã làm:
Tuần 1 — Định hình và cắt lát (ngày 1–7).
- Viết một câu duy nhất mô tả sản phẩm: "TicketLite giúp [ai] làm [việc gì] nhanh hơn [cách cũ]." Nếu không viết nổi một câu, ý tưởng còn quá mờ.
- Chọn một vertical slice — một luồng người dùng cốt lõi. Với Mai là: tạo sự kiện → sinh vé QR.
- Dùng "prompt kiến trúc" ràng buộc phạm vi và ngân sách như ví dụ 1. Ép AI trả về stack tối giản.
- Dựng bản demo chạy được của đúng một luồng đó. Chưa cần đẹp.
- Chia sản phẩm thành các mẩu nhỏ, mỗi mẩu một prompt. Yêu cầu AI viết từng màn hình, từng hàm.
- Luôn yêu cầu output đầy đủ, có thể chạy được, kèm hướng dẫn chạy. Khi lỗi, dán nguyên thông báo lỗi vào cho AI sửa.
- Lưu lại các prompt build-time hiệu quả để tái dùng — chúng là tài sản.
- Xác định MỘT tính năng thông minh tạo giá trị rõ nhất (với Mai là phân loại hỗ trợ).
- Viết prompt run-time với output có cấu trúc (JSON), có hành vi mặc định an toàn.
- Ước lượng token mỗi lần gọi và nhân với số lần dùng dự kiến/tháng. Nếu quá đắt, rút gọn ví dụ.
- Mời 5–10 người dùng thật (không phải bạn bè khen lấy lệ). Mai chọn đúng các nhà tổ chức cô từng quen.
- Quan sát chỗ họ vấp. Sửa đúng chỗ đó, đừng thêm tính năng mới.
- Đặt một cơ chế thu tiền tối giản, dù chỉ là chuyển khoản thủ công, để kiểm chứng người ta có sẵn sàng trả tiền không.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm lẫn giữa prompt build-time và run-time. Nhiều người dùng đúng một prompt lỏng lẻo cho cả hai. Prompt viết code có thể tùy hứng; prompt chạy production phải chặt chẽ, có ràng buộc và hành vi mặc định. Hãy giữ chúng ở hai "tư duy" khác nhau.
Lỗi 2 — Ôm đồm quá nhiều tính năng trong MVP. Tâm lý "làm luôn cho đủ" giết chết tốc độ. Mẹo: viết ra danh sách tính năng mơ ước, rồi gạch bỏ đến khi còn đúng một luồng. Mọi thứ bị gạch sẽ là bản cập nhật sau, không phải bây giờ.
Lỗi 3 — Bỏ qua token economy như trường hợp của Tuấn. Mẹo: trước khi ship tính năng run-time, làm một phép tính đơn giản trên giấy — token mỗi lần gọi × số lần/tháng × đơn giá. Con số này quyết định MVP của bạn có sống nổi qua tháng thứ hai không.
Lỗi 4 — Tin tưởng mù quáng vào code AI sinh ra. AI viết code rất nhanh nhưng đôi khi sai tinh vi, nhất là ở phần xử lý tiền và dữ liệu người dùng. Mẹo: với các phần nhạy cảm, yêu cầu AI viết kèm test và tự bạn kiểm thử luồng đó bằng tay ít nhất một lần.
Lỗi 5 — Không nói chuyện với người dùng đủ sớm. Solo founder dễ rơi vào "hang động", cắm mặt xây dựng suốt tháng rồi mới cho người dùng xem. Mẹo: đưa bản demo xấu xí cho người dùng ngay từ tuần 2. Phản hồi sớm đáng giá hơn một sản phẩm bóng bẩy nhưng sai hướng.
Mẹo tổng quát: Hãy coi prompt của bạn — cả build-time lẫn run-time — là tài sản có thể tái sử dụng. Mai xây được một "thư viện prompt" riêng, và ở sản phẩm thứ hai cô đi nhanh hơn gấp đôi vì không phải bắt đầu từ con số không.
Bài tập thực hành
- Câu một dòng. Lấy một ý tưởng sản phẩm bất kỳ của bạn và viết nó thành đúng một câu theo mẫu "[Sản phẩm] giúp [ai] làm [việc gì] nhanh hơn [cách cũ]". Nếu chưa viết được, đó là dấu hiệu cần thu hẹp ý tưởng.
- Prompt kiến trúc ràng buộc. Viết một prompt yêu cầu AI đề xuất kiến trúc MVP cho ý tưởng của bạn, trong đó bắt buộc có ít nhất ba ràng buộc cụ thể (quy mô, ngân sách, mức độ đơn giản). Chạy thử và quan sát AI có tôn trọng ràng buộc không.
- Một prompt run-time. Chọn một tính năng thông minh nhỏ trong sản phẩm của bạn (phân loại, tóm tắt, trích xuất) và viết prompt run-time cho nó với: output JSON có cấu trúc rõ ràng, và một hành vi mặc định an toàn khi gặp đầu vào lạ.
- Phép tính token economy. Ước lượng số token mỗi lần gọi prompt ở bài 3, giả định 1.000 lượt dùng mỗi tháng, và tính chi phí dự kiến. Nếu quá cao, viết lại phiên bản gọn hơn và so sánh.
- Cắt lát dọc. Liệt kê 8 tính năng bạn muốn có, rồi gạch bỏ đến khi còn đúng một vertical slice. Viết ra lý do vì sao slice còn lại là quan trọng nhất.
Tóm tắt
Case study của Mai và TicketLite cho thấy một solo founder không biết code hoàn toàn có thể ship một MVP thật trong 30 ngày, nếu biết dùng prompt engineering như đòn bẩy trung tâm. Ba ý cốt lõi cần khắc ghi:
- Phân biệt hai vai trò của prompt: build-time (thuê AI viết code, thoải mái thử sai) và run-time (prompt là tính năng, phải chặt chẽ, có cấu trúc và an toàn).
- Cắt lát dọc và ràng buộc phạm vi: một luồng chạy trọn vẹn thắng mười tính năng dở dang; và chính prompt của bạn là công cụ kiểm soát phạm vi.
- Ship nhanh nhưng bền: đừng như Tuấn quên mất token economy; hãy tính chi phí trước khi tính năng chạy với người dùng thật, và đưa bản demo tới người dùng sớm nhất có thể.