Mình đã thử khá nhiều cách để build website bằng AI. Có lúc bắt đầu bằng một câu prompt rất mơ hồ, có lúc ngồi sửa code do AI sinh ra đến mức còn mệt hơn tự làm từ đầu. Sau vài vòng như vậy, mình nhận ra một điều khá rõ: AI không thay thế được tư duy sản phẩm, nhưng nó làm cho toàn bộ quá trình đi nhanh hơn rất nhiều nếu mình biết cách dẫn nó đi đúng hướng.
Bài này là cách mình đang làm thật, từ lúc nảy ý tưởng, viết prompt đầu tiên, dựng specs, chọn stack, chọn tool vibe code, cho tới lúc chuẩn bị release. Không phải công thức hoàn hảo, nhưng là workflow đủ thực tế để mình dùng lại nhiều lần.
Build website bằng AI, từ prompt đầu tiên đến lúc release
Mình không bắt đầu bằng code
Trước đây, mỗi lần muốn làm một website mới, mình hay có thói quen mở luôn công cụ AI lên rồi gõ đại kiểu: “make a modern website for my studio”. Kết quả thì không tệ, nhưng nhìn rất quen. Nó ra đúng kiểu website mà AI nào cũng có thể tạo ra: hero lớn, vài card, vài section bóng bẩy, nhưng không có cảm giác đây là website của riêng mình.
Mình mất khá lâu mới hiểu rằng thứ nên làm đầu tiên không phải là code, mà là làm rõ bài toán. Website này dành cho ai? Họ vào đây để làm gì? Mình muốn họ bấm vào nút nào? Nếu chỉ có một việc duy nhất cần xảy ra trên site này, đó là việc gì?
Chỉ cần trả lời mấy câu đó thôi, prompt đã khác hẳn. Thay vì yêu cầu một “website đẹp”, mình bắt đầu mô tả rõ hơn:
- Ai là người dùng chính?
- Mục tiêu business là gì?
- Trang nào cần có?
- Tone của thương hiệu ra sao?
- Cái gì là bắt buộc, cái gì là “nice to have”.
Càng cụ thể, AI càng bớt tự bịa.
Prompt đầu tiên nên như một brief ngắn
Nếu mình phải viết prompt đầu tiên cho một website mới, nó thường sẽ giống một brief hơn là một lời nhờ vả. Mình viết theo kiểu:
Tôi muốn build một website cho studio thiết kế.
Người dùng chính là founder startup và marketing manager.
Mục tiêu là đặt lịch tư vấn.
Cần các trang: Home, Services, Case Studies, About, Contact.
Tone: tối giản, hiện đại, premium, nhiều whitespace.
Ưu tiên tốc độ tải, SEO tốt và dễ chỉnh sửa nội dung.
Mình thấy prompt kiểu này hiệu quả hơn rất nhiều so với những câu chung chung. Nó không chỉ nói cho AI biết “làm gì”, mà còn nói rõ “vì sao làm”, “ai dùng”, và “đo thành công bằng gì”.
Điều thú vị là khi prompt đủ rõ, AI thường giúp mình nhìn thấy cả những thứ mình chưa nghĩ ra. Nó gợi ý thêm trang, thêm flow, thêm component hoặc thêm thứ tự ưu tiên cho nội dung. Mình không cần nhận hết, nhưng ít nhất nó giúp mình nghĩ có cấu trúc hơn.
Sau prompt là specs, không phải code
Một lỗi mình từng mắc là có prompt xong thì nhảy thẳng vào sinh code. Làm như vậy nhanh thật, nhưng dễ vỡ ở bước sau. Từ lúc mình chuyển sang yêu cầu AI viết specs trước, mọi thứ ổn hơn hẳn.
Specs ở đây không cần dài dòng như tài liệu công ty lớn. Mình chỉ cần một bản ngắn, đủ để mình biết:
- Mục tiêu sản phẩm là gì.
- Sitemap gồm những gì.
- User flow đi như thế nào.
- Có những tính năng nào.
- Cần những integration nào.
- Trước khi launch thì phải kiểm tra gì.
Mình thường nhờ AI viết specs theo format đó. Sau đó mình đọc lại, cắt bớt, chỉnh lại, rồi mới bắt đầu build. Cách này hơi chậm hơn một chút ở đầu, nhưng tiết kiệm rất nhiều thời gian về sau.
Mình học được rằng AI làm tốt nhất khi mình đưa cho nó ranh giới rõ ràng. Không có specs, nó thường sinh ra những quyết định khá ngẫu nhiên. Có specs, nó bắt đầu giống một người cộng sự hơn.
Chọn stack thì nên thực dụng
Mình không còn tin vào việc “stack nào hot thì dùng stack đó”. Mình chọn công nghệ theo loại website, không chọn theo cảm hứng trên mạng.
Stack (ngăn xếp) trong IT thường được hiểu theo hai nghĩa chính: Cấu trúc dữ liệu hoạt động theo nguyên lý LIFO (Vào sau – Ra trước), và Technology Stack (tập hợp công nghệ) dùng để phát triển ứng dụng. Stack thường dùng để quản lý gọi hàm, đảo ngược dữ liệu, hoặc duyệt đồ thị.
Nếu là website giới thiệu dịch vụ, portfolio, blog cá nhân, landing page hay site nội dung, mình muốn stack đơn giản, nhanh, dễ deploy và dễ sửa. Nếu là web app có auth, data, dashboard, billing hoặc email flow, mình sẽ nghĩ khác.
Hiện tại, khi build bằng AI, mình thường nghĩ theo hướng này:
- Site giới thiệu / content site: Next.js hoặc Astro.
- Web app nhỏ hoặc SaaS MVP: Next.js + Supabase.
- Deploy: Vercel.
- Email, auth, data: chọn dịch vụ gọn, có tài liệu tốt và ít ma sát.
Mình thích combo này vì AI hỗ trợ rất tốt khi stack đủ phổ biến để nó biết bối cảnh, nhưng không quá phức tạp đến mức mình phải sửa thủ công quá nhiều. Với mình, cái giá trị lớn nhất không phải là “dùng tech mới”, mà là giữ được tốc độ mà vẫn kiểm soát được chất lượng.
Tool vibe code nên chia theo vai trò
Khoảng một năm gần đây, mình thấy nhiều người dùng cụm “vibe code” để chỉ cách build bằng cách nói chuyện với AI. Mình không phản đối cụm từ này, nhưng mình nghĩ muốn vibe code hiệu quả thì phải bớt “vibe” một chút ở khâu tổ chức.
Cụm “vibe code” nghe vui, nhưng nếu dùng lung tung thì rất dễ loạn. Mình thấy hiệu quả nhất là chia AI thành từng vai khác nhau trong từng giai đoạn.
Ví dụ:
- Một tool dùng để brainstorm và làm rõ brief.
- Một tool dùng để viết specs.
- Một tool dùng để generate code.
- Một tool dùng để review, sửa bug và refactor.
- Một tool dùng để viết checklist release.
Lúc đầu mình cứ tưởng chỉ cần một cửa sổ chat là đủ cho tất cả mọi thứ: brainstorm, viết specs, generate code, sửa bug, deploy. Nhưng càng làm nhiều, mình càng thấy chia vai rõ ràng giúp đỡ mệt hơn rất nhiều. Mỗi lần mình yêu cầu một việc cụ thể, AI trả lời thường gọn hơn, chính xác hơn, và ít bị trôi ngữ cảnh hơn.
Mình cũng hay chia prompt thành từng task nhỏ thay vì yêu cầu “build cả website”. Ví dụ:
- Tạo project structure trước.
- Viết homepage sau.
- Tạo contact form riêng.
- Thêm SEO metadata riêng.
- Cuối cùng mới đi qua phần release settings.
Làm theo nhịp này, mình thấy AI giống một senior pair programmer hơn là một cái máy sinh code.
Mình thích prompt có cấu trúc
Một prompt tốt với mình không cần hoa mỹ. Nó chỉ cần rõ. Mình hay dùng một khung rất đơn giản:
Context + Goal + Constraints + Output format + Quality bar
Ví dụ:
Bạn là senior product engineer.
Hãy giúp tôi build website cho studio thiết kế.
Mục tiêu là tăng lead booking.
Stack ưu tiên: Next.js, Tailwind, Vercel.
Yêu cầu: responsive, SEO tốt, code sạch, dễ maintain.
Hãy trả ra theo 3 phần: tech decisions, project structure, implementation plan.
Mình thích cách này vì nó buộc AI phải trả lời đúng thứ mình cần. Nếu prompt chỉ “làm website đi”, mình gần như chắc chắn sẽ nhận lại một bản code hay nhưng chưa chắc dùng được. Nếu prompt có cấu trúc, đầu ra thường sát với nhu cầu thật hơn nhiều.
Prompt để viết specs
Hãy chuyển brief này thành MVP specs, gồm sitemap, user flow, component list, integration needs, analytics events và launch checklist.
Prompt để chọn stack
Với specs này, hãy so sánh Astro và Next.js theo tiêu chí SEO, performance, flexibility, độ phù hợp cho solo builder, và khuyến nghị một lựa chọn.
Prompt để scaffold code
Tạo khung dự án Next.js app router với layout, metadata, homepage, contact page, shared UI components và cấu trúc thư mục dễ maintain.
Prompt để chuẩn bị release
Dựa trên dự án này, hãy sinh production checklist cho Vercel + Supabase, gồm env vars, auth URLs, webhook URLs, SMTP, analytics, error tracking.
Bước mình không còn bỏ qua: release checklist
Nếu phải chọn ra một chỗ mà AI thường khiến người ta chủ quan, mình nghĩ đó là giai đoạn cuối. Local chạy ngon không có nghĩa là đã sẵn sàng release. Đây là lúc mình từng chủ quan nhất, và cũng là lúc mình thấy lỗi phát sinh nhiều nhất.
Một website hoặc app có thể nhìn rất ổn trên máy mình, nhưng lên production thì lại vấp ở những thứ rất “chán” như:
- Env vars thiếu.
- Auth callback sai.
- Webhook chưa cấu hình.
- Email chưa gửi được.
- Domain production chưa khớp.
- Analytics chưa hoạt động.
Từ khi mình làm nghiêm túc hơn, mình luôn yêu cầu AI sinh ra một checklist release riêng cho dự án đó. Với mình, đây là một trong những cách tốt nhất để biến một demo thành một sản phẩm có thể ship thật.
Những setting mình luôn kiểm tra trước khi bấm release
Nếu dùng Vercel, mình luôn kiểm tra từng môi trường riêng: Development, Preview và Production. Mình không còn xem env vars là chuyện “để sau”. Có lần mình deploy xong mới phát hiện biến môi trường chưa được set đúng cho production, và bài học đó đủ đau để mình không quên nữa.
Nếu dự án có Supabase, mình sẽ rà thêm các phần như:
- Production project đã tách riêng chưa.
- Migrations đã được push lên production chưa.
- Auth redirect URL đã đúng chưa.
- Email template có ổn không.
- SMTP thật đã được set chưa.
- Webhook đã test chưa.
Tất cả mấy thứ này nghe không sexy chút nào, nhưng nó là thứ giữ cho website sống được ngoài đời thực. Mình càng làm nhiều, càng thấy release không phải là một nút bấm, mà là một trạng thái mà mình phải chuẩn bị khá kỹ.
Checklist tối thiểu của mình thường có:
- Repo đã nối với Vercel.
- Production branch đúng.
- Domain đã trỏ đúng.
- Tất cả env vars đã set đủ cho Production.
- Nếu có Preview, env vars cho Preview cũng đã tách rõ.
- Metadata cơ bản như title, description, OG image đã có.
- Form chạy được ở domain production.
- Analytics nhận đúng event chính.
- Error tracking đang hoạt động.
- Auth callback URL đúng domain thật.
- Email gửi được bằng SMTP thật.
- Webhook đã test nếu có payment hoặc automation.
- Các trang legal không còn placeholder.
- Nội dung demo, logo, favicon, link test đã được thay hết.
Thực tế, chỉ cần thiếu một bước trong mớ này, bản deploy có thể “chạy” nhưng không “dùng được”.
Workflow mình đang dùng
Nếu tóm lại thật ngắn, workflow hiện tại của mình là thế này:
- Viết brief rõ.
- Nhờ AI chuyển brief thành specs.
- Chọn stack theo loại website, không theo trend.
- Chia task thành từng phần nhỏ.
- Dùng AI để sinh code theo từng task.
- Tự review lại logic, responsive, SEO và maintainability.
- Cuối cùng mới xử lý release checklist và production settings.
Mình không nghĩ cách này là cách duy nhất đúng. Nhưng với mình, nó đủ cân bằng giữa tốc độ và kiểm soát. AI làm mình đi nhanh hơn, nhưng không làm mình mất quyền quyết định.
Điều mình rút ra sau nhiều lần làm
Sau vài lần build website bằng AI, mình thấy AI giỏi nhất ở chỗ giúp mình đi từ ý tưởng đến một bản rất gần production nhanh hơn nhiều. Nó giỏi tạo scaffold, giỏi giúp mình suy nghĩ có cấu trúc, và giỏi nhắc mình những thứ dễ quên ở bước release.
Nhưng AI chỉ thật sự hữu ích khi mình không trao hết quyền kiểm soát cho nó. Mình vẫn phải là người hiểu bài toán, hiểu người dùng và hiểu lúc nào nên dừng generate để chuyển sang review.
Có lẽ đó là điều mình thích nhất ở workflow này: nó không biến mình thành người “ngồi xem AI làm”, mà biến mình thành người ra quyết định nhanh hơn. Và với mình, đó mới là điểm đáng giá nhất.
Demo dự án mình đã vibe coding để có kinh nghiệm viết ra bài này:
Để lại một bình luận