TL;DR: เราได้ทดสอบโมเดลการเขียนโค้ด AI หลักทุกโมเดลในโลกจริงMercury Technology Solutionsงานพัฒนา — ฟรอนต์เอนด์และแบ็คเอนด์ การจัดอันดับ: Fable > Kimi K3 > Claude Opus 4.8 > Grok 4.5 > Codex 5.5 > Kimi 2.7 > Claude Opus 4.6 > GLM 5.2 > MiniMax.Fable ชนะ ไม่ใช่เพราะมันเป็นโมเดลที่ใหญ่ที่สุด แต่เพราะมันเข้าใจว่า "เสร็จสิ้น" เป็นอย่างไร.
เจมส์ที่นี่ ซีอีโอของ Mercury Technology Solutions. จากสำนักงานของฉันใน Cyberport, ฮ่องกง — 17 กรกฎาคม 2026
ฉันใช้เวลาสองสัปดาห์ที่ผ่านมาในการทำสิ่งที่ฉันควรทำไปนานแล้ว: ทดสอบโมเดล AI การเขียนโค้ดหลักทุกตัวกับงานจริง
ไม่ใช่การวัดผล ไม่ใช่ LeetCode ไม่ใช่ "เขียนฟังก์ชัน Python เพื่อเรียงลำดับรายการ" งานจริง คอมโพเนนต์ React ที่ต้องจัดการกับกรณีขอบ จุดสิ้นสุด API ที่ต้องรวมกับบริการของบุคคลที่สาม การโยกย้ายฐานข้อมูลที่ไม่สามารถสูญเสียข้อมูลได้ สิ่งที่จริงๆ แล้วเกิดปัญหาในผลิต
นี่คือสิ่งที่เราได้เรียนรู้
ระเบียบวิธี: ไม่มีการวัดผล แค่การต่อสู้
เราให้โมเดลแต่ละตัวทำงานเดียวกัน:
1. ด้านหน้า:สร้างแดชบอร์ดที่ตอบสนองได้พร้อมการแสดงผลข้อมูลแบบเรียลไทม์ การจัดการข้อผิดพลาด และการปฏิบัติตามมาตรฐานการเข้าถึง
2. ด้านหลัง:ออกแบบ API ที่มีการจำกัดอัตราการเข้าถึงพร้อมการตรวจสอบสิทธิ์ การแคช และการลดความสามารถอย่างมีระเบียบภายใต้ภาระงาน
3. การรวมระบบ:เชื่อมต่อทั้งสองด้วยประเภท TypeScript ที่เหมาะสม ขอบเขตข้อผิดพลาด และสถานะการโหลด
ไม่มีการช่วยเหลือ ไม่มีการกระตุ้น "คิดทีละขั้นตอน" เพียงแค่สเปคที่วิศวกรอาวุโสจะได้รับในเช้าวันจันทร์
เราทำคะแนนในสี่มิติ:
• ความถูกต้อง: มันทำงานได้โดยไม่มีข้อบกพร่องหรือไม่?
• ความสมบูรณ์: มันจัดการกับกรณีขอบหรือแค่เส้นทางที่ดีหรือไม่?
• ความสามารถในการบำรุงรักษา:วิศวกรคนอื่นสามารถอ่านและแก้ไขสิ่งนี้ได้ในหกเดือนหรือไม่?
• ความเร็ว:ใช้เวลานานแค่ไหนจากคำสั่งไปยังโค้ดที่สามารถส่งได้?
การจัดอันดับ: อะไรชนะและทำไม
1. Fable — ม้าดำที่ทำให้ "เสร็จ"
Fable อยู่ในอันดับต้น ๆ ของรายการของเรา และพูดตามตรง ฉันไม่เห็นสิ่งนี้มาก่อน มันไม่ใช่โมเดลที่ได้รับการโปรโมทมากที่สุด มันไม่มีจำนวนพารามิเตอร์ที่มากที่สุด แต่สิ่งที่ Fable ทำได้ดีกว่าใคร ๆ คือ:มันเข้าใจความแตกต่างระหว่าง "โค้ดที่คอมไพล์ได้" และ "โค้ดที่ส่งออกได้."
ในงานด้านหน้าของเรา Fable สร้างขอบเขตข้อผิดพลาดโดยไม่ถูกขอ มันเพิ่มโครงกระดูกการโหลด มันรวมป้าย ARIA ที่เหมาะสมสำหรับโปรแกรมอ่านหน้าจอ เมื่อเราขอให้ทำด้านหลัง มันสร้างการจำกัดอัตราด้วยเบรกเกอร์วงจรและกลยุทธ์สำรองสำหรับเมื่อแคชล้มเหลว.
นี่คือโมเดลที่คิดเหมือนวิศวกรอาวุโส ไม่ใช่ระดับจูเนียร์ที่เพิ่งเรียนรู้ไวยากรณ์.
ความเร็วก็ไร้สาระเช่นกัน Fable ทำงานชุดสามงานของเราเสร็จใน 12 นาที คนถัดไปที่เร็วที่สุดคือ Kimi K3 ที่ 18 นาที.
ทำไม Fable ถึงชนะ: มันสร้างโค้ดที่พร้อมสำหรับการผลิต ไม่ใช่โค้ดสาธิต ไม่ใช่โค้ดสอน โค้ดที่จัดการกับกรณีขอบที่คุณคิดถึงหลังจากการหยุดทำงานในผลิตภัณฑ์ครั้งแรกของคุณ.
2. Kimi K3 — ม้าทำงานที่เชื่อถือได้
Kimi K3 คือโมเดลที่ฉันไว้วางใจสำหรับโค้ดการผลิต มันไม่ "ฉลาด" เท่า Fable — มันจะไม่ทำให้คุณประหลาดใจกับวิธีแก้ปัญหาที่สวยงามที่คุณไม่เคยคิดถึง แต่ก็จะไม่ทำให้คุณประหลาดใจกับข้อบกพร่องเช่นกัน.
หน้าต่างบริบท 1M คือฟีเจอร์ที่โดดเด่นจริงๆ เราได้ป้อนโค้ดทั้งหมดของเรา (47K บรรทัด) และขอให้มันเพิ่มฟีเจอร์ มันเข้าใจรูปแบบ ปฏิบัติตามข้อตกลง และสร้างโค้ดที่ดูเหมือนเขียนโดยทีมของเรา.
จุดเด่นของ Kimi K3: งานที่มีบริบทยาว การปรับปรุงโค้ดเก่า การรักษาความสอดคล้องในโครงการขนาดใหญ่ นี่คือโมเดลที่คุณต้องการเมื่อ "ทำงาน" สำคัญกว่าที่จะ "ว้าว."
การแลกเปลี่ยน:K3 ช้ากว่า Fable ในงาน greenfield มันใช้เวลาในการอ่านบริบท เข้าใจรูปแบบ และสร้างโค้ดที่เหมาะสม แต่เวลานั้นคุ้มค่าเมื่อคุณไม่ต้องแก้ไขข้อผิดพลาดในการรวมระบบที่ลึกลับสามวันต่อมา.
3. Claude Opus 4.8 — นักทฤษฎี
Opus 4.8 เป็นโมเดลที่ฉลาดที่สุดในห้อง มันจะอธิบายทำไมสถาปัตยกรรมของคุณถึงผิด แนะนำทางเลือกที่ดีกว่าสามทาง และเขียนเอกสารขาวเกี่ยวกับการแลกเปลี่ยน มันยังเป็นโมเดลที่มีแนวโน้มจะออกแบบระบบ CRUD ที่เรียบง่ายให้กลายเป็นระบบกระจายที่มีการจัดเก็บเหตุการณ์.
ปัญหา Opus:มันคิดมากเกินไป เมื่อได้รับงานที่ควรใช้เวลา 30 นาที Opus 4.8 จะใช้เวลา 20 นาทีในการจัดทำเอกสารการออกแบบ 15 นาทีในการดำเนินการ และจากนั้นแนะนำให้คุณปรับโครงสร้างโค้ดทั้งหมดให้ตรงกับรูปแบบใหม่.
เมื่อคุณต้องการการวิเคราะห์เชิงลึก — อัลกอริธึมที่ซับซ้อน การตัดสินใจด้านสถาปัตยกรรม การวิเคราะห์ความปลอดภัย — Opus 4.8 ไม่มีใครเทียบได้ เมื่อคุณต้องการส่งงานภายในวันศุกร์ มันเป็นภาระ.
ตรวจสอบความเป็นจริงของค่าใช้จ่าย: Opus 4.8 มีราคาแพง เช่น "อาจจะต้องจ้างวิศวกรอีกคน" แพง ที่ $65.75 ต่อ 1000 งานในกระดานผู้นำ Aider มันเป็นเครื่องมือระดับพรีเมียมสำหรับปัญหาระดับพรีเมียม.
4. Grok 4.5 — ปีศาจความเร็วพร้อมข้อควรระวัง
Grok 4.5 เร็วมาก เช่น, จริงๆ เร็ว มันสร้างงานส่วนหน้าของเราในเวลาไม่ถึง 8 นาที โค้ดทำงานได้ มันดูดี.
แต่เมื่อเราทดสอบความเครียดที่ส่วนหลัง — โดยการส่งคำขอพร้อมกัน, จำลองการล้มเหลวของแคช, ทดสอบกรณีขอบ — โค้ดของ Grok เริ่มแตก มันจัดการเส้นทางที่ดีได้อย่างสวยงาม เส้นทางที่ไม่ดี? ไม่ค่อย.
Grok เป็นโมเดลสำหรับการสร้างต้นแบบ ไม่ใช่การผลิต.หากคุณต้องการตรวจสอบแนวคิดในช่วงบ่าย Grok จะช่วยให้คุณทำได้ หากคุณต้องการนอนหลับอย่างสบายใจโดยรู้ว่า API ของคุณจะไม่ล้มเหลวในเวลา 3 โมงเช้า ให้มองหาที่อื่น
ปัจจัย xAI:การรวมกันของ Grok กับข้อมูล X/Twitter ทำให้มันมีข้อได้เปรียบในด้านบริบทแบบเรียลไทม์ แต่สำหรับการเขียนโค้ดล้วน ๆ ข้อได้เปรียบนี้ไม่ได้แปลเป็นคุณภาพโค้ดที่ดีกว่า
5. Codex 5.5 — ผู้เชี่ยวชาญ
Codex 5.5 คือสิ่งที่เกิดขึ้นเมื่อคุณปรับแต่งโมเดลสำหรับสิ่งหนึ่งและสิ่งเดียวเท่านั้น: การสร้างโค้ด มันคือโค้ดเดอร์ที่ดีที่สุดในรายการนี้ ไวยากรณ์สมบูรณ์แบบ รูปแบบเป็นแบบอิดิโอมาติก ชื่อของตัวแปรมีความหมายจริง ๆ
แต่ถามมันว่าทำไมมันถึงเลือกวิธีการเฉพาะ หรือพิจารณาผลกระทบทางธุรกิจของการตัดสินใจทางเทคนิค และมันจะเงียบไป Codex เขียนโค้ด มันไม่คิดเกี่ยวกับโค้ด
ใช้ Codex เมื่อ: คุณรู้ว่าคุณต้องการอะไรและแค่ต้องการให้มันพิมพ์อย่างรวดเร็ว มันคือการเติมคำอัตโนมัติที่แพงที่สุดในโลก — และบางครั้ง นั่นคือสิ่งที่คุณต้องการจริงๆ
ระบบนิเวศของ OpenAI: Codex 5.5 ส่องแสงเมื่อคุณอยู่ในสแต็กของ OpenAI แล้ว การรวมเข้ากับ ChatGPT ความคุ้นเคยกับผลลัพธ์แบบ GPT API ที่สอดคล้องกัน — มันเป็นทางเลือกที่สะดวกสบาย ไม่ใช่ทางเลือกที่กล้าหาญ
6. Kimi 2.7 — นักเก่าที่แข็งแกร่ง
Kimi 2.7 คือโมเดลที่เราใช้ก่อนที่ K3 จะมี มันเชื่อถือได้ สม่ำเสมอ และคาดการณ์ได้ มันจะไม่ทำให้คุณตะลึง แต่ก็จะไม่ทำให้โค้ดของคุณพังเช่นกัน
การประเมินอย่างตรงไปตรงมา: หากคุณเข้าถึง K3 ได้ ไม่มีเหตุผลที่จะใช้ 2.7 หน้าต่างบริบทเพียงอย่างเดียว (256K เทียบกับ 1M) ทำให้ K3 เป็นเครื่องมือในหมวดหมู่ที่แตกต่าง แต่สำหรับทีมที่อยู่ในแผนเก่าหรือมีการรวมระบบเก่า 2.7 ยังคงเป็นวิศวกรที่มีความสามารถอย่างสมบูรณ์
ราคาเหมาะสม: ที่ $1.24 ต่อ 1000 งานในกระดานผู้นำ Aider, Kimi 2.7 เป็นแชมป์งบประมาณ มันไม่ใช่สิ่งที่ดีที่สุด แต่เป็นสิ่งที่ดีที่สุด ค่าใช้จ่าย สำหรับทีมที่ไม่ต้องการเทคโนโลยีล้ำสมัย.
7. Claude Opus 4.6 — รุ่นก่อนหน้า
Opus 4.6 รู้สึกเหมือนเป็นการพรีวิวความยอดเยี่ยมของ 4.8 โดยไม่มีการปรับปรุง มันมีแนวโน้มที่จะคิดมากเกินไป แต่มีความแม่นยำน้อยกว่า ความทะเยอทะยานทางสถาปัตยกรรมเดียวกัน แต่มีข้อบกพร่องมากกว่า.
ข้ามไป. หากคุณอยู่ในระบบนิเวศของ Anthropic ให้ไปที่ 4.8 โดยตรง ช่องว่างระหว่าง 4.6 และ 4.8 ไม่ใช่การพัฒนาแบบค่อยเป็นค่อยไป — มันเป็นรุ่นโมเดลที่แตกต่าง.
8. GLM 5.2 — ผู้แข่งขันระดับภูมิภาค
GLM 5.2 เป็นโมเดลที่ดีที่สุดที่คุณไม่เคยได้ยินมาก่อน — เว้นแต่คุณจะอยู่ในประเทศจีน มันจัดการกับความต้องการด้านภาษาจีนของเราได้ดีกว่าโมเดลตะวันตกใด ๆ และความเข้าใจในระบบนิเวศ API ท้องถิ่น (WeChat, Alipay, DingTalk) นั้นน่าประทับใจจริง ๆ
แต่สำหรับการพัฒนาแบบทั่วไปล่ะ? มันก็ใช้ได้ ไม่ดี ไม่เลว มันทำงานได้ แต่ก็ระมัดระวัง มันจะไม่แนะนำรูปแบบสมัยใหม่ มันจะไม่ปรับให้เหมาะสมกับประสิทธิภาพ มันจะให้คุณมีวิธีแก้ปัญหาที่คอมไพล์และรันได้ ในปี 2022
มุมมองของ Zhipu AI: GLM ได้รับการสนับสนุนโดย Zhipu AI ซึ่งเป็นหนึ่งในห้องปฏิบัติการ LLM ชั้นนำของจีน สำหรับทีมที่สร้างสรรค์สำหรับตลาดจีน ความตระหนักในวัฒนธรรมและกฎระเบียบของ GLM เป็นข้อได้เปรียบที่แท้จริง สำหรับคนอื่น ๆ มันเป็นเรื่องน่าสนใจ
9. MiniMax — งานที่กำลังดำเนินการ
MiniMax ตกอยู่ที่ก้นของรายการของเรา และฉันรู้สึกไม่ดีเกี่ยวกับเรื่องนี้เพราะทีมงานชัดเจนว่ากำลังพยายาม แต่การพยายามไม่ใช่การส่งมอบ
โค้ดที่สร้างขึ้นนั้น... ใช้งานได้ มันถูกคอมไพล์ มันทำงานได้ แต่พลาดกรณีขอบที่โมเดลอื่นๆ จับได้ การจัดการข้อผิดพลาดนั้นน้อยมาก ประเภท TypeScript นั้นหลวม เมื่อเราขอให้มันปรับปรุงเพื่อประสิทธิภาพ มันทำให้โค้ดช้าลง
MiniMax อาจจะไปถึงจุดนั้นแต่ตอนนี้มันยังไม่พร้อมสำหรับการพัฒนาในระดับการผลิต
ภูมิทัศน์ LLM ของจีน:MiniMax เป็นส่วนหนึ่งของสนามที่แออัดซึ่งรวมถึง Qwen, DeepSeek, และ GLM ในบริษัทนั้น มันกำลังดิ้นรนเพื่อแยกแยะ ความแตกต่างของคุณภาพโค้ดระหว่าง MiniMax และ DeepSeek-V3.2 (74.2% บน Aider) ชัดเจนมาก
รูปแบบที่ไม่มีใครพูดถึง
นี่คือสิ่งที่ทำให้ฉันประหลาดใจมากที่สุด: โมเดลที่ดีที่สุดไม่ใช่โมเดลที่ใหญ่ที่สุด
Fable ไม่ได้ทำงานด้วยจำนวนพารามิเตอร์ที่มากที่สุด Kimi K3 ไม่ใช่ตัวเลือกที่แพงที่สุดในการดำเนินงาน แต่ทั้งสองเข้าใจสิ่งที่โมเดลที่ใหญ่กว่าพลาดไป:การจัดส่งเป็นกรอบความคิด ไม่ใช่ความสามารถ
โมเดลที่ติดอันดับในรายการของเราแชร์ลักษณะร่วมกันอย่างหนึ่ง: พวกเขาสร้างโค้ดราวกับว่ามีคนอื่นต้องดูแลมัน พวกเขาเพิ่มความคิดเห็น พวกเขาจัดการกับข้อผิดพลาด พวกเขาคิดเกี่ยวกับกรณีขอบที่ปรากฏขึ้นเฉพาะในเวลา 2 โมงเช้าในวันเสาร์
โมเดลที่ล้มเหลว? พวกเขาสร้างโค้ดเหมือนการสัมภาษณ์การเขียนโค้ด — แก้ปัญหา ผ่านการทดสอบ แล้วไปต่อ นั่นไม่ใช่วิธีที่ซอฟต์แวร์ทำงาน นั่นคือวิธีที่ซอฟต์แวร์พัง
**หลักการจัดส่ง:** โค้ดที่ดีที่สุดไม่ใช่โค้ดที่ฉลาดที่สุด แต่มันคือโค้ดที่ยังมีความหมายเมื่อผู้เขียนต้นฉบับอยู่ในวันหยุดและฐานข้อมูลในระบบกำลังลุกไหม้
สิ่งที่การวัดผลบอก (และทำไมเราถึงมองข้ามมัน)
ฉันได้กล่าวถึงว่าเราไม่ได้ใช้การวัดผล แต่ฉันได้ตรวจสอบหลังจากการทดสอบของเราเพื่อดูว่าประสบการณ์ของเราตรงกับข้อมูลในลีดเดอร์บอร์ดหรือไม่
ลีดเดอร์บอร์ด Aider LLM (aider.chat/docs/leaderboards) เล่าเรื่องราวที่น่าสนใจ:
| โมเดล | คะแนน Aider | ต้นทุนต่อ 1K งาน | สไตล์ | |-------|-------------|-------------------|-------| | GPT-5 (สูง) | 88.0% | $29.08 | diff | | o3-pro (สูง) | 84.9% | $146.32 | diff | | Gemini 2.5 Pro (32k คิด) | 83.1% | $49.88 | diff-fenced | | Grok 4 (สูง) | 79.6% | $59.62 | diff | | DeepSeek-V3.2-Exp | 74.2% | $1.30 | diff | | Claude Opus 4 (32k คิด) | 72.0% | $65.75 | diff | | Kimi K2 | 59.1% | $1.24 | diff | | Grok 3 Beta | 53.3% | $11.03 | diff | | GPT-4.1 | 52.4% | $9.86 | diff | | Claude 3.5 Sonnet | 51.6% | $14.41 | diff |
รูปแบบ: โมเดลที่มีราคาสูงที่สุด (o3-pro ที่ $146.32, Opus 4 ที่ $65.75) ไม่รับประกันผลลัพธ์ที่ดีที่สุด GPT-5 ที่ $29.08 ทำได้ดีกว่าทั้งคู่ DeepSeek ที่ $1.30 ส่งมอบ 74.2% — เกือบจะตรงกับ 72.0% ของ Opus 4 ที่ต้นทุน 1/50.
ประสบการณ์ของเราตรงกับสิ่งนี้. Fable และ Kimi K3 ไม่ใช่โมเดลที่มีราคาสูงที่สุดที่เราทดสอบ แต่พวกเขาคือโมเดลที่ส่งมอบโค้ดที่สามารถส่งได้อย่างสม่ำเสมอ.
สิ่งนี้หมายถึงอะไรสำหรับทีมของคุณ
หากคุณกำลังสร้างซอฟต์แวร์ในปี 2026 นี่คือคำแนะนำของฉัน:
1. ใช้ Fable สำหรับโครงการ greenfield.เมื่อคุณเริ่มต้นจากศูนย์และต้องการเคลื่อนที่อย่างรวดเร็วโดยไม่ทำลายทุกอย่าง สัญชาตญาณ "วิศวกรอาวุโส" ของ Fable ไม่มีใครเทียบได้
2. ใช้ Kimi K3 สำหรับงานที่เป็นมรดกหน้าต่างบริบท 1M หมายความว่ามันสามารถเข้าใจฐานรหัสที่มีอยู่ของคุณจริง ๆ ไม่ใช่แค่สร้างรหัสใหม่ที่ไม่สนใจแนวทางของคุณ
3. ใช้ Opus 4.8 สำหรับการตัดสินใจด้านสถาปัตยกรรมเมื่อคุณออกแบบระบบที่ต้องการขยาย เมื่อความปลอดภัยมีความสำคัญ เมื่อคุณกำลังทำการเดิมพันทางเทคนิคมูลค่าหลายล้านดอลลาร์ — ความลึกของ Opus คุ้มค่ากับการคิดมากเกินไป
4. หยุดใช้ทุกอย่างอื่นสำหรับการผลิตGrok สำหรับต้นแบบ Codex สำหรับการเติมอัตโนมัติ แต่ไม่ควรส่งรหัสของพวกเขาให้ผู้ใช้โดยไม่ผ่านการตรวจสอบอย่างจริงจัง
5. พิจารณาสมการต้นทุนที่ Mercury เราใช้โมเดลหลายตัวพร้อมกันสำหรับงานที่สำคัญ ค่าใช้จ่ายในการใช้ Kimi K3 ($1.24/1K งาน) เทียบกับ Opus 4.8 ($65.75/1K งาน) หมายความว่าเราสามารถทำซ้ำได้มากขึ้นถึง 50 เท่าสำหรับงบประมาณเดียวกัน นั่นไม่ใช่แค่ถูกกว่า — แต่มันเร็วกว่า
ภาพรวมที่ใหญ่กว่า
เรากำลังเฝ้าดูการทำให้การเขียนโค้ดเป็นสินค้าในเวลาจริง ช่องว่างระหว่าง "ฉันสามารถเขียนโค้ดได้" และ "ฉันสามารถส่งผลิตภัณฑ์ได้" กำลังหายไป ผู้สร้างคนเดียวที่ใช้ Fable หรือ Kimi K3 สามารถทำสิ่งที่เคยต้องการทีมงานห้าคน
แต่มีสิ่งหนึ่งที่ต้องพูดถึง:โมเดลกำลังเก่งขึ้นในการเขียนโค้ดเร็วกว่าที่วิศวกรส่วนใหญ่จะเก่งขึ้นในการใช้งานมัน
วิศวกรที่ประสบความสำเร็จในปี 2026 ไม่ใช่คนที่เขียนบรรทัดมากที่สุด แต่เป็นคนที่ตั้งคำถามที่ถูกต้อง ตรวจสอบโค้ดที่สร้างขึ้นอย่างมีวิจารณญาณ และรู้ว่าเมื่อใดควรยอมรับข้อเสนอของ AI และเมื่อใดควรข้ามมัน
โมเดลคือเครื่องมือ การตัดสินใจยังคงเป็นของคุณ
หรืออย่างที่ Yang Wen-li จะพูดว่า: "วิธีที่มีประสิทธิภาพที่สุดในการชนะคือการทำให้ศัตรูสูญเสียความตั้งใจที่จะต่อสู้" ในปี 2026 ศัตรูคือความซับซ้อน โมเดลที่ชนะคือโมเดลที่ทำให้ความซับซ้อนสามารถจัดการได้
โซลูชันเทคโนโลยีของเมอร์คิวรี: เร่งความเป็นดิจิทัล.
