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 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ỉ bàn về một kỹ thuật nhắc lệnh thông thường, mà là về 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à trợ lý mã hóa phản hồi các chỉ thị một lần, mà bắt đầu trở thành một Tác nhân (Agent) thực thi có thể liên tục thúc đẩy xoay quanh một 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 một tiêu chuẩn thoát rõ ràng, có thể kiểm chứng. Ví dụ: "Giảm thời gian triển khai 30%", "Đạt độ bao phủ kiểm thử 100% như bản gốc", "Giảm LCP xuống dưới 2.5 giây". Những chỉ số này cho phép Codex đánh giá liệu nhiệm vụ đã hoàn thành hay chưa, đồng thời tránh cho nó thử sai 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 đủ định hướng, 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 phương án có vẻ khả thi trong điều kiện giả định hoặc cục bộ.
Bài viết đặc biệt nhắc nhở, các nhiệm vụ liên quan đến hình ảnh dễ khiến Codex sa đà vào chi tiết nhất. Thay vì yêu cầu "phục nguyên 100% ở cấp độ pixel", hãy chia nhỏ mục tiêu hình ảnh 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ụ dài hạn kéo dài hàng giờ thậm chí hàng ngày, cũng cần theo dõi liên tục thông qua commit, PR nháp, tài liệu tiến độ, cập nhật Slack hoặc side chat, tránh việc cuối cùng chỉ nhận được một đống thay đổi không thể truy vết.
Thông tin mới 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 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 theo: không chỉ là để AI tạo ra mã, mà là định nghĩa 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 rà soát và tổng kết. Nói cách khác, lập trình với AI đang chuyển từ "viết lệnh nhắc" sang "quản lý một tác nhân 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 đã giới thiệu chế độ mục tiêu (goal mode, hoặc /goal) để giúp bạn khiến Codex liên tục thúc đẩy hướng tới một kết quả cụ thể. Khi bạn thiết lập một mục tiêu, Codex sẽ tiếp tục làm việc cho đến khi đạt được mục tiêu đó — cho dù đ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ờ.
Chế độ mục tiêu rất mạnh mẽ. Để tận dụng tối đa sức mạnh của nó, có 7 điều đáng lưu ý khi sử dụng /goal.
Thiết lập tiêu chuẩn rõ ràng, có thể kiểm chứng
Lệnh nhắc bạn nhập khi kích hoạt chế độ mục tiêu, vừa có thể đóng vai trò là lệnh nhắc ban đầu, quan trọng hơn, nó sẽ trở thành tiêu chuẩn thoát cho 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ệnh nhắc 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 chuẩn rõ ràng: Trong trường hợp nào, thì mới được tính là mục tiêu này đã đạt được.
Trong hầu hết trường hợp, một mục tiêu tốt nên chứa một chỉ số số rõ ràng, để mô hình có thể đánh giá xem đã hoàn thành 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 được độ nhất quán kiểm thử 100%."
"Tối ưu hóa khung ứng dụng, sao cho LCP (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 thấp hơn 2.5 giây."
Lệnh nhắc này không nhất thiết lúc nào cũng phải chứa số, nhưng thông thường, con số sẽ giúp các bước tiếp theo dễ tiến triển hơn.
Nếu bạn vẫn chưa chắc chắn cách định nghĩa mục tiêu, hoặc muốn trước hết động não về dự án này cùng Codex, cũng không cần thiết 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ể trước tiên bắt đầu một cuộc trò chuyện bình thường, sau khi bạn đã sẵn sàng để Codex bắt đầu thực thi, 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 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.
Cung cấp định hướng càng nhiều càng tốt
Một lệnh nhắc như "giảm thời gian xây dựng và triển khai 30%" nghe có vẻ rất hay, và cũng 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 đã biết đại khái vấn đề có thể nằm ở đâu, loại lệnh nhắc này cũng có thể khiến Codex đi vào ngõ cụt.
Vì vậy, trong những trường hợp có thể, tốt nhất hãy nói 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 sai hướng.
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 nói với Codex, có thể sử dụng trình duyệt Chrome để vào Google Colab, và nêu ra một số điều kiện giới hạn có thể chấp nhận được, chẳng hạn như khi để Codex huấn luyện mô hình, có thể để nó 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 tiêu tốn ở khâu nào, tốt nhất hãy hướng Codex đến khu vực đó trước trong lệnh nhắc.
Một cách làm khác là, bạn có thể để Codex thực hiện một số nghiên cứu sơ bộ trong chế độ kế hoạch (plan mode), và để nó tạo một tệp kế hoạch, dùng để ghi lại các phương án tiềm năng. Sau đó, hãy để mục tiêu của bạn tham chiếu đến bản kế hoạch này.
Làm cho tiến độ có thể đo lường
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 để tiệm cận mục tiêu từng bước, 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 nhiên đúng. Ví dụ tối ưu hóa thời gian xây dựng, nâng cao độ bao phủ kiểm thử, bởi 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 những công cụ này.
Nhưng đối với các mục tiêu khác, bạn tốt nhất nên trước hết động não cùng Codex: những công cụ nào có ích cho việc đánh giá tiến độ? Hoặc cho nó một số gợi ý, để nó biết nên xác nhận bản thân có đang tiến gần đến mục tiêu hay không. Ví dụ, tạo một công cụ so sánh sự khác biệt hình ảnh cho hai ảnh chụp màn hình, hoặc tạo một bộ đánh giá cho tác nhân thông minh mà bạn đang gỡ lỗi.
Tôi từng để Codex tạo lại một số thành phần dựa trên một đoạn video, lúc đó 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 lặp lại công cụ này, thêm vào các chế độ so sánh khác biệt khác nhau.
Tùy theo nhiệm vụ, bạn cũng cần cân nhắc liệu có một số tiêu chuẩn bổ sung 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 trong mắt bạn thì thực ra vẫn chưa đầy đủ.
Ví dụ, Codex có thể để đạt được "phục nguyên ở cấp độ pixel" cho một UI nào đó, trực tiếp cắt ảnh tham khảo thiết kế và nhúng vào trang; hoặc để đạt tỷ lệ vượt qua kiểm thử 100%, lại cắt giảm phạm vi bao phủ kiểm thử. Đây không phải là cách thức hoàn thành mà bạn thực sự mong muố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 triển hiệu quả hướng tới 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 vấn đề độ trễ, Codex nên có thể truy cập vào môi trường triển khai và kiểm thử, và những môi trường này càng mô phỏng môi trường sản xuất càng tốt. Tức là sử dụng cùng công nghệ, cùng cấu hình switch, và cơ sở dữ liệu tương tự.
Ví dụ, chúng tôi từng gỡ lỗi tối ưu hóa thời gian xây dựng và triển khai cho developers.openai.com. Lúc đó chúng tôi đã sử dụng triển khai xem trước, vì vậy Codex có thể sử 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à, 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, triển khai 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ể thực sự kiểm tra vấn đề nằm ở đâu.
Tương tự, bạn cũng có thể để Codex sử dụng computer use (khả năng cho mô hình thao tác giao diện ứng dụng thực) để kiểm thử ứ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ực, để có được môi trường kiểm thử chính xác nhất.
Thiết lập mục tiêu hình ảnh một cách thận trọng
Đưa cho Codex một mục tiêu hình ảnh, ví dụ "phục nguyên 100% pixel UI này dựa theo bức ảnh này", quả thực rất hấp dẫn. Nhưng tùy theo cài đặt cụ thể, điều này cũng có thể mang lại 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 đà vào một số chi tiết, thay vì bỏ qua mục tiêu tổng thể. Ví dụ, nếu ả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 — cho dù là biểu tượng SVG hay hình ảnh — nó có thể tiêu tốn nhiều công sức vào "làm thế nào để phục nguyên chính xác những tài liệu này", thay vì phân giải toàn bộ vấn đề một cách chính xác.
Ngoài ra, Codex cần công cụ để có thể so sánh hình ảnh một cách chính xác. Điều này đồng nghĩa với việc đầu vào hình ảnh nhiều hơn, tổng tiêu hao token cao hơn, nhưng không nhất định cung cấp cho Codex một cách thức đơn giản để nó nhận diện cơ hội cải thiện thực sự có giá trị.
Vì vậy, hình ảnh thường phù hợp hơn khi là ngữ cảnh mục tiêu, thay vì là tiêu chuẩn hoàn thành duy nhất. Bạn nên tìm kiếm các cách thức khác để Codex đánh giá mục tiêu đã đạt được hay chưa, ví dụ danh sách chức năng, quy chuẩn triển khai, có phù hợp với hệ thống thiết kế hay không.
Theo dõi tiến độ
Nếu Codex cuối cùng làm việc trong nền hàng giờ thậm chí hàng ngày, thậm chí là chạy trên một máy khác, bạn rất dễ quên nó thực sự đã tiến đến đâu, đã làm 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 đây rất hữu ích:
· Để Codex commit mã ở các điểm nút quan trọng, và đẩy lên một PR nháp. Đặc biệt khi bạn đang làm website, và có triển khai xem trước, điều này sẽ rất hữu ích.
· Để Codex cập nhật một tài liệu giao nộp hướng tới quản lý. Nó có thể là một tệp HTML, bạn có thể luôn mở trong trình duyệt trong ứng dụng; cũng có thể là một trang được triển khai qua Sites để nhóm xem; có thể là một biểu đồ tiến độ đã render, hoặc cũng có thể chỉ là một tệp Markdown thông thường.
Chỉ thị Codex chủ động công bố cập nhật tiến độ. Bạn cũng có thể viết điều này vào mục tiêu: để Codex gửi cập nhật đến kênh Slack, hoặc những nơi khác bạn muốn ghi lại tiến độ khi đạt được tiến triể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, có thể chạy /side để khởi động một cuộc trò chuyện bên mới, và hỏi ở đó. Vì nó sẽ được nhánh ra từ luồng hiện tại, nên có toàn bộ ngữ cảnh tính đến thời điểm hiện tại, nhưng vòng đời rất ngắn.
Một phương pháp thay thế khác trong ứng dụng Codex là: mở 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. Nếu bạn để Codex thiết lập một nhiệm vụ tự động hóa, định kỳ kiểm tra tiến độ, cách thức này sẽ đặc biệt mạnh mẽ.
Dọn dẹp và xác nhận kết quả cuối cùng
Thật tuyệt vời, cuối cùng mục tiêu cũng đã hoàn thành! Bây giờ có phải chỉ cần quăng thẳng thành quả cho nhóm, rồi thu dọn?
Thông thường, đặc biệt là trong các nhiệm vụ tối ưu hóa, tôi thấy việc để Codex xem xét lại và rà soát công việc mình đã hoàn thành sẽ rất hữu ích. Bạn có thể trước tiên chạy /review để thực hiện một lần rà soát mã cục bộ, 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 có hiệu quả? Những nỗ lực nào không hiệu quả? Sau đó dựa vào đó để dọn dẹp mã.
Bởi vì Codex sẽ tiếp tục làm việ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 đủ tốt, thậm chí hoàn toàn vô hiệu, và những thay đổi tồn đọng này có thể vẫn còn trong mã cuối cùng.
Thiết lập một goal 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 ý nghĩa nhất. Nhưng chỉ khi bạn cung cấp đúng môi trường và chỉ thị, nó mới có thể đến đích hiệu quả hơn.
Bạn đã làm gì với /goal?










