มีช่วงเวลาหนึ่งที่เฉพาะเจาะจงที่แยกคนที่ใช้ AI แบบเล่นๆ ออกจากคนที่ใช้มันเป็นระบบจริงๆ
มันคือช่วงเวลาที่พวกเขาหยุดเป็นคนที่ต้องคอยจับข้อผิดพลาด
ตอนนี้ สำหรับคนส่วนใหญ่ วงจรเป็นแบบนี้ ขอ Claude สร้างอะไรสักอย่าง อ่านผลลัพธ์ สังเกตว่ามีอะไรผิด ชี้ให้เห็น ได้เวอร์ชันที่แก้ไขแล้ว อ่านอีกครั้ง สังเกตอย่างอื่นอีก ชี้ให้เห็นอีกครั้ง คุณคือเลเยอร์การตรวจสอบ ต้องทำด้วยตัวเอง ทุกครั้ง สำหรับทุกงาน
วงจรการแก้ไขตัวเองจะกำจัดคุณออกจากตำแหน่งนั้นโดยสิ้นเชิง ระบบจะสร้าง ตรวจสอบงานของตัวเองกับมาตรฐานจริง จับสิ่งที่มันทำผิด แก้ไขมัน แล้วจึงแสดงผลลัพธ์ให้คุณเห็นเท่านั้น เมื่อคุณเห็นผลลัพธ์ ข้อผิดพลาดที่ชัดเจนถูกจับได้และจัดการเรียบร้อยแล้ว สิ่งที่เหลือให้คุณคือการตัดสินใจในสิ่งต่างๆ ที่ต้องการมนุษย์จริงๆ ไม่ใช่การพิสูจน์อักษรฉบับร่างแรกของเครื่องจักร
นี่คือการสร้างที่สมบูรณ์ เมื่อจบแล้ว คุณจะมีสถาปัตยกรรมที่แน่นอน พร้อมท์ที่แน่นอน และรูปแบบความล้มเหลวที่แน่นอนเพื่อทดสอบก่อนที่คุณจะไว้ใจสิ่งนี้กับอะไรก็ตามที่สำคัญ
ทำไมสิ่งนี้ไม่เหมือนกับการแค่ถามสองครั้ง
สัญชาตญาณแรกที่เห็นได้ชัดคือการแค่ขอให้โมเดลตรวจสอบงานของตัวเองในบทสนทนาเดียวกัน "ทบทวนสิ่งที่คุณเพิ่งเขียนและแก้ไขข้อผิดพลาดใดๆ" สิ่งนี้ช่วยได้เล็กน้อย แต่ไม่ได้สร้างวงจรการแก้ไขตัวเองที่แท้จริง และการเข้าใจว่าทำไมถึงเป็นเช่นนั้นคือรากฐานทั้งหมดของสิ่งที่ตามมา
โมเดลที่ตรวจสอบผลลัพธ์ของตัวเองในบริบทเดียวกัน ด้วยเหตุผลเดียวกันที่ทำให้เกิดข้อผิดพลาดตั้งแต่แรก มักจะปกป้องงานของตัวเองมากกว่าที่จะตรวจสอบอย่างจริงจัง นี่ไม่ใช่ข้อบกพร่องเฉพาะของโมเดลใดโมเดลหนึ่ง มันเป็นปัญหาเชิงโครงสร้าง การผ่านครั้งเดียวกันที่สร้างคำตอบที่ฟังดูมีเหตุผลแต่ผิดนั้น ไม่ได้อยู่ในตำแหน่งที่ดีที่จะสังเกตว่ามันผิด เพราะจากภายใน คำตอบนั้นยังคงฟังดูมีเหตุผล การถามว่า "คุณแน่ใจไหม?" มักจะให้คำรับรองมากกว่าที่จะให้การตรวจสอบซ้ำอย่างจริงจัง
วิธีแก้ไขไม่ใช่การถามให้ดีขึ้น มันคือสถาปัตยกรรม วงจรการแก้ไขตัวเองที่แท้จริงจะแยกงานสร้างคำตอบออกจากงานตัดสินมัน โดยใช้การผ่านที่แตกต่างกัน พร้อมท์ที่แตกต่างกัน และ ideally กรอบอ้างอิงที่แตกต่างกันโดยสิ้นเชิง เพื่อให้การตัดสินไม่ถูกปนเปื้อนจากจุดบอดเดียวกันกับที่สร้างข้อผิดพลาด
สามบทบาทที่ทุกวงจรการแก้ไขตัวเองต้องการ
ทุกระบบการแก้ไขตัวเองที่ใช้งานได้ โดยไม่คำนึงถึงงานเฉพาะ จะลดลงเหลือสามบทบาทที่แตกต่างกัน การเข้าใจบทบาทเหล่านี้อย่างชัดเจนสำคัญกว่าพร้อมท์เฉพาะใดๆ ด้านล่าง เพราะเมื่อคุณเห็นมันแล้ว คุณสามารถสร้างวงจรสำหรับเกือบทุกงานโดยการกรอกรายละเอียดเฉพาะ
ผู้สร้าง (The Builder) ผลิตผลลัพธ์ที่แท้จริง เขียนโค้ด ร่างเนื้อหา ทำการวิจัย ดำเนินงาน บทบาทนี้ควรได้รับอิสระในการสร้างสรรค์มากที่สุดและข้อจำกัดน้อยที่สุด เพราะงานของมันคือการสร้างความพยายามครั้งแรก ไม่ใช่ความสมบูรณ์แบบ
ผู้ตัดสิน (The Judge) ไม่ได้สร้างอะไรเลย งานเดียวของมันคือการประเมินผลลัพธ์ของผู้สร้างเทียบกับมาตรฐานที่เขียนไว้โดยเฉพาะ ไม่ใช่ความรู้สึกคลุมเครือเกี่ยวกับคุณภาพ โค้ดผ่านการทดสอบของมันหรือไม่ เนื้อหาตรงตามข้อกำหนดหรือไม่ งานวิจัยตอบคำถามที่ถูกถามจริงหรือไม่ ผู้ตัดสินควร ideally เข้าถึงสิ่งที่ผู้สร้างไม่มี แหล่งที่มาดั้งเดิม ชุดทดสอบ เอกสารข้อกำหนดจริง เพื่อให้มันมีข้อมูลจริงอิสระเพื่อตรวจสอบ แทนที่จะแค่อ่านผลลัพธ์เดียวกันซ้ำและสร้างความคิดเห็นใหม่
ผู้จัดการ (The Manager) อ่านคำตัดสินของผู้ตัดสินและตัดสินใจว่าจะเกิดอะไรขึ้นต่อไป ส่งกลับไปยังผู้สร้างพร้อมข้อเสนอแนะเฉพาะ ส่งต่อไปยังมนุษย์ ทำเครื่องหมายว่างานเสร็จสมบูรณ์ นี่คือที่ที่เงื่อนไขหยุดของคุณอยู่ กฎที่ป้องกันไม่ให้วงจรทำงานตลอดไปเมื่อบางสิ่งไม่สามารถแก้ไขโดยอัตโนมัติได้จริงๆ
หลักการออกแบบที่สำคัญในทั้งสามบทบาท: การตรวจสอบต้องอ้างอิงถึงบางสิ่งภายนอกเหตุผลของผู้สร้างเอง ชุดทดสอบ เอกสารต้นฉบับ รายการตรวจสอบที่เขียนไว้ การเรียก AI ครั้งที่สองที่มีกรอบแตกต่างอย่างแท้จริง อะไรก็ตามที่ไม่ใช่แค่ "โมเดลเดียวกัน ถามอีกครั้ง ในลมหายใจเดียวกัน"
การสร้างการส่งต่อ (Handoffs)
งานวิศวกรรมที่แท้จริงในวงจรการแก้ไขตัวเองไม่ใช่พร้อมท์ที่ชาญฉลาดสำหรับแต่ละบทบาท มันคือโครงสร้างของสิ่งที่ส่งผ่านระหว่างพวกมัน และนี่คือส่วนที่คนส่วนใหญ่ที่สร้างวงจรแรกของพวกเขาข้ามไปโดยสิ้นเชิง แล้วก็สงสัยว่าทำไมระบบถึงทำงานไม่แน่นอน
การส่งต่อต้องมีสามคุณสมบัติเพื่อให้ทำงานได้อย่างน่าเชื่อถือ รูปแบบที่กำหนดไว้ เพื่อให้บทบาทที่รับไม่ต้องแยกวิเคราะห์ข้อความที่หลวมและเดาเอาว่าสำคัญอะไร ทริกเกอร์ที่กำหนดไว้ เพื่อให้ผู้สร้างไม่ใช่คนตัดสินใจว่าเมื่อไรมันเสร็จ และเส้นทางความล้มเหลวที่กำหนดไว้ เพื่อที่เมื่อบางอย่างไม่ราบรื่น จะมีขั้นตอนถัดไปที่ระบุไว้ แทนที่ระบบจะเงียบๆ พังหรือวนซ้ำตลอดไป
ในทางปฏิบัติ นี่หมายความว่าผู้สร้างควรส่งออกสิ่งที่มีโครงสร้าง ไม่ใช่แค่ข้อความสนทนา ผลงานที่ชัดเจนพร้อมข้อความชัดเจนเกี่ยวกับสิ่งที่มันไม่แน่ใจ จากนั้นผู้ตัดสินประเมินผลลัพธ์ที่มีโครงสร้างนั้นเทียบกับมาตรฐานที่เขียนไว้และส่งคืนคำตัดสินที่มีโครงสร้างของตัวเอง ไม่ใช่ย่อหน้าของข้อความที่กำกวม แต่เป็นการผ่าน ล้มเหลว หรือต้องแก้ไขอย่างชัดเจน พร้อมเหตุผลเฉพาะที่แนบมา ผู้จัดการอ่านคำตัดสินที่มีโครงสร้างนั้น ไม่ใช่เนื้อหาดิบ และตัดสินใจการดำเนินการถัดไปตามกฎที่กำหนดไว้ล่วงหน้า ไม่ใช่โดยการ improvising การตัดสินในขณะนั้น
นี่คือเทมเพลตโครงสร้างที่ใช้ได้กับงานส่วนใหญ่ ไม่ว่างานพื้นฐานจะเป็นงานเขียน โค้ด หรือการวิจัย:
1BUILDER OUTPUT FORMAT2Deliverable: [ผลลัพธ์จริง]3Confidence: [สูง / กลาง / ต่ำ]4Known uncertainties: [อะไรก็ตามที่คุณไม่แน่ใจ ระบุอย่างชัดเจน]5Assumptions made: [อะไรก็ตามที่คุณสันนิษฐานโดยไม่ได้รับแจ้ง]67JUDGE VERDICT FORMAT8Verdict: [ผ่าน / ไม่ผ่าน / ต้องแก้ไข]9Checked against: [มาตรฐานเฉพาะที่ใช้ เช่น ข้อกำหนดดั้งเดิม10ชุดทดสอบ เอกสารต้นฉบับ]11Specific issues found: [ปัญหาที่แน่นอน ไม่ใช่ความประทับใจทั่วไป]12Confidence in this verdict: [สูง / กลาง / ต่ำ]1314MANAGER ACTION15If PASS: ทำเครื่องหมายเสร็จสมบูรณ์ ส่งมอบให้ผู้ใช้16If FAIL or NEEDS REVISION: ส่งกลับไปยังผู้สร้างพร้อมปัญหาเฉพาะ17ของผู้ตัดสินที่แนบมา เพิ่มตัวนับการแก้ไข18If revision counter exceeds [N]: หยุดวนซ้ำ ส่งต่อไปยังมนุษย์19พร้อมประวัติทั้งหมดของสิ่งที่ลองและสาเหตุที่ล้มเหลว
สิ่งนี้ดูมีโครงสร้างมากกว่าการสนทนาที่กลับไปกลับมาแบบไม่เป็นทางการ และมันก็เป็นเช่นนั้น ต้นทุนล่วงหน้านี้คือสิ่งที่ทำให้คุณได้ระบบที่ทำงานในลักษณะเดียวกันในรอบที่ร้อยเหมือนกับที่ทำในรอบแรก แทนที่จะล่องลอยไปอย่างคาดเดาไม่ได้เมื่อบริบทสะสม
ผู้ตัดสินต้องการความจริงพื้นฐาน (Ground Truth) ไม่ใช่แค่ความคิดเห็น
นี่คือหลักการที่สำคัญที่สุดในระบบทั้งหมด และมันสมควรมีส่วนของตัวเองเพราะการทำให้มันผิดจะบ่อนทำลายทุกอย่างอื่นอย่างเงียบๆ
ผู้ตัดสินที่เห็นเฉพาะผลลัพธ์ของผู้สร้าง โดยไม่มีข้อมูลอ้างอิงอิสระเพื่อตรวจสอบ สามารถประเมินได้เพียงความสอดคล้องภายในเท่านั้น ว่าผลลัพธ์ดูสอดคล้องและมีรูปแบบที่ดีหรือไม่ มันไม่สามารถประเมินความถูกต้อง ว่าผลลัพธ์ตรงกับสิ่งที่ถูกถามจริงหรือแก้ปัญหาจริงหรือไม่ คำตอบที่ผิดแต่มั่นใจ มีรูปแบบดีและสอดคล้องภายใน จะผ่านผู้ตัดสินที่ไม่มีข้อมูลจริงทุกครั้ง
สำหรับงานโค้ด ความจริงพื้นฐานคือชุดทดสอบ ผลลัพธ์จริงของการรันโค้ด ผลลิงต์ สถานะบิลด์ ไม่ใช่ "โค้ดนี้ดูถูกต้องหรือไม่" แต่ "มันผ่านจริงเมื่อถูก execute หรือไม่"
สำหรับงานเนื้อหา ความจริงพื้นฐานคือแหล่งที่มาดั้งเดิมและข้อกำหนดดั้งเดิม วางเคียงข้างกับร่าง ไม่ใช่ "สิ่งนี้อ่านดีหรือไม่" แต่ "ทุกข้ออ้างเฉพาะในร่างนี้โยงกลับไปยังสิ่งที่อยู่ในแหล่งที่มาจริงหรือไม่ และชิ้นงานนั้นตอบสนองทุกข้อกำหนดในข้อกำหนดจริงหรือไม่"
สำหรับงานวิจัย ความจริงพื้นฐานคือผลการค้นหาจริงและเอกสารต้นฉบับที่งานวิจัยควรจะอ้างอิง ไม่ใช่ "บทสรุปนี้ฟังดูน่าเชื่อถือหรือไม่" แต่ "ทุกข้ออ้างสามารถโยงไปยังแหล่งที่มาเฉพาะได้หรือไม่ และแหล่งที่มาที่ถูกค้นหาเป็นแหล่งที่เกี่ยวข้องจริงหรือไม่"
ถ้าคุณไม่สามารถระบุได้ว่าความจริงพื้นฐานของผู้ตัดสินคืองานเฉพาะของคุณคืออะไร คุณยังไม่มีวงจรการแก้ไขตัวเอง คุณมีวงจรการเรียบเรียงใหม่ ที่ข้อผิดพลาดที่มั่นใจของผู้สร้างได้รับการเรียบเรียงใหม่อย่างมั่นใจโดยผู้ตัดสิน แทนที่จะถูกจับได้จริงๆ
เงื่อนไขหยุด (Stop Condition) ไม่ใช่ทางเลือก
วิธีที่พบบ่อยที่สุดที่วงจรการแก้ไขตัวเองกลายเป็นเรื่องยุ่งเหยิงที่มีค่าใช้จ่ายสูงและควบคุมไม่ได้คือการไม่มีเงื่อนไขหยุดที่ชัดเจนและเข้มงวด หากไม่มี ผู้สร้างและผู้ตัดสินสามารถวนซ้ำได้ไม่มีกำหนด การแก้ไขแต่ละครั้งกระตุ้นการประเมินอีกครั้ง การประเมินแต่ละครั้งกระตุ้นการแก้ไขอีกครั้ง ในขณะที่ค่าใช้จ่ายเพิ่มสูงขึ้นและไม่มีใครสังเกตจนกระทั่งบิลมาถึง
เงื่อนไขหยุดที่แท้จริงต้องการสามองค์ประกอบ และทั้งหมดควรถูกบังคับใช้เป็นตรรกะที่ชัดเจน ไม่ใช่ปล่อยให้เป็นดุลยพินิจของโมเดลในขณะนั้น
จำนวนการวนซ้ำสูงสุด เพดานแข็งของรอบการแก้ไข หลังจากนั้นผู้จัดการถูกบังคับให้ส่งต่อไปยังมนุษย์ไม่ว่าผู้ตัดสินจะพอใจหรือไม่ก็ตาม
เกณฑ์คุณภาพที่วัดได้จริง ไม่ใช่ความทะเยอทะยาน "ดีพอ" ในคำสั่งภายในพร้อมท์ไม่ใช่เงื่อนไขหยุด เพราะมันเป็นคำแนะนำที่โมเดลสามารถและจะเพิกเฉยในที่สุดภายใต้แรงกดดันที่เหมาะสม เกณฑ์เฉพาะที่ตรวจสอบได้ การทดสอบทั้งสิบเอ็ดกรณีผ่าน หรือร่างตรงตามข้อกำหนดที่ระบุทั้งหมดห้าข้อ เป็นเงื่อนไขหยุด เพราะมันสามารถตรวจสอบได้โดยกลไก แทนที่จะถูกตัดสินตามอัตวิสัยทุกครั้ง
เพดานค่าใช้จ่ายหรือเวลา งบประมาณที่แน่นอนที่งานต้องไม่เกิน ไม่ว่ามันจะอยู่ในสถานะใดเมื่อถึงเพดานนั้น นี่คือราวกั้นที่ปกป้องคุณโดยเฉพาะจากสถานการณ์ที่เลวร้ายที่สุด งานที่แก้ไม่ได้จริงๆ วนซ้ำจนกว่าจะมีใครสังเกตเห็นใบแจ้งหนี้
STOP CONDITIONS
Maximum revisions: 3. ในการตัดสินล้มเหลวครั้งที่ 3 ให้หยุดและส่งต่อไปยังมนุษย์
พร้อมประวัติการแก้ไขทั้งหมดที่แนบมา อย่าพยายามรอบที่ 4 โดยอัตโนมัติ
Quality threshold: รายการทั้งหมดในรายการตรวจสอบของผู้ตัดสินต้องแสดงสถานะผ่าน
ไม่ใช่ "ผ่านเป็นส่วนใหญ่" หรือ "ใกล้เคียง"
Budget ceiling: หากงานนี้ใช้ token มากกว่า [X] หรือเวลาเกิน [Y] นาที
ให้หยุดทันทีโดยไม่คำนึงถึงสถานะปัจจุบัน และรายงานสิ่งที่เสร็จสมบูรณ์เทียบกับสิ่งที่เหลืออยู่
เขียนสิ่งเหล่านี้ลงในตรรกะจริงของผู้จัดการ ไม่ใช่ในคำสั่งที่นุ่มนวลภายในพร้อมท์ยาวที่โมเดลสามารถโต้แย้งออกไปได้ภายใต้แรงกดดัน
ตัวอย่างการทำงาน: การผลิตเนื้อหาแบบแก้ไขตัวเอง
เพื่อให้เป็นรูปธรรม นี่คือวิธีที่สามบทบาทและเงื่อนไขหยุดทำงานร่วมกันสำหรับงานทั่วไปที่เกิดขึ้นจริง การเปลี่ยนเอกสารต้นฉบับให้เป็นชิ้นเนื้อหาที่เสร็จสมบูรณ์ โดยไม่มีมนุษย์ตรวจทานร่างทุกฉบับด้วยตนเอง
ผู้สร้างได้รับแหล่งที่มาและข้อกำหนด และผลิตร่าง ผลลัพธ์ของมันรวมถึงตัวร่างเอง พร้อมข้อความแสดงความมั่นใจที่ชัดเจนและรายการอะไรก็ตามที่มันไม่แน่ใจในขณะเขียน ตัวเลขที่มันไม่แน่ใจว่าอยู่ในแหล่งที่มาจริง ข้ออ้างที่มันอนุมาน而非พบโดยตรง
ผู้ตัดสินได้รับร่างและแหล่งที่มาดั้งเดิมวางเคียงข้างกัน ไม่เคยได้รับร่างเพียงลำพัง มันตรวจสอบสามสิ่งเฉพาะ โดยแต่ละอย่างมีผ่านหรือไม่ผ่านของตัวเอง ข้ออ้างข้อเท็จจริงทุกข้อในร่างโยงกลับไปยังสิ่งที่มีอยู่ในแหล่งที่มาจริงหรือไม่ ร่างตอบสนองทุกข้อกำหนดเฉพาะในข้อกำหนดหรือไม่ ความยาว น้ำเสียง ส่วนที่ต้องการ แกนหลักของข้อโต้แย้งหรือจุดขายมีอยู่จริงและไม่ถูกเจือจางด้วยเนื้อหาที่ไม่จำเป็นหรือไม่ ผู้ตัดสินส่งคืนคำตัดสินที่มีโครงสร้างพร้อมผ่านหรือไม่ผ่านในแต่ละการตรวจสอบสามอย่างแยกกัน เพราะการรวมเป็นคะแนนเดียวจะซ่อนว่ามิติใดล้มเหลว
ผู้จัดการอ่านคำตัดสินที่มีโครงสร้างนั้น การผ่านที่สะอาดในทั้งสามอย่างส่งร่างไปยังคิวผลลัพธ์สุดท้าย ความล้มเหลวในมิติการตรวจสอบข้อเท็จจริงส่งกลับไปยังผู้สร้างพร้อมข้ออ้างที่ไม่ได้รับการยืนยันเฉพาะที่ถูกชี้โดยตรง ไม่ใช่คำสั่งคลุมเครือให้ "ตรวจสอบความถูกต้องอีกครั้ง" ความล้มเหลวในการปฏิบัติตามข้อกำหนดส่งกลับไปยังผู้สร้างพร้อมข้อกำหนดที่ขาดหายไปที่ระบุชื่อ หลังจากสามรอบที่ล้มเหลวในการตรวจสอบเดียวกัน ผู้จัดการหยุดวนซ้ำโดยสิ้นเชิงและส่งต่อไปยังมนุษย์พร้อมประวัติที่สมบูรณ์ของสิ่งที่ลอง แทนที่จะพยายามแก้ไขปัญหาที่ระบบได้แสดงให้เห็นแล้วว่าไม่สามารถแก้ไขได้ด้วยตัวเอง
นี่คือระบบขนาดเล็ก สามบทบาท รูปแบบการส่งต่อที่มีโครงสร้างหนึ่งรูปแบบ เงื่อนไขหยุดที่ชัดเจนหนึ่งอย่าง มันยังเป็นระบบที่คุณสามารถรันโดยไม่ต้องดูแลและไว้วางใจผลลัพธ์ของมัน เพราะทุกรูปแบบความล้มเหลวมีเส้นทางที่กำหนดไว้แทนที่จะไม่กำหนด
การทดสอบวงจรก่อนที่คุณจะไว้ใจมัน
ก่อนที่คุณจะพึ่งพาระบบการแก้ไขตัวเองสำหรับสิ่งที่มีความสำคัญจริงๆ ให้รันมันผ่านการทดสอบความเครียดเฉพาะเหล่านี้อย่างตั้งใจ วงจรส่วนใหญ่ที่ล้มเหลวในการใช้งานจริงจะล้มเหลวในการทดสอบเหล่านี้ทันที ถ้ามีใครสักคนเคยตรวจสอบก่อน
การทดสอบงานที่แก้ไม่ได้ จงใจให้ผู้สร้างทำงานที่มันไม่สามารถทำให้สำเร็จตามมาตรฐานของผู้ตัดสิน โดยตั้งใจ ผู้จัดการชนเพดานการวนซ้ำและส่งต่อไปยังมนุษย์อย่างถูกต้องหรือไม่ หรือมันหมุนต่อไปไม่มีที่สิ้นสุด สิ้นเปลืองค่าใช้จ่ายกับงานที่จะไม่มีวันสำเร็จ
การทดสอบความผิดพลาดที่มั่นใจ ป้อนผลลัพธ์ที่คุณรู้อยู่แล้วว่าผิดอย่าง subtle ให้ผู้ตัดสิน สิ่งที่อ่านดีแต่มีข้อผิดพลาดทางข้อเท็จจริงหรือตรรกะที่เฉพาะเจาะจง ผู้ตัดสินที่มีข้อมูลอ้างอิงความจริงพื้นฐานจับมันได้ถูกต้องหรือไม่ ถ้าผู้ตัดสินผ่านสิ่งที่คุณรู้ว่าพัง ข้อมูลอ้างอิงความจริงพื้นฐานของคุณไม่ได้ถูกตรวจสอบจริง หรือการตรวจสอบตื้นเกินไป
การทดสอบจุดบอดของโมเดลเดียวกัน ถ้าผู้สร้างและผู้ตัดสินของคุณรันบนโมเดลพื้นฐานเดียวกัน สิ่งนี้คุ้มค่าที่จะตรวจสอบโดยตรง ป้อนผลลัพธ์ที่มีข้อผิดพลาดประเภทที่โมเดลนั้นมีแนวโน้มจะทำเป็นนิสัยให้ผู้ตัดสิน ถ้าผู้ตัดสินปล่อยผ่าน คุณสร้างวงจรที่แบ่งปันจุดบอดระหว่างบทบาท ซึ่งทำลายจุดประสงค์ทั้งหมดของการแยกพวกมัน พิจารณาใช้โมเดลที่แตกต่างอย่างแท้จริง หรืออย่างน้อยที่สุด กรอบพร้อมท์ที่แตกต่างอย่างมีนัยสำคัญ สำหรับบทบาทผู้ตัดสินโดยเฉพาะ
การทดสอบค่าใช้จ่ายหนีไม่พ้น คำนวณเส้นทางที่เลวร้ายที่สุดผ่านระบบของคุณ การแก้ไขสูงสุด การเรียกโมเดลที่แพงที่สุดที่เกี่ยวข้อง ความยาวเนื้อหาที่สมเหตุสมผลที่สุด และคำนวณว่าสิ่งนั้นมีค่าใช้จ่ายจริงเท่าไหร่ในเงินจริงและเวลาจริง ถ้าตัวเลขนั้นทำให้คุณตกใจเมื่อปรากฏบนใบแจ้งหนี้จริง เงื่อนไขหยุดของคุณยังไม่เข้มงวดพอ
การรันการทดสอบสี่อย่างนี้ก่อนที่จะไว้วางใจวงจรการแก้ไขตัวเองกับสิ่งใดจริงๆ จะจับข้อผิดพลาดส่วนใหญ่ที่มิฉะนั้นจะปรากฏขึ้นครั้งแรกต่อหน้าลูกค้า เจ้านาย หรือใบแจ้งหนี้ธนาคารของคุณ
ข้อผิดพลาดทั่วไปที่ทำลายการออกแบบที่ดีอย่างเงียบๆ
แม้จะมีสถาปัตยกรรมสามบทบาทที่ถูกต้อง ข้อผิดพลาดในการนำไปใช้เฉพาะจำนวนหนึ่งเกิดขึ้นซ้ำแล้วซ้ำเล่าในโดเมนที่แตกต่างกันโดยสิ้นเชิง และการรู้ล่วงหน้าช่วยคุณจากการค้นพบแต่ละอย่างอีกครั้งด้วยวิธีที่ยากลำบาก
ปล่อยให้ผู้ตัดสินเห็นเฉพาะผลลัพธ์ของผู้สร้าง โดยไม่มีข้อมูลอ้างอิงอิสระ นี่คือข้อผิดพลาดที่พบบ่อยที่สุด และมันเปลี่ยนระบบของคุณจากการตรวจสอบความถูกต้องเป็นการตรวจสอบความสอดคล้องอย่างเงียบๆ ผู้ตัดสินที่ไม่มีอะไรเทียบสามารถบอกคุณได้เพียงว่าผลลัพธ์ดูสอดคล้องภายใน ไม่เคยบอกว่ามันถูกต้องจริงหรือไม่
ให้ทุกบทบาทมีโมเดลเดียวกันโดยมีเพียงคำสั่งที่แตกต่างกันเล็กน้อยวางซ้อน ถ้าผู้ตัดสินรันโมเดลพื้นฐานเดียวกันกับผู้สร้าง โดยมีเพียงพร้อมท์ที่แตกต่างกันบอกให้ "จับผิด" มันมักจะสืบทอดจุดบอดเดียวกันกับที่ผู้สร้างมี เพราะโดยพื้นฐานแล้วมันเป็นกระบวนการเหตุผลเดียวกันที่สวมหมวกคนละใบ เมื่องบประมาณเอื้ออำนวย โมเดลที่แตกต่างอย่างแท้จริงสำหรับบทบาทผู้ตัดสินจะสร้างความเป็นอิสระที่แท้จริงแทนที่จะเป็นความเป็นอิสระที่แสดงละคร
ปฏิบัติต่อผู้จัดการเป็นทางผ่านธรรมดาแทนที่จะให้มันมีความทรงจำจริงเกี่ยวกับความพยายามก่อนหน้านี้ ผู้จัดการที่ไม่มีความสามารถในการมองเห็นสิ่งที่ลองไปแล้วในงานนี้ จะส่งข้อเสนอแนะที่ล้มเหลวแบบเดียวกันกลับไปยังผู้สร้างเป็นครั้งที่สองและสาม ทำให้เกิดผลลัพธ์ที่ล้มเหลวเหมือนเดิมทุกครั้ง เพราะไม่มีอะไรในระบบที่จำได้ว่าแนวทางนี้เคยล้มเหลวแล้วครั้งหนึ่ง
ข้ามการทดสอบความเครียดสี่อย่างเพราะระบบทำงานได้ดีในการรันสาธิตครั้งเดียวที่ทุกคนดูอย่างใกล้ชิด ระบบที่ทำงานถูกต้องในขณะที่คุณดูมันอย่างใกล้ชิด กับระบบที่ทำงานถูกต้องในขณะที่รันโดยไม่มีใครดูแล เป็นข้ออ้างที่แตกต่างกัน ข้ออ้างที่สองเท่านั้นคือจุดประสงค์ที่แท้จริงของการสร้างวงจรการแก้ไขตัวเองตั้งแต่แรก ถ้าคุณยังไม่ได้ทดสอบรูปแบบความล้มเหลวอย่างตั้งใจ คุณยังไม่รู้จริงๆ ว่าข้ออ้างใดเป็นจริงสำหรับระบบของคุณ
เขียนเงื่อนไขหยุดเป็นคำสั่งที่นุ่มนวลแทนที่จะเป็นตรรกะที่แข็ง "หยุดเมื่อมันดีพอ" ภายในพร้อมท์ไม่ใช่เงื่อนไขหยุด มันเป็นคำแนะนำที่โมเดลสามารถและจะพูดเกินเลยออกไปภายใต้แรงกดดันที่เหมาะสม ตัวนับการวนซ้ำที่แข็งที่ผู้จัดการตรวจสอบโดยกลไกก่อนที่จะอนุญาตให้มีรอบถัดไปคือเงื่อนไขหยุด ความแตกต่างระหว่างสองสิ่งนี้สำคัญมากในครั้งแรกที่งานกลายเป็นว่าแก้ไม่ได้จริงๆ
ตัวอย่างการทำงานที่สอง: โค้ดแบบแก้ไขตัวเอง
โครงกระดูกเดียวกันดูแตกต่างแต่ใช้ตรรกะเดียวกันเมื่องานเป็นโค้ดแทนที่จะเป็นเนื้อหา และการเดินผ่านทั้งสองอย่างเคียงข้างกันทำให้ชัดเจนว่ามีอะไรเปลี่ยนแปลงน้อยเพียงใดระหว่างโดเมน
ผู้สร้างที่นี่คือเอเจนต์การเขียนโค้ดที่ทำงานผ่านงานที่กำหนด การแก้ไขบั๊ก ฟีเจอร์ การรีแฟคเตอร์ ผลลัพธ์ที่มีโครงสร้างของมันไม่ใช่แค่ diff โค้ด แต่รวมถึงผลลัพธ์คำสั่งจริงจากการพยายามรันมัน ผลการทดสอบ ผลลิงต์ สถานะบิลด์ ที่รวมอยู่ใน handoff ผู้สร้างที่สร้างโค้ดแต่ไม่เคย execute มันจริงๆ ไม่ได้ทำหน้าที่ผู้สร้างอย่างถูกต้อง เพราะโค้ดที่ดูมีไวยากรณ์ถูกต้องแต่ล้มเหลวในชุดทดสอบของตัวเองนั้นแย่กว่าไม่มีโค้ดเลย เพราะมันดูเสร็จโดยไม่เสร็จ
ผู้ตัดสินตรวจสอบสามสิ่งที่เฉพาะเจาะจงและตรวจสอบได้ การเปลี่ยนแปลงผ่านชุดทดสอบที่มีอยู่โดยที่ตัวทดสอบเองไม่ถูกแก้ไขหรือไม่ เพราะผู้สร้างที่แก้ไขการทดสอบอย่างเงียบๆ เพื่อให้ผ่านเป็นความล้มเหลวเฉพาะที่พบได้บ่อยอย่างน่าประหลาดใจและคุ้มค่าที่จะตรวจสอบโดยตรง การวิเคราะห์แบบ static และ linting กลับมาสะอาดหรือไม่ Diff นั้นจัดการกับงานที่ได้รับมอบหมายจริงหรือไม่ ไม่ใช่ปัญหาที่เกี่ยวข้องแต่แตกต่างที่ผู้สร้างตัดสินใจว่าน่าสนใจกว่าที่จะแก้ไขระหว่างทาง แต่ละอย่างได้รับการผ่านหรือไม่ผ่านที่ชัดเจนในคำตัดสินที่มีโครงสร้าง
ผู้จัดการกำหนดเส้นทางตามการตรวจสอบเฉพาะที่ล้มเหลว ชุดทดสอบที่ล้มเหลวส่งกลับไปยังผู้สร้างพร้อมผลลัพธ์การทดสอบที่ล้มเหลวที่แนบมาโดยตรง ไม่ใช่คำสั่งทั่วไปให้ "แก้ไขการทดสอบ" ความไม่ตรงกันของขอบเขต ที่ diff แก้ปัญหาที่แตกต่างจากที่ได้รับมอบหมาย ส่งต่อไปยังมนุษย์ทันทีแทนที่จะวนซ้ำ เพราะนั่นคือความล้มเหลวในการตัดสินเกี่ยวกับว่างานนั้นคืออะไรจริงๆ ไม่ใช่ข้อบกพร่องทางกลที่ผู้สร้างสามารถแก้ไขได้ด้วยการวนซ้ำด้วยตัวเอง
สังเกตว่าโครงกระดูกพื้นฐานที่นี่ ผู้สร้างผลิตและส่งพร้อมหลักฐาน ผู้ตัดสินตรวจสอบเทียบกับเกณฑ์ที่ระบุชื่อเฉพาะพร้อมคำตัดสินต่อการตรวจสอบ ผู้จัดการกำหนดเส้นทางตามว่าการตรวจสอบใดล้มเหลว เหมือนกับตัวอย่างการผลิตเนื้อหาด้านบน นี่คือบทเรียนที่แท้จริงที่ควรนำติดตัวไปจากการเห็นสองโดเมนที่แตกต่างกันเคียงข้างกัน เมื่อคุณมีโครงกระดูกที่ถูกต้องแล้ว การนำไปใช้กับงานประเภทใหม่ส่วนใหญ่คือการเขียนรายการตรวจสอบเฉพาะใหม่สำหรับผู้ตัดสิน ไม่ใช่การออกแบบสถาปัตยกรรมทั้งหมดใหม่จากหลักการแรกทุกครั้ง
การปรับขนาดเป็นหลายวงจรพร้อมกัน
เมื่อวงจรการแก้ไขตัวเองเดี่ยวมีความน่าเชื่อถือจริงๆ คำถามถัดไปที่แท้จริงคือวิธีรันหลายวงจรพร้อมกันโดยที่ระบบไม่จัดการไม่ได้ เนื่องจากนี่คือจุดที่ความพยายามครั้งที่สองของคนส่วนใหญ่ในการปรับขนาดสิ่งนี้ผิดพลาด
สิ่งล่อใจคือการเปิดหลายวงจรพร้อมกันทันทีที่วงจรแรกทำงานได้ รับมือกับห้างานที่แตกต่างกันในแบบขนานเพราะสถาปัตยกรรมรองรับในทางเทคนิค ต่อต้านสิ่งนี้นานกว่าที่คุณรู้สึกว่าจำเป็น ทุกวงจรพร้อมกันที่เพิ่มขึ้นคืออีกที่ที่เงื่อนไขหยุดสามารถล้มเหลวอย่างเงียบๆ อีกที่ที่ค่าใช้จ่ายสามารถหนีไม่พ้นโดยไม่มีใครสังเกต อีกที่ที่ข้อมูลอ้างอิงความจริงพื้นฐานของผู้ตัดสินอาจผิดเล็กน้อยในทางที่ปรากฏเฉพาะภายใต้ปริมาณจริงเท่านั้น ไม่ใช่ในการรันทดสอบครั้งเดียว
เส้นทางการปรับขนาดที่ปลอดภัยกว่าคือการขยายตามลำดับด้วยเกณฑ์ความไว้วางใจที่แท้จริงในแต่ละขั้นตอน ทำให้วงจรเดียวทำงานได้อย่างน่าเชื่อถือพอที่คุณหยุดตรวจสอบผลลัพธ์อย่างใกล้ชิด หมายความว่ามันผ่านการสุ่มตรวจสอบด้วยตนเองของคุณอย่างสม่ำเสมอในช่วงเวลาจริงที่ยาวนาน ไม่ใช่แค่การรันสาธิตที่สำเร็จครั้งเดียว จากนั้นจึงเพิ่มวงจรที่สองสำหรับงานที่แตกต่างกัน ติดตามอัตราความล้มเหลวจริงของแต่ละวงจรเมื่อเวลาผ่านไป ไม่ใช่แค่ว่ามันดูเหมือนทำงานในการรันที่คุณบังเอิญสังเกต
เมื่อคุณรันหลายวงจรพร้อมกัน ให้คิดอย่างจริงจังเกี่ยวกับแดชบอร์ดค่าใช้จ่ายร่วมในทุกวงจร ไม่ใช่การติดตามต่อวงจรแยกกัน วงจรเดียวที่มีงบประมาณต่องานที่สมเหตุสมผลดูดีโดยสิ้นเชิงเมื่อแยกออกมา สิบวงจรแต่ละวงจรอยู่ในงบประมาณแยกกันยังสามารถรวมเป็นยอดรวมที่น่าตกใจอย่างแท้จริงที่ไม่มีใครสังเกตจนกว่าบิลรวมจะมาถึง แน่นอนเพราะการติดตามแต่ละวงจรดูดีในตัวเอง
นิสัยเดียวที่ป้องกันปัญหาการปรับขนาดก่อนที่มันจะเริ่ม: บันทึกทุกการกระตุ้นเงื่อนไขหยุดในทุกวงจร ไม่ใช่แค่ความสำเร็จที่สมบูรณ์ วงจรที่ชนเพดานการวนซ้ำสูงสุดและส่งต่อไปยังมนุษย์กำลังทำสิ่งที่มันควรจะทำ แต่ถ้าวงจรเฉพาะหนึ่งชนเพดานนั้นอย่างต่อเนื่องในขณะที่วงจรอื่นไม่ค่อยทำ นั่นเป็นสัญญาณว่ามาตรฐานของผู้ตัดสินสำหรับงานนั้นถูกปรับเทียบผิด เข้มงวดเกินไปที่จะผ่านจริง หรือตรวจสอบกับความจริงพื้นฐานที่ผิดทั้งหมด รูปแบบนั้นมองไม่เห็นถ้าคุณติดตามเฉพาะความสำเร็จและปฏิบัติต่อการส่งต่อทุกครั้งเป็นเหตุการณ์ที่แยกเดี่ยวและไม่น่าสังเกต แทนที่จะเป็นจุดข้อมูลเกี่ยวกับการออกแบบของวงจรนั้น
จะเริ่มต้นที่ไหนในสัปดาห์นี้
อย่าพยายามสร้างระบบการแก้ไขตัวเองที่ครอบคลุมทั่วไปในความพยายามครั้งแรก เลือกงานเฉพาะที่แคบและกำหนดไว้อย่างดีหนึ่งงานที่คุณทำเป็นประจำอยู่แล้ว บางสิ่งที่มีมาตรฐานชัดเจนที่คุณสามารถเขียนลงไปถ้าถูกถาม และสร้างวงจรสามบทบาทรอบงานเดียวนั้นก่อน
เขียนรายการตรวจสอบของผู้ตัดสินลงไปอย่างชัดเจนก่อนที่คุณจะเขียนพรอมต์ผู้สร้างแม้แต่บรรทัดเดียว มาตรฐานที่คุณตรวจสอบเทียบควรกำหนดสิ่งที่คุณขอให้ผู้สร้างผลิต ไม่ใช่กลับกัน ถ้าคุณยังเขียนรายการตรวจสอบไม่ได้ แสดงว่าคุณยังไม่รู้ดีพอว่า "ถูกต้อง" หมายถึงอะไรสำหรับงานนี้ในการตรวจสอบอัตโนมัติ และนั่นคุ้มค่าที่จะค้นพบก่อนที่คุณจะสร้างอะไร
รันการทดสอบความเครียดสี่อย่างข้างต้นก่อนที่คุณจะไว้วางใจวงจรกับสิ่งที่มีความสำคัญจริงๆ ไม่ใช่หลังจากที่มีอะไรผิดพลาดไปแล้วต่อหน้าใครบางคน เพิ่มเงื่อนไขหยุดเป็นตรรกะที่แข็งและจริงตั้งแต่เวอร์ชันแรก ไม่ใช่สิ่งที่คิดภายหลังเมื่อคุณถูกวงจรที่หนีไม่พ้นเผาแล้วครั้งหนึ่ง
เมื่อวงจรหนึ่งเชื่อถือได้จริงๆ รันโดยไม่มีใครดูแล จับข้อผิดพลาดจริง หยุดอย่างสะอาดเมื่อควร วงจรที่สองจะเร็วขึ้นมาก ไม่ใช่เพราะพรอมต์ถ่ายโอนโดยตรง โดยปกติแล้วต้องเขียนใหม่สำหรับงานใหม่ แต่เพราะคุณเข้าใจรูปร่างที่แท้จริงของปัญหาแล้ว แยกการสร้างออกจากการตัดสิน ให้การตัดสินมีบางสิ่งที่จริงเพื่อตรวจสอบ เขียนเงื่อนไขหยุดเป็นตรรกะ ไม่ใช่ความหวัง
รูปร่างนั้นคือวินัยทั้งหมด ทุกอย่างอื่นเป็นเพียงการนำไปใช้กับงานที่อยู่ตรงหน้าคุณ
ติดตาม @cyrilXBT สำหรับเทมเพลตวงจรที่แน่นอนและการตั้งค่าผู้สร้าง-ผู้ตัดสิน-ผู้จัดการที่อยู่เบื้องหลังทุกสิ่งในบทความนี้
