Cách viết prompt cho công cụ tạo app bằng AI (kèm ví dụ trước và sau)
Một prompt tốt cho công cụ tạo app bằng AI mô tả sản phẩm, không mô tả mã nguồn: ai dùng nó, họ làm gì từng bước, nó lưu dữ liệu gì, và ai được phép xem những gì. Sau khi phiên bản đầu tiên đã tồn tại, hãy yêu cầu một thay đổi cụ thể mỗi lần, nói rõ điều gì phải giữ nguyên, và mô tả vấn đề theo kiểu “Tôi đã làm X, mong đợi Y, nhưng nhận được Z”. Ba thói quen này sửa được hầu hết các kết quả gây thất vọng.
Phần còn lại của hướng dẫn này trình bày các mẫu chi tiết hơn, kèm ví dụ trước và sau mà bạn có thể điều chỉnh.
Vì sao việc viết prompt cho công cụ tạo app khác với trò chuyện với AI
Khi bạn hỏi một trợ lý AI trong khung chat, một prompt mơ hồ cho một câu trả lời mơ hồ và bạn chuyển sang việc khác. Khi bạn viết prompt cho công cụ tạo app bằng AI, kết quả là một chương trình đang chạy. Mọi chỗ trống trong mô tả của bạn đều được lấp bằng phỏng đoán, và những phỏng đoán đó trở thành mã nguồn, bảng cơ sở dữ liệu và màn hình mà bạn phải sống cùng hoặc gỡ bỏ.
Vì vậy, mục tiêu của một prompt không phải là nghe thông minh. Mục tiêu là để lại ít quyết định quan trọng cho may rủi. Bạn không cần thuật ngữ kỹ thuật cho việc đó. Bạn cần cụ thể về những điều chỉ bạn biết: người dùng, quy trình và quy tắc của bạn.
Nên đưa gì vào prompt đầu tiên
Trước khi viết bất cứ điều gì, hãy trả lời các câu hỏi sau. Mỗi câu lấp một khoảng trống mà AI sẽ phải đoán.
| Đưa vào | Vì sao quan trọng | Ví dụ |
|---|---|---|
| Sản phẩm trong một câu | Đặt khung cho mọi quyết định sau đó | “Trang đặt lịch cho một tiệm cắt tóc nam có hai ghế” |
| Ai dùng nó | Quyết định các màn hình và giọng văn | “Khách vãng lai trên điện thoại, và chủ tiệm trên laptop” |
| Luồng chính, từng bước | Điều phải chạy được trước tiên | “Chọn dịch vụ, chọn giờ, nhập tên và số điện thoại, nhận xác nhận” |
| Dữ liệu được lưu | Trở thành thiết kế cơ sở dữ liệu | “Dịch vụ, lượt đặt, khách hàng” |
| Ai được xem hoặc thay đổi gì | Quyết định đăng nhập và phân quyền | “Chỉ chủ tiệm xem được mọi lượt đặt” |
| Giao diện và cảm giác, ngắn gọn | Tránh kiểu mặc định chung chung | “Tối giản, sáng sủa, nút lớn” |
| Những gì để sau | Giữ phiên bản đầu tiên nhỏ gọn | “Chưa có thanh toán hay đánh giá” |
Hàng cuối cùng thường bị đánh giá thấp. Nói rõ điều bạn không muốn sẽ ngăn AI thêm một blog, một trang giá và một ô đăng ký bản tin mà bạn chưa hề yêu cầu.
Trước và sau: prompt đầu tiên
Trước:
Làm cho tôi một ứng dụng cho phòng gym của tôi.
Công cụ phải đoán mọi thứ: thành viên hay nhân viên? Lớp học hay huấn luyện cá nhân? Có thanh toán không? Bạn sẽ nhận được thứ trông giống một trang web phòng gym nhưng không làm được việc bạn cần.
Sau:
Xây dựng một ứng dụng đặt lớp học cho một phòng yoga nhỏ. Hội viên xem các lớp trong tuần này (tên, giáo viên, giờ, số chỗ còn lại), đặt chỗ, và hủy trước hai giờ. Hội viên đăng ký bằng email và mật khẩu. Chủ phòng đăng nhập để thêm lớp, xem ai đã đặt chỗ, và đánh dấu điểm danh. Lưu lớp học, hội viên và lượt đặt trong cơ sở dữ liệu. Thiết kế nhẹ nhàng, sáng, hoạt động tốt trên điện thoại. Chưa có thanh toán.
Phiên bản thứ hai vẫn ngắn. Nó chỉ trả lời các câu hỏi trong bảng trên.
Mô tả hành vi, không mô tả cách triển khai
Bạn thường nhận được kết quả tốt hơn khi mô tả điều gì nên xảy ra thay vì cách xây dựng.
Trước:
Thêm một useEffect để lấy danh sách lượt đặt và một component modal để chỉnh sửa.
Sau:
Khi chủ phòng nhấn vào một lượt đặt, mở một bảng nơi họ có thể đổi giờ hoặc hủy lượt đó. Thay đổi phải hiện ngay trong danh sách.
Prompt đầu tiên khóa AI vào một kỹ thuật cụ thể có thể không hợp với cách ứng dụng đã được xây dựng. Prompt thứ hai nói cho AI kết quả mong muốn và để nó chọn cách tiếp cận đúng cho mã nguồn đã có. Nếu bạn là lập trình viên và có một sở thích mạnh, hãy nói ra, nhưng hãy đi kèm với kết quả mong muốn.
Nêu rõ các quy tắc
Các quy tắc nghiệp vụ là nơi ứng dụng do AI tạo thường sai nhất, vì chúng hiển nhiên với bạn và vô hình với AI. Hãy nói rõ chúng.
- Giới hạn: “Một thành viên chỉ được giữ tối đa ba lượt đặt trong tương lai.”
- Thời điểm: “Việc hủy đặt đóng hai giờ trước khi lớp bắt đầu.”
- Trường hợp đặc biệt: “Nếu lớp đã đầy, hiển thị nút danh sách chờ thay vì nút Đặt.”
- Phân quyền: “Giáo viên chỉ xem được điểm danh của lớp mình, không xem của giáo viên khác.”
Mỗi quy tắc chỉ cần một câu. Bỏ sót bất kỳ quy tắc nào cũng có nghĩa là ứng dụng hoặc không thi hành quy tắc đó, hoặc tự bịa ra phiên bản riêng của nó.
Sau phiên bản đầu tiên: một thay đổi mỗi tin nhắn
Khi đã có thứ gì đó chạy trong bản xem trước, hãy chuyển từ mô tả toàn bộ sản phẩm sang yêu cầu các thay đổi nhỏ có thể kiểm tra được.
Trước:
Thiết kế chưa ổn, đặt lịch chưa chạy đúng, và tôi muốn có chế độ xem lịch và email.
Sau (bốn tin nhắn riêng biệt):
- Khi tôi đặt chỗ cuối cùng của một lớp, lớp vẫn hiển thị “Còn 1 chỗ”. Nó nên hiển thị “Đã đầy” và ẩn nút Đặt.
- Thêm lịch xem theo tuần trên trang lịch, mỗi cột là một ngày. Giữ chế độ xem danh sách hiện tại như một tùy chọn.
- Làm thẻ lớp gọn hơn trên điện thoại: giảm khoảng đệm, đặt tên giáo viên cùng dòng với giờ.
- Gửi cho hội viên một email xác nhận khi họ đặt lớp.
Vì sao cách này hiệu quả:
- Mỗi thay đổi đủ nhỏ để AI làm đúng chỉ trong một lần.
- Bạn có thể kiểm tra từng cái trước khi chuyển sang bước tiếp theo.
- Nếu một cái bị sai, bạn có thể quay lại đúng bước đó mà không làm mất những cái khác.
Nói rõ điều gì cần giữ nguyên
Khi yêu cầu thay đổi một thứ đã hoạt động, hãy nói cho AI biết điều gì không được thay đổi. Đây là cách dễ nhất để ngăn các hồi quy (những thứ từng chạy tốt bỗng bị hỏng sau một lần chỉnh sửa).
Thiết kế lại phần đầu trang chủ với tiêu đề lớn hơn và một ảnh bên phải. Giữ nguyên thanh điều hướng, bảng màu và mọi thứ bên dưới phần đầu trang.
Tương tự với dữ liệu: “Thêm trường số điện thoại cho hội viên. Không xóa hoặc đổi tên bất kỳ trường hiện có nào.”
Dùng ảnh chụp màn hình và văn bản chính xác
Những cụm như “cái ở trên cùng” rất mơ hồ. Hầu hết công cụ tạo app bằng AI đều nhận hình ảnh, và một ảnh chụp màn hình kèm ghi chú ngắn nhanh hơn một đoạn mô tả dài.
- Đính kèm ảnh chụp màn hình và nói “nút được khoanh đỏ đè lên menu trên điện thoại”.
- Dán nguyên văn thông báo lỗi thay vì diễn đạt lại.
- Trích đúng nhãn trên màn hình: “nút Lưu thay đổi ở trang Cài đặt”.
Với lỗi cụ thể, hãy dùng cấu trúc sau:
Trên trang lượt đặt, tôi nhấn Hủy cho một lượt đặt vào ngày mai. Tôi mong đợi nó biến mất khỏi danh sách. Nhưng không có gì xảy ra và lượt đặt vẫn còn đó sau khi tải lại trang. Hãy sửa và kiểm tra rằng việc hủy hoạt động.
Hướng dẫn của chúng tôi về cách gỡ lỗi ứng dụng do AI tạo đi sâu hơn về điều này.
Lập kế hoạch trước với các thay đổi lớn
Với bất cứ việc gì ảnh hưởng nhiều phần của ứng dụng, như thêm tài khoản người dùng vào một ứng dụng chưa có, thêm thanh toán, hoặc thay đổi cách cấu trúc dữ liệu, hãy yêu cầu một kế hoạch trước khi có bất kỳ thay đổi mã nguồn nào.
Trước khi thay đổi bất cứ thứ gì, hãy giải thích cách bạn sẽ thêm tài khoản nhóm: những bảng mới nào, trang nào thay đổi, và điều gì xảy ra với người dùng hiện có. Chưa sửa mã nguồn.
Hãy đọc kế hoạch. Nếu nó hiểu sai điều gì, sửa một đoạn văn rẻ hơn nhiều so với sửa một tính năng đã hoàn thành. Nhiều công cụ có một chế độ riêng cho việc này; trên Mythex, đó là chế độ Plan, bên cạnh Build và Ask.
Những điều nên tránh
| Tránh | Vì sao | Thay vào đó |
|---|---|---|
| “Làm cho nó tốt hơn” / “Làm cho nó nổi bật” | Không có mục tiêu, nên AI thay đổi mọi thứ một cách ngẫu nhiên | Nêu rõ thay đổi: “khoảng trắng giữa các phần nhiều hơn, tiêu đề lớn hơn” |
| Một prompt khổng lồ với mười tính năng | Lỗi cộng dồn; khó kiểm thử | Mỗi tin nhắn một tính năng |
| Dán khóa API vào khung chat | Khóa nằm lại trong lịch sử chat | Dùng phần bí mật (secrets) hoặc cài đặt môi trường của công cụ |
| Tranh luận với một kết quả hỏng | Mỗi bản sửa chồng lên lỗi | Quay lại, rồi diễn đạt lại |
| Chỉ định mã nguồn mà bạn không hiểu | Khóa vào một cách làm không phù hợp | Mô tả hành vi bạn muốn |
| Yêu cầu “bảo mật cấp doanh nghiệp” | Không có nghĩa cụ thể | Liệt kê các quy tắc thực tế: ai được xem gì |
Về khóa API: nếu bạn cần một dịch vụ thanh toán hoặc email, hãy đặt khóa của nó vào phần bí mật của dự án thay vì prompt. Xem biến môi trường và phần bí mật là gì nếu bạn còn mới với khái niệm này.
Mẫu prompt tái sử dụng
Điều chỉnh các mẫu này bằng cách thay những phần trong ngoặc vuông.
Ứng dụng mới:
Xây dựng một [loại ứng dụng] cho [đối tượng]. Họ [luồng chính, từng bước]. [Loại người dùng thứ hai] đăng nhập để [việc họ làm]. Lưu [dữ liệu] trong cơ sở dữ liệu. [Giao diện và cảm giác]. Bỏ qua [những thứ để sau].
Tính năng mới:
Thêm [tính năng] vào [trang]. Khi [người dùng] thực hiện [hành động], [điều gì nên xảy ra]. Chỉ [ai] mới được [làm việc đó]. Giữ nguyên [những thứ hiện có].
Thay đổi thiết kế:
Trên [trang], đổi [thành phần cụ thể] thành [thay đổi cụ thể]. Giữ nguyên [những gì cần giữ]. Kiểm tra xem nó hiển thị đúng trên màn hình có chiều rộng bằng điện thoại.
Lỗi:
Trên [trang], tôi [các bước]. Tôi mong đợi [kỳ vọng]. Nhưng thực tế là [thực tế, kèm nguyên văn thông báo lỗi]. Hãy sửa và kiểm tra luồng hoạt động.
Câu hỏi không kèm thay đổi:
Đừng thay đổi mã nguồn nào. Giải thích cách [một phần của ứng dụng] hoạt động và [dữ liệu] được lưu ở đâu.
Viết một đặc tả dài hơn
Với các dự án lớn hơn, có thể hữu ích khi viết trước một bản tóm tắt một trang và dán nó như prompt mở đầu: người dùng, các luồng cốt lõi, dữ liệu, quy tắc và những gì nằm ngoài phạm vi. Bạn thậm chí có thể nhờ AI giúp soạn nó; hướng dẫn của chúng tôi về cách viết PRD với AI cho biết cách làm. Chỉ cần giữ yêu cầu xây dựng đầu tiên ở mức luồng cốt lõi, rồi thêm phần còn lại từng bước.
Viết prompt trong Mythex
Mọi điều ở trên đều dùng được trong Mythex. Một vài điểm cụ thể giúp ích:
- Các chế độ Build, Plan và Ask. Dùng Plan cho những thay đổi lớn hoặc rủi ro, và Ask khi bạn muốn một lời giải thích mà không có chỉnh sửa nào.
- Điểm lưu (checkpoint). Sau mỗi thay đổi thành công, Mythex lưu một điểm lưu, và Revert to this point trên một phản hồi sẽ đưa dự án về trạng thái đó. Bạn cũng có thể sửa một tin nhắn trước đó và gửi lại để thử một prompt khác từ điểm đó.
- Thẻ bí mật. Khi agent cần một khóa API, nó hỏi qua một thẻ trong chat để giá trị được lưu làm phần bí mật của dự án thay vì bị ghi vào tin nhắn của bạn.
- Hình ảnh. Đính kèm ảnh chụp màn hình hoặc bản phác thảo và agent sẽ xem chúng.
Tài liệu có một trang ngắn về prompt hiệu quả và một trang về lặp lại mà không cần xây dựng lại. Nếu bạn bắt đầu từ đầu, cách xây dựng ứng dụng bằng AI hướng dẫn một dự án đầy đủ, còn cách thiết kế ứng dụng đẹp bằng AI bao gồm các prompt để làm giao diện đẹp hơn.
Câu hỏi thường gặp
Prompt cho công cụ tạo app bằng AI nên dài bao nhiêu?
Với phiên bản đầu tiên, một đoạn ngắn bốn đến tám câu thường là đủ: ai dùng ứng dụng, luồng chính, dữ liệu được lưu và ai được xem những gì. Sau đó, các prompt ngắn yêu cầu một thay đổi mỗi lần hiệu quả hơn các prompt dài.
Tôi có nên nói cho AI biết dùng framework hay ngôn ngữ nào không?
Chỉ khi bạn có lý do, chẳng hạn như có lập trình viên sẽ tiếp quản mã nguồn, hoặc một dịch vụ chỉ hoạt động với một bộ công nghệ nhất định. Nếu không, hãy mô tả sản phẩm và để công cụ tự chọn các mặc định hợp lý.
Tại sao AI cứ thay đổi những thứ tôi không yêu cầu?
Thường là do prompt quá rộng (“làm cho nó tốt hơn”) hoặc không nói rõ cần giữ nguyên điều gì. Hãy nêu đúng thứ cần thay đổi, nói rõ điều gì phải giữ nguyên, và yêu cầu một thay đổi mỗi tin nhắn.
Khi kết quả sai, nên sửa bằng nhiều prompt hơn hay bắt đầu lại?
Nếu thay đổi gần nhất làm mọi thứ tệ hơn, hãy quay lại phiên bản trước đó và diễn đạt lại, thay vì chồng thêm bản sửa lên trên. Chỉ nên tạo dự án mới khi chính ý tưởng đã thay đổi.