# /goal ใน Claude Code: โหมดอัตโนมัติและ Agent View ในปี 2026

> คำสั่ง /goal ใน Claude Code 2.1.139 เปิดโหมดอัตโนมัติ: เอเจนต์ทำงานจนกว่าจะบรรลุเป้าหมาย ฉันอธิบาย Agent View, worktree และตัวอย่าง 5 แบบ

Source: https://ailoot.ai/blog/th/claude-code-goal-agent-view/
Canonical: https://ailoot.ai/blog/th/claude-code-goal-agent-view/
Language: th
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-102
Revision: sha256-3e7f90ea9b0eea9b3526126b620a74db929eadde65c5a5c0c4d8e797c4dffdc8


เอกสารอ้างอิง Ailoot: [ailoot.ai/docs/](https://ailoot.ai/docs/).

## /goal ใน Claude Code คืออะไร?

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

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

`/goal` คือคำสั่งใน Claude Code 2.1.139+ (เผยแพร่เมื่อ 11 พฤษภาคม 2026) ที่เปิดโหมดอัตโนมัติ: คุณกำหนดเงื่อนไขการทำงานให้เสร็จ แล้ว Claude จะเขียนโค้ด รันการทดสอบ และทำงานต่อในรอบถัดไปจนกว่าจะบรรลุเป้าหมาย หลังจบแต่ละรอบ โมเดลขนาดเล็ก (โดยปริยายคือ Haiku) จะอ่านบทสนทนาและตอบ «ใช่/ไม่ใช่» ว่าตรงตามเงื่อนไขหรือไม่ เปิดใช้ได้ทั้งในเซสชันปกติและโหมด headless ผ่าน `claude -p`

</div>

ก่อนหน้านี้ Claude Code จะหยุดหลังตอบแต่ละครั้งและรอพรอมป์ต์ถัดไปจากคุณ วิธีนี้ใช้ได้กับงานสั้น ๆ แต่เริ่มไม่เหมาะกับงานยาว เช่น การย้าย API การแก้การทดสอบที่ไม่ผ่าน 12 รายการ หรือการรีแฟกเตอร์ไฟล์ขนาด 800 บรรทัด งานเหล่านี้ต้องทำซ้ำ 20–30 รอบ และทุกครั้งก็ต้องกลับไปที่เทอร์มินัล

`/goal` แก้ปัญหานี้ด้วยแนวคิดง่าย ๆ คือแยก «คนที่ทำงาน» ออกจาก «คนที่ตัดสินว่างานเสร็จเมื่อใด» เอเจนต์หลักเขียนโค้ด ส่วนตัวประเมินแยกต่างหาก (โมเดล Haiku ที่รวดเร็ว) จะอ่านบทสนทนาหลังจบแต่ละรอบและตอบคำถามเดียวว่า «บรรลุเงื่อนไขแล้วหรือยัง?» ถ้ายังไม่บรรลุ เอเจนต์จะเริ่มรอบถัดไป ถ้าบรรลุแล้ว การควบคุมจะกลับมาที่คุณ

เอกสารทางการของ Anthropic ให้นิยามไว้ดังนี้:

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





เอเจนต์หลายพันตัวทำงานตอนกลางคืนจากโทรศัพท์ — นี่ไม่ใช่คำโฆษณา แต่เป็นแนวปฏิบัติในปัจจุบันของวิศวกร Anthropic และกลไกที่ทำให้เป็นไปได้คือการใช้ `/goal` ร่วมกับ Agent View ซึ่งเปิดตัวในรุ่นเดียวกันเมื่อวันที่ 11 พฤษภาคม 2026

## ทำไมจึงต้องมีโหมดอัตโนมัติ: ก่อนและหลังวันที่ 11 พฤษภาคม 2026 มีอะไรเปลี่ยนไป?

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

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

ก่อนวันที่ 11 พฤษภาคม 2026 Claude Code ไม่มีโหมดอัตโนมัติในตัว นักพัฒนาเขียนสคริปต์ bash ของตนเองพร้อมตัวตั้งเวลา cron ซึ่งนำไปสู่ความเสียหายทางการเงิน — นักพัฒนาคนหนึ่งเสียเงิน 6,000 ดอลลาร์ในชั่วข้ามคืนเมื่อวันที่ 22 พฤษภาคม เพราะ TTL ของแคชเปลี่ยนจากหนึ่งชั่วโมงเป็น 5 นาทีโดยไม่มีการแจ้งเตือน `/goal` เพิ่มความสามารถอัตโนมัติเข้าไปในเครื่องมือโดยตรง ด้วยสถาปัตยกรรม supervisor การกำหนดขีดจำกัดรอบไว้ในเงื่อนไข และโมเดลประเมินผลที่หยุดเซสชันซึ่งวนลูป

</div>

แนวคิดเรื่อง «ปล่อยให้ AI ทำงานข้ามคืน» มีมาตั้งแต่ฤดูใบไม้ร่วงปี 2025 เมื่อ Cursor Composer และ Cline auto mode สามารถทำงานเบื้องหลังได้แล้ว แต่ก่อนวันที่ 11 พฤษภาคม 2026 Claude Code ต้องใช้ตัวครอบที่เขียนเอง เช่น งาน cron ที่เรียก `claude -p` ทุก N นาที หรือตัวครอบที่เฝ้าดู git status แล้วเปิดพรอมป์ต์ถัดไป

แนวทาง DIY นี้นำไปสู่เหตุการณ์เสียหายซ้ำแล้วซ้ำเล่า เมื่อวันที่ 22 พฤษภาคม 2026 นักพัฒนาคนหนึ่งปล่อยสคริปต์ดังกล่าวทำงานข้ามคืนแล้วตื่นมาพบใบเรียกเก็บเงิน 6,000 ดอลลาร์ สาเหตุหลักคือ Anthropic เปลี่ยน cache TTL ของ Claude Code จากหนึ่งชั่วโมงเป็นห้านาทีโดยไม่แจ้งให้ทราบ cron เรียกระบบ production ทุก 30 นาที — แคชจึงหมดอายุระหว่างการทำงานแต่ละครั้ง ทุกครั้งที่รัน ระบบสร้างประวัติขนาด 800,000 โทเค็นขึ้นใหม่ตั้งแต่ต้น การเขียนข้อมูลใหม่ลงแคชมีค่าใช้จ่ายสูงกว่าการอ่านจากแคชที่ยังทำงานอยู่มาก

นักพัฒนาคนนั้นไม่ได้ทำอะไรแปลกใหม่ — เขาใช้เครื่องมือตามที่ Anthropic โฆษณาไว้อย่างตรงไปตรงมา

`/goal` แก้ปัญหานี้ด้วยสถาปัตยกรรมในตัว:

1.  **โปรเซส Supervisor** ที่ทำให้เซสชันทำงานอยู่นอกเทอร์มินัล และทำงานต่อได้แม้ปิดหน้าต่างหรือแล็ปท็อปเข้าสู่โหมดพักเครื่อง
2.  **ตัวประเมิน Haiku** — โมเดลราคาประหยัดตรวจสอบแต่ละรอบ โทเค็นของตัวประเมินมีค่าใช้จ่ายเพียงไม่กี่เซนต์
3.  **ขีดจำกัดรอบแบบตายตัวในเงื่อนไข** — คุณเขียน `or stop after 20 turns` ได้อย่างชัดเจน และเซสชันจะหยุดแน่นอน
4.  **การแยก worktree** สำหรับเซสชันเบื้องหลัง — การเปลี่ยนแปลงจะไปอยู่ใน branch แยกโดยไม่แตะสำเนาที่คุณกำลังทำงานอยู่

ความแตกต่างจากแนวทาง «เขียนสคริปต์ bash เอง» คือ Anthropic ทำให้กลไกทั้งหมดนี้เป็นส่วนหนึ่งของเครื่องมือโดยตรง แทนที่จะเป็นแฮ็กจากบุคคลที่สาม

## วิธีเปิดใช้ /goal ใน 3 ขั้นตอน

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

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

ขั้นตอนขั้นต่ำ: 1) อัปเดต Claude Code เป็น 2.1.139+ ด้วย `claude update` หรือ `npm i -g @anthropic-ai/claude-code` 2) พิมพ์ `/goal` ตามด้วยเงื่อนไขในเซสชันโดยตรง 3) ติดตามความคืบหน้าผ่านโอเวอร์เลย์แบบเรียลไทม์ (เวลาที่ผ่านไป จำนวนรอบ โทเค็น) คำสั่งนี้ใช้ได้ทั้งในเซสชันแบบโต้ตอบและโหมด headless `claude -p` หากต้องการหยุด ให้กด `Ctrl+C`; หากต้องการยกเลิกเป้าหมาย ให้ใช้ `/goal clear`

</div>

**ขั้นตอนที่ 1 อัปเดต Claude Code เป็นเวอร์ชัน 2.1.139 หรือใหม่กว่า**

ตรวจสอบเวอร์ชัน:

```bash
claude --version
```

หากต่ำกว่า 2.1.139 ให้อัปเดต:

```bash
claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest
```

รุ่นที่เผยแพร่ระหว่างวันที่ 12 ถึง 19 พฤษภาคม 2026 แก้บั๊กสำคัญในรุ่นแรก ในเวอร์ชัน 2.1.140 แก้ปัญหาค้างเงียบที่ `disableAllHooks` ทำให้ตัวประเมินถูกบล็อก ใน 2.1.143 เพิ่ม `worktree.bgIsolation: "none"` และการแก้ลูป stop hook ส่วน 2.1.144 (19 พฤษภาคม) เพิ่ม `--resume` สำหรับเซสชันเบื้องหลังและ `--json` ของ agents สำหรับการเขียนสคริปต์ เวอร์ชันขั้นต่ำคือ 2.1.143

**ขั้นตอนที่ 2 พิมพ์ `/goal` พร้อมเงื่อนไข**

เปิดเซสชัน Claude Code ปกติ แล้วป้อนคำสั่ง:

```
/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns
```

ไม่จำเป็นต้องส่งพรอมป์ต์แยกหลังจากนั้น — คำสั่งจะเริ่มรอบแรกทันที เขียนเงื่อนไขเป็นภาษารัสเซีย ภาษาอังกฤษ หรือผสมกันก็ได้ โมเดลเข้าใจทั้งสองภาษา ความยาวจำกัดไม่เกิน 4,000 อักขระ

**ขั้นตอนที่ 3 ติดตามผ่านโอเวอร์เลย์แบบเรียลไทม์**

หลังเริ่ม `/goal` แผงข้อมูลสดจะปรากฏที่ด้านล่างของเทอร์มินัล:

```
/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail
```

แผงนี้แสดง:

- **Turns** — จำนวนรอบที่เสร็จสิ้นแล้ว
- **Elapsed** — เวลาที่ผ่านไปนับจากเริ่มต้น
- **Tokens** — จำนวนโทเค็นที่ใช้ทั้งหมด (ตัวเลขหลักสำหรับติดตามงบประมาณ)
- **Last** — เหตุผลล่าสุดที่ตัวประเมินตอบว่า «ยังไม่ถึง»

เคล็ดลับที่มีประโยชน์: หากตัวประเมินให้เหตุผลเดิมสามรอบติดต่อกัน แสดงว่าคุณอาจกำลังวนลูป ให้กด `Ctrl+C` หรือพิมพ์ `/goal clear` (คำพ้อง: `stop`, `off`, `reset`, `cancel`) แล้วเรียบเรียงเงื่อนไขใหม่ก่อนเริ่มอีกครั้ง คู่มุมชนนักพัฒนาหลายแห่งระบุว่านี่เป็นสัญญาณหลักของการวนลูปใน `/goal`: «ติดอยู่กับเหตุผลเดิมสามครั้ง — นี่คือลูป ให้ออกจากลูป»

## วิธีเขียนเงื่อนไขที่ดี: 5 กฎและ 5 ตัวอย่าง

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

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

เงื่อนไขคือเกณฑ์จบงานที่ตรวจสอบได้ ไม่ใช่พรอมป์ต์ เงื่อนไขที่ดีมีสามส่วน: สถานะปลายทางที่วัดผลได้ (การทดสอบผ่าน บิลด์เป็นสีเขียว), วิธีตรวจสอบ (`npm test exits 0`) และข้อจำกัดที่ห้ามละเมิด («ห้ามแก้ไขไฟล์นอก /auth») เงื่อนไขที่ไม่ดีจะคลุมเครือ («ทำให้ดูดี»), ตรวจสอบไม่ได้ («ปรับ UX ให้เหมาะที่สุด») หรือไม่มีขีดจำกัดรอบ นักพัฒนาคนหนึ่งเสียเงิน 200 ดอลลาร์ใน 14 ชั่วโมงเพราะใช้เงื่อนไขที่คลุมเครือ

</div>

เอกสารของ Anthropic ระบุองค์ประกอบสามประการของเงื่อนไขที่ดีไว้ดังนี้:

<figure>
<blockquote>
<p>เงื่อนไขที่ใช้ได้กับหลายรอบมักประกอบด้วย: สถานะสุดท้ายที่วัดผลได้หนึ่งรายการ — ผลการทดสอบ รหัสออกของบิลด์ จำนวนไฟล์ หรือคิวว่าง; วิธีตรวจสอบอย่างชัดเจน — Claude ต้องพิสูจน์อย่างไร เช่น <code>npm test exits 0</code> หรือ <code>git status</code> ที่สะอาด; และข้อจำกัดสำคัญ — สิ่งที่ห้ามเปลี่ยนระหว่างทำงาน เช่น <code>no other test file is modified</code></p>
</blockquote>
<figcaption>— Anthropic Docs, https://code.claude.com/docs/en/goal</figcaption>
</figure>

แม่แบบพร้อมใช้ครอบคลุมองค์ประกอบทั้งสามในบรรทัดเดียว:

```
/goal [ทำงาน] จนกว่า [จะถึงสถานะปลายทางที่วัดผลได้] โดยไม่ [ละเมิดข้อจำกัดที่ต้องปฏิบัติตาม]
```


**5 กฎที่คนส่วนใหญ่มักพลาด:**

**กฎข้อ 1 สถานะปลายทางต้องตรวจสอบได้ด้วยคำสั่ง ไม่ใช่ด้วยรสนิยม**

อย่าเขียนว่า «ทำให้ดูดี» แต่ให้ใช้ `npm test exits 0` อย่าเขียนว่า «ปรับ UX ให้ดีขึ้น» แต่ให้ใช้ `Lighthouse Performance score above 90` ตัวประเมินอ่านข้อความในบทสนทนาเท่านั้น — ไม่ได้รันคำสั่งหรือดูภาพหน้าจอ หากบันทึกผลลัพธ์เป็นข้อความไม่ได้ ตัวประเมินก็จะไม่ตอบว่า «ใช่»

**กฎข้อ 2 ระบุข้อจำกัดให้ชัดเจนและแคบ**

หากไม่มีข้อจำกัด Claude อาจแก้การทดสอบด้วยการลบการทดสอบเองหรือใส่คอมเมนต์ปิด assertions ที่ไม่ผ่าน ระบุ `without modifying any file outside /auth`, `without removing existing assertions`, `without bumping major versions of dependencies`

**กฎข้อ 3 ต้องกำหนดขีดจำกัดรอบแบบตายตัว**

เพิ่ม `or stop after N turns` ในทุกเงื่อนไข เพื่อป้องกันการวนลูปไม่รู้จบ หากไม่มีขีดจำกัด ลูปที่ทำงานหนึ่งชั่วโมงอาจใช้โทเค็นมากกว่าการทำงานเดียวกันด้วยตนเอง กำหนดงบประมาณไว้

หากไม่มีขีดจำกัด ลูปที่ทำงานหนึ่งชั่วโมงอาจใช้โทเค็นมากกว่าการทำงานเดียวกันด้วยตนเอง กำหนดงบประมาณไว้

**กฎข้อ 4 ระบุว่าต้องการอะไร ไม่ใช่แค่ว่าจะทำอย่างไร**





หากคุณไม่ได้กล่าวถึงภาพในเงื่อนไข Claude ก็จะไม่สร้างภาพ หากเงื่อนไขกำหนดเพียงว่า «การทดสอบผ่าน» Claude อาจใส่คอมเมนต์ปิดการทดสอบที่ซับซ้อน ระบุว่าคุณต้องการอะไร ไม่ใช่เพียงวิธีตรวจสอบ

**กฎข้อ 5 ให้ Claude แสดงหลักฐานในแชต**

ตัวประเมินไม่ได้รันคำสั่ง — อ่านเฉพาะสิ่งที่ Claude แสดงไว้แล้ว หากเงื่อนไขกำหนดว่า “`npm test` ผ่าน” แต่ Claude ไม่ได้แสดงผลลัพธ์ `npm test` ในบทสนทนา ตัวประเมินจะตอบว่า «ยังไม่ถึง» ตลอดไป เพิ่มข้อความ «แสดงผลลัพธ์ของ `<command>` ในบทสนทนา» ลงในเงื่อนไข

**ตัวอย่างที่ใช้ได้จริง 5 แบบสำหรับงานทั่วไป:**

```
1. การย้าย API:
/goal every call to getUser() has been replaced with fetchUser(), npm test passes, npm run build is green, no other API names have been touched, or stop after 30 turns

2. การแก้การทดสอบ:
/goal all failing tests in test/auth are now green (npm test shows 0 fails in the chat), without changing assertions or deleting tests, or stop after 20 turns

3. คุณภาพโค้ด (ขนาดไฟล์):
/goal src/legacy/UserService.ts has been split into files under 200 lines each, all imports are updated, npm run build is green, or stop after 25 turns

4. การจัดการงานค้าง:
/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a worktree branch, open a PR. Continue until the queue is empty or 6 issues have been processed

5. การตรวจสอบความปลอดภัย:
/goal every npm audit vulnerability with severity >= high is fixed, all existing tests pass, no breaking API changes, or stop after 15 turns
```



## 5 ตัวอย่างที่ /goal ใช้งานได้จริง

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

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

`/goal` เหมาะกับงานที่มีสถานะปลายทางตรวจสอบได้ เช่น การย้าย API การแก้การทดสอบที่ไม่ผ่าน การแยกไฟล์ขนาดใหญ่ การจัดการงานค้าง และการตรวจสอบความปลอดภัย เหมาะน้อยกว่าสำหรับงานเชิงอัตวิสัย เช่น การออกแบบ การขัดเกลา UX การค้นหาข้อมูลเชิงลึก และงานสร้างสรรค์ หลักจำง่าย ๆ คือ อธิบายว่า «เสร็จแล้ว» ด้วยคำสั่ง `bash` ได้ไหม? ถ้าได้ ก็เหมาะกับงานนี้ ถ้าไม่ได้ ให้กลับไปใช้เซสชันปกติหรือ Plan Mode

</div>

เอกสารของ Anthropic ยกตัวอย่างงานสี่ประเภทที่เหมาะกับ `/goal`:

<figure>
<blockquote>
<p>ใช้ goal กับงานสำคัญที่มีสถานะปลายทางตรวจสอบได้: ย้ายโมดูลไปยัง API ใหม่จนทุกการเรียกคอมไพล์ได้และการทดสอบผ่าน; ทำเอกสารการออกแบบให้เสร็จจนเป็นไปตามเกณฑ์การยอมรับทั้งหมด; แยกไฟล์ขนาดใหญ่เป็นโมดูลเฉพาะทางจนแต่ละไฟล์อยู่ภายในขีดจำกัดขนาด; จัดการงานที่ติดป้ายกำกับใน backlog จนคิวว่าง</p>
</blockquote>
<figcaption>— Anthropic Docs, https://code.claude.com/docs/en/goal</figcaption>
</figure>

ต่อไปนี้คือตัวอย่างห้าแบบพร้อมเงื่อนไขที่นำไปใช้ได้ทันที — นำไปปรับให้เข้ากับโปรเจกต์ของคุณ

**ตัวอย่างที่ 1 ย้ายโมดูลไปยัง API ใหม่**

สถานการณ์: คุณกำลังย้ายจาก REST ไปยัง GraphQL หรือแทนที่ฟังก์ชันเก่า `getUser()` ด้วย `fetchUser()` งานนี้ทำตามขั้นตอนได้ แต่กระทบไฟล์ 30–50 ไฟล์

เงื่อนไข:

```
/goal every getUser() in src/ has been replaced with fetchUser(), all calls updated to the new interface (id instead of userId), npm test passes, no files outside src/ touched, or stop after 30 turns
```

เหตุผลที่ใช้ได้: ตรวจสอบสถานะปลายทางได้ด้วย `grep -r getUser src/ | wc -l` (ควรได้ 0) และ `npm test exits 0` ข้อจำกัดช่วยปกป้องไฟล์ทดสอบ

**ตัวอย่างที่ 2 แก้การทดสอบที่ไม่ผ่าน**

สถานการณ์: หลังอัปเดตไลบรารี การทดสอบ 15 รายการพัง คุณรู้ว่าการแก้ไขเป็นงานเชิงกลไก — อัปเดต mocks และปรับ assertions ให้เข้ากับรูปแบบใหม่ คุณไม่อยากทำเองทีละรายการ

เงื่อนไข:

```
/goal all failing tests in test/ are now green, npm test shows the results in the chat with 0 failures, without deleting tests or commenting out assertions, or stop after 25 turns
```

อีกตัวอย่างของเงื่อนไขลักษณะเดียวกัน:

```

แก้การทดสอบทั้งหมดที่ไม่ผ่านจนกว่า npm test จะคืนค่า 0 โดยไม่แก้ไขไฟล์ใดนอกไดเรกทอรี /auth
```

**ตัวอย่างที่ 3 แยกคลาสขนาดใหญ่ที่ทำทุกอย่าง**

สถานการณ์: ไฟล์เดียวขนาด 1,200 บรรทัดมีทุกอย่างอยู่ในนั้น ทั้งโมเดล บริการ ยูทิลิตี และไคลเอนต์ API คุณต้องการแยกตามหลัก «หนึ่งไฟล์ หนึ่งความรับผิดชอบ» อัปเดต imports ทั้งหมด และทำให้การทดสอบยังผ่าน

เงื่อนไข:

```
/goal src/legacy/UserService.ts has been split into files under 200 lines, each file handles one responsibility (model, repository, api-client, validator), all imports are updated, npm run build is green, existing tests pass, or stop after 25 turns
```

**ตัวอย่างที่ 4 จัดการงานค้างข้ามคืน**

สถานการณ์: คุณมี repository โอเพนซอร์สที่มี issue เปิดอยู่ 20 รายการและติดป้าย `good-first-issue` คุณต้องการให้ Claude จัดการรายการเหล่านั้นข้ามคืน

เงื่อนไข:

```
/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a separate worktree branch worktree-issue-N, open a PR with a description. Continue until the queue is empty or 6 issues have been processed, or stop after 80 turns
```

เลือกเลข 6 ไม่ใช่โดยบังเอิญ — เป็นเพดานที่เป็นไปได้จริงสำหรับหนึ่งคืนบนแผน Pro

**ตัวอย่างที่ 5 ตรวจสอบความปลอดภัย**

สถานการณ์: `npm audit` แสดงช่องโหว่ความรุนแรงสูง 8 รายการ คุณต้องการให้ Claude แก้ช่องโหว่โดยไม่อัปเดตเวอร์ชันหลัก

เงื่อนไข:

```
/goal every npm audit vulnerability with severity high+ is fixed, npm audit shows 0 high in the chat, all existing tests pass, no breaking API changes, no major version bumps to packages, or stop after 15 turns
```



**สิ่งที่ไม่ควรทำด้วย /goal:**

| ประเภทงาน | เหตุผลที่ใช้ไม่ได้ |
|----|----|
| «ทำ UI ให้สวย» | ตัวประเมินเห็นเพียงข้อความ ไม่เห็นงานออกแบบ |
| «ค้นหาข้อมูลเชิงลึกจากข้อมูล» | ไม่มีสถานะปลายทางที่ตรวจสอบได้ |
| «ปรับ UX ของหน้าให้เหมาะที่สุด» | เป็นเรื่องรสนิยม ตัวเอเจนต์จะปรับสิ่งที่มีการวัดผล |
| การวิจัย / สำรวจ | ไม่มีขอบเขตชัดเจน ตัวประเมินไม่รู้ว่าเมื่อไรจึง «พอ» |
| การนำขึ้น production | ผลกระทบภายนอกไม่สามารถย้อนกลับได้ |
| การสร้างเนื้อหา / การตลาด | ตรวจสอบคุณภาพข้อความด้วยคำสั่งไม่ได้ |

Croucher เน้นย้ำหลักจำง่าย ๆ ในคู่มือภาคสนามว่า อย่าใช้ `/goal` กับงานที่คำว่า «เสร็จแล้ว» หมายถึง «ดูดี» «รู้สึกถูกต้อง» «ออกแบบดี» หรือ «สนุก» ตัวประเมินอ่านเพียงบทสนทนา — ไม่ได้เรียกใช้เครื่องมือและประเมินไม่ได้ว่าผลลัพธ์ทำงานอย่างไร หลักนี้ตัดงานเชิงอัตวิสัย 80% ที่ `/goal` วนลูปโดยไม่สร้างผลงานที่มีประโยชน์ออกไป

## เมื่อ /goal ใช้เงินเปล่าประโยชน์: 3 รูปแบบการใช้งานที่ผิดพลาด

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

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

รูปแบบการใช้ `/goal` ที่ผิดพลาดสามแบบที่พบบ่อย: เงื่อนไขคลุมเครือและไม่มีขีดจำกัดรอบ (นักพัฒนาคนหนึ่งเสียเงิน 200 ดอลลาร์ใน 14 ชั่วโมง), ลูปวนซ้ำที่แคชค้าง (เสียเงิน 6,000 ดอลลาร์ข้ามคืนเพราะ TTL ของแคชเปลี่ยนไป) และงานสร้างสรรค์ที่ไม่มีสถานะปลายทางตรวจสอบได้ (เกมที่สร้างโดยไม่มีภาพ แต่ตัวประเมินบอกว่า «เสร็จแล้ว» ทั้งที่กราฟิกหายไป) วิธีป้องกันคือใส่ `or stop after N turns` ทุกครั้ง ระบุผลลัพธ์ที่วัดได้ และตรวจสอบก่อนว่างานนั้นเหมาะกับการทำงานอัตโนมัติหรือไม่

</div>

**รูปแบบผิดพลาดที่ 1 เงื่อนไขคลุมเครือและไม่มีขีดจำกัดรอบตายตัว**

ข้อผิดพลาดที่พบบ่อยที่สุดคือใช้เงื่อนไขอย่าง «ปรับปรุงโค้ด» / «ทำให้ดี» / «ปรับให้เหมาะที่สุด» หากไม่มีขีดจำกัดรอบ เอเจนต์จะทำงานต่อไปจนใช้โควตาของคุณหมด

Findskill เล่ากรณีจริงไว้ว่า:

นักพัฒนาคนหนึ่งรายงานว่าเสียเงิน 200 ดอลลาร์ระหว่างเซสชัน 14 ชั่วโมงจากการใช้เงื่อนไขที่คลุมเครือ เงื่อนไขที่ไม่รัดกุมจนตัวประเมินตอบว่า “ยังไม่ถึง” ซ้ำ ๆ อาจทำให้เซสชันทำงาน 50, 100 หรือ 500 รอบก่อนที่คุณจะทันสังเกต

การเสียเงิน 200 ดอลลาร์ใน 14 ชั่วโมงเพราะเงื่อนไขคลุมเครือ เท่ากับโควตารายสัปดาห์ทั้งหมดของแผน Max คุณตื่นมาตอนเช้าโดยไม่มีโควตาเหลือและไม่ได้ผลงานที่มีประโยชน์

วิธีป้องกัน: ลงท้ายทุกเงื่อนไขด้วย `or stop after N turns` (15 รอบสำหรับงานง่าย 50 สำหรับงานยาก และสูงสุด 100 สำหรับการทำงานข้ามคืน)

**รูปแบบผิดพลาดที่ 2 ลูปวนซ้ำพร้อมแคชที่เสีย**

นักพัฒนาคนหนึ่งเสียเงิน 6,000 ดอลลาร์ข้ามคืน เพราะ Anthropic เปลี่ยน cache TTL จากหนึ่งชั่วโมงเป็น 5 นาทีอย่างเงียบ ๆ นักพัฒนาคนนั้นไม่ได้ใช้ `/goal` โดยตรง แต่ใช้ตรรกะเดียวกัน คือมีลูปอัตโนมัติพร้อมตัวตั้งเวลา cron ทุก 30 นาทีที่สร้างประวัติ 800,000 โทเค็นขึ้นใหม่ตั้งแต่ต้นทุกครั้ง

ปัญหาหลักคือระบบอัตโนมัติภายนอกไม่รู้ถึงการเปลี่ยนแปลงภายในของผู้ให้บริการ สิ่งเดียวกันอาจเกิดขึ้นกับ `/goal` หากคุณปล่อยทำงาน 8 ชั่วโมงโดยไม่มีคนดูแล: การใช้โทเค็นเพิ่มขึ้นแบบไม่เป็นเชิงเส้น และ prompt cache อาจไม่ทำงานอย่างที่คุณคิด

วิธีป้องกัน:

1.  **อย่าปล่อย `/goal` ทำงานนาน 8+ ชั่วโมงโดยไม่มีการตรวจสอบระหว่างทาง**
2.  **เปิดใช้ขีดจำกัดการใช้งานใน Settings → Usage** (มาตรการป้องกันใหม่หลังเหตุการณ์ 6,000 ดอลลาร์)
3.  **เปิด `claude agents` สองครั้งระหว่างคืน** — แวะดูด้วย `Space` และตรวจสอบว่าจำนวนรอบไม่ได้เพิ่มเร็วกว่าที่คาด
4.  **สำหรับชุดโมเดลราคาแพง (Opus 4.7)** ให้ตั้งขีดจำกัดรอบที่เข้มงวดขึ้น — สูงสุด 30 รอบ

**รูปแบบผิดพลาดที่ 3 ใช้ `/goal` ทำงานสร้างสรรค์**

Croucher ใช้ `/goal` สร้างเกม — เงื่อนไขระบุเรื่องความเป็นเชิงกำหนด invariants และการตรวจสอบว่าด่านเล่นชนะได้ เกมถูกสร้างขึ้น การทดสอบผ่าน และตัวประเมินบอกว่า «บรรลุแล้ว» แต่เกมไม่มีภาพ เพราะเงื่อนไขไม่ได้กล่าวถึงกราฟิก

นี่แสดงให้เห็นหลักทั่วไป: ตัวประเมินปรับให้ตรงกับสิ่งที่คุณวัดอย่างเคร่งครัด หากเงื่อนไขไม่กล่าวถึงภาพ ก็จะไม่มีภาพ หากกล่าวถึงเพียงการทดสอบ ตัวประเมินอาจใส่คอมเมนต์ปิด assertions

วิธีป้องกัน: อย่าใช้ `/goal` กับสิ่งที่ขึ้นอยู่กับรสนิยม (การออกแบบ ข้อความ UX) กลับไปใช้เซสชันปกติหรือ [Plan Mode](https://ailoot.ai/blog/th/claude-code-plan-mode/) ซึ่งทำให้คุณยังมีส่วนร่วมในการตัดสินใจ

## Agent View คืออะไร และเปิดแดชบอร์ดอย่างไร

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

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

Agent View คือแดชบอร์ดภาพสำหรับจัดการเซสชัน Claude Code ที่ทำงานเบื้องหลัง เปิดได้ด้วยคำสั่ง `claude agents` ในเทอร์มินัล แต่ละเซสชันเบื้องหลังจะแสดงเป็นแถวพร้อมสถานะ (Working, Needs input, Idle, Completed, Failed, Stopped) มีประโยชน์เมื่อคุณรันงานอัตโนมัติ 2–5 งานพร้อมกัน — แทนการสลับระหว่างเทอร์มินัล คุณจะเห็นทุกอย่างในหน้าจอเดียว มีฟังก์ชัน peek (Space — ดูอย่างรวดเร็วโดยไม่เชื่อมต่อ), attach (Enter), detach (ลูกศรซ้าย) และ pin (Ctrl+T)

</div>

หาก `/goal` คือคำสั่ง «ทำงานจนกว่าจะเสร็จ» Agent View ก็คือห้องควบคุมที่แสดงคำสั่งทั้งหมดพร้อมกัน Anthropic อธิบายไว้ดังนี้:

<figure>
<blockquote>
<p>เปิด Agent View ด้วย <code>claude agents</code> — หน้าจอเดียวสำหรับเซสชันเบื้องหลังทั้งหมดของคุณ: เซสชันใดกำลังทำงาน เซสชันใดต้องการข้อมูลจากคุณ และเซสชันใดเสร็จแล้ว เริ่มเซสชันใหม่ ตรวจสอบสถานะได้อย่างรวดเร็วโดยไม่ต้องเลื่อนดูบทสนทนา และเชื่อมต่อเฉพาะเมื่อเซสชันต้องการคุณ</p>
</blockquote>
<figcaption>— Anthropic Docs, https://code.claude.com/docs/en/agent-view</figcaption>
</figure>

**คำสั่งเปิด:**

```bash
claude agents
```

TUI จะเปิดขึ้น — แดชบอร์ดข้อความภายในเทอร์มินัล รายการเซสชันอยู่ด้านซ้าย ส่วนแผง peek ที่มีข้อความล่าสุดจากแถวที่เลือกอยู่ด้านขวา

**สถานะเซสชันทั้งหกแบบ:**

| สถานะ | ความหมาย |
|----|----|
| **Working** | Claude กำลังทำงานอย่างต่อเนื่อง — เรียกใช้เครื่องมือหรือสร้างคำตอบ |
| **Needs input** | Claude กำลังรอคำตอบจากคุณสำหรับคำถามเฉพาะหรือรอการอนุญาต |
| **Idle** | เซสชันไม่ได้ทำงานและพร้อมรับพรอมป์ต์ถัดไป |
| **Completed** | ทำงานเสร็จสมบูรณ์แล้ว |
| **Failed** | เซสชันจบลงพร้อมข้อผิดพลาด |
| **Stopped** | เซสชันถูกหยุดด้วย Ctrl+X หรือ `claude stop` |

**คีย์ลัดหลัก:**

```
↑ / ↓             move through the session list
Space             peek pane (view without attaching)
Enter / →         attach to a session (enter it)
←                 detach (leave without killing it)
Ctrl+T            pin (protect the session from auto-stopping)
Ctrl+X            stop the session; press again within 2 sec to delete
Ctrl+R            rename
Ctrl+S            toggle grouping (state ↔ directory)
```

**วิธีเริ่มเซสชันเบื้องหลัง:**

จาก Claude Code แบบโต้ตอบ:

```
/bg fix the failing test test/auth/login.test.ts
```

หรือจาก shell โดยตรง:

```bash
claude --bg "fix the failing test test/auth/login.test.ts"
```

หรือกำหนดชื่อเพื่อให้แสดงใน Agent View ด้วยป้ายที่จำง่าย:

```bash
claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"
```

เซสชันเบื้องหลังจะถูกเพิ่มเข้า Agent View โดยอัตโนมัติ — เริ่มด้วย `--bg` เปิด `claude agents` แล้วคุณจะเห็นเซสชันในรายการ

**คุณสมบัติหลัก: เซสชันทำงานต่อได้แม้แล็ปท็อปเข้าสู่โหมดพักเครื่องและปิดหน้าต่าง:**

<figure>
<blockquote>
<p>สถานะเซสชันจะบันทึกลงดิสก์และอยู่ต่อได้แม้มีการอัปเดตอัตโนมัติหรือเริ่ม supervisor ใหม่ นอกจากนี้ยังบันทึกเซสชันเมื่อเครื่องเข้าสู่โหมดพักเครื่อง เมื่อเครื่องตื่นขึ้น กระบวนการจะทำงานต่อ และ supervisor จะเชื่อมต่อกลับไปยังเซสชันแทนการนับช่วงหยุดพักเป็นเวลาว่าง</p>
</blockquote>
<figcaption>— Anthropic Docs, https://code.claude.com/docs/en/agent-view</figcaption>
</figure>

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

## Worktree: วิธีที่ Claude แยกเซสชันที่ทำงานพร้อมกัน

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

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

worktree คือสำเนา repository แยกต่างหากใน `.claude/worktrees/<name>/` บน branch แยกชื่อ `worktree-<name>` เมื่อเริ่มเซสชันเบื้องหลังผ่าน `/bg` หรือ Agent View Claude จะย้ายเซสชันไปยัง worktree โดยอัตโนมัติก่อนแก้ไขไฟล์ เซสชันที่ทำงานพร้อมกันอ่าน checkout เดียวกันได้ แต่แต่ละเซสชันเขียนลงสำเนาของตนเอง จึงไม่เขียนทับงานของกันและกัน คุณปิดการแยกนี้ได้ด้วย `worktree.bgIsolation: "none"` ใน `.claude/settings.json` (มีให้ใช้ตั้งแต่ 2.1.143)

</div>

Worktree แก้ปัญหาหลักของการทำงานอัตโนมัติพร้อมกัน: จะเกิดอะไรขึ้นถ้าสองเซสชันพยายามแก้ `src/auth.ts` ในเวลาเดียวกัน? ก่อน 2.1.139 เซสชันเหล่านั้นอาจเขียนทับการเปลี่ยนแปลงของกันและกันได้จริง เมื่อเปิดตัว Agent View, Anthropic ก็เพิ่มการแยกอัตโนมัติ:

<figure>
<blockquote>
<p>เซสชันเบื้องหลังทุกเซสชันที่เริ่มจาก Agent View ผ่าน /bg หรือด้วย <code>claude --bg</code> จะเริ่มในไดเรกทอรีทำงานของคุณ ก่อนแก้ไขไฟล์ Claude จะย้ายเซสชันไปยัง git worktree ที่แยกเป็นอิสระใน <code>.claude/worktrees/</code> ทำให้เซสชันที่ทำงานพร้อมกันอ่าน checkout เดียวกัน แต่แต่ละเซสชันเขียนลงสำเนาของตนเอง</p>
</blockquote>
<figcaption>— Anthropic Docs, https://code.claude.com/docs/en/agent-view</figcaption>
</figure>

**วิธีทำงานจริง:**

```bash
# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate copy on branch worktree-split-userservice
```

แต่ละเซสชันทำงานในสำเนาของตนเอง เมื่องานเสร็จ ให้รวม branch ที่ต้องการเข้า main

**ข้อผิดพลาดอันตราย — การลบเซสชันจะลบ worktree ของเซสชันนั้นด้วย**

<figure>
<blockquote>
<p>worktree ที่ Claude สร้างจะถูกลบพร้อมกับเซสชันใน Agent View: รวม branch หรือ push การเปลี่ยนแปลงก่อนลบเซสชันที่แก้ไขไฟล์ใน worktree ของตนเอง</p>
</blockquote>
<figcaption>— Anthropic Docs, https://code.claude.com/docs/en/agent-view</figcaption>
</figure>

หากยุติเซสชันใน Agent View (กด `Ctrl+X` สองครั้ง) worktree ของเซสชันนั้นจะหายไป การเปลี่ยนแปลงที่ยังไม่ได้ commit จะสูญหายทั้งหมด ก่อนลบเซสชันใน Agent View ให้ commit หรือ push เสมอ

**ปิดการแยก (สำหรับกรณีที่พบไม่บ่อย):**

หากมี repository ที่ใช้ git worktree ไม่ได้ (เช่น การตั้งค่าที่ใช้ symlinks หรือ monorepo ขนาดใหญ่ที่ checkout ช้า) คุณสามารถปิดการแยกได้:

```json
// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}
```

จากนั้นเซสชันเบื้องหลังจะแก้ไขสำเนาที่คุณกำลังทำงานอยู่โดยตรง ตัวเลือกนี้เพิ่มเข้ามาใน 2.1.143 หลังทีมที่ทำงานกับ monorepo ขนาดใหญ่ร้องเรียน

**การทำงานพร้อมกันใช้โควตาเร็วขึ้น:**

<figure>
<blockquote>
<p>ขีดจำกัดอัตราการใช้งานมีผลกับกรณีนี้ด้วย: เซสชันเบื้องหลังใช้โควตาสมาชิกเหมือนเซสชันแบบโต้ตอบ ดังนั้นเอเจนต์พร้อมกัน 10 ตัวจึงใช้โควตาเร็วกว่าเอเจนต์เดียวประมาณ 10 เท่า</p>
</blockquote>
<figcaption>— Anthropic Docs, https://code.claude.com/docs/en/agent-view</figcaption>
</figure>

นั่นหมายความว่าแผน Pro (20 ดอลลาร์/เดือน) เพียงพอสำหรับเซสชันพร้อมกัน 1–2 เซสชันข้ามคืน ไม่ใช่ 10 เซสชัน หากต้องการเรียกใช้เอเจนต์หลายตัวพร้อมกัน คุณต้องใช้แผน Max หรือ Enterprise

## ผสาน /goal, Plan Mode และ subagents สำหรับงานระยะยาว

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

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

`/goal` เป็นเพียงขั้นตอนสุดท้ายของกระบวนการ หากใช้เพียงลำพัง ก่อนหน้านั้นให้ใช้ [Plan Mode](https://ailoot.ai/blog/th/claude-code-plan-mode/) สร้างแผนแบ่งเป็นระยะไว้ใน `plans/` และใช้ [subagents](https://ailoot.ai/blog/th/claude-code-subagents/) กระจายงาน การทำงานร่วมกันเป็นดังนี้: 1) Plan Mode เขียนแผนละเอียดพร้อมช่องทำเครื่องหมายที่ตรวจสอบได้ 2) subagents ทำงานคนละระยะพร้อมกันได้ใน branch worktree ของตนเอง 3) `/goal` ทำวงจร «ทำงาน → ประเมิน → รอบถัดไป» จนกว่าจะทำเครื่องหมายครบทุกช่อง หากไม่มี Plan Mode, `/goal` จะไม่มีประโยชน์กับงานซับซ้อน

</div>

ข้อผิดพลาดที่พบได้บ่อยคือพิมพ์ `/goal build a new feature` ทันที วิธีนี้ใช้ไม่ได้เพราะตัวประเมินไม่รู้ว่า «ฟีเจอร์ที่เสร็จแล้ว» มีหน้าตาอย่างไร คุณต้องมีแผนที่ประกอบด้วยช่องทำเครื่องหมายซึ่งตัวประเมินตรวจสอบทีละข้อได้

**ชั้นที่ 1 Plan Mode เขียนแผนแบ่งเป็นระยะ**

ใน [Plan Mode](https://ailoot.ai/blog/th/claude-code-plan-mode/) ขอให้ Claude สร้างแผนการเปลี่ยนแปลงอย่างละเอียด แบ่งเป็น 5–7 ระยะพร้อมช่องทำเครื่องหมายที่ตรวจสอบได้ บันทึกเป็น `plans/2026-05-24-google-oauth.md` แต่ละระยะมีช่องทำเครื่องหมาย 3–7 ข้อพร้อมการดำเนินการที่ชัดเจน

**ชั้นที่ 2 Subagents แบ่งงานตามระยะ**

หากแบ่งแผนทำงานพร้อมกันได้ (เช่น แต่ละระยะเป็นอิสระต่อกัน ได้แก่ backend endpoint + frontend form + DB migration) คุณสามารถเริ่มแต่ละระยะในเซสชันเบื้องหลังแยกกันผ่าน `claude --bg --name "<phase>"` แต่ละเซสชันจะมี worktree ของตัวเอง

**ชั้นที่ 3 `/goal` ทำงานเป็นวงจรจนกว่าจะทำเครื่องหมายครบทุกช่อง**

```
/goal all phases 1–7 in plans/2026-05-24-google-oauth.md are complete and marked [x], all tests in test/auth pass (npm test shows 0 failures), npm run build is green, or stop after 50 turns
```

หลังจบแต่ละรอบ ตัวประเมินจะอ่านแผน ตรวจสอบว่ามีช่องใดเสร็จแล้วบ้าง และหากยังเหลืออะไร เอเจนต์จะทำงานต่อ

**การผสานนี้อาศัยองค์ประกอบสามอย่าง:**

- การจัดการบริบท: บริบทที่เหมาะสมใน `plans/` ซึ่งตัวประเมินอ่านได้
- [สมองที่สอง](https://ailoot.ai/blog/th/claude-code-second-brain/): โฟลเดอร์ `plans/` เก็บแผนไว้ระหว่างเซสชัน
- `CLAUDE.md` กำหนดกฎที่เอเจนต์ต้องปฏิบัติตาม

หากไม่มี CLAUDE.md, `/goal` อาจเสนอวิธีแก้ที่ทำให้สถาปัตยกรรมเสียหาย หากไม่มีแผนใน `plans/` ตัวประเมินก็ไม่รู้เกณฑ์ความสำเร็จ หากไม่มี subagents ก็ไม่มีการทำงานพร้อมกันตามระยะ ทุกอย่างจะทำตามลำดับ



## เปรียบเทียบ /goal กับ Codex, Cursor และโหมดเอเจนต์อื่นอย่างไร

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

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

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

</div>

`/goal` เพิ่มการตรวจเงื่อนไขจบหลังทุกรอบ ผลิตภัณฑ์อื่นมีหลายโหมด CLI ในเครื่อง งานคลาวด์ที่โฮสต์ และเซสชันเอดิเตอร์ที่มีคนกำกับไม่ใช่หน่วยเปรียบเทียบเดียวกัน โดยเฉพาะอย่าเรียกงาน Codex CLI ทั้งหมดว่าคอนเทนเนอร์คลาวด์ หรือสมมติว่า Codex ทุกงานใช้โมเดลตรวจและวิธีคิดเงินเหมือนกัน

ใช้ snapshot repository และงานเดียวกันพร้อมเกณฑ์ยอมรับชุดเดียว แล้วบันทึกมิติต่อไปนี้:

| มิติ | สิ่งที่ต้องบันทึก |
|----|----|
| การรัน | ไคลเอนต์ เวอร์ชัน และ runtime ในเครื่องหรือโฮสต์ |
| โมเดล | โมเดลที่แน่นอน reasoning effort และขีดจำกัดบริบท |
| การทำต่อ | อะไรเริ่มรอบใหม่และอะไรหยุด |
| การแยก | สำเนาทำงาน สิทธิ์ ข้อมูลลับ และเครือข่าย |
| ผลลัพธ์ | การตรวจที่ผ่าน ความล้มเหลว และการแก้โดยมนุษย์ |
| การใช้ | โทเค็นอินพุต อ่าน/เขียนแคช เอาต์พุต เวลา และวิธีคิดเงินจริง |

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

เลือกตาม workflow ที่ต้องการ: แก้โดยมีคนกำกับ งานเบื้องหลังขอบเขตชัด หรืองานหลายรอบที่มีเงื่อนไขจบชัด ทดสอบโหมดที่ผลิตภัณฑ์ติดตั้งรองรับ แทนสมมติว่าคู่แข่งทั้งตัวทำงานอัตโนมัติไม่ได้ แยกการอนุมัติสิทธิ์จากการทำงานต่อ การอนุมัติเรียกเครื่องมืออัตโนมัติไม่ได้ยืนยันว่าเป้าหมายผู้ใช้สำเร็จ

## รายการตรวจสอบก่อนเริ่ม /goal: 7 ข้อ

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

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

ก่อนเรียกใช้ `/goal` ทุกครั้ง ให้ตรวจสอบ 7 ข้อ: Claude Code เวอร์ชัน 2.1.139+, เงื่อนไขระบุสถานะปลายทางที่ตรวจสอบได้, มีขีดจำกัดรอบแบบตายตัว, ระบุข้อจำกัดชัดเจน, commit การเปลี่ยนแปลงสำคัญทั้งหมดแล้ว, เปิดใช้ขีดจำกัดการใช้งานใน Settings และเปิด Agent View ไว้ติดตาม หากขาดข้อใดข้อหนึ่ง คุณอาจเสียเงินหลายร้อยดอลลาร์และสูญเสียงาน

</div>

รายการตรวจสอบก่อนเรียกใช้ `/goal` ทุกครั้ง:

1.  **Claude Code เวอร์ชัน 2.1.139+** — ตรวจสอบด้วย `claude --version` และอัปเดตหากต่ำกว่า เวอร์ชันขั้นต่ำที่แนะนำคือ 2.1.143 (15 พฤษภาคม 2026) ซึ่งแก้ลูป stop hook

2.  **เงื่อนไขมีสถานะปลายทางที่ตรวจสอบได้** — แทนที่จะเขียนว่า «ปรับปรุงมัน» ให้ระบุ `npm test exits 0` หากคิดคำสั่ง `bash` สำหรับตรวจสอบผลลัพธ์ไม่ได้ ก็ไม่ควรใช้ `/goal` กับงานนี้

3.  **มีขีดจำกัดรอบแบบตายตัว** — ทุกเงื่อนไขระบุ `or stop after N turns` ใช้ 15 รอบกับงานง่าย 50 รอบกับงานยาก และสูงสุด 100 รอบสำหรับการทำงานข้ามคืน

4.  **ระบุข้อจำกัดอย่างชัดเจนและแคบ** — `without modifying files outside /auth`, `without removing existing assertions`, `without bumping major versions` หากไม่มีข้อจำกัดเหล่านี้ Claude อาจแก้การทดสอบด้วยการลบการทดสอบเอง

5.  **commit หรือ push การเปลี่ยนแปลงสำคัญทั้งหมดแล้ว** — หากไม่ได้ทำงานใน worktree (เช่น `worktree.bgIsolation: "none"`) Claude จะแก้สำเนาที่คุณกำลังทำงานอยู่ ความผิดพลาดอาจทำให้งานที่ยังไม่ได้บันทึกสูญหาย

6.  **เปิดใช้ขีดจำกัดการใช้งานใน Settings → Usage แล้ว** — มาตรการป้องกันใหม่หลังเหตุการณ์ 6,000 ดอลลาร์ ตั้งขีดจำกัดต่อวัน ต่อเซสชัน และต่อเดือน

7.  **เปิด Agent View ด้วย `claude agents` ในหน้าต่างแยก** — สำหรับงานยาว ให้ peek ด้วย Space ทุกชั่วโมง หากจำนวนรอบเพิ่มเร็วเกินคาด หรือตัวประเมินให้เหตุผลเดิมซ้ำสามรอบ ให้กด `Ctrl+C` แล้วเรียบเรียงเงื่อนไขใหม่

ข้อเพิ่มเติม — **ห้ามใช้ `/goal` กับ `--dangerously-skip-permissions` ในโค้ดของผู้อื่นหรือโค้ดที่ไม่คุ้นเคยเด็ดขาด** การใช้ร่วมกันจะปิดการตรวจสอบทั้งหมดและปล่อยให้เอเจนต์ทำอะไรก็ได้ในโปรเจกต์ของคุณ ผู้เขียนบทวิเคราะห์นี้ใช้ตัวเลือกดังกล่าวเฉพาะใน worktree ใหม่ที่ไม่มีอะไรให้สูญเสีย

`/goal` เป็นฟีเจอร์ทรงพลัง แต่ไม่ใช่เวทมนตร์ มันทำงานได้ดีเท่ากับความชัดเจนในการเขียนเงื่อนไขของคุณ หากอธิบายเป็นคำพูดได้ว่าอะไรคือ «เสร็จแล้ว» และมีคำสั่งตรวจสอบได้ `/goal` ก็จะจัดการส่วนที่เหลือ หากอธิบายไม่ได้ ให้กลับไปใช้เซสชันปกติหรือ Plan Mode

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

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

- [Anthropic Docs - คำสั่ง /goal](https://code.claude.com/docs/en/goal)
- [Anthropic Docs - Agent View](https://code.claude.com/docs/en/agent-view)
- [Anthropic Docs - เรียกใช้เอเจนต์แบบขนาน](https://code.claude.com/docs/en/agents)
- [Anthropic Docs - Worktree](https://code.claude.com/docs/en/worktrees)
- [Anthropic Docs - โหมด headless](https://code.claude.com/docs/en/headless)
- [Anthropic Claude Code Changelog](https://code.claude.com/docs/en/changelog)

</div>

อ่านต่อเกี่ยวกับ Ailoot ได้ที่ [ailoot.ai](https://ailoot.ai/)

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

### เขียนเงื่อนไขจบให้ตัวประเมินตรวจได้อย่างไร?

ระบุผลวัดได้หนึ่งอย่าง คำสั่งหรือหลักฐานยืนยัน และข้อจำกัด เช่น รักษา assertions หรือแก้เฉพาะไฟล์ที่กำหนด ใส่เพดานหยุดชัดและให้เอเจนต์แสดงผลตรวจในบทสนทนา

### ตัวคูณประสิทธิภาพโทเค็นคงที่เพียงพอสำหรับเลือกเอเจนต์หรือไม่?

ไม่ได้ ไม่มีการวัดเงื่อนไขเท่ากันรองรับ ต้องเทียบงานที่ยอมรับเดียวกันและบันทึกโมเดล รุ่นไคลเอนต์ โหมดรัน แคช โทเค็น เวลา และการแก้ของมนุษย์


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

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

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

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