lang
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
หน้าแรก
AI
OPRR
ด่วน
ความลึก
กิจกรรม
BlockBeats Pro
เพิ่มเติม
การเงิน
พิเศษ
ระบบนิเวศบล็อกเชน
รายการ
พอดแคสต์
ข้อมูล
BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
BNB
$710
3.05%
Partnered With:

คู่มือการใช้โหมดเป้าหมายของ Codex: วิธีทำให้ AI ดำเนินการตามเป้าหมายเฉพาะอย่างต่อเนื่อง

อ่านบทความนี้ใน 38 นาที
ประเด็นสำคัญไม่ได้อยู่ที่การเขียน prompt ที่ยาวขึ้น แต่อยู่ที่การกำหนดมาตรฐานที่ตรวจสอบได้ สภาพแวดล้อมจริง และกลไกการติดตามความคืบหน้า
หัวข้อต้นฉบับ: คู่มือการใช้ /goal
ผู้เขียนต้นฉบับ: @dkundel สมาชิกทีมนักพัฒนาสัมพันธ์ของ OpenAI
แปลโดย: Peggy


หมายเหตุบรรณาธิการ: บทความนี้มาจาก Dominik Kundel สมาชิกทีมนักพัฒนาสัมพันธ์ของ OpenAI ซึ่งสรุปประสบการณ์การใช้ฟีเจอร์ "goal mode / /goal" ของ Codex บทความนี้ไม่ได้พูดถึงเทคนิค prompt ทั่วไป แต่เป็นการเปลี่ยนแปลงบทบาทของเครื่องมือเขียนโค้ด AI: Codex ไม่ใช่แค่ผู้ช่วยเขียนโค้ดที่ตอบสนองคำสั่งเดี่ยวอีกต่อไป แต่เริ่มกลายเป็น Agent ที่สามารถดำเนินการตามเป้าหมายที่ชัดเจนอย่างต่อเนื่อง


ในโหมด /goal สิ่งที่สำคัญจริงๆ ไม่ใช่การเขียนความต้องการให้ยาวและละเอียดขึ้น แต่เป็นการกำหนดเกณฑ์การออกจากงานที่ชัดเจนและตรวจสอบได้ให้กับ Codex เช่น "ลดเวลาในการปรับใช้ลง 30%" "ครอบคลุมการทดสอบถึง 100% parity" "ลด LCP ให้ต่ำกว่า 2.5 วินาที" ตัวชี้วัดเหล่านี้ช่วยให้ Codex สามารถตัดสินใจได้ว่างานเสร็จสมบูรณ์หรือไม่ และยังป้องกันไม่ให้มันลองผิดลองถูกอย่างไม่มีที่สิ้นสุดในเป้าหมายที่คลุมเครือ ในขณะเดียวกัน ผู้ใช้ยังต้องให้ทิศทาง เครื่องมือ และสภาพแวดล้อมจริงที่เพียงพอ เพื่อให้ Codex สามารถวัดความคืบหน้าและตรวจสอบผลลัพธ์ แทนที่จะทำงานเฉพาะในเครื่องหรือภายใต้เงื่อนไขสมมติเพื่อสร้างโซลูชันที่ดูเหมือนเป็นไปได้


บทความนี้เตือนเป็นพิเศษว่างานที่เกี่ยวข้องกับภาพมักทำให้ Codex ติดอยู่ในรายละเอียด แทนที่จะเรียกร้อง "การคืนค่า 100% ในระดับพิกเซล" ควรแยกเป้าหมายทางภาพออกเป็นรายการฟังก์ชัน ข้อกำหนดของระบบการออกแบบ และตัวชี้วัดที่ประเมินได้ สำหรับงานระยะยาวที่ใช้เวลาหลายชั่วโมงหรือหลายวัน จำเป็นต้องติดตามอย่างต่อเนื่องผ่าน commit, draft PR, เอกสารความคืบหน้า, การอัปเดต Slack หรือ side chat เพื่อหลีกเลี่ยงการได้เพียงการเปลี่ยนแปลงที่ไม่สามารถตรวจสอบย้อนกลับได้


ข้อมูลที่เพิ่มขึ้นในบทความนี้คือการนิยาม /goal ใหม่เป็น "กลไกการจัดการงานระยะยาว" เมื่อ AI สามารถทำงานต่อเนื่องได้หลายสิบหรือหลายร้อยชั่วโมง ความสามารถหลักของนักพัฒนาก็เปลี่ยนไปเช่นกัน: ไม่ใช่แค่ให้ AI สร้างโค้ด แต่เป็นการกำหนดเป้าหมาย สร้างระบบการวัดผล กำหนดค่าสภาพแวดล้อมการทำงาน และสุดท้ายดำเนินการตรวจสอบและทบทวน กล่าวอีกนัยหนึ่ง การเขียนโค้ดด้วย AI กำลังเปลี่ยนจาก "การเขียน prompt" ไปสู่ "การจัดการผู้ดำเนินการทางวิศวกรรมที่ทำงานอย่างต่อเนื่อง"


ต่อไปนี้เป็นเนื้อหาต้นฉบับ:


เราเปิดตัวโหมดเป้าหมาย (goal mode หรือ /goal) เพื่อช่วยให้คุณทำให้ Codex ดำเนินการไปสู่ผลลัพธ์ที่เฉพาะเจาะจงอย่างต่อเนื่อง เมื่อคุณตั้งเป้าหมายแล้ว Codex จะทำงานต่อไปจนกว่าเป้าหมายจะสำเร็จ ไม่ว่าจะใช้เวลาหลายชั่วโมงหรือหลายวัน มีบางคนให้ Codex ทำงานเพื่อเป้าหมายเดียวกันต่อเนื่องนานกว่า 120 ชั่วโมงแล้ว



รูปแบบเป้าหมายมีพลังมาก หากต้องการใช้ประโยชน์สูงสุด มี 7 สิ่งที่ควรคำนึงถึงเมื่อใช้ /goal


กำหนดมาตรฐานที่ชัดเจนและตรวจสอบได้


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


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


ในกรณีส่วนใหญ่ เป้าหมายที่ดีควรมีตัวชี้วัดเชิงตัวเลขที่ชัดเจนเพื่อให้โมเดลตัดสินว่าสำเร็จหรือไม่ ตัวอย่างเช่น:


"ลดเวลาในการสร้างและปรับใช้ลง 30%"


"ย้ายฟังก์ชันนี้จาก TypeScript ไปยัง Rust และให้มีความสอดคล้องในการทดสอบ 100%"


"ปรับแต่งโครงสร้างแอปพลิเคชันให้ Largest Contentful Paint (ตัวชี้วัดที่วัดความเร็วในการโหลดเนื้อหาหลักของหน้า) ในสภาพแวดล้อมการผลิตต่ำกว่า 2.5 วินาที"


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


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


Codex สามารถกำหนดเป้าหมายได้ด้วยตัวเอง คุณสามารถเริ่มการสนทนาตามปกติก่อน แล้วเมื่อคุณพร้อมให้ Codex เริ่มดำเนินการ ก็ให้ Codex กำหนดเป้าหมายตามการสนทนาก่อนหน้านี้


คุณยังสามารถแก้ไขเป้าหมายได้ตลอดเวลา: คลิกปุ่มแก้ไขในแอปพลิเคชัน Codex หรือใช้ /goal อีกครั้งใน CLI


ให้คำแนะนำให้มากที่สุด


ข้อความแจ้งเช่น "ลดเวลาในการสร้างและปรับใช้ลง 30%" ฟังดูเจ๋งและอาจทำให้ Codex ค้นหาโซลูชันที่สร้างสรรค์ได้ แต่ถ้าคุณพอจะรู้ว่าปัญหาน่าจะอยู่ที่ไหน ข้อความแจ้งแบบนี้อาจทำให้ Codex หลงทาง


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


ตัวอย่างเช่น เพื่อนร่วมงานของฉัน @reach_vb เคยทำในการทดลองครั้งหนึ่ง: เขาบอก Codex ว่าสามารถใช้ Chrome เข้า Google Colab และระบุข้อจำกัดที่ยอมรับได้ เช่น เมื่อให้ Codex ฝึกโมเดล ก็สามารถให้มันสร้างชุดข้อมูลเองได้



ในทำนองเดียวกัน หากคุณต้องการลดเวลาในการสร้าง และรู้อยู่แล้วว่าส่วนใหญ่ของเวลาหมดไปกับขั้นตอนไหน ควรชี้ Codex ไปยังพื้นที่นั้นในคำแนะนำก่อน


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


ทำให้ความคืบหน้าวัดผลได้


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


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


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


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



รูปภาพ: ภาพหน้าจอที่ Codex สร้างขึ้นเพื่อใช้เปรียบเทียบภาพสองเฟรมด้วยสายตา


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


ตัวอย่างเช่น Codex อาจตัดภาพอ้างอิงการออกแบบและฝังลงในหน้าเพื่อให้ UI "ตรงตามพิกเซล" หรือลดขอบเขตการทดสอบเพื่อให้อัตราการผ่านการทดสอบถึง 100% ซึ่งไม่ใช่วิธีที่คุณต้องการให้เสร็จสมบูรณ์จริงๆ


สร้างสภาพแวดล้อมที่สมจริง


หากคุณต้องการให้ Codex ก้าวหน้าไปสู่เป้าหมายอย่างมีประสิทธิภาพอย่างแท้จริง มันจำเป็นต้องทำงานในสภาพแวดล้อมที่สมจริงเพียงพอ


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


ยกตัวอย่างเช่น เราเคยดีบักการปรับแต่งเวลาในการสร้างและปรับใช้ของ developers.openai.com ในตอนนั้นเราใช้การแสดงตัวอย่างการปรับใช้อยู่แล้ว ดังนั้น Codex จึงสามารถใช้สภาพแวดล้อมการแสดงตัวอย่างเหล่านี้ในการปรับใช้และดูบันทึกที่เกี่ยวข้อง แต่ปัญหาคือ การปรับใช้ตัวอย่างของเราเมื่อเทียบกับสภาพแวดล้อมการผลิตเต็มรูปแบบ ได้ปิดเส้นทางการสร้างบางส่วนไว้


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


ในทำนองเดียวกัน คุณยังสามารถให้ Codex ใช้ computer use (ความสามารถของโมเดลในการโต้ตอบกับอินเทอร์เฟซแอปพลิเคชันจริง) เพื่อทดสอบแอปพลิเคชันจริงได้อีกด้วย เพื่อปรับปรุงปัญหาด้านประสิทธิภาพบางอย่างบน iOS @dimillian ถึงกับใช้อุปกรณ์จริงเพื่อให้ได้สภาพแวดล้อมการทดสอบที่แม่นยำที่สุด



กำหนดเป้าหมายทางภาพอย่างระมัดระวัง


การให้เป้าหมายทางภาพแก่ Codex เช่น "สร้าง UI นี้ให้ตรงตามภาพนี้ 100% ในระดับพิกเซล" นั้นดูน่าดึงดูดใจ แต่ขึ้นอยู่กับการตั้งค่าเฉพาะ อาจทำให้เกิดปัญหาได้


หากคุณไม่ได้ให้คำแนะนำและข้อจำกัดที่เหมาะสม Codex อาจจมอยู่กับรายละเอียดบางอย่างมากเกินไป จนละเลยเป้าหมายโดยรวม ตัวอย่างเช่น หากภาพอ้างอิงมีองค์ประกอบกราฟิกบางอย่าง และคุณคาดหวังให้ Codex สร้างองค์ประกอบเหล่านี้ ไม่ว่าจะเป็นไอคอน SVG หรือรูปภาพ มันอาจใช้พลังงานจำนวนมากไปกับ "วิธีการทำซ้ำ素材เหล่านี้อย่างแม่นยำ" แทนที่จะแยกย่อยปัญหาทั้งหมดอย่างถูกต้อง


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


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


ติดตามความคืบหน้า


หาก Codex ทำงานอยู่เบื้องหลังเป็นเวลาหลายชั่วโมงหรือหลายวัน หรือแม้กระทั่งทำงานบนเครื่องอื่น คุณอาจลืมได้ง่ายว่ามันคืบหน้าไปถึงไหนแล้ว และได้ทำงานอะไรไปบ้าง


ขึ้นอยู่กับเป้าหมายที่แตกต่างกัน ฉันพบว่าวิธีต่อไปนี้มีประโยชน์:


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


· ให้ Codex อัปเดตผลลัพธ์ที่มุ่งเน้นไปยังฝ่ายบริหาร อาจเป็นไฟล์ HTML ที่คุณเปิดไว้ในเบราว์เซอร์ภายในแอปพลิเคชัน หรือเป็นหน้าเว็บที่ปรับใช้ผ่าน Sites เพื่อให้ทีมดูได้ หรือเป็นแผนภาพความคืบหน้าที่เรนเดอร์แล้ว หรือเพียงแค่ไฟล์ Markdown ทั่วไป


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


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


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


ทำความสะอาดและยืนยันผลลัพธ์สุดท้าย


เยี่ยมมาก ในที่สุดเป้าหมายก็สำเร็จ! ตอนนี้คุณสามารถโยนผลลัพธ์ให้ทีมแล้วเลิกงานได้เลยหรือ?


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


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


ตั้งเป้าหมายสำหรับงานถัดไปของคุณด้วย


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


คุณเคยใช้ /goal ทำอะไรบ้าง?


[ลิงก์ต้นฉบับ]



ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia

举报 แก้ไข/รายงาน
เลือกคลัง
เพิ่มคลัง
ยกเลิก
เสร็จสิ้น
เพิ่มคลัง
เห็นได้เฉพาะตัวเอง
สาธารณะ
บันทึก
แก้ไข/รายงาน
ส่ง