.NET ที่อยู่มายาวนาน
การเขียนโปรแกรม
รองรับ AST และสัญลักษณ์

การรองรับ C# ใน Maguyva: รีแฟกเตอร์ที่ปลอดภัยขึ้นสำหรับโค้ดเบส .NET

Maguyva รองรับ C# ด้วยการแยกวิเคราะห์ AST และการดึงสัญลักษณ์ เพื่อให้เอเจนต์ AI ทำงานข้าม service ของ .NET, ลอจิกทางธุรกิจที่หนัก LINQ, ไลบรารีที่ใช้ร่วมกัน และรีโพซิทอรีระดับองค์กรที่อยู่มานาน

เริ่มต้นใช้งานฟรี เริ่มต้นใช้งานด่วน รายละเอียดความเข้ากันได้

ภาพรวมการรองรับ

ระดับ

AST + สัญลักษณ์

นามสกุลไฟล์

.cs, .csx

ความหมายคือ

การแยกวิเคราะห์ AST จริงสำหรับการค้นหาที่รู้จักไวยากรณ์และบริบทเชิงโครงสร้าง

สัญลักษณ์ที่มีชื่อป้อนข้อมูลให้การค้นหาเชิงความหมายและการอ้างอิงไขว้ การนำทางกราฟจะใช้งานได้เมื่อเปิดใช้การสกัดความสัมพันธ์

ภาษานี้ส่งสัญลักษณ์และความสัมพันธ์ไปยังการค้นหาแบบรู้บริบทกราฟ โดยประเภทเอดจ์ที่รองรับจะแตกต่างกันตามโครงสร้างเฉพาะของภาษา

รองรับทั้งการแยกวิเคราะห์ AST และการสกัดสัญลักษณ์

สิ่งที่สำคัญในโค้ดเบส .NET ที่เติบโตเต็มที่

ทีมจำนวนมากที่ใช้เครื่องมือ AI อยู่ใน .NET ไม่ใช่ JavaScript แบบกรีนฟิลด์ พวกเขามี API, โปรเซส worker, โมเดลที่ใช้ร่วมกัน, ไลบรารีภายใน และลอจิกทางธุรกิจที่สะสมมาหลายปี คำถามไม่ใช่ว่า LLM จะเขียนไวยากรณ์ C# ได้หรือไม่ แต่เป็นว่ามันจะอ้างอิงโค้ดจริงได้อย่างถูกต้องภายในรีโพซิทอรีที่การแก้ไขผิดจุดเดียวอาจกระเพื่อมไปทั่ว service, model และแอบสแตรกชันที่ใช้ร่วมกันได้หรือไม่

นั่นคือเหตุผลที่หน้า C# ต้องเจาะจงกว่าคำว่า “รองรับ”

สิ่งที่ Maguyva ดึงออกมาจริงใน C#

Maguyva ทำให้การ import using เป็นมาตรฐานเดียวกัน ตัดส่วนต่อท้ายแบบ nullable และอาร์เรย์ เช่น ? และ [] ออกจากคำนิยาม และถือว่า call node ที่คล้ายคอนสตรักเตอร์เป็นการสร้างอินสแตนซ์ พร้อมตัดวงเล็บเจเนริกออก รายละเอียดเหล่านี้มีประโยชน์ในรีโพ C# ที่มีคลาสจำนวนมาก เพราะทำให้กราฟสะอาดขึ้นรอบๆ ชนิดข้อมูลโดเมนจริง

การตั้งค่ายังกรองสัญญาณรบกวนจาก BCL และ LINQ ออกไปจำนวนมาก สิ่งนี้สำคัญกว่าที่ฟังดู ในโค้ดเบส .NET ที่เติบโตเต็มที่ กราฟที่ถูกครอบงำโดยการเรียกเฟรมเวิร์กนั้นไม่ค่อยมีประโยชน์ กราฟที่มีประโยชน์คือกราฟที่ controller, service, DTO และคลาสตัวช่วยเฉพาะของรีโพยังโดดเด่นออกมา

เวิร์กโฟลว์ MCP ที่มีประโยชน์สำหรับโค้ดเบส .NET

โฟลว์ที่ใช้ได้จริงมักเริ่มด้วย:

find_symbol เมื่อคุณรู้ชื่อ controller, service, DTO หรือ model
dependency_search ก่อนแก้ไข service ที่ใช้ร่วมกันหรือ type ที่อาจถูกโค้ดส่วนอื่นเรียกใช้ในวงกว้าง
get_task_context สำหรับคำสั่งอย่าง “ตามรอยคำขอนี้จาก controller ไปยัง repository” เมื่อเส้นทางพาดผ่านหลายเลเยอร์

เมื่อใดที่หน้านี้มีประโยชน์

หน้านี้เหมาะกับทีมที่ต้องการความช่วยเหลือจาก AI ภายในโค้ดเบส .NET จริง ไม่ใช่แค่โปรเจกต์ทดลอง หากระบบโดยรอบเน้น JVM มากกว่า .NET ให้เทียบกับ Java หากชั้น C# ของคุณเป็นเพียงส่วนหนึ่งของระบบหลายภาษาที่ใหญ่กว่า หน้า TypeScript ที่อยู่ใกล้เคียงก็มักจะเกี่ยวข้องด้วย

เหมาะที่สุดสำหรับ

> รีโพซิทอรีของ ASP.NET, worker-service และแพลตฟอร์มภายในที่ผสม web endpoint, job และไลบรารีที่ใช้ร่วมกันเข้าด้วยกัน
> ทีมที่ดูแลระบบ .NET ที่เติบโตเต็มที่ ซึ่ง LINQ, async flow และแอบสแตรกชันของเฟรมเวิร์กซ่อนเส้นทางการทำงานจริงไว้
> ทีมที่ทดสอบว่าเอเจนต์สามารถยึดโยงกับความจริงในโค้ด .NET แบบเป็นชั้นได้หรือไม่ ก่อนเขียนลอจิกทางธุรกิจใหม่

เวิร์กโฟลว์ของเอเจนต์

> ตามรอย controller, service และ repository ก่อนแก้ไขลอจิกทางธุรกิจ
> ตรวจสอบว่า model, DTO หรือยูทิลิตี้ที่ใช้ร่วมกันถูกสร้างอินสแตนซ์ที่ไหนบ้างทั่วทั้งรีโพ
> ทำความเข้าใจรูปแบบ LINQ หรือ async โดยรอบก่อนปล่อยให้เอเจนต์เขียนใหม่

รายละเอียดเอนจิน

> คำนำหน้า `using` ถูกปรับให้เป็นมาตรฐานในการ import และส่วนต่อท้าย nullable หรืออาร์เรย์ เช่น `?` และ `[]` ถูกตัดออกจากนิยามสัญลักษณ์
> การสร้างอินสแตนซ์ใช้โหนดการเรียกที่ตัดวงเล็บเจเนริกออก ซึ่งช่วยให้การใช้งานแบบคอนสตรักเตอร์อ่านง่ายในกราฟ
> การตั้งค่ากรองสัญญาณรบกวนจาก BCL และ LINQ ออกเป็นจำนวนมากอย่างชัดเจน ทำให้เซอร์วิสและโมเดลเฉพาะของรีโพปรากฏขึ้นง่ายกว่า

จุดเริ่มต้น MCP ที่มีประโยชน์

find_symbol
ใช้เมื่อคุณรู้ชื่อ controller เซอร์วิส DTO หรือชนิดข้อมูลที่ใช้ร่วมกันที่กำลังจะแตะต้อง
dependency_search
ใช้การไล่แบบ incoming ก่อนแก้ไขเซอร์วิสหรือโมเดลหลักที่ใช้ทั่วทั้งแอปพลิเคชัน
get_task_context
มีประโยชน์สำหรับพรอมป์อย่าง “ตามรอยคำขอนี้จาก controller ไปยัง repository” ในโค้ดเบส .NET แบบแบ่งชั้น