Chúng tôi đã ra mắt chế độ mục tiêu (hay /goal) như một cách để giúp bạn có thể hướng Codex đạt được một kết quả cụ thể. Khi bạn đặt một mục tiêu, Codex sẽ tiếp tục làm việc cho đến khi mục tiêu đạt được, dù việc đó mất vài giờ hay vài ngày. Một số người đã dùng Codex để làm việc với một mục tiêu duy nhất trong hơn 120 giờ.
Chế độ mục tiêu cực kỳ mạnh mẽ và có một số điều bạn có thể làm để tận dụng tối đa nó. Dưới đây là 7 điều cần ghi nhớ khi bạn sử dụng /goal.
1. Tiêu chí *có thể kiểm chứng* rõ ràng
Yêu cầu bạn đặt ra khi kích hoạt chế độ mục tiêu có thể đóng vai trò là yêu cầu ban đầu, nhưng quan trọng hơn, nó sẽ là tiêu chí hoàn thành mục tiêu. Codex sẽ kiểm tra sau mỗi lượt xem mục tiêu đã đạt được hay chưa. Do đó, yêu cầu mục tiêu của bạn không nên quá dài và tập trung vào một tiêu chí rõ ràng về thời điểm mục tiêu được hoàn thành.
Trong hầu hết các trường hợp, một mục tiêu tốt có chứa một con số rõ ràng\* để mô hình đạt được trước khi mục tiêu được coi là hoàn thành. Ví dụ tốt:
- "Giảm thời gian build và triển khai xuống 30%."
- "Di chuyển tính năng này từ TypeScript sang Rust và đạt 100% tương đương về kiểm thử."
- "Cải thiện khung ứng dụng để đạt được largest contentful paint (LCP) trong môi trường production dưới 2,5 giây."
\Yêu cầu không nhất thiết phải là một con số, nhưng nhìn chung nó sẽ hữu ích cho các mẹo sau.*
Nếu bạn không chắc chắn cách xác định mục tiêu tốt nhất hoặc muốn làm việc với Codex trước để lên ý tưởng cho dự án, bạn không cần phải bắt đầu một luồng với chế độ mục tiêu.
Codex có thể tự đặt mục tiêu, vì vậy bạn có thể bắt đầu một cuộc trò chuyện và khi bạn sẵn sàng để Codex bắt đầu công việc, bạn có thể yêu cầu Codex đặt mục tiêu dựa trên cuộc trò chuyện của bạn.
Bạn cũng có thể chỉnh sửa mục tiêu bất cứ lúc nào bằng cách nhấn nút chỉnh sửa trong ứng dụng Codex hoặc sử dụng /goal lại trong CLI.
2. Cung cấp hướng dẫn nếu có thể
Gửi một yêu cầu như "Giảm thời gian build và triển khai xuống 30%" có thể thú vị và thậm chí tìm ra một số giải pháp sáng tạo. Nhưng nó cũng có thể khiến Codex đi lạc nếu bạn có một ý tưởng về nơi vấn đề có thể nằm.
Khi có thể, hãy cho Codex một điểm khởi đầu để bắt đầu làm việc, những công cụ nó có thể sử dụng để đạt được mục tiêu, hoặc bất kỳ chỉ dẫn nào khác để tránh Codex đi sai hướng.
Đồng nghiệp của tôi @reach_vb chẳng hạn, đã làm điều này trong một thí nghiệm của anh ấy bằng cách nói với Codex rằng nó có thể sử dụng trình duyệt Chrome để vào Google Colab và các giới hạn chấp nhận được như tự tạo tập dữ liệu khi anh ấy yêu cầu Codex huấn luyện một mô hình.
Tương tự, nếu bạn muốn giảm thời gian build và bạn biết đa phần thời gian được dùng vào đâu, hãy cố gắng chỉ cho Codex hướng đến khu vực đó trước trong yêu cầu của bạn.
Ngoài ra, bạn thậm chí có thể yêu cầu Codex thực hiện một số nghiên cứu ban đầu trong chế độ kế hoạch và để Codex tạo một kế hoạch dưới dạng tệp mà nó có thể sử dụng để ghi lại các phương án khả thi. Sau đó, yêu cầu mục tiêu của bạn tham chiếu đến kế hoạch đó.
3. Làm cho tiến trình có thể đo lường được
Nếu mục tiêu của bạn có tham vọng hoặc có nhiều cách Codex có thể tiến gần hơn đến mục tiêu, điều quan trọng là bạn cung cấp cho Codex các công cụ để đo lường tiến trình.
Trong trường hợp của một số tác vụ, điều này có thể đã được cho sẵn, như cải thiện thời gian build hoặc tăng độ phủ kiểm thử, vì Codex thường đã có sẵn các công cụ hoặc tự tạo ra chúng.
Đối với các mục tiêu khác, bạn nên cùng Codex suy nghĩ về những công cụ nào sẽ hữu ích hoặc gợi ý cho nó cách để biết nó đang tiến triển như thế nào. Ví dụ, có các công cụ để tính toán sự khác biệt hình ảnh giữa hai ảnh chụp màn hình hoặc tạo một bộ đánh giá cho một agent mà bạn đang cố gắng tinh chỉnh.
Khi tôi yêu cầu Codex tái tạo lại một số thành phần từ một video, tôi đã yêu cầu Codex tạo một công cụ cho chính nó để có thể so sánh ảnh chụp màn hình và kiểm tra sự khác biệt. Nó đã chọn phát triển công cụ theo thời gian để có các chế độ so sánh khác nhau.
Một ảnh chụp màn hình Codex tạo ra để so sánh trực quan hai khung hình
Tùy thuộc vào tác vụ của bạn, bạn cũng nên cân nhắc xem có thêm tiêu chí nào cần đo lường/kiểm tra có thể khiến Codex nghĩ rằng tác vụ đã hoàn thành nhưng bạn lại cho là chưa hoàn thành hay không. Ví dụ, triển khai giao diện người dùng bằng cách cắt ghép cảm hứng thiết kế và nhúng nó để trở nên “hoàn hảo đến từng pixel” hoặc đạt tỷ lệ kiểm thử đạt 100% bằng cách giảm độ phủ kiểm thử.
4. Tạo một môi trường thực tế
Để Codex thực sự tiến triển hướng tới mục tiêu, nó cần hoạt động trong một môi trường thực tế. Trong thực tế, điều đó có nghĩa là nếu bạn đang cố gắng cải thiện thời gian triển khai hoặc các vấn đề về độ trễ, nó cần có quyền truy cập vào các môi trường triển khai và kiểm thử mô phỏng production. Cùng một stack, cùng các cờ, một cơ sở dữ liệu tương tự.
Ví dụ, chúng tôi đã gỡ lỗi một số cải tiến về thời gian build và triển khai cho developers.openai.com. Chúng tôi đã sử dụng các bản xem trước triển khai, vì vậy Codex có thể sử dụng chúng để triển khai và xem xét các nhật ký liên quan, nhưng các bản triển khai xem trước của chúng tôi đã vô hiệu hóa một số đường dẫn build so với các lần chạy production đầy đủ. Vì vậy, thay vào đó, Codex phải thực hiện các triển khai thủ công đến cùng một môi trường với các cấu hình production tương tự để kiểm tra môi trường.
Tương tự, bạn có thể yêu cầu Codex sử dụng computer use để kiểm tra ứng dụng thực tế. Để cải thiện hiệu suất trên iOS, @dimillian thậm chí còn sử dụng một thiết bị vật lý để có môi trường chính xác nhất.
5. Cẩn thận với các mục tiêu trực quan
Đưa cho Codex một mục tiêu trực quan như "Triển khai giao diện người dùng này hoàn hảo 100% pixel dựa trên hình ảnh này" là điều hấp dẫn, nhưng tùy thuộc vào thiết lập, nó có thể gây ra một số rắc rối.
Nếu bạn không đưa ra hướng dẫn và ràng buộc phù hợp, nó có thể sa lầy vào một số vấn đề, bỏ qua mục tiêu tổng thể. Ví dụ, nếu tài liệu tham khảo bao gồm đồ họa mà Codex được kỳ vọng sẽ tạo ra, dù là biểu tượng SVG hay hình ảnh, nó có thể bị lạc vào việc làm cho chúng chính xác thay vì phân tích vấn đề một cách thích hợp.
Ngoài ra, Codex sẽ cần các công cụ để thực hiện so sánh trực quan một cách chính xác, điều này có nghĩa là nhiều đầu vào hình ảnh hơn và tổng lượng token sử dụng cao hơn mà không nhất thiết mang lại cho Codex một cách dễ dàng để xác định cơ hội.
Thay vào đó, hình ảnh thường có thể đóng vai trò là ngữ cảnh hữu ích để hướng tới mục tiêu, nhưng bạn nên tìm cách khác để Codex xác định rằng mục tiêu đã đạt được, chẳng hạn như danh sách kiểm tra tính năng, thông số kỹ thuật để triển khai, tuân thủ hệ thống thiết kế, v.v.
6. Theo dõi tiến trình
Nếu Codex làm việc trong nhiều giờ hoặc nhiều ngày ở chế độ nền (hoặc thậm chí trên một máy khác), bạn rất dễ mất dấu Codex đã đi được bao xa hoặc công việc gì đã được thực hiện. Có một số điều tôi thấy hữu ích tùy thuộc vào mục tiêu để theo kịp nó:
- Yêu cầu Codex commit tại các bước có ý nghĩa và push lên một Draft PR. Điều này đặc biệt hữu ích nếu bạn làm việc trên một trang web có bản xem trước triển khai.
- Yêu cầu Codex cập nhật một artifact cho lãnh đạo. Đây có thể là một tệp HTML mà bạn có thể mở trong trình duyệt trong ứng dụng hoặc thậm chí triển khai cho nhóm của bạn bằng Sites, một hình ảnh của biểu đồ kết xuất theo dõi tiến trình hoặc thậm chí một tệp markdown đơn giản.
- Hướng dẫn Codex đăng cập nhật. Bạn cũng có thể yêu cầu Codex như một phần của mục tiêu để thông báo tiến độ lớn trở lại một kênh Slack hoặc những nơi khác mà bạn muốn tiến trình được ghi lại.
- Sử dụng các cuộc trò chuyện khác để yêu cầu cập nhật trạng thái. Nếu bạn chỉ muốn kiểm tra nhanh trạng thái hiện tại, bạn có thể chạy /side để tạo một cuộc trò chuyện phụ mới và đặt câu hỏi ở đó. Vì nó fork luồng hiện tại, nó có tất cả ngữ cảnh cho đến thời điểm này nhưng cũng tồn tại trong thời gian ngắn. Giải pháp thay thế trong ứng dụng Codex là yêu cầu Codex trong một cuộc trò chuyện mới thông thường đọc luồng mục tiêu khác và trả lời câu hỏi của bạn. Điều này có thể đặc biệt mạnh mẽ nếu bạn yêu cầu Codex lên lịch một tự động hóa để kiểm tra thường xuyên.
7. Dọn dẹp và hoàn thiện kết quả
Tuyệt vời, cuối cùng mục tiêu đã đạt được! Đã đến lúc chỉ $yeet nó cho nhóm và kết thúc ngày làm việc?
Nhìn chung, tôi thấy hữu ích, đặc biệt là đối với các tác vụ tối ưu hóa, khi yêu cầu Codex suy ngẫm về công việc đã làm và xem xét lại nó. Bạn có thể bắt đầu bằng /review để chạy đánh giá mã nguồn cục bộ nhưng cũng có thể yêu cầu Codex suy ngẫm sâu hơn về các cách tiếp cận khác nhau mà nó đã thử để giải quyết mục tiêu và dọn dẹp cho phù hợp.
Vì Codex sẽ tiếp tục cho đến khi đạt được mục tiêu, nó có thể đã thử một số điều không hiệu quả hoặc hoàn toàn không hiệu quả và có thể còn sót lại trong các thay đổi.
Đã đến lúc đặt mục tiêu cho tác vụ tiếp theo của bạn
Chức năng mục tiêu trong Codex là một công cụ cực kỳ mạnh mẽ để giải quyết một số thách thức có ý nghĩa nhất mà bạn gặp phải, nhưng việc cung cấp môi trường và hướng dẫn phù hợp sẽ giúp bạn đạt được mục tiêu hiệu quả hơn.
Bạn đã sử dụng /goal cho việc gì?
https://x.com/OpenAIDevs/status/2057530209470210453
