7 คะแนน โดย davespark 2026-02-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

อดีตวิศวกร Facebook Christopher Chedeau (Vjeux) ทำการทดลองพอร์ตเอนจินการต่อสู้ของ Pokemon Showdown (TypeScript ราว 100,000 บรรทัด) ไปเป็น Rust โดยใช้ Claude Code

เป้าหมายของโปรเจ็กต์

  • สร้างออราเคิลความเร็วสูง (ระบบอ้างอิง) สำหรับฝึก AI การต่อสู้ของ Pokemon
  • อิมพลีเมนเทชัน TypeScript เดิม → ช้าเกินไป (ไม่สามารถจำลองการต่อสู้ได้หลายล้านครั้ง)
  • ภาษาเป้าหมาย: Rust (ประสิทธิภาพสูง) → แต่เจ้าตัวมีประสบการณ์ Rust เป็นศูนย์

ผลลัพธ์สำคัญ

  • พอร์ตเสร็จราว 100,000 บรรทัดภายใน 1 เดือน (เวลาทำงานจริงประมาณ 2~4 สัปดาห์)
  • สร้างคอมมิตประมาณ 5,000 ครั้ง
  • ความเร็วในการทำงานเพิ่มขึ้น 3.5 เท่า
  • ผลการทดสอบแบบเปรียบเทียบให้ความสอดคล้อง 99.96% (อิงจากการต่อสู้แบบสุ่ม 2 ล้านครั้ง)
    • อีก 0.04% ที่เหลือคาดว่าเป็นบั๊กในโค้ด TS ต้นฉบับ

กลยุทธ์หลักที่ทำให้สำเร็จ

  • นำ differential testing มาใช้
    • รันต้นฉบับ TS เทียบกับเวอร์ชัน Rust พร้อมกัน → เปรียบเทียบผลลัพธ์
    • เคสที่ผลไม่ตรงกัน → แสดงล็อกให้ Claude ดูแล้วสั่งให้แก้ไข
  • ทำให้ตรวจสอบได้แม้แทบไม่รู้ไวยากรณ์ Rust

ปัญหาหลักที่ Claude เจอ

  • พอร์ตไฟล์เดี่ยวทำได้ดี ↔ แต่มีปัญหาบ่อยในการ รวมข้ามไฟล์
    • เช่น นิยามแนวคิดเดียวกัน (move) เป็นคนละ struct
  • ข้อจำกัดของ context window → ระหว่างสรุประหว่างทาง ข้อมูลสำคัญบางส่วนหายไป
  • มีแนวโน้มจะทำให้ “ดีขึ้น” → เพิกเฉยต่อคำสั่งแบบชัดเจนว่าให้ “พอร์ตทีละบรรทัด” แล้วพยายามรีแฟกเตอร์ → สร้างบั๊กจำนวนมาก
  • คำขอให้ optimize → แผนดูดีมาก แต่แทบไม่ช่วยเรื่องประสิทธิภาพจริง (บางส่วนกลับช้าลง)

การแฮ็กเวิร์กโฟลว์แบบแปลก ๆ

  • ทำให้คำขออนุมัติจากผู้ใช้ของ Claude เป็นอัตโนมัติ
    • ใช้ AppleScript กด Enter อัตโนมัติทุกไม่กี่วินาที → รันแบบไร้คนเฝ้าได้ 24 ชั่วโมง
    • (มีความเสี่ยงด้านความปลอดภัย แต่ยอมรับได้เพราะเป็นออราเคิลแบบใช้ครั้งเดียว)

สถานะปัจจุบันของเครื่องมือเขียนโค้ด AI (การประเมิน)

  • งานแปลงเชิงกลและการพอร์ตโค้ดจำนวนมาก → ทรงพลังมาก
  • งานระดับสูงอย่างการ optimize ประสิทธิภาพหรือออกแบบสถาปัตยกรรม → ยังไม่ดีพอ
  • ข้อถกเถียงใน Hacker News
    • ฝ่ายสงสัย: บำรุงรักษาไม่ได้ เป็นโค้ดที่ “แค่คอมไพล์ผ่าน”
    • ฝ่ายสนับสนุน: differential testing ทำให้น่าเชื่อถือได้เพียงพอ + ประหยัดเวลาได้มากกว่ามนุษย์อย่างชัดเจน

บทเรียนสำหรับการนำไปใช้จริง 3 ข้อ

  • ต้องมี ระบบทดสอบอัตโนมัติ ที่เข้มงวด (ถ้าไม่มี differential testing โอกาสล้มเหลวสูงมาก)
  • คำสั่งที่ ชัดเจนและมีขอบเขตแคบ ได้ผลดีที่สุด (“พอร์ตทีละบรรทัด” O vs “ช่วยปรับปรุงให้หน่อย” X)
  • AI เป็นเพียง เครื่องมือ → นักพัฒนายังต้องวินิจฉัยปัญหา ออกแบบคำถาม และคุมทิศทางอยู่ดี

→ นี่คือตัวอย่างที่คนซึ่งไม่รู้ Rust เลยสามารถย้ายโค้ดระดับ 100,000 บรรทัดไปสู่ระดับใช้งานได้ภายในหนึ่งเดือน → เป็นทั้งกรณีพิสูจน์ ความใช้งานได้จริงของ AI coding และในขณะเดียวกันก็เป็นการทดลองตัวแทนที่เผยให้เห็น ข้อจำกัดอย่างชัดเจน

https://aisparkup.com/posts/8701

1 ความคิดเห็น

 
ahwjdekf 2026-02-03

นี่มองข้ามไปว่าการเขียน test case ไม่ได้เป็นยาวิเศษสำหรับทุกอย่าง แค่ input กับ output ทำงานปกติไม่ใช่ทั้งหมด สุดท้ายก็ต้องกลับไปรีวิวโค้ดทั้ง 100,000 บรรทัดอีกอยู่ดี