Claude Code เพิ่มการรองรับ LSP แบบเนทีฟ

 (github.com/anthropics)
18 คะแนน โดย GN⁺ 2025-12-23 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Claude Code เครื่องมือเขียนโค้ดด้วย AI ที่ทำงานบนเทอร์มินัล ได้เพิ่ม เครื่องมือ LSP (Language Server Protocol) ในเวอร์ชันล่าสุด
  • ทำให้สามารถใช้งาน ความสามารถด้าน code intelligence ระดับ IDE เช่น go-to-definition, find references และ แสดงเอกสารเมื่อโฮเวอร์ ได้
  • คำสั่ง /terminal-setup รองรับเทอร์มินัล Kitty, Alacritty, Zed, Warp อย่างเป็นทางการ
  • ในหน้าจอ /theme สามารถกด Ctrl+T เพื่อสลับเปิด/ปิด syntax highlighting ได้
  • เพิ่ม คู่มือการตั้งค่าเทอร์มินัล สำหรับกรณีที่ปุ่มลัด Alt ใช้งานไม่ได้บน macOS และปรับการแสดงปุ่มลัดบน macOS ให้ใช้ opt แทน alt เพื่อให้ตรงกับข้อความบนคีย์จริง
  • ปรับปรุงผลลัพธ์ของคำสั่ง /context โดย จัดกลุ่ม skill และ agent ตามแหล่งที่มา, จัดระเบียบตามคำสั่ง slash และ เรียงตามการใช้โทเค็น

บทความที่เกี่ยวข้อง

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

 
aqqnucs 2025-12-23

ผมเคยใช้ serena อยู่ แต่สุดท้ายก็ต้องเป็นแบบบิลต์อินนี่แหละ
 
GN⁺ 2025-12-23
ความคิดเห็นจาก Hacker News

  • ไม่เข้าใจว่าทำไม JetBrains ถึงไม่ผสาน เครื่องมือรีแฟกเตอร์ เข้ากับระบบ AI
    แม้งานง่าย ๆ อย่างการเปลี่ยนชื่อฟังก์ชัน ก็น่าจะทำได้ด้วยคอนเท็กซ์ที่เล็กกว่ามาก แทนที่จะต้องแก้หลายร้อยไฟล์
    การรองรับ LSP เป็นจุดเริ่มต้นที่ดี แต่ถ้าไม่มี ความสามารถในการแปลงโค้ด ก็ยังถือว่ายังไม่พอ
    คุณภาพ LSP ของ JetBrains เองก็ไม่ได้ดีกว่าตัวทั่วไป

    • ช่วงนี้รู้สึกว่า JetBrains เหมือนกำลังหลงทิศทาง
      ตั้งแต่เอา commit modal ออกแล้วขึ้นราคา ก็เริ่มคิดว่าจะย้ายจากที่ใช้มามากกว่า 10 ปีดีไหม
      ตัวอย่างความพลาดล่าสุดก็ดูได้จากบล็อกโพสต์นี้
    • นี่ดูเหมือน dilemma ของนักนวัตกรรม แบบคลาสสิก
      JetBrains มี PSI engine ที่เข้าใจความหมายของโค้ดได้ดีที่สุด แต่ก็ยังติดอยู่กับกระบวนทัศน์ที่คนต้องเป็นฝ่ายควบคุม IDE โดยตรง
      Claude Code หรือ Cursor มองเอดิเตอร์เป็น ผืนผ้าใบ ที่ AI ใช้งานได้อย่างอิสระ ขณะที่ JetBrains ปฏิบัติต่อ AI เหมือนปลั๊กอินแถบด้านข้างธรรมดา
      ถ้าไม่เปิดเครื่องมือรีแฟกเตอร์ภายในให้อะเจนต์ใช้ได้ แรงเสียดทานในการย้ายไป VS Code ก็จะหายไป
    • JetBrains ควรเลิกยึดติดกับ AI ของตัวเองอย่าง Junie แล้วไปโฟกัสกับการเชื่อมกับเครื่องมือที่มีฐานอยู่แล้ว
      ไม่อย่างนั้น VS Code จะกินตลาดไปหมด
    • ปัญหาคือความหยิ่งยโส
      ครั้งหนึ่งเคยมี กำแพงการเข้าสู่ตลาด ที่สูง แต่ VS Code ทำลายมันลง
      ดูเหมือนจะคาดไม่ถึงกระแสการเปลี่ยนแปลงนี้เลย และตอนนี้ก็เหมือนกำลังหลงทาง
    • Microsoft ก็ทำพลาดแบบคล้ายกัน
      ยังผสาน Roslyn กับ Copilot ได้ไม่ดี
      Roslyn analyzer ไม่ใช่แค่ลินเตอร์ธรรมดา แต่เป็นเครื่องมือทรงพลังที่ทำ code transformation ได้ด้วย การที่ AI ยังจัดการด้วยแค่ find/replace เลยทำให้น่าหงุดหงิด
      ถ้ามีเอเจนต์ที่อิง Roslyn โผล่มา ประสิทธิภาพในการทำงานกับโค้ดเบสขนาดใหญ่จะพุ่งขึ้นแบบก้าวกระโดด

  • ฉันมองบวกมากกับชุด Claude Code / Codex CLI + LSP
    สุดสัปดาห์ลองใช้ Codex แล้วรู้สึกไม่สะดวกที่เวลาย้ายสัญลักษณ์หรือเปลี่ยนชื่อฟังก์ชันมันพลาดการอ้างอิง เลยลองทำสกิลเชื่อมกับ Rope ซึ่งเป็นเครื่องมือรีแฟกเตอร์สำหรับ Python ด้วยตัวเอง
    ผลลัพธ์ค่อนข้างน่าพอใจ

    • เหมือนวิศวกร OpenAI กด ปุ่ม Copilot แทนปุ่ม F2 เลยทำให้การเปลี่ยนชื่อ reference ล้มเหลว
      การไม่มี LSP support นี่แปลกจริง ๆ
    • ตอนเวอร์ชัน Codex 5.1 มันไม่ค่อยดี เลยสงสัยว่าตอนนี้ดีกว่า Claude Code แล้วหรือยัง
    • น่าแปลกที่แม้แต่ใน OpenAI เองก็ยังต้องสร้างฟีเจอร์แบบนี้ขึ้นมาใช้
      มันแสดงให้เห็นว่ายังมี งานให้ทำอีกมาก ในด้านนี้

  • เอกสารทางการยังขาดอยู่ เลยขอแชร์สิ่งที่ลองหามาเอง
    ใช้คำสั่ง /plugin เพื่อเปิด plugin manager ของ Claude Code แล้วในแท็บ Discover ให้ค้นหา lsp กด spacebar เพื่อเปิดใช้งาน แล้วกด i เพื่อติดตั้ง

    • ตอนแรกฉันก็ตกใจเหมือนกันที่ Claude ถามว่าจะติดตั้ง Go LSP ไหม
      พอไปไล่ดู changelog ล่าสุดก็พบว่าเป็นฟีเจอร์ที่เพิ่งเพิ่มเมื่อ 3 วันก่อน
      ตอนนี้ยังเป็นแบบทดลองอยู่เลยปิดไว้ก่อน
    • แม้ในเวอร์ชันล่าสุด ค้นหา mcp ก็ยังไม่เจออะไรเลย
      ดูเหมือนว่าฟีเจอร์นี้ยัง อยู่ระหว่างทำไม่เสร็จ
      หวังว่าในอนาคต Claude จะตรวจจับ LSP ได้เองอัตโนมัติ
    • ถ้าจะเพิ่ม LSP แบบกำหนดเอง ต้องห่อมันด้วย plugin wrapper ของ Claude Code
      เอกสารที่เกี่ยวข้องอยู่ที่นี่

  • UX ของ Claude Code ของ Anthropic แย่ที่สุดในบรรดาผลิตภัณฑ์ AI หลัก
    แค่คัดลอกแล้ววางข้อความยังลำบาก และยังเมินฟีดแบ็กจากผู้ใช้
    ถ้าเป็นแบบนี้ก็ไม่รู้ว่าจะใช้สิ่งนี้แทน ChatGPT ไปทำไม

  • ฉันใช้ OpenCode ซึ่งเป็นโอเพนซอร์สมาราว 6 เดือนแล้ว และมันมีฟีเจอร์แบบนี้อยู่ก่อนแล้ว
    เลยแปลกใจที่ซอฟต์แวร์ปิดพัฒนาได้ช้าขนาดนี้
    ใช้ร่วมกับการสมัคร Claude หรือ Copilot ได้ด้วย เลยแนะนำ

    • ฉันอยากชอบ OpenCode เพราะชอบโอเพนซอร์สและ ความเป็นอิสระจากผู้ให้บริการ แต่ในทางปฏิบัติ Claude Code เสถียรกว่า
      OpenCode มี ปัญหาด้านประสิทธิภาพ เช่น กิน CPU 100% ระหว่างรออนุมัติ หรือ popover ทำให้ทำงานผิดพลาด
      ถึงอย่างนั้น Claude Code เองก็ยังมีบั๊กอย่างหน้าจอกระพริบเวลาเลื่อน
    • ฉันยังใช้ OpenCode ได้ไม่ค่อยเต็มที่
      Claude Code ให้ผลลัพธ์ที่ดีได้ทันที แต่ OpenCode ทั้งเชื่อมโมเดลยากและประสิทธิภาพต่ำกว่า
      น่าจะเพราะ การปรับแต่งพรอมป์ต์ ของ Claude Code สั่งสมมานานกว่า
    • โอเพนซอร์สมีโครงสร้างการตัดสินใจที่ง่าย เลยขยับได้เร็ว
      ไม่ต้องเสียเวลากับการโน้มน้าวผู้มีส่วนได้ส่วนเสียหลายฝ่ายหรือจัดสปรินต์ให้ลงตัว
    • ประสบการณ์การตั้งค่าของ OpenCode เป็นหนึ่งใน CLI tool ที่ ง่ายและตรงไปตรงมาที่สุด
      แต่ก็ยังมีบั๊กยิบย่อยกับแครชให้เจอบ่อย ๆ
    • ความเร็วในการพัฒนาของ OpenCode นั้นสูงมาก
      ถ้าใครประกาศ AGI ตอนเช้า ตอนเย็นมันอาจถูกรวมเข้าไปแล้ว
      ฉันทดสอบสลับไปมาหลายเครื่องมือ แต่ OpenCode ก็ยังพัฒนาอย่างต่อเนื่อง

  • รู้สึกแปลกที่คนตื่นเต้นกับเครื่องมือแบบ CLI กันมาก
    เอเจนต์ที่อิง IDE มีฟีเจอร์แบบนี้เป็น ของพื้นฐาน อยู่แล้ว เลยสงสัยว่าการไปทำ diff หรือ LSP ในเทอร์มินัลจะคุ้มจริงหรือ
    Cursor รองรับเรื่องพวกนี้มานานแล้ว

    • เดิมที LSP ถูกออกแบบมาให้ หนึ่งเซิร์ฟเวอร์ใช้ร่วมกันได้หลายไคลเอนต์
      ฝั่ง CLI แค่ทำไคลเอนต์เล็ก ๆ มาเชื่อมกับ LSP server ก็พอ
      ไม่มีเหตุผลที่ IDE ต้องผูกขาดประโยชน์จาก LSP อยู่ฝ่ายเดียว
    • มีคนบอกว่าแม้แต่คนที่ไม่ใช่นักพัฒนาก็ยังรู้สึกว่า Claude Code CLI เป็นธรรมชาติกว่า
      เทอร์มินัลไม่ใช่แค่ที่แก้โค้ด แต่เป็นพื้นที่สำหรับ ประสานงานทั้งคอมพิวเตอร์
      คล้ายกับเหตุผลที่ kubectl ไม่ได้วิวัฒน์ไปเป็น GUI
      บทความที่เกี่ยวข้อง: It's on your computer
    • สงสัยว่าเอเจนต์ใน IDE เข้าถึง LSP ได้จริงไหม
      อย่างเช่น Zed ถ้าไม่มี MCP server ก็อาจใช้ข้อมูลจาก LSP ไม่ได้
    • เอดิเตอร์กับแชตบอตของฉันอยู่ในเทอร์มินัลทั้งหมดอยู่แล้ว เลยไม่อยากย้ายไป IDE โดยไม่จำเป็น
      รู้สึกว่า CLI ดีกว่า UI ที่ยังไม่สมบูรณ์ ของแอปเดสก์ท็อป
    • ข้อดีของ CLI คืออิสระที่ ไม่ต้องผูกติดกับ IDE ใด IDE หนึ่ง

  • อย่างที่ฉันเขียนไว้ในโพสต์ล่าสุด ตอนนี้เรากำลังรัน LLM กันอย่างไม่มีประสิทธิภาพจนเกิด การสิ้นเปลืองทั้งโทเคนและพลังงาน สูงมาก
    หัวใจสำคัญคือทำให้ LLM ใช้เครื่องมือได้ง่ายขึ้น
    นี่เป็นหลักการที่ใช้ได้ไม่ใช่แค่กับการเขียนโค้ด แต่กับทุกสาขา

    • อีกไม่กี่ปีเราคงย้อนกลับมามอง ระบบนิเวศเครื่องมือที่ไร้ประสิทธิภาพ ในตอนนี้ด้วยความละอาย
      เราควรคำนึงถึงผลกระทบต่อสิ่งแวดล้อมจากการสิ้นเปลืองพลังงาน น้ำ และทรัพยากร
    • มีความพยายามแก้ปัญหานี้อยู่แล้ว
      ตัวอย่างเช่นโปรเจกต์อย่าง Serena

  • เอเจนต์ที่ฉันชอบอย่าง Crush รองรับ LSP อยู่แล้ว
    แต่ในทางปฏิบัติเอเจนต์ก็ไม่ได้ใช้ความสามารถนั้นบ่อยนัก
    ลิงก์ GitHub ของ Crush

    • สงสัยว่าถ้าระบุ LSP server ที่ติดตั้งไว้ใน AGENT.md จะช่วยให้ต่างออกไปไหม

  • ยังไม่เคยเห็นกรณีที่ LSP ถูกใช้งานจริงมากนัก
    Opus 4.5 มีจังหวะ QA ที่เสถียร และการเช็ก lint ก็ทำงานได้ดีนอก IDE
    ถ้าตำแหน่ง definition ซ่อนอยู่ลึกมาก LSP อาจจะมีประโยชน์
    รายการความสามารถ LSP ที่ Claude ให้มามีดังนี้

    • goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, prepareCallHierarchy, incomingCalls, outgoingCalls เป็นต้น

  • LSP ควรมี API ในรูปแบบ คำสั่งเชลล์
    แบบนั้นจะผสานกับ LLM ได้ง่ายขึ้น และมีประโยชน์กับมนุษย์ด้วย

    • ตอนนี้ก็มี CLI frontend อย่าง lsp-cli อยู่แล้ว
      แต่ถ้า LLM ใช้ LSP ผ่านเครื่องมือเฉพาะทางโดยตรง ก็จะมีประสิทธิภาพกว่าการเรียกคำสั่งเชลล์ธรรมดา