Codex ห้องยาวจนเริ่มหลงงาน? วิธีทำงานต่อ แตกห้อง และย้าย Session โดยไม่เริ่มใหม่จากศูนย์

ทำงานจริงกับ Codex ไปสักพัก มีโอกาสเจอปัญหานี้แน่นอนค่ะ

ตอนเริ่มโปรเจกต์ ห้องยังสั้น Codex รู้ว่าเรากำลังทำอะไร ไฟล์ไหนแก้ไปแล้ว ขั้นตอนต่อไปคืออะไร

แต่พอทำต่อหลายวัน...

ทั้งการแก้ Code, Debug, วาง Architecture, เพิ่ม Feature, เปลี่ยน Requirement และการทดลองต่าง ๆ เริ่มรวมอยู่ใน Session เดียว

จนเกิดคำถามว่า

“ห้องนี้เริ่มยาวแล้ว ถ้าจะย้ายไปห้องใหม่ จะทำยังไงให้ Codex ไม่เริ่มงานใหม่จากศูนย์?”

หรือบางครั้งเราไม่ได้อยากย้ายงานเลยค่ะ

แค่อยากถามอีกเรื่องหนึ่ง ทดลองอีกแนวหนึ่ง หรือแตกงานออกไปทำอีกทาง โดยไม่ทำให้ Main Session เดิมเละ

ตรงนี้ Codex มีวิธีจัดการอยู่หลายระดับ

แก่นที่ควรรู้มี 4 ตัวนี้ค่ะ

Resume → Side → Fork → Handoff + Repo

แต่ละตัวไม่ได้ใช้แทนกันนะคะ

1. ถ้าแค่ต้องการกลับมาทำ Session เดิมต่อ — ใช้ Resume

กรณีแรกง่ายที่สุด

ถ้างานยังอยู่เรื่องเดิม ทิศทางเดิม และเราต้องการกลับเข้ามาทำ Session เดิมต่อ

ไม่จำเป็นต้องสร้างห้องใหม่ค่ะ

Codex CLI มีคำสั่งสำหรับ Resume session เดิมโดยตรง เช่น

codex resume

หรือกลับไป Session ล่าสุด

codex resume --last

Codex จะให้เรากลับเข้า Session ที่เคยทำไว้แล้วและทำต่อจากประวัติเดิมได้

เหมาะกับสถานการณ์เช่น

• เมื่อวานหยุดทำงาน วันนี้กลับมาทำต่อ

• ปิด Terminal หรือ Codex ไปแล้ว

• งานยังอยู่โปรเจกต์เดิม

• ไม่ได้ต้องการสร้างแนวทางใหม่

• ไม่ได้ต้องการแยก Context

จำง่าย ๆ ว่า

งานเดิม + ห้องเดิม = Resume

2. อยากถามหรือทดลองเรื่องข้างทาง แต่ไม่อยากให้ Main Session ยาวขึ้น — ใช้ Side

นี่เป็นฟีเจอร์ที่มีประโยชน์มากเวลาทำงานยาวค่ะ

สมมติ Codex กำลังทำระบบหลักอยู่

ระหว่างนั้นเราเกิดสงสัยว่า

Library ตัวนี้รองรับวิธีนี้ไหม?

หรือ

ถ้าเปลี่ยน Architecture เป็นอีกแบบจะมีข้อเสียอะไร?

เราอยากคุย อยากวิเคราะห์ แต่ยังไม่อยากให้เรื่องเหล่านั้นเข้าไปปนกับ Main Thread

ตรงนี้ใช้ Side Conversation

ใน Codex มี /side สำหรับเปิด Side Conversation โดย Codex implementation ปัจจุบันอธิบาย Side ว่าเป็น ephemeral fork หรือการแตกจาก Thread หลักแบบชั่วคราว

ตัวอย่าง

/side

แล้วค่อยถามเรื่องที่ต้องการแยกออกมา

ประโยชน์คือ Main Session ยังสามารถรักษาแกนงานหลักไว้ได้ โดยไม่ต้องเอาทุกคำถาม ทุกการทดลอง และทุกเรื่องข้างทางไปรวมอยู่ใน Context เดียว

เหมาะกับ

• ถามเรื่องข้างเคียง

• Research ก่อนตัดสินใจ

• วิเคราะห์ Alternative

• ตรวจ Documentation

• Debug ประเด็นที่ยังไม่แน่ว่าเกี่ยวกับงานหลักหรือไม่

• อยากคิดก่อน แต่ยังไม่อยากเปลี่ยน Main Work

แต่มีเรื่องที่ต้องเข้าใจค่ะ

Side ไม่ใช่ Fork แบบถาวร

Side Conversation ถูกออกแบบให้เป็นลักษณะชั่วคราวมากกว่า ดังนั้นถ้าเรื่องที่ทดลองเริ่มกลายเป็น “งานจริงที่จะเดินต่อ” ไม่ควรฝากงานสำคัญไว้ใน Side อย่างเดียว

3. ถ้าอยากแตกจากงานปัจจุบัน แล้วเอา Context เดิมไปสร้าง Session ใหม่จริง ๆ — ใช้ Fork

นี่คือจุดสำคัญของบทความนี้เลยค่ะ

Fork ต่างจากการเปิด Session ใหม่จากศูนย์

เวลาทำงานมาถึงจุดหนึ่ง เราอาจต้องการเก็บ Main Session เดิมเอาไว้ แต่สร้าง Session ใหม่ที่เริ่มจากสิ่งที่เราทำมาถึงตอนนี้

นี่คือหน้าที่ของ Fork

Codex รองรับการ Fork previous interactive session ไปเป็น Session ใหม่ และในหน้าจอ Codex สามารถเลือกได้ทั้ง Fork chat และ Fork chat in new worktree ตามลักษณะงานที่ต้องการแยก

ถ้าใช้งานผ่าน CLI ก็สามารถ Fork session ได้ เช่น

codex fork

หรือ

codex fork --last

แนวคิดคือ

SESSION เดิม
      │
      ├── เดินต่อแนวทางเดิม
      │
      └── FORK → SESSION ใหม่ → ทดลอง/พัฒนาอีกแนวทาง

ข้อมูลก่อนจุด Fork กลายเป็นฐานให้ Session ใหม่เริ่มต้นได้ โดยไม่ต้องกลับไปอธิบายโปรเจกต์ใหม่ทั้งหมด

นี่จึงเหมาะมากกับงานพัฒนา

ตัวอย่างค่ะ

เรากำลังสร้าง Agent ตัวหนึ่ง

Architecture ปัจจุบันใช้วิธี A

แต่เราอยากลองวิธี B

ถ้าทดลอง B ต่อใน Main Session เลย แล้วสุดท้ายไม่เวิร์ก Context จะเต็มไปด้วยการลองผิดลองถูกจำนวนมาก

วิธีที่สะอาดกว่าคือ

Fork จากจุดที่ระบบยังถูกต้อง

แล้วให้ Session ใหม่ทดลอง B

ถ้า B ไม่ดี ก็กลับ Session เดิม

ถ้า B ดีกว่า ก็พัฒนาต่อจาก Fork นั้นได้

นี่เป็นประโยชน์ที่ต่างจาก Side อย่างชัดเจนค่ะ

Side

เหมือนเดินออกจากโต๊ะไปถามอะไรสั้น ๆ แล้วกลับมาทำงานเดิม

Fork

เหมือน Copy สถานะงานถึงจุดนี้ แล้วเปิดโต๊ะทำงานอีกโต๊ะหนึ่งเพื่อเดินงานต่อจริง

แล้ว Fork ช่วยเรื่อง Context ได้ทั้งหมดไหม?

ช่วยได้มากค่ะ แต่ครูเฟิร์นไม่แนะนำให้คิดว่า

“มี Fork แล้วไม่ต้องจัดระบบข้อมูลโปรเจกต์อีก”

เพราะเมื่อโปรเจกต์ใหญ่ขึ้น ปัญหาจะไม่ได้มีแค่ “AI จำบทสนทนาได้ไหม”

แต่จะเริ่มมีเรื่อง

• ตอนนี้ Version ไหนคือของจริง

• Architecture ล่าสุดคืออะไร

• ไฟล์ไหนเลิกใช้แล้ว

• Decision ไหนถูกยกเลิกแล้ว

• Agent ตัวไหนรับผิดชอบอะไร

• งานอะไรเสร็จแล้ว

• Next Action จริงคืออะไร

เรื่องพวกนี้ไม่ควรถูกฝากไว้กับ Chat History เพียงอย่างเดียวค่ะ

4. งานใหญ่ หลายวัน หลาย Agent — ทำ Handoff แล้วให้ Repo เป็น Source of Truth

นี่คือวิธีที่ครูเฟิร์นใช้กับงานจริงมากขึ้นเรื่อย ๆ

พอโปรเจกต์เริ่มใหญ่ เราจะไม่ถามว่า

“ทำยังไงให้ Codex จำทุกอย่าง?”

แต่เปลี่ยนเป็น

“ทำยังไงให้ Codex เปิดเข้ามาแล้วอ่านสถานะล่าสุดของโปรเจกต์ได้?”

สองอย่างนี้ต่างกันมากค่ะ

วิธีแรกพึ่งความจำของ Session

แต่วิธีที่สองสร้าง Project Memory ที่อยู่นอกบทสนทนา

ก่อนจะย้าย Session สามารถให้ Codex สร้าง Handoff เป็น Markdown เช่น

สรุป Handoff ล่าสุดของโปรเจกต์นี้เป็นไฟล์ Markdown

ให้มี:
- เป้าหมายของโปรเจกต์
- สถานะปัจจุบัน
- สิ่งที่ทำเสร็จแล้ว
- Architecture ล่าสุด
- repo/path ที่เกี่ยวข้อง
- ไฟล์สำคัญ
- commit ล่าสุด
- Decision ที่ต้องยึด
- สิ่งที่ทดลองแล้วและไม่ควรทำซ้ำ
- งานค้าง
- Next Action
- Prompt สำหรับ Agent/Session ที่รับงานต่อ

จากนั้น Session ใหม่ไม่ต้องย้อนอ่านบทสนทนายาวทั้งหมด

ให้เริ่มจาก

อ่าน AGENTS.md
อ่าน README.md
อ่าน Handoff ล่าสุด
ตรวจสถานะใน repo

จากนั้นทำงานต่อจาก Next Action
ห้ามเริ่มโปรเจกต์ใหม่จากศูนย์

นี่คือจุดที่ Repo กลายเป็นสมองกลางของงาน

ตัวอย่างโครงสร้างง่าย ๆ

PROJECT/
│
├── AGENTS.md
├── README.md
├── ARCHITECTURE.md
├── SOP/
├── DECISIONS/
├── HANDOFF/
├── LOGS/
└── source code / project files

เมื่อจัดแบบนี้แล้ว ต่อให้เปลี่ยน Session เปลี่ยน Agent หรือ Fork ไปกี่ครั้ง

ความจริงของโปรเจกต์ยังอยู่ที่เดิม

สรุป Side, Fork, Resume และ Handoff ต่างกันอย่างไร?

จำแบบนี้ง่ายที่สุดค่ะ

Resume

กลับไปทำงานเดิม

Session เดิม Context เดิม งานเดิม

Side

แตกไปถามหรือสำรวจชั่วคราว

ไม่อยากให้คำถามข้างทางไปรบกวน Main Thread

เหมาะกับ Research และการคิดระยะสั้น

Fork

เอางานจากจุดปัจจุบันไปสร้าง Session ใหม่

รักษาฐาน Context เดิมไว้ แต่เปิดทางให้ทำงานต่ออีกเส้นหนึ่ง

นี่เหมาะมากกับการทดลอง Architecture, Feature หรือแนวทางใหม่

Handoff + Repo

ส่งมอบสถานะของโปรเจกต์ให้ Session หรือ Agent ไหนก็อ่านต่อได้

เหมาะกับงานจริง งานหลายวัน งานหลาย Agent และโปรเจกต์ที่ต้องกลับมาทำต่อในอนาคต

ถ้าถามว่าครูเฟิร์นใช้แบบไหน?

จริง ๆ ไม่ได้เลือกเพียงตัวใดตัวหนึ่งค่ะ

Workflow ที่เหมาะกับงานจริงคือ

MAIN CODEX SESSION
       │
       ├── /side
       │   └── ถาม / Research / ทดลองความคิดชั่วคราว
       │
       ├── Fork
       │   └── แตกงานจริงไปอีกแนวทาง
       │
       └── Handoff
            ↓
          REPO
            ↓
       NEW SESSION / NEW AGENT

และถ้าวันถัดไปแค่กลับมาทำ Session เดิม

Resume → ทำต่อ

นี่ช่วยให้เราไม่ต้องเอาทุกอย่างยัดอยู่ในห้องเดียว

และไม่ต้องกลัวว่าเปิด Session ใหม่แล้ว Codex จะไม่รู้เรื่องอะไรเลย

สิ่งที่สำคัญกว่า “จำ Prompt เก่ง”

เมื่อเริ่มใช้ Codex ทำงานจริง ครูเฟิร์นมองว่าทักษะที่สำคัญไม่ได้มีแค่การเขียน Prompt ค่ะ

แต่คือการออกแบบว่า

AI จะรับงานต่อกันอย่างไร สถานะงานอยู่ที่ไหน อะไรคือ Source of Truth เมื่อ Session ยาวแล้วจะแตกงานตรงไหน เมื่อเปลี่ยน Agent แล้วตัวใหม่จะเริ่มจากอะไร

เมื่อจัด 5 เรื่องนี้ได้ Codex จะเริ่มเปลี่ยนจาก

AI ที่เราต้องคอยเล่างานให้ฟัง

ไปเป็น

ทีมงานที่เปิด Project เข้ามาแล้วรู้ว่าจะทำอะไรต่อ

และนี่เป็นพื้นฐานสำคัญมากสำหรับคนที่กำลังจะขยับจากการ “ใช้ Codex” ไปสู่การสร้าง AI Agent Team สำหรับธุรกิจจริง

คำถามที่พบบ่อย

Fork ใน Codex คืออะไร?

Fork คือการนำ Session ที่มีอยู่ไปสร้าง Session ใหม่ เพื่อให้สามารถพัฒนาหรือทดลองงานต่อจากบริบทเดิมได้ โดยไม่ต้องเปลี่ยนหรือทำลาย Session ต้นทาง

Fork กับ Side ต่างกันอย่างไร?

Side เหมาะกับการถามหรือสำรวจเรื่องข้างทางชั่วคราว และปัจจุบันถูกออกแบบเป็น ephemeral fork ส่วน Fork เหมาะกับการสร้าง Session ใหม่เพื่อเดินงานต่อจริงอย่างเป็นอิสระจากต้นทาง

ถ้าปิด Codex แล้วอยากกลับมาทำงานเดิมควรใช้ Fork หรือไม่?

ถ้าต้องการทำ Session เดิมต่อ ให้ใช้ Resume ไม่จำเป็นต้อง Fork

Fork แล้วจำเป็นต้องทำ Handoff อีกไหม?

สำหรับงานสั้นอาจไม่จำเป็น แต่โปรเจกต์สำคัญควรมี Handoff และ Project Files อยู่ดี เพราะ Fork แก้เรื่องการแตก Session แต่ไม่ได้แทนระบบ Knowledge และ Project State

ทำไมควรเก็บข้อมูลไว้ใน Repo?

เพราะ Repo สามารถเก็บ Code, Version, SOP, Architecture, Decision และ Handoff ไว้เป็นแหล่งข้อมูลกลาง ทำให้ Session หรือ Agent ใหม่ไม่ต้องพึ่ง Chat History เพียงอย่างเดียว