Codex có thể làm việc trong thời gian dài, đặc biệt là khi một /goal cung cấp cho nó một mục tiêu bền bỉ. Phần khó hơn là duy trì định hướng khi nó làm việc trong nhiều giờ hoặc nhiều ngày, khám phá ra các chi tiết triển khai mới và trải qua nhiều hình thức xác minh khác nhau.
Các giả định ban đầu thường thay đổi khi quá trình triển khai bắt đầu. Mô hình cộng tác cần bảo toàn mục tiêu trong khi cho cả bạn và Codex không gian để điều chỉnh kế hoạch khi có bằng chứng mới xuất hiện.
Trong vài tuần qua, tôi đã sử dụng năm phương pháp sau:
- Để Codex lập kế hoạch công việc và duy trì lộ trình.
- Giữ luồng chính tập trung vào việc điều phối.
- Kiểm tra lộ trình và xem xét mã sau mỗi cột mốc.
- Sử dụng các luồng cục bộ để kiểm thử Computer Use.
- Báo cáo tiến độ thông qua các bản cập nhật và bảng điều khiển ngắn gọn.
Được tạo bằng GPT Image 2 trong Codex
1. Để Codex lập kế hoạch công việc và duy trì lộ trình
Tôi thường bắt đầu bằng một cuộc trò chuyện thay vì chế độ /plan. Tôi mô tả những gì tôi đang cố gắng xây dựng, đọc ra những suy nghĩ sơ bộ, chia sẻ các ràng buộc và để Codex đặt câu hỏi cho đến khi nó có đủ ngữ cảnh để đề xuất một kế hoạch ban đầu.
Điều này giúp cuộc thảo luận ban đầu trở nên linh hoạt. Tôi không cần phải biến những ý tưởng còn dang dở thành một đặc tả chính thức trước khi Codex có thể bắt đầu hỗ trợ. Nó có thể phỏng vấn tôi, phản hồi lại những gì nó hiểu, xác định các khoảng trống và dần dần biến cuộc trò chuyện thành một kế hoạch khả thi.
Khi dự án hình thành, tôi yêu cầu Codex thiết lập Goal hiện tại. Chế độ Goal cung cấp cho Codex một mục tiêu bền bỉ, cho phép nó tiếp tục làm việc hướng tới cùng một kết quả qua nhiều lượt cho đến khi mục tiêu hoàn thành, bị chặn hoặc được thay thế.
Tôi có thể tự đặt mục tiêu bằng /goal, nhưng tôi thường yêu cầu Codex làm điều đó. Chế độ Goal được hiển thị thông qua harness, vì vậy Codex có thể tổng hợp cuộc trò chuyện của chúng tôi, bối cảnh dự án và mọi thứ nó đã học được cho đến nay thành một mục tiêu rõ ràng. Nó cũng có thể xác định bằng chứng cần thiết trước khi coi mục tiêu đó là hoàn thành.
Đối với các dự án lớn hơn, tôi yêu cầu Codex viết lộ trình tổng thể vào GOALS.md. Đây là một quy ước của dự án chứ không phải là một tính năng có sẵn của Codex và tệp có thể được đặt tên tùy thích.
Tôi thường tổ chức GOALS.md xoay quanh các cột mốc thay vì một danh sách tác vụ phẳng. Mỗi cột mốc ghi lại:
- kết quả dự kiến
- công việc hiện đang trong phạm vi
- các quyết định quan trọng
- các trình chặn đã biết
- bằng chứng cần thiết trước khi tiếp tục
Codex duy trì tệp khi dự án phát triển. Những phát hiện mới có thể thay đổi phạm vi của một cột mốc, giới thiệu một cột mốc khác hoặc thay đổi bằng chứng cần thiết để hoàn thành.
Chỉ có một mục tiêu ở chế độ Goal hoạt động tại một thời điểm. Khi các cột mốc được hoàn thành, Codex cập nhật GOALS.md, kích hoạt mục tiêu tiếp theo và tiếp tục làm việc hướng tới nó.
2. Giữ luồng chính tập trung vào việc điều phối
Khi lộ trình đã tồn tại, tôi giữ luồng chính tập trung vào mục tiêu, các ràng buộc, quyết định và trạng thái hiện tại của dự án.
Nó quyết định điều gì sẽ xảy ra tiếp theo, ủy quyền các nhiệm vụ có giới hạn và đánh giá kết quả. Nó không cần phải mang theo mọi chi tiết triển khai.
Một worker có thể dành một giờ để đọc mã không quen thuộc, thử một vài cách tiếp cận hoặc theo dõi một bài kiểm tra thất bại. Người điều phối chỉ cần thông tin ảnh hưởng đến dự án rộng hơn:
- worker đã học được gì
- những gì đã thay đổi
- bằng chứng hỗ trợ
- điều gì sẽ xảy ra tiếp theo
Codex có thể ủy quyền công việc này cho một subagent hoặc tạo một luồng riêng biệt. Về mặt chức năng, chúng có thể thực hiện cùng một nhiệm vụ. Tôi sử dụng một luồng riêng biệt khi tôi mong đợi sẽ xem lại công việc sau, vì nó vẫn hiển thị trong ứng dụng Codex và giữ lịch sử riêng của nó.
Điều này trở nên đặc biệt hữu ích khi một số phần công việc đang chạy song song. Luồng chính có thể tiếp tục điều phối dự án trong khi mỗi cuộc điều tra, triển khai hoặc đánh giá vẫn dễ dàng được kiểm tra.
3. Kiểm tra lộ trình và xem xét mã sau mỗi cột mốc
GOALS.md phản ánh những gì đã biết khi Codex cập nhật nó lần cuối. Vào cuối một cột mốc, dự án thường đã khám phá ra điều gì đó mới.
Trước khi tiếp tục, tôi yêu cầu một luồng khác so sánh lộ trình với trạng thái hiện tại:
- Cột mốc có thực sự hoàn thành không?
- Mục tiêu tiếp theo có còn đúng không?
- Có cột mốc nào bị thiếu không?
- Bằng chứng mới có thay đổi thứ tự công việc không?
- Định nghĩa về "hoàn thành" có còn giá trị không?
Tôi chạy kiểm tra này vào cuối mỗi cột mốc, cũng như bất cứ khi nào bằng chứng mới thay đổi đáng kể hướng đi của dự án.
Tôi cũng chạy /review trên quá trình triển khai.
Giả sử quá trình triển khai và các bài kiểm tra từ xa cho một luồng đăng nhập đã hoàn tất. Kiểm tra lộ trình có thể nhận thấy rằng chưa ai kiểm tra luồng này trong một trình duyệt đã đăng nhập thực sự. Đồng thời, /review có thể phát hiện ra rằng đường dẫn mới lưu trữ token không chính xác mặc dù các bài kiểm tra từ xa đã vượt qua.
Người điều phối cập nhật GOALS.md, ủy quyền sửa lỗi token, thêm xác minh trình duyệt còn thiếu và chỉ sau đó mới kích hoạt cột mốc tiếp theo.
Tôi thường giữ các cuộc kiểm tra và đánh giá trong các luồng riêng biệt. Một subagent có thể thực hiện cùng một công việc, nhưng một luồng riêng biệt để lại một bản ghi có thể nhìn thấy mà tôi có thể quay lại sau.
4. Sử dụng các luồng cục bộ để kiểm thử Computer Use
Hầu hết các phiên Codex của tôi chạy trên một phiên bản từ xa, vì vậy công việc có thể tiếp tục trong khi máy tính xách tay của tôi đóng. Một số kiểm tra vẫn phụ thuộc vào máy cục bộ của tôi:
- một trình duyệt đã đăng nhập
- thông tin xác thực cục bộ
- Xcode
- quyền của macOS
- Trình mô phỏng iOS
Người điều phối từ xa có thể tạo một luồng cục bộ cho một trong những kiểm tra đó. Tôi áp dụng bản diff từ xa hoặc checkout nhánh hoặc commit có liên quan để luồng cục bộ kiểm tra đúng mã.
Luồng cục bộ vận hành trình duyệt hoặc ứng dụng và trả về ảnh chụp màn hình, nhật ký và kết quả. Khi một kiểm tra thất bại, một worker từ xa sửa lỗi và luồng cục bộ kiểm tra lại.
Một vòng lặp điển hình trông như thế này:
- Một worker từ xa triển khai luồng đăng nhập.
- Các bài kiểm tra từ xa vượt qua.
- Một luồng cục bộ sử dụng tiện ích mở rộng Codex Chrome.
- Kiểm tra trình duyệt phát hiện ra lỗi chuyển hướng.
- Một worker từ xa sửa nó.
- Luồng cục bộ lặp lại kiểm tra.
Dự án vẫn ở chế độ từ xa theo mặc định. Máy tính của tôi chỉ tham gia cho các kiểm tra yêu cầu nó. Luồng từ xa cũng có thể tiếp tục kiểm tra xem luồng cục bộ có khả dụng trở lại khi tôi mở lại máy tính xách tay hay không.
5. Báo cáo tiến độ thông qua các bản cập nhật và bảng điều khiển ngắn gọn
Các luồng worker thường báo cáo về một nhiệm vụ. Khi tôi quay lại dự án, tôi cần một cái nhìn tổng quan về trạng thái:
- những gì đã hoàn thành
- những gì đã thay đổi
- những gì còn lại
- những gì cần quyết định
Tôi yêu cầu Codex báo cáo bất cứ khi nào trạng thái dự án thay đổi, sử dụng ba phần ngắn:
**Những gì đã làm xong
Những gì tiếp theo
Bất kỳ trình chặn nào**
Điều này gần giống như có một cuộc họp standup hàng ngày với Codex, mặc dù là hàng giờ.
Codex có thể gửi cùng một bản cập nhật qua Slack, dưới dạng tin nhắn trực tiếp hoặc trong một kênh dự án chuyên dụng.
Khi tôi đang ở trong ứng dụng Codex, tôi cũng sử dụng /side để kiểm tra mà không làm gián đoạn luồng chính. Từ luồng phụ, tôi có thể yêu cầu tóm tắt về những gì đã được hoàn thành, những gì còn lại và liệu có điều gì cần sự giúp đỡ của tôi không—ví dụ: một cú nhấp chuột thủ công, sự chấp thuận hoặc một phần clickops khác.
Nhận tóm tắt từ luồng phụ
Yêu cầu luồng phụ chuyển tiếp hướng dẫn của tôi đến luồng chính
Sau đó, tôi có thể làm rõ một hướng dẫn, giải quyết một trình chặn, thêm ngữ cảnh hoặc yêu cầu luồng phụ gửi hướng dẫn cập nhật trở lại luồng chính.
Đối với các dự án có nhiều cột mốc hoặc luồng công việc song song, tôi cũng duy trì một progress-dashboard.html. Đây là một artifact tùy chỉnh của dự án chứ không phải giao diện người dùng có sẵn của Codex. Nó có thể hiển thị:
- mục tiêu đang hoạt động
- các cột mốc đã hoàn thành
- bằng chứng
- các trình chặn
- các quyết định
- các bản cập nhật gần đây
Khi tôi quay lại sau vài giờ, tôi có thể hiểu trạng thái của dự án mà không cần đọc mọi luồng worker. Codex cũng có thể triển khai bảng điều khiển dưới dạng một Site để nó vẫn có thể truy cập từ xa.
Tóm tắt
Tôi sử dụng cấu trúc này khi một dự án có khả năng khám phá thông tin mới, liên quan đến một số phần công việc độc lập hoặc yêu cầu bằng chứng từ nhiều hơn một môi trường.
Quy trình làm việc tuân theo một chu kỳ đơn giản. Codex biến cuộc trò chuyện ban đầu thành một lộ trình, kích hoạt một cột mốc, ủy quyền công việc và kiểm tra kết quả trước khi tiếp tục. Các luồng cục bộ xử lý các kiểm tra yêu cầu máy của tôi, trong khi các bản cập nhật và bảng điều khiển giúp tôi quay lại dự án mà không cần tái tạo mọi thứ từ đầu.
Phần quan trọng là giữ cho trạng thái dự án đủ cập nhật để quyết định tiếp theo phản ánh những gì Codex thực sự đã học được.
Hãy thử nó
Dán nội dung này vào một luồng Codex mới:
Điều phối việc này như một dự án dài hạn.
Bắt đầu bằng cách phỏng vấn tôi về những gì tôi đang cố gắng xây dựng. Hãy để tôi mô tả các ý tưởng và ràng buộc sơ bộ một cách trò chuyện, sau đó biến cuộc thảo luận đó thành một kế hoạch ban đầu.
Tạo GOALS.md làm lộ trình chung. Tổ chức nó xoay quanh các cột mốc, với kết quả dự kiến, phạm vi, quyết định, trình chặn và bằng chứng cần thiết cho mỗi cột mốc.
Thiết lập và duy trì một mục tiêu ở chế độ Goal tại một thời điểm. Mục tiêu đang hoạt động phải tương ứng với cột mốc hiện tại.
Giữ luồng này tập trung vào mục tiêu, các ràng buộc, quyết định và trạng thái dự án. Ủy quyền triển khai cho các subagent hoặc luồng mới.
Yêu cầu worker trả về kết luận, thay đổi và bằng chứng thay vì bản ghi đầy đủ.
Sử dụng các luồng riêng biệt khi tôi có thể muốn kiểm tra, tiếp tục hoặc xem xét công việc sau. Sử dụng subagent cho công việc có giới hạn không cần lịch sử hiển thị riêng.
Sau mỗi cột mốc, sử dụng một luồng riêng biệt để kiểm tra GOALS.md với trạng thái hiện tại và chạy /review trên quá trình triển khai. Cập nhật lộ trình trước khi kích hoạt mục tiêu tiếp theo.
Sử dụng các luồng cục bộ để kiểm thử Computer Use phụ thuộc vào trình duyệt, ứng dụng máy tính để bàn, quyền, thông tin xác thực hoặc trạng thái thiết bị của tôi.
*Khi trạng thái dự án thay đổi, chỉ báo cáo: - Những gì đã làm xong - Những gì tiếp theo - Bất kỳ trình chặn nào*
Duy trì progress-dashboard.html khi dự án kéo dài nhiều cột mốc hoặc worker. Không tuyên bố hoàn thành cho đến khi bằng chứng đã thỏa thuận tồn tại.
Ngoài ra, bạn cũng có thể chụp Appshot của bài viết này và yêu cầu Codex:
Tạo một kỹ năng Codex có thể tái sử dụng có tên orchestrate-projects từ bài viết này.
Giữ nguyên các phương pháp sau:
*- để Codex phỏng vấn tôi và tạo kế hoạch ban đầu - sử dụng GOALS.md làm lộ trình dựa trên cột mốc - giữ một mục tiêu ở chế độ Goal hoạt động tại một thời điểm - giữ luồng chính tập trung vào việc điều phối - kiểm tra lộ trình và chạy /review sau mỗi cột mốc - sử dụng các luồng riêng biệt cho công việc tôi có thể muốn xem lại - sử dụng các luồng cục bộ để kiểm thử Computer Use - báo cáo tiến độ thông qua các bản cập nhật ngắn gọn, Slack và progress-dashboard.html*
