การทำงานร่วมกับ Codex ในงานระยะยาว

Codex สามารถทำงานได้เป็นเวลานาน โดยเฉพาะเมื่อมี /goal ที่ให้เป้าหมายที่ชัดเจนอย่างต่อเนื่อง ส่วนที่ยากกว่าคือการรักษาทิศทางในขณะที่มันทำงานเป็นเวลาหลายชั่วโมงหรือหลายวัน ค้นพบรายละเอียดการใช้งานใหม่ๆ และผ่านการตรวจสอบหลายรูปแบบ

สมมติฐานในช่วงแรกมักจะเปลี่ยนไปเมื่อเริ่มลงมือทำจริง โมเดลการทำงานร่วมกันจำเป็นต้องรักษาเป้าหมายไว้ ในขณะที่ให้ทั้งคุณและ Codex มีพื้นที่ในการปรับเปลี่ยนแผนเมื่อมีหลักฐานใหม่ปรากฏขึ้น

ในช่วงไม่กี่สัปดาห์ที่ผ่านมา ฉันได้ใช้แนวทางปฏิบัติ 5 ข้อ:

1. ให้ Codex วางแผนงานและดูแลแผนงานหลัก
2. ให้เธรดหลักโฟกัสไปที่การประสานงาน
3. ตรวจสอบแผนงานหลักและตรวจสอบโค้ดหลังจากแต่ละเหตุการณ์สำคัญ
4. ใช้เธรดในเครื่องสำหรับการทดสอบ Computer Use
5. รายงานความคืบหน้าผ่านอัปเดตและแดชบอร์ดที่กระชับ

สร้างด้วย GPT Image 2 ใน Codex

1. ให้ Codex วางแผนงานและดูแลแผนงานหลัก

โดยปกติฉันจะเริ่มต้นด้วยการสนทนาแทนที่จะใช้โหมด /plan ฉันอธิบายสิ่งที่ฉันพยายามจะสร้าง บอกแนวคิดคร่าวๆ แบ่งปันข้อจำกัด และให้ Codex ถามคำถามจนกว่าจะมีบริบทเพียงพอที่จะเสนอแผนเริ่มต้นได้

วิธีนี้ทำให้การสนทนาในช่วงแรกมีความยืดหยุ่น ฉันไม่จำเป็นต้องเปลี่ยนความคิดที่ยังไม่เป็นรูปเป็นร่างให้เป็นข้อกำหนดที่เป็นทางการก่อนที่ Codex จะเริ่มช่วยเหลือได้ มันสามารถสัมภาษณ์ฉัน สะท้อนสิ่งที่มันเข้าใจ ระบุช่องว่าง และค่อยๆ เปลี่ยนการสนทนาให้เป็นแผนที่ใช้งานได้

เมื่อโปรเจกต์เริ่มเป็นรูปเป็นร่าง ฉันขอให้ Codex ตั้งค่า Goal ปัจจุบัน โหมด Goal จะให้เป้าหมายที่ชัดเจนอย่างต่อเนื่องแก่ Codex ทำให้มันสามารถทำงานไปสู่ผลลัพธ์เดียวกันในหลายๆ รอบจนกว่าเป้าหมายจะสำเร็จ ถูกขัดขวาง หรือถูกแทนที่

ฉันสามารถตั้งเป้าหมายเองด้วย /goal แต่ปกติฉันจะขอให้ Codex ทำ โหมด Goal จะแสดงผ่าน harness ดังนั้น Codex สามารถสังเคราะห์การสนทนาของเรา บริบทของโปรเจกต์ และทุกสิ่งที่มันได้เรียนรู้มาจนถึงตอนนี้ให้เป็นเป้าหมายที่ชัดเจน นอกจากนี้ยังสามารถกำหนดหลักฐานที่จำเป็นก่อนที่จะถือว่าเป้าหมายนั้นสำเร็จ

สำหรับโปรเจกต์ขนาดใหญ่ ฉันขอให้ Codex เขียนแผนงานหลักที่กว้างขึ้นลงใน GOALS.md นี่เป็นธรรมเนียมปฏิบัติของโปรเจกต์ ไม่ใช่ฟีเจอร์ในตัวของ Codex และสามารถตั้งชื่อไฟล์ตามที่คุณต้องการ

ฉันมักจะจัดระเบียบ GOALS.md รอบๆ เหตุการณ์สำคัญแทนที่จะเป็นรายการงานแบบราบ แต่ละเหตุการณ์สำคัญจะบันทึก:

• ผลลัพธ์ที่ตั้งใจไว้
• ขอบเขตงานปัจจุบัน
• การตัดสินใจที่สำคัญ
• อุปสรรคที่ทราบ
• หลักฐานที่จำเป็นก่อนจะดำเนินการต่อไป

Codex จะดูแลไฟล์นี้เมื่อโปรเจกต์พัฒนาไป การค้นพบใหม่อาจเปลี่ยนขอบเขตของเหตุการณ์สำคัญ เพิ่มเหตุการณ์สำคัญอื่น หรือเปลี่ยนหลักฐานที่จำเป็นสำหรับการทำให้สำเร็จ

มีวัตถุประสงค์ในโหมด Goal เพียงหนึ่งเดียวที่ทำงานอยู่ในแต่ละครั้ง เมื่อเหตุการณ์สำคัญเสร็จสมบูรณ์ Codex จะอัปเดต GOALS.md เปิดใช้งานวัตถุประสงค์ถัดไป และทำงานต่อไปจนกว่าจะสำเร็จ

2. ให้เธรดหลักโฟกัสไปที่การประสานงาน

เมื่อมีแผนงานหลักแล้ว ฉันจะให้เธรดหลักโฟกัสไปที่วัตถุประสงค์ ข้อจำกัด การตัดสินใจ และสถานะปัจจุบันของโปรเจกต์

มันจะตัดสินใจว่าสิ่งใดควรเกิดขึ้นต่อไป มอบหมายงานที่มีขอบเขต และประเมินผลลัพธ์ มันไม่จำเป็นต้องแบกรับรายละเอียดการใช้งานทุกอย่าง

ผู้ปฏิบัติงานอาจใช้เวลาหนึ่งชั่วโมงในการอ่านโค้ดที่ไม่คุ้นเคย ลองหลายวิธี หรือติดตามการทดสอบที่ล้มเหลว ผู้ประสานงานต้องการเพียงข้อมูลที่ส่งผลกระทบต่อโปรเจกต์ในวงกว้าง:

• สิ่งที่ผู้ปฏิบัติงานเรียนรู้
• สิ่งที่เปลี่ยนแปลงไป
• หลักฐานสนับสนุน
• สิ่งที่ควรเกิดขึ้นต่อไป

Codex สามารถมอบหมายงานนี้ให้กับ subagent หรือสร้างเธรดแยกต่างหาก ในทางปฏิบัติแล้ว พวกมันสามารถทำงานเดียวกันได้ ฉันใช้เธรดแยกต่างหากเมื่อฉันคาดว่าจะกลับมาทำงานนั้นอีกครั้งในภายหลัง เนื่องจากมันยังคงมองเห็นได้ในแอป Codex และมีประวัติของตัวเอง

สิ่งนี้มีประโยชน์อย่างยิ่งเมื่อมีงานหลายชิ้นทำงานแบบขนานกัน เธรดหลักสามารถประสานงานโปรเจกต์ต่อไปได้ ในขณะที่การตรวจสอบ การใช้งาน หรือการตรวจสอบแต่ละรายการยังคงตรวจสอบได้ง่าย

3. ตรวจสอบแผนงานหลักและตรวจสอบโค้ดหลังจากแต่ละเหตุการณ์สำคัญ

GOALS.md สะท้อนถึงสิ่งที่รู้เมื่อ Codex อัปเดตล่าสุด เมื่อสิ้นสุดเหตุการณ์สำคัญ โปรเจกต์มักจะค้นพบสิ่งใหม่ๆ

ก่อนที่จะดำเนินการต่อ ฉันขอให้เธรดอื่นเปรียบเทียบแผนงานหลักกับสถานะปัจจุบัน:

• เหตุการณ์สำคัญเสร็จสมบูรณ์จริงหรือไม่?
• เป้าหมายถัดไปยังคงเป็นเป้าหมายที่ถูกต้องหรือไม่?
• มีเหตุการณ์สำคัญใดที่ขาดหายไปหรือไม่?
• หลักฐานใหม่เปลี่ยนลำดับการทำงานหรือไม่?
• คำจำกัดความของ "เสร็จสิ้น" ยังคงใช้ได้หรือไม่?

ฉันจะดำเนินการตรวจสอบนี้เมื่อสิ้นสุดแต่ละเหตุการณ์สำคัญ รวมถึงเมื่อใดก็ตามที่มีหลักฐานใหม่เปลี่ยนแปลงทิศทางของโปรเจกต์อย่างมีนัยสำคัญ

ฉันยังรัน /review ในการใช้งานด้วย

สมมติว่าการใช้งานและการทดสอบระยะไกลสำหรับขั้นตอนการเข้าสู่ระบบเสร็จสมบูรณ์แล้ว การตรวจสอบแผนงานหลักอาจสังเกตว่าไม่มีใครทดสอบขั้นตอนดังกล่าวในเบราว์เซอร์ที่เข้าสู่ระบบจริง ในเวลาเดียวกัน /review อาจพบว่าเส้นทางใหม่จัดเก็บโทเค็นอย่างไม่ถูกต้องแม้ว่าการทดสอบระยะไกลจะผ่าน

ผู้ประสานงานอัปเดต GOALS.md มอบหมายให้แก้ไขโทเค็น เพิ่มการตรวจสอบเบราว์เซอร์ที่ขาดหายไป จากนั้นจึงเปิดใช้งานเหตุการณ์สำคัญถัดไป

ฉันมักจะเก็บการตรวจสอบและการทบทวนไว้ในเธรดแยกต่างหาก subagent สามารถทำงานเดียวกันได้ แต่เธรดแยกต่างหากจะทิ้งบันทึกที่มองเห็นได้ซึ่งฉันสามารถกลับมาดูได้ในภายหลัง

4. ใช้เธรดในเครื่องสำหรับการทดสอบ Computer Use

เซสชัน Codex ส่วนใหญ่ของฉันทำงานบนอินสแตนซ์ระยะไกล ดังนั้นงานจึงสามารถดำเนินต่อไปได้ในขณะที่ปิดแล็ปท็อปของฉัน การตรวจสอบบางอย่างยังคงขึ้นอยู่กับเครื่องในเครื่องของฉัน:

• เบราว์เซอร์ที่เข้าสู่ระบบ
• ข้อมูลประจำตัวในเครื่อง
• Xcode
• สิทธิ์ของ macOS
• iOS Simulator

ผู้ประสานงานระยะไกลสามารถสร้างเธรดในเครื่องสำหรับการตรวจสอบเหล่านั้น ฉันใช้ diff ระยะไกลหรือเช็คเอาท์ branch หรือ commit ที่เกี่ยวข้อง เพื่อให้เธรดในเครื่องทดสอบโค้ดที่ถูกต้อง

เธรดในเครื่องจะใช้งานเบราว์เซอร์หรือแอปพลิเคชัน และส่งคืนภาพหน้าจอ บันทึก และสิ่งที่ค้นพบ เมื่อการตรวจสอบล้มเหลว ผู้ปฏิบัติงานระยะไกลจะแก้ไขปัญหา และเธรดในเครื่องจะทดสอบอีกครั้ง

ลูปทั่วไปมีลักษณะดังนี้:

1. ผู้ปฏิบัติงานระยะไกลใช้ขั้นตอนการเข้าสู่ระบบ
2. การทดสอบระยะไกลผ่าน
3. เธรดในเครื่องใช้ Codex Chrome extension
4. การทดสอบเบราว์เซอร์เผยให้เห็นบั๊กการเปลี่ยนเส้นทาง
5. ผู้ปฏิบัติงานระยะไกลแก้ไข
6. เธรดในเครื่องทำการตรวจสอบซ้ำ

โปรเจกต์ยังคงเป็นระยะไกลโดยค่าเริ่มต้น คอมพิวเตอร์ของฉันจะเข้าร่วมเฉพาะการตรวจสอบที่จำเป็นเท่านั้น เธรดระยะไกลยังสามารถตรวจสอบต่อไปเพื่อให้เธรดในเครื่องพร้อมใช้งานอีกครั้งเมื่อฉันเปิดแล็ปท็อปอีกครั้ง

5. รายงานความคืบหน้าผ่านอัปเดตและแดชบอร์ดที่กระชับ

โดยปกติแล้วเธรดของผู้ปฏิบัติงานจะรายงานเกี่ยวกับงานเดียว เมื่อฉันกลับมาที่โปรเจกต์ ฉันต้องการมุมมองของสถานะโดยรวม:

• สิ่งที่เสร็จสมบูรณ์
• สิ่งที่เปลี่ยนแปลงไป
• สิ่งที่เหลืออยู่
• สิ่งที่ต้องการการตัดสินใจ

ฉันขอให้ Codex รายงานเมื่อใดก็ตามที่สถานะของโปรเจกต์เปลี่ยนแปลง โดยใช้สามส่วนสั้นๆ:

**สิ่งที่ทำเสร็จแล้ว

สิ่งที่ต้องทำต่อไป

อุปสรรคใดๆ**

ซึ่งเกือบจะเหมือนกับการมี daily standup กับ Codex แม้จะเป็นรายชั่วโมงก็ตาม

Codex สามารถส่งอัปเดตเดียวกันผ่าน Slack ไม่ว่าจะเป็นข้อความโดยตรงหรือในช่องโปรเจกต์โดยเฉพาะ

ในขณะที่ฉันอยู่ในแอป Codex ฉันยังใช้ /side เพื่อตรวจสอบโดยไม่รบกวนเธรดหลัก จากเธรดด้านข้าง ฉันสามารถขอสรุปสิ่งที่ทำเสร็จแล้ว สิ่งที่เหลืออยู่ และมีอะไรที่ต้องการความช่วยเหลือจากฉันหรือไม่ เช่น การคลิกด้วยตนเอง การอนุมัติ หรือ clickops อื่นๆ

รับสรุปจากเธรดด้านข้าง

ขอให้เธรดด้านข้างส่งคำแนะนำของฉันไปยังเธรดหลัก

จากนั้นฉันสามารถชี้แจงคำแนะนำ แก้ไขอุปสรรค เพิ่มบริบท หรือขอให้เธรดด้านข้างส่งคำแนะนำที่อัปเดตกลับไปยังเธรดหลัก

สำหรับโปรเจกต์ที่มีหลายเหตุการณ์สำคัญหรือสายงานแบบขนาน ฉันยังคงรักษา progress-dashboard.html นี่คือสิ่งประดิษฐ์ของโปรเจกต์ที่กำหนดเอง ไม่ใช่ UI ในตัวของ Codex มันสามารถแสดง:

• เป้าหมายที่ใช้งานอยู่
• เหตุการณ์สำคัญที่เสร็จสมบูรณ์
• หลักฐาน
• อุปสรรค
• การตัดสินใจ
• อัปเดตล่าสุด

เมื่อฉันกลับมาหลังจากหลายชั่วโมง ฉันสามารถเข้าใจสถานะของโปรเจกต์ได้โดยไม่ต้องอ่านทุกเธรดของผู้ปฏิบัติงาน Codex ยังสามารถปรับใช้แดชบอร์ดเป็น Site เพื่อให้สามารถเข้าถึงได้จากระยะไกล

สรุป

ฉันใช้โครงสร้างนี้เมื่อโปรเจกต์มีแนวโน้มที่จะค้นพบข้อมูลใหม่ เกี่ยวข้องกับงานอิสระหลายชิ้น หรือต้องการหลักฐานจากมากกว่าหนึ่งสภาพแวดล้อม

ขั้นตอนการทำงานเป็นไปตามวงจรง่ายๆ Codex เปลี่ยนการสนทนาเริ่มต้นเป็นแผนงานหลัก เปิดใช้งานหนึ่งเหตุการณ์สำคัญ มอบหมายงาน และตรวจสอบผลลัพธ์ก่อนดำเนินการต่อ เธรดในเครื่องจัดการการตรวจสอบที่ต้องใช้เครื่องของฉัน ในขณะที่อัปเดตและแดชบอร์ดช่วยให้ฉันกลับมาที่โปรเจกต์ได้โดยไม่ต้องสร้างทุกอย่างขึ้นมาใหม่ตั้งแต่ต้น

ส่วนสำคัญคือการทำให้สถานะของโปรเจกต์เป็นปัจจุบันพอที่การตัดสินใจครั้งต่อไปจะสะท้อนถึงสิ่งที่ Codex ได้เรียนรู้จริงๆ

ลองดู

วางสิ่งนี้ในเธรด Codex ใหม่:

ประสานงานโปรเจกต์ระยะยาวนี้

เริ่มต้นด้วยการสัมภาษณ์ฉันเกี่ยวกับสิ่งที่ฉันพยายามจะสร้าง ให้ฉันอธิบายแนวคิดและข้อจำกัดคร่าวๆ ผ่านการสนทนา จากนั้นเปลี่ยนการสนทนานั้นเป็นแผนเริ่มต้น

สร้าง GOALS.md เป็นแผนงานหลักที่ใช้ร่วมกัน จัดระเบียบรอบๆ เหตุการณ์สำคัญ โดยมีผลลัพธ์ที่ตั้งใจไว้ ขอบเขต การตัดสินใจ อุปสรรค และหลักฐานที่จำเป็นสำหรับแต่ละเหตุการณ์

ตั้งค่าและรักษาวัตถุประสงค์ในโหมด Goal ไว้ทีละรายการ วัตถุประสงค์ที่ใช้งานอยู่ควรสอดคล้องกับเหตุการณ์สำคัญปัจจุบัน

ให้เธรดนี้โฟกัสไปที่วัตถุประสงค์ ข้อจำกัด การตัดสินใจ และสถานะของโปรเจกต์ มอบหมายการใช้งานให้กับ subagent หรือเธรดใหม่

กำหนดให้ผู้ปฏิบัติงานส่งคืนข้อสรุป การเปลี่ยนแปลง และหลักฐาน แทนที่จะเป็นบันทึกการสนทนาทั้งหมด

ใช้เธรดแยกต่างหากเมื่อฉันอาจต้องการตรวจสอบ ดำเนินการต่อ หรือตรวจสอบงานในภายหลัง ใช้ subagent สำหรับงานที่มีขอบเขตซึ่งไม่ต้องการประวัติที่มองเห็นได้ของตัวเอง

หลังจากแต่ละเหตุการณ์สำคัญ ให้ใช้เธรดแยกต่างหากเพื่อตรวจสอบ GOALS.md กับสถานะปัจจุบัน และรัน /review ในการใช้งาน อัปเดตแผนงานหลักก่อนเปิดใช้งานวัตถุประสงค์ถัดไป

ใช้เธรดในเครื่องสำหรับการทดสอบ Computer Use ที่ขึ้นอยู่กับเบราว์เซอร์ แอปพลิเคชันเดสก์ท็อป สิทธิ์ ข้อมูลประจำตัว หรือสถานะอุปกรณ์ของฉัน

*เมื่อสถานะของโปรเจกต์เปลี่ยนแปลง ให้รายงานเฉพาะ: - สิ่งที่ทำเสร็จแล้ว - สิ่งที่ต้องทำต่อไป - อุปสรรคใดๆ*

ดูแลรักษา progress-dashboard.html เมื่อโปรเจกต์ครอบคลุมหลายเหตุการณ์สำคัญหรือผู้ปฏิบัติงาน อย่าประกาศว่าเสร็จสมบูรณ์จนกว่าจะมีหลักฐานที่ตกลงกันไว้

หรืออีกทางหนึ่ง คุณยังสามารถใช้ Appshot ของบทความนี้และถาม Codex:

สร้างทักษะ Codex ที่ใช้ซ้ำได้ชื่อว่า orchestrate-projects จากบทความนี้

รักษาแนวทางปฏิบัติเหล่านี้:

*- ให้ Codex สัมภาษณ์ฉันและสร้างแผนเริ่มต้น - ใช้ GOALS.md เป็นแผนงานหลักตามเหตุการณ์สำคัญ - รักษาวัตถุประสงค์ในโหมด Goal ไว้ทีละรายการ - ให้เธรดหลักโฟกัสไปที่การประสานงาน - ตรวจสอบแผนงานหลักและรัน /review หลังจากแต่ละเหตุการณ์สำคัญ - ใช้เธรดแยกต่างหากสำหรับงานที่ฉันอาจต้องการกลับมาดู - ใช้เธรดในเครื่องสำหรับการทดสอบ Computer Use - รายงานความคืบหน้าผ่านอัปเดตที่กระชับ, Slack และ progress-dashboard.html*