Tiêu đề gốc: Hướng dẫn về /goal
Tác giả gốc: @dkundel, thành viên Quan hệ nhà phát triển OpenAI
Biên soạn bởi: Peggy

Lưu ý của biên tập viên: Bài viết này đến từ Dominik Kundel, thành viên Quan hệ nhà phát triển OpenAI, tóm tắt trải nghiệm sử dụng chức năng "chế độ mục tiêu / / mục tiêu" của Codex. Những gì nó thảo luận không phải là một kỹ thuật nhắc thông thường mà là một sự thay đổi vai trò đang diễn ra trong các công cụ lập trình AI: Codex không còn chỉ là một trợ lý mã đáp ứng một vòng hướng dẫn duy nhất mà đã bắt đầu trở thành một tác nhân thực thi có thể liên tục tiến lên xung quanh các mục tiêu rõ ràng.

Trong chế độ /mục tiêu, điều thực sự quan trọng không phải là viết các yêu cầu dài và chi tiết nhất có thể mà là đặt ra các tiêu chí thoát rõ ràng và có thể kiểm chứng được cho Codex. Ví dụ: "thời gian triển khai giảm 30%", "phạm vi kiểm tra đạt mức chẵn lẻ 100%" và "LCP giảm xuống dưới 2,5 giây". Các chỉ số này cho phép Codex xác định xem nhiệm vụ đã được hoàn thành hay chưa và ngăn chặn việc thử và sai liên tục với các mục tiêu mơ hồ. Đồng thời, người dùng cũng cần cung cấp đầy đủ chỉ dẫn, công cụ và môi trường thực tế để Codex có thể đo lường tiến độ và xác minh kết quả, thay vì chỉ hoàn thành một giải pháp có vẻ khả thi tại địa phương hoặc trong các điều kiện giả định.

Bài viết đặc biệt nhắc nhở rằng các tác vụ trực quan là tác vụ dễ khiến Codex sa lầy vào chi tiết nhất. Thay vì yêu cầu "khôi phục 100% mức pixel", tốt hơn là bạn nên chia nhỏ các mục tiêu trực quan thành danh sách tính năng, thông số kỹ thuật của hệ thống thiết kế và các số liệu có thể đánh giá được. Đối với các nhiệm vụ dài hạn kéo dài hàng giờ hoặc thậm chí nhiều ngày, cũng cần phải liên tục theo dõi các cam kết, dự thảo PR, tài liệu tiến độ, cập nhật Slack hoặc trò chuyện bên lề để tránh kết thúc với một loạt thay đổi không thể theo dõi.

Thông tin bổ sung của bài viết này là nó định nghĩa lại /goal như một "cơ chế quản lý nhiệm vụ dài hạn". Khi AI có thể được thực thi liên tục trong hàng chục, thậm chí hàng trăm giờ, khả năng cốt lõi của nhà phát triển cũng thay đổi: không chỉ để AI tạo mã mà còn xác định mục tiêu cho nó, thiết lập hệ thống đo lường, định cấu hình môi trường thực thi và hoàn thành việc xem xét, đánh giá ở giai đoạn cuối. Nói cách khác, lập trình AI đang chuyển từ “viết lời nhắc” sang “quản lý người thực thi dự án làm việc liên tục”.

Sau đây là văn bản gốc:

Chúng tôi đã ra mắt chế độ mục tiêu (hoặc /mục tiêu) để giúp bạn tiếp tục Codex hướng tới một kết quả cụ thể. Khi bạn đặt mục tiêu, Codex sẽ hoạt động cho đến khi đạt được mục tiêu—dù việc đó mất hàng giờ hay hàng ngày. Có người đã để Codex làm việc liên tục hơn 120 giờ cho cùng một mục tiêu.

Chế độ mục tiêu rất cao mạnh mẽ. Để tận dụng tối đa tính năng này, dưới đây là 7 điều cần lưu ý khi sử dụng /goal.

Đặt tiêu chí rõ ràng, có thể kiểm chứng

Từ nhắc bạn nhập khi kích hoạt chế độ mục tiêu đóng vai trò vừa là lời nhắc ban đầu vừa đóng vai trò là tiêu chí hoàn thành cho mục tiêu đó. Codex sẽ kiểm tra sau mỗi vòng làm việc: mục tiêu này đã được hoàn thành chưa.

Vì vậy, lời nhắc mục tiêu của bạn không nên quá dài mà nên tập trung vào một tiêu chuẩn rõ ràng: trong hoàn cảnh nào thì mục tiêu đó sẽ được coi là đã đạt được.

Trong hầu hết các trường hợp, mục tiêu tốt nhất là bao gồm một chỉ số bằng số rõ ràng cho mô hình để đánh giá xem nó đã được hoàn thành hay chưa. Ví dụ:

"Giảm 30% thời gian xây dựng và triển khai."

"Chuyển tính năng này từ TypeScript sang Rust và đạt được độ nhất quán kiểm tra 100%."

"Tối ưu hóa khung ứng dụng để Thời gian hiển thị nội dung lớn nhất (thước đo tốc độ tải nội dung chính của trang) trong quá trình sản xuất nhỏ hơn 2,5 giây."

Mẹo này không phải lúc nào cũng phải bao gồm một con số, nhưng nhìn chung, các con số giúp việc này trở nên dễ dàng hơn để tiến về phía trước.

Nếu bạn không chắc chắn về cách xác định mục tiêu của mình hoặc muốn lên ý tưởng cho dự án bằng Codex trước, bạn không cần phải bắt đầu cuộc trò chuyện với chế độ mục tiêu.

Codex có thể đặt ra mục tiêu riêng của mình. Bạn có thể bắt đầu cuộc trò chuyện một cách bình thường và khi bạn đã sẵn sàng để Codex bắt đầu thực thi, hãy để Codex đặt mục tiêu dựa trên cuộc thảo luận trước đó.

Bạn cũng có thể chỉnh sửa mục tiêu bất kỳ lúc nào: nhấp vào nút chỉnh sửa trong ứng dụng Codex hoặc sử dụng lại /goal trong CLI.

Cung cấp hướng dẫn nếu có thể

Các mẹo như "Giảm 30% thời gian xây dựng và triển khai" nghe có vẻ hay và có thể giúp Codex tìm ra một số giải pháp sáng tạo. Nhưng nếu bạn đã có ý tưởng sơ bộ về vấn đề có thể xảy ra ở đâu thì loại gợi ý này cũng có thể khiến Codex phải đi đường vòng.

Vì vậy, nếu có thể, tốt nhất bạn nên cho Codex biết nên bắt đầu khắc phục sự cố từ đâu, công cụ nào có thể sử dụng để hoàn thành mục tiêu hoặc đưa ra các gợi ý khác để ngăn không cho nó đi sai hướng.

Ví dụ: đồng nghiệp @reach_vb của tôi đã làm điều này trong một thử nghiệm: anh ấy nói với Codex rằng anh ấy có thể sử dụng trình duyệt Chrome để vào Google Colab và giải thích một số ràng buộc có thể chấp nhận được, chẳng hạn như cho phép Codex tự tạo tập dữ liệu khi đào tạo mô hình.

Tương tự, nếu bạn muốn rút ngắn thời gian xây dựng và đã biết phần lớn thời gian được sử dụng ở đâu, tốt nhất là trỏ Codex đến khu vực đó trong từ nhắc nhở.

Ngoài ra, bạn có thể yêu cầu Codex thực hiện một số nghiên cứu sơ bộ ở chế độ kế hoạch và yêu cầu Codex tạo một tệp kế hoạch để ghi lại các giải pháp tiềm năng. Sau đó, yêu cầu mục tiêu của bạn tham khảo kế hoạch này.

Đo lường tiến độ

Nếu mục tiêu của bạn đầy tham vọng hoặc nếu Codex có nhiều cách để dần dần tiến gần hơn đến mục tiêu thì điều quan trọng là bạn phải cung cấp cho Codex các công cụ để đo lường tiến độ.

Đối với một số nhiệm vụ, điều này có thể đúng. Những việc như tối ưu hóa thời gian xây dựng và cải thiện phạm vi kiểm tra, bởi vì Codex thường có sẵn các công cụ hoặc tạo chúng một cách tự nhiên.

Nhưng đối với các mục tiêu khác, tốt nhất bạn nên suy nghĩ bằng Codex trước: Công cụ nào sẽ giúp đánh giá tiến độ? Hoặc cung cấp cho nó một số gợi ý để nó biết cách xác nhận xem nó có đang tiếp cận mục tiêu hay không. Ví dụ: tạo công cụ so sánh sự khác biệt trực quan cho hai ảnh chụp màn hình hoặc tạo bộ đánh giá cho tác nhân bạn đang gỡ lỗi.

Có lần tôi yêu cầu Codex phân nhánh một số thành phần dựa trên một video và lúc đó Codex đã tự tạo một công cụ để so sánh ảnh chụp màn hình và kiểm tra sự khác biệt. Sau đó, nó tiếp tục lặp lại công cụ này và thêm các chế độ so sánh sự khác biệt khác nhau.

Hình ảnh: Ảnh chụp màn hình được tạo bởi Codex để so sánh trực quan hai khung hình.

Tùy thuộc vào nhiệm vụ, bạn cũng có thể cần xem xét liệu có bất kỳ tiêu chí bổ sung nào cần được đo lường hoặc kiểm tra hay không. Nếu không, Codex có thể cho rằng nhiệm vụ đã hoàn thành nhưng đối với bạn thì nó có vẻ chưa hoàn thành.

Ví dụ: Codex có thể cắt trực tiếp hình ảnh tham chiếu thiết kế và nhúng nó vào trang để "khôi phục cấp độ pixel" một giao diện người dùng nhất định; hoặc để đạt được tỷ lệ vượt qua bài kiểm tra là 100%, điều đó có thể làm giảm phạm vi kiểm tra. Không ai trong số này thực sự là cách bạn muốn nó được thực hiện.

Tạo một môi trường thực tế

Nếu bạn muốn Codex thực sự đạt được tiến bộ hiệu quả hướng tới mục tiêu của mình thì nó cần phải chạy trong một môi trường đủ thực tế.

Trong thực tế, điều này có nghĩa là: Nếu bạn muốn tối ưu hóa các vấn đề về thời gian triển khai hoặc độ trễ, Codex phải có quyền truy cập vào môi trường triển khai và thử nghiệm mô phỏng quá trình sản xuất nhiều nhất có thể. Tức là sử dụng cùng một ngăn xếp công nghệ, cùng các bộ chuyển mạch cấu hình và cơ sở dữ liệu tương tự.

Ví dụ: chúng tôi đang gỡ lỗi tối ưu hóa thời gian xây dựng và triển khai chodevelopers.openai.com. Vào thời điểm đó, chúng tôi đã sử dụng các bản xem trước triển khai nên Codex có thể sử dụng các môi trường xem trước này để triển khai và xem các nhật ký liên quan. Vấn đề là việc triển khai bản xem trước của chúng tôi có một số đường dẫn xây dựng bị vô hiệu hóa so với môi trường sản xuất đầy đủ.

Kết quả là Codex đã phải thực hiện triển khai thủ công để triển khai mã đến môi trường gần với cấu hình sản xuất hơn nhằm kiểm tra thực sự sự cố.

Tương tự, bạn cũng có thể cho Codex sử dụng máy tính (khả năng để mô hình vận hành giao diện ứng dụng thực) để kiểm tra ứng dụng thực tế. Để tối ưu hóa một số vấn đề về hiệu suất trên iOS, @dimillian thậm chí còn sử dụng các thiết bị vật lý để có được môi trường thử nghiệm chính xác nhất.

Đặt mục tiêu trực quan cẩn thận

Thật sự rất hấp dẫn khi đặt cho Codex một mục tiêu trực quan, chẳng hạn như "khôi phục 100% cấp độ pixel của giao diện người dùng này dựa trên hình ảnh này". Nhưng tùy thuộc vào thiết lập cụ thể, điều này cũng có thể gây rắc rối.

Nếu bạn không đưa ra hướng dẫn và ràng buộc phù hợp, Codex có thể sa lầy vào một số chi tiết nhất định và bỏ qua mục tiêu chung. Ví dụ: nếu hình ảnh tham chiếu chứa một số thành phần đồ họa và bạn mong đợi Codex tạo ra các thành phần này - cho dù đó là biểu tượng SVG hay hình ảnh - nó có thể tốn nhiều công sức vào "cách tái tạo chính xác các tài liệu này" thay vì phân tích chính xác toàn bộ vấn đề.

Ngoài ra, Codex yêu cầu 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à có nhiều đầu vào hình ảnh hơn và mức tiêu thụ mã thông báo tổng thể cao hơn, nhưng nó không nhất thiết cung cấp cho Codex một cách dễ dàng để xác định các cơ hội cải tiến thực sự có giá trị.

Do đó, hình ảnh thường phù hợp làm bối cảnh mục tiêu hơn là tiêu chí hoàn thiện duy nhất. Bạn nên tìm những cách khác để Codex xác định xem mục tiêu có đạt được hay không, chẳng hạn như danh sách tính năng, thông số kỹ thuật triển khai, tuân thủ hệ thống thiết kế, v.v.

Theo dõi tiến trình

Nếu Codex ngừng hoạt động ở chế độ nền trong nhiều giờ, thậm chí nhiều ngày hoặc thậm chí chạy trên một máy khác, bạn rất dễ quên chính xác tiến trình của nó và công việc đã được thực hiện.

Tùy thuộc vào các mục tiêu khác nhau, tôi thấy các phương pháp sau hữu ích:

·Yêu cầu Codex gửi mã tại các nút chính và đẩy mã đó tới bản PR dự thảo. Điều này đặc biệt hữu ích khi bạn đang làm việc trên một trang web và triển khai bản xem trước.

·Yêu cầu Codex cập nhật sản phẩm gửi cho ban quản lý. Nó có thể là một tệp HTML mà bạn luôn có thể mở trong trình duyệt trong ứng dụng; nó cũng có thể là một trang được triển khai để nhóm xem qua Sites; nó có thể là biểu đồ tiến trình được hiển thị hoặc chỉ là một tệp Markdown thông thường.

Hướng dẫn Codex chủ động xuất bản các bản cập nhật tiến độ. Bạn cũng có thể ghi điều này vào mục tiêu của mình: yêu cầu Codex gửi thông tin cập nhật tới kênh Slack khi đạt được tiến bộ quan trọng hoặc bất kỳ nơi nào khác mà bạn muốn ghi lại tiến trình.

Sử dụng cửa sổ trò chuyện khác để hỏi về trạng thái. Nếu bạn chỉ muốn có cái nhìn tổng quan nhanh về trạng thái hiện tại, bạn có thể chạy /side để bắt đầu một cuộc trò chuyện bên lề mới và đặt câu hỏi ở đó. Bởi vì nó sẽ phân nhánh từ thread hiện tại nên nó có đầy đủ ngữ cảnh cho đến thời điểm hiện tại, nhưng vòng đời của nó lại ngắn.

Một cách khác trong ứng dụng Codex là bắt đầu một cuộc trò chuyện mới thông thường và yêu cầu Codex đọc một chuỗi mục tiêu khác và trả lời các câu hỏi của bạn. Điều này đặc biệt hữu ích nếu bạn để Codex thiết lập tác vụ tự động để kiểm tra tiến độ theo định kỳ.

Làm sạch và hoàn thiện kết quả

Tuyệt vời, mục tiêu cuối cùng đã hoàn thành! Chúng ta có thể bàn giao kết quả cho nhóm ngay bây giờ và kết thúc một ngày được không?

Thông thường, đặc biệt là trong các nhiệm vụ thuộc loại tối ưu hóa, tôi thấy việc Codex quay lại và xem lại công việc tôi đã thực hiện sẽ rất hữu ích. Bạn có thể bắt đầu bằng cách chạy đánh giá mã cục bộ với /review, nhưng cũng đáng yêu cầu Codex phản ánh sâu hơn: nó đã cố gắng đạt được mục tiêu bằng những con đường nào? Những nỗ lực nào đã có hiệu quả? Những nỗ lực nào không thành công? Sau đó làm sạch mã cho phù hợp.

Vì Codex hoạt động cho đến khi đạt được mục tiêu nên có thể nó đã thử một số phương pháp không đủ hiệu quả hoặc thậm chí không hoạt động chút nào và những thay đổi còn sót lại này có thể vẫn còn trong mã cuối cùng.

Đặt mục tiêu cho nhiệm vụ tiếp theo của bạn

Tính năng mục tiêu của Codex là một công cụ cực kỳ mạnh mẽ có thể giúp bạn giải quyết một số thách thức kỹ thuật có ý nghĩa nhất. Nhưng chỉ khi bạn cung cấp môi trường và hướng dẫn phù hợp thì nó mới có thể đạt được mục tiêu hiệu quả hơn.

Bạn đã làm gì với /goal?

[Liên kết gốc]