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 của OpenAI
Biên dịch: Peggy
Lời biên tập: Bài viết này đến từ Dominik Kundel, thành viên Quan hệ nhà phát triển của OpenAI, tổng kết kinh nghiệm sử dụng tính năng "goal mode / /goal" của Codex. Nó không chỉ đơn thuần là một mẹo prompt thông thường, mà là một sự thay đổi vai trò đang diễn ra trong công cụ lập trình AI: Codex không còn chỉ là trợ lý mã phản hồi các lệnh đơn lẻ, mà bắt đầu trở thành một Agent thực thi liên tục hướng tới mục tiêu rõ ràng.
Trong chế độ /goal, điều thực sự quan trọng không phải là viết yêu cầu càng dài càng chi tiết, mà là thiết lập cho Codex các tiêu chí thoát rõ ràng và có thể kiểm chứng. Ví dụ như "giảm thời gian triển khai 30%", "độ phủ kiểm thử đạt 100% parity", "LCP giảm xuống dưới 2,5 giây". Những chỉ số này giúp Codex đánh giá liệu nhiệm vụ đã hoàn thành hay chưa, đồng thời tránh việc nó thử nghiệm vô hạn trong các mục tiêu mơ hồ. Đồng thời, người dùng cũng cần cung cấp đủ hướng dẫn, công cụ và môi trường thực tế để Codex có thể đo lường tiến độ, xác minh kết quả, thay vì chỉ hoàn thành một giải pháp có vẻ khả thi trong môi trường cục bộ hoặc giả định.
Bài viết đặc biệt nhấn mạnh rằng, các nhiệm vụ liên quan đến hình ảnh dễ khiến Codex sa lầy vào chi tiết. Thay vì yêu cầu "tái tạo 100% pixel", hãy chia nhỏ mục tiêu hình ảnh thành danh sách chức năng, quy tắc hệ thống thiết kế và các chỉ số đánh giá. Đối với các nhiệm vụ kéo dài hàng giờ hoặc thậm chí hàng ngày, cũng cần theo dõi liên tục thông qua commit, draft PR, tài liệu tiến độ, cập nhật Slack hoặc side chat, để tránh cuối cùng chỉ nhận được một đống thay đổi không thể truy xuất.
Giá trị thông tin của bài viết này nằm ở chỗ, 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ể thực thi liên tục hàng chục hoặc thậm chí hàng trăm giờ, năng lực cốt lõi của nhà phát triển cũng thay đổi theo: không chỉ là để AI tạo mã, mà là xác định mục tiêu cho nó, thiết lập hệ thống đo lường, cấu hình môi trường thực thi, và cuối cùng thực hiện đánh giá và tổng kết. Nói cách khác, lập trình AI đang chuyển từ "viết prompt" sang "quản lý một người thực thi kỹ thuật làm việc liên tục".
Dưới đây là nội dung gốc:
Chúng tôi đã ra mắt chế độ mục tiêu (goal mode, hay /goal), để giúp bạn thúc đẩy Codex liên tục hướng tới một kết quả cụ thể. Khi bạn đặt ra một mục tiêu, Codex sẽ làm việc cho đến khi mục tiêu đạt được—bất kể điều đó mất vài giờ hay vài ngày. Đã có người để Codex làm việc liên tục cho cùng một mục tiêu trong hơn 120 giờ.

Mô hình mục tiêu rất mạnh mẽ. Để tối đa hóa hiệu quả của nó, có 7 điều đáng lưu ý khi sử dụng /goal.
Khi bạn kích hoạt chế độ mục tiêu, prompt nhập vào vừa đóng vai trò là prompt khởi tạo, quan trọng hơn, nó sẽ trở thành tiêu chí thoát của mục tiêu này. Codex sẽ kiểm tra sau mỗi vòng làm việc: liệu mục tiêu này đã hoàn thành hay chưa.
Do đó, prompt mục tiêu của bạn không nên viết quá dài, mà nên tập trung vào một tiêu chí rõ ràng: trong trường hợp nào thì mục tiêu này được coi là đã đạt được.
Trong hầu hết các trường hợp, một mục tiêu tốt nhất nên bao gồm một chỉ số định lượng rõ ràng để mô hình có thể đánh giá xem đã hoàn thành hay chưa. Ví dụ:
“Giảm thời gian xây dựng và triển khai xuống 30%.”
“Di chuyển tính năng này từ TypeScript sang Rust và đạt 100% tính nhất quán trong kiểm thử.”
“Tối ưu hóa khung ứng dụng để Largest Contentful Paint (chỉ số đo tốc độ tải nội dung chính của trang) trong môi trường sản xuất dưới 2,5 giây.”
Prompt này không nhất thiết phải luôn chứa con số, nhưng thông thường, con số sẽ giúp các bước tiếp theo dễ dàng hơn.
Nếu bạn chưa chắc chắn về cách định nghĩa mục tiêu, hoặc muốn cùng Codex động não về dự án trước, bạn không cần phải bắt đầu cuộc trò chuyện bằng chế độ mục tiêu ngay từ đầu.
Codex có thể tự thiết lập mục tiêu. Bạn có thể bắt đầu một cuộc trò chuyện bình thường, và khi bạn sẵn sàng để Codex bắt đầu thực thi, hãy yêu cầu Codex thiết lập mục tiêu dựa trên nội dung thảo luận trước đó.
Bạn cũng có thể chỉnh sửa mục tiêu bất cứ 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.
Những prompt như “Giảm thời gian xây dựng và triển khai xuống 30%” nghe có vẻ hay và có thể khiến Codex tìm ra một số giải pháp sáng tạo. Nhưng nếu bạn đã biết đại khái vấn đề có thể nằm ở đâu, prompt này cũng có thể khiến Codex đi sai hướng.
Vì vậy, trong phạm vi có thể, tốt nhất bạn nên cho Codex biết nên bắt đầu kiểm tra từ đâu, có thể sử dụng công cụ nào để hoàn thành mục tiêu, hoặc đưa ra các gợi ý khác để tránh nó đi vào hướng sai.
Ví dụ, đồng nghiệp của tôi @reach_vb đã làm điều này trong một thí nghiệm: anh ấy bảo Codex có thể sử dụng trình duyệt Chrome để vào Google Colab, đồng thời nêu rõ một số giới hạn có thể chấp nhận, chẳng hạn như khi để Codex huấn luyện mô hình, có thể để nó tự tạo tập dữ liệu.

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 bị tiêu tốn ở khâu nào, tốt nhất nên trong prompt hướng Codex đến khu vực đó trước.
Một cách khác là bạn có thể để Codex thực hiện nghiên cứu sơ bộ ở chế độ lập kế hoạch (plan mode) và yêu cầu nó tạo một tệp kế hoạch để ghi lại các giải pháp tiềm năng. Sau đó, hãy để mục tiêu của bạn tham chiếu đến kế hoạch này.
Nếu mục tiêu của bạn rất tham vọng, hoặc Codex có nhiều cách để từng bước tiến gần đến mục tiêu, thì điều quan trọng là: bạn cần 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ể hiển nhiên. Ví dụ như tối ưu hóa thời gian xây dựng, tăng tỷ lệ phủ kiểm thử, vì Codex thường đã có thể sử dụng các công cụ liên quan hoặc sẽ tự nhiên tạo ra các công cụ này.
Nhưng đối với các mục tiêu khác, tốt nhất bạn nên cùng Codex động não: những công cụ nào giúp đánh giá tiến độ? Hoặc đưa ra cho nó một số gợi ý về cách xác nhận xem nó có đang tiến gần đến mục tiêu hay không. Ví dụ, tạo công cụ so sánh trực quan giữa hai ảnh chụp màn hình, hoặc tạo một bộ đánh giá cho tác nhân (agent) mà bạn đang gỡ lỗi.
Tôi đã từng yêu cầu Codex tái tạo một số thành phần dựa trên một đoạn video, và Codex đã tự tạo cho mình 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ó còn liên tục cải tiến công cụ này, thêm vào các chế độ so sánh khác nhau.

Hình ảnh: Một ảnh chụp màn hình do Codex tạo ra, dùng để so sánh trực quan giữa hai khung hình.
Tùy theo nhiệm vụ, bạn cũng cần cân nhắc xem có tiêu chuẩn 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ể nghĩ rằng nhiệm vụ đã hoàn thành, nhưng theo quan điểm của bạn thì nó vẫn chưa đầy đủ.
Ví dụ, Codex có thể cắt trực tiếp ảnh thiết kế tham khảo và nhúng vào trang để đạt được độ chính xác "từng pixel" của một UI; hoặc để đạt tỷ lệ vượt qua kiểm thử 100%, nó lại cắt giảm phạm vi kiểm thử. Đây không phải là cách hoàn thành mà bạn thực sự mong muốn.
Nếu bạn muốn Codex thực sự đạt được tiến triển hiệu quả hướng tới mục tiêu, nó cần được vận hành 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 thời gian triển khai hoặc vấn đề độ trễ, Codex nên có quyền truy cập vào môi trường triển khai và thử nghiệm, và các môi trường này cần mô phỏng môi trường sản xuất càng sát càng tốt. Tức là sử dụng cùng một stack công nghệ, cùng các công tắc cấu hình, và cơ sở dữ liệu tương tự.
Ví dụ, chúng tôi từng gỡ lỗi quá trình xây dựng và tối ưu hóa thời gian triển khai cho developers.openai.com. Khi đó chúng tôi đã sử dụng bản xem trước triển khai, vì vậy Codex có thể tận dụng các môi trường xem trước này để triển khai và xem các log liên quan. Nhưng vấn đề là, bản triển khai xem trước của chúng tôi so với môi trường sản xuất đầy đủ đã vô hiệu hóa một số đường dẫn xây dựng.
Do đó, Codex cuối cùng phải thực hiện triển khai thủ công, đưa mã lên một môi trường gần với cấu hình sản xuất hơn để thực sự kiểm tra vấn đề.
Tương tự, bạn cũng có thể để Codex sử dụng computer use (khả năng cho phép mô hình thao tác giao diện ứng dụng thực tế) để thử nghiệm ứng dụng thực tế. Để tối ưu hóa một số vấn đề hiệu suất trên iOS, @dimillian thậm chí đã sử dụng thiết bị thật để có được môi trường thử nghiệm chính xác nhất.

Việc đưa cho Codex một mục tiêu trực quan, chẳng hạn như "tái tạo chính xác 100% pixel UI này dựa trên hình ảnh", thực sự rất hấp dẫn. Nhưng tùy thuộc vào cài đặt cụ thể, điều này cũng có thể gây ra 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, bỏ qua mục tiêu tổng thể. Ví dụ, nếu hình ảnh tham chiếu chứa một số yếu tố đồ họa và bạn mong đợi Codex tạo ra các yếu tố này—dù là biểu tượng SVG hay hình ảnh—nó có thể dành quá nhiều nỗ lực vào việc "sao chép chính xác các tài nguyên này" thay vì phân tích đúng vấn đề tổng thể.
Ngoài ra, Codex cần 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, tiêu thụ token tổng thể cao hơn, nhưng không nhất thiết mang lại cho Codex một cách đơn giản để nhận ra các cơ hội cải tiến thực sự có giá trị.
Vì vậy, hình ảnh thường phù hợp hơn như một bối cảnh mục tiêu, chứ không phải là tiêu chí hoàn thành duy nhất. Bạn nên tìm kiếm những cách khác để Codex đánh giá xem mục tiêu đã đạt được hay chưa, chẳng hạn như danh sách tính năng, thông số kỹ thuật triển khai, hoặc tuân thủ hệ thống thiết kế.
Nếu Codex cuối cùng phải làm việc trong nhiều giờ hoặc thậm chí nhiều ngày ở chế độ nền, hoặc chạy trên một máy khác, bạn rất dễ quên mất nó đã tiến triển đến đâu và đã thực hiện những công việc gì.
Tùy theo từng mục tiêu, tôi thấy những cách sau đây rất hữu ích:
· Yêu cầu Codex commit code tại các mốc quan trọng và push lên một bản PR nháp. Điều này đặc biệt hữu ích khi bạn đang làm website và có bản xem trước khi triển khai.
· Yêu cầu Codex cập nhật một bản giao diện dành cho quản lý. Nó có thể là một file HTML mà bạn luôn mở trong trình duyệt ứng dụng; hoặc một trang được triển khai qua Sites để nhóm xem; có thể là một biểu đồ tiến độ được render, hoặc chỉ đơn giản là một file Markdown thông thường.
Hướng dẫn Codex chủ động đăng tải 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: yêu cầu Codex gửi cập nhật lên kênh Slack hoặc bất kỳ nơi nào bạn muốn ghi lại tiến độ khi đạt được những bước tiến quan trọng.
Sử dụng cửa sổ chat khác để hỏi trạng thái. Nếu bạn chỉ muốn nhanh chóng biết trạng thái hiện tại, hãy chạy /side để mở một cuộc trò chuyện bên cạnh mới và đặt câu hỏi ở đó. Vì nó được fork từ luồng hiện tại, nên có toàn bộ ngữ cảnh cho đến thời điểm đó, nhưng vòng đời rất ngắn.
Một phương án thay thế khác trong ứng dụng Codex là: mở một cuộc trò chuyện mới thông thường, yêu cầu Codex đọc một luồng mục tiêu khác và trả lời câu hỏi của bạn. Cách này đặc biệt mạnh mẽ nếu bạn yêu cầu Codex thiết lập một tác vụ tự động để kiểm tra tiến độ định kỳ.
Tuyệt vời, mục tiêu cuối cùng cũng hoàn thành! Bây giờ có thể ném kết quả cho nhóm và kết thúc công việc không?
Thông thường, đặc biệt là trong các tác vụ tối ưu hóa, tôi thấy việc yêu cầu Codex xem xét và đánh giá lại công việc đã làm rất hữu ích. Bạn có thể chạy /review để thực hiện một đánh giá code cục bộ, nhưng cũng đáng để Codex suy ngẫm sâu hơn: nó đã thử những hướng nào để đạt được mục tiêu? Những thử nghiệm nào hiệu quả? Những thử nghiệm nào không? Sau đó dọn dẹp code dựa trên đó.
Vì Codex sẽ làm việc liên tục cho đến khi đạt được mục tiêu, nên nó có thể đã thử một số phương pháp không hiệu quả hoặc hoàn toàn vô ích, và những thay đổi còn sót lại đó có thể vẫn nằm trong code cuối cùng.
Đặt một mục tiêu cho nhiệm vụ tiếp theo của bạn
Mục tiêu chức năng 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, nó mới có thể đạt được mục tiêu một cách hiệu quả hơn.
Bạn đã từng làm gì với /goal?
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia