ถ้าคุณคิดว่า Codex เป็นแค่ "แชทที่เขียนโค้ด" แสดงว่าคุณตามหลังคนรุ่นต่อไปแล้ว
ในวันที่ 9 กรกฎาคม 2026 GPT-5.6 ได้ถูกปล่อยให้สาธารณชนใช้งาน
หัวใจสำคัญของมันคือโมเดลธงประจำรุ่นที่ชื่อว่า "Sol"
ความสามารถในการดำเนินการตามคำขอเดียวจนเสร็จสมบูรณ์ ตั้งแต่การเขียนโค้ดที่ซับซ้อน การวิจัย การสร้างเอกสาร ไปจนถึงการทำงานบนเบราว์เซอร์ Computer Use ความปลอดภัย และการดำเนินโครงการระยะยาว ได้เติบโตขึ้นอย่างมาก
มันทำคะแนนได้ 80 บน Artificial Analysis Coding Agent Index บน Terminal-Bench 2.1 มันทำได้ 88.8% และในการตั้งค่า Ultra มันพุ่งขึ้นไปถึง 91.9%
อย่างไรก็ตาม มีการเปลี่ยนแปลงที่ยิ่งใหญ่กว่าตัวเลขเหล่านั้น
นั่นคือ Codex ได้เปลี่ยนจาก "AI ที่ตอบคำถาม" กลายเป็น "AI ที่ประกอบและทำให้งานสำเร็จ"
ค้นคว้า
วางแผน
สร้างสรรค์
ตรวจสอบ
กระจายงานให้ AI หลายตัวหากจำเป็น
บันทึกขั้นตอนที่ทำสำเร็จและเรียกใช้โดยอัตโนมัติตั้งแต่ครั้งต่อไป
คุณสามารถทำวงจรทั้งหมดนี้ให้เสร็จภายใน Codex
มีผู้คนมากกว่า 5 ล้านคนใช้ Codex ทุกสัปดาห์แล้ว และประมาณ 20% ของพวกเขาไม่ใช่วิศวกร ยิ่งไปกว่านั้น การใช้งานในกลุ่มที่ไม่ใช่วิศวกรเติบโตเร็วกว่าในกลุ่มนักพัฒนามากกว่าสามเท่า
กล่าวอีกนัยหนึ่ง การเปลี่ยนแปลงนี้ไม่ได้มีไว้สำหรับวิศวกรเท่านั้น
การผลิตบทความ การจัดการ SNS การวิจัยคู่แข่ง การวางแผนผลิตภัณฑ์ การสร้างเอกสาร การสนับสนุนลูกค้า และการผลิตเว็บ
งานเกือบทุกอย่างที่ทำบนคอมพิวเตอร์คือเป้าหมาย
ในบทความนี้ ฉันจะเชื่อมต่อฟังก์ชันทั้งหมดที่จำเป็นในการใช้ Codex อย่างเต็มที่ในยุค GPT-5.6 Sol เรียงตามลำดับพลังที่เพิ่มขึ้น
ตั้งแต่การเลือกระหว่าง Sol, Terra และ Luna ไปจนถึง Plan mode, AGENTS.md, config.toml, Skills, Plugins, MCP, Ultra, Subagents, Custom Agents, การตรวจสอบ และ Automations
นี่ไม่ใช่การแนะนำฟีเจอร์แบบแยกส่วน แต่เป็นแผนที่ยุทธศาสตร์สำหรับสร้างสภาพแวดล้อมการทำงานเฉพาะของคุณเองให้สำเร็จ
สำหรับผู้ที่ต้องการเห็นภาพใหญ่ของการบรรลุผลลัพธ์ในงานเสริมไปพร้อมกับบทความนี้ 🎁
ตอนนี้บน LINE ทางการ
"กลยุทธ์ครบชุดสำหรับงานเสริม SNS สไตล์คุโรเนโกะ: แพ็คโบนัส 5 อย่าง"
กำลังแจกฟรีอยู่ 🎁
เนื่องจากเดิมทีสิ่งนี้มีแผนจะปล่อยเป็นเนื้อหาที่ต้องชำระเงิน
การแจกจ่ายจะสิ้นสุดลงเมื่อถึงขีดจำกัดความจุ
โปรดรับไว้พร้อมกับบทความในขณะที่ยังมีโอกาส
▼▼▼
▶︎▶︎▶︎ รับโบนัส 5 อย่าง
ตอนนี้ มาดูหัวข้อหลักกันเลย!
ตัวตนที่แท้จริงของ Codex ไม่ใช่ "AI แชท" แต่เป็น OS ที่ขับเคลื่อนงาน
เพื่อให้เข้าใจ Codex ในยุค Sol คุณต้องเข้าใจภาพรวมก่อน
Codex ประกอบด้วย 6 ชั้นดังต่อไปนี้
หลายคนมองแค่ชั้นแรก: "โมเดลไหนฉลาดที่สุด"
อย่างไรก็ตาม ความแตกต่างในงานจริงเกิดขึ้นตั้งแต่ชั้นที่สองเป็นต้นไป
ไม่ว่าโมเดลจะฉลาดแค่ไหน ถ้าจุดประสงค์คลุมเครือ วัสดุที่จำเป็นหายไป และไม่ได้กำหนดเงื่อนไขความสำเร็จ สิ่งที่ได้กลับมาคือทฤษฎีทั่วไปที่ไม่ถึงเป้าหมาย
ในทางกลับกัน ถ้าคุณให้บริบท กฎ เครื่องมือ บทบาท และเงื่อนไขความสำเร็จ Codex จะกลายเป็นฝ่ายที่ทำให้งานสำเร็จ
ไม่ต้องสงสัยเลยว่า Sol นั้นแข็งแกร่ง
แต่แค่เลือก Sol ไม่ได้ทำให้ Codex สมบูรณ์
คุณจะเห็นศักยภาพที่แท้จริงของมันก็ต่อเมื่อคุณเชื่อมต่อประสิทธิภาพของสมองเข้ากับกลไกของการทำงาน
1. การเลือก Sol, Terra หรือ Luna สำหรับงาน
ใน GPT-5.6 คุณสามารถเลือกได้จากสามโมเดลขึ้นอยู่กับวัตถุประสงค์ของคุณ
Sol คือ "ศูนย์บัญชาการ" ที่คิดจนกว่าจะสำเร็จ
Sol คือโมเดลธงของ GPT-5.6 เหมาะสำหรับงานที่คำตอบไม่ได้ถูกกำหนดไว้ตั้งแต่แรก
- อ่านวัสดุหลายชิ้นเพื่อตัดสินใจกลยุทธ์
- ทำความเข้าใจโค้ดเบสขนาดใหญ่เพื่อเพิ่มฟีเจอร์
- ดำเนินการตั้งแต่การวิจัย โครงสร้าง การผลิต และการตรวจสอบในคราวเดียว
- ทำให้งานที่ต้องใช้เบราว์เซอร์และแอปต่างๆ สำเร็จลุล่วง
- รักษาความสอดคล้องในโปรเจกต์ระยะยาว
- สั่งงาน Subagents หลายตัว
Sol เหมาะสำหรับงานที่คุณต้องการให้ AI คิดไม่เพียงแค่ "จะทำอะไร" แต่รวมถึง "จะดำเนินการอย่างไรเพื่อให้บรรลุเป้าหมาย"
Terra คือ "ผู้ปฏิบัติ" ที่สร้างสมดุลระหว่างความเร็วและคุณภาพ
Terra เป็นโมเดลที่สร้างสมดุลระหว่างความสามารถและต้นทุน เหมาะสำหรับงานที่ต้องการการตัดสินใจแต่ไม่จำเป็นต้องใช้ความคิดที่ลึกซึ้งและต่อเนื่องของ Sol เช่น การวิจัยประจำวัน การสรุปความ การจัดระเบียบไฟล์ การร่าง การแก้ไขโค้ด และการตรวจสอบวัสดุหลายชิ้น
เมื่อรัน Subagents หลายตัว การกำหนด Terra ให้กับบทบาทการวิจัยหรือการสำรวจจะเพิ่มประสิทธิภาพ
Luna คือ "ผู้ทำงาน" ที่รับผิดชอบด้านปริมาณและความเร็ว
Luna เป็นโมเดลที่เร็วที่สุดและมีต้นทุนต่ำที่สุด
- การจัดหมวดหมู่ไฟล์จำนวนมาก
- การตรวจสอบความไม่สอดคล้องของสัญกรณ์
- การคัดกรองเบื้องต้น
- การแปลงข้อความเทมเพลต
- การสร้างตัวเลือกจำนวนมาก
- การจัดรูปแบบให้เป็นสไตล์คงที่
เหมาะสำหรับการทำงานเบาๆ เหล่านี้ด้วยความถี่สูง แทนที่จะปล่อยให้ Luna ตัดสินใจขั้นสุดท้าย ให้มันจัดการรวบรวม จัดระเบียบ และจำกัดตัวเลือกให้แคบลง แล้วส่งกลับไปที่ Sol ในตอนท้าย การแบ่งงานแบบนี้มีประสิทธิภาพ
ถ้าไม่แน่ใจ ให้เริ่มด้วยชุดค่าผสมนี้
คุณไม่จำเป็นต้องรัน Sol ในการตั้งค่าสูงสุดทุกครั้ง Sol สำหรับศูนย์บัญชาการ Terra สำหรับการวิจัย และ Luna สำหรับการประมวลผลประจำ เหมือนทีมมนุษย์ คุณจัดสรรสมองตามน้ำหนักของงาน
Ultra ไม่ใช่แค่ "การตั้งค่าคิดลึก"
Ultra คือการตั้งค่าที่ใช้การให้เหตุผลระดับสูงสุดสำหรับโมเดลนั้นๆ ที่สำคัญยิ่งกว่านั้นคือความสามารถในการกระจายงานที่เหมาะสมไปยัง Subagents หลายตัวอย่างแข็งขัน
ในการตั้งค่าปกติ คุณสามารถทำแบบคู่ขนานได้โดยการพูดอย่างชัดเจนว่า "แบ่งงานนี้ให้สามคน" ใน Ultra Codex จะตัดสินว่า "การแบ่งงานนี้จะเร็วขึ้นและคุณภาพดีขึ้น" และสามารถแยกย่อยเป็นงานวิจัย การผลิต การตรวจสอบ ฯลฯ กล่าวโดยสรุป Ultra ไม่ใช่แค่โหมดความฉลาดสูง มันคือโหมดจัดตั้งทีม AI อัตโนมัติ
Fast mode เพิ่มความเร็วโดยไม่เปลี่ยนโมเดล
Codex ยังมี Fast mode ด้วย เพื่อแลกกับการเพิ่มความเร็วของโมเดลนั้นๆ ประมาณ 1.5 เท่า มันจะกินเครดิตใน GPT-5.6 มากกว่าปกติ คุณสามารถสลับได้ใน CLI ด้วยคำสั่งต่อไปนี้:
/fast on
/fast off
/fast status
ฟีเจอร์นี้มีไว้สำหรับการแก้ไขที่มีกำหนดส่งสั้นๆ หรือการทำงานแบบจดจ่อที่คุณต้องการลดเวลารอ Fast mode แตกต่างจาก "การลดระดับไปใช้โมเดลที่เบากว่า" ใช้เมื่อคุณต้องการเพิ่มความเร็วในขณะที่รักษาความสามารถของ Sol ไว้
2. การเลือกระหว่าง App, CLI, IDE และ Cloud
จุดแข็งของ Codex เปลี่ยนไปตามสถานที่ที่คุณใช้
ChatGPT Desktop App คือ "ห้องบัญชาการ"
ถ้าคุณต้องการวางแผนในขณะที่ดูไฟล์หลายไฟล์ ดำเนินการงานต่างๆ และจัดการกับรูปภาพ เอกสาร ตาราง เบราว์เซอร์ และเครื่องมือภายนอก เดสก์ท็อปแอปคือศูนย์กลาง คุณสามารถจัดการความคืบหน้า diffs, Subagents, Skills, Plugins และงานตามกำหนดเวลาของ Codex ได้ทั้งหมดในที่เดียว สำหรับผู้ที่ไม่ใช่วิศวกรที่ต้องการผสาน Codex เข้ากับงาน การเริ่มต้นด้วยแอปคือเส้นทางที่สั้นที่สุด
CLI คือ "ผู้ประหารชีวิตใน Terminal"
CLI เก่งในการจัดการไฟล์และโค้ดในเครื่องโดยตรง การรันคำสั่ง การทดสอบ การดำเนินการ Git และการประมวลผลอัตโนมัติแบบไม่ต้องโต้ตอบ โดยการใช้ codex exec แทนที่จะใช้แค่ codex แบบโต้ตอบ คุณสามารถรันมันจากสคริปต์หรือ CI คุณค่าของ CLI จะเพิ่มขึ้นสำหรับผู้ที่ต้องการรันกระบวนการที่ตายตัวในลักษณะเดียวกันทุกครั้ง
IDE Extension คือ "ผู้ช่วยข้างโค้ด"
ถ้าคุณต้องการดำเนินการแก้ไข อธิบาย และตรวจสอบในขณะที่ดูโค้ดที่คุณเปิดอยู่ใน VS Code หรือโปรแกรมอื่น ให้ใช้ IDE extension มันง่ายที่จะให้คำแนะนำโดยละเอียดในขณะที่สลับไฟล์เป้าหมาย ทำให้การโต้ตอบระหว่างการดำเนินการสั้นที่สุด
Cloud คือ "ผู้รับจ้างที่ปลดปล่อยคอมพิวเตอร์ของคุณ"
Cloud เหมาะสำหรับเมื่อคุณต้องการปล่อยงานที่ใช้เวลานานให้กับสภาพแวดล้อมที่แยกต่างหาก คุณสามารถทำงานอื่นๆ ไปพร้อมกันได้โดยไม่ต้องหยุดงานในเครื่องของคุณ
หลักการคิดนั้นง่าย:
- คำสั่งประจำวัน: Desktop App
- คำสั่งและการประมวลผลอัตโนมัติ: CLI
- งานที่ต้องใกล้ชิดสำหรับการนำโค้ดไปใช้: IDE
- งานแยกต่างหากที่ใช้เวลานาน: Cloud
คุณไม่จำเป็นต้องรวมทุกอย่างไว้ในที่เดียว ใช้ Codex ตัวเดียวกันจากทางเข้าที่เหมาะกับงาน
3. ให้คำแนะนำด้วยสี่องค์ประกอบ: วัตถุประสงค์ บริบท ข้อจำกัด และเงื่อนไขความสำเร็จ
GPT-5.6 Sol สามารถทำงานได้ค่อนข้างดีแม้จะมีคำแนะนำสั้นๆ ถึงกระนั้น สำหรับงานสำคัญ การให้สี่องค์ประกอบนี้จะทำให้มันเสถียรอย่างท่วมท้น
วัตถุประสงค์
ไม่ใช่เรื่องของสิ่งที่จะทำ แต่เป็นสิ่งที่คุณต้องการบรรลุ แทนที่จะ "เขียนบทความ" ให้พูดว่า "ทำให้บทความที่ช่วยให้ผู้อ่านที่ใช้ Codex แค่แชทครั้งเดียวสามารถสร้างสภาพแวดล้อมการทำงาน AI เฉพาะของตนเองได้สำเร็จ"
บริบท
ไฟล์ วัสดุ ตัวอย่าง และการตัดสินใจในอดีตไหนที่มันควรดู จุดแข็งของการให้โฟลเดอร์แก่ Codex อยู่ตรงนี้ แทนที่จะเขียนคำอธิบายใหม่ในช่องแชททุกครั้ง ให้มันอ่านวัสดุที่ถูกต้อง
ข้อจำกัด
เงื่อนไขที่ต้องปฏิบัติตาม รวมถึงจำนวนคำ น้ำเสียง ไฟล์ที่ห้ามแตะต้อง เทคโนโลยีที่จะใช้ กลุ่มเป้าหมาย ข้อมูลหลักที่ต้องอ้างอิง สำนวนต้องห้าม ฯลฯ
เงื่อนไขความสำเร็จ
อะไรที่ต้องเกิดขึ้นเพื่อให้งานเสร็จ? แทนที่จะ "เสร็จหลังจากเขียนข้อความ" ให้ตัดสินใจว่า "เสร็จหลังจากตรวจสอบข้อเท็จจริง ตรวจสอบลิงก์ ตรวจสอบจำนวนคำ ตรวจสอบความสามารถในการอ่าน และบันทึกลงในโฟลเดอร์ที่ระบุ"
การสรุปทั้งสี่สิ่งนี้จะได้รูปแบบดังต่อไปนี้:
ーーーーーーーーーーーー
【พรอมต์พื้นฐานสำหรับการมอบงานให้ Codex】
วัตถุประสงค์:
[สิ่งที่คุณต้องการบรรลุด้วยงานนี้]
บริบท:
[ไฟล์ โฟลเดอร์ วัสดุอ้างอิง การตัดสินใจในอดีตที่ต้องอ่าน]
ข้อจำกัด:
[กฎที่ต้องปฏิบัติตาม ขอบเขตการเปลี่ยนแปลง กลุ่มเป้าหมาย รูปแบบ]
เงื่อนไขความสำเร็จ:
[สิ่งที่ต้องตรวจสอบและสถานะที่ต้องเป็นเพื่อให้เสร็จสมบูรณ์]
โปรดดำเนินการวิจัยและงานที่จำเป็นด้วยตัวเอง และดำเนินการจนกว่าจะตรงตามเงื่อนไขความสำเร็จ ถามคำถามเฉพาะในจุดที่ต้องใช้การตัดสินใจ มิฉะนั้นให้ตัดสินใจและดำเนินการอย่างมีเหตุผล
ーーーーーーーーーーーー
Sol จะทำงานได้ดีกว่าเมื่อวัตถุประสงค์และเงื่อนไขความสำเร็จชัดเจน มากกว่าตอนที่คุณระบุขั้นตอนละเอียด 30 ขั้นตอน ถ้าคุณตัดสินใจทุกขั้นตอน Codex จะทำได้แค่งานที่ได้รับคำสั่งเท่านั้น ทำให้เป้าหมายชัดเจนและปล่อยให้กระบวนการมีอิสระ นั่นคือคำแนะนำสำหรับ Agent
เปลี่ยนข้อมูลที่ให้ Codex เป็นไฟล์ ไม่ใช่แชท
ยิ่งคุณใช้ Codex นานเท่าไหร่ การออกแบบไฟล์ก็สำคัญกว่าทักษะการแชทมากขึ้นเท่านั้น ถ้าคุณดำเนินการด้วยการสนทนาอย่างเดียว การตัดสินใจที่สำคัญ วัสดุอ้างอิง ผลงาน และงานต่อไปจะปะปนกันในที่เดียวกัน คุณต้องอธิบายใหม่ทุกครั้งที่เริ่มแชทใหม่ และการตัดสินใจที่ได้จะแตกต่างจากครั้งก่อน เพื่อหลุดจากสถานการณ์นี้ ให้ตัดสินใจ "สิ่งที่ต้องอ่านเพื่อเริ่มงานต่อ" สำหรับแต่ละโปรเจกต์
การกำหนดค่าขั้นต่ำคือสี่สิ่งต่อไปนี้:
Project/
├── Context.md # วัตถุประสงค์ เป้าหมาย ข้อสันนิษฐานที่ไม่ค่อยเปลี่ยน
├── Project.md # ปัญหาปัจจุบัน การตัดสินใจ งานต่อไป
├── Materials/ # วัสดุอ้างอิง ข้อมูลต้นฉบับ ข้อมูลคู่แข่ง
└── Outputs/ # ผลงานที่เสร็จสมบูรณ์
วาง "ข้อสันนิษฐานที่ไม่ค่อยเปลี่ยน" ใน Context.md
วางข้อมูลที่จำเป็นทุกครั้ง เช่น วัตถุประสงค์โปรเจกต์ กลุ่มเป้าหมาย เกณฑ์การตัดสินใจ และเงื่อนไขที่ต้องปฏิบัติตาม
วาง "สิ่งที่กำลังทำอยู่ตอนนี้" ใน Project.md
อัปเดตปัญหาปัจจุบัน แผนที่อยู่ระหว่างการพิจารณา การตัดสินใจ และการเคลื่อนไหวครั้งต่อไป แม้แชทจะเปลี่ยน คุณสามารถเริ่มจากจุดที่ค้างไว้ได้โดยการอ่านไฟล์นี้
วาง "หลักฐาน" ใน Materials
สรุปวัสดุสำหรับสร้างผลงาน เช่น บทความอ้างอิง งานวิจัยคู่แข่ง รูปภาพ บันทึกการประชุม ข้อมูล และข้อกำหนด
วาง "เวอร์ชันสุดท้าย" ใน Outputs
โดยการแยกร่างและเวอร์ชันสุดท้าย มันจะยากขึ้นที่ Codex จะเข้าใจผิดว่าแบบร่างเก่าเป็นต้นฉบับ
เมื่อคุณสร้างโครงสร้างนี้แล้ว ให้เขียนลำดับการอ่านใน AGENTS.md จากนั้นคำขอครั้งต่อไปก็จะสั้นได้:
ทำตาม AGENTS.md ของโปรเจกต์นี้และอ่าน Context.md และ Project.md ดำเนินการต่อจากจุดปัจจุบันจนกว่าจะตรงตามเงื่อนไขความสำเร็จ
แชทคือสถานที่สำหรับคำแนะนำและการตัดสินใจ ไฟล์คือสถานที่สำหรับความทรงจำและผลงาน เมื่อการแบ่งบทบาทนี้สำเร็จ Codex จะไม่ใช่คู่สนทนาครั้งเดียว แต่เป็นผู้รับผิดชอบที่ขับเคลื่อนโปรเจกต์ไปข้างหน้าอย่างต่อเนื่อง
4. เริ่มต้นด้วย Plan mode สำหรับงานที่คลุมเครือ
คุณมีสิ่งที่อยากทำ แต่ไม่รู้ว่าจะทำอะไรหรือจะเริ่มจากตรงไหน ถ้าคุณกระโดดเข้าสู่การใช้งานหรือการผลิตทันทีในสถานะนี้ ข้อสันนิษฐานจะเปลี่ยนไปกลางทาง นั่นคือจุดที่ Plan mode เข้ามา
ใน Plan mode Codex จะค้นคว้าไฟล์และสถานการณ์ก่อน ถามคำถามที่จำเป็น และสร้างพิมพ์เขียวก่อนดำเนินการ คุณสามารถสลับไปใช้ได้ด้วย /plan ใน CLI หรือ Shift+Tab ในแอป
Plan mode แข็งแกร่งสำหรับงานต่อไปนี้:
- โปรเจกต์ใหม่ที่ข้อกำหนดยังคลุมเครือ
- การเปลี่ยนแปลงที่ครอบคลุมหลายไฟล์
- การปรับปรุงใหม่ที่คุณไม่ต้องการทำลายกลไกที่มีอยู่
- การแนะนำเครื่องมือที่มีตัวเลือกมากมาย
- การออกแบบกระบวนการสำหรับโปรเจกต์ระยะยาว
- การผลิตบทความที่ตัดสินใจจากทิศทางของผู้อ่านหรือผลิตภัณฑ์
การใช้งานไม่ยาก
ーーーーーーーーーーーー
【พรอมต์สำหรับ Plan mode】
อย่าดำเนินการคำขอนี้ทันที ก่อนอื่น ให้ค้นคว้าสถานการณ์ปัจจุบัน
- รวบรวมข้อมูลที่จำเป็นเพื่อบรรลุวัตถุประสงค์
- แยกจุดที่ไม่ชัดเจนออกจากการตัดสินใจที่สำคัญ
- วางแผนขั้นตอนการดำเนินการ เป้าหมายการเปลี่ยนแปลง และวิธีการตรวจสอบ
- ถามเฉพาะสิ่งที่ฉันต้องตัดสินใจ
เมื่อแผนพร้อมแล้ว ให้นำเสนอในลำดับที่สามารถดำเนินการได้
วัตถุประสงค์: [สิ่งที่คุณต้องการบรรลุ]
ーーーーーーーーーーーー
คุณค่าของ Plan mode ไม่ใช่การระมัดระวัง มันคือการกำจัดงานซ้ำซ้อน การใช้ 15 นาทีแรกเพื่อสร้างการออกแบบที่ถูกต้องนั้นเร็วกว่าการเริ่มทำใน 10 นาทีแล้วต้องทำใหม่ 3 ชั่วโมงต่อมา ยิ่งงานใหญ่ ช่องว่างนี้ยิ่งกว้างขึ้น
5. กำจัด "การอธิบายซ้ำ" ด้วย AGENTS.md
สินทรัพย์ชิ้นแรกที่ผู้เริ่มต้นใช้ Codex ควรสร้างคือ AGENTS.md AGENTS.md คือคู่มือกฎที่ Codex อ่านก่อนเริ่มทำงาน คุณสามารถกำหนดสิ่งที่คุณต้องการให้มันปฏิบัติตามทุกครั้งในไฟล์ แทนที่จะเป็นแชท
ตัวอย่างเช่น เนื้อหาต่อไปนี้:
- ลำดับของไฟล์ที่ต้องอ่านก่อน
- วัตถุประสงค์ของโปรเจกต์
- โฟลเดอร์สำคัญ
- กฎสำหรับการเขียนและการออกแบบ
- คำสั่งทดสอบและยืนยัน
- ขอบเขตที่ห้ามเปลี่ยนแปลง
- คำจำกัดความของความสำเร็จ
- วิธีการรายงานต่อผู้ใช้
แยก Global และ Project
วางกฎส่วนตัวทั่วไปใน ~/.codex/AGENTS.md วางกฎสำหรับโปรเจกต์เฉพาะใน AGENTS.md ใต้โปรเจกต์โดยตรง ถ้าโฟลเดอร์เฉพาะต้องการกฎแยกต่างหาก คุณสามารถเพิ่ม AGENTS.md ภายในโฟลเดอร์นั้น Codex จะอ่านจากกฎระดับบนสุดและให้ความสำคัญกับไฟล์ที่ใกล้กับ workspace มากขึ้น กล่าวคือ คุณสามารถแยกกฎทั่วไปออกจากกฎเฉพาะหน้างาน
AGENTS.md แรกก็เพียงพอด้วยสิ่งนี้
AGENTS.md
วัตถุประสงค์
- สิ่งที่จะบรรลุในโปรเจกต์นี้
อ่านก่อน
- Context.md
- Project.md
- ข้อกำหนดของฟังก์ชันเป้าหมาย
กฎการทำงาน
- ห้ามลบข้อมูลที่มีอยู่
- ให้ความสำคัญกับรูปแบบการออกแบบที่มีอยู่
- ห้ามเปลี่ยนไฟล์ที่ไม่เกี่ยวข้อง
เงื่อนไขความสำเร็จ
- การใช้งานหรือผลงานที่จำเป็นเสร็จสมบูรณ์
- การทดสอบและการยืนยันการแสดงผลเสร็จสิ้น
- รายงานรายละเอียดการเปลี่ยนแปลงและผลการยืนยัน
คุณไม่จำเป็นต้องสร้างสารานุกรมตั้งแต่เริ่มต้น เมื่อ Codex ทำผิดพลาดแบบเดิม ให้เพิ่มกฎที่ทำให้เกิดข้อผิดพลาดนั้น ถ้าคุณให้คำอธิบายเดียวกันสองครั้ง แสดงว่ามันเป็นปัญหาที่กลไก ไม่ใช่การสนทนา อย่าแค่แก้ไขเฉพาะหน้า ให้เปลี่ยนเพื่อไม่ให้เกิดอีกครั้ง AGENTS.md คือสถานที่เพื่อพัฒนา Codex
6. ตั้งค่าสถานะเริ่มต้นของ Codex ด้วย config.toml
ถ้า AGENTS.md คือ "กฎการทำงาน" config.toml คือ "การตั้งค่าตัวหลักของ Codex" มันจัดการรายการต่อไปนี้เป็นหลัก:
- โมเดลที่จะใช้
- ระดับความพยายามในการให้เหตุผล
- สิทธิ์และวิธีการอนุมัติ
- Sandbox
- MCP servers
- การตั้งค่า Subagent
- Feature flags
- Profiles
วางการตั้งค่าส่วนตัวใน ~/.codex/config.toml วางการตั้งค่าเฉพาะโปรเจกต์ใน .codex/config.toml CLI, IDE extensions และเดสก์ท็อปแอปใช้เลเยอร์การตั้งค่านี้ร่วมกัน
ในการกำหนดค่าขั้นต่ำ จะมีลักษณะดังนี้:
model = "gpt-5.6"
model_reasoning_effort = "high"
approval_policy = "on-request"
[agents]
max_threads = 6
max_depth = 1
max_threads คือจำนวนเธรด Agent ที่สามารถเปิดพร้อมกันได้ และ max_depth คือความลึกที่ Subagents สามารถแตกแขนงต่อไปได้ มาตรฐานปัจจุบันคือสูงสุด 6 เธรดและความลึก 1 คุณไม่จำเป็นต้องเพิ่ม Agent จำนวนมากแบบวนซ้ำตั้งแต่แรก มันแข็งแกร่งพอแล้วที่ตัวหลักจะมอบงานให้ผู้เชี่ยวชาญหลายคนและรวบรวมผลลัพธ์
การแบ่งบทบาทของการตั้งค่าช่วยป้องกันความสับสน:
- วิธีการปฏิบัติตัว: AGENTS.md
- โมเดล สิทธิ์ และการเชื่อมต่อใดที่จะใช้: config.toml
- วิธีการดำเนินงาน: Skills
- จะทำอะไรกับบริการภายนอก: MCP / Plugins
7. เปลี่ยน "ขั้นตอนที่สำเร็จ" ให้เป็นความสามารถด้วย Skills
คุณกำลังอธิบายงานที่ทำทุกสัปดาห์ตั้งแต่ต้นทุกครั้งหรือไม่? การผลิตบทความ การวิจัยคู่แข่ง การสรุปการประชุม การเผยแพร่ การตรวจสอบ การประมวลผลใบแจ้งหนี้ การสร้างรายงาน ถ้าคุณทำซ้ำกระบวนการเดิม สิ่งที่ต้องสร้างต่อไปไม่ใช่พรอมต์ยาวๆ แต่เป็น Skill
Skill คือความสามารถเฉพาะงานที่สามารถเพิ่มให้ Codex ได้ โดยพื้นฐานแล้ว คุณเขียนสิ่งต่อไปนี้ใน SKILL.md:
- เมื่อใดควรใช้
- รับอินพุตอะไร
- ต้องอ่านอะไร
- ดำเนินการตามลำดับใด
- ใช้เครื่องมือใด
- ต้องตรวจสอบอะไรเพื่อความสำเร็จ
ถ้าจำเป็น สามารถวางวัสดุอ้างอิง เทมเพลต สคริปต์ และทรัพยากรรูปภาพในโฟลเดอร์เดียวกัน
Skills จะอ่านข้อความเต็มเมื่อจำเป็นเท่านั้น
Codex จะไม่โหลดข้อความ Skill ทั้งหมดตั้งแต่แรก มันจะดูชื่อและคำอธิบายก่อน และเปิดเฉพาะ Skill ที่ตรงกับคำขอปัจจุบัน นี่คือ "Progressive Disclosure" คุณสามารถเรียกเฉพาะความสามารถที่จำเป็นโดยไม่ต้องยัดเยียดขั้นตอนจำนวนมากลงในบริบททุกครั้ง
สามารถใช้ได้ทั้งแบบชัดเจนหรืออัตโนมัติ
เมื่อใช้แบบชัดเจน ให้ระบุ $skill-name ในพรอมต์ ถ้าคำอธิบายและเนื้อหาคำขอตรงกัน Codex ก็สามารถเลือกได้โดยอัตโนมัติเช่นกัน นั่นเป็นเหตุผลที่ คำอธิบาย สำคัญกว่าชื่อ Skill มันคือ Skill แบบไหน เมื่อใดควรใช้ และเมื่อใดไม่ควรใช้ ถ้าสิ่งนี้ชัดเจน การทำงานที่ผิดพลาดจะลดลง
งานที่ควรทำเป็น Skill
ถ้าสองข้อหรือมากกว่าต่อไปนี้ใช้ได้ ก็ถึงเวลาทำให้เป็น Skill:
- คุณทำกระบวนการเดียวกันมาแล้ว 3 ครั้งขึ้นไป
- วัสดุที่อ้างอิงเหมือนกันทุกครั้ง
- คุณภาพลดลงถ้าลำดับผิด
- มีรายการตรวจสอบที่ต้องผ่านเสมอ
- ต้องมีการประสานงานกับเครื่องมือเฉพาะ
- คุณต้องการนำไปใช้ซ้ำกับคนอื่นหรือในโปรเจกต์อื่น
แค่บันทึกพรอมต์ที่ใช้ได้ครั้งเดียวไม่ได้เพิ่มความสามารถในการทำซ้ำ มันจะกลายเป็นความสามารถก็ต่อเมื่อคุณแก้ไขอินพุต กระบวนการ เกณฑ์การตัดสินใจ และการตรวจสอบแล้ว
ถ้าคุณใช้ macOS ที่มี Computer Use คุณสามารถสร้าง Skills จากการสาธิตได้
สำหรับการดำเนินการที่ยากจะอธิบายเป็นข้อความ คุณสามารถใช้ Record & Replay ถ้าคุณแสดงการทำงานบน Mac จริงๆ Codex จะวิเคราะห์ขั้นตอนและสร้างร่างของ Skill ฟีเจอร์นี้เข้ากันได้กับ "งานที่แสดงเร็วกว่าอธิบาย" เช่น การเบิกค่าใช้จ่าย การดาวน์โหลดรายงานประจำ การโพสต์วิดีโอ และการกรอกแบบฟอร์มคงที่
8. Plugins รวม "ความสามารถ การเชื่อมต่อ และเครื่องมือ"
ถ้า Skill คือขั้นตอนการทำงาน Plugin คือแพ็คเกจที่แจกจ่ายความสามารถและการเชื่อมต่อหลายอย่าง Plugin สามารถรวมองค์ประกอบต่อไปนี้:
- Skills
- ตัวเชื่อมต่อเช่น Gmail และ Google Drive
- MCP servers
- Hooks
- ฟีเจอร์เบราว์เซอร์
- เทมเพลตงานตามกำหนดเวลา
ก่อนที่จะสร้าง Skill เอง ถ้ามี Plugin ที่เหมาะกับวัตถุประสงค์ของคุณ การใช้ของที่มีอยู่ก่อนจะเร็วกว่า ตัวอย่างเช่น โดยการเพิ่ม Plugins สำหรับ GitHub, Gmail, Google Drive และ Slack workspace ของ Codex จะขยายออกไปนอกโฟลเดอร์ในเครื่อง
ความแตกต่างระหว่าง Skill และ Plugin
Plugins สามารถใช้ได้จาก Plugin browser ในเดสก์ท็อปแอปและ CLI ใน CLI ให้เปิดด้วย /plugins หลังจากติดตั้ง การเริ่มแชทหรือเซสชันใหม่จะทำให้ Skills และเครื่องมือที่เพิ่มเข้ามาพร้อมใช้งาน
9. ให้ Codex มี "มือและเท้าสำหรับบริการภายนอก" ด้วย MCP
ไม่ว่า Codex จะแข็งแกร่งแค่ไหน มันก็ไม่สามารถแตะต้องข้อมูลล่าสุดหรือข้อมูลส่วนตัวของบริการที่ไม่ได้เชื่อมต่อได้ คุณต้องการให้มันอ่านวัสดุจาก Google Drive คุณต้องการตรวจสอบ GitHub Issues คุณต้องการดูดีไซน์ Figma คุณต้องการรับข้อมูลจาก Notion หรือระบบภายใน คุณต้องการใช้งานเบราว์เซอร์ นั่นคือจุดที่ MCP เข้ามา
MCP คือมาตรฐานทั่วไปสำหรับการเชื่อมต่อ Codex กับเครื่องมือและข้อมูลภายนอก MCP servers ส่วนใหญ่ให้สามสิ่ง:
- เครื่องมือ: การดำเนินการเช่น ค้นหา สร้าง อัปเดต และส่ง
- ทรัพยากร: การอ่านเอกสาร ข้อมูล ข้อกำหนด ฯลฯ
- พรอมต์: พรอมต์ที่ใช้ซ้ำได้สำหรับบริการนั้น
การเพิ่ม MCP เปลี่ยนรูปแบบของคำขอ
ก่อนการเชื่อมต่อ ผู้ใช้รวบรวมข้อมูลและวางลงใน Codex หลังการเชื่อมต่อ Codex สามารถรับข้อมูลที่จำเป็น สร้างผลงาน และสะท้อนกลับในสถานที่ที่จำเป็นได้ด้วยตัวเอง ตัวอย่างเช่น งานแบบนี้:
- รวบรวมวัสดุการประชุมจาก Google Drive และสรุปการตัดสินใจ
- ตรวจสอบ GitHub PRs และ Issues และดำเนินการแก้ไข
- ดู Figma เพื่อสร้างหน้าจอขึ้นมาใหม่และตรวจสอบการแสดงผลในเบราว์เซอร์
- ดึงอีเมลที่ต้องการตอบกลับจาก Gmail และสร้างร่าง
- สร้างแผนการดำเนินงานจากข้อกำหนดใน Notion
รวม Skill และ MCP
MCP เพียงอย่างเดียวแค่เพิ่มเครื่องมือ เขียนลำดับของสิ่งที่ต้องทำใน Skill "ทุกวันจันทร์ อ่านค่าจาก Drive เปรียบเทียบกับสัปดาห์ที่แล้ว ตรวจสอบค่าผิดปกติ และสร้างรายงาน" ในกรณีนี้ มือที่ดึงข้อมูลจาก Drive คือ MCP และขั้นตอนการทำงานประจำสัปดาห์คือ Skill แยกเครื่องมือและขั้นตอนออกจากกัน แนวคิดนี้ทำให้ Codex มั่นคง
10. สร้าง "ทีม AI คนเดียว" ด้วย Ultra และ Subagents
ไฮไลท์ของยุค Sol ไม่ใช่การทำให้ AI ตัวเดียวฉลาดขึ้นอีก มันคือการทำให้ AI หลายตัวทำงานพร้อมกัน Codex สามารถแบ่งงานเป็น Subagents ดำเนินการแบบคู่ขนาน และสุดท้าย Agent หลักสามารถรวมผลลัพธ์ได้
การปล่อยให้คนเดียวทำทุกอย่างทำให้บริบทปนเปื้อน
ถ้าคุณใส่บันทึกการวิจัยยาวๆ ผลการทดสอบ ข้อผิดพลาด แผนตัวเลือก และแผนที่ถูกปฏิเสธลงในแชทเดียว วัตถุประสงค์และการตัดสินใจที่สำคัญจะถูกฝัง นี่คือมลพิษทางบริบท (Context pollution) ยิ่งไปกว่านั้น เมื่อข้อมูลที่ไม่จำเป็นเพิ่มขึ้นเรื่อยๆ ความแม่นยำในการตัดสินใจจะลดลงในช่วงครึ่งหลังของการสนทนาที่ยาว ดังนั้น ให้ย้ายงานหนักระหว่างกลางไปยัง Agent ที่แยกต่างหาก
- หลัก: วัตถุประสงค์ การตัดสินใจ การรวมผลลัพธ์ เวอร์ชันสุดท้าย
- นักวิจัย: วัสดุ คู่แข่ง ข้อเท็จจริง ตัวเลข
- ผู้สร้าง: ร่างแรก การนำไปใช้ การสร้างตัวเลือก
- ผู้ตรวจสอบ: ข้อผิดพลาด การละเว้น การเปลี่ยนแปลง การทดสอบ
ส่งเฉพาะข้อสรุปที่จัดระเบียบแล้วกลับไปยังหลัก ไม่ใช่บันทึกการทำงานยาวๆ ของผู้รับผิดชอบแต่ละคน
บทบาทในตัว 3 บทบาท
Codex มี Agent พื้นฐานสามตัว:
default: วัตถุประสงค์ทั่วไปworker: ดำเนินการและแก้ไขexplorer: อ่านและค้นคว้าโค้ดและวัสดุ
สามสิ่งนี้เพียงพอแล้วในตอนแรก ถ้าคุณต้องการแก้ไขบทบาทเพิ่มเติม คุณสามารถสร้าง Custom Agents วางไฟล์ TOML ใน ~/.codex/agents/ สำหรับการใช้งานส่วนตัว และ .codex/agents/ สำหรับการใช้งานในโปรเจกต์ นอกจากชื่อ คำอธิบาย และคำแนะนำการมอบหมาย คุณยังสามารถเปลี่ยนโมเดล Reasoning, Sandbox, MCP และ Skills สำหรับแต่ละบทบาทได้
ทีม 4 คนแรกที่ควรสร้าง
ーーーーーーーーーーーー
【สำหรับคัดลอก-วาง: Sol Command Center + ทีม AI 3 คน】
ดำเนินการงานนี้ด้วย Agent หลักและ Subagents สามตัว
Agent หลัก:
จัดการวัตถุประสงค์และเงื่อนไขความสำเร็จ และสร้างเวอร์ชันสุดท้ายจากผลลัพธ์ของผู้รับผิดชอบแต่ละคน
หัวหน้านักวิจัย:
รวบรวมข้อมูลหลัก ตัวอย่าง ตัวเลข และข้อสันนิษฐานที่จำเป็น และส่งคืนพร้อมหลักฐาน
หัวหน้าฝ่ายผลิต:
นี่คือคำแปลภาษาไทยของเนื้อหาที่ให้มา โดยรักษาโครงสร้าง Markdown, HTML tags, payload-block tags, และลิงก์ไว้ครบถ้วน พร้อมใช้ภาษาที่เป็นธรรมชาติและเป็นทางการเล็กน้อยตามเนื้อหาต้นฉบับ:
สร้างร่างแรกของผลงานตามผลการวิจัยและวัตถุประสงค์
หัวหน้าฝ่ายตรวจสอบ:
ตรวจสอบข้อเท็จจริง ข้อบกพร่อง คุณภาพ ความสามารถในการอ่าน และการเบี่ยงเบนจากวัตถุประสงค์
ดำเนินงานที่สามารถทำได้อย่างอิสระแบบขนาน รอให้หัวหน้าทุกคนทำงานเสร็จ จากนั้นให้เอเจนต์หลักรวบรวมผลลัพธ์
ผลลัพธ์สุดท้าย:
- เวอร์ชันสุดท้าย
- เหตุผลในการนำไปใช้
- ประเด็นที่แก้ไขในการตรวจสอบ
- การตัดสินใจที่เหลืออยู่
วัตถุประสงค์: [ใส่วัตถุประสงค์ที่นี่]
เงื่อนไขการเสร็จสิ้น: [ใส่เงื่อนไขการเสร็จสิ้นที่นี่]
ーーーーーーーーーーーー
การทำงานแบบขนาน "งานที่ทำได้โดยอิสระ"
การเพิ่มเอเจนต์ย่อยไม่ได้ทำให้ทุกอย่างเร็วขึ้นเสมอไป สิ่งที่ได้ผลดีคืองานที่สามารถทำพร้อมกันได้
- การค้นคว้าจากแหล่งข้อมูลหลายแห่ง
- การตรวจสอบแยกในมุมมองด้านความปลอดภัย คุณภาพ และความสามารถในการอ่าน
- การจำแนกไฟล์จำนวนมาก
- การสร้างแผนหลายแผน
- การทดสอบและการวิเคราะห์ล็อก
ในทางกลับกัน ถ้ามีหลายคนแก้ไขไฟล์เดียวกันพร้อมกัน ก็จะเกิดความขัดแย้ง ให้รวมบทบาทการเขียนไว้ที่คนเดียว และกระจายบทบาทการอ่าน ค้นคว้า และตรวจสอบให้ทำงานแบบขนาน นี่คือคำตอบแรกที่ถูกต้อง
11. แยกหัวหน้าฝ่ายผลิตและหัวหน้าฝ่ายตรวจสอบ
การขอให้ Codex "สร้างแล้วตรวจสอบว่ามีปัญหาหรือไม่" จะทำให้การผลิตและการยืนยันเกิดขึ้นจากมุมมองเดิมซ้ำ ๆ หากต้องการปรับปรุงคุณภาพ ให้แยกบทบาทตั้งแต่เริ่มต้น
สำหรับโค้ด:
- หัวหน้าฝ่าย implement
- หัวหน้าฝ่ายทดสอบ
- หัวหน้าฝ่ายความปลอดภัย
- หัวหน้าฝ่ายตรวจสอบการบำรุงรักษา
สำหรับบทความ:
- หัวหน้าฝ่ายเขียน
- หัวหน้าฝ่ายตรวจสอบข้อเท็จจริง
- หัวหน้าฝ่ายมุมมองผู้เริ่มต้น
- หัวหน้าฝ่ายตรวจสอบความสอดคล้องของชื่อเรื่อง
สำหรับเอกสาร/สื่อ:
- หัวหน้าฝ่ายโครงสร้าง
- หัวหน้าฝ่ายยืนยันตัวเลข
- หัวหน้าฝ่ายยืนยันการออกแบบ
- หัวหน้าฝ่ายมุมมองผู้ตัดสินใจ
แม้จะเป็นผลงานชิ้นเดียวกัน ประเด็นที่ถูกหยิบยกขึ้นมาจะเปลี่ยนไปเมื่อบทบาทที่มองเปลี่ยนไป Codex มี /review เช่นกัน คุณสามารถดำเนินการตรวจสอบหลังจาก implement โดยกำหนดเป้าหมายที่การเปลี่ยนแปลงที่ยังไม่ commit, commit ที่เฉพาะเจาะจง, diff กับ branch หลัก ฯลฯ อย่างไรก็ตาม การเรียกใช้ฟังก์ชัน review ยังไม่เพียงพอ ต้องตัดสินใจว่าจะค้นหาอะไรว่าเป็นปัญหา
ーーーーーーーーーーーー
【สำหรับการคัดลอก-วาง: การตรวจสอบก่อนเสร็จสิ้น】
ตรวจสอบผลงานนี้ในฐานะผู้ตรวจสอบที่แยกจากผู้สร้าง
ลำดับความสำคัญ:
- ข้อบกพร่องที่ขัดขวางการบรรลุวัตถุประสงค์
- ข้อผิดพลาดในข้อเท็จจริง ตัวเลข หรือข้อกำหนด
- ข้อสันนิษฐานหรือขั้นตอนที่ขาดหายไป
- จุดที่ผู้ใช้จะสับสน
- ความสามารถในการอ่าน ความสามารถในการบำรุงรักษา และการแสดงออก
แสดงปัญหาตามลำดับความสำคัญ และระบุส่วนที่เกี่ยวข้องพร้อมข้อเสนอแนะในการแก้ไข หากไม่มีปัญหา ให้แสดงขอบเขตที่ตรวจสอบแล้วและความเสี่ยงที่เหลืออยู่โดยย่อ
เงื่อนไขการเสร็จสิ้น: [ใส่เงื่อนไขการเสร็จสิ้นที่นี่]
ーーーーーーーーーーーー
อย่าพูดว่า "ทำให้ดูดี" ให้กำหนดเงื่อนไขการผ่าน การตรวจสอบก็เป็นส่วนหนึ่งของงานเช่นกัน
12. ออกแบบ "ขอบเขตที่มอบหมาย" ด้วยสิทธิ์และ Sandbox
Codex สามารถอ่านและเขียนไฟล์ รันคำสั่ง และดำเนินการกับบริการภายนอกได้ ดังนั้นการออกแบบสิทธิ์จึงสำคัญพอ ๆ กับความฉลาดของโมเดล มีแนวคิดพื้นฐาน 3 ข้อ:
- อ่านอย่างเดียว: แค่อ่าน
- เขียนในพื้นที่ทำงาน: สามารถเปลี่ยนแปลงได้ภายในโฟลเดอร์พื้นที่ทำงาน
- เข้าถึงเต็มรูปแบบ: สามารถเข้าถึงได้ในวงกว้าง
ให้ใช้การเขียนในพื้นที่ทำงานเป็นฐานสำหรับการผลิตและการทำงานประจำวัน เพิ่มขอบเขตที่จำเป็นเมื่อต้องการเครือข่ายภายนอกหรือโฟลเดอร์แยกต่างหาก และปล่อยให้เป็นการยืนยันสำหรับการดำเนินการที่แก้ไขยาก เช่น การลบ การส่ง การเผยแพร่ การชำระเงิน และการเปลี่ยนแปลงบริการภายนอก นี่ไม่ใช่การทำให้ Codex อ่อนแอลง แต่เป็นพื้นฐานสำหรับการมอบหมายงานใหญ่ ๆ อย่างสบายใจ หากสิทธิ์ไม่ชัดเจน Codex จะหยุดที่การดำเนินการที่จำเป็น หรือในทางกลับกันก็มีขอบเขตที่กว้างเกินไป การตัดสินใจว่า "สามารถดำเนินการอัตโนมัติได้ไกลแค่ไหน" ก่อนจะช่วยลดจำนวนการยืนยันระหว่างทำงาน
13. ทำให้งานซ้ำซากเป็นอัตโนมัติด้วย Automations
เมื่องานเสร็จสมบูรณ์ครั้งหนึ่งแล้ว ให้ทำเป็นอัตโนมัติต่อไป การใช้ Scheduled tasks ของ Codex คุณสามารถรันงานตามเวลาที่กำหนด เป็นระยะ หลังเหตุการณ์ หรือภายใต้เงื่อนไขการตรวจสอบได้ เช่น การใช้งานแบบนี้:
- ทุกเช้า รวบรวมข่าวล่าสุดในอุตสาหกรรม AI
- ทุกสัปดาห์ ตรวจสอบบทความใหม่จากคู่แข่ง
- ทุกคืน ตรวจสอบการเปลี่ยนแปลงของโปรเจกต์
- ตรวจสอบสถานะ PR เป็นประจำ และตอบกลับประเด็นใหม่ที่ถูกหยิบยกขึ้นมา
- สร้างรายงานเมื่อต้นเดือน
- ติดตามจนกว่างานที่ใช้เวลานานจะเสร็จในแชทเดียวกัน
แยกแยะระหว่างงานที่ทำครั้งเดียวกับแชทต่อเนื่อง
หากต้องการผลลัพธ์ที่เป็นอิสระทุกครั้ง ให้ใช้ Standalone Scheduled task หากต้องการสืบทอดการสนทนาก่อนหน้าและทำงานเดียวกันต่อไป ให้สร้างกำหนดการภายในแชทที่มีอยู่
ทำให้แอปทำงานต่อไปสำหรับงานในเครื่อง
Scheduled tasks ที่จัดการโปรเจกต์ท้องถิ่นในแอปเดสก์ท็อปต้องการให้คอมพิวเตอร์และแอปทำงานอยู่ ในโปรเจกต์ Git คุณสามารถเลือกได้ว่าจะใช้โฟลเดอร์พื้นที่ทำงานปัจจุบันโดยตรงหรือแยกกับ Worktree อื่น หากมีความเป็นไปได้ว่างานเป็นระยะจะแตะต้องไฟล์ที่คุณกำลังทำงานอยู่ การจัดการจะง่ายกว่าโดยการแยกกับ Worktree
การทำงานอัตโนมัติจะทำ "หลังจากที่ทำด้วยตนเองสำเร็จแล้ว"
อย่าเพิ่งรันทุกวันทันที ให้ทำให้เสร็จครั้งหนึ่งในแชทปกติก่อน จากนั้นทำให้เป็น Skill สุดท้ายจึงใส่เป็น Scheduled task ทำด้วยตนเองสำเร็จ → ทำให้เป็น Skill → ทำให้เป็นอัตโนมัติ ทำตามลำดับนี้ คุณจะไม่ผลิตงานที่ผิดพลาดออกมาทุกวัน
14. เริ่มต้นจากการกำหนดค่าตามวัตถุประสงค์นี้
คุณไม่จำเป็นต้องใช้ฟีเจอร์ทั้งหมด สร้างจากเลเยอร์ที่จำเป็นสำหรับงานของคุณ
ผู้เริ่มต้นใช้ AI / พนักงาน
- แอปเดสก์ท็อป
- GPT-5.6 Sol หรือ Terra
- วัตถุประสงค์, บริบท, ข้อจำกัด, เงื่อนไขการเสร็จสิ้น
- โหมดแผน
- AGENTS.md สำหรับโปรเจกต์
เป้าหมายแรกคือการส่งมอบโฟลเดอร์หนึ่งให้ Codex และดำเนินการตั้งแต่การวางแผนจนเสร็จสมบูรณ์
การผลิตบทความ, SNS, เนื้อหา
- ใช้ Sol สำหรับโครงสร้างและการแก้ไขครั้งสุดท้าย
- ใช้ Terra สำหรับการวิจัย
- บันทึกกฎการผลิตใน AGENTS.md
- ทำให้การผลิตบทความและการสร้างโพสต์เป็น Skill
- เชื่อมต่อ Web search และ Drive กับ MCP
- ทำให้หัวหน้าฝ่ายตรวจสอบข้อเท็จจริงเป็นเอเจนต์ย่อย
- ทำให้การวิจัยหัวข้อเป็น Scheduled task
ด้วยการกำหนดค่านี้ มันไม่ใช่แค่การสร้างข้อความ แต่เชื่อมต่อการวางแผน การวิจัย การผลิต การยืนยัน และการปรับปรุงครั้งต่อไป
เจ้าของคนเดียว / บริษัทคนเดียว
- แยกโฟลเดอร์และต้นฉบับสำหรับแต่ละงานทางธุรกิจ
- วางกฎทั่วไปใน AGENTS.md
- ทำให้งานประจำเป็น Skills
- เชื่อมต่อ Gmail, Drive, GitHub ฯลฯ ด้วย Plugins/MCP
- สร้าง Custom Agents สำหรับการวิจัย การผลิต และการตรวจสอบ
- กระจายหลายโปรเจกต์ด้วย Ultra
- ย้ายงานที่มั่นคงไปยัง Automations
เป้าหมายไม่ใช่การเป็นคนที่ถาม AI แต่เป็นคนที่กระจายงานให้ AI และตัดสินผลลัพธ์เท่านั้น
นักพัฒนา / ทีมผลิต
- CLI หรือ IDE Extension
- AGENTS.md ใต้ repository โดยตรง
.codex/config.toml- กำหนด lint, test, และ build เป็นเงื่อนไขการเสร็จสิ้น
- กระจายการ implement, การทดสอบ, และการตรวจสอบระหว่างเอเจนต์ย่อย
/reviewและการรวม GitHub- ย้ายการตรวจสอบ PR และการตรวจสอบเป็นระยะไปยัง Scheduled tasks
อย่าหยุดแค่การสร้างโค้ด ให้เสร็จวงจรผ่านการทดสอบ การยืนยัน diff การตรวจสอบ และการตอบกลับ PR
15. 7 ลักษณะทั่วไปของคนที่ล้มเหลวกับ Codex
- ยัดทุกอย่างลงในแชทเดียว หากคุณค้นคว้า ผลิต แก้ไข และโปรเจกต์แยกกันในแชทเดียวกัน วัตถุประสงค์จะถูกกลบ แยกโปรเจกต์และโหลดงานกลางที่หนักไปยังเอเจนต์ย่อย
- อธิบายสิ่งเดิมทุกครั้ง ย้ายข้อสันนิษฐานที่เกิดซ้ำไปยัง AGENTS.md และกระบวนการที่เกิดซ้ำไปยัง Skills อย่าทำให้การสนทนาสั้นลง แต่เปลี่ยนคำอธิบายให้เป็นสินทรัพย์
- ไม่มีคำจำกัดความของ "เสร็จสิ้น" หากคุณแค่ทำเสร็จ ผลงานที่ไม่ได้รับการตรวจสอบจะเพิ่มขึ้น รวมการทดสอบ รายการยืนยัน ตำแหน่งที่บันทึก และรูปแบบในเงื่อนไขการเสร็จสิ้น
- ประมวลผลทุกอย่างด้วย Sol Ultra แยกงานหนักและงานเบา การตัดสินใจครั้งสุดท้ายคือ Sol งานประจำคือ Terra และการประมวลผลปริมาณมากคือ Luna การแบ่งนี้จะจัดระเบียบความเร็วและการใช้งาน
- แค่เพิ่มเครื่องมือ แม้คุณจะใส่ MCPs หรือ Plugins จำนวนมาก พวกมันจะไม่ทำงานหากไม่ได้กำหนดกระบวนการใช้งาน ตัดสินใจงานก่อนแล้วเชื่อมต่อเฉพาะเครื่องมือที่จำเป็น
- ให้หัวหน้าฝ่ายผลิตให้คะแนนตัวเอง แยกบทบาทผู้สร้างและผู้ยืนยัน สำหรับผลงานสำคัญ ให้ใช้สายตาของเอเจนต์อื่นเข้ามาตรวจสอบ
- ทำอัตโนมัติก่อนที่จะสำเร็จ หากคุณใส่ขั้นตอนที่คุณไม่แน่ใจว่าจะได้ผลลงใน Scheduled task งานยืนยันจะเพิ่มขึ้น ทำให้เสร็จด้วยตนเอง ปรับให้เป็น Skill จากนั้นจึงทำอัตโนมัติ
ทำให้สภาพแวดล้อม Codex ในยุค Sol ของคุณสมบูรณ์ใน 7 วัน
คุณไม่จำเป็นต้องเรียนรู้ทุกอย่างในวันนี้ สร้างงานทีละเลเยอร์ต่อวัน
วันที่ 1: มอบหมายงานหนึ่งให้เสร็จสิ้น
เปิดโฟลเดอร์เป้าหมายและระบุวัตถุประสงค์ บริบท ข้อจำกัด และเงื่อนไขการเสร็จสิ้น ขอผลงาน ไม่ใช่คำถาม
วันที่ 2: ให้โหมดแผนออกแบบ
เลือกงานที่คลุมเครือหนึ่งงานและมอบหมายให้ค้นคว้า ถามคำถาม และวางแผน สัมผัสถึงการกำจัดงานซ้ำก่อนดำเนินการ
วันที่ 3: สร้าง AGENTS.md
เขียนเพียง 5 สิ่งที่คุณอธิบายทุกครั้ง รวมถึงลำดับการอ่าน กฎที่ต้องปฏิบัติตาม และเงื่อนไขการเสร็จสิ้นก็เพียงพอ
วันที่ 4: ทำให้งานที่ทำซ้ำเป็น Skill
เลือกงานที่คุณทำอย่างน้อยสัปดาห์ละครั้งและกำหนดวิธีการป้อนข้อมูล กระบวนการ และวิธีการยืนยัน
วันที่ 5: เชื่อมต่อบริการภายนอกหนึ่งอย่าง
เชื่อมต่อบริการที่คุณใช้บ่อยที่สุด เช่น Drive, GitHub, Gmail หรือเบราว์เซอร์ ผ่าน Plugin หรือ MCP
วันที่ 6: รันเอเจนต์ย่อย 3 ตัว
แบ่งเป็นการค้นคว้า การผลิต และการตรวจสอบ และรวบรวมผลลัพธ์กับ Sol ในที่สุด คุณจะเห็นความแตกต่างจากเมื่อคนเดียวดำเนินการตามลำดับสำหรับงานเดียวกัน
วันที่ 7: เพิ่มการตรวจสอบและระบบอัตโนมัติ
เพิ่มการตรวจสอบในเงื่อนไขการเสร็จสิ้นและย้ายงานที่มั่นคงหนึ่งงานไปยัง Scheduled task
เมื่อถึงจุดนี้ Codex ไม่ใช่แค่แชทครั้งเดียว มันกลายเป็นสภาพแวดล้อมการทำงานที่อ่านกฎของคุณ ใช้เครื่องมือที่จำเป็น แบ่งงานระหว่างหัวหน้าหลายคน และยืนยันจนกว่าจะเสร็จสมบูรณ์
ตารางอ้างอิงด่วนสำหรับดูเป็นครั้งสุดท้าย
สิ่งที่จำเป็นในยุค Sol ไม่ใช่ทักษะการเขียน Prompt แต่เป็นทักษะการออกแบบงาน
ด้วย GPT-5.6 Sol, Codex ฉลาดขึ้นมาก แต่การเปลี่ยนแปลงที่ยิ่งใหญ่จริง ๆ ไม่ใช่ตัวเลขบนแผนภูมิประสิทธิภาพ มันคือการที่ AI สามารถคิดเกี่ยวกับงานที่จำเป็นจากวัตถุประสงค์ อ่านเนื้อหา ใช้เครื่องมือ กระจายไปยัง AI หลายตัว และดำเนินการจนเสร็จสมบูรณ์โดยที่มนุษย์ไม่ต้องสั่งทีละขั้นตอน
จากนี้ไป ความแตกต่างจะเกิดขึ้นไม่ใช่โดยคนที่รู้ prompt มหัศจรรย์ แต่โดยคนที่สามารถเตรียมบริบทที่ถูกต้อง คนที่สามารถเปลี่ยนการตัดสินใจซ้ำ ๆ เป็นกฎ คนที่สามารถบันทึกกระบวนการที่สำเร็จเป็น Skills คนที่สามารถเชื่อมต่อเครื่องมือที่จำเป็นด้วย MCP คนที่สามารถแบ่งงานระหว่าง AI หลายตัวและจัดการด้วยเงื่อนไขการเสร็จสิ้น
กล่าวอีกนัยหนึ่ง ไม่ใช่คนที่ใช้ AI แต่เป็นคนที่สร้างสภาพแวดล้อมที่ AI สามารถทำงานได้
ยุคที่แค่เปิด Codex แล้วโยนคำถามทันทีนั้นสิ้นสุดลงแล้ว
สร้างโฟลเดอร์ วางต้นฉบับ กำหนดกฎด้วย AGENTS.md ให้ Skills เรียนรู้งาน มอบมือและเท้าด้วย MCP เคลื่อนย้ายทีมด้วย Ultra ยืนยันความสมบูรณ์ด้วย Review ทำให้เป็นอัตโนมัติตั้งแต่ครั้งต่อไปด้วย Automation
สำหรับผู้ที่สร้างวงจรนี้ Codex จะหยุดเป็น "AI ที่สะดวก" มันจะกลายเป็นทีมที่ทำงานนานกว่าคุณ อ่านข้อมูลมากกว่าคุณ และดำเนินงานตามกฎของคุณ นั่นคือ Codex ในยุค GPT-5.6 Sol
สำหรับผู้ที่ต้องการทราบภาพรวมของการบรรลุผลลัพธ์ในงานเสริมควบคู่ไปกับบทความนี้ 🎁
ปัจจุบันบน LINE ทางการ
"กลยุทธ์ครบวงจรสำหรับงานเสริม SNS แบบ Kuroneko: ชุดโบนัสใหญ่ 5 รายการ"
กำลังแจกฟรี 🎁
เนื่องจากเนื้อหานี้เดิมทีวางแผนจะเผยแพร่เป็นเนื้อหาที่ต้องชำระเงิน
การแจกจะสิ้นสุดเมื่อถึงจำนวนที่กำหนด
โปรดรับไปพร้อมกับบทความในขณะที่ยังมีโอกาส
▼▼▼
▶︎▶︎▶︎ รับโบนัส 5 รายการ
เอาล่ะ มาถึงเนื้อหาหลักกัน!
