Claude Code bổ sung hỗ trợ LSP gốc

• Claude Code, công cụ lập trình dùng AI chạy trong terminal, đã bổ sung công cụ LSP (Language Server Protocol) trong phiên bản mới nhất
• Nhờ đó, công cụ cung cấp các tính năng thông minh mã nguồn ở cấp độ IDE như đi tới định nghĩa (go-to-definition), tìm tham chiếu (find references) và hiển thị tài liệu khi hover
• Lệnh /terminal-setup chính thức hỗ trợ các terminal Kitty, Alacritty, Zed, Warp
• Trong màn hình /theme, có thể bật/tắt tô sáng cú pháp bằng Ctrl+T
• Đã bổ sung hướng dẫn thiết lập terminal cho trường hợp phím tắt Alt không hoạt động trên macOS, đồng thời thống nhất ký hiệu phím tắt trên macOS từ alt thành opt để khớp với ký hiệu thực tế trên keycap
• Đầu ra của lệnh /context đã được cải thiện, với skill và agent được nhóm theo nguồn, sắp xếp theo lệnh gạch chéo, và sắp xếp theo mức sử dụng token

[aqqnucs]

Tôi đã dùng serena, nhưng đúng là hàng tích hợp sẵn vẫn hơn.

[GN⁺]

Ý kiến trên Hacker News

• Không hiểu vì sao JetBrains lại không tích hợp công cụ refactoring vào hệ thống AI
  Ngay cả các tác vụ đơn giản như đổi tên hàm cũng lẽ ra có thể xử lý với ngữ cảnh nhỏ hơn rất nhiều thay vì chỉnh sửa hàng trăm tệp
  Hỗ trợ LSP là một khởi đầu tốt, nhưng vẫn chưa đủ nếu không có khả năng biến đổi mã
  Chất lượng LSP của JetBrains cũng không tốt hơn mức thông thường

  • Dạo này JetBrains có cảm giác hơi mất phương hướng
    Từ sau khi bỏ modal commit và tăng giá gói dịch vụ, tôi đã nghĩ đến chuyện chuyển khỏi công cụ mình dùng hơn 10 năm
    Có thể thấy một ví dụ sai lầm gần đây trong bài blog này
  • Đây giống một thế lưỡng nan của nhà đổi mới điển hình
    JetBrains có engine PSI hiểu ngữ nghĩa mã tốt nhất, nhưng vẫn bị trói trong mô hình con người trực tiếp thao tác IDE
    Claude Code hay Cursor xem editor là một canvas để AI tự do thao tác, còn JetBrains lại đối xử với AI như một plugin sidebar đơn thuần
    Nếu không mở các công cụ refactoring nội bộ cho agent, rào cản chuyển sang VS Code sẽ biến mất
  • JetBrains nên thôi bám vào AI nội bộ Junie và tập trung tích hợp với những công cụ đã có chỗ đứng
    Nếu không, VS Code sẽ nuốt trọn thị trường
  • Vấn đề là sự tự mãn
    Trước đây họ có rào cản gia nhập rất lớn, nhưng VS Code đã phá vỡ điều đó
    Có vẻ họ hoàn toàn không lường trước được làn sóng thay đổi và giờ đang mất phương hướng
  • Microsoft cũng đang mắc sai lầm tương tự
    Họ chưa kết hợp tốt Roslyn với Copilot
    Analyzer của Roslyn không chỉ là linter đơn giản mà là công cụ mạnh có thể biến đổi mã, nên nhìn AI vẫn xử lý bằng find/replace đơn thuần thật đáng bực
    Nếu xuất hiện agent dựa trên Roslyn, hiệu suất làm việc với codebase lớn sẽ tăng bùng nổ

• Tôi rất tích cực với tổ hợp Claude Code / Codex CLI + LSP
  Cuối tuần rồi tôi thử Codex, nhưng việc nó bỏ sót tham chiếu khi đổi tên hàm hay di chuyển symbol khá khó chịu, nên tôi đã tự làm một skill nối với Rope, công cụ refactoring cho Python
  Khá hài lòng

  • Một kỹ sư OpenAI coi như đã bấm nút Copilot thay vì phím F2 nên đổi tên tham chiếu thất bại
    Việc không có hỗ trợ LSP thật sự rất lạ
  • Bản Codex 5.1 trước đây không tốt lắm, nên tôi tò mò không biết giờ nó đã khá hơn Claude Code chưa
  • Thật ngạc nhiên là ngay trong nội bộ OpenAI cũng phải tự xây những tính năng như thế này
    Điều đó cho thấy lĩnh vực này vẫn còn rất nhiều việc phải làm

• Vì tài liệu chính thức còn thiếu nên tôi chia sẻ những gì tự tìm ra
  Mở trình quản lý plugin của Claude Code bằng lệnh /plugin, ở tab Discover tìm lsp, nhấn spacebar để kích hoạt rồi nhấn i để cài đặt

  • Lúc đầu tôi cũng bất ngờ khi Claude hỏi có muốn cài Go LSP hay không
    Tìm changelog gần đây thì thấy đây là tính năng mới được thêm vào cách đây 3 ngày
    Hiện vẫn đang ở mức thử nghiệm nên bị tắt mặc định
  • Ngay cả ở bản mới nhất, tìm mcp cũng không ra gì
    Có vẻ tính năng này vẫn đang chưa hoàn thiện
    Hy vọng sau này Claude sẽ tự động nhận diện LSP
  • Muốn thêm LSP tùy chỉnh thì phải bọc nó bằng plugin wrapper của Claude Code
    Tài liệu liên quan ở đây

• UX của Claude Code của Anthropic là tệ nhất trong các sản phẩm AI lớn
  Ngay cả việc đơn giản như copy-paste văn bản cũng bất tiện, và họ còn phớt lờ phản hồi người dùng
  Nếu ở trạng thái này thì tôi không hiểu vì sao phải dùng nó thay vì ChatGPT

• Tôi đã dùng OpenCode mã nguồn mở được 6 tháng, và nó đã có những tính năng kiểu này từ trước
  Tiến độ chậm chạp của phần mềm đóng thật đáng ngạc nhiên
  Có thể dùng cùng thuê bao Claude hoặc Copilot nên tôi khuyên thử

  • Tôi muốn thích OpenCode vì ưu tiên mã nguồn mở và tính độc lập với nhà cung cấp, nhưng thực tế Claude Code lại ổn định hơn
    OpenCode gặp vấn đề hiệu năng như dùng CPU 100% khi chờ phê duyệt, lỗi do popover gây ra, v.v.
    Dù vậy Claude Code cũng có bug như nhấp nháy khi cuộn
  • Tôi chưa tận dụng OpenCode tốt được
    Claude Code cho kết quả tốt gần như ngay lập tức, còn OpenCode thì khó kết nối model và hiệu quả thấp hơn
    Có lẽ nhờ prompt tuning của Claude Code đã được trau chuốt lâu hơn
  • Mã nguồn mở có cấu trúc ra quyết định đơn giản nên có thể di chuyển rất nhanh
    Không tốn thời gian thuyết phục nhiều bên liên quan hay điều phối sprint
  • Trải nghiệm cấu hình của OpenCode là đơn giản và trực quan nhất trong số các công cụ CLI khác
    Chỉ là vẫn hay có bug lặt vặt và crash
  • Tốc độ phát triển của OpenCode rất nhanh
    Nếu sáng ai đó công bố AGI thì đến tối họ có khi đã tích hợp xong
    Tôi cũng đang thử qua lại nhiều công cụ, nhưng OpenCode vẫn tiến bộ đều đặn

• Cảm giác việc mọi người phát cuồng vì công cụ dạng CLI khá kỳ lạ
  Agent tích hợp trong IDE đã có sẵn những tính năng này, nên tôi nghi ngờ việc cố triển khai diff hay LSP trong terminal có thực sự hiệu quả không
  Cursor đã hỗ trợ những thứ này từ lâu rồi

  • Vốn dĩ LSP được thiết kế để một server được nhiều client dùng chung
    CLI chỉ cần làm một client nhỏ kết nối vào server LSP là đủ
    Không có lý do gì để chỉ IDE mới được hưởng lợi từ LSP
  • Nghe nói cả người không phải lập trình viên cũng thấy Claude Code CLI tự nhiên hơn
    Terminal không chỉ là nơi chỉnh mã mà là không gian để điều phối toàn bộ máy tính
    Nó cũng giống lý do kubectl không tiến hóa thành GUI
    Bài liên quan: It's on your computer
  • Tôi tò mò không biết agent trong IDE có truy cập được LSP hay không
    Ví dụ Zed thì nếu không có MCP server sẽ không tận dụng được thông tin LSP
  • Editor và chatbot của tôi đều nằm trong terminal nên tôi không muốn chuyển sang IDE
    Tôi thấy CLI tốt hơn UI còn dang dở của các ứng dụng desktop
  • Điểm mạnh của CLI là sự tự do không bị ràng buộc vào một IDE cụ thể

• Như tôi đã nói trong bài viết gần đây, việc chạy LLM kém hiệu quả đang gây lãng phí token và lãng phí năng lượng nghiêm trọng
  Điều cốt lõi là làm cho LLM dễ sử dụng công cụ hơn
  Đây là nguyên tắc áp dụng được không chỉ cho lập trình mà cho mọi lĩnh vực

  • Vài năm nữa chúng ta sẽ nhìn lại hệ sinh thái công cụ kém hiệu quả hiện nay với sự xấu hổ
    Cần tính đến tác hại môi trường do lãng phí năng lượng, nước và tài nguyên
  • Đã có những nỗ lực giải quyết vấn đề này
    Ví dụ có các dự án như Serena

• Agent tôi thích là Crush đã có hỗ trợ LSP từ trước
  Chỉ là trên thực tế agent không thường xuyên dùng tới tính năng đó
  Liên kết GitHub của Crush

  • Tôi tò mò không biết việc ghi rõ các LSP server đã cài trong AGENT.md có tạo ra khác biệt gì không

• Tôi vẫn chưa thấy trường hợp nào LSP thực sự được dùng
  Opus 4.5 có timing QA ổn định, và kiểm tra lint cũng hoạt động tốt ngoài IDE
  Khi phần định nghĩa bị chôn sâu, LSP có thể hữu ích
  Danh sách tính năng LSP mà Claude cung cấp gồm

  • goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, prepareCallHierarchy, incomingCalls, outgoingCalls, v.v.

• LSP nên cung cấp API dưới dạng lệnh shell
  Khi đó việc tích hợp với LLM sẽ dễ hơn và cũng hữu ích cho con người

  • Đã có các frontend CLI như lsp-cli
    Nhưng để LLM dùng LSP qua công cụ chuyên dụng vẫn hiệu quả hơn các lệnh shell đơn giản