ข้ามไปที่เนื้อหา
cd /languages
.NET ที่อยู่มายาวนานการเขียนโปรแกรมรองรับกราฟแบบเต็มรูปแบบ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • find_symbol

    ใช้เมื่อคุณรู้ชื่อ controller เซอร์วิส DTO หรือชนิดข้อมูลที่ใช้ร่วมกันที่กำลังจะแตะต้อง

  • dependency_search

    ใช้การไล่แบบ incoming ก่อนแก้ไขเซอร์วิสหรือโมเดลหลักที่ใช้ทั่วทั้งแอปพลิเคชัน

  • get_task_context

    มีประโยชน์สำหรับพรอมป์อย่าง “ตามรอยคำขอนี้จาก controller ไปยัง repository” ในโค้ดเบส .NET แบบแบ่งชั้น

คู่มือที่เกี่ยวข้อง

พื้นผิวรีโปที่ใกล้เคียงกัน

ดูคู่มือทั้งหมด