Biên tập viên: Bài viết này đến từ Dominik Kundel, thành viên quan hệ phát triển của OpenAI, tổng hợp kinh nghiệm sử dụng tính năng Codex “goal mode //goal”. Bài viết không bàn về một kỹ thuật prompt thông thường, mà đề cập đến 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à trợ lý mã nguồn phản hồi các lệnh đơn lẻ, mà đang bắt đầu trở thành một Agent thực thi có thể tiếp tục tiến hành một cách nhất quán xung quanh các mục tiêu rõ ràng.

Trong chế độ /goal, điều quan trọng thực sự không phải là viết yêu cầu càng dài và chi tiết càng tốt, mà là thiết lập các tiêu chí thoát rõ ràng và có thể kiểm chứng cho Codex. Ví dụ: “giảm thời gian triển khai 30%”, “đạt độ bao phủ kiểm thử 100% parity”, “giảm LCP xuống dưới 2,5 giây”. Những chỉ số này giúp Codex xác định được khi nào nhiệm vụ đã hoàn thành, đồng thời ngăn nó thử nghiệm 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 độ và xác minh kết quả, thay vì chỉ hoàn thành một giải pháp trông có vẻ khả thi trong điều kiện cục bộ hoặc giả định.

Bài viết đặc biệt lưu ý rằng các nhiệm vụ trực quan dễ khiến Codex mắc kẹt trong chi tiết. Thay vì yêu cầu “phản chiếu 100% ở cấp độ pixel”, hãy chia nhỏ mục tiêu trực quan thành danh sách chức năng, quy chuẩn hệ thống thiết kế và các chỉ số có thể đánh giá. Đối với các nhiệm vụ kéo dài hàng giờ甚至 vài ngày, cần theo dõi liên tục thông qua các cách như commit, draft PR, tài liệu tiến độ, cập nhật Slack hoặc trò chuyện phụ, nhằm 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.

Sự gia tăng thông tin trong bài viết này nằm ở chỗ nó tái định nghĩa /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 trong hàng chụ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: không còn chỉ là khiến AI tạo mã, mà còn là xác định mục tiêu cho nó, 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 tiến hành kiểm tra và tổng kết. Nói cách khác, lập trình bằng AI đang chuyển từ “viết prompt” sang “quản lý một thực thể thực thi công 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, hoặc /goal) để giúp bạn thúc đẩy Codex tiến tới 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 được đạt được—dù điều đó cần 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ẽ. Để tối đa hóa hiệu quả của nó, khi sử dụng /goal, hãy lưu ý 7 điều sau.

Thiết lập các tiêu chuẩn rõ ràng, có thể xác minh được

Khi bạn nhập từ khóa kích hoạt chế độ mục tiêu, từ khóa này không chỉ đóng vai trò là lời nhắc ban đầu, mà quan trọng hơn, nó sẽ trở thành tiêu chí kết thúc mục tiêu này. Codex sẽ kiểm tra sau mỗi vòng làm việc: mục tiêu này đã hoàn thành chưa.

Do đó, 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 trường hợp nào thì mục tiêu đó được coi là đã đạt được.

Trong hầu hết các trường hợp, một mục tiêu tốt nên bao gồm một chỉ số số liệu rõ ràng để mô hình đá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 30%.

Di chuyển tính năng này từ TypeScript sang Rust và đạt 100% độ nhất quán kiểm thử.

Tối ưu hóa khung ứng dụng để giảm chỉ số Largest Contentful Paint (LCP) – thước đo tốc độ tải nội dung chính của trang – xuống dưới 2,5 giây trong môi trường sản xuất.

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

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

Codex có thể tự thiết lập mục tiêu. Bạn có thể bắt đầu một cuộc hội thoại bình thường, và khi bạn sẵn sàng để Codex bắt đầu thực hiện, hãy để 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 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.

Cố gắng cung cấp hướng dẫn càng nhiều càng tốt

Các gợi ý như “giảm thời gian xây dựng và triển khai 30%” nghe có vẻ tuyệt vời 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大致 về nơi có thể xảy ra vấn đề, những gợi ý này cũng có thể khiến Codex đi lệch hướng.

Vì vậy, khi có thể, tốt nhất nên chỉ cho Codex biết nên bắt đầu tìm kiếm từ đâu, có thể sử dụng những công cụ nào để đạt được 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 thông báo cho Codex rằng có thể truy cập Google Colab thông qua trình duyệt Chrome và nêu ra một số giới hạn chấp nhận được, chẳng hạn như khi để Codex huấn luyện mô hình, nó có thể tự tạo bộ 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 ở giai đoạn nào, tốt nhất hãy hướng Codex đến khu vực đó ngay trong lời nhắc.

Một cách khác là bạn có thể để Codex thực hiện một số nghiên cứu ban đầu ở chế độ lập kế hoạch (plan mode) và cho nó tạo một tệp kế hoạch ghi lại các phương án tiềm năng, sau đó bạn có thể tham chiếu đến tệp kế hoạch này.

Make progress measurable

Nếu mục tiêu của bạn rất tham vọng hoặc Codex có nhiều cách khác nhau để từng bước tiếp cậ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ể tự nhiên đúng. Ví dụ: tối ưu hóa thời gian xây dựng, tăng độ bao 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.

Tuy nhiên, đối với các mục tiêu khác, bạn nên bắt đầu bằng cách brainstorm cùng Codex: những công cụ nào giúp đánh giá tiến độ? Hoặc cung cấp một số gợi ý để nó biết cách xác định liệu mình có đang tiến gần đến mục tiêu hay không. 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 xây dựng một bộ đánh giá dành riêng cho tác nhân bạn đang gỡ lỗi.

Tôi từng yêu cầu Codex sao chép một số thành phần từ một đoạn video, lúc đó Codex đã tự tạo ra 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 bằng cách thêm các chế độ so sánh khác nhau.

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

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

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

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

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 giải quyết các vấn đề về độ trễ, Codex cần có quyền truy cập vào các môi trường triển khai và kiểm thử, và các môi trường này nên mô phỏng gần nhất với môi trường sản xuất — sử dụng cùng một stack công nghệ, cùng các công tắc cấu hình, cũng như cơ sở dữ liệu tương tự.

Ví dụ, chúng tôi từng điều chỉnh tối ưu thời gian xây dựng và triển khai tại developers.openai.com. Lúc đó, chúng tôi đã sử dụng bản xem trước triển khai, do đó Codex có thể tận dụng các môi trường xem trước này để triển khai và xem nhật ký liên quan. Nhưng vấn đề là 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 xây dựng so với môi trường sản xuất đầy đủ.

Do đó, Codex cuối cùng phải thực hiện triển khai thủ công để đưa mã vào môi trường gần với cấu hình sản xuất hơn, mới có thể xác định chính xác vấn đề.

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

Đặt mục tiêu thị giác một cách cẩn trọng

Việc đưa cho Codex một mục tiêu trực quan, chẳng hạn như “phục hồi chính xác 100% giao diện người dùng này theo hình ảnh”, thật sự rất hấp dẫn. Tuy nhiên, tùy 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ể bị cuốn sâu vào một số chi tiết nhỏ và 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 những yếu tố này—dù là biểu tượng SVG hay hình ảnh—nó có thể tốn quá nhiều nỗ lực vào việc "tái tạo chính xác các tài liệu này" thay vì phân tích đúng toàn bộ vấn đề.

Ngoài ra, Codex cần công cụ để thực hiện so sánh trực quan chính xác. Điều này có nghĩa là cần nhiều hình ảnh đầu vào hơn và tiêu tốn nhiều token hơn, nhưng không nhất thiết cung cấp cho Codex một cách đơn giả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 ngữ cảnh mục tiêu thay vì tiêu chuẩn hoàn thành duy nhất. Bạn nên tìm các cách khác để Codex xác định xem mục tiêu đã đạt được chưa, ví dụ như danh sách chức năng, thông số kỹ thuật triển khai, hoặc việc có tuân thủ hệ thống thiết kế hay không.

Theo dõi tiến độ

Nếu Codex cuối cùng chạy hàng giờ甚至 hàng ngày ở nền, thậm chí trên một máy khác, bạn rất dễ quên nó đã tiến đến đâu và đã thực hiện những công việc gì.

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

· Để Codex gửi mã tại các mốc quan trọng và đẩy đến một PR nháp. Điều này đặc biệt hữu ích khi bạn đang phát triển trang web và có bản triển khai xem trước.

· Hãy để Codex cập nhật một tài liệu giao hàng dành cho ban quản lý. Tài liệu này có thể là một tệp HTML mà bạn có thể luôn mở trong trình duyệt nội bộ; 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 tệp Markdown thông thường.

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

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 nhanh chóng kiểm tra trạng thái hiện tại, hãy chạy /side để khởi động một cuộc trò chuyện bên cạnh và đặt câu hỏi ở đó. Vì nó sẽ tách ra từ luồng hiện tại nên có đầy đủ ngữ cảnh cho đến thời điểm hiện tại, nhưng vòng đời ngắn.

Một phương pháp thay thế khác trong ứng dụng Codex là: khởi tạo một cuộc trò chuyện mới bình thường, để 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ỳ.

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

Tuyệt vời, mục tiêu cuối cùng đã hoàn thành! Giờ thì có thể trực tiếp giao kết quả cho đội ngũ và nghỉ ngơi rồi phải không?

Thông thường, đặc biệt trong các tác vụ tối ưu hóa, tôi thấy rằng việc để Codex xem lại và đánh giá công việc mà nó đã hoàn thành là rất hữu ích. Bạn có thể chạy một cuộc kiểm tra mã cục bộ bằng lệnh /review, nhưng cũng đáng để Codex suy ngẫm sâu hơn: nó đã thử những con đường nào để đạt được mục tiêu? Những nỗ lực nào hiệu quả? Những nỗ lực nào không hiệu quả? Sau đó, dựa trên đó để làm sạch mã.

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

Đặt mộ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 giải quyết một số thách thức kỹ thuật ý nghĩa nhất. Nhưng nó chỉ có thể đạt hiệu quả cao hơn khi bạn cung cấp môi trường và hướng dẫn chính xác.

Bạn đã dùng /goal để làm gì?