Một yêu cầu như “làm giao diện đẹp hơn” khiến Codex phải tự đoán cả mục tiêu lẫn gu thẩm mỹ. Có thể nó sửa nhiều component, thay màu toàn trang và thêm thư viện mới, trong khi điều bạn muốn chỉ là làm nút chính dễ thấy hơn. Tôi thấy chất lượng làm việc với tác nhân tăng rõ rệt khi mình mô tả hành vi cần có và giới hạn thay đổi, thay vì chỉ dùng vài từ chung chung.
Viết yêu cầu như một phiếu công việc
Hãy bắt đầu bằng vấn đề người dùng đang gặp. Tiếp theo nói kết quả mong muốn, vị trí hoặc thành phần liên quan, điều cần giữ nguyên và cách nghiệm thu. Chẳng hạn: “Trên trang danh sách sản phẩm, người dùng khó nhận ra bộ lọc đang được bật. Thêm trạng thái hiển thị rõ cho bộ lọc đã chọn. Giữ nguyên dữ liệu, thứ tự trường và hành vi tải danh sách. Không đổi cấu trúc trang. Xong khi có trạng thái mặc định, trạng thái đang bật và trạng thái bàn phím dễ phân biệt.” Mô tả bằng hành vi giúp Codex hiểu mục tiêu tốt hơn các tính từ như ‘xịn’ hay ‘hiện đại’.
Nếu chưa biết tệp nào cần sửa, đừng đoán tên file. Có thể yêu cầu: “Hãy tìm component xử lý bộ lọc, mô tả cách nó hoạt động và hỏi tôi trước khi sửa.” Cách thăm dò này đặc biệt hữu ích ở codebase lạ hoặc dự án lớn. Hãy cho Codex biết công nghệ và lệnh kiểm tra nếu bạn đã biết, đồng thời nói rõ không được thay đổi file nào như cấu hình triển khai hoặc migration dữ liệu.
Đặt tiêu chí kiểm tra dễ làm theo
Một yêu cầu tốt trả lời được câu “tôi sẽ nhìn vào đâu để biết việc này hoàn thành?”. Với lỗi, tiêu chí có thể là bước tái hiện không còn cho lỗi và các hành vi bình thường vẫn hoạt động. Với tính năng, liệt kê vài tình huống: dữ liệu hợp lệ, dữ liệu trống, lỗi mạng hoặc dùng bằng bàn phím. Không phải dự án nào cũng có bộ kiểm thử sẵn, vậy hãy yêu cầu Codex đề xuất cách kiểm tra thủ công và cho biết nó đã chạy lệnh nào.
Prompt mẫu tôi hay sửa lại: “Bối cảnh: [mô tả ngắn]. Vấn đề: [điều đang xảy ra]. Kết quả mong muốn: [hành vi cụ thể]. Giới hạn: [công nghệ, tệp, thiết kế hoặc dữ liệu cần giữ]. Cách xác nhận: [các tình huống]. Trước khi sửa, hãy kiểm tra cấu trúc liên quan và hỏi nếu yêu cầu còn mơ hồ. Sau khi sửa, tóm tắt tệp thay đổi, quyết định chính và việc chưa xác minh.” Đây không phải khuôn cứng; nó giúp bạn nhớ những ý dễ bỏ sót.
Nhìn diff như người duyệt
Sau khi Codex làm xong, xem từng thay đổi có phục vụ đúng yêu cầu không. Một thay đổi nhỏ mà lan qua mười tệp có thể hợp lý, nhưng bạn nên hỏi vì sao. Nếu Codex thêm thư viện, hỏi lợi ích và cách làm không cần thư viện đó. Nếu nó sửa định dạng toàn bộ dự án, yêu cầu chỉ trình bày diff liên quan. Giao tiếp qua phản hồi cụ thể như “hãy giữ lại xử lý dữ liệu, chỉ đổi nhãn và thông báo lỗi” hiệu quả hơn việc bắt đầu lại bằng “làm lại”.
Để học sâu hơn về cách mô tả nhiệm vụ lập trình, xem [Codex Prompting Guide](https://developers.openai.com/cookbook/examples/gpt-5/codex_prompting_guide) và các công thức thực hành trong [Codex Cookbook](https://developers.openai.com/cookbook/topic/codex). Khi dùng, nhớ rằng tài liệu có thể cập nhật theo sản phẩm và mô hình, nên hãy quay lại nguồn chính thức nếu một nút hay tuỳ chọn không còn giống hướng dẫn. Chọn một việc nhỏ trong dự án của bạn, viết yêu cầu theo phiếu công việc, rồi tự xem diff. Kỹ năng giao việc và duyệt kết quả quan trọng ngang với khả năng tạo mã.
