Prompt Gemini tạo website
Bùi Tấn Lực - 103
- 08/10/2026
Gemini có thể hỗ trợ từ khâu lên ý tưởng, xây dựng giao diện đến viết và chỉnh sửa mã cho một website. Tuy nhiên, chất lượng website nhận được phụ thuộc rất lớn vào cách mô tả yêu cầu. Một câu lệnh quá ngắn như “hãy tạo cho tôi một website bán hàng đẹp” thường chỉ cho ra một kết quả mang tính minh họa, bởi Gemini chưa biết chính xác website dành cho ai, cần những chức năng nào, phong cách ra sao và phải xử lý nội dung theo hướng nào.
Muốn sử dụng Gemini hiệu quả khi làm website, cần xem prompt như một bản đặc tả ngắn cho dự án. Prompt càng xác định rõ mục tiêu, cấu trúc trang, đối tượng sử dụng, công nghệ, giao diện, chức năng và tiêu chí hoàn thiện thì kết quả càng dễ kiểm soát. Quan trọng hơn, không nhất thiết phải viết một prompt thật dài ngay từ đầu. Với dự án phức tạp, có thể chia quá trình thành nhiều bước và yêu cầu Gemini cải thiện từng phần.
Prompt tạo website cần xác định những gì?
Một prompt tốt không đơn thuần nói cho Gemini biết “hãy tạo website”, mà phải trả lời được những câu hỏi cơ bản của một dự án web. Website phục vụ mục đích gì? Người truy cập là ai? Họ cần làm gì trên trang? Website có những trang nào? Giao diện cần truyền tải cảm giác nào? Mã nguồn phải dùng công nghệ gì? Những yếu tố nào bắt buộc phải có và những yếu tố nào không được xuất hiện?
Có thể hình dung một prompt tạo website gồm nhiều lớp thông tin. Không phải dự án nào cũng cần khai báo tất cả, nhưng càng nhiều yêu cầu ảnh hưởng trực tiếp đến sản phẩm thì càng nên mô tả rõ.
- Mục tiêu: xác định website dùng để bán hàng, giới thiệu doanh nghiệp, làm portfolio, cung cấp dịch vụ, đăng bài viết, giới thiệu sản phẩm hay thực hiện một nhiệm vụ cụ thể.
- Đối tượng: mô tả người sử dụng chính để Gemini lựa chọn cách trình bày nội dung và giao diện phù hợp.
- Cấu trúc: xác định các trang hoặc khu vực quan trọng như trang chủ, sản phẩm, chi tiết sản phẩm, giới thiệu, liên hệ, blog hoặc tài khoản.
- Chức năng: nêu rõ tìm kiếm, lọc, giỏ hàng, biểu mẫu, đăng nhập, đăng ký, đặt lịch, quản lý dữ liệu hoặc các tương tác cần thiết.
- Thiết kế: mô tả màu sắc, phong cách, bố cục, kiểu chữ, khoảng cách, hình ảnh và cảm giác tổng thể.
- Công nghệ: chỉ định HTML, CSS, JavaScript, PHP, framework hoặc thư viện cần sử dụng nếu dự án có yêu cầu kỹ thuật cụ thể.
- Responsive: yêu cầu giao diện hoạt động tốt trên điện thoại, máy tính bảng và màn hình lớn.
- Đầu ra: yêu cầu Gemini trả về mã hoàn chỉnh, chia thành file riêng hoặc trình bày theo cấu trúc nhất định.
- Giới hạn: chỉ rõ những thành phần không được sử dụng, chẳng hạn không dùng thư viện ngoài, không tạo dữ liệu giả hoặc không thay đổi cấu trúc đã có.
Điểm quan trọng là không nên đưa mọi thứ vào prompt theo kiểu liệt kê ngẫu nhiên. Các yêu cầu nên được sắp xếp theo nhóm để Gemini dễ phân biệt đâu là mục tiêu, đâu là bối cảnh, đâu là ràng buộc và đâu là kết quả cuối cùng cần tạo.
Ví dụ, thay vì viết một câu rất ngắn:
Hãy tạo website bán giày đẹp, hiện đại và responsive.
có thể mô tả rõ hơn:
Hãy tạo giao diện website bán giày thể thao dành cho khách hàng từ 18 đến 35 tuổi.
Mục tiêu:
- Giới thiệu các mẫu giày mới.
- Cho phép người dùng xem danh sách và chi tiết sản phẩm.
- Có chức năng tìm kiếm và lọc sản phẩm.
Cấu trúc:
- Trang chủ.
- Danh sách sản phẩm.
- Trang chi tiết sản phẩm.
- Giới thiệu.
- Liên hệ.
Thiết kế:
- Phong cách hiện đại, tối giản.
- Hình ảnh sản phẩm là thành phần nổi bật.
- Bố cục rõ ràng, nhiều khoảng trắng.
- Màu nền sáng, màu nhấn tương phản.
- Có trạng thái hover cho các nút và thẻ sản phẩm.
Kỹ thuật:
- Sử dụng HTML, CSS và JavaScript thuần.
- Không dùng framework.
- Giao diện responsive cho điện thoại, máy tính bảng và desktop.
- Code có cấu trúc rõ ràng, dễ tiếp tục phát triển.
Hai cách yêu cầu trên cùng hướng đến một website bán giày, nhưng cách thứ hai cung cấp cho Gemini nhiều thông tin để đưa ra quyết định. Đây là khác biệt quan trọng giữa việc yêu cầu AI “tạo một website” và việc đưa cho AI một bản mô tả đủ rõ để bắt đầu triển khai.
Cách mô tả website để Gemini không tự đoán quá nhiều
Một trong những nguyên nhân khiến kết quả tạo website không đúng ý là prompt bỏ trống quá nhiều thông tin. Khi thiếu yêu cầu, Gemini buộc phải tự quyết định. Nó có thể tự chọn màu sắc, số lượng khu vực, tên menu, nội dung mẫu, cách bố trí sản phẩm hoặc công nghệ triển khai. Những lựa chọn này có thể hợp lý nhưng chưa chắc phù hợp với dự án thực tế.
Vì vậy, với những thành phần quan trọng, nên chuyển yêu cầu từ dạng cảm tính sang dạng có thể kiểm tra được.
Chẳng hạn, “giao diện sang trọng” vẫn khá mơ hồ. Có thể cụ thể hóa thành “nền sáng, màu nhấn tối, kiểu chữ dễ đọc, bố cục thoáng, hình ảnh lớn, hạn chế hiệu ứng chuyển động”. Gemini khi đó có cơ sở rõ ràng hơn để thiết kế.
Tương tự, thay vì nói “trang chủ đầy đủ chức năng”, nên liệt kê những khu vực thực sự cần có:
- Thanh điều hướng.
- Khu vực giới thiệu chính.
- Danh mục nổi bật.
- Sản phẩm mới.
- Sản phẩm bán chạy.
- Ưu điểm của doanh nghiệp.
- Đánh giá khách hàng.
- Thông tin liên hệ.
- Chân trang.
Cách mô tả này không có nghĩa phải áp dụng tất cả các khu vực cho mọi website. Ngược lại, chỉ nên đưa vào những thành phần thực sự phục vụ mục tiêu của trang. Một website dịch vụ có thể cần phần giới thiệu dịch vụ, quy trình, dự án và biểu mẫu liên hệ; trong khi một website portfolio có thể ưu tiên dự án, kỹ năng và thông tin cá nhân.
Cũng nên phân biệt giữa yêu cầu bắt buộc và gợi ý thiết kế. Ví dụ, “website phải có biểu mẫu liên hệ” là yêu cầu bắt buộc. Trong khi “có thể sử dụng hiệu ứng xuất hiện nhẹ khi cuộn trang” chỉ là một gợi ý. Nếu không phân biệt, Gemini có thể xem một ý tưởng trang trí ngang hàng với chức năng quan trọng.
Một cách viết dễ kiểm soát hơn là sử dụng các nhóm yêu cầu:
Mục tiêu:
Tạo website giới thiệu dịch vụ thiết kế nội thất.
Bắt buộc:
- Có trang chủ.
- Có danh sách dịch vụ.
- Có khu vực dự án tiêu biểu.
- Có biểu mẫu liên hệ.
- Responsive trên mobile và desktop.
- Các nút chính phải có trạng thái hover.
Ưu tiên:
- Giao diện hiện đại.
- Bố cục thoáng.
- Hình ảnh dự án được ưu tiên về mặt thị giác.
Không sử dụng:
- Popup tự động.
- Hiệu ứng chuyển động quá mạnh.
- Thư viện JavaScript bên ngoài.
Việc dùng các nhóm như vậy đặc biệt hữu ích khi dự án có nhiều yêu cầu. Gemini có thể hiểu đâu là phần phải giữ nguyên, đâu là phần có thể linh hoạt và đâu là giới hạn không được vượt qua.
Nếu website đã có sẵn giao diện hoặc mã nguồn, prompt cũng nên nói rõ Gemini được phép thay đổi đến đâu. Đây là điểm rất quan trọng khi dùng AI để chỉnh sửa website hiện có. Nếu chỉ yêu cầu “làm giao diện đẹp hơn”, Gemini có thể thay đổi cả cấu trúc HTML, tên class hoặc logic JavaScript không nằm trong phạm vi mong muốn.
Trong trường hợp đó, nên viết cụ thể:
Hãy cải thiện giao diện hiện tại nhưng giữ nguyên:
- Cấu trúc dữ liệu.
- Tên các API.
- Logic xử lý biểu mẫu.
- Tên các biến JavaScript hiện có.
Chỉ được thay đổi:
- HTML của khu vực giao diện được yêu cầu.
- CSS.
- Các hiệu ứng hiển thị cần thiết.
Không viết lại toàn bộ dự án nếu không cần thiết.
Đây là nguyên tắc rất đáng chú ý khi dùng Gemini để lập trình: phạm vi chỉnh sửa càng rõ thì nguy cơ AI sửa nhầm phần không liên quan càng thấp.
Cấu trúc một prompt website dễ kiểm soát
Với một dự án đơn giản, prompt có thể chỉ cần vài đoạn. Nhưng khi website có nhiều trang và chức năng, nên sử dụng một cấu trúc ổn định để tránh bỏ sót yêu cầu. Một cấu trúc thực tế có thể gồm sáu phần: vai trò, mục tiêu, bối cảnh, yêu cầu giao diện, yêu cầu kỹ thuật và tiêu chí đầu ra.
Xác định vai trò và nhiệm vụ
Phần đầu tiên cho Gemini biết nó đang đảm nhận công việc gì. Không cần viết vai trò quá hoa mỹ. Một câu rõ ràng như “Bạn là lập trình viên frontend có kinh nghiệm xây dựng giao diện responsive” đã đủ để định hướng nhiệm vụ.
Ngay sau đó phải nói chính xác việc cần làm. “Thiết kế một website” khác với “viết mã hoàn chỉnh cho trang chủ”. Nếu nhiệm vụ không rõ, phạm vi kết quả cũng dễ bị lệch.
Bạn là lập trình viên frontend có kinh nghiệm xây dựng website responsive.
Nhiệm vụ:
Tạo giao diện trang chủ cho một website giới thiệu dịch vụ thiết kế website.
Cung cấp bối cảnh dự án
Bối cảnh giúp Gemini hiểu website đang phục vụ hoạt động nào. Đây là phần thường bị bỏ qua nhưng có ảnh hưởng trực tiếp đến cách AI lựa chọn bố cục.
Ví dụ, cùng là website giới thiệu doanh nghiệp nhưng website dành cho công ty công nghệ sẽ có cách trình bày khác với website dành cho một cửa hàng địa phương. Nếu chỉ nói “website doanh nghiệp”, Gemini phải tự suy đoán rất nhiều.
Bối cảnh:
- Website dùng để giới thiệu dịch vụ thiết kế website.
- Khách hàng chính là doanh nghiệp nhỏ và hộ kinh doanh.
- Người truy cập cần nhanh chóng hiểu dịch vụ, xem lợi ích và gửi yêu cầu tư vấn.
- Website ưu tiên khả năng đọc trên điện thoại.
Mô tả cấu trúc trang
Đây là phần biến ý tưởng thành bố cục cụ thể. Không nhất thiết phải mô tả từng pixel. Chỉ cần cho Gemini biết thứ tự và vai trò của các khu vực quan trọng.
Trang chủ gồm:
1. Header với logo và menu.
2. Hero giới thiệu dịch vụ.
3. Các lợi ích nổi bật.
4. Danh sách dịch vụ.
5. Quy trình làm việc.
6. Dự án tiêu biểu.
7. Câu hỏi thường gặp.
8. Form liên hệ.
9. Footer.
Cách mô tả theo thứ tự giúp Gemini hiểu mạch nội dung. Người dùng thường nhìn thấy phần nào trước, thông tin nào cần được giải thích tiếp theo và hành động cuối cùng mà website muốn họ thực hiện.
Nêu yêu cầu giao diện và trải nghiệm
Phần này nên tập trung vào những quyết định ảnh hưởng đến trải nghiệm thay vì dùng quá nhiều tính từ. “Đẹp”, “xịn”, “cao cấp” hoặc “chuyên nghiệp” có thể dùng làm định hướng, nhưng nên đi kèm các đặc điểm có thể triển khai.
Phong cách:
- Hiện đại, tối giản và chuyên nghiệp.
- Bố cục thoáng.
- Nội dung chính dễ quét bằng mắt.
- CTA nổi bật nhưng không gây cảm giác quảng cáo quá mức.
- Card có bo góc vừa phải.
- Hiệu ứng hover nhẹ.
- Không sử dụng animation liên tục.
Responsive:
- Mobile ưu tiên khả năng đọc và thao tác bằng một tay.
- Menu chuyển thành dạng phù hợp với màn hình nhỏ.
- Các cột tự động điều chỉnh khi viewport thay đổi.
Chốt công nghệ và cách xuất mã
Nếu có yêu cầu kỹ thuật, nên đưa trực tiếp vào prompt. Nếu không chỉ định, Gemini có thể lựa chọn cách triển khai mà bạn không mong muốn.
Công nghệ:
- HTML5.
- CSS3.
- JavaScript thuần.
- Không sử dụng framework.
- Không phụ thuộc thư viện bên ngoài.
Đầu ra:
- Trả về mã hoàn chỉnh.
- Tách HTML, CSS và JavaScript thành các phần rõ ràng.
- Không bỏ qua các phần quan trọng bằng chú thích như “phần còn lại tương tự”.
- Code phải có thể chạy sau khi lưu thành các file tương ứng.
Đặc biệt, câu “không bỏ qua phần còn lại” rất hữu ích khi cần mã có thể sử dụng trực tiếp. Nếu không yêu cầu, AI đôi khi có thể rút gọn những đoạn dài bằng cách mô tả thay vì cung cấp toàn bộ mã.
Đặt tiêu chí kiểm tra trước khi hoàn thành
Một prompt tốt không chỉ nói Gemini phải tạo gì mà còn nói thế nào được xem là đạt. Đây là bước giúp biến yêu cầu chung thành một danh sách kiểm tra.
Trước khi hoàn thành, hãy tự kiểm tra:
- Không thiếu khu vực đã yêu cầu.
- Giao diện hiển thị tốt trên mobile và desktop.
- Không có nút không có mục đích rõ ràng.
- Không có nội dung mẫu mâu thuẫn với lĩnh vực website.
- Không có lỗi cú pháp HTML, CSS hoặc JavaScript.
- Các liên kết và nút trong giao diện có trạng thái phù hợp.
- Không tự ý thêm framework hoặc thư viện ngoài yêu cầu.
Phần kiểm tra này đặc biệt hữu ích khi prompt được dùng cho những website có nhiều thành phần. Thay vì chỉ nhận kết quả rồi tự tìm lỗi, người dùng có thể yêu cầu Gemini thực hiện một vòng rà soát trước khi trả mã.
Với dự án lớn, cũng không nên ép Gemini tạo toàn bộ website trong một lần nếu yêu cầu đã trở nên quá phức tạp. Có thể bắt đầu bằng kiến trúc trang, sau đó xây trang chủ, tiếp tục đến các trang con, rồi cuối cùng kiểm tra responsive và sửa lỗi. Cách làm từng bước giúp dễ xác định nguyên nhân khi một phần kết quả không đúng.
Một prompt tạo website hiệu quả vì thế không nằm ở việc dùng thật nhiều câu chữ. Giá trị nằm ở việc đưa đúng thông tin cần thiết, sắp xếp chúng theo cấu trúc dễ hiểu và xác định rõ kết quả mong muốn. Khi Gemini hiểu được mục tiêu, phạm vi và tiêu chí hoàn thành, người dùng sẽ có nhiều khả năng nhận được mã và giao diện gần với dự án thực tế ngay từ những lượt đầu tiên.
Viết prompt theo từng loại website
Không có một mẫu prompt duy nhất phù hợp với mọi website. Website bán hàng cần chú trọng sản phẩm, tìm kiếm và chuyển đổi; website dịch vụ cần làm rõ năng lực, quy trình và liên hệ; trong khi website tin tức lại ưu tiên khả năng đọc, phân loại nội dung và điều hướng. Vì vậy, sau khi xác định cấu trúc chung, nên điều chỉnh prompt theo mục tiêu thực tế của từng loại dự án.
Website bán hàng
Với website thương mại điện tử, không nên chỉ yêu cầu Gemini tạo “giao diện cửa hàng đẹp”. Prompt nên mô tả hành trình từ lúc người dùng nhìn thấy sản phẩm đến khi thực hiện hành động mua hoặc liên hệ.
Hãy xây dựng giao diện website bán đồ gia dụng.
Đối tượng:
- Người dùng mua sản phẩm gia dụng trực tuyến.
- Ưu tiên trải nghiệm trên điện thoại.
Trang chủ cần có:
- Header với logo, menu, ô tìm kiếm và biểu tượng giỏ hàng.
- Banner giới thiệu chương trình nổi bật.
- Danh mục sản phẩm.
- Sản phẩm mới.
- Sản phẩm bán chạy.
- Khu vực ưu đãi.
- Chính sách giao hàng và đổi trả.
- Footer.
Trang danh sách:
- Hiển thị ảnh, tên, giá và trạng thái sản phẩm.
- Có bộ lọc theo danh mục và khoảng giá.
- Có sắp xếp theo giá và sản phẩm mới.
- Có phân trang.
Trang chi tiết:
- Ảnh sản phẩm.
- Tên, giá và mô tả.
- Lựa chọn biến thể nếu có.
- Số lượng.
- Nút thêm vào giỏ hàng.
- Thông tin giao hàng.
- Sản phẩm liên quan.
Yêu cầu:
- Thiết kế rõ ràng, ưu tiên khả năng mua hàng.
- Không sử dụng popup gây gián đoạn.
- Responsive trên mobile, tablet và desktop.
Cách viết này giúp Gemini hiểu rằng website bán hàng không chỉ là một trang có nhiều thẻ sản phẩm. Các thành phần phải liên kết thành một luồng sử dụng hợp lý.
Website giới thiệu dịch vụ
Website dịch vụ thường không cần quá nhiều chức năng phức tạp nhưng cần trình bày giá trị một cách thuyết phục. Prompt nên tập trung vào vấn đề khách hàng, dịch vụ cung cấp, lợi ích, quy trình và phương thức liên hệ.
Hãy tạo website giới thiệu dịch vụ sửa chữa máy tính.
Mục tiêu:
- Giúp khách hàng nhanh chóng hiểu các dịch vụ cung cấp.
- Tạo sự tin cậy.
- Khuyến khích khách hàng gọi điện hoặc gửi yêu cầu tư vấn.
Trang chủ gồm:
- Phần giới thiệu chính với thông điệp rõ ràng.
- Các dịch vụ nổi bật.
- Những vấn đề khách hàng thường gặp.
- Lý do nên lựa chọn dịch vụ.
- Quy trình tiếp nhận và xử lý.
- Khu vực đánh giá khách hàng.
- Câu hỏi thường gặp.
- Form yêu cầu tư vấn.
- Thông tin liên hệ.
Thiết kế:
- Chuyên nghiệp, dễ đọc.
- Số điện thoại và nút liên hệ dễ nhìn trên mobile.
- Không dùng quá nhiều hiệu ứng.
- CTA được bố trí ở những vị trí phù hợp với hành trình đọc.
Với dạng website này, việc nói rõ hành động mong muốn của người truy cập quan trọng hơn việc yêu cầu quá nhiều hiệu ứng thị giác. Một giao diện đẹp nhưng không giúp người dùng tìm được dịch vụ hoặc phương thức liên hệ vẫn chưa giải quyết đúng bài toán.
Website tin tức hoặc blog
Website nội dung cần ưu tiên khả năng đọc và tìm kiếm thông tin. Nếu chỉ yêu cầu “tạo blog hiện đại”, Gemini có thể tập trung quá nhiều vào hình thức mà bỏ qua cấu trúc nội dung.
Hãy tạo giao diện website tin tức công nghệ.
Trang chủ:
- Header và menu chuyên mục.
- Bài viết nổi bật.
- Danh sách bài mới.
- Các chuyên mục chính.
- Khu vực bài viết được xem nhiều.
- Footer.
Trang bài viết:
- Tiêu đề.
- Thông tin ngày đăng và tác giả.
- Ảnh đại diện.
- Nội dung bài viết.
- Mục lục nếu bài dài.
- Bài viết liên quan.
- Khu vực chia sẻ.
Yêu cầu trải nghiệm:
- Font dễ đọc.
- Chiều rộng vùng nội dung phù hợp với bài viết dài.
- Khoảng cách giữa các đoạn rõ ràng.
- Hình ảnh không làm vỡ bố cục trên mobile.
- Menu và điều hướng dễ sử dụng.
Ở đây, prompt đã chuyển trọng tâm từ “thiết kế đẹp” sang “đọc nội dung dễ dàng”. Đây là cách điều chỉnh yêu cầu theo bản chất của từng loại website.
Yêu cầu Gemini xây dựng giao diện responsive
Responsive không nên chỉ được viết bằng một câu “hãy làm responsive”. Câu này cho biết mục tiêu nhưng chưa cho biết cách xử lý các thành phần khi màn hình thay đổi kích thước.
Ví dụ, một trang có bốn cột sản phẩm trên desktop cần được xác định cách thu gọn khi chuyển sang mobile. Menu cũng cần có phương án riêng. Bảng dữ liệu, hình ảnh, form và các nút hành động đều có thể phát sinh vấn đề nếu chỉ thu nhỏ toàn bộ giao diện.
Prompt có thể mô tả theo hướng:
Yêu cầu responsive:
Desktop:
- Khu vực sản phẩm hiển thị 4 cột.
- Nội dung chính và sidebar nằm cạnh nhau.
- Header hiển thị đầy đủ menu.
Tablet:
- Khu vực sản phẩm chuyển thành 2 hoặc 3 cột tùy chiều rộng.
- Sidebar có thể chuyển xuống dưới nội dung chính.
- Giảm khoảng cách giữa các thành phần.
Mobile:
- Sản phẩm hiển thị 2 cột nếu vẫn đảm bảo khả năng đọc.
- Header chuyển sang bố cục gọn.
- Menu không làm che khuất nội dung.
- Các nút quan trọng có vùng bấm đủ lớn.
- Hình ảnh không vượt quá chiều rộng màn hình.
- Form chuyển thành một cột.
Ngoài việc mô tả từng kích thước, có thể yêu cầu Gemini tự kiểm tra những lỗi thường gặp như nội dung bị tràn ngang, chữ quá nhỏ, nút khó bấm hoặc hình ảnh vượt khỏi khung.
Sau khi hoàn thành responsive, hãy kiểm tra các vấn đề sau:
- Không có thanh cuộn ngang ngoài ý muốn.
- Không có nội dung bị cắt.
- Không có nút quá nhỏ để thao tác trên màn hình cảm ứng.
- Không để chữ và hình ảnh chồng lên nhau.
- Không làm mất các chức năng chính khi chuyển sang mobile.
Cách này thực tế hơn việc chỉ ghi “mobile friendly”, bởi Gemini có danh sách cụ thể để tự rà soát.
Cách yêu cầu Gemini tạo mã website dễ chỉnh sửa
Một website được AI tạo ra có thể chạy được nhưng vẫn khó bảo trì nếu mã nguồn bị viết dồn vào một khối lớn, tên class thiếu nhất quán hoặc các phần giao diện bị lặp lại. Vì vậy, prompt nên đưa ra yêu cầu về cấu trúc mã ngay từ đầu.
Với HTML và CSS, có thể yêu cầu tên class dễ hiểu, phân chia các khu vực theo chức năng và hạn chế CSS inline nếu dự án cần bảo trì lâu dài.
Yêu cầu về code:
- Đặt tên class có ý nghĩa và nhất quán.
- Tách cấu trúc HTML khỏi phần CSS khi dự án có nhiều thành phần.
- Hạn chế CSS inline.
- Không lặp lại cùng một đoạn CSS nếu có thể tái sử dụng.
- Nhóm CSS theo từng khu vực giao diện.
- Viết JavaScript theo từng chức năng.
- Không tạo biến hoặc hàm có tên khó hiểu.
- Giữ code dễ đọc và dễ chỉnh sửa về sau.
Nếu website có nhiều trang, nên yêu cầu Gemini giữ một hệ thống thiết kế thống nhất. Ví dụ, nút chính trên trang sản phẩm và nút liên hệ trên trang dịch vụ không nên tự nhiên có hai kiểu hoàn toàn khác nhau nếu không có lý do.
Hãy duy trì hệ thống thiết kế thống nhất trên toàn website:
- Cùng quy tắc màu sắc.
- Cùng kiểu nút chính và nút phụ.
- Cùng cách bo góc.
- Cùng hệ thống khoảng cách.
- Cùng phong cách tiêu đề.
- Các thành phần có cùng chức năng phải sử dụng cùng kiểu giao diện.
Nếu tạo thêm trang mới, hãy tái sử dụng các thành phần đã có thay vì thiết kế lại từ đầu.
Đây là một yêu cầu quan trọng khi xây website qua nhiều lượt hội thoại. Nếu không nhắc Gemini duy trì hệ thống giao diện, mỗi lần yêu cầu thêm một trang, thiết kế có thể dần trở nên thiếu đồng nhất.
Yêu cầu Gemini xử lý chức năng thay vì chỉ tạo giao diện
Một lỗi phổ biến khi dùng AI tạo website là nhầm giữa “có giao diện” và “có chức năng”. Một nút có chữ “Thêm vào giỏ hàng” chưa đồng nghĩa với việc giỏ hàng hoạt động. Một ô tìm kiếm cũng chưa có nghĩa là nó thực sự tìm được dữ liệu.
Vì vậy, nếu cần chức năng hoạt động, prompt phải nói rõ hành vi mong muốn.
Chức năng tìm kiếm:
- Người dùng nhập từ khóa vào ô tìm kiếm.
- Khi gửi biểu mẫu, lấy từ khóa hiện tại.
- Lọc danh sách sản phẩm theo tên.
- Không phân biệt chữ hoa và chữ thường.
- Nếu không có kết quả, hiển thị thông báo phù hợp.
- Nếu xóa từ khóa, khôi phục danh sách ban đầu.
Với bộ lọc cũng nên mô tả đầu vào, cách xử lý và trạng thái kết quả:
Chức năng lọc sản phẩm:
- Lọc theo danh mục.
- Lọc theo khoảng giá.
- Có thể kết hợp nhiều điều kiện.
- Khi thay đổi bộ lọc, danh sách cập nhật tương ứng.
- Hiển thị trạng thái khi không có sản phẩm phù hợp.
- Có nút xóa toàn bộ bộ lọc.
Đối với các chức năng liên quan đến dữ liệu thật, cần nói rõ dữ liệu đến từ đâu. Nếu chưa có backend, không nên yêu cầu Gemini giả vờ rằng hệ thống đã kết nối cơ sở dữ liệu. Có thể yêu cầu tạo dữ liệu mẫu và đánh dấu rõ phần cần kết nối sau.
Hiện tại chưa có API backend.
Hãy:
- Sử dụng dữ liệu mẫu để minh họa giao diện.
- Tách phần dữ liệu khỏi phần hiển thị nếu có thể.
- Không giả lập việc gửi dữ liệu lên máy chủ.
- Ghi chú rõ vị trí cần kết nối API sau này.
- Không tạo chức năng backend giả nhưng trình bày như đã hoạt động thật.
Yêu cầu này giúp tránh một vấn đề thường gặp: giao diện nhìn như một ứng dụng hoàn chỉnh nhưng thực tế các nút chỉ thay đổi trạng thái trên màn hình.
Chia nhỏ yêu cầu khi website quá lớn
Với một website nhiều trang, việc đưa toàn bộ yêu cầu vào một prompt duy nhất thường không phải lựa chọn tốt nhất. Prompt càng lớn thì càng khó kiểm soát phần nào đã hoàn thành, phần nào bị bỏ qua và thay đổi nào làm ảnh hưởng đến các thành phần khác.
Một quy trình hợp lý là chia thành các giai đoạn. Trước tiên yêu cầu Gemini phân tích cấu trúc website, sau đó xây dựng hệ thống giao diện, tiếp tục triển khai từng trang và cuối cùng kiểm tra toàn bộ.
- Xác định mục tiêu và kiến trúc website.
- Xây dựng hệ thống giao diện chung.
- Triển khai trang quan trọng nhất.
- Triển khai các trang còn lại dựa trên thành phần đã có.
- Bổ sung chức năng tương tác.
- Kiểm tra responsive.
- Rà soát lỗi và tối ưu mã.
Ví dụ, sau khi Gemini hoàn thành trang chủ, không nên ngay lập tức yêu cầu “hãy tạo lại toàn bộ website với thêm 10 trang”. Có thể tiếp tục bằng một yêu cầu có phạm vi rõ:
Dựa trên hệ thống giao diện và quy tắc thiết kế đã xây dựng ở bước trước, hãy tạo trang danh sách sản phẩm.
Giữ nguyên:
- Header.
- Footer.
- Hệ thống màu.
- Typography.
- Nút và các thành phần dùng chung.
Chỉ bổ sung:
- Tiêu đề trang.
- Bộ lọc.
- Danh sách sản phẩm.
- Phân trang.
Không thay đổi cấu trúc của các thành phần dùng chung.
Cách này giúp từng bước phát triển có sự liên kết. Nó cũng thuận tiện hơn khi phát hiện lỗi, bởi người dùng có thể xác định lỗi xuất hiện từ bước nào thay vì phải kiểm tra một khối mã khổng lồ.
Cách yêu cầu Gemini kiểm tra và sửa website sau khi tạo
Không nên xem lần sinh mã đầu tiên là phiên bản cuối cùng. Với dự án web, việc kiểm tra và sửa nhiều vòng là hoàn toàn bình thường. Tuy nhiên, mỗi vòng sửa nên có mục tiêu cụ thể.
Thay vì yêu cầu chung chung như “hãy sửa website cho đẹp hơn”, có thể yêu cầu Gemini kiểm tra một nhóm vấn đề:
Hãy kiểm tra mã hiện tại theo các nhóm sau:
1. HTML:
- Kiểm tra cấu trúc thẻ.
- Kiểm tra các thẻ đóng mở.
- Kiểm tra phần tử bị lồng sai.
2. CSS:
- Tìm quy tắc bị trùng.
- Kiểm tra bố cục responsive.
- Kiểm tra nội dung bị tràn.
3. JavaScript:
- Kiểm tra lỗi cú pháp.
- Kiểm tra các sự kiện tương tác.
- Kiểm tra trường hợp dữ liệu rỗng.
4. Giao diện:
- Kiểm tra mobile.
- Kiểm tra tablet.
- Kiểm tra desktop.
Chỉ sửa những lỗi được phát hiện và giữ nguyên hành vi đang hoạt động đúng.
Nếu Gemini phát hiện nhiều vấn đề, có thể yêu cầu nó giải thích nguyên nhân trước rồi mới sửa. Cách này đặc biệt hữu ích khi làm việc với mã nguồn đã có sẵn, vì người dùng có thể biết chính xác thay đổi nào đang được thực hiện.
Đối với những thay đổi lớn, nên yêu cầu Gemini không tự ý thay thế toàn bộ mã nếu chưa cần thiết. Việc sửa đúng khu vực thường an toàn hơn việc sinh lại cả trang.
Hãy sửa trực tiếp phần gây lỗi.
Không viết lại toàn bộ file nếu không cần thiết.
Không thay đổi các chức năng đang hoạt động.
Sau khi sửa, hãy kiểm tra lại các phần có liên quan để tránh tạo lỗi mới.
Đây là cách sử dụng Gemini hiệu quả hơn trong thực tế: không chỉ giao cho AI nhiệm vụ “tạo website”, mà còn dùng AI như một công cụ phân tích, triển khai, kiểm thử và cải thiện từng phần của dự án.
Mẫu prompt tạo website hoàn chỉnh bằng Gemini
Sau khi nắm được cách xây dựng từng nhóm yêu cầu, có thể kết hợp chúng thành một prompt hoàn chỉnh. Mẫu dưới đây phù hợp khi muốn Gemini xây dựng một website giới thiệu dịch vụ từ đầu, đồng thời vẫn giữ được khả năng kiểm soát về giao diện, cấu trúc và mã nguồn.
Bạn là lập trình viên frontend có kinh nghiệm xây dựng website hiện đại và responsive.
Nhiệm vụ:
Xây dựng website giới thiệu dịch vụ thiết kế website cho doanh nghiệp nhỏ và hộ kinh doanh.
Mục tiêu:
- Giúp khách truy cập hiểu nhanh các dịch vụ.
- Tạo cảm giác chuyên nghiệp và đáng tin cậy.
- Hướng người dùng đến hành động liên hệ hoặc yêu cầu tư vấn.
Đối tượng:
- Chủ doanh nghiệp nhỏ.
- Hộ kinh doanh.
- Người đang cần xây dựng hoặc nâng cấp website.
Cấu trúc trang chủ:
1. Header gồm logo, menu điều hướng và nút liên hệ.
2. Hero giới thiệu giá trị chính của dịch vụ.
3. Các lợi ích nổi bật.
4. Danh sách dịch vụ.
5. Quy trình thực hiện.
6. Dự án tiêu biểu.
7. Câu hỏi thường gặp.
8. Form liên hệ.
9. Footer.
Yêu cầu giao diện:
- Phong cách hiện đại, chuyên nghiệp và dễ sử dụng.
- Bố cục thoáng, phân cấp nội dung rõ ràng.
- Có màu chủ đạo và màu nhấn nhất quán.
- CTA dễ nhận biết nhưng không lạm dụng.
- Hình ảnh và nội dung cân đối.
- Hiệu ứng chuyển động nhẹ, chỉ sử dụng khi thực sự cần thiết.
Responsive:
- Hoạt động tốt trên desktop, tablet và mobile.
- Không xuất hiện thanh cuộn ngang ngoài ý muốn.
- Các cột tự động điều chỉnh theo chiều rộng màn hình.
- Menu có phương án hiển thị phù hợp trên mobile.
- Nút và trường nhập liệu dễ thao tác trên màn hình cảm ứng.
Công nghệ:
- HTML5.
- CSS3.
- JavaScript thuần.
- Không sử dụng framework nếu không được yêu cầu.
- Không phụ thuộc thư viện bên ngoài.
Yêu cầu về code:
- Tên class và biến rõ ràng.
- Code có cấu trúc dễ đọc.
- Hạn chế lặp code.
- Không sử dụng inline style nếu không cần thiết.
- Tách các thành phần theo chức năng.
- Không bỏ qua phần mã bằng cách viết “các phần còn lại tương tự”.
Nội dung:
- Sử dụng nội dung mẫu phù hợp với lĩnh vực thiết kế website.
- Không sử dụng nội dung vô nghĩa hoặc văn bản giữ chỗ quá nhiều.
- Không tạo thông tin doanh nghiệp giả nếu chưa được cung cấp.
Trước khi trả kết quả:
- Kiểm tra HTML, CSS và JavaScript.
- Kiểm tra responsive.
- Kiểm tra các nút và tương tác.
- Kiểm tra nội dung có phù hợp với mục tiêu website.
- Không tự ý thêm chức năng ngoài phạm vi yêu cầu.
Hãy trả về mã hoàn chỉnh và giải thích ngắn gọn cấu trúc các phần đã tạo.
Điểm đáng chú ý của mẫu này là các yêu cầu được chia thành từng nhóm. Khi muốn sử dụng cho dự án khác, chỉ cần thay đổi mục tiêu, đối tượng, cấu trúc và chức năng thay vì viết lại toàn bộ cách ra lệnh.
Mẫu prompt tạo website bán hàng
Nếu mục tiêu là xây dựng cửa hàng trực tuyến, nên yêu cầu Gemini quan tâm đồng thời đến giao diện sản phẩm và hành trình mua hàng. Một prompt thực tế có thể bắt đầu như sau:
Bạn là lập trình viên frontend chuyên xây dựng giao diện thương mại điện tử.
Hãy tạo giao diện website bán laptop.
Mục tiêu:
- Giúp người dùng tìm nhanh sản phẩm phù hợp.
- So sánh thông tin cơ bản giữa các sản phẩm.
- Xem chi tiết trước khi quyết định mua.
- Tạo trải nghiệm tốt trên điện thoại.
Các trang:
- Trang chủ.
- Danh sách sản phẩm.
- Chi tiết sản phẩm.
- Giỏ hàng.
- Liên hệ.
Trang chủ:
- Header.
- Ô tìm kiếm.
- Danh mục sản phẩm.
- Sản phẩm nổi bật.
- Sản phẩm mới.
- Thương hiệu.
- Chính sách mua hàng.
- Footer.
Danh sách sản phẩm:
- Bộ lọc thương hiệu.
- Bộ lọc khoảng giá.
- Bộ lọc cấu hình.
- Sắp xếp sản phẩm.
- Phân trang.
- Hiển thị trạng thái không có kết quả.
Chi tiết sản phẩm:
- Hình ảnh.
- Tên sản phẩm.
- Giá.
- Thông số kỹ thuật.
- Mô tả.
- Tình trạng hàng.
- Số lượng.
- Nút thêm vào giỏ hàng.
- Sản phẩm liên quan.
Yêu cầu:
- Thiết kế ưu tiên khả năng tìm kiếm và đọc thông tin.
- Không làm giao diện quá nhiều chi tiết gây rối.
- Responsive.
- Sử dụng HTML, CSS và JavaScript thuần.
- Dữ liệu sản phẩm dùng dữ liệu mẫu có cấu trúc rõ ràng.
- Không giả lập thanh toán thật.
Nếu website chỉ mới ở giai đoạn thiết kế giao diện, việc nói rõ “không giả lập thanh toán thật” giúp Gemini không tạo ra một hệ thống thanh toán trông như đã hoạt động trong khi backend chưa tồn tại.
Mẫu prompt yêu cầu Gemini tạo website từ mã nguồn có sẵn
Đây là trường hợp cần cẩn thận hơn so với tạo website mới. Mã nguồn hiện tại có thể đã chứa logic quan trọng, vì vậy prompt phải xác định rõ phần được phép thay đổi.
Tôi sẽ cung cấp mã nguồn website hiện tại.
Nhiệm vụ:
Cải thiện giao diện trang danh sách sản phẩm nhưng không phá vỡ chức năng hiện có.
Giữ nguyên:
- Cấu trúc dữ liệu.
- Tên API.
- Logic lấy dữ liệu.
- Logic thêm sản phẩm vào giỏ hàng.
- Các biến và hàm cần thiết cho chức năng hiện tại.
Được phép thay đổi:
- HTML của khu vực giao diện sản phẩm.
- CSS.
- Bố cục hiển thị.
- Hiệu ứng hover và trạng thái tương tác.
Yêu cầu thiết kế:
- Hiện đại.
- Dễ đọc.
- Responsive.
- Hình ảnh sản phẩm nổi bật.
- Giá và nút hành động dễ nhận biết.
Quy trình:
1. Phân tích mã hiện tại.
2. Xác định những phần liên quan đến giao diện.
3. Chỉ ra những phần không nên thay đổi.
4. Sau đó mới đề xuất mã đã chỉnh sửa.
Không viết lại toàn bộ dự án nếu không cần thiết.
Điểm quan trọng ở đây là yêu cầu Gemini phân tích trước khi sửa. Khi làm việc với một dự án có sẵn, điều này giúp giảm khả năng AI nhìn thấy một đoạn code chưa quen thuộc rồi thay thế nó bằng cách triển khai hoàn toàn khác.
Cách yêu cầu Gemini tối ưu giao diện sau khi đã tạo
Sau khi có phiên bản đầu tiên, không nên chỉ nói “tối ưu website”. Tối ưu là một khái niệm rất rộng. Có thể chia thành tốc độ, trải nghiệm, responsive, khả năng đọc, khả năng bảo trì hoặc giao diện.
Nếu muốn tối ưu giao diện, hãy chỉ rõ những điểm cần đánh giá:
Hãy đánh giá giao diện hiện tại theo các tiêu chí:
- Thứ bậc thị giác.
- Khoảng cách giữa các thành phần.
- Khả năng đọc nội dung.
- Độ nổi bật của CTA.
- Sự nhất quán giữa các thành phần.
- Khả năng sử dụng trên mobile.
- Mật độ thông tin.
- Các khu vực gây rối mắt.
Đề xuất các thay đổi có tác động lớn nhất trước.
Không thêm hiệu ứng chỉ để làm giao diện bắt mắt hơn.
Cách này giúp Gemini tập trung vào trải nghiệm thay vì liên tục thêm gradient, animation, bóng đổ hoặc những thành phần không phục vụ mục tiêu của website.
Nếu muốn tối ưu hiệu năng, cần đưa ra phạm vi khác:
Hãy kiểm tra khả năng tối ưu hiệu năng của giao diện.
Tập trung vào:
- CSS dư thừa.
- JavaScript không cần thiết.
- Hình ảnh có kích thước không phù hợp.
- Tài nguyên được tải nhưng không sử dụng.
- Các đoạn code có thể giảm lặp.
- Những thao tác JavaScript có thể gây ảnh hưởng đến trải nghiệm.
Không thay đổi giao diện hoặc chức năng nếu không cần thiết để cải thiện hiệu năng.
Việc tách riêng từng mục tiêu giúp Gemini không thực hiện quá nhiều thay đổi cùng lúc.
Cách yêu cầu Gemini tạo website theo phong cách có sẵn
Trong thực tế, nhiều dự án không bắt đầu từ một trang trắng mà có một website mẫu, bộ nhận diện hoặc một giao diện đã được thống nhất. Khi đó, prompt nên mô tả những đặc điểm cần học theo thay vì yêu cầu sao chép nguyên mẫu.
Tôi muốn xây dựng một giao diện mới dựa trên phong cách của thiết kế tham khảo đã cung cấp.
Hãy phân tích:
- Bố cục tổng thể.
- Cách phân cấp nội dung.
- Hệ thống khoảng cách.
- Kiểu nút.
- Cách sử dụng màu sắc.
- Kiểu trình bày hình ảnh.
- Cách xử lý responsive.
Sau đó tạo giao diện mới có cùng tinh thần thiết kế nhưng sử dụng:
- Nội dung mới.
- Cấu trúc nội dung mới.
- Thành phần phù hợp với website của tôi.
Không sao chép nguyên văn nội dung hoặc tạo bản sao của giao diện.
Cách mô tả này hướng Gemini vào việc học các nguyên tắc thiết kế thay vì chỉ yêu cầu bắt chước từng thành phần.
Những lỗi thường gặp khi viết prompt tạo website
Prompt càng rõ không có nghĩa là càng dài càng tốt. Một prompt chứa hàng trăm yêu cầu không liên quan vẫn có thể kém hiệu quả hơn một prompt ngắn nhưng có cấu trúc. Một số lỗi dưới đây thường khiến kết quả không đúng mong muốn.
Chỉ dùng các tính từ chung chung
Các cụm như “đẹp”, “xịn”, “chuyên nghiệp”, “sang trọng” không đủ để xác định một giao diện. Nên biến chúng thành những đặc điểm có thể quan sát và triển khai.
Ví dụ, thay vì chỉ viết “thiết kế hiện đại”, có thể nói “bố cục thoáng, typography rõ ràng, màu nhấn tiết chế, card có bo góc vừa phải và animation nhẹ”.
Không nói rõ công nghệ
Nếu dự án yêu cầu PHP nhưng prompt chỉ nói “tạo website”, Gemini có thể tạo một giao diện frontend thuần HTML, CSS và JavaScript. Nếu cần framework hoặc backend cụ thể, nên nói rõ ngay từ đầu.
Yêu cầu quá nhiều thứ trong một lần
Một website lớn có thể gồm hàng chục trang, nhiều chức năng và một lượng lớn mã nguồn. Nếu yêu cầu tất cả trong một lượt, việc kiểm tra và sửa lỗi sẽ khó hơn. Chia dự án thành các giai đoạn thường dễ kiểm soát hơn.
Không quy định phạm vi thay đổi
Khi sửa website có sẵn, đây là lỗi đặc biệt dễ gây hậu quả. Nếu chỉ nói “sửa phần này”, Gemini có thể thay đổi những phần khác vì cho rằng chúng có liên quan. Hãy nêu rõ những gì được phép và không được phép thay đổi.
Không yêu cầu kiểm tra sau khi tạo
Một đoạn mã nhìn có vẻ hoàn chỉnh vẫn có thể chứa lỗi cú pháp, lỗi responsive hoặc chức năng chưa xử lý trường hợp đặc biệt. Nên dành một bước riêng để kiểm tra.
Quy trình dùng Gemini để xây website hiệu quả
Thay vì phụ thuộc vào một prompt duy nhất, có thể xây dựng website theo một quy trình nhiều bước. Cách này phù hợp hơn với dự án thực tế vì mỗi bước có một mục tiêu rõ ràng.
- Phân tích yêu cầu: xác định mục tiêu, đối tượng, nội dung và chức năng.
- Lập cấu trúc: xác định các trang và thành phần quan trọng.
- Thiết kế hệ thống giao diện: thống nhất màu sắc, typography, nút, card, khoảng cách và responsive.
- Xây trang chính: bắt đầu từ trang quan trọng nhất để hình thành hệ thống thiết kế.
- Xây các trang còn lại: tái sử dụng thành phần đã có thay vì tạo lại từ đầu.
- Bổ sung tương tác: triển khai tìm kiếm, bộ lọc, menu, biểu mẫu hoặc những chức năng cần thiết.
- Kiểm tra: rà soát mã, giao diện, responsive và các trạng thái đặc biệt.
- Tối ưu: xử lý những vấn đề còn tồn tại mà không làm thay đổi những phần đang hoạt động tốt.
Ở mỗi bước, nên lưu lại phiên bản hoạt động ổn định trước khi thực hiện thay đổi lớn. Nếu một lần chỉnh sửa khiến website xuất hiện lỗi, việc quay lại phiên bản trước sẽ đơn giản hơn.
Cách viết prompt để Gemini hiểu yêu cầu chỉnh sửa chính xác
Khi website đã có sẵn, một prompt chỉnh sửa tốt thường có bốn phần: hiện trạng, vấn đề, kết quả mong muốn và giới hạn. Đây là cấu trúc ngắn nhưng rất hiệu quả.
Hiện trạng:
Trang sản phẩm hiện hiển thị 4 sản phẩm trên một hàng ở desktop.
Vấn đề:
Trên màn hình rộng vừa, các thẻ sản phẩm quá hẹp.
Trên mobile, hình ảnh và tên sản phẩm khó đọc.
Mong muốn:
- Desktop lớn: tối đa 4 cột.
- Tablet: 2 hoặc 3 cột tùy chiều rộng.
- Mobile: 2 cột nếu nội dung vẫn dễ đọc.
- Tăng khoảng cách giữa ảnh và thông tin sản phẩm.
- Giữ nguyên dữ liệu và chức năng hiện tại.
Giới hạn:
Chỉ sửa HTML/CSS cần thiết cho khu vực danh sách sản phẩm.
Không thay đổi logic JavaScript.
Prompt này tốt hơn nhiều so với câu “sửa danh sách sản phẩm cho responsive” vì Gemini biết chính xác vấn đề đang xảy ra và giới hạn được phạm vi can thiệp.
Checklist trước khi đưa website vào sử dụng
Sau khi Gemini hoàn thành website, vẫn cần kiểm tra bằng góc nhìn của một dự án thực tế. AI có thể hỗ trợ rà soát nhưng không nên xem câu trả lời của AI là bằng chứng tuyệt đối rằng website không còn lỗi.
- Kiểm tra tất cả trang quan trọng có hiển thị đúng.
- Kiểm tra menu trên desktop và mobile.
- Kiểm tra biểu mẫu và thông báo lỗi.
- Kiểm tra các nút có đúng hành động.
- Kiểm tra liên kết không dẫn sai địa chỉ.
- Kiểm tra hình ảnh không bị vỡ hoặc vượt khỏi bố cục.
- Kiểm tra website không xuất hiện thanh cuộn ngang ngoài ý muốn.
- Kiểm tra nội dung trên màn hình nhỏ.
- Kiểm tra trạng thái khi danh sách không có dữ liệu.
- Kiểm tra trạng thái loading nếu website có tải dữ liệu.
- Kiểm tra thông báo lỗi khi người dùng nhập dữ liệu không hợp lệ.
- Kiểm tra mã nguồn để phát hiện phần dư thừa.
- Kiểm tra các thư viện hoặc tài nguyên bên ngoài có thực sự cần thiết.
- Kiểm tra tiêu đề, mô tả và nội dung của từng trang nếu website phục vụ SEO.
Có thể tiếp tục sử dụng Gemini cho chính bước kiểm tra này bằng cách cung cấp mã nguồn hoặc từng phần của dự án và yêu cầu AI rà soát theo checklist. Tuy nhiên, với các chức năng liên quan đến dữ liệu thật, tài khoản, thanh toán, bảo mật hoặc hệ thống máy chủ, cần kiểm thử thực tế thay vì chỉ dựa vào việc AI nói rằng mã đã đúng.
Prompt tốt giúp Gemini tạo website sát yêu cầu hơn
Điểm quan trọng nhất khi dùng Gemini để tạo website không phải là tìm một câu lệnh thần kỳ có thể tự động hoàn thành mọi dự án. Kết quả tốt thường đến từ cách mô tả bài toán rõ ràng và quy trình làm việc có kiểm soát.
Một prompt hiệu quả nên cho Gemini biết website dùng để làm gì, phục vụ ai, có những phần nào, cần hoạt động ra sao, sử dụng công nghệ gì và kết quả phải đáp ứng những tiêu chí nào. Khi website đã có sẵn, cần bổ sung phạm vi thay đổi để tránh ảnh hưởng đến những chức năng đang hoạt động.
Đối với dự án nhỏ, một prompt đầy đủ có thể đủ để tạo phiên bản đầu tiên. Với dự án lớn, nên chia thành các bước từ phân tích, thiết kế, lập trình đến kiểm tra và tối ưu. Mỗi lần yêu cầu Gemini nên tập trung vào một mục tiêu rõ ràng, đồng thời giữ lại những phần đã được xác nhận là đúng.
Cuối cùng, Gemini nên được xem là công cụ hỗ trợ quá trình phát triển website chứ không phải người tự quyết định toàn bộ dự án. Người xây dựng website vẫn cần kiểm tra yêu cầu, đánh giá mã nguồn, thử nghiệm giao diện trên thiết bị thực tế và xác nhận các chức năng trước khi đưa vào sử dụng. Khi kết hợp prompt có cấu trúc với quy trình kiểm tra hợp lý, Gemini có thể rút ngắn đáng kể thời gian từ ý tưởng đến một website có thể tiếp tục phát triển.
- 0 Bình luận
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *
