Claude Code 支持哪些编程语言与框架

上周三凌晨两点，我在处理一个跨语言项目的紧急故障。前端是 Next.js 写的，后端 API 用 Go 搭的，数据处理管道跑在 Rust 上，还有个遗留的 Python 脚本混在中间。GitHub Copilot 在 Go 文件里给我推荐了 Rust 的语法，Cursor 在 Python 里死活理解不了我那套自己封装的异步上下文管理器。我切到 Claude Code，把四个仓库的根目录路径喂进对话，然后敲了一行：“分析跨项目的支付回调延迟根因。”

它用大约四十秒遍历了 TypeScript 接口定义、Go 的中间件链、Rust 的 tokio 任务图，最后指着 Python 脚本里一个没有设置 loop= 参数的 asyncio.run() 说：三次超时中有两次是从这里穿过来的。

我说这个故事不是为了神化 Claude Code。我想说的是：如果你还在用“是否支持某语言”这个维度来选 AI 编程工具，你已经落后了。真正该问的问题是，你的代码库结构和工程实践，能不能让 AI 理解你正在做的事情。

但这篇文章既然叫“Claude Code 支持哪些编程语言与框架”，我会先把这个问题正面回答清楚，然后再告诉你为什么这个问题本身就问窄了。

一、核心结论：先把话说清楚

Claude Code 目前对主流编程语言的支持可以概括为一句话：几乎所有能在公开互联网上找到足够优质训练语料的语言，它都能处理；但表现质量从“惊艳”到“勉强可用”之间，落差极大。

如果非要拉一张清单：

但这个表格有一个巨大的陷阱，“支持”的定义本身就模糊到毫无意义。Claude Code 能给你生成一段能跑的 Erlang OTP 代码，跟你用它维护一个 10 万行的 Erlang 生产系统，完全是两码事。

我在 2024 年下半年密集使用 Claude Code 做了六个项目，横跨 TypeScript、Python、Go、Rust 四个语言栈。接下来的内容，全部基于这些实战经验展开。

二、为什么“语言清单”是最大的误导

2.1 “支持”这个词，你自己都说不清

当你问“Claude Code 支持 Java 吗”，你到底在问什么？

• 它能生成一个能跑的 Spring Boot 启动类？
• 它能理解你们公司内部封装的 27 个自定义注解？
• 它能处理 Java 8 到 21 之间虚拟线程、Record、密封类的演进差异？
• 它能搞清楚你项目里那套诡异的 Maven 多模块依赖关系？

大部分人在问出这个问题时，脑子里想的是第一项。而实际工作中遇到的痛点，永远是后三项。

我见过的最惨的例子，是一个团队用 Claude Code 重构一个 Java 遗留系统。工程师兴奋地告诉我“Claude Code 对 Java 支持太好了”，然后展示了它生成的代码，确实好，Spring Boot 3.2 标准写法，响应式 WebClient，虚拟线程。问题是他们的生产环境跑的是 Java 8 加 Spring Boot 1.5。Claude Code 默认生成的是它“知道的最好的 Java”，不是你项目中实际在用的那个版本。

2.2 训练数据的分布决定了“隐性偏好”

Claude 的底层模型在训练时，不同语言的代码语料量级天差地别。公开数据显示 TypeScript 和 Python 的语料占比远超其他语言，这不是 Anthropic 的选择，而是 GitHub 公开仓库的语言分布决定的。

一个直接的后果是：Claude Code 对 TypeScript 的类型系统理解，细腻到能帮你推导出 conditional types 的嵌套链；但面对 Rust 的生命周期标注，它偶尔会给出“看起来对但编译不过”的方案。

三、一等公民语言：为什么是 TypeScript 和 Python

3.1 TypeScript：类型系统是 Claude Code 的母语

我在 2024 年 9 月用 Claude Code 完成了一个完整的 Next.js 14 项目迁移：从 Pages Router 切到 App Router，同时引入 Server Components 和 Server Actions。代码量约 3.2 万行。

整个过程让我对 Claude Code 的能力边界有了非常具体的认知：

它真正擅长的是类型推导和重构。当你给它一个包含泛型约束、条件类型映射的 TypeScript 文件，它能准确追踪类型流，然后在你重构函数签名时，递推式地更新所有调用点的类型标注。这种能力在 Copilot 上也能看到，但 Claude Code 的优势在于它能跨文件理解类型的传播路径，Copilot 在这方面受限于上下文窗口（即使最新的版本也远小于 Claude Code 的 200K token 窗口）。

一个具体的例子：

// 原始代码
async function fetchUserOrders<T extends UserType>(

user: T,

filters: OrderFilters<T>

): Promise<PaginatedResponse<OrderFor<T>>> {

// ...

}

当我决定把 OrderFilters 从泛型改为 discriminated union 模式时，Claude Code 帮我定位了 23 个文件、47 处调用点，给出了完整的变更方案。我审查后接受了 41 处，手动修改了 6 处（涉及业务逻辑判断）。

3.2 Python：动态语言的静态理解

Python 是另一个有意思的案例。理论上，动态类型语言对 AI 应该更友好，语法噪音少，表达力强。但实践中，Claude Code 对 Python 的支持质量高度依赖于你代码库的类型标注程度。

我有两个 Python 项目：

• 项目 A：全面使用 type hints + mypy strict mode + dataclasses
• 项目 B：老派的 Django 2.2 项目，几乎零类型标注

在项目 A 上，Claude Code 的表现接近 TypeScript 水平，能准确推断异步上下文传递、Pydantic 模型转换。在项目 B 上，它对 **kwargs 的透传和 Django ORM 的懒查询常常判断失误。

结论：不是 Python 被支持得好，是“写得好的 Python”被支持得好。 这个差异在动态语言上比静态语言明显得多。

四、框架支持的真实图景

4.1 前端框架：React/Next.js 生态是最强项

这不是主观判断，而是有明确的工程原因的：

1. React 生态的代码量在公开仓库中占比极高，训练语料充足。
2. JSX/TSX 的结构化特征让模型容易理解组件层级和数据流。
3. Hooks 的声明式模式比类组件的命令式模式更符合模型的语言生成特性。

我在一个电商项目中用 Claude Code 写了一个复杂的拖拽排序组件，涉及 useRef、useCallback、dnd-kit 库的传感器配置、以及跨多个 Context 的状态同步。Claude Code 在第一次生成时就准确处理了闭包陷阱问题，它在 useCallback 的依赖数组中正确列出了所有使用到的外部变量。我见过五年经验的 React 开发者犯同样的错误。

Vue 和 Angular 的支持程度明显逊于 React，但仍在可用范围内。Vue 3 的 setup 语法 Claude Code 理解得不错，Vue 2 的 Options API 也能处理，但遇到复杂的 mixins 合并时会出问题。Angular 因为其依赖注入和装饰器的元编程特性，Claude Code 的理解深度不如 React。

4.2 后端框架：Spring Boot 的隐藏成本

Spring Boot 是一个特别有代表性的案例，它“被支持”，但支持的方式代价很大。

Claude Code 能给你生成标准的 Spring Boot Controller、Service、Repository 三层代码，语法正确，注解齐全。问题出在两个地方：

第一，版本差异。 Spring Boot 3.x 和 2.x 在 Security 配置、Jakarta 迁移、AOT 编译上有巨大差异，Claude Code 默认倾向生成最新版本的写法。如果你声明了 spring-boot-starter-parent 版本号，它会适配；如果你忘了声明，它生成的可能无法在你的项目上编译。

第二，企业内部框架。 如果你公司封装了一套自己的 Starter（比如统一的异常处理、链路追踪、权限校验），Claude Code 完全不认识。你必须先让它“学习”这些内部框架的用法，然后才能让它生成兼容的代码。这个过程我测试下来，大概需要手动喂入 800-1500 行代表性的内部框架使用代码。

4.3 数据科学框架：PyTorch 和 TensorFlow 的截然不同

这一点很多人没意识到：Claude Code 对 PyTorch 的理解明显优于 TensorFlow。

原因不难推断：近年来公开的 ML 论文代码、HuggingFace 上的模型实现、各类开源项目，绝大多数使用 PyTorch。TensorFlow 的训练数据相对陈旧，且 API 演变历史混乱（1.x 到 2.x 的迁移，Keras 的整合与剥离）。

我给 Claude Code 下过一个任务：用 PyTorch 实现一个带混合精度的 Transformer 训练循环，使用 torch.cuda.amp。它生成的代码正确处理了 GradScaler、autocast 的上下文切换、以及梯度裁剪的位置，这些细节如果写错，模型可能完全无法收敛。而同一个任务描述给到 TensorFlow 版本，它生成的 tf.GradientTape 用法有两次关键的 API 错误。

五、能力边界：需要你的“教”而非它的“猜”

5.1 Go 语言：工程规范是双刃剑

Go 是一个让 AI 编程工具又爱又恨的语言。语法简单意味着生成门槛低，但 Go 社区的工程哲学（少即是多、显式错误处理、接口隐式满足）与 AI 的“概率生成”本质存在张力。

Claude Code 在 Go 上的表现有两个典型特点：

优点：标准库操作非常准确。 net/http、context、sync 等常见包的用法，生成的代码质量很高，几乎不需要修改。

缺点：错误处理模式容易被“简化”。 Go 的 if err != nil 不是样板代码，它承载了错误上下文传递和资源清理逻辑。Claude Code 偶尔会省略它认为“不重要”的错误检查，这在 Go 中是致命的。我在一个 gRPC 服务中遇到过：Claude Code 生成了一个 defer file.Close() 却不检查 Close 的错误，导致文件描述符泄漏在压测时才暴露。

使用建议：永远在提示词最后加上，“严格遵循 Go 的错误处理惯例，不省略任何 error check”。

5.2 Rust：所有权模型是试金石

Rust 最能暴露 AI 编程工具的底层能力差异。所有权、借用、生命周期这些概念不是靠模式匹配就能掌握的，它们是编译器在编译时执行的严格规则。 Claude Code 生成的 Rust 代码“看起来对”但编译不过的概率，是我测试的所有语言中最高的。

但同时，Claude Code 在 Rust 上有一个被低估的优势：解释型任务。当你给它一段复杂的生命周期标注代码，让它解释“为什么这里需要 'a: 'b”，它的回答质量非常高。这意味着 Claude Code 在 Rust 上的最佳使用姿势不是让它写代码，而是让它帮你理解代码（包括理解编译器报错）。

5.3 Java 与 C++：活在巨大遗产中的两面性

这两个语言放在一起说，因为它们面临同一个核心问题：语言的表面语法是现代的，但实际项目中的用法可能跨越二十年的历史。

Claude Code 处理“现代 Java”（17+，virtual threads，records）和“现代 C++”（20/23，concepts，ranges）表现不错。但一旦涉及企业级 Java（EJB、JSF、Struts）或老式 C++（C++98、裸指针、宏地狱），表现急剧下降。

这不是 Claude Code 的问题，是这些老式写法的训练数据本身就充满噪声和不一致。

六、配置文件类“语言”的特殊地位

6.1 YAML、JSON、TOML、Markdown：被低估的核心能力

严格来说这些不是编程语言，但 Claude Code 对它们的处理能力，在很多场景下比写代码本身更有价值。

YAML 是典型例子。一个 Kubernetes Deployment 文件、一份 GitHub Actions 工作流、一段 Ansible Playbook，这些配置的编写痛点从来不是语法，而是与平台特定的字段语义和版本兼容性。

Claude Code 在处理 K8s 资源配置时，对 apiVersion、kind、字段的嵌套层级、label selector 的匹配规则理解得相当到位。我让它帮忙写了一个带 HPA、PodDisruptionBudget、ServiceMonitor 的完整部署清单，它自动处理了 apiVersion 的版本差异，甚至在注释中标注了哪些字段在哪个 K8s 版本中引入。

Dockerfile 和 docker-compose 的优化建议也是高频场景。Claude Code 能识别出镜像层的缓存优化机会、不需要的 RUN 命令合并、安全最佳实践（不以 root 运行、COPY vs ADD 的选择）。

6.2 Shell 和 PowerShell：运维脚本的救星

Shell 脚本是一个让人头疼的领域，语法诡异、引号规则复杂、跨平台兼容性差。Claude Code 在这方面给了我不少惊喜。

我让它写过一个递归遍历目录、对符合特定模式的文件执行 ffmpeg 转码的 bash 脚本。它一次生成了正确的结果，处理了带空格的文件名、并行任务数控制、错误退出码传播，这些细节如果让我手写，得查三四次 StackOverflow。

但这里的风险是平台假设。Claude Code 默认倾向于 GNU 工具链的语法（比如 sed -i），在 macOS 的 BSD 版本上可能出错。你需要明确告诉它目标平台。

七、一套可复用的语言-框架评估方法

基于前面的分析，我总结了一个自用的评估框架。当你考虑在某个语言/框架上使用 Claude Code 时，按以下五个维度打分：

7.1 训练数据充足度

判断标准：该语言/框架在 GitHub 公开仓库中的占比、在 StackOverflow 上的问答量、近年来的流行度趋势。

• 如果语言在 TIOBE 前 15 且社区活跃，数据量通常不是瓶颈。
• 如果框架是“一家公司主导且开源社区不大”（如某些内部孵化项目），数据量可能不足。

7.2 语法稳定性

判断标准：过去三年该语言/框架的 API 变更频率和向后兼容性。

• TypeScript 的类型系统演进频繁但向后兼容好 → 高稳定性。
• Python 2.x 到 3.x 的断裂会影响旧代码理解 → 中稳定性。
• TensorFlow 的 API 频繁重构 → 低稳定性。

逻辑：LLM 的训练数据跨越时间窗口，如果同一个 API 在不同时期有不同的用法，模型给出的答案可能不正确。

7.3 项目上下文暴露度

判断标准：你的项目结构、配置文件、类型标注能在多大程度上被 Claude Code 读取和理解。

这是完全由你控制的因素。一个 tsconfig.json 或 pyproject.toml 比一段自然语言描述有效得多。 把 Claude Code 能自己读到的东西写到对话里，是性价比最低的做法。

7.4 社区规范共识度

判断标准：该生态是否有强烈且统一的工程规范。

• Go 有 gofmt、Effective Go → 高共识。
• Rust 有 rustfmt、Clippy、The Book → 高共识。
• JavaScript 有 ESLint 但规范多样 → 中共识。
• PHP 规范因框架而异 → 低共识。

共识度高 = Claude Code 更容易生成“符合预期的”代码。

7.5 质量反馈闭环效率

判断标准：你从 Claude Code 生成代码到验证其正确性的时间有多短。

• 静态类型语言的类型检查器能秒级反馈 → 快速闭环。
• 动态语言需要跑测试 → 中速闭环。
• 分布式系统需要部署到集群验证 → 慢速闭环。

八、我实际用过的六个项目：语言选择的决策回顾

8.1 项目一：全栈 SaaS（TypeScript + Next.js + Prisma）

语言/框架：TypeScript, React 18, Next.js 14 App Router, Prisma, tRPC, Zod

Claude Code 使用比例：约 60% 的前端代码、45% 的后端 API、30% 的数据库 schema 变更由 Claude Code 生成初稿。

采纳率：前端 75% 直接采纳或微调后采纳；后端 60%；数据库 schema 45%。

关键经验：

• tRPC 的类型安全终点到端点，Claude Code 理解得很透。
• Prisma schema 的关联关系，需要你在上下文中提供足够的表结构信息。
• 数据库迁移文件的生成从来不可靠，涉及数据安全的操作我全部手动写。

8.2 项目二：数据管道重构（Python + PySpark + Airflow）

语言/框架：Python 3.11, PySpark 3.4, Airflow 2.7, Pydantic, Pandas

Claude Code 使用比例：约 40% 的数据处理逻辑、70% 的 DAG 配置、20% 的 PySpark UDF。

采纳率：数据处理 50%；DAG 配置 80%；PySpark UDF 25%。

关键经验：

• PySpark 的 UDF 生成质量很差，Claude Code 对 Spark 的分布式执行模型理解不够，经常生成在 driver 端运行大量数据的代码。
• Airflow DAG 生成质量很高，因为 DAG 本质上是声明式配置。
• Pandas 操作高度依赖数据预览：你必须先把 DataFrame 的列名、dtypes、前几行数据喂给它，才能获得准确的 transform 建议。

8.3 项目三：CLI 工具（Go + Cobra）

语言/框架：Go 1.21, Cobra, Viper, Bubble Tea (TUI 框架)

Claude Code 使用比例：约 55% 的 CLI 命令实现、70% 的 TUI 界面。

采纳率：命令实现 65%；TUI 界面 70%。

关键经验：

• Cobra + Viper 的标准组合，Claude Code 非常熟悉。
• Bubble Tea 的 Elm 架构（Model-Update-View），Claude Code 的理解出乎意料地好，可能因为这种模式在训练数据中有足够的正面示例。

8.4 项目四：计费系统优化（Rust + gRPC + PostgreSQL）

语言/框架：Rust, tokio, tonic, sqlx, Rustls

Claude Code 使用比例：约 30%（主要是代码审查和性能优化建议）。

采纳率：优化建议 55%；新代码生成 35%。

关键经验：

• Rust 的编译期反馈是一个天然的“验证环”，Claude Code 生成代码 → 编译 → 报错 → Claude Code 修正 → 再编译。这个循环迭代 2-3 次后通常能得到可用代码。
• 与 tokio 的异步 trait 相关的代码（#[async_trait]），Claude Code 偶尔会遗漏。
• SQLx 的编译时查询检查，Claude Code 不了解，它不知道你在编译时会检查 SQL。

8.5 项目五：现有系统迁移（Java 8 → Java 17 + Spring Boot 2.x → 3.x）

语言/框架：Java, Spring Boot, Spring Security, JPA/Hibernate

Claude Code 使用比例：约 25%（迁移指南生成、重复模式替换）。

采纳率：迁移步骤建议 70%；自动代码替换 40%。

关键经验：

• Spring Security 的配置迁移是阿喀琉斯之踵，从基于 WebSecurityConfigurerAdapter 的写法迁移到基于 SecurityFilterChain bean 的新写法，Claude Code 给出的方案有 30% 的路径映射错误。
• Jakarta 命名空间替换（javax.* → jakarta.*）这种机械替换，Claude Code 准确率接近 100%，但前提是你在上下文中明确告知这是迁移目标之一。

8.6 项目六：前端监控 SDK（TypeScript + Rollup + 浏览器 API）

语言/框架：TypeScript, Rollup, Web APIs (Performance, Error Tracking, Beacon)

Claude Code 使用比例：约 65%。

采纳率：70%。

关键经验：

• 浏览器 API 的兼容性处理，Claude Code 表现超出预期，它会自动考虑 navigator.sendBeacon 的降级方案。
• Rollup 插件配置生成准确，但需要你指定目标浏览器列表。
• 错误堆栈解析的跨浏览器差异，Claude Code 处理得不够细，Firefox 和 Chrome 的错误对象结构差异需要手动处理。

九、常见误区深度拆解

9.1 误区一：“新语言反正不支持，不用试了”

这个想法对了一半。新语言（如 Mojo、Gleam）确实不会被深度支持，因为训练数据几乎没有。 但 Claude Code 对语法规则的理解有迁移能力。

我测试过一个场景：用 Gleam（一个运行在 Erlang VM 上的静态类型语言）写一个简单的 HTTP 服务器。Claude Code 完全没有 Gleam 的训练数据，但我喂给它 Gleam 的语法速览和标准库文档片段后，它生成了一段在语法上完全正确的代码，尽管在库的使用上需要调整。

这个发现很关键：Claude Code 的真正能力不是“记住所有语言的 API”，而是“理解语言设计范式并迁移”。当遇到新语言时，它的上下文学习能力比你想象的要强。因此，对于小众或新语言的用户，更应该关注的不是 Claude Code “会不会”，而是如何构建有效的最小上下文。

9.2 误区二：“既然是 AI，纯文本语言和框架都一样”

我见过一个团队用 Claude Code 写 COBOL，不是开玩笑，他们维护一个银行遗留系统。结果是：Claude Code 生成的 COBOL 代码语法基本正确，但完全不符合他们那套 30 年前制定的内部编码规范。

语言的时间维度被严重低估了。Claude Code 的训练数据中，COBOL 的代码量本就不多，那些代码所属的年代、风格、平台五花八门。对于这种高度依赖历史上下文的语言，你需要提供的不仅仅是“这是 COBOL”，而是“这是我们项目中的 COBOL 写法示例”。

9.3 误区三：“框架支持好 = 可以直接用于生产”

这是最危险的误区。Claude Code 对框架的“支持”意味着它能生成语法正确、符合框架惯例的代码。这不等于生成的代码没有安全漏洞、没有性能陷阱、没有业务逻辑错误。

React Server Components 是一个典型例子。Claude Code 能写出标准的 RSC 组件，但"use server" 指令下的安全边界，哪些数据会暴露给客户端，它不主动帮你考虑。你必须明确要求它执行安全审查。

十、实战方法论：如何让 Claude Code “精通”任何语言

10.1 第一步：建立语义层

我在每个项目根目录放一个 CLAUDE.md 文件（Anthropic 推荐的约定），内容不是“这是 TypeScript 项目”这种废话，而是：

• 语言和运行时版本：精确到 Node.js 20.11.0, Python 3.11.7
• 核心框架及版本：Next.js 14.1.0 (App Router), Prisma 5.9.0
• 关键架构约定：API 路由模式、数据库命名规范、类型文件组织方式
• 反模式清单：明确告诉它“不要用 X 模式”、“避免 Y 写法”

一个实战例子：

# CLAUDE.md - Project Context
Stack

TypeScript 5.3.3, strict mode

Next.js 14.1.0, App Router only

Prisma 5.9.0, PostgreSQL 16

Zod 3.22 + tRPC 10.45

Conventions

Server Components by default, 'use client' only when needed

Data fetching always in Server Components, never in client

Mutations via Server Actions only

Zod schemas co-located with tRPC routers in /server/api/routers/

Database access via Prisma in /server/db/, never in components

Anti-patterns to avoid

DO NOT use getServerSideProps or getStaticProps (Pages Router APIs)

DO NOT import 'server-only' modules in client components

DO NOT use Prisma client directly in React components

这个文件的效果是立竿见影的。在我加上它之前，Claude Code 偶尔会混用 Pages Router 和 App Router 的 API；加上之后，这类错误完全消失了。

10.2 第二步：深度使用代码库上下文

Claude Code 的 200K token 上下文窗口是它区别于其他 AI 编程工具的核心优势。很多人用不好它，是因为把上下文当成了“提问的输入”，而不是“让 Claude Code 真正读懂你的项目”。

正确的用法：在对话开始时，主动引用：

• 项目的 package.json / pyproject.toml / Cargo.toml
• 核心模块的目录结构
• 关键类型的定义文件
• 最近修改的 5-10 个文件

这个过程不是一次性的，每次对话的上下文是独立的。我的习惯是每次开启新会话时，至少花 2 分钟“喂上下文”。

10.3 第三步：建立类型驱动的护栏

对于 TypeScript，我在 tsconfig.json 中开启最严格的编译器选项：

{
"compilerOptions": {

"strict": true,

"noUncheckedIndexedAccess": true,

"exactOptionalPropertyTypes": true,

"noUnusedLocals": true,

"noUnusedParameters": true

}

}

这些选项不是为了让代码更“严谨”，它们是让 Claude Code 的生成结果能被编译器立即验证。 任何类型错误都会在保存时暴露，形成秒级的反馈闭环。

对于 Python，等效做法是 mypy --strict + ruff + pytest。

10.4 第四步：角色转换，从代码生成者到设计审查者

这是最容易发挥 Claude Code 价值的使用方式。与其让它生成你写不出的代码，不如让它审查你已经写好的代码。

我现在的标准开发流程：

1. 自己写第一版代码（或 Claude Code 生成初稿后我修改）。
2. 把修改后的代码+需求描述喂给 Claude Code，问：“这段实现有没有偏离需求的地方？有没有边界情况没覆盖？”
3. 根据反馈调整。
4. 再问：“这段代码如果要维护两年，哪里会最先出问题？”

这个流程让我发现了大量我自己忽略的问题，尤其是在 Rust 的 unsafe 块审查、Go 的并发竞态、TypeScript 的类型收窄遗漏上。

十一、不同场景下的语言/框架选择指南

11.1 场景一：启动全新产品（MVP 阶段）

推荐栈：TypeScript + Next.js + Prisma 或 Python + FastAPI + SQLAlchemy

理由：你会大量依赖 Claude Code 生成代码来加速开发。这两个栈在 Claude Code 上的体验最好，采纳率高，返工少。

权衡：如果产品对性能有硬性要求（如高并发、低延迟），这个阶段的选择可能在后期需要重写。但 MVP 阶段的速度优先级高于性能。

11.2 场景二：维护现有企业系统

核心原则：不要指望 Claude Code “直接理解”你们的内部框架。

行动步骤：

1. 为内部框架编写专门的上下文文档（类似上面的 CLAUDE.md 但更详细）。
2. 选取 5-10 个最具代表性的内部框架使用文件，固定作为每次对话的上下文输入。
3. 重点使用 Claude Code 做代码审查和重构建议，而非新功能生成。

案例：一个金融科技团队维护一个 12 年历史的 Java 系统，内部有 40+ 个自定义注解。他们花了两周时间整理了注解的用法文档和代表性代码片段。之后 Claude Code 在他们项目上的采纳率从 15% 提升到 50%。

11.3 场景三：跨语言迁移（如 Java → Kotlin）

Claude Code 的优势：能理解两种语言的语义对应关系，处理机械的语法转换。

但注意：

• 它能处理的是“一对一”的语法映射，不能处理“设计模式级别的范式转换”。
• Java 的 null 处理和 Kotlin 的可空类型系统之间的转换，需要人工审查。
• 框架迁移（如 Spring → Ktor）超出了它的能力范围，你需要自己做架构决策。

11.4 场景四：学习一门新语言

Claude Code 是极佳的学习辅助工具，但使用方式不是让它“教你语法”。

高效用法：

1. 用新语言手写一个简单功能的代码。
2. 让 Claude Code 审查你的代码，指出不符合该语言惯用法的地方。
3. 让它解释为什么某个写法更“地道”。

我在学习 Rust 的早期阶段大量使用这个模式。Claude Code 帮我纠正了很多“带着 TypeScript 习惯写 Rust”的问题，比如过度使用 clone()、不理解 &str vs String 的场景选择、Result 的错误传播模式。

十二、总结：语言是皮，代码库是骨

回到开头的问题，“Claude Code 支持哪些编程语言与框架”。我希望读完这篇文章的你，已经意识到这个问题本身的局限性。

真正重要的不是名单上写了哪些语言，而是你的代码库能在多大程度上被 AI 理解。

TypeScript + React 之所以表现惊艳，不仅是因为训练数据多，更是因为这个生态天然具备让 AI 理解的特征：强类型约束、声明式组件树、统一的文件组织模式。而一个混乱的 Python 项目即使理论上“被支持”，Claude Code 的实际帮助也有限。

你下一步应该做什么

第一件事：不要再去搜索“Claude Code 支持 XX 语言吗”。打开你的项目根目录，问自己三个问题：

• 我的项目结构和配置能被 AI 读懂吗？
• 我的类型系统或验证规则足够严格，能形成快速的质量反馈吗？
• 我的代码风格是否有一致性，还是充满了个人偏好的奇技淫巧？

第二件事：如果你决定在某个语言/框架上深度使用 Claude Code，请立刻建立一个 CLAUDE.md 文件。哪怕只有 15 行内容，效果也比没有好得多。

第三件事：调整你对 AI 编程工具的期望模型。把它当成一个能极速查阅代码、精通模式匹配、但缺乏真实业务判断力的高级同事。 给它足够多的上下文（好的），信任它输出而不加审查（坏的），后者是当前 AI 编程工具最大的生产力陷阱。

我在六个项目中的经验告诉我一个朴素的道理：Claude Code 的上限不取决于 Anthropic 训练了多少语言的数据，而取决于你作为一个工程师，能为它构建多好的可被理解的环境。 这个道理适用于 Claude Code，也适用于未来任何一代 AI 编程工具。