"ผมไม่ได้พิมพ์ prompt ให้ Claude อีกต่อไปแล้ว มันคือ loop ที่กำลังทำงานอยู่ และ loop นั่นแหละที่เป็นคนตัดสินใจว่าจะทำอะไรต่อโดยการ prompt Claude หน้าที่ของผมเปลี่ยนไปเป็นการเขียน loop เหล่านี้"
นี่คือคำพูดที่ Boris Cherny หัวหน้าทีมพัฒนา Claude Code กล่าวต่อสาธารณะ (ปรากฏในบทความของ The New Stack และบทความต่างๆ โดย Addy Osmani)
ในขณะที่พวกเราหลายคนยังคงปรับแต่ง prompt เพื่อเพิ่มความแม่นยำ คนที่สร้างเครื่องมือขึ้นมากลับก้าวออกจากบทบาท "ผู้สั่งงาน" ไปแล้ว
เมื่อลองคิดดู ตราบใดที่ยังมี "เทิร์นของมนุษย์" คือการนั่งอยู่หน้าจอ รอคำตอบจาก AI ตรวจสอบ แล้วก็สั่งงานอีกครั้ง ความเร็วสูงสุดก็ยังคงถูกจำกัดด้วยความเร็วของมือคุณนั่นแหละ
Loop Engineering คือแนวคิดในการกำจัดเทิร์นของมนุษย์ออกจากโครงสร้างนั้น Boris ทุ่มเทให้กับแนวคิดนี้เต็มที่ เขาบอกว่าเขาลบ IDE ทิ้งไปตั้งแต่เดือนพฤศจิกายน 2024 และไม่ได้เปิดมันอีกเลย เขาอ้างว่าผลงานเกือบทั้งหมดที่เขาทำให้ Claude Code ในเดือนที่ผ่านมา ถูกเขียนโดย Claude Code เอง (รายงานว่ามีกว่า 200 PRs)
ผู้สร้างเครื่องมือไม่ได้เขียนโค้ดด้วยตัวเองอีกต่อไป แต่ย้ายไปอยู่ฝั่ง "คอยดูว่า loop ทำงานถูกต้องหรือไม่" วันนี้ผมจะมาอธิบายเรื่องนี้ในระดับสเปกทางเทคนิค ไม่ใช่แค่ให้ความรู้สึกเท่านั้น ผมเองก็กำลังอยู่ในขั้นตอนของการเปลี่ยนผ่านไปสู่ฝั่ง loop และผมเริ่มรู้สึกว่ามือของผมว่างขึ้นเรื่อยๆ ยิ่งเปลี่ยนมากเท่าไหร่
บทความที่เกี่ยวข้อง: Introduction to Vibe Coding: 6 Steps for People Who Can't Code to Build Apps with Claude. The Era of In-House Production on Weekends Has Arrived
https://note.com/nobel/n/n8192ec07d689
Loop Engineering หมายถึงการเปลี่ยนแปลงบทบาท
พูดง่ายๆ คือตำแหน่งหน้าที่ของคุณเปลี่ยนไป ก่อนหน้านี้มนุษย์นั่งอยู่ตรงกลางของกระบวนการโต้ตอบแบบไป-กลับ โดยมนุษย์เป็นคนสั่ง AI ตอบ แล้วมนุษย์ตรวจสอบและแก้ไข ในการออกแบบ loop มนุษย์มีหน้าที่ออกแบบกลไกการหมุนเวียน (loop) ในขณะที่ส่วนของการลองผิดลองถูกและตรวจสอบผลลัพธ์จะถูกย้ายไปอยู่ฝั่ง AI คุณแค่รอการแจ้งเตือนเมื่อมันเสร็จแล้วเท่านั้น
Addy Osmani จาก Google เขียนในทำนองเดียวกันในบทความชื่อ Loop Engineering โดยอธิบายว่าเป็นการ "แทนที่คนที่พิมพ์ prompt ด้วยกลไกที่พิมพ์ prompt แทนพวกเขา" จุดเปลี่ยนของแรงงัด (leverage) ได้ย้ายจากความสามารถในการเขียน prompt ที่ดี ไปสู่การออกแบบระบบที่ให้ AI เขียน prompt ให้คุณแทน นี่คือแก่นกลาง
อย่างไรก็ตาม Addy เองก็เตือนว่า "มันยังอยู่ในช่วงเริ่มต้น และผมก็ค่อนข้างกังขาอยู่ คุณต้องระวังเรื่องค่าใช้จ่าย token จริงๆ" เราจะกลับมาพูดถึงหลุมพรางนี้ในช่วงท้าย
สเปกทางเทคนิคของ /loop
Claude Code มีความสามารถในตัวที่เรียกว่า /loop (ตั้งแต่เวอร์ชัน v2.1.72 เป็นต้นไป) นี่คือจุดเริ่มต้นที่ง่ายที่สุดสำหรับ loop engineering เนื่องจากคำอธิบายในโลกออนไลน์มักมีข้อผิดพลาดปนอยู่ ผมจะเน้นเฉพาะประเด็นสำคัญโดยอ้างอิงจากเอกสาร scheduled execution อย่างเป็นทางการ
พฤติกรรมจะเปลี่ยนไปตามสิ่งที่คุณส่งให้มัน:
- ทั้ง interval และ prompt:
/loop 5m check if the deployment is finished and let me knowจะทำงานตามช่วงเวลาที่กำหนด - เฉพาะ prompt:
/loop check if the CI passed and respond to review commentsClaude จะตัดสินใจช่วงเวลาเองระหว่าง 1 นาที ถึง 1 ชั่วโมง (กำหนดจังหวะเอง) - ไม่ส่งอะไรเลย
/loop: จะใช้ maintenance prompt ในตัว (ทำงานที่ค้างอยู่ต่อ, ดูแล PR, ทำความสะอาดเล็กๆ น้อยๆ) หรือไฟล์loop.mdที่คุณวางไว้
interval สามารถวางไว้ข้างต้นเช่น 30m หรือไว้ท้ายเช่น every 2 hours หน่วยคือ s / m / h / d คุณยังสามารถส่งคำสั่งอื่นๆ ได้ เช่น /loop 20m /review-pr 1234 เพื่อรันสกิลที่บันทึกไว้ทุกครั้ง หากต้องการหยุด ให้กด Esc ขณะรอ (งานที่สร้างผ่านคำขอภาษาธรรมชาติจะไม่หยุดด้วย Esc คุณต้องขอให้ลบมัน) ในโหมดกำหนดจังหวะเอง ถ้า Claude ตรวจสอบว่างานเสร็จแล้วจริงๆ มันจะจบลงโดยไม่กำหนดรอบต่อไป
โหมดกำหนดจังหวะเองมีข้อดีเล็กๆ น้อยๆ คือมันปรับตัวได้เอง โดยจะรอสั้นๆ ถ้าบิลด์ใกล้เสร็จ และรอนานขึ้นถ้าไม่มีอะไรเกิดขึ้น บางครั้งมีการใช้กลไกที่เรียกว่า "Monitor" เพื่อสตรีม output ในพื้นหลังแทนการ polling ซึ่งมักจะถูกกว่าการส่ง prompt ตามช่วงเวลาที่ตายตัว
ขอแก้ไขความเข้าใจผิดทั่วไปที่พบในบทความต้นทาง มีการเขียนว่างานจะ "ถูกลบโดยอัตโนมัติ 3 วันหลังจากสร้าง" แต่ที่ถูกต้องคือ งานที่เกิดขึ้นซ้ำ (recurring tasks) จะหมดอายุ 7 วันหลังจากสร้าง (มันจะทำงานครั้งสุดท้ายแล้วหายไป) นอกจากนี้ /loop อยู่ในขอบเขตของ session และจะหายไปเมื่อคุณเริ่มบทสนทนาใหม่ หากคุณปิดมันไป คุณสามารถกลับมาพร้อม --resume ได้ถ้ายังไม่หมดอายุ
มีวิธีการกำหนดตารางเวลาสามแบบ ให้เลือกตามกรณีการใช้งาน:
- Cloud (Routines): ทำงานบนฝั่ง Anthropic มันจะทำงานแม้เครื่องของคุณจะปิดอยู่ ช่วงเวลาขั้นต่ำคือ 1 ชั่วโมง
- Desktop Scheduled Tasks: ทำงานบนเครื่องของคุณและสามารถเข้าถึงไฟล์ในเครื่องได้
- /loop: ทำงานเฉพาะเมื่อ session เปิดอยู่เท่านั้น ขั้นต่ำ 1 นาที สะดวกสำหรับการ polling ระหว่าง session
การแบ่งหน้าที่คือ: ใช้ Routines หรือ GitHub Actions สำหรับการทำงานถาวรโดยไม่ต้องมีมนุษย์คอยควบคุม และใช้ /loop สำหรับการตรวจสอบระหว่าง session
งานมาตรฐานที่ Loops มีประสิทธิภาพ
งานในกิจวัตรของคุณที่ต้องทำซ้ำ "ตรวจสอบและแก้ไขเล็กน้อย" โดยทั่วไปแล้วเหมาะกับ loops มีรูปแบบทั่วไปสามแบบ:
- Bug Patrol: ตรวจจับปัญหาหรือ test ที่ล้มเหลว อ่านสาเหตุ แก้ไข รัน test และสร้าง PR ในช่วงเวลาที่กำหนด
- Continuous Review: ตรวจสอบการเปลี่ยนแปลงโค้ดและชี้ประเด็นที่น่ากังวลอย่างต่อเนื่อง มนุษย์แค่ตัดสินใจว่าจะยอมรับข้อเสนอแนะหรือไม่
- Document Sync: ตรวจจับการเปลี่ยนแปลงของ source และทำให้ README หรือสเปกเป็นปัจจุบันอยู่เสมอ
สิ่งที่เหมือนกันในสามอย่างนี้คือเป้าหมายสามารถตัดสินได้อย่างชัดเจน เช่น "test ผ่าน" หรือ "สร้าง PR แล้ว" ในทางกลับกัน งานที่มีเกณฑ์คลุมเครือไม่เหมาะกับ loops ถ้าจุดหยุดไม่ชัดเจน มันก็จะทำงานไปเรื่อยๆ และกิน token เลือกงานแรกที่ความสำเร็จหรือความล้มเหลวดูออกได้ง่ายๆ จะปลอดภัยกว่า
การป้องกันการทำงานไม่มีที่สิ้นสุดและการหลงลืมด้วย "State Files"
ความกลัวสองอย่างของ loops คือ: การทำ failure ซ้ำแล้วซ้ำเล่า และการกิน token อย่างไม่มีที่สิ้นสุด
นี่คือจุดที่การออกแบบโดยใช้ไฟล์ state เดียวในโปรเจกต์มีประสิทธิภาพ ไม่ว่าจะเป็น STATE.md หรือ todo.md AI จะอ่านและเขียนเป้าหมายปัจจุบัน / รายการที่เสร็จแล้ว / ขั้นตอนถัดไป / จุดที่ติดขัด ในการ loop แต่ละครั้ง แม้ว่า session จะถูกตัด AI ก็จะไม่หลงทางว่า "กำลังอยู่ตรงไหนและกำลังมุ่งไปไหน"
นี่ไม่ใช่แค่แนวทางปฏิบัติแบบสุ่มๆ Anthropic เองก็ได้ข้อสรุปเกือบจะเหมือนกันใน Effective harnesses for long-running agents (พฤศจิกายน 2024) การตั้งค่าของพวกเขาใช้สองบทบาท: initializer agent เพื่อตั้งค่าสภาพแวดล้อม และ coding agent เพื่อดำเนินการหนึ่งฟีเจอร์ต่อ session การส่งต่องานระหว่าง session ใช้ git commits และไฟล์ claude-progress.txt สำหรับงานที่ยาวนาน การบีบอัดผ่านสรุปความนั้นไม่เพียงพอ นโยบายคือเขียนออกมาเป็นไฟล์ที่มีโครงสร้างครั้งหนึ่ง แล้วสร้าง context ขึ้นมาใหม่
ในการดำเนินงานของผมเอง ผมใช้ tasks/state.md เป็นศูนย์กลางของ state ที่แชร์กัน ซึ่งทั้งฝ่ายระดมความคิดและฝ่าย implement จะอ่านก่อนลงมือปฏิบัติ มันเหมือนกับในรายงาน: "อย่าไว้ใจ context จงไว้ใจไฟล์" มันเรียบง่าย แต่ถ้าไม่มีสิ่งนี้ loop จะหลงทางในรอบที่สอง
วิธี Ralph และการแยก Maker ออกจาก Checker
มีวิธีการ loop แบบสุดโต่งที่เรียกว่าวิธี "Ralph" Geoffrey Huntley ทำให้มันเป็นที่นิยม ต้นทาง เป็นเพียง bash loop ง่ายๆ:
โดยการป้อน prompt เดิมซ้ำๆ และใช้ไฟล์ Markdown ที่มีแผนเป็น state ที่แชร์กันบนดิสก์ AI จะอ่านมันทุกครั้งและตัดสินใจเองว่า "จะทำอะไรต่อไป" มันดูเหมือนเสี่ยง แต่เนื่องจากมี state ไฟล์ มันจึงเดินหน้าต่อไปในทุกๆ รอบ Claude Code เองก็มี plugin ทางการ ralph-loop ที่ส่ง prompt เดิมซ้ำๆ จนกว่าจะตรงตามเงื่อนไขการเสร็จสิ้น (completion promise) มีข้อจำกัดว่าการประกาศว่าเสร็จสิ้นจะต้องถูกส่งออกมาก็ต่อเมื่อมันสำเร็จอย่างแท้จริงเท่านั้น
อย่างไรก็ตาม ถ้าปล่อยให้ AI ตัวเดียวจัดการทุกอย่าง มันจะบอกว่า "โอเค" กับโค้ดที่มันเขียนเอง นี่คือจุดที่การแยก AI ที่สร้าง (Maker) และ AI ที่ตรวจสอบ (Checker) มีประสิทธิภาพ ในการดำเนินงานของผมเอง ผมแยก implementation และ verification ไปไว้ใน agent ต่างกัน และผมไม่ให้เจตนาของการ implement แก่ฝ่ายตรวจสอบ ผมแค่แสดง requirement และให้มันประเมินอย่างอิสระ ผมเรียนรู้จากประสบการณ์ที่เจ็บปวดว่าการ review ตัวเองใน session เดียวกันนั้นย่อมผ่อนปรนอย่างหลีกเลี่ยงไม่ได้
การรวม "review-only agent ที่มีมุมมองที่แตกต่าง" เข้าไปใน loop การออกแบบการตรวจสอบแบบหลายชั้นนี้ เป็นหนึ่งในงานที่มนุษย์ควรคงไว้
การออกแบบอิสระในสามขั้นตอน
การมอบหมายทุกอย่างในครั้งเดียวมักจะนำไปสู่อุบัติเหตุ การแยกระดับของการมีส่วนร่วมเป็นชั้นๆ จะปลอดภัยกว่า:
- L1 (Manual): มนุษย์พิมพ์ prompt และตรวจสอบทุกครั้ง วิธีการแบบดั้งเดิม
- L2 (Semi-autonomous Loop): ตามไฟล์ state และดูงานชุดหนึ่งๆ จนเสร็จด้วย
/loop - L3 (Resident): รันต่อเนื่องผ่าน Routines หรือ GitHub Actions โดยไม่ต้องมีมนุษย์ควบคุม
เป็นการสมจริงที่จะเริ่มที่ L2 รันงานหนึ่งให้เสร็จด้วย /loop และสังเกตพฤติกรรม จากนั้นค่อยเลื่อนไป L3 เมื่อคุณเห็นขอบเขตของความน่าเชื่อถือได้ สองสามครั้งแรก ให้ดู log ที่จอด้านข้างเพื่อดูว่า "มันตัดสินใจผิดตรงไหน"
หลุมพราง (รู้ไว้ก่อน)
เนื่องจากผมเขียนถึงแต่ข้อดี ต่อไปนี้คือสามประเด็นที่คุณอาจติดขัด:
- ค่าใช้จ่าย Token: Loops กิน token มากขึ้นเมื่อมันทำงานนานขึ้น นี่คือสิ่งที่ Addy เน้นย้ำ ถ้าคุณตั้ง interval สั้นเกินไป มันอาจเสียค่าใช้จ่ายพอสมควรในชั่วข้ามคืน การกำหนดจังหวะเองดีกว่าช่วงเวลาที่ตายตัว เพราะมันจะรอเมื่อควรจะรอ ซึ่งช่วยลดการสิ้นเปลือง
- การดำเนินการที่ย้อนกลับไม่ได้: Maintenance prompt ในตัวจะดำเนินการที่ย้อนกลับไม่ได้ เช่น การ push หรือการลบ เฉพาะใน "ขอบเขตที่ได้รับอนุญาตไว้แล้วในบทสนทนา" เมื่อเขียน prompt ของคุณเอง การกำหนดขอบเขตสำหรับการดำเนินการที่ทำลายล้างด้วยตัวเองจะปลอดภัยกว่า
- หายไปใน 7 วัน: งาน
/loopที่เกิดขึ้นซ้ำจะหมดอายุ 7 วันหลังจากสร้าง หากต้องการให้มันทำงานนานขึ้น ให้ย้ายไปใช้ Routines หรือ Desktop tasks
หมายเหตุสำหรับผู้ใช้ระดับกลาง
/loopและ/goalต่างกัน/loopทำงานตามช่วงเวลา หากคุณต้องการดำเนินการต่อทุกเทิร์นจนกว่าจะตรงตามเงื่อนไข ให้ใช้/goalหากคุณต้องการให้มันตอบสนองทันทีที่เหตุการณ์เกิดขึ้น ให้ใช้ push ผ่าน Channels- การวาง
loop.md(.claude/loop.mdหรือ~/.claude/loop.md) จะช่วยให้คุณแทนที่ prompt เริ่มต้นของ/loopเปล่าๆ ด้วย prompt ของคุณเอง มีประโยชน์สำหรับการเขียนงานประจำเช่น "แก้ไขถ้า CI ของ release branch เป็นสีแดง" - สามารถมี scheduled tasks ได้สูงสุด 50 รายการต่อ session คุณสามารถดูรายการได้ด้วย
CronListและลบตาม ID ด้วยCronDelete
สรุป
ก่อนหน้านี้ เวลาที่ผมใช้อยู่หน้าจอคือขีดจำกัดสูงสุดของความก้าวหน้า ตอนนี้ loop ที่อ่าน state file ในขณะที่ผมหลับ ดำเนินการหนึ่งฟีเจอร์ต่อครั้ง และเช้าของผมเริ่มต้นด้วยการตรวจสอบความคืบหน้านั้น
ก่อนที่จะปรับปรุงเนื้อหา (ความแม่นยำของ prompt) ให้ออกแบบวิธีการทำงาน (การแยก loop, การจัดการ state, และการตรวจสอบ) เสียก่อน จุดเปลี่ยนของแรงงัดได้ย้ายไปที่นี่แล้ว—นี่คือจุดร่วมในเรื่องราวของ Boris, Addy, และ harness ของ Anthropic ผมเชื่อว่ามันไม่ใช่ทฤษฎีที่ยาก แต่เป็นการสั่งสมการออกแบบที่เรียบง่ายอย่างต่อเนื่อง เช่น การตัดสินใจว่าจะหยุดเมื่อไหร่ ก่อนที่จะเริ่ม loop
ข้อมูลที่เป็นประโยชน์ซึ่งไม่สามารถแชร์บน X ได้กำลังถูกแชร์ใน LINE OpenChat หากคุณสนใจในการใช้ Claude Code/Codex หรือการใช้ AI สำหรับการดำเนินงานบน X โปรดเข้าร่วมกับเรา
