Opus 4.8 + Kimi Agent Swarm: วิธีที่ผมลดค่าใช้จ่ายในการเขียนโค้ดจาก 4,000 ดอลลาร์ เหลือ 700 ดอลลาร์ต่อเดือน

ฉันได้ทดสอบ Kimi K2.6's Agent Swarm และ Claude Opus 4.8's Dynamic Workflows ควบคู่กันในงานโปรดักชันเป็นเวลาสองสัปดาห์ สิ่งที่น่าสนใจไม่ใช่ "อันไหนดีกว่า" เพราะทั้งคู่ทำคะแนนบน SWE-Bench ใกล้เคียงกัน (80.2 vs 80.8) สิ่งที่น่าสนใจคือจุดอ่อนของพวกมันตรงกันข้ามกันโดยสิ้นเชิง และนั่นทำให้การนำทั้งสองมาใช้ร่วมกันสร้างสิ่งที่แต่ละตัวทำคนเดียวไม่ได้

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

แนวคิดหลักในหนึ่งประโยค

Kimi swarm กว้างและถูก Opus 4.8 ลึกและแพง ดังนั้นคุณให้ swarm สร้างทุกตัวเลือกที่เป็นไปได้ แล้วใช้ Opus เพื่อกำจัดตัวเลือกที่ผิดพลาดอย่างเข้มงวดเท่านั้น

เหตุผลที่วิธีนี้ใช้ได้ผลโดยเฉพาะ:

Kimi swarm สามารถสร้าง sub-agent ได้มากถึง 300 ตัวที่แยกย่อยงานด้วยตัวเอง: ไม่ต้องใช้ LangGraph, ไม่ต้องใช้ CrewAI, ไม่ต้องเขียน workflow ด้วยมือ มันถูกสร้างไว้ในโมเดลแล้ว มันเร็วกว่าประมาณ 4.5 เท่าในงานที่กว้าง และมีต้นทุนประมาณ $0.60/M ขาเข้า, $2.50/M ขาออก โดยการแคชช่วยลดต้นทุนได้ 75-83% คุณสามารถปล่อยให้มันทำงานแบบสิ้นเปลืองได้

จุดอ่อนที่รู้กัน: ถ้าคุณไม่ระบุให้ตรวจสอบอย่างชัดเจน มันจะสร้างข้อมูลที่อ้างอิงน้อยเกินไป มั่นใจเกินจริง และ sub-agent ขัดแย้งกันเอง

Opus 4.8 ทำตรงกันข้าม Dynamic Workflows ของมันเขียนสคริปต์การทำงาน เรียกใช้ sub-agent ที่โจมตีปัญหาจากมุมมองที่แตกต่างกัน จากนั้น deploy adversarial agents ที่มีหน้าที่เดียวคือหักล้างสิ่งที่ค้นพบ และวนซ้ำจนกว่าคำตอบจะสอดคล้องกัน มันเป็น Claude ตัวแรกที่ได้คะแนน 0% ในการรายงานผลลัพธ์ที่ผิดพลาดโดยไม่ตรวจสอบ ซึ่งมั่นใจเกินจริงน้อยกว่า 4.7 ประมาณ 10 เท่า

ต้นทุนของมัน: การรันครั้งเดียวสามารถสร้าง agent ได้มากถึง 1,000 ตัว ดังนั้นคุณไม่ต้องการให้มันทำงานค้นหาแบบกว้าง คุณต้องการให้มันทำงานกำจัดข้อผิดพลาด

คำถามที่ทุกคนถามคือคำถามที่ผิด

"ฉันควรใช้โมเดลไหน?" ฟังดูเหมือนคำถามที่ฉลาด แต่มันไม่ใช่

มันสันนิษฐานอย่างเงียบๆ ว่าคุณต้องแต่งงานกับโมเดลหนึ่งและหย่ากับอีกโมเดลหนึ่ง ซึ่งคุณไม่จำเป็นต้องทำ

ผู้สร้างที่ส่งงานมากที่สุดในปี 2026 หยุดคิดเกี่ยวกับโมเดลและเริ่มคิดเกี่ยวกับบทบาท นักเขียนไม่ต้องเลือกระหว่างเครื่องพิมพ์ดีดกับบรรณาธิการ พวกเขาใช้ทั้งสองอย่าง ในเวลาที่ต่างกัน สำหรับงานที่ต่างกัน

นั่นคือความลับทั้งหมด งั้นให้ฉันแนะนำสองบทบาทนี้

พบกับเครื่องยนต์: ทำไม Kimi K2.6 ถึงเปลี่ยนสมการอย่างเงียบๆ

ถ้า workflow นี้มีดาวเด่น มันคือ Kimi และยิ่งคุณดูตัวเลขมากเท่าไหร่ มันก็ยิ่งรู้สึกเหมือนรหัสโกงมากกว่าการอัปเกรด

ราคาแทบไม่รู้สึกเลย อย่างเป็นทางการ $0.95 ต่อล้าน input tokens และ $4.00 ต่อล้าน output tokens ซึ่งถูกกว่าประมาณ 5 เท่าตอนเข้าและ 6 เท่าตอนออกเมื่อเทียบกับระดับพรีเมียม มีแม้กระทั่งวิธีเริ่มต้นฟรี: คุณสามารถใช้มันบน kimi.com วันนี้ และใช้เครดิตฟรีรายวันผ่าน Cloudflare Workers AI เมื่อต้นทุนในการลองอะไรสักอย่างลดลงขนาดนี้ คุณจะหยุดกั๊กไอเดียของคุณ คุณแค่ลงมือทำ

มันไม่เหนื่อย และมันไม่ทำงานคนเดียว นี่คือส่วนที่คนส่วนใหญ่ยังมองข้าม Kimi's Agent Swarm สามารถสร้าง sub-agent เฉพาะทางได้มากถึง 300 ตัวและประสานงานพวกมันในประมาณ 4,000 ขั้นตอนในการรันอัตโนมัติครั้งเดียว มากกว่าสามเท่าของเวอร์ชันก่อนหน้า ผู้ช่วยอื่นๆ ทุกตัวเป็นคนงานคนเดียวที่ทำงานทีละอย่าง Kimi คือผู้ประสานงานที่ส่งชิ้นส่วนให้คนงานหลายสิบหรือหลายร้อยคนพร้อมกัน จากนั้นรวมผลลัพธ์

นี่คือสิ่งที่เกิดขึ้นเมื่อคุณปล่อยมันทำงาน:

• ผู้คนสร้างผลงานเทียบเท่าเอเจนซี่ขนาดเล็กได้ในเวลาไม่ถึงชั่วโมง: ค้นหาธุรกิจท้องถิ่นที่มีเว็บไซต์ไม่ดี, สร้างร่างหน้า Landing Page สำหรับแต่ละแห่ง, เขียนอีเมลติดต่อ, และผลิตรายงานตลาด จากข้อมูลสั้นๆ เพียงชุดเดียว
• นักพัฒนาดึงข้อมูลที่ตรวจสอบแล้วหลายพันแถวลงในสเปรดชีตที่สะอาดภายในช่วงบ่าย โดยแต่ละแถวตรวจสอบกับแหล่งข้อมูลจริง ซึ่งเป็นงานที่ agent ตัวเดียวใช้เวลาเกือบทั้งวัน
• ในการรันที่มีการแชร์กันอย่างแพร่หลายครั้งหนึ่ง Kimi ถูกชี้ไปที่โมเดลขนาดเล็กบนแล็ปท็อปและบอกให้ทำให้เร็วขึ้น มันทำงานโดยไม่มีคนดูแลเป็นเวลา 12 ชั่วโมง, โทรหาเครื่องมือมากกว่าพันครั้ง, เขียนโค้ดใหม่หลายพันบรรทัด, และเพิ่มปริมาณงานจากประมาณ 15 tokens ต่อวินาทีเป็นเกือบ 200 tokens โดยไม่มีมนุษย์อยู่ในวงจร มีแค่เป้าหมาย

มันเป็น open-weight ด้วย ปล่อยภายใต้สัญญาอนุญาต MIT ที่แก้ไขแล้ว พร้อม CLI คู่หูที่นักพัฒนาหลายพันคนบน GitHub กดติดตาม คุณไม่ได้เช่าเข้าถึงกล่องดำ คุณกำลังยืนอยู่บนสิ่งที่คุณสามารถตรวจสอบ โฮสต์ และสร้างต่อได้

Kimi คือห้องเครื่องยนต์ มันทำงานหนัก มันรัน swarm มันเปลี่ยน "ฉันหวังว่าจะลองสักสิบเวอร์ชัน" เป็น "ฉันลองสิบเวอร์ชันก่อนเที่ยงแล้ว"

แต่เครื่องยนต์ที่ไม่มีคนบังคับก็แค่วิ่งเร็วไปผิดทาง ซึ่งเป็นจุดที่บทบาทที่สองเข้ามาพอดี

พบกับผู้ปิดดีล: จุดที่ Opus 4.8 แสดงคุณค่า

ถ้า Kimi ทำงานหนัก Opus 4.8 ก็จับข้อผิดพลาด

หัวข้อข่าวของ Anthropic สำหรับการเปิดตัวครั้งนี้ไม่ใช่ benchmark มันคือความซื่อสัตย์ Opus 4.8 มีรายงานว่ามีโอกาสน้อยกว่ารุ่นก่อนหน้าประมาณสี่เท่าที่จะปล่อยให้ข้อบกพร่องในโค้ดของตัวเองผ่านไปโดยไม่ถูกตรวจจับ มัน bluff น้อยลง และมันบอกได้เร็วกว่าเมื่อ "ส่วนนี้ไม่แน่นอน"

คุณลักษณะเดียวนั้นมีค่ามหาศาลภายใน workflow ที่มีปริมาณงานสูง เมื่อ swarm ผลิตงานออกมาเป็นภูเขา คุณไม่ต้องการผู้สร้างที่ไม่รู้จักเหน็ดเหนื่อยอีกคน คุณต้องการสายตาที่เฉียบคมและขี้สงสัยที่จะบอกความจริงกับคุณ Opus ยังมักจะชนะในสิ่งที่คุณต้องการความมั่นใจมากที่สุด: ความแม่นยำระดับโปรดักชัน และการอ่านเอกสารและภาพที่มีความเที่ยงตรงสูง

มันนำการตัดสินใจมาใช้ในส่วนหน้าของกระบวนการด้วย ซึ่งเป็นส่วนที่การตัดสินใจทางสถาปัตยกรรมที่ดีครั้งเดียวช่วยประหยัดเวลาทำงานผิดทางได้สิบชั่วโมง หน้าต่างบริบทที่ใหญ่มากหมายความว่ามันสามารถเก็บปัญหาทั้งหมดไว้ในหัวก่อนที่จะเขียนโค้ดแม้แต่บรรทัดเดียว

มันคือผู้ตรวจสอบอาวุโส สถาปนิก คนที่คุณไว้ใจให้มองทุกสิ่งที่เครื่องยนต์ผลิตออกมาแล้วพูดอย่างใจเย็นว่า "ส่งอันนี้ แต่แก้ไขอันนั้นก่อน"

การเปรียบเทียบแบบตัวต่อตัว: Opus 4.8 vs Kimi K2.6

นี่คือส่วนที่ทุกคนต้องการและแทบไม่มีใครเขียนอย่างซื่อสัตย์

Anthropic ทำให้ Opus 4.8 ก้าวขึ้นมาจริงๆ: การตัดสินใจที่เฉียบคมขึ้น, โมเดลที่ซื่อสัตย์ที่สุดที่พวกเขาทำ, และคะแนนสูงสุดในการทดสอบการเขียนโค้ดและการใช้เหตุผลที่ยากที่สุด งานที่ยอดเยี่ยมอย่างแท้จริง

และควบคู่กันไป Kimi K2.6 ก็ทำบางอย่างที่เถียงได้ยากอย่างเงียบๆ agent ของมันทำงานจริงแบบเดียวกัน ส่งมอบผลลัพธ์ที่ไม่ได้แย่กว่าอย่างมีนัยสำคัญในงานส่วนใหญ่ และทำได้ด้วยเงินที่น้อยกว่าหลายเท่า ในสิ่งที่คนส่วนใหญ่ส่งงานจริงในชีวิตประจำวัน ช่องว่างของผลลัพธ์นั้นเล็กและช่องว่างของราคานั้นใหญ่

นี่คือการเปรียบเทียบทั้งสองแบบทีละจุด:

• ราคาต่อ token. Opus 4.8 อยู่ที่ $5 ต่อล้าน input และ $25 ต่อล้าน output Kimi K2.6 อยู่ที่ $0.95 ต่อล้าน input และ $4.00 ต่อล้าน output ถูกกว่าประมาณ 5 ถึง 6 เท่าในทุกด้าน

• น้ำหนักโมเดล. Kimi เป็น open-source ภายใต้สัญญาอนุญาต MIT ที่แก้ไขแล้ว ดังนั้นคุณสามารถโฮสต์เองได้ Opus เป็น proprietary

• ขนาดและบริบท. Kimi เป็นโมเดล 1 ล้านล้านพารามิเตอร์ที่มีหน้าต่างบริบท 256K Opus มีหน้าต่างบริบท 1M

• Agent. จุดเด่นของ Kimi คือ swarm: sub-agent มากถึง 300 ตัวที่ประสานงานกันประมาณ 4,000 ขั้นตอนในการรันอัตโนมัติครั้งเดียว Opus รัน sub-agent แบบขนานผ่าน Dynamic Workflows
• อินพุตที่รองรับ. Kimi รับข้อความ รูปภาพ และวิดีโอ Opus รับข้อความและรูปภาพ
• การทดสอบโค้ดที่ยากที่สุด (SWE-bench Verified). ทั้งคู่ทำคะแนนสูง Kimi อยู่ประมาณช่วงต้น 80, Opus สูงกว่าเล็กน้อยในช่วงปลาย 80
• สิ่งที่แต่ละตัวทำได้ดีที่สุด. Kimi: ต้นทุน, ปริมาณงานแบบขนาน, และการเปิดกว้าง Opus: ความซื่อสัตย์, การตัดสินใจ, และความแม่นยำ

อ่านอย่างซื่อสัตย์แล้วบทเรียนไม่ใช่ "Kimi ชนะ" หรือ "Opus ชนะ" มันคือพวกเขาชนะในสิ่งที่แตกต่างกัน ตัวหนึ่งคือเครื่องมือวัดความแม่นยำที่คุณหยิบใช้เมื่อความถูกต้องแม่นยำสำคัญที่สุด อีกตัวคือเครื่องยนต์ที่ทำงานหนัก รัน swarm และแทบไม่แตะงบประมาณของคุณ ซึ่งเป็นเหตุผลว่าทำไมการเคลื่อนไหวที่ฉลาดไม่ใช่การเลือกข้าง แต่คือการวางแต่ละตัวในจุดที่มันแข็งแกร่งที่สุด

Workflow: วางแผน, Swarm, ตัดสิน, ส่งงาน

นี่คือส่วนที่ควรบันทึกไว้ สี่จังหวะ สองโมเดล การส่งต่อที่สะอาด

1. วางแผนด้วย Opus 4.8 (การคิด).

อธิบายปัญหาทั้งหมดให้ Opus ฟังและขอให้มันออกแบบสถาปัตยกรรม ไม่ใช่ลงมือทำ โครงสร้างคืออะไร ความเสี่ยงคืออะไร เส้นทางที่สะอาดที่สุดคืออะไร จากนั้นขอสิ่งเฉพาะอย่างหนึ่ง: spec ที่เป็นลายลักษณ์อักษร (เพิ่มเติมว่าทำไมถึงสำคัญในอีกสักครู่) คุณจ่าย tokens ระดับพรีเมียมที่นี่โดยตั้งใจ นี่คือชั่วโมงที่ถูกที่สุดที่คุณจะเคยซื้อ เพราะมันป้องกันข้อผิดพลาดที่มีราคาแพง

2. Swarm ด้วย Kimi K2.6 (การลงมือทำ).

ส่ง spec ให้ Kimi และปล่อยให้เครื่องยนต์ทำงาน นี่คือที่มาของปริมาณงาน: สร้างโค้ด, เขียนเทส, ร่างรูปแบบต่างๆ, ทำการสร้างซ้ำๆ ข้ามไฟล์ ปล่อยให้ swarm ทำการทำงานที่ซ้ำซากแบบขนาน เพราะมันถูกมาก คุณไม่กลัวที่จะทิ้งความพยายามครั้งแรกแล้วรันใหม่ ขั้นตอนนี้ทำงาน 80% ของงานด้วยต้นทุนเพียงเศษเสี้ยว

3. ตัดสินด้วย Opus 4.8 (ผู้บอกความจริง).

ป้อนทุกอย่างที่ swarm ผลิตกลับไปให้ Opus และถามคำถามที่สำคัญ: มีอะไรผิดปกติกับสิ่งนี้? นี่คือจุดที่ความซื่อสัตย์ของมันจ่ายคืนให้ตัวเอง มันจับข้อบกพร่องที่เงียบ, ข้อสันนิษฐานที่ไม่ได้รับการสนับสนุน, สิ่งที่ดูเหมือนถูกต้องแต่ไม่ใช่ คุณไม่ได้จ่ายราคาพรีเมียมเพื่อสร้าง คุณจ่ายเพื่อตรวจสอบ ซึ่งเป็นวิธีใช้ tokens ราคาแพงที่มี leverage สูงที่สุด

4. ส่งงานกลับไปที่ Kimi K2.6 (การวนซ้ำ).

นำบันทึกของ Opus ส่งให้ Kimi และปล่อยให้เครื่องยนต์แก้ไขและขัดเกลาด้วยต้นทุนเกือบเป็นศูนย์ จากนั้นส่งงาน และเนื่องจากการวนซ้ำมีต้นทุนถูกมากในฝั่ง Kimi คุณสามารถรันมันอีกครั้งพรุ่งนี้ และมะรืนนี้ โดยไม่ต้องดูมิเตอร์

วางแผนกับสถาปนิก สร้างด้วยเครื่องยนต์ ตัดสินด้วยผู้บอกความจริง ส่งงานด้วยเครื่องยนต์ ทำซ้ำ

กุญแจสำคัญที่แท้จริง: เขียน Spec ไม่ใช่ Prompt

นี่คือเคล็ดลับที่แยกคนที่ได้รับความมหัศจรรย์จาก swarm ออกจากคนที่ได้รับขยะราคาแพง

เมื่อคนส่วนใหญ่ได้ยิน "300 agents" พวกเขาจะยิง prompt บรรทัดเดียวเช่น "ขูดข้อมูลทุกศูนย์ข้อมูลในสหรัฐฯ" และคาดหวังความยอดเยี่ยม นั่นคือวิธีที่เร็วที่สุดในการเผาเครดิตและได้ขยะ

กุญแจสำคัญที่แท้จริงคือการปฏิบัติต่อ swarm เหมือนผู้รับเหมา ไม่ใช่ยักษ์ในตะเกียง แทนที่จะเป็นบรรทัดเดียว คุณให้เอกสารสองหรือสามหน้าที่กำหนดอย่างชัดเจนว่าจะรวบรวมอะไร, อะไรนับว่าใช้ได้, แหล่งข้อมูลใดที่ยอมรับได้, รูปแบบผลลัพธ์ควรเป็นอย่างไร, และจะทำอย่างไรเมื่อพบข้อมูลที่ขัดแย้งกัน คุณไม่ได้เขียน prompt คุณกำลังเขียน spec และ swarm ดำเนินการตาม spec ในขณะที่คุณไปทำอย่างอื่น

และตอนนี้สองบทบาทก็คลิกเข้าหากันอย่างสมบูรณ์แบบ: เครื่องมือที่ดีที่สุดในโลกสำหรับการเขียน spec นั้นคือโมเดลที่รอบคอบและมีวิจารณญาณของคุณ Opus 4.8 เปลี่ยนเป้าหมายที่คลุมเครือให้เป็น spec ที่แม่นยำในขั้นตอน PLAN swarm ของ Kimi ดำเนินการ spec นั้นในระดับใหญ่ในขั้นตอน SWARM นักคิดเขียนคำสั่ง กองทัพดำเนินการตาม

คนที่เรียก agent swarms ว่า "เปราะบาง" เกือบตลอดเวลาหมายถึง prompt ของพวกเขาเปราะบาง งานที่ขับเคลื่อนด้วย spec เปลี่ยนผลลัพธ์อย่างสิ้นเชิง

ขโมยโครงสร้างนี้สำหรับ spec ที่สถาปนิกของคุณเขียน:

ส่งให้เครื่องยนต์แล้วเดินออกไป

รัน Loop วันนี้: 3 Prompts ที่ควรขโมย

คุณไม่จำเป็นต้องมีโปรเจกต์ใหญ่เพื่อลองสิ่งนี้ ใช้งานใดๆ ที่คุณปกติจะโยนให้โมเดลตัวเดียว แล้วรันผ่านสาม prompts ด้านล่างนี้ กรอกข้อมูลในวงเล็บแล้วเริ่มได้เลย

Prompt A. PLAN (วางใน Opus 4.8)

1ฉันต้องการ [อธิบายเป้าหมายของคุณด้วยภาษาธรรมดา]
2อย่าสร้างอะไรเลย ทำตัวเป็นสถาปนิก
3เปลี่ยนสิ่งนี้เป็น spec ที่แม่นยำโดยใช้หัวข้อเหล่านี้ทุกประการ:
4เป้าหมาย, ขอบเขต, กฎ, แหล่งข้อมูล, ผลลัพธ์, เงื่อนไขการหยุด
5ก่อนที่คุณจะเสร็จ ให้ระบุข้อสันนิษฐานที่เสี่ยงที่สุดสองข้อในแผน

Prompt B. SWARM (วางใน Kimi K2.6)

1นี่คือ spec ดำเนินการตั้งแต่ต้นจนจบ
2ทำแบบขนาน wherever you can, then merge everything into the final OUTPUT defined below.
3อย่าถามคำถามฉันเว้นแต่ spec จะขัดแย้งกับตัวเองจริงๆ
4[วาง spec จาก Prompt A]

Prompt C. JUDGE (วางใน Opus 4.8)

1นี่คือ spec และผลลัพธ์ที่ swarm ผลิตขึ้นตาม spec
2จงสงสัย งานของคุณคือค้นหาสิ่งที่ผิด ไม่ใช่ชื่นชมมัน
3แสดงรายการข้อบกพร่องทุกอย่าง, ข้ออ้างที่ไม่ได้รับการสนับสนุน, และช่องว่างที่เงียบ, จัดอันดับตามความรุนแรง,
4จากนั้นให้รายการแก้ไขสั้นๆ ที่ฉันสามารถส่งกลับไปให้ผู้สร้างได้ทันที
5[วาง spec และผลลัพธ์]

จากนั้นนำรายการแก้ไขจาก Prompt C กลับไปที่ Kimi ปล่อยให้มันแก้ไขทุกอย่าง แล้วส่งงาน นั่นคือหนึ่งรอบเต็มของ loop และมันแทบไม่มีค่าใช้จ่ายในการรันอีกครั้ง

ตัวเลขที่ทำให้ CFO ของคุณยิ้มได้

นี่คือเหตุผลว่าทำไมสิ่งนี้ไม่ใช่แค่สวยงาม แต่ยังชัดเจนทางเศรษฐกิจ

ใน workflow แบบไร้เดียงสา คุณรันทุกอย่างด้วย tokens ระดับพรีเมียม ทุกฉบับร่างที่ทิ้ง, ทุกเทส, ทุกการทดลองที่โง่เขลา, ราคาเต็ม

ใน workflow นี้ โมเดลราคาแพงจะสัมผัสเฉพาะสองช่วงเวลาที่การตัดสินใจสำคัญจริงๆ: แผนและคำตัดสิน ทุกอย่างที่อยู่ระหว่างนั้น 80% ของปริมาณ tokens ที่เป็นแค่การทำงาน ทำงานบนโมเดลที่ราคาถูกกว่าหลายเท่า

คุณไม่ได้ลดคุณภาพ คุณกำลังลดราคาของส่วนที่ไม่เคยจำเป็นต้องแพง

นั่นคือวิธีที่ทีมต่างๆ ลดค่าใช้จ่าย AI ของพวกเขาอย่างเงียบๆ ด้วยอัตรากำไรที่มหาศาล ในขณะที่เพิ่มปริมาณงานที่พวกเขาส่ง ไม่ใช่โดยการซื้อน้อยลง แต่โดยการซื้ออย่างชาญฉลาด

ทำไมคอมโบนี้ถึงเอาชนะโมเดลใดๆ เพียงตัวเดียว

หลักการที่ลึกกว่านั้นเก่าแก่กว่า AI: ข้อได้เปรียบเชิงเปรียบเทียบ

ใช้เครื่องยนต์ที่ไม่รู้จักเหน็ดเหนื่อยและราคาถูกสำหรับปริมาณ ใช้ความคิดที่รอบคอบและระดับพรีเมียมสำหรับการตัดสินใจ อย่าให้นักคิดที่แพงที่สุดของคุณทำงานหนัก และอย่าไว้วางใจให้ผู้สร้างที่เร็วที่สุดของคุณเป็นคำพูดสุดท้าย

โมเดลเดียวบังคับให้ประนีประนอม การใช้พรีเมียมทั้งหมดเผาเงินกับงานที่ไม่จำเป็น การใช้ราคาถูกทั้งหมดเสี่ยงที่จะส่งข้อบกพร่องที่ไม่มีใครจับได้ loop สองโมเดลปฏิเสธการประนีประนอมโดยสิ้นเชิง มันได้ทั้งเศรษฐศาสตร์ของโมเดลราคาถูกและมโนธรรมของโมเดลที่รอบคอบ

นั่นไม่ใช่แฮค มันเป็นเพียงการแบ่งงานที่ดี ซึ่งในที่สุดก็มีให้ใช้ในซอฟต์แวร์

ความผิดพลาดเดียวที่ฆ่า Workflow นี้อย่างเงียบๆ

การข้ามขั้นตอน JUDGE

มันเป็นมุมที่ล่อตาล่อใจที่สุดที่จะตัด เพราะผลลัพธ์ของ swarm มักจะดูเสร็จแล้ว มันคอมไพล์ มันรัน มันรู้สึกเสร็จ

"ดูเสร็จ" กับ "ถูกต้อง" เป็นคนละโลกกัน และเหตุผลทั้งหมดที่ workflow นี้ปลอดภัยคือคุณมอบหมายให้โมเดลที่รอบคอบและซื่อสัตย์บอกความแตกต่างให้คุณ ตัดขั้นตอนนั้นเพื่อประหยัดเวลาสองสามนาที แล้วคุณจะเปลี่ยนระบบที่ยอดเยี่ยมกลับเป็นวิธีที่รวดเร็วในการส่งบั๊ก

ปริมาณราคาถูกจะเป็นพลังวิเศษต่อเมื่อมีสิ่งที่เชื่อถือได้ตรวจสอบงานเท่านั้น เก็บผู้ตัดสินไว้

บรรทัดล่าง

ในปีที่เต็มไปด้วยการโต้เถียงที่ดังขึ้นเรื่อยๆ ว่าโมเดลไหน "ดีที่สุด" ความจริงที่เงียบก็เกือบจะตลก โมเดลที่ดีที่สุดกลายเป็นสองตัว แต่ละตัวชี้ไปที่งานที่มันเกิดมาเพื่อทำ

Kimi ทำงานหนัก Opus จับข้อผิดพลาด Spec ที่ดีคือสะพานระหว่างพวกมัน

คนที่ยังเถียงกันอยู่จะเถียงกันต่อไป คุณมี workflow แล้ว

ไปสร้างสิ่งที่พวกเขาจะเขียนกระทู้ถึงในเดือนหน้า

บันทึกสิ่งนี้ 🔖