跳到主要内容

中文编程争议的核心原因是什么？

这个问题每隔几年就会被翻出来讨论一轮,争论的激烈程度往往超过技术本身。曾经我主张如果你用中文写出来的开源库拳打elastic search，脚踢kafka，那么中文编程就是编程史上的里程碑，围绕你的信徒没有几千也有几万，但是很可惜现在并没有人做到。 当时有个人追着我一堆喷，给我都整出PTSD了。

写过几年代码,经历过从纯英文到现在 AI 辅助开发的转变,可能能提供一些不同角度的观察。

反对中文编程最硬的理由其实很简单: 现有生态全是英文的。

  • 主流框架、库、工具链都是英文
  • Stack Overflow、GitHub 上的问答和文档是英文
  • 报错信息、日志输出是英文
  • 第三方服务的 API 文档是英文

这不是"崇洋媚外",是客观现实。你用中文写业务逻辑,调用的底层还是 HttpServletRequest,出了问题还得去英文社区找答案。这种割裂感是真实存在的。

你可以在 Spring Boot 项目里试过用中文命名变量和方法,比如 获取用户信息(),写的时候确实顺畅,但调试时看到这样的调用栈:

com.example.service.UserService.获取用户信息(UserService.java:45)
    at com.example.controller.UserController.lambda$0(UserController.java:32)
    at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:421)

中英混杂的视觉体验确实不太好。

在实际项目中,代码不是一个人写的:

  • 可能有外包团队参与
  • 开源组件需要其他开发者维护
  • 技术选型时要考虑招聘难度
  • 代码审查和交接时的理解成本

中文编程在小团队、内部系统里问题不大,但一旦涉及开放协作,英文确实是当前的通用语言。这不是技术问题,是社会网络效应。

很多人觉得中文输入慢,这在十年前确实是问题,但现在拼音输入法已经很成熟了。真正的障碍在于:

  • 中英切换的认知负担(虽然习惯后还好)
  • IDE 对中文标识符的支持参差不齐(某些老版本工具会乱码)
  • 某些字符在不同编码下显示问题

不过这些都是工程问题,不是根本性障碍。我用 IDEA 写中文注释和文档完全没问题,只是变量名还是习惯用英文。

而现在2025年的最后几天，肯定还是得说说AI编程 + 中文编程​

AI编程拯救中文编程了吗？

很多人以为 AI 时代"用中文说话就能生成代码"，所以中文编程有希望了。你用中文跟 AI 对话，AI 生成的还是英文代码。这个过程证明了：

  • 编程需要的是精确性，不是表达的"自然"
  • 标识符命名是最不重要的部分，算法逻辑才是核心
  • 你在用中文描述需求，但需求和代码是两个层次的东西

以响应式编程为例，核心问题不是方法名叫 getUserInfo 还是 获取用户信息，而是要理解 Mono、Flux、背压、调度器这些概念

这些概念用中文翻译过来反而更难懂：

// 英文
return userRepository.findById(id)
    .flatMap(user -> orderService.getOrders(user.getId()))
    .map(orders -> new UserOrderDTO(user, orders));

// 中文版
return 用户仓库.根据ID查找(id)
    .平面映射(用户 -> 订单服务.获取订单(用户.获取ID()))
    .映射(订单列表 -> new 用户订单DTO(用户, 订单列表));

第二种写法看起来你真的觉得靠谱吗？flatMap 是函数式编程的术语，翻译成"平面映射"反而失去了精确含义。

而且当需要你分辨响应式编程中的坑，中文也不能给你带来任何优势。

比如下面这个代码：

    @GetMapping("增加数量")
    public Mono<ResponseEntity> 增加数量"(){
        return Mono.just(1)
                .平面映射(i ->
                    Mono.fromRunnable(() -> 一些操作())
                        .subscribeOn(Schedulers.newSingle("线程池名字"))
                )
                .映射(it -> {
                    return ResponseEntity.ok().build();
                });
    }

bug点在于每次请求进来的时候都会创建一个新的线程池Schedulers.newSingle("线程池名字")，最终导致内存泄露

更何况AI 能帮你生成中文代码，但不能改变软件工程的协作本质。​

比如你写了一个下面这样的第三方库：

// 你用中文写
public class 用户服务 {
    private RestTemplate 请求模板;

    public 用户信息 获取用户(String id) {
        // 这里调用的还是 RestTemplate.getForObject()
        return 请求模板.getForObject("/users/" + id, 用户信息.class);
    }
}

你自己的代码可以用中文，但底层依赖的 RestTemplate、Jackson、Netty 全是英文 API。这种割裂感是结构性的，不是 AI 能解决的。

那么换句话说，用中文 + AI编程生成英文代码呢？​

你用中文描述业务逻辑 -> AI 理解后生成英文代码 -> 代码里的命名、结构都是 AI 根据最佳实践生成的。

在这个流程里，中间产物的命名根本不重要，重要的是：

  • 你的需求表达是否清晰（中英文都行）
  • 生成的代码逻辑是否正确
  • 代码能否被其他开发者或 AI 读懂

你别说，你还真别说，这确实可以。但是，古尔丹，代价是什么呢？

那么就是维护的时候还是得看英文！！！

AI要是稍微降智一点（说的就是你，ChatGPT），或者AI封锁（Claude），你不得不手动去改代码的时候，你就得直面痛苦了。

被AI反噬的滋味绝对、绝对、绝对是让你“吸髓知味”的。 别问我为什么知道，曾经因为AI 5分钟生成的代码一键commit, push, 后来排查了一星期没找到原因，最后还是得推翻重写。

古法编程的好就是，每个代码细节我都知道。

好了，别再说什么中文编程了，那真的不重要。你要是让我用中文编程赚到700万美元，我每天都要写一篇《中文编程就是屌》