Bỏ qua để đến nội dung

Xây MVP Bằng AI

Level: L6 — AI Coding & Vibe Coding (Bài 12/12 theo thứ tự sản xuất — · Đối tượng: Người đã học đầy đủ bài 53-63, dự án tích lũy đã chạy

Sau bài này, bạn có thể:

  • Giải thích đúng nghĩa “MVP” (Minimum Viable Product) — không phải “sản phẩm thiếu tính năng”, mà là “đủ nhỏ để hoàn thành, đủ để mang lại giá trị thật.”
  • Áp dụng lại toàn bộ hành trình 8 giai đoạn cho 1 vòng lặp tính năng mới quy mô nhỏ: thêm khả năng AI tóm tắt cho dự án ghi chú.
  • Thực hiện lần đầu tiên việc gọi 1 API AI thật từ trong sản phẩm của bạn — áp dụng đúng khái niệm API đã học ở bài 55.
  • Đưa ra quyết định “đủ tốt để ra mắt” — luôn là quyết định của con người, không phải AI.

MVP không phải “phiên bản cụt” — mà là “phiên bản đủ giá trị nhỏ nhất”: đây là nhầm lẫn phổ biến nhất người mới hay mắc. MVP không có nghĩa “làm ẩu, thiếu tính năng cho nhanh” — nghĩa đúng là: phạm vi nhỏ nhất mà vẫn mang lại giá trị thật cho người dùng, đã qua đủ debug (bài 59), test (bài 61), bảo mật (bài 62), và deploy (bài 63) để dùng được thật, không chỉ “chạy trên máy tôi.”

Vì sao thêm 1 tính năng mới nghĩa là lặp lại cả hành trình, ở quy mô nhỏ: dự án tích lũy hiện đã qua đủ 7 giai đoạn đầu cho phần CRUD cơ bản. Thêm tính năng AI tóm tắt không phải chỉ là “viết thêm code” — đó là 1 vòng lặp mới của chính hành trình đã học, chỉ áp dụng cho 1 phạm vi nhỏ hơn:

  • BUILD (bài 56-58) — dùng Mega Prompt mô tả tính năng mới.
  • DEBUG (bài 59) — nếu có lỗi khi tích hợp AI tóm tắt.
  • IMPROVE/TEST/SECURE (bài 60-62) — refactor nếu cần, viết test cho tính năng mới, đặc biệt rà soát API key của dịch vụ AI tóm tắt (đã chuẩn bị cách lưu ở bài 62).
  • DEPLOY (bài 63) — deploy lại, lần này với biến môi trường chứa API key thật của dịch vụ AI tóm tắt.
  • SHIP — quyết định cuối: sản phẩm đã đủ tốt để coi là hoàn chỉnh.

Đây là lần đầu tiên dự án thực sự gọi 1 API AI — áp dụng đúng khái niệm đã học ở bài 55 (API là “đường dây” nối các lớp kiến trúc, ở đây là đường dây nối Backend của bạn với 1 dịch vụ AI bên ngoài): Backend nhận nội dung ghi chú dài, gửi qua API tới dịch vụ AI tóm tắt, nhận lại bản tóm tắt, trả về cho Frontend hiển thị — đúng chu trình request-response 4 bước đã học.

Đây là bài khép lại lời hứa của cả Level 6 (“Xây và deploy một ứng dụng AI hoàn chỉnh”): 1 ứng dụng ghi chú thường (CRUD cơ bản) trở thành 1 ứng dụng AI hoàn chỉnh khi có thêm khả năng tóm tắt bằng AI — đúng nghĩa Project đề ra từ đầu Level 6, không phải phép ẩn dụ.

Phân định AI vs con người (áp dụng cho toàn bộ vòng lặp capstone):

Điều bạn cần hiểu Điều AI có thể thực hiện Điều bạn phải xác nhận
Phạm vi MVP MVP = nhỏ nhất nhưng đủ giá trị thật, không phải “làm ẩu” Đề xuất phạm vi tính năng cụ thể Phạm vi đề xuất có thực sự mang lại giá trị, không chỉ “cho có tính năng AI”
Tích hợp API AI Đây là 1 API bên ngoài thật, cần API key thật (bài 62) Viết code gọi API, xử lý kết quả trả về API key đã được lưu đúng cách (biến môi trường, bài 63), không hardcode
Toàn bộ vòng lặp Mỗi giai đoạn cũ (Debug/Test/Secure/Deploy) áp dụng lại, không bỏ qua Thực hiện lại từng bước theo đúng công cụ đã học Không bỏ qua bước nào chỉ vì “đã quen, chắc không cần kiểm tra lại”
Ra mắt (Ship) Đây là quyết định duy nhất AI không bao giờ tự thực hiện Tổng hợp trạng thái hiện tại (test pass, đã deploy…) Quyết định “đủ tốt để ra mắt” — luôn là quyết định con người, đúng nguyên tắc đã học Level 5 (bài 52): “AI trình bày, con người quyết định”

Nếu 11 bài trước là xây, kiểm tra, và mở cửa ngôi nhà cho công chúng, bài này là lúc bạn lắp thêm 1 tiện ích thông minh vào ngôi nhà đã có người ở (ví dụ: hệ thống đèn tự động) — không phải xây lại từ đầu, mà là chạy lại đúng quy trình đã thành thạo (thiết kế→lắp đặt→kiểm tra→bật lên) ở quy mô nhỏ hơn nhiều, và bạn là người quyết định khi nào tiện ích đó đủ tốt để công bố cho người ở trong nhà biết tới.

Hoàn thiện dự án tích lũy: Trợ Lý Ghi Chú Cá Nhân Có AI Tóm Tắt.

  1. Xác định phạm vi MVP cho tính năng tóm tắt — ví dụ: “khi ghi chú dài hơn X từ, hiển thị nút ‘Tóm tắt bằng AI’; bấm vào gọi 1 dịch vụ AI tóm tắt, hiển thị kết quả.” Không cần tùy chỉnh độ dài tóm tắt, không cần lưu lịch sử tóm tắt — đó là mở rộng ngoài phạm vi MVP.
  2. BUILD — viết Mega Prompt (bài 56) mô tả tính năng trên, để Claude Code (bài 57) hỏi làm rõ trước khi xây.
  3. Chuẩn bị và lưu API key của dịch vụ AI tóm tắt theo đúng nguyên tắc đã học (bài 62): không hardcode.
  4. DEBUG/IMPROVE/TEST/SECURE — nếu gọi API lần đầu gặp lỗi (ví dụ: tóm tắt trả về rỗng), áp dụng đúng quy trình debug bài 59 (tái hiện → chẩn đoán → sửa → xác minh). Viết ít nhất 1 test cho tính năng mới (bài 61). Rà soát lại: API key có đang nằm đúng biến môi trường không (bài 62).
  5. DEPLOY — deploy lại (bài 63), lần này thiết lập thêm biến môi trường cho API key thật của dịch vụ AI tóm tắt trên môi trường Production.
  6. SHIP — tự tay thử tính năng trên URL Production thật, xác nhận hoạt động đúng, rồi tự quyết định: sản phẩm đã đủ tốt để coi là hoàn chỉnh phiên bản MVP.

Mega Prompt cho tính năng capstone (tiếp nối đúng khung đã học bài 56):

Dự án ghi chú hiện đã có: thêm/xem/xóa ghi chú, lưu trữ lâu dài, đã deploy
tại [URL Production].
Thêm tính năng: khi 1 ghi chú dài hơn 200 từ, hiển thị nút "Tóm tắt bằng
AI". Bấm vào, gửi nội dung ghi chú qua API tới dịch vụ tóm tắt AI, hiển
thị kết quả tóm tắt ngay dưới ghi chú gốc.
Phạm vi hiện tại: CHỈ cần tóm tắt hiển thị 1 lần khi bấm nút, CHƯA cần
lưu lại bản tóm tắt hay tùy chỉnh độ dài.
Trước khi bắt đầu, hỏi tôi bất kỳ điều gì chưa rõ, đặc biệt về cách lưu
API key an toàn.

Checklist capstone — xác nhận đủ 8 giai đoạn trước khi Ship:

[ ] UNDERSTAND: phạm vi MVP của tính năng mới đã rõ ràng, đủ nhỏ?
[ ] BUILD: tính năng đã chạy đúng trên môi trường local?
[ ] DEBUG: các lỗi phát sinh khi tích hợp API đã được sửa và xác minh?
[ ] IMPROVE: code tích hợp API có trùng lặp/rối cần dọn dẹp không?
[ ] TEST: đã có ít nhất 1 test cho tính năng mới?
[ ] SECURE: API key đã nằm đúng biến môi trường, không hardcode?
[ ] DEPLOY: đã deploy lại, tính năng chạy đúng trên URL Production?
[ ] SHIP: tôi (con người) xác nhận sản phẩm đủ tốt để coi là hoàn chỉnh.
1. Nhận feedback2. Lập kế hoạch3. Phát triển lặp
Hình 6.12 — MVP: hành trình 8 giai đoạn lồng nhau, vòng ngoài toàn bộ dự án, vòng trong 1 tính năng.
  1. Viết Mega Prompt cho tính năng AI tóm tắt theo khung ở mục 7 (hoặc tính năng AI khác phù hợp hơn với dự án bạn đã chọn).
  2. Thực hiện đủ 8 bước trong checklist ở mục 8, không bỏ qua bước nào.
  3. Tự tay thử tính năng trên URL Production thật.
  4. Viết 1 đoạn ngắn (2-3 câu) giải thích vì sao bạn quyết định sản phẩm đã (hoặc chưa) đủ tốt để “ship.”
  • Mở rộng phạm vi MVP quá lớn (thêm nhiều tùy chọn/tính năng phụ) thay vì giữ đúng phạm vi nhỏ nhất đủ giá trị — dễ khiến bài tập capstone kéo dài không kết thúc được.
  • Bỏ qua các bước Debug/Test/Secure vì “đã quen rồi, chắc không cần” — đúng rủi ro mà cả hành trình Level 6 được thiết kế để chống lại.
  • Để AI tự quyết định “đã sẵn sàng ship” — vi phạm nguyên tắc bất biến quan trọng nhất của cả Level 6 và Level 5 (bài 52): quyết định cuối luôn thuộc về con người.
  • Không tự tay thử trên Production thật trước khi coi là xong — chỉ tin test tự động (bài 61) là chưa đủ cho bước xác nhận cuối cùng.

13. Giới hạn & khi nào KHÔNG nên áp dụng

Phần tiêu đề “13. Giới hạn & khi nào KHÔNG nên áp dụng”
  • Bài này không dạy lại cách viết PRD — nếu bạn có ý tưởng tính năng mơ hồ, quay lại bài 51 (Level 5) trước để làm rõ vấn đề/giá trị trước khi xây.
  • Bài này không dạy tự thiết kế kiến trúc agent — nếu bạn muốn tự xây 1 agent phức tạp hơn (không chỉ dùng coding agent có sẵn), đó là phạm vi Level 8.
  • Dự án tích lũy hoàn thành ở bài này vẫn là 1 MVP cá nhân/học tập, chưa qua đầy đủ các bước cần thiết cho 1 sản phẩm thương mại thật (pháp lý, vận hành quy mô lớn, hỗ trợ khách hàng).

Nguyên tắc bất biến khép lại toàn bộ Level 6: dù đã áp dụng đúng mọi giai đoạn (Debug/Test/Secure/Deploy) một cách kỷ luật, quyết định cuối cùng “sản phẩm đã đủ tốt để ra mắt” không bao giờ là quyết định của AI — đúng nguyên tắc đã thiết lập từ Level 5 (bài 52: “AI trình bày, con người quyết định”) và tái khẳng định xuyên suốt Level 6 (bài 56, 59, 63). AI có thể tổng hợp trạng thái (test pass, đã deploy thành công), nhưng phán đoán “đủ tốt” đòi hỏi bối cảnh và trách nhiệm chỉ con người có.

  • Giữ phạm vi MVP thật nhỏ — dễ hoàn thành trọn vẹn hơn nhiều so với cố làm 1 phiên bản “đầy đủ tính năng.”
  • Chạy lại đúng checklist 8 giai đoạn cho mọi tính năng mới thêm sau này, không chỉ riêng bài capstone này — đây là thói quen áp dụng lâu dài, không phải bài tập 1 lần.
  • Ăn mừng đúng mức khi hoàn thành: dự án tích lũy giờ là 1 sản phẩm AI thật, chạy công khai, do bạn tự xây từ con số 0.
16. Nội dung nâng cao (không bắt buộc)

Sau khi hoàn thành bài này, dự án tích lũy có thể tiếp tục phát triển theo đúng cùng 1 hành trình 8 giai đoạn cho bất kỳ tính năng mới nào trong tương lai — đây chính là giá trị lâu dài của Level 6: không chỉ dạy xây 1 sản phẩm cụ thể, mà dạy 1 quy trình lặp lại được cho mọi sản phẩm AI bạn sẽ xây sau này, vượt ra ngoài phạm vi dự án ghi chú của riêng khóa học.

  • Không có nguồn Tier 1 mới — bài capstone tổng hợp lại toàn bộ bài 53-63 của Level 6, đúng vai trò đã xác định trong kế hoạch (Bước 1: “#64 không cần nguồn riêng ngoài tổng hợp #53-63”).
  • Dẫn chiếu (không trích dẫn mới): bài 51 (Level 5, PRD — ranh giới đầu vào); bài 52 (Level 5, nguyên tắc “AI trình bày, con người quyết định”); bài 55 (API, áp dụng thực tế lần đầu); bài 56 (Mega Prompt); bài 57 (Claude Code); bài 59-63 (Debug/Refactor/Test/Security/Deploy, áp dụng lại toàn bộ).

Không có claim mới cần kiểm chứng thời gian — bài tổng hợp lại nội dung đã kiểm chứng ở các bài trước (ngày kiểm chứng gốc: 2026-07-12, xem từng bài 53-63 để biết chi tiết nguồn của từng phần được tổng hợp lại).