ในเดือนมิถุนายน 2026 มีสามคนที่คิดแนวคิดเดียวกันได้อย่างอิสระภายในสัปดาห์เดียวกัน
Peter Steinberger ผู้สร้าง OpenClaw กล่าวต่อสาธารณะว่าคุณควรหยุดการเขียน prompt ให้กับ coding agents และเริ่มออกแบบ loops ที่ทำหน้าที่ prompt แทน ในเวลาใกล้เคียงกัน Boris Cherny หัวหน้าทีม Claude Code ที่ Anthropic บอกว่าเขาไม่ได้ prompt Claude โดยตรงอีกต่อไปแล้ว เขามี loops ที่ทำงานเพื่อ prompt Claude และตัดสินใจว่าจะทำอย่างไร งานจริงของเขาคือการเขียน loops ไม่กี่วันต่อมา Addy Osmani วิศวกรที่ Google ได้เขียนแนวคิดนี้และตั้งชื่อให้มันว่า loop engineering
ไม่มีใครในพวกเขาที่คิดค้นแนวปฏิบัตินี้ขึ้นมาจากความว่างเปล่า พวกเขาแค่ตั้งชื่อสิ่งที่เกิดขึ้นอยู่แล้ว เพราะเครื่องมือที่อยู่เบื้องหลังได้ข้ามผ่านเกณฑ์บางอย่างไปอย่างเงียบๆ Coding agents มีความน่าเชื่อถือพอที่จะทำงานจริงให้เสร็จโดยไม่ต้องมีคนดูแล การตั้งเวลาให้ทำงานมีราคาถูกพอจนการทำงานซ้ำๆ ตามเวลาที่กำหนดไม่ดูสิ้นเปลืองอีกต่อไป ค่าใช้จ่ายในการรัน agent หนึ่งครั้งลดลงมากพอจนการลองทำอะไรสักอย่างห้าครั้งมีค่าใช้จ่ายน้อยกว่าการคิดให้รอบคอบเพียงครั้งเดียว
เกณฑ์นั้นคือเหตุผลที่แผนงานนี้มีอยู่ Prompting เป็นทักษะเมื่อมนุษย์ต้องนั่งอยู่หน้าคีย์บอร์ดเพื่อสั่งการ agent ทีละบรรทัด Loop engineering เป็นทักษะในตอนนี้ที่ agent สามารถรับเป้าหมายและปล่อยให้มันทำงานเองได้ นี่คือเส้นทาง 20 ขั้นตอนที่สมบูรณ์จากสิ่งหนึ่งไปสู่อีกสิ่งหนึ่ง ตามลำดับ เพราะลำดับนั้นสำคัญกว่าขั้นตอนใดๆ
นี่คือเหตุผลว่าทำไมลำดับจึงสำคัญเป็นพิเศษ ก่อนที่จะถึงขั้นตอนต่างๆ Loop engineering ไม่ใช่ทักษะเดียวที่คุณมีหรือไม่มี มันเป็นโครงสร้างที่แต่ละชั้นต้องพึ่งพาชั้นด้านล่างที่แข็งแรงจริงๆ การสร้าง scheduling trigger (ขั้นตอนที่ 14) ก่อนที่คุณจะมี stop condition ที่แท้จริง (ขั้นตอนที่ 10) ก็แค่หมายความว่าคุณได้ทำให้ระบบที่สามารถเสียเงินโดยไม่มีคนดูแลทำงานอัตโนมัติ แทนที่จะเสียเงินเฉพาะตอนที่คุณกำลังดูอยู่เท่านั้น การสร้าง persistence (ขั้นตอนที่ 11) ก่อนที่คุณจะมีการตรวจสอบที่แท้จริง (ขั้นตอนที่ 6 และ 7) หมายความว่าคุณกำลังบันทึกบทเรียนที่ได้จาก Judge ที่อาจจะกำลังรับรองผลลัพธ์ที่แย่อย่างไม่ใส่ใจ ซึ่งทำให้ persistence layer นั้นเป็นอันตรายแทนที่จะไร้ประโยชน์ การข้ามไปข้างหน้าในรายการนี้ไม่ได้หมายความแค่พลาดฟีเจอร์หนึ่ง มันหมายถึงการสร้างส่วนที่ดูน่าตื่นเต้นบนรากฐานที่ไม่สามารถรองรับมันได้จริงๆ และจะค้นพบก็ต่อเมื่อมีบางอย่างผิดพลาดในระดับใหญ่แล้วเท่านั้น
ระยะที่หนึ่ง: การเปลี่ยนความคิด (ขั้นตอนที่ 1 ถึง 4)
ขั้นตอนที่ 1: ยอมรับว่าคุณคือคอขวด ไม่ใช่โมเดล
ขั้นตอนแรกจริงๆ ไม่ใช่เรื่องเทคนิค มันคือการยอมรับว่าปัจจัยจำกัดใน workflow ปัจจุบันของคุณไม่ใช่ความสามารถของโมเดล แต่คือการมีอยู่ของคุณใน loop ทุกครั้งที่คุณนั่งรอการตอบกลับ อ่านมัน แล้วพิมพ์คำสั่งถัดไป คุณคือส่วนที่ช้าที่สุดของระบบอย่างมาก โมเดลสามารถทำงาน ตรวจสอบ และลองใหม่ได้เร็วกว่าที่คุณจะดูแลมันได้มาก
ขั้นตอนนี้ไม่มี prompt ติดมาด้วย มันคือการตัดสินใจ จนกว่าคุณจะเชื่อสิ่งนี้จริงๆ ทุกขั้นตอนต่อจากนี้จะรู้สึกเหมือนเป็นภาระที่ไม่จำเป็น แทนที่จะเป็นสิ่งที่มันเป็น นั่นคือการขจัดคอขวดที่แท้จริง
ขั้นตอนที่ 2: หยุดสับสนระหว่าง prompt ที่ยาวขึ้นกับระบบที่ดีกว่า
สัญชาตญาณเมื่อมีอะไรผิดพลาดคือการเพิ่มคำสั่งอีกหนึ่งรายการลงใน prompt เดิม เมื่อเวลาผ่านไปหลายเดือน สิ่งนี้จะสร้าง prompt ที่เป็นกำแพงกฎที่หนาแน่นและขัดแย้งกันเอง ซึ่งโมเดลไม่สามารถเก็บไว้ในหน่วยความจำทำงานได้ทั้งหมดในคราวเดียว ดังนั้นมันจึงจับคู่รูปแบบกับสิ่งที่รู้สึกว่าล่าสุดที่สุดและทิ้งส่วนที่เหลืออย่างเงียบๆ
Loop engineering เข้ามาแทนที่สัญชาตญาณนี้ทั้งหมด แทนที่จะเพิ่มกฎอีกข้อลงใน prompt คุณเพิ่มส่วนประกอบอีกชิ้นลงในระบบ ขั้นตอนการตรวจสอบ ไฟล์หน่วยความจำ ตัวกระตุ้นตามกำหนดเวลา ตัว prompt เองควรจะสั้นลงเมื่อเวลาผ่านไป เมื่อระบบรอบๆ มันมีความสามารถมากขึ้น ไม่ใช่ในทางกลับกัน
ขั้นตอนที่ 3: เรียนรู้ที่จะมองทุกงานเป็นการเคลื่อนไหวห้าอย่าง
การหมุนของ loop หนึ่งครั้ง ไม่ว่าสาขาเฉพาะใดๆ ก็ตาม จะแบ่งออกเป็นการเคลื่อนไหวห้าอย่าง ได้แก่ การค้นหา (Discovery) การหาว่าสิ่งใดที่ต้องทำจริงๆ การส่งต่อ (Handoff) การส่งมอบงานให้กับสิ่งที่จะดำเนินการ การตรวจสอบ (Verification) การตรวจสอบผลลัพธ์กับสิ่งที่เป็นจริง การบันทึก (Persistence) การบันทึกสิ่งที่เกิดขึ้นเพื่อไม่ให้สูญหาย การจัดตารางเวลา (Scheduling) การตัดสินใจว่าเมื่อใดที่สิ่งนี้จะทำงานอีกครั้ง
workflow ปัจจุบันของคนส่วนใหญ่มีเพียงสองการเคลื่อนไหวนี้ที่ชัดเจน คือการค้นหาและการส่งต่อ ซึ่งทำด้วยตนเองในหน้าต่างแชท อีกสามอย่างไม่มีอยู่หรือเกิดขึ้นอย่างมองไม่เห็นในหัวของคนๆ นั้น Loop engineering คือการปฏิบัติที่ทำให้การเคลื่อนไหวทั้งห้าชัดเจนและเป็นอัตโนมัติ
ขั้นตอนที่ 4: ระบุงาน candidate ที่แท้จริงงานแรกของคุณ
ก่อนที่จะสร้างอะไรก็ตาม ให้เลือกงานหนึ่งที่คุณทำซ้ำๆ เป็นประจำ โดยมีมาตรฐานที่คุณสามารถเขียนลงไปได้ถ้าถูกถาม ไม่ใช่ปัญหาที่ยากที่สุดของคุณ ไม่ใช่สิ่งที่ใหม่เอี่ยม งานที่มีคำจำกัดความของความสำเร็จที่แท้จริงและเป็นที่รู้จัก เป็นสิ่งที่เพื่อนร่วมงานสามารถดูและเห็นพ้องต้องกันได้ทันทีว่างานนั้นเสร็จสมบูรณ์ถูกต้องหรือไม่ ข้อจำกัดนี้สำคัญกว่าที่เห็น งานที่ไม่มีคำจำกัดความของความสำเร็จที่ชัดเจนจะไม่สามารถสร้างขั้นตอนที่สาม คือการตรวจสอบ ได้ และ loop ที่ไม่มีการตรวจสอบที่แท้จริงไม่ใช่ loop มันเป็นเพียงการเดาโดยไม่มีคนดูแล
ระยะที่สอง: การสร้าง Loop แรก (ขั้นตอนที่ 5 ถึง 9)
ขั้นตอนที่ 5: เขียนคำจำกัดความของความสำเร็จก่อนที่จะเขียน prompt ใดๆ
นี่คือขั้นตอนที่คนส่วนใหญ่ข้าม และเป็นขั้นตอนที่กำหนดว่าทุกอย่างหลังจากนั้นจะทำงานหรือไม่ ก่อนที่คุณจะเขียนคำสั่งแม้แต่คำเดียวสำหรับ agent ให้เขียนลงไปในภาษาธรรมดาๆ ว่าผลลัพธ์ที่ถูกต้องมีลักษณะอย่างไร เกณฑ์ที่เฉพาะเจาะจงและตรวจสอบได้ ไม่ใช่ความรู้สึกคลุมเครือเกี่ยวกับคุณภาพ
คำจำกัดความของความสำเร็จ (DEFINITION OF DONE) สำหรับ [ชื่องาน]:
- [เกณฑ์เฉพาะที่ตรวจสอบได้ 1]
- [เกณฑ์เฉพาะที่ตรวจสอบได้ 2]
- [เกณฑ์เฉพาะที่ตรวจสอบได้ 3] งานนี้ ไม่ เสร็จสมบูรณ์หากขาดข้อใดข้อหนึ่งข้างต้น แม้ว่าผลลัพธ์จะดูสมบูรณ์หรือเรียบร้อยก็ตาม
หากคุณไม่สามารถกรอกข้อมูลนี้สำหรับงานที่คุณเลือกได้ ให้กลับไปที่ขั้นตอนที่ 4 และเลือกงานอื่น
ขั้นตอนที่ 6: แยก Builder ออกจาก Judge
การตัดสินใจทางสถาปัตยกรรมที่สำคัญที่สุดใน loop ใดๆ บทบาทที่สร้างงานและบทบาทที่ตรวจสอบงานจะต้องแยกจากกัน เพราะโมเดลที่ตรวจสอบผลลัพธ์ของตัวเองในลมหายใจเดียวกับที่สร้างมัน มักจะปกป้องผลลัพธ์นั้นแทนที่จะตรวจสอบอย่างจริงจัง
Builder ได้รับอิสระในการสร้างสรรค์และสร้างความพยายามครั้งแรก Judge ได้รับผลลัพธ์ของ Builder บวกกับคำจำกัดความของความสำเร็จจากขั้นตอนที่ 5 และไม่มีอะไรอื่นที่มันจำเป็นต้องถูกโน้มน้าว ตามหลักการแล้ว Judge ควรมีสิ่งที่ Builder ไม่มีด้วย เช่น ชุดทดสอบ เอกสารต้นฉบับ ข้อมูลสด ดังนั้นคำตัดสินของมันจึงมาจากหลักฐานจริง ไม่ใช่แค่ความเห็นที่สองที่เกิดขึ้นในลักษณะเดียวกับที่ความเห็นแรกเกิดขึ้น
ขั้นตอนที่ 7: ให้ Ground Truth แก่ Judge ไม่ใช่แค่ความคิดเห็น
Judge ที่เห็นเฉพาะผลลัพธ์ของ Builder สามารถบอกคุณได้ว่ามันดูสอดคล้องกันหรือไม่ มันไม่สามารถบอกคุณได้ว่ามันถูกต้องจริงๆ หรือไม่ สำหรับงานเขียนโค้ด ground truth คือชุดทดสอบและผลลัพธ์การทำงานจริง สำหรับงานเนื้อหา คือเอกสารต้นฉบับและ brief ควบคู่ไปกับร่าง สำหรับงานวิจัย คือเอกสารจริงที่ควรจะถูกนำมาใช้
หากคุณไม่สามารถระบุ ground truth ที่เฉพาะเจาะจงที่ Judge ของคุณจะตรวจสอบได้ แสดงว่า loop ของคุณยังไม่มีการตรวจสอบที่แท้จริง ไม่ว่าภาษาของ Judge จะฟังดูมั่นใจแค่ไหนก็ตาม
ขั้นตอนที่ 8: เขียนรูปแบบการส่งต่อก่อนที่จะเขียน prompt สำหรับการส่งต่อ
ผลลัพธ์ของ Builder และคำตัดสินของ Judge ต้องมีโครงสร้างที่กำหนดไว้ ไม่ใช่ร้อยแก้วที่ไหลลื่น มิฉะนั้น Manager ในขั้นตอนถัดไปจะไม่มีอะไรที่เชื่อถือได้ในการกำหนดเส้นทาง
ผลลัพธ์ของ Builder: สิ่งที่ส่งมอบ + ความมั่นใจ + ความไม่แน่นอนที่ทราบ
คำตัดสินของ Judge: PASS / FAIL / NEEDS REVISION + ปัญหาเฉพาะที่พบ + สิ่งที่ใช้เป็น ground truth ในการตรวจสอบ
ขั้นตอนที่ 9: รันด้วยตนเองหนึ่งครั้ง ให้ครบทุกขั้นตอน ก่อนที่จะทำอะไรให้เป็นอัตโนมัติ
ก่อนที่คุณจะเชื่อมต่อ scheduling หรือการลองใหม่โดยอัตโนมัติ ให้รันลำดับ Builder แล้ว Judge ให้ครบด้วยตนเองหนึ่งครั้ง อ่านคำตัดสินของ Judge อย่างมีวิจารณญาณ คุณจะเห็นด้วยกับมันหรือไม่? ถ้า Judge ผ่านสิ่งที่คุณรู้ว่าผิด หรือล้มเหลวในสิ่งที่จริงๆ แล้วถูกต้อง ให้แก้ไข ground truth หรือเกณฑ์ก่อนที่จะก้าวต่อไป การทำให้ขั้นตอนการตรวจสอบที่พังเป็นอัตโนมัติ แค่ทำให้ผลลัพธ์ที่พังเร็วขึ้นเท่านั้น
ตัวอย่างการทำงานผ่านขั้นตอนที่ 5 ถึง 9
เพื่อให้ห้าขั้นตอนล่าสุดเป็นรูปธรรม นี่คือวิธีการทำงานกับงานจริงทั่วไป นั่นคือการเปลี่ยนเอกสารต้นฉบับดิบให้เป็นเนื้อหาที่เสร็จสมบูรณ์
คำจำกัดความของความสำเร็จจากขั้นตอนที่ 5: การอ้างข้อเท็จจริงทุกอย่างในร่างต้องย้อนกลับไปยังสิ่งที่อยู่ในเอกสารต้นฉบับจริงๆ ร่างต้องเป็นไปตามข้อกำหนดเฉพาะทุกข้อใน brief ทั้งความยาว น้ำเสียง โครงสร้างที่ต้องการ ข้อโต้แย้งหลักต้องอยู่รอดอย่างชัดเจน โดยไม่ถูกทำให้เจือจางด้วยเนื้อหาที่ไม่จำเป็น
Builder จากขั้นตอนที่ 6 ได้รับแหล่งที่มาและ brief และสร้างร่าง พร้อมกับข้อความชัดเจนเกี่ยวกับสิ่งที่มันไม่แน่ใจในขณะที่เขียน เช่น ตัวเลขที่มันไม่แน่ใจว่าอยู่ในแหล่งที่มาจริงๆ หรือไม่ ข้อกล่าวอ้างที่มันอนุมานมากกว่าที่พบว่ามีการระบุไว้โดยตรง
Judge จากขั้นตอนที่ 7 ได้รับร่างและแหล่งที่มาดั้งเดิมเคียงข้างกัน ไม่ใช่แค่ร่างเพียงอย่างเดียว และตรวจสอบเกณฑ์คำจำกัดความของความสำเร็จแต่ละข้อแยกกัน โดยส่งคืนผ่านหรือไม่ผ่านในแต่ละรายการเป็นรายบุคคล แทนที่จะเป็นคะแนนรวมที่ผสมกัน การรวมการตรวจสอบที่แตกต่างกันสามรายการเป็นคำตัดสินเดียวจะซ่อนว่ามิติใดที่ล้มเหลวจริงๆ ซึ่งเป็นวิธีที่พบบ่อยที่สุดที่ loop ที่ทำงานอยู่จะหยุดให้ข้อเสนอแนะที่เป็นประโยชน์อย่างเงียบๆ
รูปแบบการส่งต่อจากขั้นตอนที่ 8 หมายความว่าคำตัดสินของ Judge มาถึงเป็นวัตถุที่มีโครงสร้าง ไม่ใช่ย่อหน้าของร้อยแก้วที่คลุมเครือ มีผลลัพธ์ผ่านหรือไม่ผ่านสามรายการที่ชัดเจน พร้อมเหตุผลเฉพาะที่แนบมากับความล้มเหลวใดๆ
การรันด้วยตนเองหนึ่งครั้งตามขั้นตอนที่ 9 ก่อนที่จะทำให้อะไรเป็นอัตโนมัติ เป็นสิ่งที่จับกรณีที่ Judge ของคุณใจดีเกินไป โดยผ่านร่างที่มีสถิติที่สร้างขึ้นเพราะสไตล์การเขียนดูเรียบร้อย หรือเข้มงวดเกินไป โดยล้มเหลวในร่างเพราะความชอบด้านสไตล์ที่ไม่เคยอยู่ใน brief จริงๆ ทั้งสองรูปแบบความล้มเหลวเป็นเรื่องปกติในความพยายามครั้งแรก และทั้งสองแบบมีค่าใช้จ่ายถูกกว่ามากในการจับด้วยตนเองครั้งเดียว มากกว่าที่จะค้นพบหลังจากที่ loop ทำงานไปแล้วห้าสิบครั้งโดยไม่มีคนดูแล
ระยะที่สาม: การเพิ่มชิ้นส่วนที่หายไปของ Loop (ขั้นตอนที่ 10 ถึง 14)
ขั้นตอนที่ 10: สร้าง Manager และ Stop Condition ของมัน
Manager อ่านคำตัดสินของ Judge และตัดสินใจว่าจะเกิดอะไรขึ้นต่อไป นี่คือที่ที่ stop condition ของ loop อยู่ด้วย และมันต้องเขียนเป็นตรรกะที่แข็ง ไม่ใช่คำสั่งแบบอ่อนที่โมเดลสามารถพูดคุยข้ามไปได้
เงื่อนไขการหยุด (STOP CONDITIONS):
- การแก้ไขสูงสุด: 3 ครั้ง เมื่อคำตัดสินล้มเหลวครั้งที่ 3 ให้ส่งต่อไปยังมนุษย์พร้อมประวัติทั้งหมด อย่าพยายามทำรอบที่ 4
- เกณฑ์คุณภาพ: ทุกข้อในคำจำกัดความของความสำเร็จต้องแสดง PASS
- วงเงินงบประมาณ: หากงานนี้เกิน [X] ต้นทุนหรือ [Y] เวลา ให้หยุดทันทีโดยไม่คำนึงถึงสถานะปัจจุบัน
loop ที่ไม่มี stop condition จริงๆ ไม่ใช่ระบบ มันเป็นความรับผิดที่รอวันที่งานกลายเป็นสิ่งที่แก้ไม่ได้จริงๆ เหตุผลเฉพาะที่คำสั่งแบบอ่อนล้มเหลวที่นี่คุ้มค่าที่จะเข้าใจ ไม่ใช่แค่ยอมรับ "หยุดเมื่อมันดีพอ" ภายใน prompt เป็นคำแนะนำ และโมเดลที่อยู่ภายใต้ความกดดันเพียงพอ หลังจากล้มเหลวในการแก้ไขหลายครั้งแล้ว มักจะโน้มน้าวตัวเองว่าความพยายามปัจจุบันใกล้เคียงพอที่จะผ่าน เพราะมันต้องการสร้างผลลัพธ์ที่น่าพอใจให้กับงาน ตัวนับการวนซ้ำแบบแข็งที่ตรวจสอบโดยโค้ด หรือโดยกฎที่ชัดเจนที่ Manager ไม่สามารถใช้เหตุผลหลีกเลี่ยงได้ ไม่มีโหมดความล้มเหลวนั้น
ขั้นตอนที่ 11: เพิ่ม Persistence เพื่อให้ Loop จดจำข้ามการรัน
loop ที่เริ่มต้นจากศูนย์ทุกครั้งที่มันทำงาน ไม่มีความทรงจำเกี่ยวกับสิ่งที่เรียนรู้ในครั้งที่แล้ว เพิ่ม persistence layer ง่ายๆ หนึ่งไฟล์ต่อบทเรียนใหม่จริงๆ พร้อมสรุปหนึ่งบรรทัดที่ด้านบน บันทึกสิ่งที่เรียนรู้หรือแก้ไขและเหตุผลว่าทำไมมันถึงสำคัญ ที่สำคัญคือ บันทึกเฉพาะสิ่งที่ไม่ได้ถูกบันทึกไว้ที่อื่นแล้ว หน่วยความจำที่ซ้ำกันคือสัญญาณรบกวน ไม่ใช่ความรู้
วินัยที่ทำให้ขั้นตอนนี้ทำงานได้จริงในระยะยาวคือการควบคุมในเวลาที่เขียน สัญชาตญาณคือการบันทึกทุกอย่างที่เกิดขึ้นในเซสชัน ซึ่งก่อให้เกิดปัญหาสคริปต์ที่บวมเป๊ะที่แผนงานนี้เตือนไว้ในขั้นตอนที่ 2 เพียงแค่ย้ายไปยังโฟลเดอร์หน่วยความจำแทนที่จะเป็น prompt บทเรียนที่คุ้มค่าที่จะเขียนลงไปคือสิ่งที่จะต้องใช้เวลาจริงๆ ในการค้นพบอีกครั้งหากถูกลืม ไม่ใช่บันทึกของงานประจำที่สำเร็จตามที่คาดหวัง
ขั้นตอนที่ 12: เพิ่มรอบการรวมเข้าด้วยกันตามกำหนดเวลา
Persistence เพียงอย่างเดียวในที่สุดก็สร้างปัญหาเดียวกันกับ prompt ที่บวมเป๊ะ ไฟล์หลายสิบไฟล์ หลายไฟล์พูดสิ่งเดียวกันในเวอร์ชันที่แตกต่างกันเล็กน้อย ตามกำหนดเวลาที่เกิดขึ้นซ้ำๆ สัปดาห์ละครั้งก็สมเหตุสมผล ให้ตรวจสอบไฟล์หน่วยความจำ รวมไฟล์ที่ซ้ำกันเป็นบทเรียนที่คมชัดขึ้นเพียงบทเรียนเดียว และลบสิ่งที่พิสูจน์แล้วว่าผิด เป้าหมายคือไฟล์น้อยลงแต่มีความหนาแน่นมากขึ้นในแต่ละไฟล์ ไม่ใช่กองที่เพิ่มขึ้นเรื่อยๆ
ขั้นตอนนี้เป็นขั้นตอนที่คนส่วนใหญ่ข้ามไปทั้งหมด เพราะมันไม่ได้สร้างความสามารถใหม่ที่มองเห็นได้ด้วยตัวเอง มันแค่ป้องกันปัญหาในอนาคต ความไม่ชัดเจนนั้นคือเหตุผลที่มันต้องถูกกำหนดเวลาไว้อย่างชัดเจน แทนที่จะปล่อยให้มันเกิดขึ้นเมื่อมีคนสังเกตเห็นว่าโฟลเดอร์หน่วยความจำเริ่มยุ่งยาก ซึ่งในทางปฏิบัติหมายความว่ามันจะไม่เกิดขึ้นจนกว่าประสิทธิภาพของ loop จะเริ่มลดลงภายใต้น้ำหนักของบทเรียนที่ขัดแย้งกันและเกี่ยวข้องเพียงครึ่งเดียวที่แข่งขันกันใน context window เดียวกัน
ขั้นตอนที่ 13: เพิ่มขั้นตอนการเรียกคืน (Recall)
เมื่อเริ่มต้นการรันใหม่ใดๆ ให้ loop สแกนสรุปหนึ่งบรรทัดในหน่วยความจำ ระบุว่าบทเรียนใดเกี่ยวข้องกับงานปัจจุบัน และโหลดเฉพาะบทเรียนเหล่านั้น สั่งอย่างชัดเจนให้บอกเมื่อไม่มีอะไรในหน่วยความจำที่เกี่ยวข้อง แทนที่จะบังคับให้บทเรียนในอดีตที่ไม่เกี่ยวข้องเข้ากับสถานการณ์ใหม่เพียงเพราะมีหน่วยความจำอยู่
ขั้นตอนที่ 14: เพิ่ม Scheduling Trigger
ตัดสินใจว่า loop นี้จะทำงานเมื่อใดโดยที่คุณไม่ต้องเริ่มด้วยตนเอง งาน cron ตัวเฝ้าดูไฟล์ ตัวกระตุ้นตามปฏิทินที่เกิดขึ้นซ้ำๆ นี่คือขั้นตอนที่เปลี่ยนระบบที่คุณรันตามต้องการให้เป็นระบบที่ทำงานในขณะที่คุณหลับ และโดยปกติแล้วมันเป็นขั้นตอนที่ง่ายที่สุดในรายการทั้งหมด และเป็นขั้นตอนที่คนส่วนใหญ่ไม่เคยนำไปใช้แม้จะสร้างทุกอย่างอื่นเสร็จแล้วก็ตาม
ระยะที่สี่: การขยายขนาดและการทำให้แข็งแกร่ง (ขั้นตอนที่ 15 ถึง 18)
ขั้นตอนที่ 15: ทดสอบความเครียด (Stress Test) Loop ก่อนที่คุณจะไว้ใจมัน
ก่อนที่จะพึ่งพา loop นี้สำหรับสิ่งใดที่จริงจัง ให้ทดสอบมันกับโหมดความล้มเหลวสี่แบบอย่างตั้งใจ
ให้มันทำงานในเวอร์ชันที่แก้ไม่ได้จริงๆ และยืนยันว่า Manager หยุดจริงๆ แทนที่จะวนซ้ำตลอดไป เพราะ loop ที่ถูกทดสอบเฉพาะกับงานที่มันทำสำเร็จ ไม่เคยแสดงให้เห็นว่ามันรู้วิธีล้มเหลวอย่างสง่างาม
ป้อนผลลัพธ์ที่คุณรู้ว่าผิดอย่างละเอียดให้ Judge บางอย่างที่อ่านดีแต่มีข้อผิดพลาดทางข้อเท็จจริงหรือตรรกะที่คุณปลูกไว้โดยเจตนา และยืนยันว่ามันจับข้อบกพร่องนั้นได้จริงๆ แทนที่จะผ่านสิ่งที่ฟังดูเป็นไปได้
ถ้า Builder และ Judge ใช้โมเดลพื้นฐานเดียวกัน ให้ป้อนความผิดพลาดที่โมเดลนั้นมีลักษณะเฉพาะให้ Judge และดูว่ามันปล่อยความผิดพลาดนั้นผ่านไปหรือไม่ เพราะ Judge ที่มีจุดบอดร่วมกับ Builder จะทำลายจุดประสงค์ทั้งหมดของการแยกจากขั้นตอนที่ 6
คำนวณต้นทุนกรณีแย่ที่สุดของ loop ที่ทำงานถึงขีดจำกัดการแก้ไขสูงสุด โดยใช้การเรียกโมเดลที่แพงที่สุดและผลลัพธ์ที่ยาวที่สุดที่สมเหตุสมผล และตัดสินใจอย่างซื่อสัตย์ว่าตัวเลขนั้น เมื่อปรากฏในใบแจ้งหนี้จริง จะทำให้คุณตกใจหรือไม่
การทดสอบสี่อย่างนี้ก่อนที่จะไว้ใจ loop กับสิ่งที่มีความสำคัญ จะจับภาพความล้มเหลวส่วนใหญ่ที่มิฉะนั้นจะปรากฏขึ้นเป็นครั้งแรกต่อหน้าลูกค้า เจ้านาย หรือใบแจ้งหนี้ของตัวคุณเอง แทนที่จะอยู่ในการทดสอบที่ควบคุมซึ่งคุณตั้งใจทำ
ขั้นตอนที่ 16: ส่งมอบงานไปยังโมเดลที่ถูกต้อง ไม่ใช่โมเดลเดิมทุกครั้ง
เมื่อ loop ทำงานแล้ว ให้ต้านทานนิสัยการรันทุกส่วนของมันด้วยโมเดลโปรดตัวเดียวของคุณ บทบาท Builder มักจะได้ประโยชน์จากโมเดลที่มีความสามารถมากที่สุดของคุณ เพราะมันกำลังใช้เหตุผลที่ยากจริงๆ และโมเดลที่อ่อนแอกว่าที่นี่จะสร้างร่างแรกที่แย่กว่า ซึ่งต้องใช้รอบการแก้ไขมากขึ้นเพื่อแก้ไข มากกว่าที่จะสร้างได้ดีตั้งแต่แรก
บทบาท Judge ซึ่งตรวจสอบตามมาตรฐานที่เขียนไว้เฉพาะ มักจะทำงานได้อย่างน่าเชื่อถือพอๆ กันบนโมเดลที่เล็กกว่า ถูกกว่า และเร็วกว่า เพราะมันไม่ได้ถูกขอให้สร้างสรรค์ แค่ให้สม่ำเสมอ และโมเดลที่เล็กกว่าที่ตรวจสอบตามรายการตรวจสอบที่ระบุไว้อย่างดี มักจะเทียบเท่ากับโมเดลที่ใหญ่กว่าในราคาและเวลาแฝงที่น้อยกว่ามาก
Manager ที่กำหนดเส้นทางตามกฎที่คุณเขียนไว้แล้ว แทบไม่ต้องใช้โมเดลที่แพงที่สุดของคุณเลย เพราะหน้าที่ของมันคือการดำเนินการตามตรรกะที่คุณระบุไว้แล้ว ไม่ใช่การใช้เหตุผลแบบเปิด และมันรันอย่างน้อยหนึ่งครั้งต่อการวนซ้ำโดยไม่คำนึงถึงประสิทธิภาพของ Builder และ Judge ซึ่งทำให้ต้นทุนต่อการเรียกของมันสำคัญกว่าความสามารถดิบ
แนวทางแบบแบ่งชั้นนี้ (โมเดลราคาแพงสำหรับสร้าง โมเดลราคาถูกและสม่ำเสมอสำหรับตรวจสอบงานประจำ โมเดลราคาถูกสำหรับกำหนดเส้นทาง) มักจะเป็นที่มาของการประหยัดต้นทุนที่แท้จริงใน loop คนส่วนใหญ่คิดว่าการควบคุมต้นทุนหมายถึง loops น้อยลงหรือการแก้ไขน้อยลง จริงๆ แล้วมันมาจากการจับคู่ต้นทุนโมเดลกับความยากที่แท้จริงของแต่ละบทบาทเฉพาะภายใน loop ที่คุณสร้างไว้แล้ว
ขั้นตอนที่ 17: ขยายไปยัง Loop ที่สอง ไม่ใช่ห้าพร้อมกัน
สิ่งล่อใจเมื่อ loop แรกทำงานคือการสร้างอีกหลายๆ อันทันที โดยจัดการกับงานที่แตกต่างกันห้างานแบบขนาน เพราะสถาปัตยกรรมรองรับได้แล้วในตอนนี้ ให้ต้านทานสิ่งนี้นานกว่าที่คุณรู้สึกสบายใจ รับประกันว่า loop หนึ่งทำงานได้อย่างน่าเชื่อถือพอที่คุณจะหยุดตรวจสอบผลลัพธ์ของมันอย่างใกล้ชิด นั่นคือมันผ่านการตรวจสอบเฉพาะจุดของคุณเองอย่างสม่ำเสมอในช่วงเวลาจริง ไม่ใช่แค่การสาธิตที่ประสบความสำเร็จครั้งเดียวที่ทุกคนเฝ้าดูอย่างใกล้ชิด จากนั้นจึงเริ่ม loop ที่สองในงานที่แตกต่างกัน โดยเฉพาะอย่างยิ่งงานที่แตกต่างจากงานแรกอย่างสิ้นเชิง เพื่อที่คุณจะได้ทดสอบว่าโครงสร้างพื้นฐานนั้นใช้ได้ทั่วไปหรือไม่ แทนที่จะปรับแต่งงานเดียวกันเพิ่มเติม
ขั้นตอนที่ 18: สร้างมุมมองที่ใช้ร่วมกันสำหรับ Loops ที่ทำงานทั้งหมด
เมื่อคุณมีมากกว่าหนึ่ง loop ที่ทำงาน ให้ติดตามมุมมองที่ใช้ร่วมกันของต้นทุนและตัวกระตุ้น stop condition ข้ามทั้งหมด ไม่ใช่แยกเป็น loop ต่อ loop loop เดียวที่มีงบประมาณต่องานที่สมเหตุสมผลดูดีพอสมควรด้วยตัวของมันเอง แต่สิบ loops ที่แต่ละ loop อยู่ภายในงบประมาณก็สามารถรวมกันเป็นยอดรวมที่น่าตกใจที่ไม่มีใครสังเกตเห็นจนกว่าใบแจ้งหนี้รวมจะมาถึง เพราะการติดตามของแต่ละ loop นั้นดูดีในการแยก
บันทึกตัวกระตุ้น stop condition ทุกครั้งโดยเฉพาะ ไม่ใช่แค่การเสร็จสมบูรณ์ที่สำเร็จ loop ที่ถึงเพดานการแก้ไขตลอดเวลา ในขณะที่ loop อื่นๆ ไม่ค่อยถึง กำลังบอกคุณว่ามาตรฐานของ Judge ของมันปรับไม่ถูกต้อง เข้มงวดเกินไปที่จะผ่านจริงๆ หรือตรวจสอบ ground truth ที่ผิดทั้งหมด ไม่ใช่งานพื้นฐานนั้นยาก รูปแบบนั้นมองไม่เห็นหากคุณติดตามเฉพาะความสำเร็จและปฏิบัติต่อการยกระดับทุกครั้งเป็นเหตุการณ์ที่แยกออกมาและไม่น่าสนใจ แทนที่จะเป็นจุดข้อมูลเกี่ยวกับการออกแบบของ loop นั้นโดยเฉพาะ
ระยะที่ห้า: การเป็นนักออกแบบระบบ (ขั้นตอนที่ 19 และ 20)
ขั้นตอนที่ 19: หยุดวัดตัวเองด้วย prompts ที่เขียน
สัญญาณที่ชัดเจนที่สุดว่าการเปลี่ยนแปลงเกิดขึ้นจริงคือการเปลี่ยนแปลงในสิ่งที่คุณสนใจในแต่ละวัน นัก Prompt ติดตามว่าพวกเขาเขียน prompts ที่ดีกี่อัน นักออกแบบระบบติดตามว่า loops กำลังทำงานกี่อัน แต่ละอันเชื่อถือได้แค่ไหน และเวลาของตัวเองถูกคืนกลับมามากแค่ไหนโดยระบบที่ไม่ต้องการการดูแลอีกต่อไป หากคุณยังคงวัดผลผลิตภาพของคุณในจำนวน prompts ที่พิมพ์ การเปลี่ยนแปลงทางความคิดจากขั้นตอนที่หนึ่งยังไม่ลงตัวอย่างเต็มที่ ไม่ว่าคุณจะสร้าง loops ไปกี่อันในทางเทคนิคก็ตาม
ขั้นตอนที่ 20: สอนคนอื่นถึงการเคลื่อนไหวทั้งห้าอย่าง
ขั้นตอนสุดท้ายไม่เกี่ยวกับระบบของคุณเองอีกต่อไปแล้ว มันคือการยืนยันว่าคุณได้ซึมซับการเปลี่ยนแปลงจริงๆ โดยการอธิบายให้คนอื่นฟังโดยไม่ต้องใช้ศัพท์เทคนิค การค้นหา การส่งต่อ การตรวจสอบ การบันทึก การจัดตารางเวลา หากคุณสามารถพาคนอื่นผ่านการสร้าง loop แรกของพวกเขาเองโดยใช้เพียงการเคลื่อนไหวทั้งห้านี้และขั้นตอนข้างต้น คุณได้ทำการเปลี่ยนแปลงที่แท้จริงที่แผนงานนี้อธิบายไว้ คุณไม่ใช่บุคคลที่อยู่ใน loop พิมพ์คำสั่งถัดไปอีกต่อไป คุณคือบุคคลที่ออกแบบมัน ยืนอยู่ข้างนอก ดูมันทำงาน
สี่ต้นทุนที่สะสมอย่างเงียบๆ หากคุณข้ามขั้นตอน
ควรปิดท้ายด้วยคำเตือน เนื่องจากการข้ามขั้นตอนในแผนงานนี้ไม่ได้ล้มเหลวอย่างดัง มันล้มเหลวอย่างเงียบๆ ในรูปแบบที่ปรากฏให้เห็นในภายหลังเท่านั้น
หนี้การตรวจสอบ (Verification debt) สะสมเมื่อคุณข้ามขั้นตอนที่ 6 และ 7 สร้าง loops โดยไม่มี Judge จริงหรือ ground truth จริง loop ดูเหมือนว่ามันทำงานเพราะผลลัพธ์ดูดี จนกระทั่งความผิดพลาดขยายตัวอย่างเงียบๆ ผ่านการรันหลายสิบครั้งก่อนที่ใครจะสังเกตเห็น
การเสื่อมของความเข้าใจ (Comprehension rot) เกิดขึ้นเมื่อคุณข้ามขั้นตอนที่ 20 เรียกใช้ loops ที่คุณสร้างครั้งเดียว แต่ไม่สามารถอธิบายหรือแก้ไขได้อีกต่อไปถ้ามันพัง เพราะคุณไม่เคยต้องซึมซับว่าทำไมแต่ละส่วนถึงมีอยู่
การยอมจำนนทางปัญญา (Cognitive surrender) เกิดขึ้นเมื่อขั้นตอนที่ 1 ไม่เคยลงตัวอย่างแท้จริง เมื่อคุณยังคงตรวจสอบผลลัพธ์ทุกครั้งด้วยตนเองเป็นนิสัยนานหลังจากที่ระบบตรวจสอบพิสูจน์ตัวเองแล้ว ทำลายจุดประสงค์ทั้งหมดของการสร้างระบบตั้งแต่แรก
ต้นทุน Token พุ่ง (Token blowout) คือสิ่งที่เกิดขึ้นเมื่อคุณข้ามขั้นตอนที่ 10 เรียกใช้ loops โดยไม่มี stop condition จริงๆ ค้นพบต้นทุนที่แท้จริงเมื่อใบแจ้งหนี้มาถึง
ต้นทุนทุกอย่างนี้สามารถหลีกเลี่ยงได้ และทุกอย่างหลีกเลี่ยงได้ด้วยวินัยเดียวกัน สร้างขั้นตอนตามลำดับ อย่าข้ามขั้นตอนที่ดูไม่น่าสนใจ ขั้นตอนที่น่าเบื่อ ได้แก่ คำจำกัดความของความสำเร็จ stop condition และ ground truth คือสิ่งที่ทำงานจริงๆ ส่วนที่ฟังดูน่าสนใจ ได้แก่ prompt ที่ชาญฉลาด แผนภาพสถาปัตยกรรมที่ซับซ้อน มีความสำคัญน้อยกว่าระบบที่คุณสร้างขึ้นรู้จริงหรือไม่ว่ามันถูกต้องเมื่อไหร่ ผิดเมื่อไหร่ และควรหยุดเมื่อไหร่
นั่นคือความแตกต่างทั้งหมดระหว่างนัก prompt และนักออกแบบระบบ ไม่ใช่ความฉลาด แต่เป็นวินัยเกี่ยวกับส่วนที่น่าเบื่อที่จะสร้างและง่ายที่จะข้าม
ติดตาม @cyrilXBT สำหรับเทมเพลต loop ที่แน่นอนและการตั้งค่า Builder-Judge-Manager สำหรับทุกขั้นตอนในแผนงานนี้
