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

> คำสั่ง /goal ใน Claude Code 2.1.139 และ Codex CLI ทำให้เอเจนต์ AI ทำงานได้เองเป็นเวลาหลายชั่วโมง ฉันอธิบายวิธีตั้งค่า ยกตัวอย่างจริง และบอกว่าต้องใช้โทเคนเท่าไร

Source: https://ailoot.ai/blog/th/goal-mode-claude-code-codex/
Canonical: https://ailoot.ai/blog/th/goal-mode-claude-code-codex/
Language: th
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-103
Revision: sha256-79e24692beffbd16746c7dba51c42b926b245e3991261d680775660068f78b57


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

คำสั่ง `/goal` ปรากฏใน Claude Code 2.1.139 (11 พฤษภาคม 2026) และ Codex CLI 0.128.0 (30 เมษายน 2026 และเสถียรตั้งแต่ 21 พฤษภาคม) คุณกำหนดเกณฑ์ว่า “เสร็จแล้ว” เพียงครั้งเดียว จากนั้นเอเจนต์จะวนทำแผน ลงมือ และตรวจสอบด้วยตัวเองจนกว่าเกณฑ์จะผ่านหรือโทเคนจะหมด OpenAI สาธิตการทำงาน 25 ชั่วโมงโดยใช้โทเคน 13 ล้านโทเคน ฟีเจอร์นี้เหมาะกับการย้ายระบบ การทดสอบประสิทธิภาพ และการปรับโครงสร้างโค้ดที่มีเกณฑ์วัดผลได้ แต่ไม่เหมาะกับงาน UI ฐานข้อมูลโปรดักชัน หรือคำขอคลุมเครืออย่าง “ทำให้ดีขึ้น”

</div>

ดูข้อมูลเกี่ยวกับการใช้งาน Ailoot ได้ใน[เอกสารประกอบ](https://ailoot.ai/docs/)

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

ก่อนมี `/goal` เอเจนต์ต้องรอคำสั่ง “ทำต่อ” ด้วยตนเองทุกครั้ง มันเปิดไฟล์ อ่านไฟล์ เขียนบางอย่าง แล้วหยุดรอ คำสั่ง `/goal` กำหนดเกณฑ์การเสร็จสิ้นไว้ครั้งเดียว จากนั้นเอเจนต์จะตัดสินใจเองว่างานเสร็จเมื่อใด และจะไม่คืนการควบคุมให้จนกว่าจะทำงานเสร็จ

</div>

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

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

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



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



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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

Claude Code 2.1.139 เปิดตัวเมื่อวันที่ 11 พฤษภาคม 2026 พร้อมคำสั่ง `/goal` โมเดลขนาดเล็ก (ค่าเริ่มต้นคือ Haiku) จะตรวจสอบเกณฑ์หลังจบแต่ละรอบ หากเกณฑ์ยังไม่ผ่าน Claude จะทำงานต่ออีกหนึ่งรอบ เกณฑ์มีความยาวได้สูงสุด 4,000 อักขระ และมีได้หนึ่งเป้าหมายต่อหนึ่งเซสชัน

</div>

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

```bash
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 จะเริ่มรอบถัดไปโดยอัตโนมัติโดยไม่คืนการควบคุมให้คุณ
- หากคำตอบคือ “ใช่” เป้าหมายจะถูกล้างและคืนการควบคุมให้คุณ

<figure>
<blockquote>
<p>หลังจบแต่ละรอบ โมเดลขนาดเล็กที่ทำงานเร็วจะตรวจสอบว่าเงื่อนไขผ่านหรือยัง หากยังไม่ผ่าน Claude จะเริ่มรอบใหม่โดยไม่คืนการควบคุมให้คุณ</p>
</blockquote>
<figcaption>— เอกสารทางการของ Claude Code, https://code.claude.com/docs/en/goal</figcaption>
</figure>

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

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

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

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

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



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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

Codex CLI 0.128.0 เพิ่ม `/goal` เมื่อวันที่ 30 เมษายน 2026 ในฐานะฟีเจอร์ทดลอง เมื่อวันที่ 21 พฤษภาคม โหมดนี้กลายเป็นเวอร์ชันเสถียรในรุ่น 26.519 / npm 0.133.0 โดยทำงานผ่านเทมเพลตพรอมป์ต์สองไฟล์ ได้แก่ `continuation.md` (“ทำต่อ”) และ `budget_limit.md` (“หยุด”) เป้าหมายผูกกับเธรดและคงอยู่หลังการรีสตาร์ต

</div>

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

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

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

| คำสั่ง | การทำงาน |
|-----------------|---------------------------|
| `/goal condition` | ตั้งเป้าหมาย |
| `/goal` | ดูสถานะ |
| `/goal pause` | หยุดชั่วคราว |
| `/goal resume` | ทำต่อ |
| `/goal edit` | เปลี่ยนเงื่อนไข (เมื่อเป็น GA) |
| `/goal clear` | ล้างเป้าหมาย |

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

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

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

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

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

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

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

</div>

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

| ประเด็น | Claude Code `/goal` | Codex `/goal` |
|----|----|----|
| การเปิดตัว | v2.1.139, 11 พฤษภาคม 2026 | v0.128.0, 30 เมษายน 2026 (ทดลอง) → v0.133.0 / 26.519, 21 พฤษภาคม 2026 (เสถียร) |
| ขอบเขตเป้าหมาย | เซสชัน | เธรด (คงอยู่หลังรีสตาร์ต) |
| คำสั่งควบคุม | `set`, `clear` (+ ชื่อเรียกอื่น) | `set`, `view`, `pause`, `resume`, `edit`, `clear` |
| ใครตรวจว่า “เสร็จแล้ว” | โมเดลแยกต่างหาก (ค่าเริ่มต้นคือ Haiku) | เอเจนต์ตัวเดิม ผ่านพรอมป์ต์ที่แทรกเข้ามา |
| การเข้าถึงไฟล์ของตัวประเมิน | ไม่มี; ตัดสินจากข้อความสนทนาเท่านั้น | มี; ตรวจไฟล์ การทดสอบ และบันทึกได้ |
| งบประมาณ | ระบุในข้อความเงื่อนไข เช่น “หรือหยุดหลังครบ 20 รอบ” | มีขีดจำกัดโทเคนในตัว + แทรก `budget_limit.md` โดยอัตโนมัติ |
| เพดานค่าใช้จ่ายแบบตายตัว | ไม่มี; จำกัดเฉพาะตามแพ็กเกจสมาชิก | ไม่มี; จำกัดเฉพาะตามแพ็กเกจสมาชิก |
| ความยาวเงื่อนไข | สูงสุด 4,000 อักขระ | ไม่ได้ระบุ |
| ใช้งานที่ไหนได้ | โหมดโต้ตอบ, `-p`, แอปเดสก์ท็อป, Remote Control | แอป, ส่วนขยาย IDE, CLI, ไคลเอนต์ ACP |

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

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

อ่านเพิ่มเติมเกี่ยวกับตัวเครื่องมือได้ใน[คู่มือเปรียบเทียบ Codex กับ Claude Code](https://ailoot.ai/blog/th/codex-vs-claude-code-choice/)

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

Codex `/goal` ย้ายโค้ด 14,000 บรรทัดของบริการภายในจาก Pydantic v1 ไป v2 สำเร็จภายในเวลาจริง 31 ชั่วโมง แบ่งเป็นสี่เซสชัน มีค่าใช้จ่ายประมาณ $44 เมื่อใช้ gpt-5.3-codex

</div>

โจทย์ที่กำหนดคือ “ย้ายจาก 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 ชั่วโมง

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

งานประเภทไดรเวอร์ไม่เหมาะกับการทำงานแบบโต้ตอบ แต่เหมาะกับลูปที่ทำงานต่อเนื่องเป็นเวลานานอย่างยิ่ง

</div>



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

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

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

`/goal` ไม่มีเพดานค่าใช้จ่ายสูงสุดแบบตายตัว มีเพียงข้อจำกัดของแพ็กเกจคุณ ชั่วโมงการทำงานจริงของ Codex มีค่าใช้จ่ายประมาณ $1.50–$3 เมื่อใช้ gpt-5.3-codex ส่วน Claude มีค่าใช้จ่ายในการทำงานสูงกว่า แต่การประเมินมีค่าใช้จ่ายต่ำกว่า วิธีป้องกันเพียงอย่างเดียวคือเขียน “หรือหยุดหลังครบ N รอบ” ไว้ในเงื่อนไข

</div>

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

| การทำงาน | ระยะเวลา | โทเคน | ค่าใช้จ่าย |
|----|----|----|----|
| การสาธิตเครื่องมือออกแบบของ OpenAI | 25 ชั่วโมง | 13M | (การทำงานภายใน) |
| Pydantic v1→v2 | 31 ชั่วโมง, 4 เซสชัน | ~3.1M เอาต์พุต | ~\$44 |
| ระบบสัมภาษณ์ด้วยเสียง | รวม 6 ชั่วโมง 44 นาที (คำนวณ 41 นาที) | อินพุต 6.8 ล้าน, แคช 94% | \- |
| การทดสอบ smoke test สำหรับฟอนต์ | 5 นาที | 188,832 | น้อยกว่า 5% ของโควตารายสัปดาห์ |

สิ่งสำคัญที่ควรเข้าใจคือ 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 ใช้ไปกับอะไร](https://ailoot.ai/blog/th/where-claude-code-tokens-go/) และ[วิธีไม่ใช้โควตาจนหมด](https://ailoot.ai/blog/th/claude-code-token-limits-saving/)

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

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

</div>

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

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



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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

สัญญาณของการวนลูปคือเอเจนต์แก้จุดเดิมนาน 3–4 รอบ แล้วเปลี่ยนกลับเป็นแบบเดิม ให้หยุดด้วย Ctrl+C ตรวจสอบบันทึก แล้วปรับเกณฑ์ให้เข้มงวดขึ้นหรือจำกัดงานให้เหลือชิ้นเดียว ใน Claude ใช้ `/goal clear` ได้ ส่วน Codex ให้ใช้ `/goal pause` แล้วแก้เงื่อนไข

</div>

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

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

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

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

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

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

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

ประเด็นสำคัญ

เกณฑ์ที่ดีคือคำสั่งที่คืนค่า exit 0 หรือแสดงผลลัพธ์เฉพาะ “การทดสอบทั้งหมดผ่าน” ใช้ได้ ส่วน “โค้ดสะอาดขึ้น” ใช้ไม่ได้ ควรจับคู่การตรวจสอบอย่างเป็นทางการกับตัวชี้วัดที่วัดผลได้ เช่น การทดสอบร่วมกับความครอบคลุมขั้นต่ำ

</div>

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

<figure>
<blockquote>
<p>เป้าหมายไม่ได้ถือว่าเสร็จเพียงเพราะโมเดลคิดว่าเสร็จแล้ว เป้าหมายจะเสร็จก็ต่อเมื่อมีการตรวจสอบผลลัพธ์กับไฟล์ การทดสอบ บันทึก การทดสอบประสิทธิภาพ หรือสิ่งที่เป็นรูปธรรมอื่น ๆ</p>
</blockquote>
<figcaption>— OpenAI Codex Cookbook, การใช้ Goals ใน Codex, https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex</figcaption>
</figure>

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

| ประเภทเกณฑ์ | วิธีระบุเงื่อนไข |
|----|----|
| การทดสอบ | “pytest tests/ คืนค่า exit 0 และมี coverage อย่างน้อย 80%” |
| Types | “mypy strict รายงานข้อผิดพลาดเป็นศูนย์ใน src/” |
| Lint | “eslint . คืนค่า exit 0 สำหรับไฟล์ที่เปลี่ยนแปลงทั้งหมด” |
| Build | “npm run build ทำงานสำเร็จโดยไม่มีข้อผิดพลาด TypeScript” |
| Benchmark | “k6 run perf test แสดงค่า p95 ต่ำกว่า 200 ms” |
| Diff | “git diff แสดงการเปลี่ยนแปลงเฉพาะไฟล์ X, Y, Z” |
| รวมหลายเกณฑ์ | “pytest ผ่าน AND mypy strict รายงานข้อผิดพลาดเป็นศูนย์ AND ruff check ผ่าน” |



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

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

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

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

<div class="section" role="doc-bibliography" aria-label="Sources">

### แหล่งที่มา

- [เอกสาร `/goal` ของ Claude Code (Anthropic)](https://code.claude.com/docs/en/goal)
- [บันทึกการเปลี่ยนแปลงของ Claude Code (Anthropic)](https://code.claude.com/docs/en/changelog)
- [บันทึกการเปลี่ยนแปลงของ OpenAI Codex](https://developers.openai.com/codex/changelog)
- [OpenAI Codex Cookbook: การใช้ Goals](https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex)
- [บล็อก OpenAI: ใช้ Codex ทำงานระยะยาว (23 กุมภาพันธ์ 2026)](https://developers.openai.com/blog/run-long-horizon-tasks-with-codex)
- [GitHub openai/codex: continuation.md](https://github.com/openai/codex/blob/6014b6679ffbd92eeddffa3ad7b4402be6a7fefe/codex-rs/core/templates/goals/continuation.md)
- [GitHub openai/codex: budget_limit.md](https://github.com/openai/codex/blob/6014b6679ffbd92eeddffa3ad7b4402be6a7fefe/codex-rs/core/templates/goals/budget_limit.md)

</div>



ทำความรู้จักกับ [Ailoot](https://ailoot.ai/)

## คำถามที่พบบ่อย

### เกณฑ์จบงาน /goal ที่มีประโยชน์ควรเป็นอย่างไร?

ระบุผลตรวจได้ เช่น ชื่อ test, type check, build หรือ benchmark และผลที่ต้องผ่าน เขียนเงื่อนไขร่วมให้ชัดพร้อมไฟล์ที่อนุญาต คำว่าทำให้ดีขึ้นไม่มีจุดหยุดที่วัดได้

### ควรทำอย่างไรเมื่อเอเจนต์แก้แบบเดิมที่ล้มเหลวซ้ำ?

หยุดรันแล้วตรวจบันทึก หากแก้และย้อนไฟล์เดิมวนไปมา ให้ลดขอบเขตหรือเจาะจงเกณฑ์มากขึ้น ตรวจว่าการตรวจที่ต้องผ่านมีโอกาสผ่านจริงก่อนทำต่อ


## Ailoot · บริษัทและพอร์ตโฟลิโอโครงการของบริษัท

Ailoot อาศัยประสบการณ์การดำเนินงานที่สั่งสม ฐานลูกค้าขนาดใหญ่ บริการที่เสถียร และการติดตาม KPI อย่างต่อเนื่อง

บริษัทและพอร์ตโฟลิโอโครงการของบริษัท: ลูกค้าหลายล้านราย; ยอดขายระดับหลายพันล้านต่อเดือน.

Ailoot นำประสบการณ์การดำเนินงานนี้มาใช้เพื่อให้เข้าถึงฟังก์ชัน AI ผ่าน API ในผลิตภัณฑ์ของลูกค้า เอเจนต์ แอปพลิเคชัน และระบบอัตโนมัติ