` | ปรับโครงสร้างโค้ดเชิงกลแบบขนาน | v2.1.63+ | แต่ละหน่วยมี git worktree ของตัวเอง |
`/goal` เป็นคำสั่งที่คล้าย Ralph Loop มากที่สุด เบื้องหลังจะมีโมเดลประเมินผล (ค่าเริ่มต้นคือ Haiku) ตรวจสอบในแต่ละรอบว่าบรรลุเป้าหมายแล้วหรือยัง ถ้ายัง รอบถัดไปจะมีคำแนะนำว่าสิ่งใดต้องแก้ไขโดยเฉพาะ ถ้าบรรลุแล้วก็จะหยุด ฉันอธิบาย `/goal` อย่างละเอียดในคู่มือเรื่อง[การเรียกใช้ Claude Code แบบอัตโนมัติตลอดคืนด้วย /goal](https://ailoot.ai/blog/th/goal-mode-claude-code-codex/) ซึ่งมีสถานการณ์พร้อมใช้สำหรับการทำงาน 14 ชั่วโมง
`/batch` เป็นคำสั่งที่ไม่ค่อยมีคนใช้แต่ทรงพลัง เมื่อต้องทำการเปลี่ยนแปลงแบบเดียวกันในไฟล์มากกว่า 100 ไฟล์ (ย้าย API เปลี่ยนคอมโพเนนต์ หรือเปลี่ยนชื่อ) `/batch` จะส่งแต่ละไฟล์ไปให้ subagent แยกกัน โดยแต่ละตัวมี git worktree ของตัวเอง การเปลี่ยนแปลงจึงไม่ขัดแย้งกัน — เอเจนต์แต่ละตัวทำงานในสำเนาที่แยกจากกัน ดูข้อมูลเพิ่มเติมเกี่ยวกับ subagents ได้ในคู่มือเรื่อง [subagents แบบซ้อน](https://ailoot.ai/blog/th/claude-code-nested-subagents/)
ในคำอธิบายแนวทางนี้ของผู้เขียน เขาเรียกมันสั้นๆ ว่า:
ขีดจำกัดที่เข้มงวดของ `/loop` และ `/goal`:
- งานจะทำงานตราบใดที่ Claude Code เปิดอยู่ ปิดเทอร์มินัลแล้วลูปก็หยุด สำหรับรอบกลางคืนที่จริงจัง ให้ใช้เซิร์ฟเวอร์ระยะไกลหรือ shell wrapper ของคุณเอง
- อายุการทำงานสูงสุดของงานที่ทำซ้ำคือ **7 วัน** (หลังจากนั้นจะถูกลบโดยอัตโนมัติเพื่อป้องกันลูปที่ถูกลืม)
- ทำงานพร้อมกันได้สูงสุด **50 งาน** ในหนึ่งเซสชัน
## วิธีเริ่มลูปอัตโนมัติแรกของคุณใน 5 นาที
ประเด็นสำคัญ
วิธีเริ่มต้นที่เร็วที่สุดคือใช้ `/goal` ที่มีมาให้ เปิด Claude Code ป้อนคำสั่งที่ระบุเป้าหมายและเงื่อนไขหยุดที่ตรวจสอบได้ แล้วไปทำธุระของคุณ Claude จะสร้างโค้ด รันการทดสอบ อ่านข้อผิดพลาด แก้ไข แล้วรันทดสอบอีกครั้งจนกว่าจะผ่าน
5 ขั้นตอน:
1. ### เปิดโปรเจกต์ใน Claude Code
ไปที่รากของโปรเจกต์ในเทอร์มินัลแล้วรัน `claude` รอให้ Claude อ่าน `CLAUDE.md` และทำดัชนี repository
2. ### กำหนดเป้าหมายและเงื่อนไขหยุด
เป้าหมายคือสิ่งที่ต้องทำ เงื่อนไขหยุดคือวิธีที่ Claude จะรู้ว่าทำเสร็จแล้ว ตามหลักแล้วควรเป็นคำสั่งที่คืนค่า 0 หรือ 1 ตัวอย่าง: “เป้าหมาย: การทดสอบทั้ง 23 รายการใน `tests/api/*.test.ts` ต้องผ่าน หยุดเมื่อ `pnpm test` คืนค่า exit 0”
3. ### เรียกใช้ /goal
คำสั่ง:
```
/goal การทดสอบทั้งหมดใน tests/api/*.test.ts ต้องผ่าน รัน pnpm test อ่านข้อผิดพลาด แก้ไข แล้วรันอีกครั้ง หยุดเมื่อ exit code = 0 จำนวนรอบสูงสุด 20 รอบ
```
Claude เริ่มลูป: รันทดสอบ — พบข้อผิดพลาด — เปิดไฟล์ — แก้ไข — รันอีกครั้ง
4. ### ตั้งขีดจำกัดงบประมาณ
ใช้ `/usage` ในแท็บเบื้องหลังเพื่อติดตามการใช้งาน ตั้งขีดจำกัดโทเคนหรือค่าใช้จ่ายรายวัน เพื่อไม่ให้ใช้ยอดคงเหลือทั้งหมดไปกับลูปเดียว ดูรายละเอียดเพิ่มเติมในคู่มือเรื่อง[วิธีไม่ใช้ขีดจำกัด Claude Code จนหมด](https://ailoot.ai/blog/th/claude-code-token-limits-saving/)
5. ### ไปทำธุระของคุณ
กลับมาดูอีกครั้งใน 30 นาที ถ้างานง่าย คุณจะเห็นข้อความ “DONE, การทดสอบทั้งหมดผ่าน” แล้ว ถ้าซับซ้อนกว่านั้น ให้อ่านรายงาน: “หยุดที่รอบ 20 ด้วยเหตุผล X” แก้ด้วยมือในส่วนที่ลูปทำไม่สำเร็จ แล้วเริ่มใหม่
## รูปแบบ verifier: วิธีที่ Claude ตรวจสอบงานของตัวเองในลูป
ประเด็นสำคัญ
Claude ควรมีวิธีตรวจสอบงานของตัวเองอยู่เสมอ หากไม่มีการตรวจสอบ เอเจนต์ในลูปจะเริ่มหลอนข้อมูล — มันตัดสินใจว่างานเสร็จแล้วทั้งที่ทุกอย่างพัง verifier คือคำสั่ง (การทดสอบ lint โมเดลประเมินผล หรือการตรวจสอบแบบกำหนดเอง) ที่ส่งผลลัพธ์ชัดเจนว่า “เสร็จ/ยังไม่เสร็จ”
verifier มีสามประเภท:
**1. ทางเทคนิค (exit code)** — เชื่อถือได้มากที่สุด `pnpm test`, `npm run lint`, `tsc --noEmit`, `playwright test` คำสั่งเหล่านี้คืนค่า 0 หรือ 1 โดยไม่ต้องตีความ `/goal` ก็ทำงานแบบนี้เช่นกัน — เบื้องหลังใช้โมเดลประเมินผล Haiku ตรวจสอบในแต่ละรอบว่าเงื่อนไขเป็นจริงหรือยัง (ได้สูงสุด 4000 ตัวอักษร)
**2. โมเดลประเมินผล** — โมเดลตัวที่สองตรวจดูผลลัพธ์ของโมเดลแรกและให้คะแนนตามเกณฑ์ เหมาะกับงานที่ไม่มีการตรวจสอบอย่างเป็นทางการ (“สำนวนการเขียนดีไหม” “ดีไซน์ตรงกับแบรนด์ไหม”) ที่ Anthropic เรียกสิ่งนี้ว่า `Claude Code Review` — โหมดที่เอเจนต์ผู้ตรวจสอบแยกต่างหากค้นหาข้อผิดพลาดทางตรรกะ กรณีขอบ และปัญหาด้านความปลอดภัยในงานของเอเจนต์หลัก ตามข้อมูลภายในของ Anthropic มันพบ **84% ของปัญหา** ใน PR ขนาดใหญ่ (เพิ่มจาก 16% ในแนวทางพื้นฐาน)
**3. การตรวจสอบแบบกำหนดเอง** — shell script ที่คุณเขียนเอง “ถ้าในบันทึกไม่มีคำว่า ERROR ก็ถือว่าเสร็จ” “ถ้ามีไฟล์ `output.json` และแยกวิเคราะห์ได้ ก็ถือว่าเสร็จ” “ถ้าหน้า `/pricing` ตอบกลับ 200 ก็ถือว่าเสร็จ”
นี่คือแม่แบบพรอมป์ต์ที่ฉันใส่ไว้ใน `CLAUDE.md` หรือในคำสั่ง:
```
ค้นหา 10 เหตุผลที่โครงการนี้อาจพัง
ลองมองจากมุมที่มีบางอย่างผิดพลาด
ฉันสามารถไล่ตรวจเรื่องราวนี้ได้หลายครั้ง -
ก่อนเผยแพร่ต่อสาธารณะ
```
ข้อผิดพลาดที่มือใหม่ทำกันบ่อยที่สุดคือ **เริ่มลูปโดยไม่มี verifier** เอเจนต์หมุนวนอยู่กับที่: เขียนโค้ด ไม่ตรวจสอบ คิดว่าทำเสร็จแล้ว ไปยังรอบถัดไป แล้วเขียนสิ่งที่ทำไปแล้วซ้ำอีก สามชั่วโมงต่อมาก็เละเทะ และบิลอยู่ที่ $200
กฎที่ดีที่สุดคือ **เขียน verifier ก่อน แล้วค่อยเริ่มลูป** ถ้าคุณระบุเงื่อนไขหยุดเป็นประโยคเดียวไม่ได้ แสดงว่างานยังไม่พร้อมให้ทำแบบอัตโนมัติ
## วิธีไม่ใช้เงินหลายพันดอลลาร์จนหมดในชั่วข้ามคืน: ขีดจำกัดงบประมาณและเงื่อนไขหยุด
ประเด็นสำคัญ
ลูปที่ไม่มีขีดจำกัดงบประมาณ ไม่มีเงื่อนไขหยุดตามค่าใช้จ่าย และไม่มี verifier อาจใช้เงินจำนวนมากก่อนที่จะมีใครสังเกตเห็น มาตรการป้องกันสามข้อช่วยลดความเสี่ยงนี้: จำกัดจำนวนรอบ จำกัดโทเคนหรือค่าใช้จ่าย และมีตัวตรวจจับการหยุดชะงัก
เบรกสำคัญสามข้อสำหรับลูปที่ทำงานข้ามคืน:
**1. จำกัดจำนวนรอบ** `--max-iterations 20` ลูปจะทำงานได้ไม่เกิน N ครั้ง แม้ verifier จะไม่ทำงานก็ตาม หากยังไม่ถึงเงื่อนไขหยุดหลังจาก 20 รอบ แสดงว่างานติดขัดและต้องให้คนเข้ามาจัดการ
**2. จำกัดโทเคนหรือค่าใช้จ่าย** `/usage limit 50` — ใช้ไม่เกิน $50 ต่อวัน เมื่อใกล้ถึงขีดจำกัด ลูปจะหยุดเองและส่งการแจ้งเตือน วิธีนี้ช่วยป้องกันไม่ให้ลูปใช้จ่ายเกินควบคุม
**3. ตรวจความคืบหน้าด้วยข้อตกลงชัดเจน** การเทียบ `HEAD` ด้านล่างตรวจ commit ใหม่ ไม่ใช่การแก้โค้ดทุกแบบ ใช้เฉพาะ worktree แยกที่ทุกรอบเปลี่ยนโค้ดบันทึก local checkpoint commit ก่อนเทียบ การแก้ที่มีประโยชน์แต่ยังไม่ commit ไม่เปลี่ยน `HEAD` หากไม่มีข้อตกลงนี้ hash เดิมอาจส่งสัญญาณหยุดนิ่งผิด เก็บผล verifier ด้วย เพราะ commit ใหม่พิสูจน์เพียงว่าบันทึกการเปลี่ยน ไม่ใช่ว่าดีขึ้นหรือผ่าน
โครงสร้าง wrapper ตัวอย่างที่มีการตรวจสามอย่าง คำสั่งรายงานต้นทุนและเรียกเอเจนต์เป็นตัวอย่างเฉพาะ runner ไม่ใช่สูตรติดตั้ง CLI ที่พิสูจน์แล้ว ต้องตรวจอินเทอร์เฟซของรุ่นติดตั้งก่อนปรับใช้ ตัวตรวจตาม commit ต้องมี local checkpoint commit ทุกครั้งที่แก้โค้ด หาก runner ทิ้งการแก้ยังไม่ commit ให้หยุดตรวจแทนเรียกว่าไม่มีความคืบหน้า:
```bash
#!/bin/bash
PROMPT="$1"
MAX_ITER=20
MAX_COST_USD=50
COMPLETION="DONE"
PREV_HASH=""
STAGNATION=0
for i in $(seq 1 $MAX_ITER); do
# ขีดจำกัดค่าใช้จ่าย
CURRENT_COST=$(claude usage --json | jq '.cost_usd')
if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
echo "STOP: ถึงขีดจำกัดงบประมาณ $MAX_COST_USD แล้ว"
break
fi
# เรียกใช้
OUTPUT=$(claude code -p "$PROMPT" --auto-accept)
# ตรวจสอบการเสร็จสิ้น
if echo "$OUTPUT" | grep -q "$COMPLETION"; then
echo "STOP: ได้รับสัญญาณเสร็จสิ้น"
break
fi
# ตรวจเฉพาะความคืบหน้า commit: ทุกรอบที่แก้โค้ดต้องมี checkpoint commit
# HEAD มองไม่เห็นการแก้ที่มีประโยชน์ซึ่งยังไม่ commit
CURRENT_HASH=$(git rev-parse HEAD 2>/dev/null)
if [ "$CURRENT_HASH" = "$PREV_HASH" ]; then
STAGNATION=$((STAGNATION + 1))
if [ "$STAGNATION" -ge 3 ]; then
echo "STOP: หยุดชะงัก 3 รอบ"
break
fi
else
STAGNATION=0
fi
PREV_HASH="$CURRENT_HASH"
done
```
ตรวจตัววัดก่อนขยายโครงร่าง: การแก้ไม่มี commit คือการทำงานที่ยังไม่บันทึก checkpoint commit เปลี่ยน `HEAD` และมีเพียง verifier แยกที่ยืนยันสำเร็จได้ HEAD ไม่เปลี่ยนสามรอบหมายถึงไม่มีการเปลี่ยนที่บันทึกตามข้อตกลง ไม่พิสูจน์ว่าไฟล์ทำงานทั้งหมดไม่เปลี่ยน จากนั้นจึงเพิ่มการแจ้งเตือน Slack เมื่อหยุด รายงานอัตโนมัติผ่าน Telegram ในตอนเช้า หรือการแจ้งเตือน push เมื่อใช้งบประมาณถึง 80% หลักการยังเหมือนเดิม: ลูปต้องมี **เบรก** ไม่ใช่มีแต่คันเร่ง
## 5 สถานการณ์ลูปข้ามคืนพร้อมใช้
ประเด็นสำคัญ
ไม่ใช่ทุกงานจะเหมาะกับลูปอัตโนมัติ งานที่เหมาะคือมี verifier ชัดเจนและทำซ้ำเป็นรอบได้ เช่น การทดสอบ การปรับโครงสร้างโค้ด การติดตามตรวจสอบ กระบวนการทำบทความ และการนำเข้าข้อมูล งานที่ไม่เหมาะคือไม่มีการตรวจสอบอย่างเป็นทางการหรือมีเกณฑ์เชิงอัตวิสัยหลายข้อ
**สถานการณ์ 1: ทำให้การทดสอบที่ล้มเหลวผ่านทั้งหมด**
```
/goal มีการทดสอบที่ล้มเหลว 47 รายการในไดเรกทอรี tests/ เป้าหมาย: ทำให้ทั้งหมดผ่าน
รัน pnpm test อ่าน stderr เปิดไฟล์ที่มีข้อผิดพลาด แก้ไข แล้วรัน pnpm test อีกครั้ง
หยุดเมื่อ exit 0 สูงสุด 30 รอบ
```
**สถานการณ์ 2: ปรับโครงสร้างครั้งใหญ่ใน 200 ไฟล์**
```
/batch แทนที่ไคลเอนต์ API apiV1 รุ่นเก่าด้วย apiV2 รุ่นใหม่ในไฟล์ทั้งหมดใต้ src/**/*.ts
ให้แต่ละไฟล์มี worktree ของตัวเอง หลังแทนที่แล้ว รัน tsc --noEmit และแก้ข้อผิดพลาดที่พบ
รวม worktree เข้าด้วยกันเมื่อเสร็จ
```
**สถานการณ์ 3: ติดตามตรวจสอบระบบโปรดักชันข้ามคืน**
```
/loop 30m ทุก 30 นาที ตรวจสอบ https://your-app.example.com/api/health
หากไม่ได้รับสถานะ 200 ให้อ่านบันทึก หาสาเหตุ แก้ไข และปรับใช้ใหม่
บันทึกแต่ละรอบไว้ที่ /tmp/night-monitor.log
```
**สถานการณ์ 4: นำเข้าชุดข้อมูลขนาดใหญ่พร้อมลบรายการซ้ำ**
```
/goal นำเข้าไฟล์ CSV /tmp/import.csv (12,000 แถว) ไปยังตาราง clients
สำหรับแต่ละแถว ให้ตรวจหารายการซ้ำด้วยอีเมล หากไม่มี ให้เพิ่มรายการ หากมี ให้อัปเดต
บันทึกความขัดแย้งไว้ที่ /tmp/conflicts.log หยุดเมื่อประมวลผลแถวสุดท้ายแล้ว
```
**สถานการณ์ 5: กระบวนการทำบทความ (รูปแบบทั่วไป)**
สำหรับบริการออนไลน์หรือเอเจนซีที่ต้องการบทความ SEO เป็นประจำ สถานการณ์จะเป็นดังนี้:
```
/loop 8h ทุก 8 ชั่วโมง: เปิดไฟล์ backlog เพื่อหาหัวข้อที่มีสถานะ 'queued'
หากมีหัวข้อ ให้เรียกใช้ skill สำหรับเขียนคู่มือ
เผยแพร่ไปยัง dev เปลี่ยนสถานะเป็น 'review' แจ้งผู้รับผิดชอบทาง Telegram
```
สถานการณ์นี้คือการใช้ลูปทำงานข้ามคืน โดยแต่ละลูปมีงานของตัวเอง หลักการสำคัญคือแบ่งงานเป็นส่วนและให้แต่ละลูปมีหน้าที่ชัดเจน:
## สิ่งที่ควรจัดเตรียมให้ในแต่ละรอบ: CLAUDE.md และ Second Brain ในฐานะ state
ประเด็นสำคัญ
หากไม่มีหน่วยความจำ Claude จะเริ่มแต่ละรอบจากศูนย์ — เปิดโปรเจกต์ใหม่ อ่านไฟล์ และลืมการตัดสินใจจากรอบก่อน หากไม่มี `CLAUDE.md` ก็ไม่รู้จักสถาปัตยกรรม หากไม่มี `business/` (Second Brain) ก็ไม่รู้บริบทของผลิตภัณฑ์ และหากไม่มี skills ก็จำกฎและสไตล์ของคุณไม่ได้ state ระหว่างรอบจะถูกเก็บไว้ในไฟล์สามชั้นนี้ หากไม่มีสิ่งเหล่านี้ ลูปจะเสื่อมลงภายในรอบที่ 5
หน่วยความจำโปรเจกต์สามชั้นเปลี่ยนพรอมป์ต์ครั้งเดียวให้เป็นลูปที่ควบคุมได้:
**1. CLAUDE.md** — ธรรมนูญของโปรเจกต์ ผลิตภัณฑ์คืออะไร ใช้ tech stack อะไร มีกฎอะไร และห้ามทำอะไรเด็ดขาด Claude อ่านไฟล์นี้เมื่อเริ่มแต่ละเซสชันและแต่ละรอบของลูป หากไม่มีไฟล์นี้ Claude ต้อง “เปิด” โปรเจกต์ใหม่ทุกครั้ง — ใช้ context จนหมดและเพิ่มความเสี่ยงที่จะหลอนข้อมูล ดูแม่แบบพร้อมใช้และกฎ 6 ข้อได้ในคู่มือ [CLAUDE.md](https://ailoot.ai/blog/th/claude-md-template/)
**2. Second Brain** — โฟลเดอร์ที่เก็บความรู้ทางธุรกิจ: ผลิตภัณฑ์ กลุ่มเป้าหมาย เป้าหมาย เศรษฐศาสตร์ และการตลาด ไม่ใช่โค้ด แต่เป็นความหมาย เมื่อลูปเขียนบทความหรือค้นหาคำตอบให้ฝ่ายสนับสนุน ก็จะอ่าน Second Brain และตอบจากบริบทของโปรเจกต์ ไม่ใช่จากความว่างเปล่า
**3. Context engineering** — สิ่งที่คุณป้อนให้ Claude ในแต่ละรอบ ไม่ใช่โฟลเดอร์ Second Brain ทั้งหมด ไม่ใช่ repository ทั้งหมด แต่เฉพาะส่วนที่เกี่ยวข้อง Plan Mode ช่วยได้: Claude จะกำหนดว่าไฟล์ใดจำเป็นสำหรับงาน แล้วอ่านเฉพาะไฟล์เหล่านั้น ดูรายละเอียดเพิ่มเติมในคู่มือ [Plan Mode](https://ailoot.ai/blog/th/claude-code-plan-mode/)
หลักการปฏิบัติการสำคัญที่ฉันต้องย้ำให้เข้าใจผ่านความผิดพลาดคือ:
แต่ละเซสชันมีอะไรบ้าง? งานแตกต่างกัน: ลูปหนึ่งแก้บั๊ก อีกลูปเขียนฟีเจอร์ใหม่ ลูปที่สามรีวิว PR ของทีม ลูปที่สี่ปรับปรุงประสิทธิภาพ และลูปที่ห้าเตรียมเอกสาร ไม่ใช่เอเจนต์อเนกประสงค์ขนาดใหญ่ตัวเดียว แต่เป็นเอเจนต์เฉพาะทางหลายสิบตัว แต่ละตัวมี skill เป้าหมาย และ verifier ของตัวเอง
การปรับกรอบความคิดที่สำคัญ:
สำหรับผู้ประกอบการที่ไม่มีโปรแกรมเมอร์ นี่หมายถึงสิ่งที่จับต้องได้ คุณมีบัญชี Claude หนึ่งบัญชีราคา $200/เดือน และแล็ปท็อปทั่วไป คุณเปิด **5 ลูปพร้อมกัน** ได้ — ฝ่ายสนับสนุน บทความ ตัวชี้วัด การทดสอบผลิตภัณฑ์ใหม่ และการติดตามคู่แข่ง แต่ละลูปทำงานในแท็บ Claude Code ของตัวเอง ตอนเช้าคุณอ่านสรุป นี่เป็นบรรทัดฐานของการทำงานในฤดูร้อนปี 2026 แล้ว
## ปัญหาที่พบบ่อย 4 ข้อของลูปอัตโนมัติ
ประเด็นสำคัญ
ปัญหาส่วนใหญ่ของลูปอัตโนมัติเข้ากับรูปแบบ 4 แบบ: ไม่มี verifier — เอเจนต์ตัดสินใจเองว่าเสร็จแล้ว; ไม่มีขีดจำกัดงบประมาณ — ลูปอาจใช้เงินเกินงบในชั่วข้ามคืน; ไม่มี state ระหว่างรอบ — การตัดสินใจขัดแย้งกันเอง; เงื่อนไขหยุดคลุมเครือ — ลูปไม่รู้ว่าควรหยุดเมื่อใด
**ปัญหา 1: “ลูปหลอนข้อมูล”**
เอเจนต์ตัดสินใจว่าทำเสร็จแล้วทั้งที่ verifier ยังไม่ทำงาน หรือไม่มี verifier เลย สามชั่วโมงต่อมา Claude บอกว่า “เสร็จหมดแล้ว!” — แต่การทดสอบยังล้มเหลว หน้าเว็บเปิดไม่ได้ และไม่มีอะไรทำงาน คุณเสียเงิน $80 ไปกับการทำซ้ำที่ไร้ประโยชน์แล้ว
**วิธีแก้:** ใช้ verifier ที่เข้มงวด (ค่า `exit code` ของคำสั่ง) ไม่ใช่การตรวจด้วยคำพูด
**ปัญหา 2: “งบประมาณหมดระหว่างคืน”**
หากไม่มีขีดจำกัดงบประมาณ ลูปก็เหมือนระเบิดที่ไม่มีสลักนิรภัย
**วิธีแก้:** ใช้ `/usage limit` หรือสคริปต์ภายนอกที่ใช้ `claude usage --json` เพื่อหยุดลูปเมื่อถึงเกณฑ์
**ปัญหา 3: “ลูปทำบริบทระหว่างรอบหาย”**
ในรอบที่ 1 Claude ตัดสินใจเรื่องสถาปัตยกรรม พอถึงรอบที่ 7 ก็ลืมแล้วตัดสินใจตรงกันข้าม หลังจาก 15 รอบ โค้ดก็กลายเป็นกองระเกะระกะ
**วิธีแก้:** เพิ่มชั้น state ผ่าน `CLAUDE.md` และโฟลเดอร์ Second Brain ลูปจะ**เขียน**การตัดสินใจด้านสถาปัตยกรรมทุกครั้งลงในไฟล์ที่อ่านในรอบถัดไป
**ปัญหา 4: “เงื่อนไขหยุดไม่ชัดเจน — ลูปทำงานไม่รู้จบ”**
`/goal "Make the page beautiful"` — “สวย” หมายถึงอะไร? หากไม่มีตัวชี้วัดที่ชัดเจน ลูปก็จะไม่หยุด มันจะทำงานต่อไปจนถึงขีดจำกัดจำนวนรอบหรืองบประมาณ
**วิธีแก้:** เงื่อนไขหยุดต้อง**วัดผลได้**เสมอ ไม่ใช่ “สวย” แต่เป็น “Lighthouse Performance ≥ 90, Accessibility ≥ 95” ไม่ใช่ “ใช้งานได้” แต่เป็น “การทดสอบใน `tests/pricing.test.ts` ผ่าน”
## เมื่อใดที่ไม่จำเป็นต้องใช้ loop engineering
ประเด็นสำคัญ
Loop engineering เป็นเครื่องมือสำหรับงานซ้ำๆ ที่ตรวจสอบได้ ไม่จำเป็นสำหรับงานสร้างสรรค์ที่ทำครั้งเดียว งานที่ไม่มี verifier อย่างเป็นทางการ และงานที่ต้องประเมินเชิงอัตวิสัย การรู้ขีดจำกัดสำคัญกว่าการรู้เทคนิค
งานที่ไม่เหมาะกับลูปอัตโนมัติ:
- **งานสร้างสรรค์ที่ทำครั้งเดียว** เว็บไซต์หนึ่งเว็บสำหรับผลิตภัณฑ์ใหม่ โลโก้หนึ่งชิ้น บันทึกเชิงกลยุทธ์หนึ่งฉบับ การใช้ลูปกับงานเหล่านี้เกินจำเป็น เขียนพรอมป์ต์เดียวแล้วปรับผลลัพธ์ด้วยมือจะง่ายกว่า
- **งานที่ไม่มี verifier** หากคุณไม่สามารถระบุเงื่อนไขหยุดเป็น exit code หรือสัญญาณที่ชัดเจนได้ ก็อย่าเริ่มลูป ไม่เช่นนั้นจะกลายเป็นกองไฟที่เผาไหม้ไม่รู้จบ
- **งานที่ต้องประเมินเชิงอัตวิสัย** “ทำให้ฟังดูดีขึ้น” “ปรับปรุง UX ให้ใช้งานรื่นรมย์ขึ้น” — งานเหล่านี้ต้องใช้คุณ ไม่ใช่ลูป
- **โดเมนใหม่ที่ไม่คุ้นเคย** หากคุณเองยังไม่เข้าใจว่า “เสร็จแล้ว” ควรมีหน้าตาอย่างไร อย่าเรียกใช้ Claude เป็นลูป ทำความเข้าใจก่อน แล้วค่อยทำให้เป็นระบบอัตโนมัติ
และกฎสำคัญที่ฉันเรียนรู้จากความผิดพลาดคือ:
คำถามหลักก่อนเริ่มลูปคือ: **ฉันอธิบายได้ในหนึ่งบรรทัดไหมว่าจะรู้ได้อย่างไรว่า Claude ทำเสร็จแล้ว?** ถ้าได้ ลูปก็ช่วยคุณได้ ถ้าไม่ได้ ให้กำหนดเงื่อนไขที่ตรวจสอบได้ก่อน แล้วค่อยเริ่ม
### แหล่งที่มา
- [ปลั๊กอิน Ralph Loop สำหรับ Claude - Anthropic](https://claude.com/plugins/ralph-loop) - ปลั๊กอินอย่างเป็นทางการ
- [ปลั๊กอิน Ralph Wiggum บน GitHub - Anthropic](https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum) - ซอร์สโค้ด
- [Claude Code Review - Anthropic blog](https://claude.com/blog/code-review) - ตัวอย่างวิจัยสำหรับการรีวิว PR แบบหลายเอเจนต์ อัตราการค้นพบปัญหา 84%
- [เอกสาร /goal - Claude Code Docs](https://code.claude.com/docs/en/goal) - เอกสารคำสั่งอย่างเป็นทางการ
- [เอกสาร /loop สำหรับงานที่กำหนดเวลา - Claude Code Docs](https://code.claude.com/docs/en/scheduled-tasks) - เอกสารอย่างเป็นทางการ
Loop engineering เป็นชั้นที่ต่อยอดจากทุกสิ่งที่คุณรู้เกี่ยวกับ Claude Code อยู่แล้ว สำรวจ Ailoot ต่อได้ที่ [ailoot.ai](https://ailoot.ai/).
## คำถามที่พบบ่อย
### ทำไม HEAD เดิมอาจทำให้เข้าใจผิดว่าลูปไม่คืบหน้า?
HEAD ระบุ commit การแก้ใน working tree ไม่เปลี่ยนจน commit ตัวอย่างจึงต้องมี local checkpoint commit หลังทุกรอบแก้โค้ด หากไม่มีข้อตกลงนี้ให้พักตรวจการแก้ที่ยังไม่ commit แทนเรียกว่าหยุดนิ่ง
### commit ใหม่พิสูจน์ว่าลูปทำผลดีขึ้นหรือไม่?
ไม่พิสูจน์ บอกเพียงว่าบันทึกการเปลี่ยน ต้องเก็บผล verifier คู่ checkpoint และหยุดตามเกณฑ์ยอมรับจริง อินเทอร์เฟซเรียก runner กับรายงานต้นทุนต้องตรวจให้ใช้ได้ก่อนใช้ wrapper
## Ailoot · บริษัทและพอร์ตโฟลิโอโครงการของบริษัท
Ailoot อาศัยประสบการณ์การดำเนินงานที่สั่งสม ฐานลูกค้าขนาดใหญ่ บริการที่เสถียร และการติดตาม KPI อย่างต่อเนื่อง
บริษัทและพอร์ตโฟลิโอโครงการของบริษัท: ลูกค้าหลายล้านราย; ยอดขายระดับหลายพันล้านต่อเดือน.
Ailoot นำประสบการณ์การดำเนินงานนี้มาใช้เพื่อให้เข้าถึงฟังก์ชัน AI ผ่าน API ในผลิตภัณฑ์ของลูกค้า เอเจนต์ แอปพลิเคชัน และระบบอัตโนมัติ