ผู้คนมักเดินเข้ามาหาผมแล้วถามว่า "Codex ทำแบบนี้ได้ไหม?"
จากนั้นพวกเขาก็ใช้เวลาสองถึงสามนาทีถัดไปอธิบายว่า "แบบนี้" คืออะไรกันแน่: ปัญหาที่พวกเขาอยากแก้, แอปพลิเคชันควรทำอะไร, และผลลัพธ์ที่ดีควรเป็นอย่างไร บางครั้งพวกเขาก็แชร์สิ่งที่ลองทำไปแล้ว, อะไรที่ใช้ได้ผล, และอะไรที่ไม่ได้ผล
แล้วผมก็คิดว่า: คุณควรจะพูดทั้งหมดนี้ให้ Codex ฟังเลยนะ
คำอธิบายทั้งหมดนั้นคือพรอมต์อยู่แล้ว
Prompt engineering ตายแล้ว และก็ไม่ตาย
ถ้า prompt engineering หมายถึงการเรียนรู้ภาษาลับก่อนที่จะขอความช่วยเหลือ ผมว่ามันตายแล้วเป็นส่วนใหญ่ โดยเฉพาะกับโมเดลที่มีเหตุผล (reasoning models) มักจะไม่มีคีย์เวิร์ดวิเศษที่ปลดล็อกคำตอบที่ถูกต้อง ผมไม่คิดว่าคุณควรจ้องหน้าจอว่างๆ เป็นชั่วโมงเพื่อพยายามสร้างพรอมต์ที่สมบูรณ์แบบ
แต่มันก็ไม่ตายเสียทีเดียว เพราะความชัดเจนยังคงมีความสำคัญ ความคลุมเครือทำให้งานยากขึ้นสำหรับ Codex เช่นเดียวกับคนอื่นๆ ถ้าผมสลับย่อหน้าในบทความนี้ หรือเปลี่ยนเป็นภาษาที่คุณไม่เข้าใจ มันก็จะติดตามได้ยากขึ้น แม้แต่กาลก็มีความสำคัญ: "ฉันลองทำแบบนี้แล้ว" ไม่เหมือนกับ "ฉันอยากให้คุณลองทำแบบนี้"
คุณต้องการอะไรกันแน่? บริบทอะไรที่สำคัญ? ข้อจำกัดอะไรที่ Codex ควรรู้? ผลลัพธ์ที่ดีควรมีหน้าตาเป็นอย่างไร?
คุยกับ Codex แบบเดียวกับที่คุณคุยกับคนที่คุณทำงานด้วย
ผมชอบเริ่มต้นที่ผลลัพธ์: เป้าหมายของฉันคืออะไร? นั่นคือการเปลี่ยนแปลงครั้งใหญ่กับเอเจนต์เช่นกัน แทนที่จะเขียนสคริปต์ทุกขั้นตอนและขอผลลัพธ์ระหว่างทางทุกครั้ง ผมสามารถอธิบายสิ่งที่ฉันต้องการบรรลุ, กำหนดขอบเขต, และให้ Codex ช่วยหาหนทาง
พูดแบบที่ยังไม่เรียบร้อย
แนวคิดส่วนใหญ่ไม่ได้มาในรูปแบบสเปกที่สะอาดเรียบร้อย พวกมันมักจะออกมาแบบนี้:
"โอเค ฉันมีไฟล์พวกนี้ทั้งหมด รูปแบบแตกต่างกันเล็กน้อย ฉันต้องการรายงานภายในวันศุกร์ ฉันคิดว่าข้อมูลส่วนใหญ่อยู่แล้ว แต่ไฟล์ส่งออกอันนี้มันแปลกๆ นิดหน่อย..."
ไม่เป็นไร แค่พูดมันออกมา
เวลาคุณพูดเรื่อยเปื่อย คุณมักจะให้สัญญาณแก่ Codex มากขึ้น คุณพูดถึงรายละเอียดที่คุณอาจจะตัดออกจากพรอมต์ที่ผ่านการขัดเกลาแล้ว คุณเปลี่ยนใจกลางทาง คุณพูดว่า "จริงๆ แล้วไม่ ฉันไม่ต้องการแบบนั้น"
การเปลี่ยนใจเผยให้เห็นสิ่งที่คุณไม่ต้องการ การอ้อมไปเรื่องอื่นอาจเผยให้เห็นข้อจำกัดที่ซ่อนอยู่ การคิด aloud ช่วยให้ทั้งคุณและ Codex เข้าใจงานได้ดีขึ้น
ด้วย การป้อนตามคำบอก คุณกดไมโครโฟน, พูดสรุปงานคร่าวๆ, ตรวจสอบข้อความถอดเสียง, แล้วส่งไป
ถ้ามีในระบบของคุณ โหมดเสียง จะไปได้ไกลกว่านั้น คุณสามารถถามต่อ, ขัดจังหวะ, เปลี่ยนทิศทาง, หรือหยิบประเด็นความคิดใหม่ขึ้นมา คุณยังสามารถใช้มันเพื่อประสานงาน: เริ่มงานอื่น, ตรวจสอบงานที่มีอยู่, ถามว่าติดอะไรอยู่, หรือควบคุมงานที่กำลังทำงานอยู่
พูดตามตรง: การคุยกับคอมพิวเตอร์ยังรู้สึกแปลกๆ อยู่ ในออฟฟิศ ผมถือไมค์ DJI ไว้ในมือ หูฟังที่มีไมโครโฟนก็ใช้ได้เหมือนกัน
แต่มันก็ดีกว่าปล่อยให้ความคิดดีๆ ติดอยู่ในหัวของคุณเพราะคุณยังหาวิธีเขียนมันออกมาที่สมบูรณ์แบบไม่ได้
ถามคำถามที่ดูไร้สาระ
มีมเวอร์ชันที่คุ้นเคยเกี่ยวกับเรื่องนี้:
"Codex สร้าง B2B SaaS มูลค่าพันล้านดอลลาร์ให้ฉันหน่อย ไม่มีข้อผิดพลาด ทำทีเดียวจบ"
คุณจะไม่สร้างบริษัทมูลค่าพันล้านดอลลาร์ได้ในครั้งเดียว แต่การสนทนานั้นอาจเปิดเผยบางสิ่งที่เป็นจริง: ปัญหาที่คุณเข้าใจ, คนที่มีปัญหานั้น, และก้าวแรกที่คุ้มค่าที่จะทำ มันคือการแก้ปัญหาแบบเก่าที่ดี: แบ่งปัญหาที่ซับซ้อนออกเป็นขั้นตอนเล็กๆ ที่ทำได้
คุณค่าอยู่ที่การสนทนานั่นเอง มันสามารถพาคุณจากคำถามที่ดูไร้สาระไปสู่สิ่งที่คุณสามารถส่งมอบได้จริงในวันนี้
วิธีเริ่มต้นที่ใช้ได้จริงสองสามวิธี
ถ้าความคิดยังคลุมเครือ ให้ขอให้ Codex สัมภาษณ์คุณ:
"ฉันยังคงหาคำตอบอยู่ ถามฉันทีละคำถาม ดันในสิ่งที่คลุมเครือ แล้วช่วยฉันเปลี่ยนมันให้เป็นรูปธรรม"
หรือตรงไปตรงมามาก:
- จุดบอดของฉันคืออะไร?
- อะไรที่จะทำให้สิ่งนี้ล้มเหลว?
- ฉันกำลังคิดมากเรื่องอะไร?
- เวอร์ชันที่เล็กที่สุดแต่มีประโยชน์คืออะไร?
- คุณจำเป็นต้องรู้อะไรก่อนที่จะเริ่มได้?
โหมด Plan ของ Codex มีประโยชน์เมื่อคุณต้องการโครงสร้างมากขึ้น มันสามารถถามคำถามเพื่อความกระจ่าง, เสนอทางเลือก, และหาวิธีการก่อนที่จะลงมือทำ
แต่ผมไม่คิดว่าทุกความคิดต้องเริ่มต้นที่นั่น บางครั้งการสนทนาแบบเปิดกว้างก็ไหลลื่นกว่า เราไม่ได้แบ่งทุกการสนทนากับเพื่อนร่วมงานเป็นการวางแผนและดำเนินการ คุยกันก่อน ปล่อยให้รูปทรงของปัญหาปรากฏออกมา แล้วค่อยเปลี่ยนเป็นแผนเมื่องานต้องการ
ถาม Codex เกี่ยวกับ Codex
"คุยกับ Codex" มีความหมายที่สอง: ถามคำถามเกี่ยวกับตัวมันเอง
ถามว่ามันเห็นอะไรได้บ้าง ถามว่าโหมดไหนที่เหมาะสม ถามว่ามีเครื่องมืออะไรบ้าง ถามว่ามันวางแผนจะตรวจสอบงานของมันอย่างไร
ถ้า ทักษะ OpenAI Docs พร้อมใช้งาน ให้ขอให้ Codex ตรวจสอบเอกสาร คุณยังสามารถตรวจสอบ ที่เก็บ Codex สาธารณะ, หรือโคลนมันแล้วขอให้ Codex อธิบายว่ามันทำงานอย่างไร
ถ้า Codex พลาดเป้า ให้ถามว่าทำไม
"คุณทำแบบนี้ แต่ฉันอยากได้แบบนั้นจริงๆ เราผิดพลาดตรงไหน?"
บางทีคำขอของคุณอาจคลุมเครือ บางทีไฟล์ AGENTS.md หรือทักษะอาจดึงงานไปในทิศทางอื่น บางทีปลั๊กอิน, สิทธิ์, หรือเครื่องมืออาจไม่พร้อมใช้งาน บางที Codex อาจตั้งสมมติฐานที่ผิด
ถามว่ามันเข้าใจอะไร, ทำตามคำสั่งไหน, อะไรล้มเหลว, และคุณจะทำให้ชัดเจนขึ้นได้อย่างไร Codex มักจะใช้บริบทที่ยังคงมีอยู่เพื่อช่วยตรวจสอบการทำงานร่วมกันนั้นเอง
ในกรณีที่ทำได้ คุณสามารถเปิดแชทด้านข้างด้วย /side ขณะที่ Codex กำลังทำงาน โดยไม่รบกวนแชทหลัก ถามว่าทำอะไรไปแล้ว, เหลืออะไร, ติดอะไรอยู่, และคุณจะช่วยได้อย่างไร โดยพื้นฐานแล้วคุณคือผู้จัดการของมันในที่ประชุมยามเช้า
ถ้าคุณต้องการให้อธิบายบางอย่างเป็นภาษาที่เข้าใจง่าย ให้เลือกข้อความในบันทึกการสนทนาแล้วเลือก "ถามในแชทด้านข้าง"
นำความคิดออกจากหัวของคุณ
ระหว่างการเดินทางไกล ผมเริ่มคุยกับ Codex เกี่ยวกับงานนำเสนอ นั่นกลายเป็นโครงสร้างสำหรับการบรรยายและบทความนี้ ผมพูดถึงความคิดคร่าวๆ, เปลี่ยนใจสองสามครั้ง, และก็พูดต่อไป
บ่อยครั้ง อุปสรรคที่ใหญ่ที่สุดไม่ใช่โมเดล มันคือเรา เราคิดว่าความคิดยังไม่พร้อม เราไม่รู้พรอมต์ที่ถูกต้อง เรากังวลว่าเรายังอธิบายมันไม่ถูกต้อง
อินเทอร์เฟซจะดีขึ้น และถ้าคุณมีไอเดียว่าการคุยกับ Codex ควรรู้สึกอย่างไร ผมอยากฟังจริงๆ
แค่ถาม Codex
