Viết prompt xây ứng dụng với AI: quy trình và ví dụ thực hành

Viết prompt xây ứng dụng với AI không chỉ là tìm một câu lệnh thật dài. Một yêu cầu tốt giúp AI hiểu người dùng, mục tiêu, ràng buộc và cách kiểm tra kết quả. Quan trọng hơn, nó giúp chính nhóm làm rõ điều đang muốn xây. Bài viết sử dụng một ứng dụng quản lý nhiệm vụ sinh viên làm ví dụ xuyên suốt, từ mô tả ban đầu đến sửa lỗi và bàn giao. Các mẫu dưới đây là tài liệu thực hành, không phải yêu cầu kỹ thuật bắt buộc của cuộc thi.

1. Bắt đầu bằng kết quả người dùng cần đạt

Hãy mở đầu bằng người dùng và công việc: “Tạo bản thử ứng dụng cho nhóm trưởng theo dõi nhiệm vụ trong một nhóm học phần. Người dùng cần biết việc nào sắp đến hạn và ai phụ trách.” Sau đó mô tả kết quả có thể quan sát: “Sau khi tạo nhiệm vụ, nhiệm vụ xuất hiện trong danh sách với đúng người phụ trách và ngày đã chọn.”

2. Dùng một khung prompt đủ rõ và dễ sửa

Ví dụ: “Bối cảnh: nhóm bốn sinh viên làm báo cáo. Người dùng chính: nhóm trưởng. Chức năng đầu: thêm nhiệm vụ, chọn người phụ trách, đặt hạn và đổi trạng thái. Dữ liệu thử hoàn toàn giả. Giao diện tiếng Việt, ưu tiên điện thoại. Chưa tích hợp email hay dịch vụ trả phí. Trước khi viết mã, hãy đề xuất luồng thao tác và liệt kê những điểm cần hỏi lại.”

3. Tách công việc thành các vòng có đầu ra kiểm tra được

Ở vòng đầu, yêu cầu: “Hãy mô tả các bước tạo nhiệm vụ và những trường thông tin tối thiểu. Chưa viết mã.” Khi nhóm đồng ý với luồng, chuyển sang: “Tạo giao diện thêm nhiệm vụ và danh sách bằng dữ liệu giả. Các thao tác thêm, sửa và đổi trạng thái phải hoạt động trong bản thử.” Sau đó mới bàn đến lưu dữ liệu lâu dài và phân quyền.

4. Mô tả dữ liệu và trạng thái thay vì chỉ mô tả màn hình

Tiếp theo, nêu tình huống biên: danh sách rỗng; tên quá dài; người dùng bỏ trống ngày; nhiệm vụ quá hạn; hai thành viên cùng mở một nhóm. Bạn không cần giải quyết tất cả ngay, nhưng cần biết đâu là hành vi mong muốn. Ví dụ: “Nếu chưa có nhiệm vụ, hiển thị hướng dẫn tạo việc đầu tiên. Nếu tên bị bỏ trống, báo lỗi ngay tại trường nhập và giữ nguyên các dữ liệu đã điền.”

5. Biến tiêu chí hoàn thành thành tình huống kiểm thử

“Hoạt động tốt” là một tiêu chí khó đánh giá. Hãy viết tiêu chí dưới dạng thao tác và kết quả. Ví dụ: “Khi nhập tên nhiệm vụ hợp lệ và lưu, danh sách xuất hiện một dòng mới. Khi tải lại trang, dữ liệu còn tồn tại nếu phiên bản này đã có lưu trữ lâu dài. Khi lưu thất bại, người dùng thấy thông báo và có thể thử lại.”

Trong prompt, yêu cầu AI báo rõ đã chạy kiểm tra nào và chưa kiểm tra gì. Nếu công cụ chỉ đọc mã, kết quả đó khác với việc mở ứng dụng, thao tác và xem dữ liệu sau khi lưu. Tài liệu chính thức của GitHub cũng lưu ý kết quả do AI đề xuất cần đi cùng việc kiểm tra và đánh giá của con người; ví dụ thực hành ở đây áp dụng nguyên tắc đó vào từng bước xây ứng dụng.

6. Gửi yêu cầu sửa lỗi với bằng chứng đủ dùng

Một yêu cầu rõ hơn là: “Ở form tạo nhiệm vụ, nhập tên và chọn thành viên rồi bấm Lưu. Nút chuyển sang Đang lưu nhưng không trở lại bình thường; danh sách không có nhiệm vụ mới. Mong đợi: lưu thành công thì đóng form, thất bại thì hiện lý do và cho thử lại. Hãy xác định nguyên nhân trước, sau đó sửa phạm vi nhỏ nhất có thể.”

7. Giữ bối cảnh làm việc và tránh để AI mở rộng phạm vi

Ví dụ: “Đã hoàn thành thêm và đổi trạng thái nhiệm vụ. Chưa có thông báo tự động. Dữ liệu thử không chứa thông tin cá nhân thật. Việc tiếp theo chỉ là thêm bộ lọc theo người phụ trách; không đổi đăng nhập hoặc cấu trúc dữ liệu.” Ràng buộc hẹp giúp nhóm kiểm tra thay đổi dễ hơn và tránh phát sinh công việc ngoài kế hoạch.

Hãy lưu một phiên bản có thể quay lại trước thay đổi đáng kể. Nếu công cụ đề xuất thay thư viện, xóa dữ liệu hoặc triển khai lên môi trường thật, cần đọc lý do và hiểu tác động. Một prompt rõ không đồng nghĩa mọi hành động tiếp theo đều tự động an toàn; người làm sản phẩm vẫn chịu trách nhiệm lựa chọn, kiểm tra và quyết định khi nào phát hành.

8. Bài tập: viết ba prompt cho cùng một chức năng

Chọn chức năng thêm nhiệm vụ và viết ba prompt riêng. Prompt thứ nhất yêu cầu phân tích luồng, chưa viết mã. Prompt thứ hai yêu cầu tạo chức năng theo luồng đã duyệt. Prompt thứ ba yêu cầu kiểm tra các tình huống tên trống, hạn không hợp lệ và lưu thất bại. Đọc kết quả từng vòng trước khi chuyển tiếp.

• Prompt có nêu người dùng và kết quả mong muốn không?
• Dữ liệu mẫu có được xác định là giả không?
• Có giới hạn rõ phần được phép thay đổi không?
• Tiêu chí hoàn thành có thể kiểm tra bằng thao tác không?
• Nhóm có đọc lại và thử kết quả trước vòng tiếp theo không?

9. Câu hỏi thường gặp về prompt xây ứng dụng

Prompt càng dài có càng tốt không?

Không nhất thiết. Một yêu cầu ngắn nhưng đủ bối cảnh có thể hữu ích hơn một đoạn dài chứa nhiều mục tiêu mâu thuẫn. Hãy giữ thông tin ảnh hưởng đến công việc hiện tại, bỏ những chỉ dẫn trang trí lặp lại và ghi riêng các quyết định đã được chốt.

AI nói đã hoàn thành thì có thể nộp bài ngay không?

Chưa nên chỉ dựa vào lời xác nhận đó. Bạn cần mở sản phẩm, thực hiện luồng chính, kiểm tra dữ liệu và đối chiếu yêu cầu bài nộp do BTC công bố. Những phần chưa kiểm tra nên được ghi rõ trong tài liệu thay vì trình bày như đã vận hành đầy đủ.

Có nên dùng lại một prompt mẫu cho mọi dự án không?

Bạn có thể dùng lại cấu trúc, nhưng cần thay người dùng, dữ liệu, giới hạn và tiêu chí hoàn thành. Giá trị của prompt nằm ở việc diễn đạt đúng quyết định sản phẩm của nhóm. Một mẫu có nhiều thuật ngữ không thể thay cho việc hiểu nhu cầu và quan sát kết quả thực tế.