เมื่อวันที่ 23 มิถุนายน 2026 เขียนโดย Thomas Ricouard เนื้อหาอธิบายว่า Codex Remote ไม่ได้มีไว้เพียงเปิดโทรศัพท์ขึ้นมาตรวจว่า AI เขียนโค้ดเสร็จหรือยัง แต่ถูกออกแบบให้โทรศัพท์กลายเป็นศูนย์ควบคุมงานที่กำลังทำงานอยู่บนเครื่องพัฒนา ไม่ว่าจะเป็น Mac, Windows, Devbox หรือเครื่องอื่นที่เชื่อมต่อไว้
แนวคิดสำคัญคือ โทรศัพท์ไม่จำเป็นต้องกลายเป็น Terminal ขนาดเล็ก เพราะงานประมวลผลและการแก้ไขโค้ดยังคงเกิดขึ้นบนคอมพิวเตอร์ โทรศัพท์มีหน้าที่ช่วยให้วิศวกรเริ่มงาน กำหนดทิศทาง อนุมัติคำสั่ง ตรวจสอบโค้ด และจัดระเบียบงานได้จากทุกที่
Codex Remote คืออะไร
Codex Remote คือส่วนหนึ่งของระบบ Codex ที่ช่วยให้ผู้ใช้เชื่อมต่อไปยังเครื่องพัฒนาของตนเองผ่านโทรศัพท์ จากนั้นจึงสั่ง Codex ให้ทำงานกับ Repository, Workspace, Branch หรือ Worktree ที่อยู่บนเครื่องนั้น
ในช่วงสองเดือนก่อนบทความนี้เผยแพร่ OpenAI เพิ่มความสามารถหลายด้าน เช่น
- การเชื่อมต่อ Remote Host
- การสร้างและเลือก Worktree
- การตั้ง Goal ระยะยาว
- Side Chat สำหรับถามคำถามแยก
- การตรวจ Diff และแสดงความคิดเห็นในโค้ด
- การส่งคำสั่งแบบ Queue และ Steer
- การแนบไฟล์ ภาพ และรูปจากกล้อง
- การเรียกใช้ Skills และ Plugins
- การจัดเก็บ Thread ที่จบแล้ว
- การตั้งค่าความปลอดภัยและสิทธิ์อนุมัติ
เมื่อใช้ความสามารถเหล่านี้ร่วมกัน Codex Remote จึงมีลักษณะคล้าย “โต๊ะควบคุมงานวิศวกรรม” มากกว่าแอปสำหรับเปิดดูสถานะงาน
แนวคิดที่ถูกต้อง โทรศัพท์คือ Control Plane
โค้ดยังคงทำงานอยู่บนเครื่องที่เหมาะสม เช่น เครื่อง Mac ที่มี Xcode, เครื่อง Windows ที่มีเครื่องมือเฉพาะ หรือ Devbox ที่ตั้งค่าสภาพแวดล้อมไว้แล้ว
Codex Remote ทำหน้าที่เป็น Control Plane หรือชั้นควบคุม ซึ่งช่วยให้ผู้ใช้ตัดสินใจเรื่องสำคัญ เช่น
- จะใช้ Repository และ Workspace ใด
- จะทำงานบน Branch ปัจจุบันหรือสร้าง Worktree ใหม่
- ข้อความถัดไปควรรอให้ Codex ทำงานเสร็จก่อนหรือควรแทรกเพื่อเปลี่ยนทิศทางทันที
- คำสั่งที่ Codex ขออนุมัติมีความปลอดภัยหรือไม่
- Codex แก้ไขไฟล์อะไร และการแก้ไขนั้นถูกต้องหรือไม่
- งานนี้ควรกลายเป็น Goal ระยะยาว ควรแยกเป็น Thread ใหม่ หรือควรถามผ่าน Side Chat
ดังนั้น Codex Remote ไม่ได้พยายามย่อหน้าจอ Desktop มาไว้บนโทรศัพท์ แต่เลือกนำเฉพาะการตัดสินใจที่จำเป็นต่อการควบคุม Agent มาแสดงให้ใช้งานได้ง่าย
1. เริ่มต้นงานด้วยขอบเขตที่ถูกต้อง
งานของ Coding Agent จะออกมาดีหรือไม่ เริ่มจากการเลือกสภาพแวดล้อมให้ถูกต้องตั้งแต่ต้น
ก่อนส่ง Prompt แรก Codex Remote เปิดให้ผู้ใช้เลือกได้ว่า
- จะเชื่อมต่อ Host เครื่องใด
- จะใช้ Repository หรือ Workspace ใด
- จะเริ่มจาก Branch ไหน
- จะทำงานใน Checkout ปัจจุบันหรือสร้าง Worktree แยก
- จะเรียกขั้นตอนตั้งค่า Environment ก่อนเริ่มทำงานหรือไม่
เลือก Current Checkout เมื่อใด
เหมาะกับงานสั้น ๆ เช่น
- ตรวจสอบสาเหตุของ Error
- อ่านและอธิบายโค้ด
- ค้นหาว่าฟังก์ชันหนึ่งถูกเรียกจากที่ใด
- ตรวจสอบผลกระทบของการเปลี่ยนแปลง
สร้าง Worktree ใหม่เมื่อใด
เหมาะกับงานที่ต้องแก้ไขโค้ดจริง และไม่ต้องการให้กระทบกับงานที่เปิดอยู่ เช่น
- สร้างฟีเจอร์ใหม่
- แก้ Bug ที่ต้องทดลองหลายแนวทาง
- Refactor โครงสร้างขนาดใหญ่
- ทำงานหลาย Feature พร้อมกัน
- ต้องการแยกสถานะ Git ของแต่ละงาน
การใช้เวลาไม่กี่วินาทีเลือก Host, Branch และ Worktree ให้ถูกต้อง สามารถลดเวลาที่ต้องย้อนกลับมาแก้ Git State หรือเก็บกวาดไฟล์ภายหลังได้มาก
เพิ่ม Context ตั้งแต่ Prompt แรก
ช่องเขียน Prompt ของ Codex Remote รองรับมากกว่าข้อความ ผู้ใช้สามารถแนบได้ทั้ง
- ไฟล์
- ภาพหน้าจอ
- ภาพถ่ายจากกล้อง
- Skills
- Plugins
ตัวอย่างเช่น หากพบปัญหาหน้าจอแสดงผลผิดบนโทรศัพท์ แทนที่จะอธิบายด้วยข้อความยาว ๆ สามารถแนบ Screenshot แล้วระบุว่า
ตรวจสอบหน้าจอนี้ เปรียบเทียบกับโค้ดใน mobile package และหาสาเหตุที่ปุ่มด้านล่างถูกตัดออก
หลักคิดคือ หากไฟล์ ภาพ หรือ Skill ที่ระบุชื่อชัดเจนช่วยลดความกำกวมได้ ก็ควรส่งไปพร้อม Prompt แรก ไม่ควรรอให้ Codex เข้าใจผิดก่อนแล้วจึงค่อยแก้คำสั่ง
2. เข้าใจความแตกต่างระหว่าง Queue และ Steer
เมื่อ Codex กำลังทำงานอยู่ ผู้ใช้สามารถส่งข้อความติดตามได้สองรูปแบบ ได้แก่ Queue และ Steer
Queue คือสั่งงานต่อหลังจากงานปัจจุบันเสร็จ
Queue จะเก็บ Prompt ใหม่ไว้ก่อน เมื่อ Codex ตอบงานปัจจุบันเสร็จ ระบบจึงส่ง Prompt นั้นเป็นข้อความลำดับถัดไป
เหมาะกับสถานการณ์ เช่น
- ขอให้เพิ่ม Test หลังจากแก้โค้ดเสร็จ
- ขอให้เขียนเอกสารประกอบ
- ให้ตรวจ Lint และ Type Check
- มอบหมายงานถัดไปซึ่งไม่กระทบการคิดปัจจุบัน
- ขอให้สรุปสิ่งที่เปลี่ยนแปลงหลังงานจบ
ตัวอย่าง:
หลังจากแก้ปัญหาเสร็จแล้ว ให้เพิ่ม Regression Test สำหรับกรณี Reconnect ด้วย
OpenAI แนะนำให้ใช้ Queue เป็นค่าเริ่มต้น เพราะลดความเสี่ยงที่ข้อความใหม่จะรบกวนเหตุผลหรือแผนงานที่ Codex กำลังดำเนินอยู่
Steer คือเปลี่ยนทิศทางของงานที่กำลังทำ
Steer จะแทรกคำแนะนำเข้าไปใน Turn ที่ Codex กำลังทำอยู่ เหมาะกับกรณีที่เห็นว่า Codex กำลังเดินผิดทาง และยิ่งปล่อยให้ทำต่อก็ยิ่งเสียเวลา
ตัวอย่างจากบทความ ได้แก่
ให้แก้เฉพาะใน mobile package อย่า Refactor shared renderer
ปัญหาเกิดหลัง Reconnect เท่านั้น ให้ทดสอบเส้นทาง Resume ไม่ใช่เส้นทาง Live
หยุดตรวจฝั่ง UI แล้วตรวจว่าฝั่ง Server ลบรายการระหว่าง Resume หรือไม่
Steer จึงไม่ใช่ข้อความติดตามธรรมดา แต่เป็นการแทรกแซงการทำงานที่กำลังเกิดขึ้น ผู้ใช้ควรใช้เมื่อจำเป็นจริง ๆ เพราะการเปลี่ยนคำสั่งกลางทางอาจทำให้ Codex ทิ้งแนวทางเดิม เปลี่ยนสมมติฐาน หรือแก้ไขโค้ดไม่ครบตามแผนเดิม
หลักตัดสินใจง่าย ๆ
ใช้ Queue เมื่อข้อความมีความหมายว่า “ทำสิ่งนี้ต่อด้วย”
ใช้ Steer เมื่อข้อความมีความหมายว่า “หยุดแนวทางปัจจุบัน แล้วเปลี่ยนไปทำแบบนี้ทันที”
3. ใช้ Side Chat เป็นกิ่งความคิดแยกจากงานหลัก
Thread ที่ทำงานต่อเนื่องเป็นเวลานานจะสะสม Context ที่สำคัญ เช่น
- เป้าหมายของงาน
- ข้อจำกัดทางสถาปัตยกรรม
- ไฟล์ที่แก้ไปแล้ว
- ผลการทดสอบ
- เหตุผลที่เลือกแนวทางหนึ่ง
- Feedback จากการ Review
หากแทรกทุกคำถามลงใน Main Thread งานหลักจะเริ่มมีบทสนทนาที่ไม่เกี่ยวข้องปะปน และอาจทำให้ Codex หลุดจากวัตถุประสงค์เดิม
Side Chat ถูกสร้างขึ้นเพื่อแก้ปัญหานี้
ผู้ใช้เปิด Side Chat ได้ด้วยคำสั่ง
/side
หรือเปิดพร้อมคำถามทันทีด้วย
/side <คำถาม>
นอกจากนี้ยังสามารถเลือกข้อความบางส่วนจากบทสนทนา แล้วใช้คำสั่ง “Ask in side chat” เพื่อให้ข้อความที่เลือกกลายเป็น Context เริ่มต้นของบทสนทนาใหม่
Side Chat เหมาะกับคำถามแบบใด
- ทำไม Codex จึงเลือก Architecture แบบนี้
- Error นี้หมายถึงอะไร
- พฤติกรรมนี้เหมือนกับ Desktop App หรือไม่
- ช่วยแปลงรายละเอียดทางเทคนิคเป็น Release Note
- ก่อนอนุมัติคำสั่งนี้ควรตรวจสอบอะไร
- Library ที่ Codex เลือกมีข้อจำกัดอะไร
- วิธีแก้แบบนี้มีผลกระทบด้าน Performance หรือไม่
บทความสรุปความแตกต่างไว้อย่างชัดเจนว่า Main Thread เป็นเจ้าของ “งาน” ส่วน Side Chat มีหน้าที่ช่วยให้ผู้ใช้ “เข้าใจงาน”
4. ใช้ Plan สำหรับเส้นทาง และใช้ Goal สำหรับผลลัพธ์
Plan Mode และ Goal ดูคล้ายกัน แต่ทำหน้าที่คนละอย่าง
Plan Mode ตอบว่าจะทำอย่างไร
Plan Mode ขอให้ Codex เสนอแนวทางก่อนแก้ไขโค้ด เหมาะกับงานที่
- รายละเอียดไม่ครบ
- มีความเสี่ยง
- เกี่ยวข้องกับหลายระบบ
- อาจกระทบ API หรือข้อมูลเดิม
- ต้องเลือกระหว่างหลายสถาปัตยกรรม
- ต้องการให้มนุษย์ตรวจขอบเขตก่อนลงมือ
ตัวอย่าง Prompt:
วางแผนการเพิ่ม Offline Sync โดยยังไม่แก้โค้ด อธิบายไฟล์ที่ต้องแก้ ความเสี่ยงต่อข้อมูลเดิม และแนวทาง Migration
Goal ตอบว่าเมื่อใดจึงถือว่างานเสร็จ
Goal เป็นวัตถุประสงค์ที่คงอยู่ข้ามหลาย Turn ทำให้ผู้ใช้ไม่ต้องอธิบายเป้าหมายเดิมซ้ำทุกครั้ง
สามารถสร้างหรือจัดการ Goal ด้วยคำสั่ง
/goal <objective>
ตัวอย่าง Goal ที่ชัดเจน:
/goal แก้ปัญหา Reconnect ให้สำเร็จ โดย Test เดิมทั้งหมดต้องผ่าน เพิ่ม Regression Test และไม่แก้ shared renderer
Goal ที่ดีควรมีเงื่อนไขตรวจสอบได้ เช่น
- Test ผ่านทั้งหมด
- CI เป็นสีเขียว
- Review Feedback ถูกแก้ครบ
- Performance ถึงค่าที่กำหนด
- Bug สามารถ Reproduce ก่อนแก้และไม่เกิดหลังแก้
- ไม่มีการเปลี่ยน Public API
Workflow ที่แนะนำ
- เริ่มด้วย Plan Mode เมื่องานซับซ้อนหรือมีความเสี่ยง
- ตรวจสอบแผน ขอบเขต และไฟล์ที่ Codex จะเปลี่ยน
- เมื่อยอมรับแผนแล้ว ให้เปลี่ยนผลลัพธ์ที่ต้องการเป็น Goal
- ปล่อยให้ Codex ทำ Implementation, Test, แก้ Review Feedback และ Cleanup ต่อเนื่อง
- ตรวจความคืบหน้าจาก Goal โดยไม่ต้องส่งคำถามเดิมซ้ำ
กล่าวอีกแบบคือ Plan ตอบคำถามว่า “เราควรเดินไปทางไหน” ส่วน Goal ตอบว่า “ต้องเกิดผลลัพธ์อะไรจึงถือว่าจบ”
5. Review โค้ดได้โดยไม่ต้องออกจากบทสนทนา
Codex Remote แสดงสรุปไฟล์ที่เปลี่ยนแปลงหลังจาก Codex ทำงานเสร็จ ผู้ใช้สามารถเปิด Diff และตรวจโค้ดจากโทรศัพท์ได้
ความสามารถในการ Review ประกอบด้วย
- ดูรายชื่อไฟล์ที่ถูกแก้
- เปิด Diff ของแต่ละไฟล์
- ขยายหรือย่อส่วนของ Diff
- ตัดบรรทัดยาวให้เหมาะกับหน้าจอเล็ก
- เปิด Source File พร้อม Syntax Highlighting
- แสดงความคิดเห็นตรงบรรทัดที่ต้องการ
- ส่ง Inline Comment กลับไปให้ Codex แก้ไข
- Review การเปลี่ยนแปลงในเครื่อง
- เปรียบเทียบกับ Branch ที่กำหนด
- เชื่อมไฟล์กลับเข้าไปใน Chat เพื่อให้ Codex วิเคราะห์เจาะจง
Mobile Review Loop
วงจรการ Review สามารถเกิดขึ้นได้ดังนี้
- Codex ทำ Implementation เสร็จ
- ผู้ใช้เปิด Diff จากโทรศัพท์
- ผู้ใช้ใส่ Inline Comment ในสองตำแหน่ง
- Codex แก้ไขตาม Comment ภายใน Thread เดิม
- ผู้ใช้ตรวจเฉพาะ Diff รอบใหม่ที่มีขนาดเล็กลง
โทรศัพท์ไม่สามารถแทนจอขนาดใหญ่สำหรับการอ่านโค้ดเชิงลึกได้ทั้งหมด แต่การ Review จำนวนมากติดอยู่เพียงการตัดสินใจหนึ่งหรือสองจุด เช่น ควรเปลี่ยนชื่อฟังก์ชันหรือไม่ ควรเพิ่ม Null Check ตรงไหน หรือการแก้ไขออกนอกขอบเขตหรือเปล่า
Codex Remote ช่วยให้การตัดสินใจเหล่านี้ไม่ต้องรอจนเจ้าของงานกลับมานั่งหน้าเครื่อง
6. มอง Permissions เป็นส่วนหนึ่งของ Workflow
การควบคุมงานจากระยะไกลจะมีประโยชน์ก็ต่อเมื่อผู้ใช้ยังควบคุมสิ่งที่ Codex สามารถทำได้อย่างชัดเจน
Codex Remote จะแสดงคำขออนุมัติสำหรับการทำงานหลายประเภท เช่น
- การรันคำสั่ง
- การเปลี่ยนแปลงไฟล์
- การเข้าถึงเครือข่าย
- การใช้เครื่องมือที่เชื่อมต่อ
- การทำงานที่อยู่นอกขอบเขต Permission ปัจจุบัน
บางคำขอสามารถอนุมัติได้หลายระดับ เช่น
- อนุมัติเพียงครั้งเดียว
- อนุมัติสำหรับ Chat ปัจจุบัน
- อนุมัติในขอบเขตที่กว้างขึ้นตามการตั้งค่าของ Host
หลักปฏิบัติที่บทความแนะนำไม่ใช่การกดอนุมัติทุกอย่าง แต่คือการเลือก Permission ที่แคบที่สุดซึ่งยังทำให้งานเดินหน้าต่อได้
กรณีที่อาจอนุมัติระดับ Chat
- เป็นคำสั่งที่เข้าใจชัดเจน
- อยู่ใน Repository ที่เชื่อถือได้
- Codex จำเป็นต้องรันคำสั่งเดิมซ้ำหลายครั้ง
- ขอบเขตของผลกระทบถูกจำกัดไว้แล้ว
กรณีที่ควรอนุมัติเพียงครั้งเดียวหรือปฏิเสธ
- ไม่รู้จักคำสั่งนั้น
- Repository มีข้อมูลอ่อนไหว
- คำสั่งอาจแก้หรือลบไฟล์จำนวนมาก
- ผลกระทบยังไม่ชัดเจน
- Codex ขอ Network Access โดยไม่มีเหตุผลเพียงพอ
- มีวิธีที่ปลอดภัยกว่า
ผู้ใช้สามารถปฏิเสธคำขอ แล้วให้ Codex อธิบายคำสั่งหรือเสนอวิธีที่จำกัดความเสี่ยงมากกว่าเดิมได้
7. จัดการ Context ก่อนที่จะกลายเป็นปัญหา
Thread ของ Agent มี State และสะสม Context ไปเรื่อย ๆ เมื่อบทสนทนายาวมากขึ้น Codex อาจทำงานช้าลง ให้ความสำคัญกับข้อมูลผิดส่วน หรือหลุดจากวัตถุประสงค์หลัก
Codex Remote มีคำสั่งสำหรับจัดการวงจรชีวิตของ Context ดังนี้
/status
ใช้ตรวจสอบข้อมูล Session เช่น
- Workspace ปัจจุบัน
- รายละเอียด Environment
- ปริมาณ Context ที่ใช้
- Rate Limit ที่ระบบเปิดเผย
- สถานะของการเชื่อมต่อ
/status
/compact
ใช้ย่อ Context ของ Thread ที่ยาวเกินไป โดยพยายามเก็บสถานะการทำงานและข้อมูลสำคัญไว้
/compact
เหมาะเมื่อเป้าหมายเดิมยังเหมือนเดิม แต่บทสนทนามีรายละเอียดสะสมมากเกินไป
/fork
สร้าง Primary Thread ใหม่โดยสืบทอดประวัติจาก Thread ปัจจุบัน
/fork
เหมาะเมื่อ Context เดิมยังมีประโยชน์ แต่ทิศทางของงานเริ่มแยกออกไป เช่น จากการแก้ Bug พบว่าควรสร้างงาน Refactor แยกต่างหาก
ลำดับการตัดสินใจ
- ตรวจ
/statusเมื่อสงสัยว่า Context เริ่มมากเกินไป - ใช้
/compactเมื่อยังทำเป้าหมายเดิม - ใช้
/forkเมื่อกำลังเปลี่ยนไปสู่เป้าหมายหลักใหม่
Side Chat และ Fork จึงไม่ควรใช้แทนกัน Side Chat มีไว้ถามคำถามประกอบงานปัจจุบัน ส่วน Fork คือการสร้างสายงานหลักอีกสายหนึ่งที่รับประวัติเดิมติดมาด้วย
8. จัด Thread Desk ให้สะอาด
เมื่อใช้ Codex ทำงานหลายเรื่องพร้อมกัน รายการ Thread อาจกลายเป็นเหมือนโต๊ะทำงานที่มีเอกสารกองเต็ม หากไม่จัดระเบียบ ผู้ใช้จะเริ่มไม่รู้ว่า Thread ใดกำลังทำงาน Thread ใดรอ Review และ Thread ใดจบแล้ว
แนวทางจากผู้เขียนคือ
- Pin เฉพาะ Thread ที่กำลังเคลื่อนไหว
- เปลี่ยนชื่อ Thread ตามผลลัพธ์ ไม่ใช่คำสั่งกว้าง ๆ
- Archive Thread อย่างสม่ำเสมอเมื่องานเสร็จ
- ใช้ Archived Thread สำหรับค้นย้อนหลัง
- เปิดงานจาก Completion Notification โดยตรง
ตัวอย่างชื่อ Thread ที่ไม่ชัดเจน:
Fix bug
ตัวอย่างชื่อที่บอกผลลัพธ์ได้ดีกว่า:
Resolve iOS reconnect item disappearance
หรือ
Prepare v4.2 release and clear review feedback
การ Archive ในที่นี้เป็นการจัดระเบียบ ไม่ใช่การลบ ผู้ใช้ยังสามารถกลับไปเปิด Thread เก่าได้ภายหลัง
บน iPad ยังรองรับ Keyboard Shortcut สำหรับงาน เช่น
- สร้าง Thread ใหม่
- สลับระหว่าง Thread
- เปิด Changed Files
- Pin
- Rename
- Archive
มุมมองนี้ทำให้ Codex Remote มีบทบาทคล้าย Chief of Staff ที่ช่วยบอกว่างานใดกำลังเดินหน้า งานใดติดขัด งานใดรอมนุษย์ Review และงานใดเสร็จแล้ว
9. Command Palette ที่ซ่อนอยู่หลังเครื่องหมาย /
เมื่อพิมพ์เครื่องหมาย / ระบบจะแสดงคำสั่งขั้นสูงที่มีให้ใช้งาน ความพร้อมของแต่ละคำสั่งอาจขึ้นอยู่กับ Host, เวอร์ชันแอป และการตั้งค่าบัญชี
/plan
เปิดหรือปิด Plan Mode ก่อนเริ่มแก้ไขโค้ด
/plan
/goal <objective>
สร้างหรืออัปเดต Objective ที่ต้องดำเนินต่อเนื่อง
/goal ทำให้ Test ผ่านทั้งหมดและแก้ Review Feedback ให้ครบ
/side [question]
เปิดบทสนทนาเสริมโดยไม่รบกวน Main Thread
/side ทำไมการแก้แบบนี้จึงต้องเพิ่ม Cache Layer
/review
Review การเปลี่ยนแปลงในเครื่อง หรือเปรียบเทียบกับ Branch
/review
/status
ตรวจ Session, Workspace, Context และ Rate Limit
/status
/compact
ย่อ Context ของ Thread ที่ยาว
/compact
/fork
สร้าง Primary Thread ใหม่จากประวัติของ Thread ปัจจุบัน
/fork
/fast
สลับระหว่างการประมวลผลมาตรฐานกับโหมดที่เร็วกว่า ในกรณีที่บัญชีและระบบรองรับ
/fast
/feedback
ส่ง Feedback เกี่ยวกับผลิตภัณฑ์โดยผูกกับ Session ปัจจุบัน
/feedback
ชุดคำสั่งนี้สะท้อน Workflow หลักของ Codex Remote ได้แก่ วางแผน ตั้งเป้าหมาย แยกสายความคิด ตรวจงาน ดูสถานะ และกู้การทำงานเมื่อ Context เริ่มไม่เหมาะสม
10. ห้า Workflow ที่เหมาะกับการทำผ่านโทรศัพท์
Workflow ที่ 1 ผู้ควบคุมการ Release
สร้าง Thread เฉพาะสำหรับ Release หรือ Pull Request แล้วให้ Codex ตรวจสอบ
- Branch ปัจจุบัน
- สถานะ CI
- Review Feedback ที่ยังไม่ถูกแก้
- รายการเปลี่ยนแปลงที่จะรวมใน Release
- Release Note
- ความพร้อมก่อน Merge หรือ Deploy
Pin Thread นี้ไว้ เมื่อมีข้อมูลใหม่ ให้ใช้ Steer เฉพาะเมื่อข้อมูลนั้นทำให้แนวทางปัจจุบันผิด ส่วนงานเพิ่มเติมที่ทำภายหลังให้ใช้ Queue
เมื่อ Release เสร็จแล้วจึง Archive Thread
Workflow ที่ 2 แก้ Bug ที่เข้ามากะทันหัน
แนบ Screenshot, Log หรือไฟล์ที่เกี่ยวข้อง แล้วสั่งให้ Codex วิเคราะห์ก่อนแก้ไข
ตัวอย่าง:
วิเคราะห์สาเหตุก่อน ห้ามแก้ไฟล์จนกว่าจะอธิบายเส้นทางที่ทำให้เกิดปัญหาได้
หากพบ Error ที่น่าสงสัย ให้เปิด Side Chat เพื่อถามรายละเอียดโดยไม่รบกวนการสืบสวนหลัก เมื่อยืนยันสาเหตุแล้วจึงกลับไป Main Thread และอนุมัติการแก้ไขเฉพาะจุด
Workflow ที่ 3 Mobile Reviewer
ให้ Codex Review เทียบกับ Branch ที่ตั้งใจไว้ จากนั้น
- ตรวจ Changed-File Summary
- เปิดเฉพาะไฟล์สำคัญ
- ใส่ Inline Comment
- สั่งให้ Codex แก้เฉพาะ Comment เหล่านั้น
- ตรวจ Follow-up Diff ซึ่งมีขนาดเล็กกว่าเดิม
วิธีนี้ช่วยป้องกัน Codex ใช้ Feedback เล็กน้อยเป็นเหตุผลในการ Refactor ส่วนอื่นเกินความจำเป็น
Workflow ที่ 4 เป้าหมายระยะยาว
ตั้ง Goal ที่มีเงื่อนไขจบชัดเจน เช่น
- Test ผ่านทั้งหมด
- Review Feedback ถูกแก้ครบ
- Performance ผ่านค่าที่กำหนด
- ไม่สามารถ Reproduce Bug ได้อีก
- CI ผ่านบนทุก Platform
ติดตามความคืบหน้าผ่าน Notification และ /status แทนการถามซ้ำว่า “เสร็จหรือยัง”
ใช้ Queue เมื่อต้องการเพิ่มงานต่อท้าย และเก็บ Steer ไว้ใช้เฉพาะการแก้ทิศทางที่ผิด
Workflow ที่ 5 ควบคุมหลายเครื่อง
ตั้งชื่อ Host ให้เข้าใจง่าย เช่น
- MacBook-iOS
- Windows-GameBuild
- Linux-Backend
- Devbox-Staging
จากนั้นเลือกเครื่องตามความพร้อมของ
- Source Code
- Credentials
- Simulator
- Operating System
- SDK
- เครื่องมือ Build
- Environment เฉพาะ
ตัวอย่างเช่น งานหนึ่งอาจต้องใช้ Mac เพื่อ Build แอป iOS ขณะที่อีกงานต้องใช้ Windows เพื่อทดสอบโปรแกรมเฉพาะแพลตฟอร์ม ผู้ใช้สามารถเริ่มและติดตามทั้งสองงานจากโทรศัพท์เครื่องเดียว
ฟีเจอร์เล็กที่ช่วยลดแรงเสียดทาน
บทความกล่าวถึงความสามารถขนาดเล็กหลายอย่างที่อาจไม่ใช่ฟีเจอร์หลัก แต่ช่วยให้ Workflow ใช้งานจริงได้ราบรื่นขึ้น ได้แก่
- แก้ไข Prompt ล่าสุดที่ส่งไป แทนการส่งข้อความแก้ต่างหาก
- บันทึกหรือคัดลอกภาพที่ Codex สร้างจากงาน
- มองเห็น Prompt ที่อยู่ใน Queue ขณะ Codex ยังทำงาน
- เปิด Task ที่เสร็จแล้วจาก Notification
- เรียกดู Archived Thread
- Wrap บรรทัด Diff ที่ยาวบนหน้าจอแคบ
- ล็อก Codex ด้วย Face ID หรือรหัสผ่านเครื่อง
- ตรวจว่า Prompt กำลังเรียก Skill หรือ Plugin ใดก่อนส่ง
- ถ่ายภาพจากกล้องแล้วแนบเข้า Prompt โดยตรง
- เลือกข้อความใน Transcript แล้วเปิด Side Chat จากข้อความนั้น
ฟีเจอร์เหล่านี้ไม่ได้เปลี่ยนวิธีคิดพื้นฐานของ Agent แต่ช่วยลดขั้นตอนเล็ก ๆ ที่ทำให้การควบคุมงานจากระยะไกลรู้สึกยุ่งยากหรือไม่น่าเชื่อถือ
ตัวอย่าง Workflow แบบครบวงจร
สมมติว่าระบบ Mobile App มีปัญหาข้อมูลหายหลังเชื่อมต่ออินเทอร์เน็ตใหม่
ขั้นที่ 1 เลือก Environment
- Host: Mac ที่มี iOS Simulator
- Repository: mobile-app
- Base Branch: develop
- สร้าง Worktree ใหม่ชื่อ reconnect-fix
ขั้นที่ 2 เริ่มด้วย Plan Mode
/plan
Prompt:
วิเคราะห์ปัญหาที่รายการบางส่วนหายหลัง Reconnect วางแผนการตรวจสอบทั้ง Client และ Server ก่อนแก้โค้ด ระบุไฟล์ที่คาดว่าจะเกี่ยวข้องและวิธี Reproduce
ขั้นที่ 3 ตั้ง Goal
/goal หาสาเหตุและแก้ปัญหารายการหายหลัง Reconnect โดยเพิ่ม Regression Test และไม่เปลี่ยน shared renderer
ขั้นที่ 4 แนบหลักฐาน
แนบ Screenshot, Log และไฟล์ตัวอย่างจาก Session ที่เกิดปัญหา
ขั้นที่ 5 แทรกทิศทางเมื่อจำเป็น
หาก Codex เริ่มตรวจเฉพาะ UI ทั้งที่ข้อมูลชี้ไปยัง Resume API ให้ใช้ Steer:
หยุดตรวจ Layout ก่อน ตรวจ Response หลัง Resume ว่า Server ส่งรายการกลับมาครบหรือไม่
ขั้นที่ 6 ถามรายละเอียดผ่าน Side Chat
/side เหตุใด Resume path จึงใช้ cache คนละชุดกับ live connection
ขั้นที่ 7 Review Diff
เปิด Diff จากโทรศัพท์ ตรวจเฉพาะไฟล์ที่เปลี่ยน ใส่ Inline Comment หาก Codexแก้เกินขอบเขต
ขั้นที่ 8 Queue งานต่อท้าย
หลังแก้ตาม Review เสร็จ ให้รัน Test ทั้ง mobile package และสรุป Root Cause สำหรับ Release Note
ขั้นที่ 9 ตรวจสถานะและจัดเก็บ
ใช้ /status ตรวจ Session เมื่อทุกอย่างผ่านแล้ว เปลี่ยนชื่อ Thread ให้สื่อถึงผลลัพธ์ และ Archive
สิ่งที่ Codex Remote ไม่ได้พยายามทำ
Codex Remote ไม่ได้ถูกสร้างมาเพื่อให้ผู้ใช้เขียนโค้ดยาว ๆ บนโทรศัพท์ หรือใช้โทรศัพท์แทน IDE และจอคอมพิวเตอร์ทั้งหมด
งานที่ยังเหมาะกับ Desktop มากกว่า ได้แก่
- อ่านโค้ดจำนวนมาก
- วิเคราะห์ Architecture ขนาดใหญ่
- Debug แบบโต้ตอบหลายหน้าต่าง
- เปรียบเทียบ Diff ที่ซับซ้อน
- ออกแบบ UI อย่างละเอียด
- แก้ Merge Conflict หลายไฟล์
- ตรวจ Performance ด้วยเครื่องมือเฉพาะ
ส่วนงานที่เหมาะกับ Remote คือการเริ่มงาน เลือก Environment แก้ทิศทาง อนุมัติคำสั่ง ตรวจผลลัพธ์เฉพาะจุด และจัดคิวงาน
บทเรียนสำคัญจากบทความ
ซอฟต์แวร์บนโทรศัพท์ที่ออกแบบดีไม่ควรนำหน้าจอ Desktop มาย่อจนเล็ก แต่ควรค้นหาว่าผู้ใช้จำเป็นต้องตัดสินใจอะไรเมื่อไม่ได้อยู่หน้าเครื่อง แล้วทำให้การตัดสินใจเหล่านั้นรวดเร็ว อ่านง่าย และปลอดภัย
Codex Remote ใช้หลักคิดนี้กับงานวิศวกรรมซอฟต์แวร์ คอมพิวเตอร์ยังเป็นผู้รันโค้ด ทดสอบระบบ และจัดการไฟล์ ส่วนโทรศัพท์ช่วยให้มนุษย์ควบคุมเป้าหมาย ทิศทาง สิทธิ์ และคุณภาพของงานได้ตลอดเวลา
ผลลัพธ์คือวิศวกรไม่จำเป็นต้องกลับมานั่งหน้าเครื่องทุกครั้งที่ Agent ต้องการคำตัดสินใจเล็ก ๆ งานสามารถเดินหน้าต่อได้ แต่ยังคงมีมนุษย์เป็นผู้กำหนดขอบเขตและรับผิดชอบต่อผลลัพธ์
