Một yêu cầu lập trình tốt cho AI trả lời đủ sáu câu: mã này chạy trong dự án nào, cần làm ra kết quả gì, có ràng buộc gì không được vi phạm, đầu vào và đầu ra mẫu trông thế nào, bạn muốn nhận câu trả lời dưới dạng gì, và thế nào thì coi là xong. Thiếu câu nào, trợ lý sẽ tự đoán câu đó — và phần lớn lần "AI viết sai" thực ra là AI đoán khác ý bạn.
Bài này đưa ra khung sáu phần đó, giải thích vì sao từng phần quan trọng, rồi đặt một câu lệnh kém cạnh một câu lệnh đã sửa để bạn thấy khác biệt. Khung dùng được cho chatbot chung, cho khung chat trong trình soạn thảo, và cho cả tác tử tự sửa tệp. Nó không phải công thức thần kỳ; nó là danh sách những thứ một đồng nghiệp giỏi cũng sẽ hỏi lại nếu bạn quên nói.
Vì sao AI viết mã "đúng cú pháp mà sai ý"
Mô hình ngôn ngữ sinh mã bằng cách đoán phần tiếp theo hợp lý nhất dựa trên những gì nó thấy trong yêu cầu và trong ngữ cảnh được nạp. Khi yêu cầu chỉ có một câu như "viết hàm tính phí giao hàng", nó phải tự điền hàng chục quyết định: dùng ngôn ngữ nào, đơn vị cân nặng là gam hay ki-lô-gam, làm tròn lên hay xuống, trả về số nguyên hay số thực, xử lý thế nào khi cân nặng âm. Mỗi quyết định được chọn theo kiểu phổ biến nhất trong dữ liệu huấn luyện, không phải theo kiểu của dự án bạn.
Kết quả là đoạn mã chạy được, trông gọn gàng, nhưng không khớp với phần còn lại của hệ thống. Bạn mất thêm hai ba lượt hỏi đi hỏi lại để sửa từng giả định, và đến lượt thứ tư thì cuộc trò chuyện đã dài tới mức trợ lý bắt đầu quên điều bạn dặn ở đầu. Vì vậy thời gian bỏ ra viết yêu cầu kỹ hơn một phút thường tiết kiệm được mười phút sửa sau.
Một điểm hay bị bỏ qua: trợ lý không thấy những gì bạn không đưa cho nó. Trợ lý trong trình soạn thảo có thể đọc tệp đang mở và vài tệp liên quan, tác tử có thể tự tìm trong kho mã, nhưng chatbot chung thì chỉ biết đúng những dòng bạn dán vào. Câu "dùng hàm định dạng tiền có sẵn" vô nghĩa nếu bạn chưa dán hàm đó, hoặc chưa nói nó nằm ở tệp nào.
Khung sáu phần cho một yêu cầu lập trình
Bối cảnh. Ngôn ngữ và phiên bản, khung (framework) đang dùng, tệp hoặc hàm liên quan. Ví dụ: dự án PHP 7.4 không dùng Composer, mỗi trang là một tệp, kết nối cơ sở dữ liệu qua biến PDO toàn cục. Một câu như vậy loại bỏ ngay khả năng AI viết cú pháp chỉ có ở PHP 8 hoặc gọi thư viện bạn không cài.
Mục tiêu. Mô tả kết quả, không mô tả cách làm. "Người dùng nhập mã giảm giá, hệ thống trả về số tiền được giảm" rõ hơn "viết hàm xử lý mã giảm giá". Nếu có lý do nghiệp vụ, nói luôn, vì lý do giúp AI chọn đúng khi gặp chỗ mơ hồ.
Ràng buộc. Những thứ không được làm: không thêm thư viện mới, không đổi tên hàm đang được gọi ở nơi khác, giữ tương thích trình duyệt cũ, không sửa ngoài tệp được chỉ định. Ràng buộc là phần người viết hay quên nhất vì với bạn nó hiển nhiên.
Ví dụ vào và ra. Hai đến bốn cặp đầu vào và kết quả mong muốn, trong đó ít nhất một cặp là ca biên: chuỗi rỗng, số không, danh sách trống, ngày cuối tháng. Ví dụ cụ thể truyền ý nhanh hơn ba đoạn mô tả.
Cách trả lời. Bạn muốn nhận toàn bộ tệp hay chỉ phần thay đổi, có cần giải thích không, có cần kèm kiểm thử không. Nếu muốn dán thẳng vào dự án, hãy nói rõ là chỉ trả mã, chú thích bằng tiếng Việt, không lời dẫn.
Tiêu chí xong. Một câu nói rõ khi nào việc được coi là hoàn thành: cả bốn ví dụ cho đúng kết quả, không có cảnh báo khi chạy, hàm cũ vẫn chạy như trước. Tiêu chí này cũng chính là thứ bạn sẽ tự kiểm sau khi nhận mã.
Câu lệnh kém và câu lệnh đã sửa, đặt cạnh nhau
Bảng dưới lấy cùng một việc — tính phí giao hàng cho một cửa hàng nhỏ, ví dụ giả định — và viết theo hai cách. Cột phải dài hơn, nhưng mỗi dòng thêm vào đều cắt đi một lượt hỏi lại.
| Phần | Câu lệnh kém | Câu lệnh đã sửa |
|---|---|---|
| Bối cảnh | Viết hàm tính phí ship. | Dự án Python 3.11, tệp tinh_phi.py, chưa dùng thư viện ngoài nào. |
| Mục tiêu | (không có) | Hàm nhận cân nặng tính bằng gam và cờ nội thành, trả về phí giao bằng đồng, số nguyên. |
| Ràng buộc | (không có) | Không dùng số thực cho tiền. Cân nặng âm hoặc bằng không thì ném ValueError có thông báo tiếng Việt. |
| Ví dụ | (không có) | Theo bảng phí giả định: 500 gam nội thành ra 15000; 1200 gam ngoại thành ra 35000; 0 gam ra lỗi. |
| Cách trả lời | (không có) | Chỉ trả mã hàm và ba ca kiểm thử pytest, không giải thích dài. |
| Tiêu chí xong | (không có) | Ba ca kiểm thử đều qua khi chạy trên máy. |
Để ý cột phải không hề nói cách làm: không bảo dùng vòng lặp hay từ điển. Bạn giao kết quả và ranh giới, phần cài đặt để trợ lý tự chọn, rồi bạn đọc lại. Nếu bạn đã có sẵn ý về thuật toán, cứ nói, nhưng đó là tuỳ chọn chứ không phải phần bắt buộc của khung.
Đưa ngữ cảnh vừa đủ: không thiếu, không đổ cả kho mã
Lỗi ngược với thiếu ngữ cảnh là dán quá nhiều. Người mới dùng hay dán nguyên năm tệp, mỗi tệp vài trăm dòng, rồi hỏi một câu về một hàm. Trợ lý phải đọc tất cả, độ chú ý bị chia mỏng, và câu trả lời hay vướng vào những chi tiết không liên quan. Ngoài ra cửa sổ ngữ cảnh có giới hạn; cuộc trò chuyện dài thêm vài lượt là phần đầu bắt đầu bị cắt hoặc bị xem nhẹ.
Quy tắc thực dụng là đưa đúng ba thứ: đoạn mã cần sửa, chữ ký của các hàm mà đoạn đó gọi tới (không cần thân hàm), và cấu trúc dữ liệu nó nhận vào. Với cơ sở dữ liệu, đưa câu tạo bảng hoặc danh sách cột thay vì cả tệp sao lưu. Với giao diện, đưa đoạn HTML của khối liên quan chứ không phải cả trang.
Trước khi dán, lướt qua một lượt để xoá khoá API, mật khẩu, chuỗi kết nối, địa chỉ máy chủ nội bộ và dữ liệu thật của khách. Thay bằng giá trị giả như KHOA_MAU hay khach_a. Nếu công ty bạn có quy định về việc đưa mã nguồn vào công cụ bên ngoài, quy định đó đứng trên mọi lời khuyên trong bài này.
Những câu nên có sẵn để dán đầu mọi yêu cầu
Nhiều lập trình viên giữ một đoạn mở đầu cố định cho từng dự án, dán lên đầu mỗi cuộc trò chuyện mới. Trợ lý trong trình soạn thảo và tác tử thường cho phép lưu đoạn này thành tệp hướng dẫn dự án; cách đặt tệp đó nằm ở danh mục chọn và cài công cụ. Nội dung thường gồm:
- Ngôn ngữ, phiên bản và khung đang dùng, kèm những thứ không có trên máy chủ thật, ví dụ không có tiện ích mở rộng nào đó.
- Quy ước đặt tên: tiếng Việt không dấu hay tiếng Anh, kiểu chữ thường có gạch dưới hay viết hoa chữ đầu.
- Cách xử lý lỗi chuẩn của dự án: ném ngoại lệ, trả mã lỗi hay ghi log rồi trả giá trị rỗng.
- Những thư viện được dùng và những thư viện bị cấm thêm.
- Yêu cầu chung về câu trả lời: chú thích bằng tiếng Việt, mỗi thay đổi kèm một câu giải thích lý do, không tự ý sửa ngoài phạm vi được giao.
- Một câu nhắc: nếu yêu cầu chưa rõ, hãy hỏi lại trước khi viết mã.
Đoạn mở đầu này nên ngắn, mười dòng là nhiều. Nó không thay cho phần mô tả việc cụ thể; nó chỉ giúp bạn khỏi gõ lại những điều đúng cho mọi việc trong cùng dự án.
Khi chính bạn chưa rõ mình muốn gì
Khung sáu phần giả định bạn đã biết kết quả mong muốn. Nhưng nhiều việc bắt đầu ở trạng thái mơ hồ hơn: bạn biết vấn đề, chưa biết nên giải quyết theo hướng nào. Lúc đó đừng ép mình viết đủ sáu phần bằng những giả định chưa nghĩ kỹ, vì trợ lý sẽ làm đúng theo giả định sai và bạn nhận về mã cho một bài toán khác.
Cách hợp lý hơn là tách thành hai cuộc trao đổi. Cuộc đầu chỉ để bàn hướng, không viết mã: "Cửa hàng cần nhắc khách khi đơn hàng chờ thanh toán quá một ngày. Hệ thống hiện có bảng đơn hàng và chạy được tác vụ định kỳ. Hãy nêu hai đến ba hướng làm, ưu nhược điểm từng hướng, những câu cần hỏi chủ cửa hàng trước khi chọn. Chưa viết mã." Đọc xong, bạn chọn một hướng, trả lời các câu hỏi mở, rồi mới viết yêu cầu sáu phần đầy đủ cho cuộc thứ hai.
Tách như vậy tránh được một bẫy quen thuộc: trợ lý đưa ra mã ngay từ câu đầu, mã trông ổn, bạn chấp nhận hướng đó chỉ vì nó đã có sẵn chứ không phải vì nó tốt nhất. Quyết định thiết kế nên do bạn chọn có chủ đích, kể cả khi lựa chọn được gợi ý bởi AI.
Sau khi nhận mã: kiểm theo đúng tiêu chí bạn đã đặt
Khung sáu phần có một lợi ích phụ: phần tiêu chí xong biến thành danh sách kiểm tra. Trình tự nên làm mỗi lần nhận mã:
- Đọc lướt toàn bộ để chắc trợ lý không sửa ngoài phạm vi, không thêm thư viện lạ, không đổi tên hàm cũ.
- Tìm các tên hàm, phương thức, tham số mà bạn chưa từng thấy; tra tài liệu chính thức để chắc chúng tồn tại ở đúng phiên bản bạn dùng.
- Chạy các ví dụ vào ra đã đưa trong yêu cầu; nếu có kiểm thử kèm theo, chạy thật trên máy chứ không tin câu "đã kiểm tra".
- Thử thêm một ca biên mà bạn chưa đưa, để xem trợ lý có xử lý tổng quát hay chỉ khớp đúng ví dụ.
- Nếu có chỗ sai, trả lời bằng kết quả cụ thể: đầu vào nào, kết quả mong muốn là gì, kết quả thực tế là gì. Tránh chỉ nói "vẫn sai".
Mã do AI viết vẫn là mã bạn chịu trách nhiệm khi đưa lên môi trường thật. Khung viết yêu cầu tốt làm giảm số lần sửa, nhưng không bỏ được bước đọc và chạy thử.
Câu hỏi thường gặp
Có cần viết đủ sáu phần cho cả những việc rất nhỏ không?
Không. Việc nhỏ như đổi tên biến hay thêm một dòng log thì một câu là đủ. Khung sáu phần đáng dùng khi việc có từ hai quyết định thiết kế trở lên, hoặc khi kết quả sẽ được đưa vào mã chạy thật. Với việc vừa, ít nhất hãy giữ phần ràng buộc và ví dụ vào ra.
Nên viết yêu cầu dài một đoạn hay chia gạch đầu dòng?
Gạch đầu dòng theo sáu phần dễ đọc hơn cho cả bạn lẫn trợ lý, và dễ sửa khi muốn hỏi lại. Đoạn văn liền phù hợp khi bạn kể bối cảnh nghiệp vụ dài. Điều quan trọng là mỗi ràng buộc nằm trên một dòng riêng để không bị lẫn.
Đóng vai cho AI, kiểu bảo nó là lập trình viên lâu năm, có giúp gì không?
Câu đóng vai đôi khi đổi giọng văn và mức chi tiết của lời giải thích, nhưng không thay được bối cảnh cụ thể. Một dòng nói rõ phiên bản ngôn ngữ và quy ước dự án có ích hơn nhiều so với một câu tán dương năng lực. Nếu dùng, đặt nó sau phần bối cảnh.
Trợ lý trong trình soạn thảo đã đọc được mã, vẫn cần mô tả bối cảnh à?
Vẫn cần, nhưng ngắn hơn. Trợ lý đọc được tệp không có nghĩa là nó biết tệp nào quan trọng, quy ước nào là bắt buộc, hay máy chủ thật chạy phiên bản nào. Chỉ đích danh tệp và hàm liên quan giúp nó không phải đoán phạm vi.
Khi AI trả lời sai, nên sửa trong cùng cuộc trò chuyện hay mở cuộc mới?
Sai một hai chỗ nhỏ thì sửa tiếp trong cùng cuộc. Nếu đã qua bốn năm lượt mà vẫn vòng vo, hãy mở cuộc mới, dán yêu cầu đã chỉnh lại cho đầy đủ cùng đoạn mã tốt nhất đang có. Cuộc trò chuyện dài chứa nhiều phiên bản sai làm trợ lý dễ lặp lại lỗi cũ.
Có nên lưu lại các yêu cầu viết tốt để dùng lại không?
Nên. Một tệp ghi chú chung của nhóm, chia theo loại việc như viết hàm, viết truy vấn, viết tài liệu, giúp người mới khỏi bắt đầu từ trang trắng. Định kỳ xem lại vì công cụ và quy ước dự án thay đổi, mẫu cũ có thể không còn hợp.