Prompt Gemini lập trình
Bùi Tấn Lực - 103
- 08/10/2026
Gemini có thể hỗ trợ nhiều công việc lập trình từ viết một đoạn mã nhỏ, xây dựng chức năng mới, giải thích code, tìm lỗi cho đến refactor và phát triển một quy trình xử lý hoàn chỉnh. Tuy nhiên, chất lượng kết quả không chỉ phụ thuộc vào khả năng của mô hình mà còn phụ thuộc rất lớn vào cách bạn mô tả yêu cầu.
Một yêu cầu như “viết giúp tôi code đăng nhập” thường quá chung chung. Gemini có thể tạo ra mã chạy được nhưng chưa chắc phù hợp với ngôn ngữ, framework, cơ sở dữ liệu, cấu trúc dự án hoặc tiêu chuẩn bảo mật mà bạn đang sử dụng. Ngược lại, khi yêu cầu được mô tả rõ mục tiêu, môi trường, dữ liệu đầu vào, kết quả mong muốn và các giới hạn cần tuân thủ, khả năng nhận được mã phù hợp sẽ cao hơn đáng kể.
Vì vậy, thay vì chỉ tìm một câu lệnh mẫu rồi sao chép, cách hiệu quả hơn là hiểu cách xây dựng yêu cầu dành riêng cho công việc lập trình. Bài viết này tập trung vào phương pháp đó, đồng thời đưa ra những mẫu có thể điều chỉnh cho từng tình huống thực tế.
Muốn Gemini viết code đúng, trước tiên phải mô tả đúng bài toán
Trong lập trình, vấn đề quan trọng không phải lúc nào cũng nằm ở câu lệnh bạn muốn Gemini viết. Điều quan trọng hơn là Gemini phải hiểu bạn đang giải quyết bài toán gì.
Ví dụ, yêu cầu “tạo API quản lý sản phẩm” chưa cho biết rất nhiều thông tin. API có thể được viết bằng PHP, Node.js, Python hoặc một ngôn ngữ khác. Cơ sở dữ liệu có thể là MySQL, PostgreSQL hoặc MongoDB. API cũng có thể dùng REST, xác thực bằng session, JWT hoặc một cơ chế riêng.
Một yêu cầu tốt nên giúp mô hình trả lời được ít nhất những câu hỏi sau:
- Đang sử dụng ngôn ngữ lập trình nào?
- Framework hoặc thư viện chính là gì?
- Chức năng cần xây dựng cụ thể là gì?
- Dữ liệu đầu vào có cấu trúc như thế nào?
- Kết quả đầu ra cần có dạng gì?
- Có những quy tắc hoặc giới hạn nào không được thay đổi?
- Đoạn code sẽ được đặt ở đâu trong dự án hiện tại?
- Có yêu cầu đặc biệt về hiệu năng, bảo mật hoặc khả năng tương thích hay không?
Càng nhiều thông tin quan trọng được xác định rõ, Gemini càng có cơ sở để đưa ra giải pháp sát với dự án thay vì tự suy đoán.
Tuy nhiên, “càng dài càng tốt” cũng không phải nguyên tắc đúng. Một yêu cầu dài nhưng chứa nhiều thông tin không liên quan có thể khiến vấn đề chính bị che khuất. Với công việc lập trình, nên ưu tiên thông tin có ảnh hưởng trực tiếp đến cách triển khai.
Bốn lớp thông tin nên có trong một yêu cầu lập trình
Có thể hình dung một yêu cầu tốt gồm bốn lớp chính: bối cảnh, nhiệm vụ, ràng buộc và kết quả mong muốn.
Bối cảnh cho Gemini biết dự án đang sử dụng công nghệ gì. Chẳng hạn, bạn có thể nói dự án dùng PHP 8.2, MySQL và Bootstrap, hoặc đang sử dụng Laravel với một cấu trúc thư mục có sẵn.
Nhiệm vụ mô tả chính xác việc cần làm. Thay vì nói “sửa phần sản phẩm”, hãy chỉ rõ cần thêm chức năng tìm kiếm sản phẩm theo tên, phân trang kết quả và giữ nguyên giao diện hiện tại.
Ràng buộc giúp hạn chế những thay đổi ngoài ý muốn. Đây có thể là yêu cầu không cài thêm thư viện, không thay đổi tên bảng, không sửa API hiện có hoặc phải tương thích với một phiên bản PHP cụ thể.
Kết quả mong muốn xác định Gemini cần trả về thứ gì. Bạn có thể yêu cầu một file hoàn chỉnh, chỉ phần code cần thay đổi, giải thích nguyên nhân lỗi trước khi sửa hoặc đưa ra cả code và hướng dẫn tích hợp.
Bốn lớp này tạo thành một khung khá đơn giản nhưng hữu ích để biến một yêu cầu mơ hồ thành một nhiệm vụ có thể triển khai.
Cấu trúc một prompt lập trình có thể tái sử dụng
Thay vì mỗi lần cần code lại viết một yêu cầu hoàn toàn mới, bạn có thể xây dựng một khung cố định rồi thay đổi phần nội dung bên trong. Cách này đặc biệt hữu ích khi thường xuyên sử dụng Gemini để làm việc với cùng một dự án.
Một cấu trúc thực tế có thể bắt đầu như sau:
Vai trò:
Bạn là lập trình viên có kinh nghiệm với [ngôn ngữ/framework].
Bối cảnh:
Tôi đang xây dựng [mô tả dự án].
Công nghệ đang sử dụng: [công nghệ].
Cấu trúc hoặc phần code liên quan:
[đưa thông tin cần thiết vào đây]
Nhiệm vụ:
Hãy thực hiện [mô tả chính xác chức năng cần làm].
Yêu cầu:
- [yêu cầu 1]
- [yêu cầu 2]
- [yêu cầu 3]
Ràng buộc:
- Không sử dụng [thư viện/công nghệ nếu không được phép].
- Không thay đổi [thành phần cần giữ nguyên].
- Phải tương thích với [phiên bản/môi trường].
Kết quả:
- Cung cấp code hoàn chỉnh cho phần cần thay đổi.
- Giải thích ngắn gọn cách hoạt động.
- Nêu những điểm cần kiểm tra sau khi tích hợp.
Điểm đáng chú ý là khung này không phải công thức bắt buộc. Bạn không cần lúc nào cũng phải điền đủ mọi phần. Nếu chỉ cần viết một hàm đơn giản, một yêu cầu ngắn có thể hiệu quả hơn.
Ví dụ, khi cần tạo một hàm PHP để kiểm tra dữ liệu email, không nhất thiết phải mô tả cả dự án. Chỉ cần cung cấp phiên bản PHP, đầu vào, đầu ra và những điều kiện cần kiểm tra là đủ.
Ngược lại, khi yêu cầu Gemini chỉnh sửa một module lớn, việc cung cấp bối cảnh và giới hạn thay đổi trở nên quan trọng hơn nhiều.
Đừng trộn yêu cầu chức năng với những điều không liên quan
Một lỗi thường gặp là đưa quá nhiều yêu cầu vào cùng một lần hỏi. Chẳng hạn, bạn vừa yêu cầu Gemini sửa API, thiết kế giao diện, tối ưu cơ sở dữ liệu, viết tài liệu và giải thích toàn bộ dự án trong một câu lệnh.
Với những công việc lớn, nên chia thành các nhiệm vụ có quan hệ với nhau. Có thể bắt đầu bằng việc phân tích yêu cầu, tiếp tục thiết kế giải pháp, sau đó mới viết code và cuối cùng kiểm tra lại.
Cách chia nhỏ này giúp bạn dễ phát hiện sai hướng. Nếu thiết kế ban đầu đã không phù hợp, bạn có thể điều chỉnh trước khi Gemini tạo ra hàng trăm dòng code dựa trên giả định sai.
Cho Gemini biết môi trường lập trình trước khi yêu cầu viết code
Cùng một chức năng nhưng cách triển khai có thể hoàn toàn khác nhau tùy môi trường. Đây là lý do thông tin về công nghệ đang sử dụng thường quan trọng hơn việc yêu cầu Gemini “viết code thật hay”.
Ví dụ, nếu bạn chỉ nói “tạo chức năng đăng nhập”, Gemini không biết bạn muốn sử dụng PHP thuần hay Laravel, truy vấn MySQL bằng PDO hay một ORM, lưu phiên đăng nhập bằng session hay cơ chế token.
Thay vào đó, hãy cung cấp những thông tin ảnh hưởng trực tiếp đến việc viết code.
Tôi đang sử dụng PHP 8.2, MySQL và PDO.
Tôi có bảng users gồm:
- id
- name
- email
- password
Hãy viết chức năng đăng nhập bằng email và mật khẩu.
Yêu cầu:
- Sử dụng PDO với prepared statement.
- Mật khẩu trong cơ sở dữ liệu được lưu bằng password_hash().
- Không xây dựng lại giao diện.
- Khi đăng nhập thành công, lưu id người dùng vào session.
- Khi thất bại, trả về thông báo lỗi rõ ràng.
Yêu cầu trên tốt hơn nhiều so với việc chỉ nói “viết code đăng nhập PHP”. Gemini đã biết ngôn ngữ, phiên bản, cơ sở dữ liệu, cách truy cập dữ liệu, cấu trúc bảng và những nguyên tắc cần tuân thủ.
Đặc biệt, nếu bạn đang làm việc trên một dự án có sẵn, hãy đưa đoạn code liên quan vào yêu cầu thay vì bắt Gemini tự đoán cấu trúc. Khi có code hiện tại, Gemini có thể dựa trên đó để đề xuất thay đổi phù hợp hơn với hệ thống đang tồn tại.
Khi đưa code hiện tại, hãy nói rõ Gemini được phép thay đổi phần nào
Đây là một chi tiết nhỏ nhưng có tác động lớn đến kết quả. Nếu bạn gửi cả một file dài và chỉ nói “tối ưu code này”, Gemini có thể thay đổi nhiều phần mà bạn không muốn động vào.
Tốt hơn là xác định phạm vi:
Đây là file hiện tại của tôi.
Hãy sửa riêng chức năng tìm kiếm sản phẩm.
Không thay đổi:
- Tên class.
- Tên các hàm hiện có.
- Cấu trúc HTML.
- Câu lệnh SQL dùng cho chức năng khác.
Được phép:
- Thêm hàm hỗ trợ tìm kiếm.
- Điều chỉnh câu truy vấn tìm kiếm.
- Bổ sung kiểm tra dữ liệu đầu vào.
Sau khi sửa, hãy trả về phần code hoàn chỉnh của file.
Cách yêu cầu này giúp giảm khả năng Gemini “tiện tay” viết lại những phần không nằm trong phạm vi công việc.
Nếu dự án có quy ước riêng, chẳng hạn cách đặt tên biến, cấu trúc thư mục, quy tắc xử lý lỗi hoặc chuẩn API, bạn cũng nên đưa những quy tắc đó vào phần bối cảnh hoặc ràng buộc.
Cách yêu cầu Gemini tạo một chức năng mới từ đầu
Khi cần xây dựng một chức năng chưa tồn tại trong dự án, nên mô tả chức năng theo luồng hoạt động thay vì chỉ nêu tên tính năng. Gemini sẽ dễ hiểu hơn nếu biết người dùng thực hiện thao tác gì, hệ thống xử lý dữ liệu ra sao và cuối cùng phải trả về kết quả nào.
Chẳng hạn, thay vì yêu cầu “tạo bộ lọc sản phẩm”, hãy mô tả toàn bộ hành vi mong muốn: người dùng chọn danh mục, nhập khoảng giá, hệ thống nhận dữ liệu, truy vấn cơ sở dữ liệu và hiển thị danh sách tương ứng. Nếu có phân trang hoặc trạng thái khi không tìm thấy sản phẩm, cũng nên nói rõ.
Tôi cần bổ sung chức năng lọc sản phẩm vào trang danh sách hiện tại.
Luồng hoạt động:
1. Người dùng chọn danh mục sản phẩm.
2. Người dùng có thể nhập giá tối thiểu và giá tối đa.
3. Khi nhấn nút lọc, hệ thống gửi các điều kiện lên server.
4. Server truy vấn cơ sở dữ liệu theo những điều kiện đã nhập.
5. Kết quả được hiển thị trong danh sách hiện tại.
6. Nếu không có sản phẩm phù hợp, hiển thị thông báo tương ứng.
Yêu cầu:
- Giữ nguyên giao diện hiện tại.
- Không thay đổi cấu trúc bảng products.
- Xử lý trường hợp người dùng bỏ trống một hoặc nhiều điều kiện.
- Không ghép trực tiếp dữ liệu người dùng vào câu SQL.
- Giữ nguyên cơ chế phân trang đang có.
Điểm mạnh của cách viết này là Gemini không chỉ biết “cần làm bộ lọc”, mà còn hiểu được hành vi của chức năng. Từ đó, code tạo ra thường sát với nhu cầu hơn và ít phải sửa lại.
Mô tả đầu vào và đầu ra càng rõ càng tốt
Đối với hàm, API hoặc các đoạn xử lý dữ liệu, đầu vào và đầu ra là hai thông tin đặc biệt quan trọng. Nếu không xác định rõ, Gemini có thể tự chọn kiểu dữ liệu hoặc định dạng trả về mà bạn không mong muốn.
Ví dụ, nếu cần một hàm tính tổng tiền giỏ hàng, hãy nói rõ dữ liệu đầu vào là mảng sản phẩm, mỗi phần tử có những trường nào và kết quả cần trả về kiểu dữ liệu gì.
Viết một hàm PHP tên calculateCartTotal().
Đầu vào là mảng sản phẩm. Mỗi sản phẩm có:
- price: giá sản phẩm dạng số
- quantity: số lượng dạng số nguyên
- discount: phần trăm giảm giá, có thể bằng 0
Yêu cầu:
- Tính thành tiền của từng sản phẩm sau giảm giá.
- Nhân với số lượng.
- Cộng toàn bộ sản phẩm.
- Kết quả trả về là số.
- Nếu mảng rỗng, trả về 0.
- Không làm thay đổi mảng đầu vào.
Sau phần code, giải thích ngắn gọn công thức tính.
Đây là cách đặc biệt hữu ích khi làm việc với những đoạn code nhỏ. Bạn không cần viết một prompt dài, nhưng những thông tin có ảnh hưởng đến kết quả phải được xác định.
Prompt để Gemini phân tích code trước khi sửa
Một trong những cách sử dụng hiệu quả là không yêu cầu sửa code ngay lập tức. Với những đoạn code phức tạp, nên để Gemini phân tích trước, xác định nguyên nhân rồi mới quyết định phương án chỉnh sửa.
Điều này giúp tránh tình trạng mô hình nhìn thấy một biểu hiện lỗi rồi thay đổi ngay một đoạn code mà chưa hiểu đầy đủ luồng xử lý.
Hãy phân tích đoạn code dưới đây trước, chưa cần sửa code.
Mục tiêu của tôi là tìm nguyên nhân khiến [mô tả lỗi].
Hãy trả lời theo thứ tự:
1. Code hiện tại đang hoạt động như thế nào?
2. Vấn đề có khả năng nằm ở đâu?
3. Nguyên nhân nào là đáng chú ý nhất?
4. Có trường hợp dữ liệu nào khiến lỗi xảy ra không?
5. Đề xuất cách sửa phù hợp nhất.
Không tự ý viết lại toàn bộ code.
Sau khi phân tích xong, chờ tôi yêu cầu bước sửa.
Cách làm này phù hợp với các lỗi khó xác định, đặc biệt khi một lỗi có thể xuất phát từ nhiều lớp khác nhau như giao diện, JavaScript, API, PHP hoặc cơ sở dữ liệu.
Sau khi đã xác định nguyên nhân, bạn có thể tiếp tục bằng một yêu cầu riêng để Gemini sửa đúng phần đó. Việc tách hai bước giúp quá trình kiểm soát thay đổi rõ ràng hơn.
Yêu cầu Gemini giải thích nguyên nhân thay vì chỉ đưa đáp án
Nếu mục tiêu không chỉ là có code chạy được mà còn muốn hiểu vấn đề, hãy yêu cầu Gemini giải thích nguyên nhân và lý do lựa chọn giải pháp.
Ví dụ, thay vì hỏi “sửa lỗi SQL này”, có thể yêu cầu:
Hãy tìm lỗi trong đoạn code SQL và PHP dưới đây.
Tôi muốn bạn:
- Chỉ ra chính xác câu lệnh hoặc phần xử lý gây lỗi.
- Giải thích vì sao lỗi xảy ra.
- Nêu điều kiện khiến lỗi có thể xuất hiện.
- Đưa ra phương án sửa ít thay đổi nhất.
- Sau đó cung cấp code đã sửa.
Không thay đổi những phần không liên quan đến lỗi.
Với cách yêu cầu này, phần trả lời không chỉ là một đoạn code thay thế. Bạn còn có thể biết lỗi xuất phát từ đâu và nhận ra những trường hợp tương tự trong các phần khác của dự án.
Cách dùng Gemini để debug lỗi hiệu quả hơn
Khi debug, thông tin “code bị lỗi” thường chưa đủ. Một yêu cầu tốt nên chứa ít nhất đoạn code liên quan, thông báo lỗi, hành vi thực tế và kết quả mà bạn mong muốn.
Trong đó, thông báo lỗi nguyên bản rất quan trọng. Không nên chỉ mô tả lại theo cách hiểu của mình nếu hệ thống đã cung cấp một thông báo cụ thể.
Ví dụ, thay vì viết “PHP bị lỗi database”, hãy cung cấp thông báo lỗi, câu truy vấn liên quan và dữ liệu được sử dụng tại thời điểm xảy ra lỗi.
Tôi đang gặp lỗi trong chức năng thêm sản phẩm.
Kết quả mong muốn:
- Dữ liệu sản phẩm được lưu vào bảng products.
Kết quả thực tế:
- Form gửi dữ liệu thành công nhưng bản ghi không được tạo.
Thông báo lỗi:
[giữ nguyên thông báo lỗi tại đây]
Đây là đoạn code xử lý:
[dán code tại đây]
Hãy:
1. Phân tích nguyên nhân dựa trên code và thông báo lỗi.
2. Xác định giả thuyết có khả năng cao nhất.
3. Chỉ ra dòng hoặc phần xử lý liên quan.
4. Đưa ra bản sửa hoàn chỉnh.
5. Giải thích ngắn gọn cách kiểm tra lại sau khi sửa.
Nếu lỗi vẫn chưa đủ thông tin để xác định nguyên nhân, có thể yêu cầu Gemini liệt kê những thông tin cần kiểm tra thay vì để mô hình tự đoán. Đây là điểm quan trọng khi làm việc với lỗi thực tế.
Đừng yêu cầu “sửa tất cả lỗi” khi chưa xác định phạm vi
Những câu như “tối ưu toàn bộ code”, “sửa hết lỗi” hoặc “làm code chuyên nghiệp hơn” có phạm vi quá rộng. Gemini có thể đưa ra rất nhiều thay đổi, trong đó có những thay đổi không cần thiết hoặc khó kiểm chứng.
Nếu đang xử lý một lỗi cụ thể, nên giới hạn phạm vi sửa. Sau khi chức năng hoạt động ổn định, mới tiếp tục một vòng tối ưu riêng.
Cách này cũng giúp việc so sánh trước và sau khi sửa dễ dàng hơn. Nếu một lần thay đổi quá nhiều thành phần, khi phát sinh lỗi mới sẽ khó biết nguyên nhân đến từ thay đổi nào.
Yêu cầu Gemini refactor code mà không phá vỡ chức năng cũ
Refactor khác với viết lại code từ đầu. Mục tiêu của refactor thường là cải thiện cấu trúc, khả năng đọc, khả năng bảo trì hoặc giảm sự lặp lại nhưng vẫn giữ nguyên hành vi của chương trình.
Do đó, khi yêu cầu Gemini refactor, cần nói rõ rằng hành vi hiện tại phải được bảo toàn.
Hãy refactor đoạn code dưới đây.
Mục tiêu:
- Giảm code lặp.
- Tách phần xử lý có trách nhiệm khác nhau.
- Làm code dễ đọc và dễ bảo trì hơn.
- Không thay đổi kết quả đầu ra hiện tại.
Ràng buộc:
- Không đổi tên các hàm public.
- Không thay đổi tên biến được sử dụng ở phần code bên ngoài.
- Không thay đổi cấu trúc dữ liệu đầu vào và đầu ra.
- Không thêm thư viện mới.
- Không thay đổi logic nghiệp vụ.
Hãy trả về:
1. Code sau khi refactor.
2. Những phần đã thay đổi.
3. Giải thích vì sao cách tổ chức mới tốt hơn.
4. Những hành vi cũ cần kiểm tra sau khi áp dụng.
Việc xác định rõ “không thay đổi logic nghiệp vụ” đặc biệt quan trọng. Nếu không có ràng buộc này, Gemini có thể nhìn thấy một đoạn code chưa tối ưu và tự thay đổi cả cách chương trình hoạt động.
Với những module quan trọng, bạn cũng nên yêu cầu Gemini chỉ ra các trường hợp cần test sau khi refactor. Đây là bước cần thiết vì code ngắn hơn hoặc đẹp hơn chưa đồng nghĩa với việc hành vi của hệ thống vẫn chính xác.
Cách yêu cầu Gemini viết code an toàn hơn
Trong lập trình thực tế, code chạy được chỉ là một phần của yêu cầu. Với những chức năng nhận dữ liệu từ người dùng, truy cập cơ sở dữ liệu, xử lý tài khoản hoặc cung cấp API, nên đưa các yêu cầu liên quan đến bảo mật vào ngay từ đầu.
Không nên chờ đến khi Gemini viết xong code mới hỏi “code này có an toàn không?”. Thay vào đó, hãy xác định tiêu chí an toàn ngay trong yêu cầu.
Tôi cần xây dựng chức năng tìm kiếm dữ liệu từ cơ sở dữ liệu.
Yêu cầu:
- Dữ liệu tìm kiếm đến từ người dùng.
- Sử dụng prepared statement.
- Không nối trực tiếp dữ liệu người dùng vào câu SQL.
- Xử lý trường hợp dữ liệu đầu vào rỗng.
- Kiểm tra và giới hạn dữ liệu đầu vào phù hợp.
- Không để thông báo lỗi nội bộ nhạy cảm xuất hiện trực tiếp cho người dùng.
Hãy cung cấp code và giải thích những biện pháp bảo vệ đã sử dụng.
Với các chức năng liên quan đến xác thực, phân quyền, tải file, thanh toán hoặc dữ liệu riêng tư, nên cung cấp yêu cầu bảo mật cụ thể thay vì chỉ dùng một câu chung chung như “hãy viết code bảo mật”.
Gemini có thể hỗ trợ phát hiện nhiều vấn đề, nhưng kết quả do AI tạo ra vẫn cần được kiểm tra và thử nghiệm trong môi trường phù hợp trước khi đưa vào hệ thống thật. Đặc biệt, không nên xem việc Gemini nói rằng code “an toàn” là bằng chứng cho thấy code đã được kiểm tra bảo mật đầy đủ.
Những mẫu prompt Gemini hữu ích cho công việc lập trình hằng ngày
Sau khi đã nắm được cách xây dựng yêu cầu, bạn có thể biến những tình huống thường gặp trong quá trình lập trình thành các mẫu prompt có thể tái sử dụng. Điểm quan trọng là không sao chép máy móc một mẫu duy nhất cho mọi công việc. Hãy thay đổi phần bối cảnh, dữ liệu và ràng buộc để phù hợp với dự án thực tế.
Yêu cầu viết một hàm mới
Khi cần một hàm độc lập, nên mô tả rõ nhiệm vụ, dữ liệu nhận vào, giá trị trả về và các trường hợp đặc biệt.
Viết một hàm [tên hàm] bằng [ngôn ngữ].
Mục đích:
[Hàm cần thực hiện công việc gì?]
Đầu vào:
- [tham số 1]: [kiểu dữ liệu và ý nghĩa]
- [tham số 2]: [kiểu dữ liệu và ý nghĩa]
Đầu ra:
- [kiểu dữ liệu]
- [mô tả kết quả]
Trường hợp đặc biệt:
- [trường hợp 1]
- [trường hợp 2]
Yêu cầu:
- Không sử dụng thư viện bên ngoài.
- Code dễ đọc và có thể tái sử dụng.
- Không làm thay đổi dữ liệu đầu vào.
Yêu cầu tạo API
Với API, ngoài chức năng chính, nên xác định phương thức HTTP, dữ liệu gửi lên, cấu trúc phản hồi và cách xử lý lỗi. Nếu thiếu những thông tin này, Gemini có thể tạo ra API đúng về ý tưởng nhưng không tương thích với phần frontend hoặc ứng dụng đang gọi API.
Tôi cần xây dựng API [tên chức năng].
Công nghệ:
- Backend: [công nghệ]
- Database: [công nghệ]
Endpoint:
[đường dẫn]
Phương thức:
[GET/POST/PUT/PATCH/DELETE]
Dữ liệu đầu vào:
[liệt kê các trường]
Kết quả thành công:
[mô tả dữ liệu cần trả về]
Khi có lỗi:
- Dữ liệu không hợp lệ: [cách phản hồi]
- Không tìm thấy dữ liệu: [cách phản hồi]
- Lỗi hệ thống: [cách phản hồi]
Hãy viết phần backend và giữ cấu trúc phản hồi nhất quán giữa các trường hợp.
Yêu cầu viết JavaScript xử lý giao diện
Nếu cần Gemini viết JavaScript cho một giao diện có sẵn, hãy cung cấp cấu trúc HTML liên quan thay vì mô tả bằng lời quá chung chung. Mô hình sẽ dễ xác định phần tử cần thao tác hơn.
Tôi có HTML hiện tại bên dưới.
Khi người dùng nhấn nút có id "btn-search":
- Lấy giá trị từ ô nhập có id "keyword".
- Nếu rỗng, hiển thị thông báo.
- Nếu có dữ liệu, gửi request đến endpoint hiện tại.
- Trong khi chờ kết quả, hiển thị trạng thái đang tải.
- Khi thành công, cập nhật danh sách kết quả.
- Khi lỗi, hiển thị thông báo phù hợp.
Yêu cầu:
- Chỉ sử dụng JavaScript thuần.
- Không thêm thư viện.
- Không thay đổi HTML hiện có nếu không cần thiết.
- Không reload toàn bộ trang.
Đây là HTML:
[dán phần HTML liên quan vào đây]
Cách yêu cầu Gemini viết code dựa trên code có sẵn
Trong dự án thực tế, bạn thường không bắt đầu từ một trang giấy trắng. Phần lớn công việc là bổ sung hoặc thay đổi code đã tồn tại. Vì vậy, khả năng cung cấp đúng ngữ cảnh quan trọng hơn việc viết một prompt thật dài.
Nếu chỉ đưa một file nhỏ, bạn có thể gửi trực tiếp toàn bộ file. Với dự án lớn, không nên gửi mọi thứ một cách thiếu chọn lọc. Hãy cung cấp những file hoặc đoạn code có liên quan trực tiếp đến chức năng cần sửa.
Ví dụ, khi cần sửa một form, có thể cần HTML của form, JavaScript xử lý sự kiện và đoạn backend tiếp nhận dữ liệu. Những phần hoàn toàn không liên quan chỉ làm tăng lượng thông tin mà Gemini phải xử lý.
Tôi đang có chức năng đăng ký tài khoản gồm 3 phần:
1. Form HTML.
2. JavaScript gửi dữ liệu.
3. PHP xử lý dữ liệu.
Vấn đề:
Form gửi được request nhưng thông báo lỗi không hiển thị đúng.
Hãy đọc cả 3 phần để xác định luồng dữ liệu từ frontend đến backend.
Mục tiêu:
- Xác định nguyên nhân.
- Sửa lỗi.
- Giữ nguyên giao diện.
- Không thay đổi tên các trường dữ liệu.
Hãy giải thích ngắn gọn luồng dữ liệu hiện tại trước khi đưa code đã sửa.
Kiểu yêu cầu này giúp Gemini nhìn vấn đề theo toàn bộ luồng thay vì chỉ sửa một đoạn code riêng lẻ.
Khi gửi nhiều file, hãy đánh dấu vai trò của từng file
Nếu đưa nhiều đoạn code cùng lúc, nên nói rõ file nào chịu trách nhiệm cho phần nào. Điều này giúp giảm nhầm lẫn, nhất là khi nhiều file có các hàm hoặc biến tương tự nhau.
File 1: login.html
- Chứa giao diện đăng nhập.
File 2: login.js
- Kiểm tra dữ liệu và gửi request.
File 3: login.php
- Nhận request và kiểm tra tài khoản.
File 4: database.php
- Tạo kết nối cơ sở dữ liệu.
Hãy phân tích luồng xử lý từ login.html đến login.php.
Chỉ sửa những file thực sự cần thay đổi.
Không thay đổi database.php nếu không cần thiết.
Đây cũng là cách tốt để Gemini hiểu được mối quan hệ giữa các thành phần trước khi đề xuất thay đổi.
Yêu cầu Gemini tối ưu code nhưng phải có tiêu chí rõ ràng
Tối ưu là một từ khá rộng. Một đoạn code có thể được tối ưu về tốc độ, bộ nhớ, số lần truy vấn cơ sở dữ liệu, khả năng đọc hoặc khả năng bảo trì. Vì vậy, nếu chỉ yêu cầu “tối ưu code”, bạn chưa xác định rõ mình muốn cải thiện điều gì.
Trước khi yêu cầu tối ưu, hãy xác định ưu tiên.
Hãy tối ưu đoạn code dưới đây với mục tiêu chính là giảm số lần truy vấn MySQL.
Yêu cầu:
- Giữ nguyên kết quả trả về.
- Không thay đổi cấu trúc dữ liệu đầu ra.
- Không sử dụng thư viện mới.
- Không thay đổi giao diện.
- Ưu tiên giải pháp dễ bảo trì.
- Nếu có nhiều phương án, hãy so sánh trước khi chọn phương án phù hợp.
Sau khi đưa code mới, hãy chỉ ra:
- Đã giảm truy vấn ở đâu.
- Vì sao cách mới hiệu quả hơn.
- Có đánh đổi nào về bộ nhớ hoặc độ phức tạp hay không.
Với cách này, Gemini không chỉ đưa ra một phiên bản code khác mà còn phải gắn thay đổi với mục tiêu tối ưu cụ thể.
Nếu chưa biết chính xác điểm nghẽn nằm ở đâu, tốt hơn là yêu cầu phân tích trước. Đừng mặc định rằng một đoạn code dài hoặc có nhiều vòng lặp chắc chắn là nguyên nhân gây chậm.
Cách yêu cầu Gemini viết test cho code
Test là phần thường bị bỏ qua khi sử dụng AI để lập trình. Tuy nhiên, một chức năng càng quan trọng thì việc yêu cầu Gemini xây dựng các trường hợp kiểm thử càng có giá trị.
Bạn có thể yêu cầu Gemini suy nghĩ về cả trường hợp bình thường, dữ liệu rỗng, dữ liệu sai định dạng và những tình huống biên.
Dựa trên hàm dưới đây, hãy xây dựng bộ test.
Yêu cầu:
- Test trường hợp dữ liệu hợp lệ.
- Test dữ liệu rỗng.
- Test dữ liệu sai kiểu.
- Test giá trị bằng 0.
- Test giá trị âm nếu có thể xảy ra.
- Test dữ liệu ở giới hạn nhỏ nhất và lớn nhất.
- Mỗi test phải nêu rõ dữ liệu đầu vào và kết quả mong đợi.
Không sửa hàm hiện tại.
Nếu phát hiện hành vi có thể gây lỗi, hãy ghi chú riêng sau danh sách test.
Cách yêu cầu này đặc biệt hữu ích trước khi refactor. Nếu bạn có một bộ test thể hiện hành vi hiện tại, Gemini có thể dựa vào đó để sửa code mà vẫn giữ được những hành vi cần thiết.
Yêu cầu Gemini giải thích code theo trình độ người đọc
Không phải lúc nào người sử dụng Gemini cũng muốn một lời giải thích ở mức chuyên gia. Một đoạn code có thể được giải thích theo nhiều mức độ khác nhau. Vì vậy, nếu bạn đang học hoặc cần bàn giao code cho người khác, hãy nói rõ đối tượng đọc.
Hãy giải thích đoạn code này cho người mới học PHP.
Yêu cầu:
- Giải thích từ trên xuống dưới.
- Nêu vai trò của những phần quan trọng.
- Giải thích các hàm PHP được sử dụng.
- Không dùng thuật ngữ chuyên môn nếu không giải thích trước.
- Sau cùng, tóm tắt luồng hoạt động bằng các bước đơn giản.
Không viết lại code trừ khi cần một đoạn ngắn để minh họa.
Nếu người đọc đã có kinh nghiệm, có thể yêu cầu tập trung vào kiến trúc, hiệu năng, khả năng bảo trì hoặc những điểm có thể gây lỗi. Việc xác định trình độ người đọc giúp câu trả lời bớt lan man và phù hợp hơn với mục đích sử dụng.
Đừng để Gemini tự đoán những thông tin quan trọng
Một trong những nguyên nhân khiến code do AI tạo ra không phù hợp là các thông tin quan trọng bị bỏ trống. Khi không biết, Gemini thường phải đưa ra giả định. Một giả định sai ở đầu quá trình có thể kéo theo nhiều đoạn code sai phía sau.
Nếu có thông tin chưa chắc chắn, hãy nói rõ rằng thông tin đó chưa xác định. Bạn có thể yêu cầu Gemini liệt kê những điểm cần làm rõ trước khi viết code.
Tôi muốn xây dựng chức năng [mô tả chức năng].
Trước khi viết code:
- Hãy kiểm tra yêu cầu đã đủ thông tin chưa.
- Liệt kê những thông tin còn thiếu có thể ảnh hưởng đến cách triển khai.
- Không tự ý giả định các thông tin quan trọng.
- Nếu có nhiều phương án kiến trúc, hãy nêu ngắn gọn ưu và nhược điểm.
Chỉ bắt đầu viết code sau khi xác định được những thông tin cần thiết.
Đây là một cách sử dụng Gemini rất hữu ích với những bài toán lớn. Thay vì biến AI thành công cụ “sinh code ngay lập tức”, bạn sử dụng nó như một người hỗ trợ phân tích trước khi triển khai.
Đặc biệt, với các hệ thống đang vận hành, việc giảm những giả định không được kiểm chứng có thể quan trọng hơn việc tạo code thật nhanh.
- 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 *
