วิธีปล่อยให้ Claude Code และ Codex ทำงานข้ามคืนผ่าน /goal ในปี 2026: โหมดอัตโนมัติ 14 ชั่วโมง

ดูข้อมูลเกี่ยวกับการใช้งาน Ailoot ได้ในเอกสารประกอบ

/goal คืออะไร และทำไมจึงเกิดขึ้นในปี 2026?#

สถานการณ์ที่เราทุกคนเจอก่อนเดือนเมษายน 2026: ฉันสั่ง Claude ว่า “ย้ายโปรเจกต์จาก Pydantic v1 ไป v2” มันเริ่มทำงาน แล้วหยุดหลังจาก 30 วินาที ฉันตรวจดูสิ่งที่มันทำ พิมพ์ว่า “ทำต่อ” มันทำขั้นถัดไปแล้วหยุด และฉันก็ต้องพิมพ์ “ทำต่อ” อีกครั้ง สำหรับการย้ายระบบขนาดใหญ่ นั่นหมายถึงต้องสั่ง “ทำต่อ” ด้วยตัวเอง 200–300 ครั้ง เท่ากับว่าฉันต้องคอยเฝ้าเอเจนต์แทนที่จะเขียนโค้ดอื่นไปพร้อมกัน

OpenAI วิเคราะห์ว่าปัญหาไม่ได้อยู่ที่โมเดล “โง่” แต่อยู่ที่สถาปัตยกรรมของลูป โมเดลไม่รู้ว่าควรหยุดเมื่อไร จึงแตะเบรกทุกครั้งที่จบหนึ่งรอบ หากกำหนดเกณฑ์ “เสร็จแล้ว” ให้มัน มันก็จะตัดสินใจเองได้

นั่นคือที่มาของ /goal ซึ่งเป็นกลไกที่ติดตั้งอยู่ใน harness ไม่ใช่ในโมเดล

คำกล่าวนี้เกิดขึ้นในการประชุม Code with Claude ที่ลอนดอน ระหว่างวันที่ 19–20 พฤษภาคม 2026 เป็นคำอธิบายสิ่งที่เกิดขึ้นจริงในเดือนหลังจากเปิดตัว /goal ในเครื่องมือทั้งสอง

ตั้งค่า Goal mode ใน Claude Code อย่างไร?#

ตัวอย่างสั้น ๆ จากเอกสารทางการของ Anthropic:

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

คำสั่งนี้เปิดเอเจนต์ทำงานเบื้องหลังโดยมีเป้าหมายหนึ่งข้อ Claude จะค้นหา PR ตรวจเทียบกับ CHANGELOG.md เพิ่มบรรทัดที่ขาด แล้วหยุดเมื่อผ่านเกณฑ์

ในโหมดโต้ตอบ เพียงพิมพ์ /goal ตามด้วยเงื่อนไข:

/goal all pytest tests pass and mypy strict reports zero errors

จากนั้น Claude จะทำสิ่งต่อไปนี้:

• หลังจบแต่ละรอบ โมเดลที่แยกต่างหากและทำงานเร็ว (ค่าเริ่มต้นคือ Haiku) จะได้รับเงื่อนไขปัจจุบันและประวัติการสนทนา
• โมเดลนี้จะตอบว่า “ใช่” หรือ “ไม่” พร้อมเหตุผลสั้น ๆ
• หากคำตอบคือ “ไม่” Claude จะเริ่มรอบถัดไปโดยอัตโนมัติโดยไม่คืนการควบคุมให้คุณ
• หากคำตอบคือ “ใช่” เป้าหมายจะถูกล้างและคืนการควบคุมให้คุณ

ข้อจำกัดสำคัญที่หลายคนเพิ่งรู้เมื่อเจอเข้ากับตัว:

• /goal ใช้ได้เฉพาะในไดเรกทอรีทำงานที่ยอมรับกล่องโต้ตอบเรื่องความน่าเชื่อถือแล้ว หากเป็นเครื่องใหม่และ Claude ยังไม่จำไดเรกทอรีนั้น คำสั่งจะล้มเหลว
• ในสภาพแวดล้อมองค์กรที่ตั้งค่า disableAllHooks หรือ allowManagedHooksOnly คำสั่งนี้จะใช้ไม่ได้
• เงื่อนไขมีความยาวได้สูงสุด 4,000 อักขระ
• แต่ละเซสชันมีเป้าหมายที่ทำงานอยู่ได้เพียงหนึ่งข้อ การเรียก /goal ใหม่จะรีเซ็ตเป้าหมายเดิม
• เมื่อใช้ --resume เงื่อนไขจะยังคงอยู่ แต่ตัวนับรอบ เวลา และโทเคนจะรีเซ็ต

คำสั่งควบคุม:

• /goal โดยไม่มีอาร์กิวเมนต์ — แสดงสถานะปัจจุบัน
• /goal clear (หรือ stop, off, reset, none, cancel) — ล้างเป้าหมาย

Anthropic ระบุว่าค่าใช้จ่ายของตัวประเมิน “โดยปกติแทบไม่มีนัยสำคัญเมื่อเทียบกับค่าใช้จ่ายของรอบหลัก” Haiku ประเมินเกณฑ์และข้อความการสนทนาโดยไม่เรียกใช้เครื่องมือ จึงมีค่าใช้จ่ายต่ำ ส่วนที่แพงคือรอบการทำงานของโมเดลหลัก

ตั้งค่า /goal ใน Codex CLI อย่างไร?#

คำสั่งหน้าตาเหมือนกับของ Claude:

codex
> /goal all vitest tests pass and there are no eslint errors

Codex มีคำสั่งควบคุมเป้าหมายให้เลือกมากกว่า:

ความแตกต่างหลักจาก Claude คือ Codex ตรวจสอบเองว่า “เสร็จแล้ว” หรือยัง แทนที่จะใช้โมเดลแยกต่างหาก หลังจบแต่ละรอบ Codex จะแทรกเทมเพลต continuation.md จากรีโพซิทอรี openai/codex ลงในบริบทโดยอัตโนมัติ คำแปลตามตัวอักษรคือ:

“ทำงานต่อไปเพื่อให้บรรลุเป้าหมายของเธรดที่กำลังดำเนินอยู่ อย่าทำงานที่ทำเสร็จแล้วซ้ำ เลือกการกระทำที่เป็นรูปธรรมถัดไปเพื่อเดินหน้าไปสู่เป้าหมาย ระบุว่าเป้าหมายบรรลุแล้วก็ต่อเมื่อการตรวจสอบแสดงว่าเป้าหมายสำเร็จจริงและไม่มีงานที่จำเป็นเหลืออยู่”

เมื่อโทเคนใกล้ถึงขีดจำกัด ระบบจะแทรกเทมเพลตอีกไฟล์คือ budget_limit.md:

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

ตรรกะเหมือนกันคือ “อย่าโกหกเกี่ยวกับสิ่งที่ทำไปแล้ว” ให้ทำต่อก็ต่อเมื่อเป้าหมายยังไม่สำเร็จจริง ส่วน budget_limit กำหนดให้หยุด แต่ต้องบอกอย่างตรงไปตรงมาว่ายังมีอะไรค้างอยู่

ต่างจาก Claude ตรงที่ Codex ผูกเป้าหมายกับเธรด ไม่ใช่เซสชัน คุณสามารถปิดเทอร์มินัลแล้วเปิดใหม่ในตอนเช้า จากนั้น /goal resume ก็ทำงานต่อด้วยเป้าหมายเดิมและข้อเท็จจริงเดิมในหน่วยความจำ วิธีนี้มีประโยชน์สำหรับแบ่งการทำงานเป็นช่วงตามตารางเวลาของตนเอง

/goal ใน Claude Code ต่างจาก /goal ใน Codex อย่างไร?#

นี่คือประเด็นที่มักตกหล่นในการเปรียบเทียบ เรามาดูรายละเอียดกัน

ความแตกต่างเชิงแนวคิดคือ Claude มองลูปนี้เป็นข้อตกลงด้านคุณภาพ (มีตัวประเมินภายนอก) ส่วน Codex มองว่าเป็นกลไกการทำงาน (เอเจนต์จัดการตัวเอง)

ในทางปฏิบัติ หากต้องการให้เกณฑ์ “เสร็จแล้ว” เป็นกลาง ให้เลือก Claude หากต้องการให้เอเจนต์ตรวจไฟล์และบันทึกขณะประเมิน ให้เลือก Codex

อ่านเพิ่มเติมเกี่ยวกับตัวเครื่องมือได้ในคู่มือเปรียบเทียบ Codex กับ Claude Code

ตัวอย่างจริง: ย้ายจาก Pydantic v1 ไป v2 ใน 31 ชั่วโมง#

โจทย์ที่กำหนดคือ “ย้ายจาก Pydantic v1 ไป v2 ให้การทดสอบ pytest ทั้งหมดผ่าน และให้ mypy strict รายงานข้อผิดพลาดเป็นศูนย์”

สิ่งที่เกิดขึ้น:

• เซสชัน 1 (8 ชั่วโมง) — Codex วิเคราะห์ imports เขียนคำประกาศ BaseModel ใหม่ และตั้งค่า mypy
• เซสชัน 2 (10 ชั่วโมง) — เขียน validators ใหม่และทำให้การทดสอบล้มเหลวประมาณ 200 รายการ
• เซสชัน 3 (7 ชั่วโมง) — แก้การทดสอบและพบ dependencies แบบวนซ้ำ
• เซสชัน 4 (6 ชั่วโมง) — แก้ข้อผิดพลาด mypy และ regression ที่เหลือ

ค่าใช้จ่ายโทเคน:

“เวลารวมตามนาฬิกา: ประมาณ 31 ชั่วโมงในสี่เซสชัน ค่าใช้จ่ายโทเคน Codex รวมตามอัตราของ gpt-5.3-codex: ประมาณ $44”

ค่าใช้จ่ายส่วนใหญ่มาจากโทเคนเอาต์พุตของ gpt-5.3-codex ซึ่งคิดอัตรา $14 ต่อหนึ่งล้านโทเคน นั่นหมายความว่างานอัตโนมัติ 31 ชั่วโมงมีค่าใช้จ่ายพอ ๆ กับการสมัคร ChatGPT Plus หลายสัปดาห์

สิ่งที่เอเจนต์ไม่ได้ทำเอง:

• ไม่ได้เขียนเอกสารการย้ายระบบให้ทีม (Codex ไม่เข้าใจว่านี่เป็นส่วนหนึ่งของ “การย้ายระบบ”)
• ไม่ได้ปรับไฟล์ตั้งค่าสำหรับเผยแพร่ด้วย Pydantic เวอร์ชันใหม่
• พลาด regression ในโปรดักชันหนึ่งรายการ ซึ่งตรวจพบในอีกหนึ่งวันต่อมาเท่านั้น

กล่าวคือ /goal ทำงานไป 95% ส่วนอีก 5% ที่เหลือยังต้องทำด้วยมือ นี่เป็นเรื่องปกติสำหรับเทคโนโลยีรุ่นปัจจุบัน และไม่ใช่เหตุผลที่จะไม่ใช้มัน

ทำงานกับไดรเวอร์ macOS ข้ามคืนเป็นเวลา 14 ชั่วโมง#

งานประเภทใดเหมาะกับการทำงานข้ามคืนเป็นเวลานาน#

ประเภทงานที่วิธีนี้ให้ประโยชน์มากที่สุด:

• งานระดับล่างที่การทำซ้ำและตรวจสอบใช้เวลาไม่กี่นาที (คอมไพล์ รันการทดสอบ)
• การย้ายระบบที่มีเกณฑ์อย่างเป็นทางการชัดเจน (types, tests, lint)
• การทดสอบประสิทธิภาพและการปรับปรุงที่วัดผลได้
• เอกสารและบันทึกการเปลี่ยนแปลงที่มีโครงสร้างชัดเจน

/goal ของ Claude ทำงานแบบเดียวกันได้ดีไม่แพ้กัน แต่ผู้คนมักเลือก Codex สำหรับงานไดรเวอร์ เพราะมันตรวจไฟล์และบันทึกเอง แทนที่จะพึ่งผู้ตัดสินภายนอก

มีค่าใช้จ่ายเท่าไร และจะป้องกันไม่ให้โทเคนหมดไปกับการทำงานข้ามคืนได้อย่างไร?#

ตัวเลขจากรายงานสาธารณะ:

สิ่งสำคัญที่ควรเข้าใจคือ Claude Code และ Codex ต่างก็ไม่มีขีดจำกัดตายตัวแบบ “หยุดใช้เงินเมื่อถึง $N” มีมาตรการป้องกันสามข้อ:

1. ขีดจำกัดของแพ็กเกจสมาชิก — Pro, Max หรือ Enterprise สำหรับแพ็กเกจ Max ของ Anthropic ($100/เดือน) การทำงานข้ามคืน 14 ชั่วโมงอยู่ภายในโควตารายสัปดาห์และยังเหลือโควตา
2. จำกัดข้อความในเงื่อนไข — เขียน “หรือหยุดหลังครบ 20 รอบ” ลงใน /goal โดยตรง ตัวตัดสินของ Claude จะอ่านเงื่อนไขนี้และปิดเป้าหมาย
3. ขีดจำกัดโทเคนใน Codex — กลไกในตัวที่แทรก budget_limit.md เมื่อโทเคนหมด

อะไรทำให้ค่าใช้จ่ายพุ่งขึ้นระหว่างคืน:

• เกณฑ์คลุมเครืออย่าง “ทำให้ใช้ง่ายขึ้น” — เอเจนต์จะไม่มีวันหยุด เพราะตัวประเมินไม่รู้ว่า “ดีขึ้น” หมายถึงอะไร
• การเข้าถึง API ภายนอกโดยไม่มี stub — การลองซ้ำแต่ละครั้งใช้โทเคน
• บริบทยาว — เมื่อใช้โทเคนถึง 6.7M จะเริ่มบีบอัดบริบทและทำให้ความทรงจำบางส่วนสูญหาย

อ่านเพิ่มเติมเกี่ยวกับการประหยัดค่าใช้จ่ายได้ในคู่มือ โทเคนของ Claude Code ใช้ไปกับอะไร และวิธีไม่ใช้โควตาจนหมด

เมื่อไรที่ไม่ควรใช้ /goal: 5 สถานการณ์#

เอกสารของ OpenAI ระบุชัดเจนว่าไม่ควรทำอะไรบ้าง:

1. การแก้ไขบรรทัดเดียว — การใช้ /goal เปลี่ยนชื่อตัวแปรมีค่าใช้จ่ายสูงกว่าการทำด้วยมือ
2. เป้าหมายคลุมเครือ — “เพิ่มประสิทธิภาพ”, “ทำให้โค้ดสะอาดขึ้น”, “ทำให้ใช้ง่ายขึ้น” ตัวประเมินไม่มีเกณฑ์ เอเจนต์จึงวนไปเรื่อย ๆ
3. ฐานข้อมูลโปรดักชันที่มีข้อมูลผู้ใช้ — เอเจนต์อาจทำให้การย้ายระบบเสียหาย และการกู้คืนจากข้อมูลสำรองมีค่าใช้จ่ายสูงกว่าที่ประหยัดได้
4. การเปลี่ยนแปลงด้านความปลอดภัย — การยืนยันตัวตน การเข้ารหัส การประมวลผลการชำระเงิน ต้องให้คนตรวจสอบทุก commit
5. API ภายนอกที่ไม่มี stub — ปัญหาเครือข่ายแต่ละครั้งใช้โทเคนและอยู่นอกเหนือการควบคุมของคุณ

ควรทำอย่างไรหากเอเจนต์ติดขัด?#

วิธีสังเกตการวนลูปอย่างรวดเร็ว:

• เอเจนต์แตะไฟล์เดิมติดต่อกัน 3+ รอบ แล้วคืนไฟล์กลับสู่สถานะก่อนหน้า
• มีข้อผิดพลาดเดิมปรากฏซ้ำในบันทึก ทั้งที่เอเจนต์เคยตอบสนองต่อข้อผิดพลาดนั้นแล้ว
• สำหรับคุณ เงื่อนไขดูเหมือนผ่านแล้ว แต่เอเจนต์บอกว่า “ยังไม่ผ่าน”
• การใช้โทเคนต่อรอบเพิ่มขึ้น แต่โค้ดไม่มีความคืบหน้า

สิ่งที่ควรทำต่อ:

• ใน Claude Code: ใช้ /goal clear แล้วทำให้เงื่อนไขเจาะจงมากขึ้น
• ใน Codex: ใช้ /goal pause ตรวจสอบเธรดปัจจุบัน แก้เงื่อนไขด้วย /goal edit แล้วใช้ /goal resume
• ทั้งสองเครื่องมือ: ตรวจสอบว่าเกณฑ์ตรวจสอบได้จริง (คำสั่งคืนค่า exit 0 หรือแสดงผลลัพธ์เฉพาะ)

บ่อยครั้งต้นเหตุของการวนลูปอยู่ที่ตัวงาน ไม่ใช่เอเจนต์ เงื่อนไข “การทดสอบทั้งหมดผ่าน” ตั้งสมมติฐานว่าการทดสอบสามารถผ่านได้ตั้งแต่แรก หากโค้ดมีปัญหาทางสถาปัตยกรรมที่ฝังลึก เอเจนต์ก็จะวนอยู่กับอาการเดิมต่อไป

เกณฑ์ “เสร็จแล้ว”: วินัยในการกำหนดงานสำหรับ /goal#

OpenAI อธิบายกฎนี้ไว้อย่างชัดเจนใน Codex Cookbook อย่างเป็นทางการ:

ตัวอย่างเกณฑ์ที่ใช้ได้จริง:

รูปแบบที่ควรหลีกเลี่ยง:

• “โค้ดดีขึ้น”
• “ใช้งานง่ายขึ้น”
• “ประสิทธิภาพดีขึ้น”
• “เอกสารสมบูรณ์แล้ว”

ความแตกต่างระหว่าง “ทำงานได้” กับ “ทำงานไม่ได้” คือการตรวจสอบได้ หากตรวจเกณฑ์ด้วยคำสั่งไม่ได้ ก็ตรวจสอบไม่ได้เลย นี่คือสิ่งที่ OpenAI หมายถึงด้วยคำว่า “ความสอดคล้องในงานระยะยาว”: เอเจนต์คิดได้นาน แต่ตัดสินเองไม่ได้ว่าอะไรคือ “ดีพอแล้ว”

คุณสามารถทดลองแนวคิด “พรอมป์ต์เดียว—ผลลัพธ์เดียว” กับโปรเจกต์จริงได้ โดยตั้งค่า /goal กำหนดเกณฑ์ รันงาน แล้ววิเคราะห์ว่าเกิดอะไรผิดพลาด

ทำความรู้จักกับ Ailoot