การพัฒนาตนเองเชิงเวียนซ้ำของภาษา: กรินด์ Code Intelligence ครอบคลุมเกือบ 280 ภาษา

ตัวเลขในบทความนี้สะท้อนระบบ ณ วันที่เผยแพร่ (พฤษภาคม 2026) ดูหน้าทีมของเราสำหรับตัวเลขปัจจุบัน

Maguyva ดึง symbol การอ้างอิง และ dependency กราฟ จากซอร์สโค้ดในราว 280 ภาษา แต่ละภาษาคือตัวจัดการ tree-sitter กำหนดเอง — คิวรี ฮิวริสติก กรณีขอบ — และแต่ละตัวจัดการสามารถผิดพลาดในแบบที่ละเอียดอ่อนของตัวเองได้ การเรียกเมธอดที่ถูกปล่อยออกมาเป็นการอ่าน ฟังก์ชันที่ถูกระบุว่าเป็นของขอบเขตที่ห่อหุ้มผิด ความสัมพันธ์ที่ไม่มีอยู่จริงเลย

คุณตรวจสอบด้วยมือไม่ได้ ไม่มีทีมไหนอ่านผลการแตกโครงสร้างข้าม 280 ไวยากรณ์แล้วจับ edge ที่ไม่ดีได้ ดังนั้นคำถามที่น่าสนใจไม่ใช่ “การแตกโครงสร้างของเราถูกต้องหรือไม่” — แต่เป็น “คุณจะ ค้นพบ ว่ามันผิดได้อย่างไร ในระดับความกว้างนี้ โดยไม่มีมนุษย์อยู่ในทุกลูป” คำตอบของเราคือการพัฒนาตนเองเชิงเวียนซ้ำของภาษา: ลูปคุณภาพที่ขับเคลื่อนโดย agent ประจำภาษา, LLM ที่ทำหน้าที่เป็นผู้ตัดสิน และกฎหนึ่งข้อที่เรายังคงเรียนรู้ซ้ำแล้วซ้ำเล่า: เขียวไม่เท่ากับถูกต้อง

เขียวไม่ใช่ถูกต้อง

ทุกภาษามีชุด fixture และเกณฑ์การปล่อยใช้งานให้คะแนนมันครอบคลุมห้ามิติ — ความแม่นยำ, ความสมบูรณ์เชิงโครงสร้าง, ความครบถ้วน, คุณภาพ และประสิทธิภาพ ภาษาหนึ่งจะเป็น สีเขียว (GREEN) ก็ต่อเมื่อ บน fixture ของมัน precision ≥ 0.95, recall ≥ 0.99 และ F1 ≥ 0.97 พร้อม edge ที่คาดหวังอย่างน้อย 20 edge เพื่อความเชื่อมั่นทางสถิติ ต่ำกว่านั้นคือ YELLOW หรือ RED และมันจะไม่ถูกปล่อยออกมา

เกณฑ์นั้นจำเป็นแต่ไม่เพียงพอ fixture ตรวจสอบกับ fixture ที่เราเขียนเอง มันเข้ารหัสกรณีที่เราคิดไว้แล้ว ตัวจัดการหนึ่งอาจไร้ที่ติบน fixture ของมัน แต่ยังคงบิดเบือนรูปแบบที่ปรากฏเฉพาะในโค้ดจริง — สำนวนแมโคร เมธอดที่ผูกกับเจเนอริก ฟีเจอร์ภาษาที่ไม่มีใครเขียน fixture ให้ GREEN หมายความว่า fixture ผ่าน มันไม่ได้หมายความว่า repository จริงจะแตกโครงสร้างได้สะอาด ดังนั้นลูปนี้ต้องละทิ้ง fixture แล้วมองไปที่โลกจริง

ลูปด้านใน: สุ่มตรวจ ตัดสิน แก้ไข พิสูจน์

ลูปหลักรันทีละภาษา:

        ┌──────────────────────────────────────────────────────────┐
        │                                                          │
        ▼                                                          │
  1. corpus run ── clone real-world repos, extract relationships   │
        │                                                          │
        ▼                                                          │
  2. spot-check 100 edges (seed 42, then seed 123 to cross-check)  │
        │                                                          │
        ▼                                                          │
  3. LLM judge classifies every sampled edge:                      │
        CORRECT · FALSE_POSITIVE · TYPE_ERROR ·                    │
        SCOPE_ERROR · METADATA_ERROR                               │
        │                                                          │
        ▼                                                          │
  4. fix ONE thing — handler .py, .scm query, or config           │
        │                                                          │
        ▼                                                          │
  5. re-validate — F1 + re-classify + manifest diff (no regressions)│
        │                                                          │
   better? ──no──► revert, try a different fix ────────────────────┤
        │ yes                                                       │
        ▼                                                           │
  6. promote the fix into fixtures (a permanent regression guard) ──┘

มีไม่กี่อย่างที่ทำให้สิ่งนี้ทำงานได้จริง แทนที่จะดิ้นอยู่กับที่

ผู้ตัดสินคือ agent เอง ไม่ใช่การเรียก API เมื่อเราพูดว่า “LLM เป็นผู้ตัดสิน” เราหมายถึง agent ประจำภาษาเองอ่าน edge ที่สุ่มมาแต่ละตัวเทียบกับซอร์สจริง แล้วจำแนกมันด้วยหลักเกณฑ์การตัดสินห้าประเภทที่ตายตัว: edge นี้ถูกต้องหรือไม่ เป็นผลบวกลวง เป็นความสัมพันธ์ที่ถูกต้องแต่ประเภทผิด ผูกกับขอบเขตผิด หรือพก metadata ผิด หลักเกณฑ์การตัดสินนั้นคือทั้งหมดของเกม — “อัตราความผิดพลาด 23%” ไม่มีความหมายจนกว่าคุณจะรู้ว่านั่นคือข้อบกพร่องจริงหรือผู้ตัดสินนับผิด

แก้ไขทีละอย่าง แล้วพิสูจน์มัน แต่ละรอบเปลี่ยนแปลงทรัพยากรที่แก้ไขได้เพียงหนึ่งชิ้นแม่นยำ แล้วรันซ้ำกับชุดทดสอบที่ตายตัว และเก็บการเปลี่ยนแปลงไว้ก็ต่อเมื่อ F1 ดีขึ้นและการจำแนกซ้ำดูดีขึ้น ถ้าไม่ มันจะถูกย้อนกลับ ไม่มีชุดการแก้ไขแบบเดาสุ่ม ไม่มี “น่าจะดีขึ้น” การเปลี่ยนแปลงต้องพิสูจน์คุณค่าของมันเอง ไม่เช่นนั้นก็หายไป และเมื่อการแก้ไขติดตั้งอยู่ได้ มันจะถูกเลื่อนขึ้นเข้าสู่ชุด fixture — เพื่อให้ bug ที่มันแก้ไม่สามารถกลับมาเงียบๆ ได้อีก ขั้นตอนการเลื่อนขึ้นนั้นคือสิ่งที่ทำให้ลูปนี้ เวียนซ้ำ แทนที่จะเป็นแค่การทำซ้ำ: ทุกรอบจะทำให้มาตรฐานอ้างอิงที่รอบถัดไปใช้ตรวจสอบแข็งแกร่งขึ้น

บทเรียนที่เรายังคงเรียนรู้ซ้ำ: เมตริกรายงานเกินจริง

นี่คือกับดัก และเราเดินเข้าไปตรงๆ เมตริกคลังข้อมูลรอง — ความถี่ที่เป้าหมายที่ถูกดึงออกมาไม่มี symbol ที่แก้ไขได้ symbol กี่ตัวดู “กำพร้า” และอื่นๆ — รายงานปัญหาเกินจริงอย่างมาก ส่วนใหญ่เป็น สิ่งประดิษฐ์ของกระบวนทัศน์ ไม่ใช่ bug

ตัวอย่างที่ชัดที่สุด: llvm เคยแสดงอัตรา “ซอร์สที่ไม่มี symbol” ที่ 73% และถูกตราหน้าว่าเลวร้าย เราเจาะลึกเข้าไป ความแม่นยำจริง คือ 98.5% “symbol ที่หายไป” เกือบทั้งหมดเป็นการอ้างอิงภายนอกที่ถูกต้องตามกฎหมาย — การเรียกเข้าไลบรารีมาตรฐาน เข้าเฟรมเวิร์ก เข้าโค้ดที่อยู่นอก repo เมตริกนั้นกำลังวัดคุณสมบัติของภาษา ไม่ใช่ข้อบกพร่องในตัวจัดการ ภาษาอย่าง Zig, COBOL และ Odin แสดงอัตรา “กำพร้า” 65–70% และถูกต้องทั้งหมด COBOL มีความผิดพลาดจริงเป็นศูนย์

หากเราปล่อยให้ตัวเลขเหล่านั้นขับเคลื่อนงาน เราคงใช้เวลาหลายสัปดาห์ “แก้ไข” ตัวจัดการที่ถูกต้องอยู่แล้ว และมองข้ามภาษาที่มี bug จริงแบบเงียบๆ บทสรุปนั้นตรงไปตรงมา: เมตริกรวมเป็นสัญญาณคัดกรองคร่าวๆ อย่างดีที่สุด สัญญาณคุณภาพจริงคือการสุ่มตรวจพร้อมการจำแนก edge — การมอง edge จริงใน repository จริง และตัดสินทีละตัว ข้อมูลเหนือสัญชาตญาณ แต่ก็ต่อเมื่อคุณรู้แล้วว่าข้อมูลไหนบอกความจริง

ลูปด้านนอก: ทีมงาน ไม่ใช่มาราธอน

ทีละภาษาจะใช้เวลานานมากข้าม 280 ภาษา ดังนั้นลูปด้านในจึงถูกห่อด้วยลูปด้านนอกที่รันหลายภาษาพร้อมกัน

   pick a wave of near-GREEN / high-error languages
        │
        ▼
   fan out 10–15 agents, each ISOLATED in its own git worktree,
   each grinding ONE language, committing to its own branch
        │
        ▼
   orchestrator integrates serially: file-scoped apply, then
   `manifest diff` — any cross-language regression blocks the batch
        │
        ▼
   gated push (reviewed and confirmed) ──► rotate to the next wave

แต่ละ agent ทำงานใน worktree แบบใช้แล้วทิ้งเพื่อไม่ให้เหยียบกันเอง ออร์เคสเตรเตอร์รวมการแก้ไขของพวกมันทีละอย่าง แต่ละครั้งอยู่หลังการตรวจสอบการถดถอยแบบ full-manifest: การเปลี่ยนแปลงที่ช่วยภาษาของตัวเองแต่แอบทำลายอีกสามภาษาจะไม่ถูกรวมเข้ามา การรวมเข้ามาถูกควบคุม และยืนยันก่อนที่อะไรจะถูก push — เกณฑ์การถดถอยตัดสินว่าอะไร ปลอดภัย มนุษย์ยังคงตัดสินว่าอะไร ถูกปล่อยออกมา จากนั้น pool จะหมุนไปยังชุดภาษาถัดไป และทั้งหมดก็รันอีกครั้ง

สิ่งที่ยังไม่สมบูรณ์แบบ

ผู้ตัดสินสามารถผิดพลาดได้ และความผิดพลาดนั้นมีทิศทาง: agent ที่รันด้วยบริบทน้อยเกินไป รายงานเกินจริง ในชุดหนึ่ง ภาษาแปดภาษาถูกตั้งค่าสถานะ ที่ความผิดพลาด 5–20% เมื่อตรวจสอบ มีเพียงหนึ่งภาษาที่เป็น bug จริงเฉพาะภาษา — ที่เหลือเป็นความผิดพลาดของผู้ตัดสินจากการพลาด semantic เฉพาะของภาษานั้น (บรรทัดซอร์สหนึ่งบรรทัดปล่อย edge หลายตัวอย่างถูกต้องตามกฎหมาย, การผูกพารามิเตอร์ถูกจำลองเป็นการกำหนดค่า, ภาษาที่มีการอ้างอิงต่อหนึ่งตัวระบุ) นั่นคือเหตุผลที่เราสุ่มด้วยสองซีดแล้วตรวจไขว้ และเหตุผลที่ความไม่ลงรอยกันระหว่างผู้ตัดสินกับ fixture ถูกมองว่าเป็นสัญญาณที่ น่าสนใจที่สุด ไม่ใช่คำตัดสินที่ยุติแล้ว — บางครั้ง fixture ต่างหากที่เป็นสิ่งที่ผิด

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

ได้มา ไม่ใช่แค่กล่าวอ้าง

ทุกสิ่งที่ Maguyva ทำให้ agent — การหา symbol, การตามรอย dependency, การตอบคำถามพร้อมโค้ดที่อ้างอิงได้ — ล้วนพึ่งพาการแตกโครงสร้าง ที่อยู่ข้างล่างว่าถูกต้อง ข้าม 280 ภาษา คำว่า “ถูกต้อง” ไม่สามารถกล่าวอ้างได้ มันต้อง ได้มา อย่างต่อเนื่องจากโค้ดจริง ลูปนี้คือวิธีที่เราได้มันมา: วงจรสุ่มตรวจและแก้ไขแบบอัตโนมัติ ที่ปฏิบัติต่อเมตริกของตัวเองด้วยความสงสัย พิสูจน์ทุกการเปลี่ยนแปลง และเปลี่ยนทุกการแก้ไขให้เป็นเครื่องป้องกันการถดถอยครั้งถัดไป มันไม่ใช่เรื่องหรูหรา มันคืองานที่ทำให้เราพูดได้ว่า “เรารองรับภาษาของคุณ” และหมายความอย่างนั้นจริงๆ เขียวนั้นง่าย ถูกต้องนั้นต้องได้มา