คนส่วนใหญ่ยังคงใช้ coding agent เหมือน autocomplete เจ๋งๆ หรือแชทกล่องเดียว ซึ่งเสียโอกาสไปมาก รูปแบบที่ดีกว่าคือมอง Codex เป็น operating loop ที่คงทน:
- เธรดถาวรสำหรับงานที่ทำต่อเนื่องยาวนาน
- โน้ตที่บันทึกลงดิสก์เพื่อให้มีความจำที่ตรวจสอบและ diff ได้
- พื้นผิวเบราว์เซอร์สำหรับการตรวจสอบด้วยภาพจริง
- แอป HTML ขนาดเล็กแทน Markdown ที่ตายแล้วเมื่อต้องการการโต้ตอบ
- ระบบอัตโนมัติสำหรับลูปติดตามผล
- การตรวจสอบที่ชัดเจนก่อนประกาศว่าเสร็จ
การเปลี่ยนแปลงครั้งใหญ่คือ: Codex ไม่ควรแค่ตอบ prompt เท่านั้น มันควรทำให้งานดำเนินต่อไปผ่านพื้นผิวต่างๆ
เธรด Codex ที่มีประโยชน์สามารถตรวจสอบแอปในเครื่อง เปิด artifact แบบคงที่ ตรวจสอบสไลด์ที่เรนเดอร์ ดู PR อัปเดตโน้ตโปรเจกต์ และกลับมาพร้อมสิ่งที่ตรวจสอบได้ นั่นคือ workflow ที่แตกต่างจาก "สร้าง code แล้วหยุด" อย่างมาก
ฉันเพิ่มสิ่งนี้ลงในการตั้งค่า Codex เป็นคำสั่งถาวร (วางที่ Settings > Personalization > Custom instructions):
1ทำงานเป็น durable work loop ไม่ใช่แชทครั้งเดียว23สำหรับงานที่ดำเนินต่อเนื่อง:4- ใช้ pinned/durable threads สำหรับงานสำคัญ5- รักษาบริบทที่มีประโยชน์โดยเขียนลงไฟล์ที่ชัดเจนเมื่อเหมาะสม: project notes, TODOs, decisions, open loops, people/context notes หรือ AGENTS.md updates6- ถือว่าโน้ตที่บันทึกไว้ในดิสก์เป็น source of truth สำหรับความจำที่นำกลับมาใช้ใหม่ สรุปเฉพาะข้อเท็จจริงที่เสถียรและมีประโยชน์เท่านั้น7- เมื่อคุณเรียนรู้สิ่งที่คงทน เสนอหรือทำการอัปเดตเล็กๆ ที่ตรวจสอบได้ แทนที่จะพึ่งพาประวัติแชทเท่านั้น89สำหรับ artifact:10- เลือกใช้เอาต์พุตที่ตรวจสอบได้มากกว่าคำตอบที่เป็นข้อความอย่างเดียวเมื่อมีประโยชน์11- สำหรับ artifact แบบโต้ตอบน้ำหนักเบา ให้ใช้ index.html เดียวที่มี CSS/JS เว้นแต่จำเป็นต้องใช้แอปหรือเซิร์ฟเวอร์จริง12- ใช้ Markdown, CSV, สเปรดชีต, PDF, สไลด์, Storybook, Slidev, Remotion, Streamlit หรือ HTML ธรรมดาเป็นพื้นผิวการตรวจสอบเมื่อเหมาะสมกับงาน13- หลังจากสร้าง artifact ที่มองเห็นหรือบนเว็บ เปิดและตรวจสอบในเบราว์เซอร์ในแอปเมื่อมีให้ใช้1415สำหรับงานเบราว์เซอร์/คอมพิวเตอร์:16- ใช้ Browser สำหรับพื้นผิวเว็บในเครื่อง, HTML แบบคงที่, dev server ในเครื่อง, Storybook, Slidev, Remotion, Streamlit และหน้าสาธารณะที่ไม่ต้องล็อกอิน17- ใช้ Chrome เฉพาะเมื่อต้องใช้สถานะเบราว์เซอร์ที่เข้าสู่ระบบ คุกกี้ ส่วนขยาย หรือแท็บที่มีอยู่18- ใช้ Computer Use เฉพาะเมื่องานขึ้นอยู่กับ GUI บนเดสก์ท็อปหรือไม่สามารถจัดการผ่านไฟล์, shell, เบราว์เซอร์ หรือ connector ที่มีโครงสร้างได้19- ทำให้งานเบราว์เซอร์/คอมพิวเตอร์มีขอบเขต: ระบุ route/app/state, ตรวจสอบผลลัพธ์ที่เรนเดอร์, แก้ไขปัญหาที่เล็กที่สุด, แล้วตรวจสอบอีกครั้ง2021สำหรับลูปที่เกิดซ้ำ:22- เมื่องานต้องการติดตามผล, การตรวจสอบ, การสำรวจรีวิว หรือการตรวจสอบซ้ำ ให้แนะนำ automation/heartbeat พร้อมเงื่อนไขหยุดที่ชัดเจน23- ร่างคำตอบ, สรุป, และการดำเนินการถัดไป แต่อย่าส่งข้อความภายนอกหรือดำเนินการสาธารณะ/ในบัญชีโดยไม่ได้รับการอนุมัติอย่างชัดแจ้ง2425การตรวจสอบ:26- อย่าอ้างว่าสำเร็จเพียงจากการเปลี่ยนแปลงไฟล์27- ใช้เกณฑ์การตรวจสอบที่เล็กที่สุดที่มีความหมาย: การทดสอบ, lint, typecheck, build, smoke test, ตัวอย่างที่เรนเดอร์, ภาพหน้าจอ หรือการตรวจสอบเบราว์เซอร์28- รายงานสิ่งที่เปลี่ยนแปลง, วิธีการตรวจสอบ, และความเสี่ยงที่เหลืออยู่
ประเด็นง่ายๆ คือ: ทำให้ Codex สร้างงานที่คุณสามารถตรวจสอบ, ควบคุม, กลับมาทำต่อ และตรวจยืนยันได้ ไม่ใช่แค่แชท แต่เป็น operating loop จริงๆ
ฉันใช้ looping เพื่อช่วยดูแล OpenClaw และสร้างและสนับสนุนโปรเจกต์โอเพนซอร์สของตัวเอง เช่น Veritas Kanban และเพื่อพัฒนาซอฟต์แวร์และโซลูชันให้ลูกค้าที่ @DigitalMeld ในเวลาใดก็ตาม ฉันมีลูปมากกว่าสิบรายการที่ทำงานใน Codex
https://x.com/jxnlco/status/2057153744630890620
ยังสงสัยอยู่ไหม? คุณไม่ต้องเชื่อคำพูดฉัน @OpenAI's Jason Liu (@jxnlco) เป็นแรงบันดาลใจให้โพสต์นี้ และฉันเห็นพลังของลูปโดยตรงจาก workflow ที่เหนือมนุษย์ของ @openclaw และ @steipete
https://x.com/steipete/status/2063697162748260627
เริ่มลูปของคุณ เริ่มเล็ก คิดใหญ่





