支持哪些语言，哪些模型

wescode · 2026-10-29 · FAQ / 语言 / 模型

利益声明：本文作者参与了 wescode 的开发。文中涉及 wescode 的技术描述基于内部测试数据；涉及其他工具的描述基于各家公开文档和社区反馈。

这是被问得最多的两个问题，放一起答。

Q: wescode 支持哪些编程语言？

编辑器层面：所有 VS Code 支持的语言，wescode 都支持。 因为 wescode 就是 VS Code 的 Fork——不是插件，是整个编辑器。你装得上的 language extension（Python、Rust、Go、Kotlin、Swift、C#、Ruby……），在 wescode 里一样装、一样用。

AI 辅助层面，wescode 的**代码知识图谱（CKG）**对不同语言有不同深度的支持。下面这张表是当前各语言的 CKG 特性覆盖情况：

CKG 深度支持语言（完整调用图 + 类型推断）

CKG 基础支持语言（tree-sitter 符号提取 + 启发式调用推断）

对于表中未列出的语言（比如 Haskell、Elixir、Dart），wescode 仍然能做 tree-sitter 级别的语法高亮和基础符号提取，但没有调用图能力。AI 对话会退回到"全文搜索 + 语义理解"模式。

说白了：编辑写代码不受任何限制。AI 理解代码的深度，取决于 CKG 对该语言的支持程度。

Q: 每种语言的 CKG 体验差异有多大？

不同语言的 CKG 体验差异相当明显。用一个跨语言的例子来说明——接口实现追踪：

TypeScript：IMPLEMENTS 追踪完整

// 定义接口
interface PaymentGateway {
  processPayment(amount: number): Promise<Result>
}

// CKG 知道 StripeGateway 实现了 PaymentGateway
class StripeGateway implements PaymentGateway {
  async processPayment(amount: number) { /* ... */ }
}

// 你在任何地方写 gateway.processPayment()
// CKG 能追踪到 StripeGateway 的具体实现

TypeScript 有显式 implements 关键字，CKG 直接从 AST 提取关系——零猜测、零遗漏。

Go：隐式接口，CKG 靠方法集推导

// 接口定义
type PaymentGateway interface {
    ProcessPayment(amount int64) error
}

// 没有 implements 关键字——Go 靠方法集匹配
type StripeGateway struct{}
func (s *StripeGateway) ProcessPayment(amount int64) error { /* ... */ }

// CKG 扫描所有类型的方法集，发现 StripeGateway 满足 PaymentGateway
// 这个推导过程比 TS 慢（需要全量比对），但结果同样准确

Python：动态属性是盲区

class PaymentGateway(ABC):
    @abstractmethod
    def process_payment(self, amount: float) -> Result: ...

class StripeGateway(PaymentGateway):
    def process_payment(self, amount: float) -> Result:
        # CKG 能追踪——有显式继承

# 但这种写法 CKG 追踪不到：
handler = getattr(service, f"handle_{action}")  # 运行时动态解析
handler(request)  # CKG 不知道 handler 是什么

# 加了 type hint 就能追踪：
def get_handler(service: PaymentGateway) -> Callable:
    return service.process_payment  # CKG 能通过类型注解推导

Python 的 CKG 准确率跟你写了多少 type hint 成正比。现代 Python 项目（mypy strict、Pydantic model）覆盖率接近 TypeScript；老式 Python 2 风格的代码覆盖率会降到 80%。

实际体验总结：

Q: 用什么模型？能用我自己的 Key 吗？

wescode 的模型策略是 BYOK（Bring Your Own Key） ——你直接用自己的 API Key 连接模型供应商。

当前支持的主流供应商和模型：

接入一个新 Provider 的完整步骤

以 DeepSeek 为例（最常见的低成本方案）：

# 在 wescode 设置页 → Provider 配置
# 或编辑 config.yaml：
providers:
  - name: deepseek
    type: openai_compatible
    base_url: https://api.deepseek.com/v1
    api_key: sk-your-key-here
    models:
      - name: deepseek-chat
        context_window: 65536
      - name: deepseek-reasoner
        context_window: 65536

配好后在设置页点「测试连接」——会发一个最小请求验证 Key 和端点是否可用。测试通过后模型立刻出现在 Chat 面板的模型选择器里。

关键区别： wescode 的 BYOK 是真正的直连——请求从你的机器直接发到 API 端点，中间不经过 wescode 的服务器。这跟 Cursor 的"自带 Key"不一样：Cursor 即使你填了自己的 API Key，请求仍然经过 Cursor 的后端做转发。

Q: 那 wescode 自己的 WES 账户是什么？

如果你不想管 Key，wescode 提供一个托管账户（WES 账户）：你充值，用量按各模型供应商的公开价格结算，没有加价。

WES 账户 vs BYOK 的区别：

你随时可以在 BYOK 和 WES 之间切换，也可以同时配置多个供应商做 fallback。

Q: Cursor 说自带 Key 也是直连，真的吗？

Cursor 官方文档明确说明：即使使用自带的 API Key，请求仍然经过 Cursor 的后端。他们的理由是需要做代码索引、embedding 和上下文优化。这意味着你的代码片段会被发送到 Cursor 的服务器处理。

wescode 没有远程服务——CKG 索引、上下文组装全在你本机完成。你的代码离开机器的唯一出口是你自己配置的 LLM API 调用。

Q: 能不能完全用本地模型，不联网？

可以。配置 Ollama 或任何 OpenAI 兼容的本地端点，所有请求在本机闭环。

代价是显而易见的：本地模型（即使是 70B 量化）的代码生成质量跟 Claude Sonnet 4 或 GPT-4.1 还有明显差距。wescode 不会阻止你用本地模型，但建议至少在复杂推理场景保留一个商业模型的 fallback。

Q: 通义灵码、Trae、CodeGeeX 也免费，为什么不用？

免费工具有它的位置。但你需要清楚免费背后的交换：

1. 代码上云——通义灵码和 CodeGeeX 的请求都经过各自的云端，代码上下文存在他们的服务器上
2. 模型绑定——你只能用他们提供的模型，无法接 Claude 或 GPT
3. 没有调用图——全部基于 embedding 做检索，无法准确回答"这个接口被谁调用了"

如果你写的是个人项目或开源代码，这些问题可能不重要。但如果你在企业环境写商业代码，这三条中的任何一条都可能是 blocker。

wescode 的选择很简单：你选模型、你管 Key、代码不出你的机器（除了你明确选择的 LLM API 调用）。

Q: 新语言支持的优先级怎么定？

CKG 对新语言的支持优先级取决于两个因素：

1. tree-sitter 语法包成熟度——tree-sitter 社区维护了 100+ 种语言的语法定义，但质量参差不齐。Go、TypeScript、Python、Java 的语法包非常成熟（每周活跃维护），Rust 和 C# 其次，小众语言的语法包可能有 bug 或不完整
2. 用户需求密度——哪些语言的用户在 GitHub Issues 里反馈最多，就优先做哪些

当前路线图上排在前面的：Rust 的 trait 实现完整追踪（已在开发中）、C# 的 LINQ 表达式展开。你可以在 Issues 里投票催优先级。