Codex แย่ลงไม่ใช่เวทมนตร์: ลดข้อผิดพลาด แล้วค่อยรีเซ็ต context

สรุปสั้นก่อน:

1. เพิ่ม DO NOT send optional commentary ลงใน AGENTS.md ของคุณ ไม่ว่าจะเป็นระดับ global หรือระดับโปรเจกต์ วิธีนี้อาจลดโอกาสที่ Codex จะ “แย่ลง” ได้
2. AI ไม่เสถียร แต่มีความคิดสร้างสรรค์ คล้ายมนุษย์ มันแก้ปัญหาบางอย่างที่ซอฟต์แวร์แบบ deterministic ล้วนทำไม่ได้ หน้าที่ของเราคือหาสมดุลระหว่างสองโลกนี้
3. เมื่อเจอความล้มเหลวแปลก ๆ ให้คิดลึกลงไปอีกชั้น มักมี mitigation ที่ใช้งานได้จริงซ่อนอยู่ในรูปทรงของปัญหา

---

เวลาคนรู้สึกว่า Codex “แย่ลง” ผมไม่คิดว่ามันแปลว่าผู้ให้บริการตั้งใจลดความสามารถของโมเดลเสมอไป คำอธิบายที่มีประโยชน์กว่าคือ ในบางช่วง บางเวอร์ชัน หรือบาง context ความน่าจะเป็นที่จะผิดพลาดสูงขึ้น AI ไม่เสถียรเหมือนซอฟต์แวร์ดั้งเดิมที่ logic เดิมให้ผลลัพธ์เดิมอย่างเชื่อถือได้ ทุกขั้นของมันถูกสร้างจาก context พร้อมความสุ่มบางส่วน เมื่อทุกอย่างไปได้ดี มันให้ความรู้สึกเหมือนการร่วมงานกัน แต่เมื่อผิดทาง context จะกลายเป็นตัวขยายผล: คำอธิบายที่ผิดหนึ่งครั้ง tool call ปลอมหนึ่งครั้ง หรือสมมติฐานที่ไม่ได้ตรวจสอบหนึ่งข้อ สามารถเข้าไปอยู่ใน context และส่งผลต่อการตัดสินครั้งถัดไปได้

ดังนั้นเมื่อ AI ผิดพลาดเป็นครั้งคราว ปัญหาใหญ่ที่สุดไม่ใช่คำตอบที่ผิดนั้นเอง แต่คือคำตอบนั้นจะกลายเป็นวัตถุดิบสำหรับคำตอบต่อไป ถ้าคุณถามต่อ โมเดลอาจถือความผิดเดิมเป็นข้อเท็จจริง ถ้าคุณให้มันแก้ มันอาจวน patch อยู่รอบ premise ที่ผิด ถ้าคุณเพิ่ม context มันก็อาจหา noise เพิ่มมาเย็บเป็นคำอธิบายใหม่ นี่คือสิ่งที่หลายคนรู้สึกว่า “แย่ลง” หรือเหมือนติด loop

DO NOT send optional commentary

วันนี้ผมเห็นโพสต์บน X บอกว่าการเพิ่ม DO NOT send optional commentary ลงใน AGENTS.md สามารถช่วยลดอาการเสื่อมของ Codex 5.5 ได้มาก

ผมตามรอยกลับไปที่ discussion ต้นทางบน Linux.do ในสภาพแวดล้อมทดสอบของผู้เขียน ความแม่นยำดีขึ้นอย่างเห็นได้ชัด แต่ผู้เขียนก็ย้ำหลายครั้งว่าวิธีนี้แค่ช่วยบรรเทา ไม่ได้กำจัดปัญหา

ผมคิดว่าสิ่งที่สังเกตได้นี้สอดคล้องกับสมมติฐานของผม ประโยคนี้ไม่ใช่เวทมนตร์ มันได้ผลเพราะลด output เสริมของโมเดล เวลาที่ Codex ทำงาน มันมักเพิ่มคำอธิบายระหว่างทาง บันทึกความคืบหน้า การเดา และ summary รอบงานจริง ๆ ในสภาวะปกติ คำเหล่านี้ช่วยให้สื่อสารกันง่ายขึ้น แต่เมื่อโมเดลอยู่ในสภาพไม่ดี คำ “เสริม” เหล่านี้อาจกลายเป็นการปนเปื้อน: มันอาจรีบสรุปเร็วเกินไป อธิบายขั้นตอนที่ไม่ได้เกิดขึ้นจริง หรือผสม tool call เข้ากับภาษาธรรมชาติ

พูดให้น้อยลงไม่ได้ทำให้โมเดลฉลาดขึ้น แต่เมื่อ context ที่ไม่เกี่ยวข้องน้อยลง โอกาสที่โมเดลจะพาตัวเองออกนอกทางก็น้อยลงด้วย

นี่ไม่ใช่ปัญหาเฉพาะ Codex

ผมเคยเจอปัญหาแบบเดียวกันกับ Claude โมเดลพิมพ์ข้อความที่ดูเหมือน tool invocation แทนที่จะดำเนิน preview flow ต่อไปตามปกติ แล้วปัญหาเดิมก็เกิดซ้ำใน conversation นั้น พอเปลี่ยนไป conversation ใหม่ ปัญหากลับหายไปทันที พฤติกรรมแบบนี้บอกว่าปัญหาไม่ได้อยู่แค่ในโมเดลเดียว แต่มันอาจเกิดใน toolchain ของ agent ได้ด้วย: โมเดล, system prompt, protocol ของ tool, context window และ state ปัจจุบันของ service ต้องเรียงตัวกันถูกต้อง ถ้าส่วนใดส่วนหนึ่งสั่น output ก็อาจไม่เสถียร

เมื่อสัญญาณแบบนี้ปรากฏ การขอให้แก้ต่อใน conversation เดิมมักไม่ใช่การกู้คืน มันอาจทำให้การปนเปื้อนใหญ่ขึ้น เพราะโมเดลได้เขียนเรื่องเล่าไว้ใน context แล้วว่า “เมื่อกี้เกิดอะไรขึ้น” แม้เรื่องเล่านั้นจะผิดก็ตาม

สองทาง: ป้องกัน และตัดขาดทุน

ทางแรกคือการลดความน่าจะเป็นของความผิดพลาด ใส่กฎของโปรเจกต์ไว้ใน AGENTS.md ให้ agent อ่านโค้ดก่อนแก้ ลด commentary ที่ไม่จำเป็น แบ่งงานใหญ่เป็นเป้าหมายเล็ก ๆ ให้มันรัน test และรายงานผลการตรวจสอบ บังคับให้ตรวจสมมติฐานสำคัญก่อน วิธีเหล่านี้ไม่ได้ทำให้ AI เชื่อถือได้สมบูรณ์ แต่ลดพื้นที่ให้โมเดล improvise ในจุดที่ไม่แน่นอน

ทางที่สองคือการตัดขาดทุนเร็ว ถ้ามันแก้ bug เดิมซ้ำ ๆ เขียนคำอธิบายยาวขึ้นแต่โค้ดไม่ดีขึ้น ทำรูปแบบ output พัง พิมพ์ tool call เป็นข้อความ หรือไม่สนใจ constraint ที่คุณเพิ่งให้ไป อย่าพยายามกู้ thread เดิมต่อไปเรื่อย ๆ โดยมากทางที่ดีกว่าคือเริ่ม conversation ใหม่ แล้วให้ brief ที่สะอาดและย่อแล้ว: เป้าหมาย, error ปัจจุบัน, ไฟล์สำคัญ และข้อเท็จจริงที่ตรวจสอบแล้ว

นี่ก็เป็นหนึ่งในจุดแข็งของ agent: มันบันทึกผลงานลง disk ได้ คุณจึงใช้หลาย conversation เพื่อทำงานเดียวให้เสร็จได้

มองมันเป็น hygiene ทางวิศวกรรม เมื่อ context สกปรก ก็ทำความสะอาด context เมื่องานใหญ่เกินไป ก็แบ่งงาน เมื่อ output เริ่มปนเปื้อนตัวเอง ก็ตัดสายโซ่

สรุป

อาการ Codex แย่ลงไม่ใช่เรื่องเหนือธรรมชาติ และ prompt เพียงบรรทัดเดียวแก้ไม่ได้ทั้งหมด ควรมองมันเป็นปัญหาความน่าจะเป็นบวกกับปัญหา context: บางช่วงความผิดพลาดมีแนวโน้มเกิดมากขึ้น และเมื่อความผิดพลาดหนึ่งครั้งเข้าไปอยู่ใน context ความผิดพลาดถัดไปก็มีแนวโน้มมากขึ้นด้วย

DO NOT send optional commentary คุ้มค่าที่จะลอง เพราะต้นทุนต่ำและ tradeoff ชัดเจน: คุณจะได้ note ระหว่างทางน้อยลง แต่ habit ที่กว้างกว่านั้นสำคัญกว่า ลด noise เมื่อทำได้ ตรวจสอบเมื่อทำได้ และเมื่อ conversation เริ่มวน loop อย่าต่อสู้กับ loop นั้น ย้ายงานไปยัง conversation ที่สะอาด แล้วทำต่อจากตรงนั้น

ถ้าคุณมีแนวทางที่ดีกว่านี้ ผมอยากฟัง ถ้าคุณมีคำถามเกี่ยวกับการใช้ AI agent หรือ vibe coding ฝาก comment ไว้คุยกันได้