แนวปฏิบัติที่ดีที่สุด

ภาพรวม

คู่มือนี้ให้แนวปฏิบัติที่พิสูจน์แล้วสำหรับการใช้ Codex อย่างมีประสิทธิภาพผ่าน CLI, IDE extension และ Codex app โดยเน้นการมอง Codex ว่าเป็น "เพื่อนร่วมทีมที่กำหนดค่าได้" ไม่ใช่ผู้ช่วยชั่วคราว

แนวปฏิบัติสำคัญ

การเริ่มต้นที่แข็งแกร่ง: Context และ Prompt

Prompt ที่มีประสิทธิภาพควรมีสี่องค์ประกอบ:

• Goal (เป้าหมาย): สิ่งที่คุณต้องการเปลี่ยนแปลงหรือสร้าง
• Context (บริบท): ไฟล์ โฟลเดอร์ เอกสาร หรือข้อผิดพลาดที่เกี่ยวข้อง (ใช้ @mention สำหรับไฟล์เฉพาะ)
• Constraints (ข้อจำกัด): มาตรฐาน สถาปัตยกรรม ข้อกำหนดด้านความปลอดภัย และ convention
• Done when (เสร็จเมื่อ): เกณฑ์ความสำเร็จ เช่น การผ่าน test หรือการแก้ไข bug

แนะนำให้เปลี่ยนระดับ reasoning (Low, Medium, High, Extra High) ตามความซับซ้อนของงาน

การวางแผนสำหรับงานที่ยาก

สำหรับงานที่ซับซ้อนหรือไม่ชัดเจน มีสามแนวทางที่ได้ผลดี:

• ใช้ Plan mode (สลับด้วย /plan หรือ Shift+Tab)
• ขอให้ Codex สัมภาษณ์คุณด้วยคำถามเพื่อความชัดเจน
• สร้าง template การดำเนินงาน PLANS.md สำหรับงานหลายขั้นตอน

ทำให้คำแนะนำนำกลับมาใช้ได้ด้วย AGENTS.md

ไฟล์ AGENTS.md ทำหน้าที่เป็นคำแนะนำอัตโนมัติสำหรับ Codex ครอบคลุม:

• โครงสร้าง repository และไดเรกทอรีสำคัญ
• คำสั่ง build, test และ lint
• convention ทางวิศวกรรม
• ข้อจำกัดและกฎ
• แนวทางการตรวจสอบ

สามารถมีไฟล์ AGENTS.md หลายไฟล์ในระดับไดเรกทอรีต่าง ๆ โดยไฟล์ที่เฉพาะเจาะจงกว่าจะมีความสำคัญสูงกว่า

การกำหนดค่าเพื่อความสม่ำเสมอ

ลำดับชั้นของการกำหนดค่า:

• ค่าเริ่มต้นส่วนตัว: ~/.codex/config.toml
• เฉพาะ repository: .codex/config.toml
• Override ผ่าน command line สำหรับกรณีเฉพาะ

รายการที่กำหนดค่าได้หลักได้แก่ การเลือก model, ระดับ reasoning, sandbox mode และการตั้งค่า MCP

ความน่าเชื่อถือผ่าน Test และ Review

Codex ควรสร้าง test, รันการตรวจสอบ, ยืนยันผลลัพธ์ และรีวิวงาน คำสั่ง /review เปิดใช้งาน:

• การเปรียบเทียบกับ base branch แบบ PR
• การรีวิวการเปลี่ยนแปลงที่ยังไม่ได้ commit
• การรีวิว commit
• คำแนะนำการรีวิวแบบกำหนดเอง

การใช้ MCP สำหรับ Context ภายนอก

Model Context Protocol ผสานรวมเครื่องมือภายนอกเมื่อ:

• Context อยู่นอก repository
• ข้อมูลเปลี่ยนแปลงบ่อย
• เครื่องมือควรแทนที่คำแนะนำที่วางไว้
• การผสานรวมต้องทำซ้ำได้

เริ่มต้นด้วยเครื่องมือหนึ่งหรือสองตัวที่ขจัด loop ด้วยตนเองที่ชัดเจน

Skills สำหรับงานที่ทำซ้ำ

Skills บรรจุคำแนะนำในไฟล์ SKILL.md สำหรับงานที่ทำซ้ำ เช่น:

• การ triage log
• การร่าง release note
• การรีวิว PR กับ checklist
• การวางแผน migration
• กระบวนการ debug มาตรฐาน

Skill $skill-creator ช่วย scaffold skill ใหม่ skill ส่วนตัวอยู่ใน $HOME/.agents/skills และ skill ของทีมอยู่ใน .agents/skills

Automations สำหรับงานตามกำหนด

เมื่อ workflow เสถียรแล้ว Automations จะรันในเบื้องหลัง ผู้สมัครที่ดีได้แก่:

• การสรุป commit
• การสแกน bug
• การร่าง release note
• การตรวจสอบ CI failure
• การสรุป standup

หลักการ: "skills กำหนดวิธีการ automations กำหนดกำหนดเวลา"

การจัดการ Session

การจัดระเบียบ thread ที่มีประสิทธิภาพ:

• หนึ่ง thread ต่อหน่วยงานที่เชื่อมโยงกัน
• ใช้ /fork เมื่องานแยกออกจริง ๆ
• ใช้ subagent สำหรับงานที่มีขอบเขตชัดเจน
• ใช้คำสั่ง slash ที่มีประโยชน์: /resume, /compact, /agent, /status

ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยง

• ใส่ข้อมูลมากเกินไปใน prompt แทนที่จะใช้ AGENTS.md หรือ skills
• ไม่บอก Codex ว่าจะรัน test และ build อย่างไร
• ข้ามการวางแผนสำหรับงานหลายขั้นตอน
• ให้สิทธิ์เต็มรูปแบบก่อนที่จะเข้าใจ workflow
• รัน thread แบบ live โดยไม่มี git worktree
• ทำ workflow ที่ไม่น่าเชื่อถือให้อัตโนมัติก่อนเวลา
• ดูทีละขั้นตอนแทนที่จะทำงานแบบขนาน
• ใช้หนึ่ง thread ต่อ project แทนที่จะเป็นต่องาน