วิธีสร้างลูป (Loops) ด้วย Claude Code

ลูปของ Claude คืออะไรกันแน่

ลูปไม่ใช่ "แค่ถาม Claude อีกครั้ง"

ลูปคือโครงสร้างเวิร์กโฟลว์ที่สามารถทำซ้ำได้รอบๆ โมเดล

มันกำหนด:

→ อะไรเป็นตัวกระตุ้นให้รัน

→ Claude อ่านบริบทอะไรก่อนที่จะลงมือทำ

→ Claude ได้รับอนุญาตให้ทำอะไร → ตรวจสอบผลลัพธ์อย่างไร

→ จัดเก็บสถานะไว้ที่ไหน

→ เมื่อไหร่ควรหยุด ทำซ้ำ หรือขอให้มนุษย์ตรวจสอบ

โมเดลยังคงเป็นคนใช้เหตุผล

ลูปเป็นผู้จัดหาโครงสร้างการทำงาน

การเปลี่ยนแปลงนี้สำคัญเพราะเซสชันของ Claude เป็นเพียงชั่วคราว

หากไม่มีลูป ทุกครั้งที่รันก็จะเริ่มจากศูนย์ เมื่อมีลูป Claude จะอ่านสิ่งที่เกิดขึ้นก่อนหน้านี้และดำเนินการต่อจากจุดนั้น

6 ส่วนที่ทุก Claude Loop ต้องการ

ลูปที่ไม่มีโครงสร้างก็เป็นแค่พรอมต์ที่รันสองครั้ง

ต่อไปนี้คือ 6 ส่วนที่ทำให้ลูปทำงานได้จริง:

→ 1. ตัวกระตุ้น (Trigger)

อะไรเป็นจุดเริ่มต้นการรัน

คำสั่งด้วยตนเอง ตัวจับเวลาที่กำหนดไว้ การเปลี่ยนแปลงไฟล์ CI ล้มเหลว เหตุการณ์จาก Git

→ 2. บริบท (Context)

Claude อ่านอะไรก่อนลงมือทำ

คำจำกัดความของงาน ความคืบหน้าก่อนหน้า ไฟล์โปรเจกต์ คำแนะนำ

→ 3. การดำเนินการ (Action)

Claude ทำอะไร

เขียนรายงาน ร่างการแก้ไข จัดประเภทความล้มเหลว อัปเดตเอกสาร

→ 4. การตรวจสอบ (Verification)

คุณตรวจสอบผลลัพธ์อย่างไร

รายการตรวจสอบ ชุดทดสอบ ส่วนที่จำเป็น การตรวจสอบขอบเขตความปลอดภัย

→ 5. การอัปเดตสถานะ (State update)

อะไรที่ถูกจดจำไว้สำหรับครั้งต่อไป

อัปเดต PROGRESS.md บันทึกอุปสรรค นำทางการรันครั้งถัดไป

→ 6. การตัดสินใจ (Decision)

หยุด ทำซ้ำ หรือส่งต่อไปยังมนุษย์

นั่นคือลูปที่สมบูรณ์

และทุกขั้นตอนล้วนมีความสำคัญ

ข้ามการตรวจสอบ → ลูปจะเชื่อใจตัวเองอย่างสุ่มสี่สุ่มห้า

ข้ามสถานะ → ทุกครั้งที่รันจะเริ่มจากศูนย์

ข้ามการตัดสินใจ → ลูปจะไม่มีวันรู้ว่าเมื่อไหร่ควรหยุด

ระบบ 4 ไฟล์ที่ทำให้ลูปทำงานได้

คุณไม่จำเป็นต้องมีโครงสร้างพื้นฐาน

คุณแค่ต้องการ 4 ไฟล์และ 1 โฟลเดอร์

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — เป้าหมาย สิ่งที่ลูปนี้พยายามทำให้สำเร็จ

LOOP_INSTRUCTIONS.md — ขั้นตอนการดำเนินการ วิธีที่ Claude ควรทำงาน สิ่งที่ได้รับอนุญาตให้ทำ วิธีตรวจสอบ

PROGRESS.md — หน่วยความจำ สิ่งที่เกิดขึ้นครั้งที่แล้ว มีอะไรติดขัด การรันครั้งต่อไปควรมุ่งเน้นอะไร

outputs/ — ที่ที่ Claude เขียนผลลัพธ์ คาดเดาได้ ตรวจสอบได้ ปลอดภัย

แค่นั้นเอง

Claude อ่านไฟล์เหล่านี้เมื่อเริ่มต้นทุกการรัน อัปเดตเมื่อสิ้นสุด การรันครั้งต่อไปจะดำเนินการต่อจากจุดที่การรันล่าสุดค้างไว้

นี่คือสิ่งที่ทำให้ลูปแตกต่างจากพรอมต์ที่ทำซ้ำๆ

สถานะอยู่ภายนอกแชท

TASK.md — กำหนดเป้าหมายให้ชัดเจน

ไฟล์นี้บอก Claude ว่าลูปมีไว้เพื่ออะไร

ให้อยู่ในระดับสูง อย่าใส่รายละเอียดการดำเนินการไว้ที่นี่ รายละเอียดเหล่านั้นให้ใส่ใน LOOP_INSTRUCTIONS.md

คัดลอกเทมเพลตนี้:

1# ลูปตรวจสอบโปรเจกต์รายวัน
2
3## เป้าหมาย
4ตรวจสอบโฟลเดอร์โปรเจกต์นี้ สรุปสิ่งที่เปลี่ยนแปลง
5ระบุอุปสรรค และสร้างรายงานตรวจสอบรายวันสั้นๆ
6
7## ผลลัพธ์ที่คาดหวัง
8แต่ละการรันควรสร้างหรืออัปเดต:
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## ขอบเขต
13Claude อาจตรวจสอบไฟล์ในเวิร์กสเปซนี้และเขียน
14รายงานไปยังโฟลเดอร์ `outputs/`
15
16Claude ไม่ควร:
17- แก้ไขไฟล์ต้นฉบับ
18- ลบหรือเปลี่ยนชื่อไฟล์
19- ส่งข้อความหรือเปิดตั๋ว

สังเกตส่วนสุดท้าย

ลูปเวอร์ชันแรกควรมีกฎ "ห้ามทำ" ที่ชัดเจน

นี่ไม่ใช่เพราะไม่ไว้ใจ Claude

นี่คือการที่คุณเป็นวิศวกรที่ดี

PROGRESS.md — หน่วยความจำของลูป

นี่คือไฟล์ที่สำคัญที่สุดในระบบ

หากไม่มีมัน ทุกการรันจะเริ่มจากศูนย์ เมื่อมีมัน Claude จะรู้ว่าเกิดอะไรขึ้นและดำเนินการต่อจากจุดนั้น

โครงสร้างที่ใช้งานได้จริง:

1# ความคืบหน้าของลูป
2
3## สถานะปัจจุบัน
4- สถานะ: กำลังทำงาน
5- วัตถุประสงค์หลัก: ตรวจสอบโปรเจกต์รายวัน
6- จุดสนใจปัจจุบัน: [สิ่งที่สำคัญตอนนี้]
7- อัปเดตล่าสุด: [วันที่]
8
9## การรันล่าสุด
10- วันที่:
11- สรุป:
12- ไฟล์ที่ตรวจสอบ:
13- ผลลัพธ์ที่สร้างขึ้น:
14
15## รายการที่ค้างอยู่
16-
17
18## อุปสรรค
19-
20
21## ต้องการให้มนุษย์ตรวจสอบ
22-
23
24## การรันครั้งต่อไปควร
25-
26
27## การตัดสินใจที่ทำแล้ว
28-
29
30## ห้ามทำซ้ำ
31-

ส่วน "ห้ามทำซ้ำ" มีความสำคัญอย่างยิ่ง

มันป้องกันไม่ให้ Claude ลองทำสิ่งที่ล้มเหลวแล้วซ้ำอีก

ส่วน "ต้องการให้มนุษย์ตรวจสอบ" มีความสำคัญอย่างยิ่ง

มันหยุดลูปไม่ให้ทำงานต่อไปอย่างเงียบๆ เมื่อไม่ควรทำ

กฎสองข้อสำหรับการทำให้ PROGRESS.md มีประโยชน์:

→ ถ้า Claude ต้องการมันเพื่อตัดสินใจดำเนินการต่อไป → เก็บไว้ใน PROGRESS.md → ถ้าคุณแค่ต้องการบันทึก → ย้ายไปที่ outputs/history/

ไฟล์สถานะที่เติบโตขึ้นเรื่อยๆ จะไร้ประโยชน์

ให้ PROGRESS.md เป็นแผงควบคุม ไม่ใช่ที่เก็บเอกสาร

LOOP_INSTRUCTIONS.md — ขั้นตอนการดำเนินการ

ไฟล์นี้คือชั้นควบคุมรอบๆ Claude

มันบอก Claude อย่างชัดเจนว่าต้องอ่านอะไร เขียนอะไร ไม่ควรแตะต้องอะไร และวิธีตรวจสอบผลลัพธ์ก่อนหยุด

เทมเพลตที่ใช้งานได้:

1# คำแนะนำลูป
2
3คุณกำลังรันลูปตรวจสอบโปรเจกต์รายวัน
4
5## ก่อนเริ่มต้น
61. อ่าน `TASK.md`
72. อ่าน `PROGRESS.md`
83. ตรวจสอบโฟลเดอร์โปรเจกต์
94. ระบุสิ่งที่เปลี่ยนแปลง สิ่งที่ยังไม่เสร็จ สิ่งที่ต้องการให้มนุษย์ตรวจสอบ
10
11## สิ่งที่คุณควรทำ
12เขียนรายงานตรวจสอบรายวันสั้นๆ ไปยัง `outputs/daily-review.md` รวมถึง:
13- สรุปสถานะปัจจุบัน
14- ไฟล์ที่ตรวจสอบ
15- การเปลี่ยนแปลงที่มีนัยสำคัญ
16- อุปสรรคหรือคำถามที่ยังไม่ได้แก้ไข
17- การดำเนินการถัดไปที่แนะนำ
18
19หลังจากเขียนแล้ว ให้อัปเดต `PROGRESS.md` ด้วย:
20- วันที่ของการรันนี้
21- สรุปสิ่งที่เกิดขึ้น
22- ไฟล์ที่ตรวจสอบ
23- สิ่งที่การรันครั้งต่อไปควรทำ
24- ว่าต้องการให้มนุษย์ตรวจสอบหรือไม่
25
26## กฎความปลอดภัย
27- ห้ามลบไฟล์
28- ห้ามเปลี่ยนชื่อหรือย้ายไฟล์
29- ห้ามแก้ไขไฟล์ต้นฉบับ
30- เขียนไปยัง `outputs/daily-review.md` และ `PROGRESS.md` เท่านั้น
31- หากไม่แน่ใจว่าการดำเนินการได้รับอนุญาตหรือไม่ → หยุดและถาม
32
33## รายการตรวจสอบการตรวจสอบ
34ก่อนสิ้นสุดการรัน ให้ยืนยัน:
35- `outputs/daily-review.md` มีอยู่พร้อมทุกส่วนที่จำเป็น
36- `PROGRESS.md` ได้รับการอัปเดตแล้ว
37- ไม่มีไฟล์นอกเส้นทางที่อนุญาตถูกแก้ไข
38
39## นโยบายความล้มเหลว
40หากการตรวจสอบล้มเหลว:
411. ส่วนที่ขาดหายไปในรายงาน → แก้ไขครั้งเดียว
422. PROGRESS.md ไม่ได้รับการอัปเดต → อัปเดตครั้งเดียว
433. ไฟล์ต้องห้ามถูกแก้ไข → หยุดทันที
444. การตรวจสอบเดียวกันล้มเหลวสองครั้ง → ทำเครื่องหมายว่าต้องการให้มนุษย์ตรวจสอบ

สังเกตนโยบายความล้มเหลวที่ด้านล่าง

ลูปส่วนใหญ่ไม่มีนโยบายความล้มเหลว

ดังนั้นเมื่อมีอะไรผิดพลาด Claude ก็จะแก้ไขสถานการณ์เฉพาะหน้า

นั่นคือจุดที่ลูปสร้างปัญหา

กำหนดเส้นทางความล้มเหลวอย่างชัดเจนเสมอ

การรันลูปแรกของคุณด้วยตนเอง

อย่ากำหนดเวลารันอัตโนมัติ yet

รันด้วยตนเองก่อน

เปิดโฟลเดอร์ใน Claude Code หรือ Claude Desktop/Cowork ใช้พรอมต์นี้:

1รันลูปตรวจสอบโปรเจกต์รายวันสำหรับเวิร์กสเปซนี้
2
3ทำตาม `LOOP_INSTRUCTIONS.md` อย่างเคร่งครัด
4
5ก่อนลงมือทำ ให้อ่าน:
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10จากนั้นตรวจสอบเวิร์กสเปซ เขียนรายงานตรวจสอบรายวันไปยัง
11`outputs/daily-review.md` อัปเดต `PROGRESS.md`
12รันรายการตรวจสอบการตรวจสอบ และรายงานสิ่งที่เปลี่ยนแปลง
13
14ห้ามแก้ไขไฟล์ใดๆ ยกเว้น
15`outputs/daily-review.md` และ `PROGRESS.md`

หลังจากการรัน ให้ตรวจสอบสองสิ่ง:

→ outputs/daily-review.md — รายงานที่มีโครงสร้างพร้อมทุกส่วน

→ PROGRESS.md — สถานะที่อัปเดตแล้ว คำแนะนำสำหรับการรันครั้งต่อไป ธงที่ต้องการให้มนุษย์ตรวจสอบ

หากทั้งสองอย่างถูกต้อง → ลูปกำลังทำงาน

ตอนนี้ให้รันอีก 3-5 ครั้งโดยมีการเปลี่ยนแปลงเล็กน้อย

เพิ่มไฟล์บันทึก เพิ่มอุปสรรคใน PROGRESS.md เปลี่ยนแปลงบางอย่างในเวิร์กสเปซ

แต่ละการรันควรรับรู้การเปลี่ยนแปลงโดยไม่ต้องเริ่มจากศูนย์

ความต่อเนื่องนั้นคือประเด็นสำคัญทั้งหมด

การตรวจสอบ: ส่วนที่คนส่วนใหญ่ข้าม

นี่คือโหมดความล้มเหลวที่ไม่มีใครพูดถึง

Claude รันลูป บอกว่าเสร็จแล้ว อัปเดตสถานะ หยุด

ทุกอย่างดูเรียบร้อย

แต่รายงานขาดส่วนที่จำเป็น หรือ PROGRESS.md ไม่ได้ถูกอัปเดตจริงๆ หรือ Claude แก้ไขไฟล์ที่มันไม่ควรแก้ไขอย่างเงียบๆ

คุณจะรู้ก็ต่อเมื่อมีอะไรพัง

นั่นคือเหตุผลที่การตรวจสอบมีอยู่

ลูปไม่ควรหยุดเพราะ Claude บอกว่ามันเสร็จแล้ว

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

การตรวจสอบที่ดีมีลักษณะดังนี้:

รันการตรวจสอบสำหรับการทำงานลูปล่าสุด

ตรวจสอบผลลัพธ์เทียบกับรายการตรวจสอบการตรวจสอบ

ใน \LOOP_INSTRUCTIONS.md\

รายงาน:

1. การตรวจสอบใดผ่าน
2. การตรวจสอบใดล้มเหลว
3. ไฟล์ใดถูกแก้ไข
4. การรันนี้ปลอดภัยที่จะยอมรับหรือไม่
5. ต้องการให้มนุษย์ตรวจสอบหรือไม่

ห้ามแก้ไขไฟล์ใดๆ ในระหว่างการตรวจสอบนี้

รันตัวทำงาน จากนั้นรันตัวตรวจสอบ แยกกัน

เมื่อเวลาผ่านไปคุณสามารถรวมมันได้ แต่ในระหว่างการทดสอบช่วงแรก ให้แยกไว้

ตัวตรวจสอบต้องมีมาตรฐานผ่าน/ไม่ผ่าน

"ตรวจสอบสิ่งนี้แล้วบอกฉันว่ามันดูดีหรือไม่" ไม่ใช่ตัวตรวจสอบ

"ตรวจสอบ 7 เงื่อนไขนี้และทำเครื่องหมายว่าการรันได้รับการยอมรับก็ต่อเมื่อทั้ง 7 ผ่าน" คือตัวตรวจสอบ

การกำหนดเวลาด้วย /loop

ลูปทำงานได้อย่างน่าเชื่อถือด้วยตนเองแล้ว

ตอนนี้กำหนดเวลามัน

ใน Claude Code ให้ใช้ /loop:

1/loop 24h รันลูปตรวจสอบโปรเจกต์รายวันสำหรับเวิร์กสเปซนี้
2
3ทำตาม `LOOP_INSTRUCTIONS.md` อย่างเคร่งครัด
4อ่าน `TASK.md` และ `PROGRESS.md` ก่อน
5เขียนรายงานไปยัง `outputs/daily-review.md`
6อัปเดต `PROGRESS.md` ก่อนหยุด
7รันรายการตรวจสอบการตรวจสอบ
8หากไม่มีการเปลี่ยนแปลงที่มีนัยสำคัญ → ให้รายงานสั้น
9หากต้องการให้มนุษย์ตรวจสอบ → ทำเครื่องหมายให้ชัดเจนใน `PROGRESS.md`
10ห้ามแก้ไขไฟล์ใดๆ ยกเว้น `outputs/daily-review.md`
11และ `PROGRESS.md`

ตัวเลือกช่วงเวลา:

→ /loop 15m — จังหวะการทดสอบ (ใช้ขณะเฝ้าดู)

→ /loop 1h — การตรวจสอบรายชั่วโมง

→ /loop 24h — การตรวจสอบรายวัน

→ /loop 7d — การทำความสะอาดหรือสรุปรายสัปดาห์

สำคัญ: /loop ไม่ใช่เวทมนตร์

มันแค่ทำซ้ำพรอมต์

คุณภาพของลูปมาจากโครงสร้างรอบๆ พรอมต์ — ไฟล์ คำแนะนำ การตรวจสอบ สถานะ

/loop ให้แค่ตัวกระตุ้นเท่านั้น

และรู้จัก /goal ด้วย:

/loop = รันอีกครั้งเพราะเวลาผ่านไป

/goal = รันต่อไปจนกว่าเงื่อนไขจะสำเร็จ

1/goal outputs/daily-review.md มีอยู่, PROGRESS.md ได้รับการอัปเดต,
2รายการตรวจสอบการตรวจสอบผ่าน, ไม่มีไฟล์ต้องห้ามถูกแก้ไข

ใช้ /loop สำหรับงานที่ใช้เวลาเป็นฐาน (ตรวจสอบรายวัน, การตรวจสอบ)

ใช้ /goal สำหรับงานที่ใช้ความสำเร็จเป็นฐาน (แก้ไขจนกว่าการทดสอบจะผ่าน, เขียนจนกว่าทุกส่วนจะเสร็จ)

บันไดการอนุญาต

นี่คือจุดที่ลูปส่วนใหญ่ผิดพลาด

คนสร้างลูปที่ใช้งานได้ จากนั้นก็ให้อำนาจมันมากเกินไปทันที

ลูปโพสต์ไปยัง Slack โดยตรง ผลักดันโค้ดโดยไม่ตรวจสอบ ปิดตั๋วโดยอัตโนมัติ

แล้วเมื่อมีอะไรผิดพลาด มันก็กลายเป็นเรื่องยุ่งเหยิง

ใช้บันไดการอนุญาตแทน:

1ระดับ 1 — อ่านอย่างเดียว
2Claude อ่านไฟล์ ตั๋ว บันทึก ปัญหา
3
4ระดับ 2 — ร่างผลลัพธ์
5Claude เขียนไปยัง outputs/ เท่านั้น
6รายงาน แผนงาน คำแนะนำ
7ไม่มีอะไรภายนอก
8
9ระดับ 3 — แก้ไขในแซนด์บ็อกซ์
10Claude แก้ไขไฟล์ภายในแซนด์บ็อกซ์ที่ควบคุม
11สาขาหรือ worktree ที่แยกออกมา
12
13ระดับ 4 — ร่างการดำเนินการภายนอก
14Claude เตรียม PR ข้อความ Slack การอัปเดตตั๋ว
15ไม่ส่งหรือรวม
16
17ระดับ 5 — การดำเนินการที่ได้รับการอนุมัติจากมนุษย์
18Claude ใช้การเปลี่ยนแปลงหลังจากได้รับการอนุมัติอย่างชัดแจ้งเท่านั้น
19
20ระดับ 6 — การดำเนินการอัตโนมัติที่มีความเสี่ยงต่ำ
21Claude ทำงานที่จำกัดขอบเขตอย่างแคบโดยอัตโนมัติ
22พร้อมบันทึก ขีดจำกัด และการย้อนกลับ

ลูปแรกของคุณควรอยู่ที่ระดับ 1 หรือระดับ 2

นั่นไม่ใช่จุดอ่อน นั่นคือวิศวกรรม

ลูประดับ 1 และ 2 ยังคงมีคุณค่ามหาศาล

Claude สามารถตรวจสอบ GitHub Issues ของคุณ อ่าน CI failures ตรวจสอบ PRD และสรุปทุกอย่าง — ทั้งหมดโดยไม่ต้องแตะต้องสิ่งที่สำคัญ

พิสูจน์ว่าลูปทำงานได้ที่ระดับ 2 ก่อน

จากนั้นค่อยตัดสินใจว่ามันสมควรได้รับระดับ 3 หรือไม่

เมื่อลูปผิดพลาด (และวิธีป้องกัน)

ลูปแรกที่ไม่ดี:

ทุกวัน ปรับปรุงกลยุทธ์ผลิตภัณฑ์จนกว่ามันจะรู้สึกแข็งแกร่งขึ้น

→ ไม่มีเงื่อนไขหยุด → ไม่มีการตรวจสอบ → ไม่มีสถานะ → "รู้สึกแข็งแกร่งขึ้น" ไม่ใช่รายการตรวจสอบ

ลูปนี้จะไม่ทำอะไรที่เป็นประโยชน์หรือจะเปลี่ยนแปลงสิ่งที่มันไม่ควร

ลูปแรกที่ดี:

ทุกวันศุกร์ ตรวจสอบเอกสารกลยุทธ์ผลิตภัณฑ์

ระบุส่วนที่เปลี่ยนแปลงในสัปดาห์นี้

แสดงรายการสมมติฐานที่ยังไม่ได้แก้ไข

เขียนบันทึกการตรวจสอบที่มีโครงสร้างไปยัง outputs/strategy-review.md

อย่าแก้ไขเอกสารกลยุทธ์โดยตรง

→ ตารางเวลาที่ชัดเจน → ขอบเขตที่จำกัด → ไฟล์ผลลัพธ์ที่คาดเดาได้ → ขอบเขตการอนุญาตที่ปลอดภัย

ความแตกต่างไม่ใช่ความฉลาด มันคือการออกแบบ

5 สิ่งที่ทำให้ลูปจม:

→ กำหนดเวลาก่อนการทดสอบด้วยตนเอง

→ ไม่มีไฟล์สถานะ — ทุกการรันเริ่มจากศูนย์

→ ไม่มีการตรวจสอบ — ลูปเชื่อใจตัวเอง

→ ไม่มีนโยบายความล้มเหลว — ผลลัพธ์ที่ไม่ดีแก้ไขสถานการณ์เฉพาะหน้า

→ เครื่องมือมากเกินไปเร็วเกินไป — รัศมีการระเบิดขยายตัว

แก้ไขทั้งห้าข้อก่อนคำสั่ง /loop ครั้งแรก

การเพิ่มเครื่องมือและตัวเชื่อมต่อ

เมื่อลูปในเครื่องมีเสถียรภาพแล้ว คุณสามารถขยายมันได้

GitHub Slack Linear Jira CI logs

แต่ทุกเครื่องมือใหม่จะขยายรัศมีการระเบิด

ปฏิบัติตามหลักการเดียวกัน: อ่านก่อน ร่างเป็นอันดับสอง เขียนหลังจากรันซ้ำหลายครั้งที่สำเร็จเท่านั้น

กฎเฉพาะเครื่องมือจะอยู่ใน LOOP_INSTRUCTIONS.md:

1## นโยบายการอนุญาตเครื่องมือ
2
3### GitHub
4อนุญาต:
5- อ่าน issues ที่เปิดอยู่
6- อ่านสถานะ pull request
7- อ่านสถานะ CI
8- ร่างสรุปใน `outputs/github-review.md`
9ไม่อนุญาต:
10- ผลักดัน commits
11- รวม pull requests
12- ปิด issues
13- แสดงความคิดเห็นสาธารณะโดยไม่ได้รับการอนุมัติ
14
15### Slack
16อนุญาต:
17- ร่างข้อความใน `outputs/slack-update.md`
18ไม่อนุญาต:
19- ส่งข้อความ
20- กล่าวถึงผู้ใช้
21- โพสต์ไปยังช่อง
22
23### Linear/Jira
24อนุญาต:
25- อ่านตั๋วที่ได้รับมอบหมาย
26- ร่างการอัปเดตที่แนะนำ
27ไม่อนุญาต:
28- เปลี่ยนสถานะ
29- ปิดตั๋ว
30- สร้างตั๋วโดยไม่ได้รับการอนุมัติ

หากเครื่องมือไม่อยู่ในรายการ → หยุดและขอให้มนุษย์ตรวจสอบ

สิ่งนี้ปกป้องคุณจากลูปที่ทำสิ่งที่คุณไม่ได้คิดถึง

ลูปสมบูรณ์ครั้งแรกของคุณมีลักษณะอย่างไร

นี่คือการตั้งค่าที่สมบูรณ์ตั้งแต่เริ่มต้น

1## นโยบายการอนุญาตเครื่องมือ
2
3### GitHub
4อนุญาต:
5- อ่าน issues ที่เปิดอยู่
6- อ่านสถานะ pull request
7- อ่านสถานะ CI
8- ร่างสรุปใน `outputs/github-review.md`
9ไม่อนุญาต:
10- ผลักดัน commits
11- รวม pull requests
12- ปิด issues
13- แสดงความคิดเห็นสาธารณะโดยไม่ได้รับการอนุมัติ
14
15### Slack
16อนุญาต:
17- ร่างข้อความใน `outputs/slack-update.md`
18ไม่อนุญาต:
19- ส่งข้อความ
20- กล่าวถึงผู้ใช้
21- โพสต์ไปยังช่อง
22
23### Linear/Jira
24อนุญาต:
25- อ่านตั๋วที่ได้รับมอบหมาย
26- ร่างการอัปเดตที่แนะนำ
27ไม่อนุญาต:
28- เปลี่ยนสถานะ
29- ปิดตั๋ว
30- สร้างตั๋วโดยไม่ได้รับการอนุมัติ

จากนั้นกรอกแต่ละไฟล์ (ใช้เทมเพลตจากด้านบน)

จากนั้นรันด้วยตนเอง:

1รันลูปตรวจสอบโปรเจกต์รายวันสำหรับเวิร์กสเปซนี้
2
3ทำตาม `LOOP_INSTRUCTIONS.md` อย่างเคร่งครัด
4ก่อนลงมือทำ ให้อ่าน TASK.md, PROGRESS.md,
5และ LOOP_INSTRUCTIONS.md
6เขียนรายงานตรวจสอบรายวันไปยัง `outputs/daily-review.md`
7อัปเดต `PROGRESS.md` ก่อนหยุด
8รันรายการตรวจสอบการตรวจสอบ
9ห้ามแก้ไขไฟล์ใดๆ ยกเว้น
10`outputs/daily-review.md` และ `PROGRESS.md`

จากนั้นตรวจสอบ:

1รันการตรวจสอบ
2ตรวจสอบเทียบกับรายการตรวจสอบการตรวจสอบใน
3`LOOP_INSTRUCTIONS.md`
4รายงานว่าการตรวจสอบใดผ่าน การตรวจสอบใดล้มเหลว
5ไฟล์ใดถูกแก้ไข ว่าต้องการให้มนุษย์ตรวจสอบหรือไม่
6ห้ามแก้ไขไฟล์ใดๆ

รันด้วยตนเอง 3-5 ครั้งโดยมีการเปลี่ยนแปลงเวิร์กสเปซเล็กน้อย

จากนั้นกำหนดเวลา:

1/loop 24h รันลูปตรวจสอบโปรเจกต์รายวัน...
2[พรอมต์เดียวกับแบบใช้มือ แต่เติม /loop 24h ข้างหน้า]

ตรวจสอบสัปดาห์แรกของผลลัพธ์ที่กำหนดเวลาก่อนที่จะเชื่อใจมัน

นั่นคือระบบที่สมบูรณ์

การเปลี่ยนแปลงที่เปลี่ยนทุกอย่าง

ก่อนลูป:

→ คุณเขียนพรอมต์

→ Claude ตอบ

→ พรุ่งนี้คุณเขียนพรอมต์เดิมอีกครั้ง

→ Claude ไม่มีความทรงจำของเมื่อวาน

→ คุณติดตามสิ่งที่เปลี่ยนแปลงด้วยตนเอง

→ ทุกอย่างรีเซ็ตในแต่ละเซสชัน

หลังลูป:

→ TASK.md กำหนดเป้าหมายครั้งเดียว

→ PROGRESS.md นำพาความทรงจำข้ามการรัน

→ LOOP_INSTRUCTIONS.md ควบคุมพฤติกรรม

→ Claude อ่าน ดำเนินการ ตรวจสอบ อัปเดต หยุด

→ พรุ่งนี้มันดำเนินการต่อจากจุดที่ค้างไว้

→ คุณตรวจสอบผลลัพธ์ ไม่ใช่พรอมต์

คอขวดเปลี่ยนจากการสร้างงานเป็นการตรวจสอบงาน

นั่นคือ leverage ที่แท้จริง

คุณไม่ได้ถาม Claude ด้วยคำถามที่ดีขึ้น

คุณกำลังออกแบบระบบที่ทำงานต่อไปโดยไม่มีคุณ

10 ลูปที่คุณสามารถสร้างได้ในสัปดาห์นี้

→ ตรวจสอบโปรเจกต์รายวัน — อ่านเวิร์กสเปซ เขียนสรุป

→ ตัวแยกการดำเนินการต่อจากการประชุม — เปลี่ยนบันทึกเป็นรายการดำเนินการ

→ ตัววางแผนทำความสะอาดโฟลเดอร์ — จัดระเบียบ เสนอ ไม่แตะต้อง

→ การจัดประเภท CI failure — อ่านบันทึก จัดประเภทความล้มเหลว ร่างการสอบสวน

→ ตัวสรุป GitHub Issue — อ่าน issues ที่เปิดอยู่ จัดกลุ่มตามธีม

→ ผู้ช่วยตรวจสอบ PR — อ่าน diff ชี้ปัญหาที่อาจเกิดขึ้น

→ ลูปค้นคว้าจดหมายข่าว — รวบรวมแหล่งข้อมูล ร่างสรุป

→ ตัวค้นหาช่องว่างเอกสาร — อ่านเอกสาร ชี้ส่วนที่ขาดหาย

→ ตัวร่างรายงานประจำวัน — อ่าน PROGRESS.md เขียนรายงานประจำวัน

→ ลูปทบทวนประจำสัปดาห์ — ทบทวนสัปดาห์ ระบุรูปแบบ

ทุกๆ ลูปเริ่มต้นด้วยระบบ 4 ไฟล์เดียวกัน

สิ่งเดียวที่เปลี่ยนแปลงคือ TASK.md และ LOOP_INSTRUCTIONS.md

หากสิ่งนี้มีประโยชน์:

→ แชร์ซ้ำเพื่อส่งต่อให้นักพัฒนาทุกคนที่ใช้ Claude

→ ติดตาม @sairahul1 สำหรับระบบเพิ่มเติมที่ทำงานโดยไม่มีคุณ

→ คั่นหน้านี้ — เทมเพลตพร้อมให้คัดลอกและวาง

สมัครสมาชิก theaibuilders.co สำหรับบทความที่น่าสนใจเพิ่มเติม

ฉันเขียนเกี่ยวกับ AI การสร้างผลิตภัณฑ์ และระบบอัตโนมัติ