ผู้เขียน: jason (@jxnlco
ต้นฉบับ:
jason
@jxnlco
·
บทความ
การใช้ Codex ให้ได้ประโยชน์สูงสุด
นักพัฒนาส่วนใหญ่เมื่อแรกเริ่มใช้เอเจนต์ AI สำหรับเขียนโค้ด มักจะให้มันทำอย่างเดียวคือเขียนโค้ด เช่น ตรวจสอบ repository, สร้าง diff, รันเทส, แล้วก็เปิด pull request
การเขียนโค้ดยังคงเป็นแกนหลักของ Codex อยู่จริง แต่ถ้าคิดดูดีๆ งานส่วนใหญ่ที่เราทำบนคอมพิวเตอร์ล้วนเกี่ยวข้องกับโค้ดแทบทั้งสิ้น ไม่ว่าจะเป็นการรันคำสั่ง terminal, ท่องเว็บ, เรียก API, ส่งออกเอกสาร, ตอบสนองต่อ事件ต่างๆ หรือ trigger กระบวนการ automation เมื่อ Codex เริ่มขยายอาณาเขตออกไปในส่วนเหล่านี้ มันก็ไม่ใช่แค่ "ผู้ช่วยเขียนโปรแกรม" ที่แคบอีกต่อไป แต่กลายเป็น "คนทำงานรอบด้าน" ที่ช่วยคุณจัดการงานคอมพิวเตอร์ได้ทุกประเภท
ฟีเจอร์ใหม่ของ Codex ทำให้การเปลี่ยนแปลงนี้จับต้องได้ เธรดปัจจุบันสามารถจำบริบทของคุณ เรียกใช้เครื่องมือต่างๆ แสดง artifacts ที่สร้างขึ้น และเปลี่ยนผ่านระหว่าง prompt ต่างๆ ได้อย่างราบรื่น ทำให้คุณไม่ต้อง "แนะนำตัว" ใหม่ทุกครั้งที่จบการสนทนา
เพื่อให้ดึงศักยภาพของ Codex ออกมาใช้ได้เต็มที่ คุณต้องผสมผสานท่าไม้ตายเหล่านี้:
- เธรดแบบคงทนที่เก็บความจำระยะยาวได้
- การใช้ voice input, การบังคับทิศทางงาน (steering), และการจัดคิวงาน (queuing) อย่างยืดหยุ่น ขณะที่คุณยังคงควบคุมได้
- การขยายขอบเขตการเข้าถึงของ Codex ไปไกลกว่า codebase โดยใช้ browser, computer-use, MCP server (มาตรฐานสากลสำหรับ AI ในการเชื่อมต่อกับข้อมูลและเครื่องมือในเครื่องอย่างปลอดภัย), และคอนเนกเตอร์ต่างๆ
- ปล่อยให้มันทำงานต่อในขณะที่คุณไม่อยู่หน้าคอมพิวเตอร์ โดยใช้ thread automations และ Goals
- การใช้แผงด้านข้างอย่างชำนาญ เพื่อตรวจสอบโค้ด เอกสาร สไลด์ และไฟล์อื่นๆ ที่สร้างขึ้นได้ทุกเมื่อ
เธรดแบบคงทน (Durable threads)
เธรดแบบคงทน: เธรด Codex ที่ทำงานยาวนาน ซึ่งคงบริบทการทำงานของคุณไว้ตลอดการใช้งานหลายๆ ครั้ง
การปักหมุดเธรดเป็นวิธีที่ดีเยี่ยมในการทำให้การสนทนาแบบคงทนเหล่านี้พร้อมใช้งานได้ทันทีที่ต้องการ มันเป็นของขวัญสำหรับเวิร์กโฟลว์ที่ต้องดำเนินการซ้ำๆ เช่น:
- เธรด "หัวหน้าทีม" โดยเฉพาะ (คอยช่วยเหลืองานประจำวัน)
- เธรดสำหรับการเปิดตัวผลิตภัณฑ์โดยเฉพาะ
- เธรดสำหรับตรวจทานเอกสาร
- เธรดสำหรับติดตามข้อมูลภายนอก
สิ่งเหล่านี้ไม่ใช่กล่องแชทแบบ "คุยแล้วจบ" แต่เป็นพื้นที่ทำงานถาวร เมื่อเวลาผ่านไป Codex สามารถกลับเข้ามาสนทนาเหล่านี้ได้ทุกเมื่อ โดยจดจำการตัดสินใจครั้งก่อน ความชอบส่วนตัว และความคืบหน้าปัจจุบันของคุณ หากไม่มีฟีเจอร์นี้ คุณจะต้องป้อนข้อมูลพื้นฐานทั้งหมดนี้ให้มันใหม่ทุกครั้ง
การปักหมุดทางลัดทำให้เรื่องนี้ใช้งานได้จริงอย่างยิ่ง ด้วยการกด Command-1 ถึง Command-9 คุณสามารถกระโดดกลับเข้าไปในเธรดเฉพาะที่บันทึกไว้เหล่านี้เพื่อทำงานต่อได้ทันที
Voice input (การป้อนข้อมูลด้วยเสียง)
Voice input มีประโยชน์เพราะมันจับความคิดที่ดิบและดั้งเดิมที่สุดในหัวคุณ ก่อนที่คุณจะต้องเรียบเรียงมันเป็นข้อความอย่างดี
Codex มี voice input ในตัว ซึ่งใช้ได้ผลดีโดยเฉพาะกับไอเดียคลุมเครือที่ "พูดง่ายแต่พิมพ์เสียเวลา" เช่น:
"ฉันจำได้ว่ามีคนชื่อเบ็นพูดถึงเรื่องนี้ใน Slack
แต่จำรายละเอียดไม่ได้
ไปค้นหาให้หน่อย"
สำหรับเอเจนต์ AI ที่สามารถค้นหา รวบรวมบริบท และรายงานกลับมาหาคุณได้เอง แค่ไม่กี่ประโยคนี้ก็เพียงพอให้มันลงมือทำงานได้
เมื่อคุณมีความคิดคร่าวๆ ในหัวที่ยังไม่เป็นรูปเป็นร่าง การใช้เวลาสองสามนาที "พึมพำ" กับมัน แล้วถ่ายเทความคิดทั้งหมดของคุณออกมาในครั้งเดียว ก็ได้ผลดีอย่างน่าประหลาดใจเช่นกัน
การถอดความบันทึกเสียงก็ใช้หลักการเดียวกัน บันทึกการประชุมที่ยังไม่ผ่านการขัดเกลา หรือแบบร่างแผนงานที่พูดตามคำบอก มักจะมีค่ามากกว่าบทสรุปสั้นๆ เพราะบันทึกดิบเหล่านั้นจะเก็บรักษาน้ำเสียงที่ลังเล ประเด็นที่เน้นย้ำ และประกายความคิดที่ยังไม่สมบูรณ์เหล่านั้นไว้
การบังคับทิศทางและการจัดคิว (Steering and queuing)
เมื่อคุณรวม voice input เข้ากับการควบคุมงานที่กำลังรันอยู่โดยตรง พลังของมันจะปรากฏชัดอย่างแท้จริง
เมื่องานกำลังทำงาน ถ้าคุณต้องการ:
Task Steering: ขัดจังหวะ Codex กลางคันก่อนที่มันจะทำงานเสร็จ และกำหนดทิศทางใหม่ให้มัน
ฟีเจอร์นี้มีประโยชน์เมื่อคุณพบว่า AI กำลังเดินออกนอกเส้นทาง และจำเป็นต้องแก้ไขก่อนที่มันจะชนกำแพง ตัวอย่างเช่น ขณะให้มันตรวจสอบเว็บไซต์ คุณสามารถชี้จุดในแผงด้านข้าง พร้อมกับขัดจังหวะการทำงานของมันโดยตรง:
- "ทำให้อันนี้เล็กลงหน่อย"
- "ระยะห่างระหว่างสององค์ประกอบนี้ดูไม่ถูกต้อง"
- "ข้อความ copy นี้เขียนผิด"
Task Queuing: มอบหมายงานถัดไปให้ Codex หลังจากมันทำขั้นตอนปัจจุบันเสร็จ
Task queuing แตกต่างกัน มันไม่ได้ขัดจังหวะงานที่กำลังทำอยู่ แต่วางงานใหม่ต่อท้ายแถว คุณสามารถบอกมันว่า:
"หลังจากงานนี้เสร็จ ให้ส่งลิงก์ตัวอย่างให้ผู้ตรวจทานทาง Slack"
พูดง่ายๆ "steering" คือการเปลี่ยนสิ่งที่ Codex กำลังทำอยู่ในตอนนี้ ในขณะที่ "queuing" คือการจัดเรียงสิ่งที่มันควรทำต่อไป ฟีเจอร์ทั้งสองช่วยให้คุณรักษาความรู้สึก "มนุษย์-เครื่องเป็นหนึ่งเดียว" ในการควบคุมตลอดการดำเนินงาน
เครื่องมือและการเข้าถึง (Tools and reach)
เมื่อเธรดมีความจำต่อเนื่อง คำถามต่อไปคือ: มันสามารถเข้าถึงอะไรได้บ้าง? หนวดของ Codex สามารถยื่นออกไปเป็นชั้นๆ:
- $browser: เบราว์เซอร์ในแอปที่ทำงานในแผงด้านข้าง ซึ่ง Codex สามารถตรวจสอบและทำหมายเหตุบนหน้าเว็บได้
- @chrome: สามารถเข้าถึงสถานะล็อกอินของเบราว์เซอร์คุณเพื่อจัดการเวิร์กโฟลว์บน Chrome
- @computer: สำหรับงานที่ต้องทำผ่าน GUI บนเดสก์ท็อปเท่านั้น
$browser เหมาะสำหรับการตรวจสอบเว็บในแผงด้านข้าง @chrome สำหรับงานในเบราว์เซอร์ที่ต้องใช้บัญชีล็อกอินของคุณ และ @computer ใช้สำหรับงานที่ต้องคลิกไปมาบนเดสก์ท็อป
MCP server และคอนเนกเตอร์ต่างๆ ขยายความสามารถนี้ไปยังเวิร์กโฟลว์ทั้งหมดของคุณ การผสานรวม Slack รวมถึง ตัวเชื่อมต่อเครื่องมือ MCP และ คู่มือ MCP ต่างๆ มีความสำคัญ เพราะงานสำคัญๆ จำนวนมากมักเริ่มต้นจากข้อความแชท อีเมลในกล่องข้อความ หรือปัญหาการจัดตารางเวลา ก่อนที่จะกลายเป็นโค้ด
Skills (ทักษะ) ช่วยให้เวิร์กโฟลว์ที่ทำซ้ำๆ สามารถนำกลับมาใช้ใหม่ได้ เมื่อเวิร์กโฟลว์ใดพิสูจน์แล้วว่ามีประโยชน์ คุณสามารถ ทำให้มันเป็น skill เพื่อให้ Codex สามารถรันมันได้โดยตรงในครั้งต่อไป โดยไม่ต้องเรียนรู้กระบวนการตั้งแต่ต้นอีก
ทำงานได้จากทุกที่ (Work from anywhere)
แนวคิด การทำงานกับ Codex จากทุกที่ ทำลายข้อจำกัดเดิมที่ว่า "เราต้องนั่งหน้าคอมพิวเตอร์ถึงจะทำงานได้" อย่างสิ้นเชิง งานสามารถเริ่มต้นบน Mac ของคุณที่เต็มไปด้วยไฟล์ สิทธิ์การเข้าถึง และสภาพแวดล้อมท้องถิ่น จากนั้นดำเนินการต่อไปอย่างเงียบๆ เมื่อคุณออกจากโต๊ะและไปตรวจสอบมันบนโทรศัพท์
สิ่งนี้มีประโยชน์มากในช่วงเวลาที่กระจัดกระจาย คุณสามารถให้ Codex รันงานยาวๆ บนคอมพิวเตอร์ของคุณ แล้วลุกจากโต๊ะไปชงกาแฟ ถ้ามันมีคำถามตอนคุณไม่อยู่ คุณสามารถตอบกลับผ่านโทรศัพท์โดยตรง อนุมัติขั้นตอนต่อไป หรือกำหนดทิศทางใหม่ ก่อนจะกลับมาที่นั่ง สภาพแวดล้อมท้องถิ่นของคุณยังคงทำงานเงียบๆ อยู่ตรงนั้น ในขณะที่คุณเคลื่อนไหวได้อย่างอิสระ
Automation (ระบบอัตโนมัติ)
ฟีเจอร์ Automation ช่วยให้ Codex ทำงานอัตโนมัติตามกำหนดเวลาที่คุณตั้งไว้ สำหรับงานที่ต้องเริ่มจากศูนย์ทุกวัน เช่น การสร้างรายงานประจำวัน หรือการตรวจสอบ codebase เป็นประจำ ให้ใช้ "scheduled automation" แต่ถ้าคุณต้องการดำเนินงานภายในบทสนทนาที่มีประวัติความจำ ให้ใช้ "thread automation"
Thread Automation: เปรียบเสมือนกลไก "การเต้นของหัวใจ" ตามเวลาที่กำหนด ซึ่งจะกลับมายังเธรด Codex เดิมเป็นระยะเพื่อทำงานต่อตามตารางเวลาที่ตั้งไว้
การปักหมุดเธรดมีประโยชน์ แต่มันยังต้องให้คุณกลับไปหามันด้วยตัวเอง ในขณะที่ "thread automation" สามารถตรวจสอบได้เองทุกๆ สองสามนาทีหรือสองสามชั่วโมง จนกว่าเงื่อนไขบางอย่างจะสำเร็จ และยังสามารถปรับความถี่ในการตรวจสอบตามสถานการณ์ได้อีกด้วย
ตัวอย่างเช่น เธรด "หัวหน้าทีม" ของคุณสามารถรันทุกๆ 30 นาที:
ทุกๆ 30 นาที ให้ตรวจสอบ Slack และ Gmail ของฉันว่ามีข้อความที่ต้องดำเนินการแต่ยังไม่ได้ตอบกลับหรือไม่
ช่วยฉันจัดลำดับความสำคัญให้หน่อย
ถ้ามีคนถามคำถามฉัน ให้ค้นคว้าให้ละเอียดที่สุดและช่วยร่างคำตอบ แต่ยังไม่ต้องส่งออกไป
เมื่อคุณกลับมาที่คอมพิวเตอร์ งาน "รวบรวมข้อมูลเบื้องหลัง" ที่ใช้เวลามากที่สุดมักจะเสร็จเรียบร้อยแล้ว ในฐานะมนุษย์ คุณแค่ต้องตัดสินใจครั้งสุดท้ายว่าจะส่งออกไปหรือไม่
Thread automation ยังเหมาะอย่างยิ่งสำหรับการจัดการ "feedback loop" มันสามารถเฝ้าดูความคิดเห็นของคุณใน PR, Google Docs หรือ Slack อย่างเงียบๆ และดำเนินการปรับเปลี่ยนตามนั้นโดยอัตโนมัติในขณะที่คุณไม่อยู่
ลองนึกภาพสถานการณ์การผลิตแอนิเมชัน: ผู้ตรวจทานโพสต์วิดีโอใน Slack Thread automation สามารถตรวจสอบความคืบหน้าของการสนทนาเป็นระยะ ทันทีที่มีข้อเสนอแนะแก้ไขเข้ามา มันจะเรนเดอร์เวอร์ชันใหม่โดยอัตโนมัติ จากนั้น @mention ผู้ตรวจทานในเธรดเดิมและตอบกลับด้วยวิดีโอใหม่ ถ้าอินเทอร์เฟซการผสานรวมซอฟต์แวร์ไม่สามารถอัปโหลดขั้นสุดท้ายให้เสร็จสมบูรณ์โดยอัตโนมัติ มันยังสามารถระดม "desktop automation" เพื่อทำขั้นตอนสุดท้ายผ่าน GUI ได้อีกด้วย
วงจรปิดที่สมบูรณ์นี้ครอบคลุมตั้งแต่ Slack สำหรับรับฟีดแบ็ก codebase สำหรับเรนเดอร์ และเครื่องมือ desktop automation สำหรับการอัปโหลดขั้นสุดท้าย
เป้าหมาย (Goals)
เมื่องานมีเส้นชัยที่ชัดเจน และเอเจนต์ AI สามารถทำงานอย่างต่อเนื่องเพื่อไปสู่จุดนั้นได้ พลังของ Goals จะระเบิดออกมาอย่างแท้จริง
Goals: งาน Codex ที่ทำงานยาวนานกว่าปกติ โดยมีเส้นชัยที่ชัดเจนซึ่ง AI จะมุ่งหน้าวิ่งต่อไปเป็นระยะเวลาหนึ่ง
เป้าหมายที่ไม่ดี ถูกตั้งแบบนี้:
implement แผนในไฟล์ Markdown นี้
เป้าหมายที่ดี ต้องมีเกณฑ์วัดความสำเร็จที่วัดผลได้
ตัวอย่างเช่น วิศวกรที่ต้องการย้ายเครื่องมือภายในจาก Python ไป Rust สามารถตั้งค่าไดเรกทอรีใหม่ กำหนดเป้าหมาย และวาดเส้นชัยที่ชัดเจน:
การพัฒนาเวอร์ชันใหม่นี้จะถือว่าเสร็จสมบูรณ์ก็ต่อเมื่อ unit test ทั้งหมดผ่านเท่านั้น
การตั้งเป้าหมายโดยพื้นฐานแล้วคือการรวม "การดำเนินการต่อเนื่อง" เข้ากับ "ตัวตรวจสอบ" (verifier) คุณในฐานะมนุษย์เป็นผู้กำหนดผลลัพธ์ที่ต้องการ เงื่อนไขในการหยุด และสัญญาณที่ใช้ตัดสินว่า Codex กำลังเข้าใกล้เส้นชัยหรือไม่
ตัวตรวจสอบที่มีประโยชน์ได้แก่:
- ชุด test case ที่สมบูรณ์
- การทดสอบประสิทธิภาพ (benchmark)
- บั๊กที่สามารถจำลองซ้ำได้อย่างสม่ำเสมอ
- ตารางการตรวจสอบความถูกต้อง (verification matrix)
- เวิร์กโฟลว์แบบ end-to-end ที่ต้องผ่านเสมอ
ความทะเยอทะยานเป็นสิ่งสำคัญ แต่ความทะเยอทะยานที่ไม่มีกลไกตรวจสอบก็เป็นแค่การอธิษฐาน
แผงด้านข้าง (The side panel)
ฟีเจอร์แผงด้านข้าง ทำให้ผลงานที่คุณสร้างขึ้นอยู่ถัดจากหน้าต่างแชทของคุณ คุณไม่ต้องส่งออกไฟล์และสลับไปมาระหว่างซอฟต์แวร์ต่างๆ อย่างน่าเบื่ออีกต่อไป คุณสามารถตรวจสอบได้ทันที ผลลัพธ์ที่สร้างขึ้นอาจเป็นโค้ด แต่ก็อาจเป็นสไลด์, PDF, หน้าเว็บ, สเปรดชีต, หรือสิ่งอื่นใดที่สร้างขึ้น
มันจัดการงานสี่ประเภทได้ดีเป็นพิเศษ:
- ตรวจสอบ artifacts ที่สร้างขึ้น
- ทำหมายเหตุระบุจุดที่ต้องแก้ไข
- ใช้งานอินเทอร์เฟซเว็บ
- ตรวจสอบการเปลี่ยนแปลงของโค้ดหรือไฟล์
แผงด้านข้างช่วยให้ผู้ใช้สามารถดูเอกสาร Markdown, สเปรดชีต, ตารางข้อมูล, เอกสารธรรมดา และสไลด์ได้ทันที คุณสามารถตรวจสอบ ทำหมายเหตุ และแก้ไขไฟล์โดยไม่ขัดจังหวะเวิร์กโฟลว์ที่มีอยู่
สไลด์หรือ PDF ของคุณจะเปิดอยู่ถัดจากกล่องโต้ตอบ พร้อมให้คุณตรวจสอบและแก้ไขได้ทุกเมื่อ
เบราว์เซอร์ในแอป ช่วยให้ Codex สามารถตรวจสอบหน้าเว็บที่เรนเดอร์แล้ว ควบคุมมัน และแม้แต่ตอบสนองต่อหมายเหตุที่คุณทำบนหน้าเว็บได้โดยตรง ความคิดเห็นบนหน้าเว็บหรือไฟล์ทั้งหมดจะอยู่ในวงจรการทำงานนี้ ไม่จำเป็นต้องแยกเป็นงานส่งต่อเหมือนเดิมอีกต่อไป
หน้าเว็บกลายเป็นทั้งผลลัพธ์และแผงควบคุมที่คุณสามารถจัดการได้ Codex สามารถสร้างหน้า เปิดมันในแผงด้านข้าง ตรวจสอบมันด้วยตัวเอง แก้บั๊ก จากนั้นวนซ้ำและปรับปรุงสิ่งเดียวกันในที่นั้นอย่างต่อเนื่อง
สถานการณ์ต่อไปนี้ใช้แผงด้านข้างได้ดีเป็นพิเศษ:
- การใช้ index.html ไฟล์เดียวสำหรับการแสดงผลแบบ static ที่มีน้ำหนักเบา
- การรัน Storybook เพื่อตรวจสอบ UI components
- การใช้ Remotion Studio สำหรับแอนิเมชันที่สร้างจากโค้ด
- การนำเสนอสไลด์ในเบราว์เซอร์
- Data apps สำหรับการวิเคราะห์ข้อมูล
ไฟล์ index.html ธรรมดาๆ สามารถเปลี่ยนเป็นแอปแบบอินเทอร์แอกทีฟที่สนุกได้ โดยไม่ต้องตั้งค่าเซิร์ฟเวอร์ด้วยซ้ำ ยิ่งไปกว่านั้น thread automation ยังสามารถอัปเดตไฟล์ static เหล่านี้อย่างเงียบๆ เมื่อเวลาผ่านไป ดังนั้นเมื่อคุณกลับมา ความคืบหน้าล่าสุดก็รอคุณอยู่เสมอ
ความจำที่ใช้ร่วมกัน (Shared memory)
เมื่อเธรดที่ทำงานยาวนานเหล่านั้นสามารถ打破ขอบเขตของการแชทครั้งเดียวและแบ่งปันความจำร่วมกันได้ ประโยชน์ของมันก็จะก้าวกระโดดในเชิงคุณภาพ
ความจำที่ใช้ร่วมกัน: บริบทถาวรที่ถูกเก็บไว้ภายนอกการสนทนาเดี่ยว ทำให้งานในอนาคตสามารถดำเนินการต่อได้โดยใช้ข้อมูลที่ชัดเจนและตรวจสอบย้อนกลับได้
วิธีการที่ค่อนข้างปลอดภัยคือการ "ยึด" เธรดถาวรเหล่านี้ไว้ใน Obsidian vault พูดง่ายๆ คือสร้างโฟลเดอร์สำหรับเก็บไฟล์ข้อความธรรมดา มันตรงไปตรงมา สะดวกให้คุณดู แก้ไข และย้ายได้ทุกเมื่อ และคงอยู่ได้นาน ทีมงานสามารถใส่โฟลเดอร์นี้ในคลาวด์ไดรฟ์ที่ชอบ เช่น Git, Dropbox, Google Drive หรือเครื่องมือซิงค์อื่นๆ
vault ของคุณอาจมีลักษณะแบบนี้:
[ข้อความ]
vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/
ในไดเรกทอรีราก คุณสามารถวางไฟล์ AGENTS.md ไว้ ที่นี่คุณสามารถตั้งกฏให้ Codex: ว่ามันควรอัปเดต vault นี้อย่างไรเมื่อมันเรียนรู้สิ่งใหม่ๆ เกี่ยวกับคน โปรเจกต์ การตัดสินใจ และสิ่งที่ต้องทำ
อย่าคัดลอกโครงสร้าง vault เฉพาะใดๆ อย่างไม่ลืมหูลืมตา สิ่งที่คุณต้องทำคือ "สอน" เอเจนต์ AI ของคุณ: บริบทถาวรควรไปอยู่ที่ไหน บริบทไหนที่ต้องเก็บไว้ และเมื่อไหร่ที่ไม่ควรยุ่งกับไฟล์
คู่มือ AGENTS.md ที่ใช้งานได้จริงอาจบอกว่า:
- ถือว่า ~/vault เป็นพื้นที่ความจำในการทำงานระยะยาวของคุณ
- พยายามจัดระเบียบโน้ตให้ดี อย่าให้บันทึกที่กระจัดกระจายเกลื่อนกลาด
- จัดหมวดหมู่สิ่งที่ต้องทำ, คน, โปรเจกต์, สรุปประจำวัน, และร่างต่างๆ อย่างถูกต้อง
- บันทึกการตัดสินใจที่ทำไป, อุปสรรคที่เจอ, ผู้รับผิดชอบ, วันที่, และลิงก์ที่มีประโยชน์อย่างเหมาะสม
- หากไม่มีความคืบหน้าใหม่ที่มีสาระสำคัญ อย่าแก้ไขไฟล์ใน vault โดยไม่จำเป็น
Codebase ใช้สำหรับเก็บโค้ด vault นี้ใช้สำหรับเก็บบริบทที่หมุนเวียนไป: ใครมีส่วนร่วม, อะไรถูกเปลี่ยนแปลง, ติดขัดตรงไหน, ใครเป็นคนต่อไป, และรายละเอียดเหล่านั้นที่จะหายไปอย่างสิ้นเชิงหากถูกตัดขาดระหว่างการแชทสองครั้ง
บริบทสำคัญไม่ควรถูกขังไว้เฉพาะในบันทึกข้อความของการแชทครั้งเดียว จงเขียนมันลงไปและวางไว้ในที่ที่เธรดถัดไปสามารถหยิบไปใช้ได้ทันที
Codex เองก็มี ฟีเจอร์หน่วยความจำ อย่างเป็นทางการในการตั้งค่า > Personalization > Memory มันเหมือนสมุดโน้ตในตัวที่ใช้จดจำความชอบส่วนตัว เวิร์กโฟลว์ทั่วไป และข้อผิดพลาดที่พบบ่อยของคุณ อย่างไรก็ตาม ฟีเจอร์นี้มีไว้เสริมบริบทที่คุณเขียนไว้อย่างชัดเจน ไม่ใช่แทนที่มัน ส่วนประกอบหน่วยความจำ Chronicle ก็ใช้หลักการเดียวกัน ช่วยให้ Codex ดึงข้อมูลและสร้างความจำจากสิ่งที่เพิ่งเกิดขึ้นบนหน้าจอของคุณ
จากโค้ดสู่วงกว้าง (From code outward)
แม้ว่า Codex จะเริ่มต้นด้วยการเขียนโค้ดเป็นอาชีพหลัก แต่ตอนนี้งานรอบข้างต่างๆ ที่เกี่ยวข้องกับโค้ดมากมายก็สามารถจัดการได้ภายในระบบเดียวกันนี้ ไม่ว่าจะเป็น MCP server, อินเทอร์เฟซเว็บ, การควบคุมเดสก์ท็อป, thread automation, หรือไฟล์ที่ตรวจสอบได้ในแผงด้านข้าง
สิ่งนี้改变了วิธีที่เราควบคุมมันอย่างสิ้นเชิง "Task steering" สามารถขัดจังหวะการกระทำของมันกลางคัน "task queuing" สามารถจัดเรียงขั้นตอนถัดไปให้มัน "thread automation" ช่วยให้ระบบทำงานต่อไปได้เมื่อคุณไม่อยู่ และ "goal setting" ก็วาดเส้นชัยที่ชัดเจน ให้ Codex รู้ว่าควรวิ่งต่อไปยังจุดไหน
Codex ในวันนี้สามารถแบกเวิร์กโฟลว์ที่สมบูรณ์ได้แล้ว ตั้งแต่การฟังคำสั่ง การดำเนินงาน ไปจนถึงการตรวจสอบไฟล์ขั้นสุดท้าย ถึงแม้ว่างานเหล่านี้จะล้ำขอบเขตของ codebase ไปไกลแล้ว มันก็ยังจัดการได้อย่างสบายๆ
