Bản gốc tiêu đề: Hướng dẫn /goal
Tác giả bản gốc: @dkundel, thành viên quan hệ nhà phát triển của OpenAI
Dịch: Peggy

Lời người biên tập: Bài viết này từ thành viên quan hệ nhà phát triển của OpenAI, Dominik Kundel, tổng kết kinh nghiệm sử dụng chức năng Codex「goal mode / /goal」. Nó không phải là một kỹ thuật prompt thông thường, mà là một sự thay đổi vai trò đang diễn ra của công cụ lập trình AI: Codex không còn chỉ là trợ lý mã phản hồi theo lệnh đơn lẻ nữa, mà bắt đầu trở thành một Agent thực thi có thể liên tục thúc đẩy dựa trên 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 và chi tiết, mà là thiết lập tiêu chuẩn thoát rõ ràng và có thể xác minh cho Codex. Ví dụ: 「giảm thời gian triển khai 30%」「đạt độ phủ kiểm thử 100%」「LCP giảm xuống dưới 2.5 giây」. Những chỉ số này giúp Codex xác định xem nhiệm vụ đã hoàn thành chưa, đồng thời tránh việc nó thử sai vô hạn trong các mục tiêu mơ hồ. Đồng thời, người dù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 trình, xác nhận kết quả, chứ không chỉ hoàn thành một giải pháp khả thi trong môi trường giả lập hoặc cục bộ.

Bài viết đặc biệt nhấn mạnh rằng, các nhiệm vụ liên quan đến thị giác dễ khiến Codex rơi vào bẫy chi tiết. Thay vì yêu cầu 「hoàn thiện pixel chính xác 100%」, tốt hơn là phân chia mục tiêu thị giác thành danh sách chức năng, hệ thống thiết kế và các chỉ số có thể đánh giá. Đối với các nhiệm vụ dài hàng giờ hoặc hàng ngày, cũng cần theo dõi liên tục qua commit, draft PR, tài liệu tiến trình, 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 nguồn gốc.

Thông tin bổ sung của bài viết 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ể liên tục thực thi hàng chục hoặc hàng trăm giờ, năng lực cốt lõi của nhà phát triển cũng thay đổi: không chỉ để AI sinh mã, mà còn để định nghĩa mục tiêu, xây dựng hệ thống đo lường, cấu hình môi trường thực thi, và cuối cùng là thực hiện kiểm duyệt, 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 thực thể kỹ thuật liên tục hoạt động」.

Dưới đây là nguyên bản:

Chúng tôi đã ra mắt chế độ mục tiêu (goal mode, hoặc /goal), nhằm giúp bạn thúc đẩy Codex hướng tới một kết quả cụ thể liên tục. Khi bạn đặt ra một mục tiêu, Codex sẽ làm việc liên tục cho đến khi đạt được — dù mất vài giờ, hay vài 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 mạnh mẽ. Để phát huy tối đa tác dụng của nó, khi dùng /goal có 7 điều cần chú ý.

Đặt tiêu chuẩn rõ ràng, có thể xác minh

Khi bạn kích hoạt chế độ mục tiêu, prompt bạn nhập vào có thể dùng làm prompt ban đầu, nhưng quan trọng hơn, nó sẽ trở thành tiêu chuẩn thoát của mục tiêu đó. Codex sẽ kiểm tra sau mỗi vòng làm việc: mục tiêu đã hoàn thành chưa.

Vì vậy, prompt 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 trường hợp nào, mới coi là mục tiêu đã đạt.

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

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

「Chuyển chức năng này từ TypeScript sang Rust và đạt độ nhất quán kiểm thử 100%.」

「Tối ưu hóa khung ứng dụng, để thời gian tải nội dung lớn nhất (Largest Contentful Paint, chỉ số đo tốc độ tải nội dung chính của trang) dưới 2.5 giây.」

Prompt này không nhất thiết phải luôn chứa số, nhưng thường thì, số sẽ giúp các bước tiếp theo dễ dàng hơn.

Nếu bạn còn chưa chắc chắn cách định nghĩa mục tiêu, hoặc muốn cùng Codex brainstorm dự án này trước, cũng không cần bắt đầu bằng chế độ mục tiêu ngay từ đầu.

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

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

Cung cấp hướng dẫn càng nhiều càng tốt

Những prompt như 「giảm thời gian xây dựng và triển khai 30%」 nghe có vẻ ấn tượng, và có thể giúp Codex tìm ra các giải pháp sáng tạo. Nhưng nếu bạn đã phần nào biết vấn đề nằm ở đâu, thì prompt này có thể khiến Codex đi lối mòn.

Vì vậy, trong khả năng, tốt nhất là nói cho Codex biết nên bắt đầu kiểm tra từ đâu, có thể 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 sai hướng.

Ví dụ, đồng nghiệp của tôi @reach_vb đã làm như vậy trong một thử nghiệm: anh ấy nói với Codex, có thể dùng Chrome để vào Google Colab, và nêu rõ một số giới hạn chấp nhận được, như khi huấn luyện mô hình, để nó tự sinh 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 tiêu tốn ở đâu, tốt nhất là trong prompt, hướng dẫn Codex tập trung vào khu vực đó.

Một cách khác là, bạn có thể để Codex trong chế độ lập kế hoạch (plan mode), để nó nghiên cứu sơ bộ và tạo ra một kế hoạch, ghi lại các phương án tiềm năng. Sau đó, mục tiêu của bạn sẽ dựa vào kế hoạch này.

Làm cho tiến trình đo lường được

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

Với một số nhiệm vụ, điều này vốn đã rõ ràng. Ví dụ như tối ưu thời gian xây dựng, nâng cao độ phủ kiểm thử, vì Codex thường đã có thể dùng các công cụ liên quan, hoặc tự tạo ra chúng.

Nhưng với các mục tiêu khác, tốt nhất là brainstorm cùng Codex: những công cụ nào giúp đánh giá tiến trình? Hoặc đưa ra các gợi ý để nó biết cách xác nhận đã tiến gần mục tiêu chưa. Ví dụ: tạo công cụ so sánh sự khác biệt hình ảnh giữa hai ảnh chụp màn hình, hoặc tạo bộ đánh giá cho agent đang debug.

Tôi từng yêu cầu Codex dựa trên một đoạn video để tái tạo một số thành phần, và nó đã tự tạo ra một công cụ so sánh ảnh, 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 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 hình ảnh của hai khung hình.

Tùy theo nhiệm vụ, bạn còn cần xem xét liệu có tiêu chuẩn bổ sung nào cần đo lường hoặc kiểm tra không. Nếu không, Codex có thể nghĩ rằng nhiệm vụ đã hoàn thành, trong khi thực tế chưa phải vậy.

Ví dụ, để 「hoàn thiện pixel chính xác」 một UI, Codex có thể cắt bỏ hình tham khảo và nhúng vào trang; hoặc để đạt 100% tỷ lệ thành công kiểm thử, nó có thể giảm phạm vi kiểm thử. Những cách này không phải là cách bạn muốn.

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

Nếu bạn muốn Codex thực sự tiến bộ theo mục tiêu, nó cần 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 thời gian triển khai hoặc độ trễ, Codex cần có quyền truy cập vào môi trường triển khai và kiểm thử, và các môi trường này càng giống môi trường sản xuất càng tốt. Cùng công nghệ, cấu hình, và cơ sở dữ liệu tương tự.

Ví dụ, chúng tôi từng thử tối ưu thời gian xây dựng và triển khai của developers.openai.com. Khi đó, chúng tôi đã dùng các bản xem trước triển khai, để Codex có thể dùng các môi trường này để triển khai và xem nhật ký liên quan. Nhưng vấn đề là, các môi trường xem trước này khác với môi trường sản xuất đầy đủ, vì một số đường dẫn xây dựng bị tắt.

Vì vậy, cuối cùng, Codex phải tự triển khai thủ công, đưa mã vào môi trường gần giống cấu hình sản xuất nhất có thể, để kiểm tra vấn đề thực sự.

Tương tự, bạn có thể cho Codex dùng khả năng thao tác thực tế (computer use) để thử nghiệm ứng dụng thực tế. Để tối ưu các vấn đề hiệu năng trên iOS, @dimillian thậm chí đã dùng thiết bị vật lý để có môi trường kiểm tra chính xác nhất.

Cẩn thận thiết lập mục tiêu thị giác

Giao cho Codex một mục tiêu thị giác, như 「dựa trên hình này, hoàn thiện pixel chính xác UI」, quả thật rất hấp dẫn. Nhưng tùy vào cách thiết lập, điều này cũng có thể gây rắc rối.

Nếu không cung cấp hướng dẫn và giới hạn phù hợp, Codex có thể bị sa đà vào chi tiết, bỏ quên mục tiêu tổng thể. Ví dụ, nếu hình tham khảo chứa các yếu tố đồ họa, và bạn mong muốn 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 thời gian để “tái tạo chính xác” các thành phần này, thay vì phân tích toàn bộ vấn đề đúng cách.

Ngoài ra, Codex cần công cụ để so sánh thị giác chính xác. Điều này đồng nghĩa với việc cần nhiều ảnh đầu vào hơn, token tiêu hao nhiều hơn, nhưng không nhất thiết giúp nó nhận diện 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 làm phần ngữ cảnh mục tiêu, chứ không phải tiêu chuẩn hoàn thành duy nhất. Bạn nên tìm cách khác để Codex đánh giá xem mục tiêu đã đạt chưa, như danh sách chức năng, tiêu chuẩn thực thi, hoặc phù hợp với hệ thống thiết kế.

Theo dõi tiến trình

Nếu Codex làm việc nền trong nhiều giờ hoặc nhiều ngày, thậm chí chạy trên máy khác, bạn rất dễ quên nó đã tiến xa đến đâu, đã làm gì.

Tùy theo mục tiêu, tôi thấy các cách sau rất hữu ích:

· Yêu cầu Codex commit mã tại các mốc quan trọng, đẩy lên PR nháp. Đặc biệt khi bạn làm website và có các bản xem trước, cách này rất tiện.

· Yêu cầu Codex cập nhật một tài liệu giao hàng cho quản lý. Có thể là một file HTML mở trong trình duyệt nội bộ; hoặc một trang được deploy qua Sites để nhóm xem; hoặc một biểu đồ tiến trình render, hoặc chỉ là một file Markdown thông thường.

Chỉ đạo Codex tự cập nhật tiến trình. Bạn cũng có thể đưa điều này vào mục tiêu: để Codex gửi cập nhật khi có tiến bộ quan trọng, đến Slack hoặc nơi bạn muốn ghi nhận.

Dùng các cửa sổ chat khác để hỏi trạng thái. Nếu muốn nhanh, có thể chạy /side để mở chat phụ, hỏi trực tiếp. Nó sẽ tách ra khỏi thread chính, có đầy đủ ngữ cảnh hiện tại, nhưng thời gian sống ngắn.

Trong ứng dụng Codex, một cách khác là mở một cuộc trò chuyện mới, để Codex đọc thread mục tiêu khác và trả lời câu hỏi của bạn. Nếu bạn yêu cầu Codex tự thiết lập tự động kiểm tra tiến trình định kỳ, cách này đặc biệt mạnh.

Dọn dẹp và xác nhận kết quả cuối cùng

Thật tuyệt, mục tiêu đã hoàn thành! Giờ có thể gửi kết quả cho nhóm rồi nghỉ ngơi?

Thông thường, đặc biệt với các nhiệm vụ tối ưu, tôi thấy rất hữu ích khi để Codex xem lại và đánh giá chính nó. Bạn có thể chạy /review để tự kiểm tra mã, nhưng cũng nên để Codex suy nghĩ sâu hơn: nó đã thử những cách nào để đạt mục tiêu? Những cách nào hiệu quả? Những cách nào không? Từ đó, dọn dẹp code.

Vì Codex làm việc liên tục cho đến khi đạt mục tiêu, nên nó có thể đã thử các phương pháp không hiệu quả hoặc hoàn toàn sai, và những thay đổi còn sót lại có thể nằm trong mã cuối cùng.

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

Chức năng mục tiêu của Codex là một công cụ cực kỳ mạnh mẽ, giúp bạn vượt qua những thử thách kỹ thuật quan trọng nhất. Nhưng chỉ khi cung cấp môi trường và lệnh đúng, nó mới có thể đạt được mục tiêu một cách hiệu quả hơn.

Bạn đã dùng /goal như thế nào rồi?

[Liên kết bản gốc]

Nhấn để tìm hiểu về tuyển dụng của BlockBeats tại Rhythm

Chào mừng gia nhập cộng đồng chính thức của Rhythm BlockBeats:
Telegram đăng ký nhóm: https://t.me/theblockbeats
Telegram nhóm thảo luận: https://t.me/BlockBeats_App
Twitter chính thức: https://twitter.com/BlockBeatsAsia