---
title: "AI 时代，编程语言还重要吗？| Wavect"
canonical: https://wavect.io/zh/blog/programming-languages-matter-less-ai/
language: zh
description: "AI 让语法变便宜，却没有让软件工程变简单。为什么架构、运行时、内存安全、可维护性与技术领导力比以往更重要。"
image: "https://wavect.io/img/blog/headers/header_programming-languages-matter-less-ai.png"
---

[**返回**](/zh/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/)

[Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt

12 分钟 阅读 · 2026年7月15日

[**下一篇**](/zh/blog/colibri-glm-5-2-consumer-hardware/)

# 编程语言没那么重要了，软件工程却更重要了。

要点速览

编程语言作为代码生产门槛，确实没那么重要了；作为系统决策，它依然重要。AI 让语法、 样板代码与跨语言翻译变便宜，但运行时、内存安全、并发、架构、领域规则、验证与 可维护性仍决定结果是否安全、是否值得长期持有。最新证据展示了新的分工：人类负责 大多数规划，智能体负责执行；领域知识让可验证成功率相比新手会话提高一倍以上； DORA 则发现 AI 会同时放大交付系统的优势与缺陷，包括不稳定性。正确策略不是生成 最多代码，而是按长期系统约束选语言，把架构写成可执行测试与策略，保持小变更，并让 评审、拒绝与可观测性和生成能力同步扩张。

**在 AI 时代，编程语言还重要吗？**如果它衡量的是谁能产出代码，那么重要性确实下降了；如果它代表的是系统约束，就依然重要。AI 可以随时生成 Java、Go、Python、Rust 或 TypeScript，却无法抹去它们在运行时、内存、并发、安全、生态与维护上的差异。语法越来越便宜，工程判断没有。

所以，“编程语言已经不重要”这句标题，几乎对了，却对在最没用的地方。团队亲手写的常规代码变少了，借助编码智能体产出的软件变多了。但代码来得越快，越需要有人知道究竟该造什么、各部分如何衔接、运行时在压力下会怎样，以及两年后另一个人能否安全地修改这个系统。

## “编程语言没那么重要”究竟是什么意思？

它意味着，把明确需求翻译成有效语法这件事的市场价值正在下降；并不意味着所有实现选择都可以互换。编码智能体可以在几分钟内把一段数据转换逻辑从 Python 改写成 Go。但这段逻辑究竟该放在请求处理器、队列 worker、数据库查询、流处理器里，还是根本不该存在，属于完全不同的一类决策。

| 被 AI 变便宜的能力 | 被 AI 放大的价值 |
| --- | --- |
| 记住语法与库调用 | 定义正确的问题与验收标准 |
| 生成样板代码与适配器 | 决定系统边界与所有权 |
| 在语言之间翻译 | 理解运行时、内存与并发行为 |
| 快速给出一个貌似合理的初版 | 证明正确性、安全性与可运维性 |
| 迅速增加代码 | 让系统保持小、清楚、可维护 |

GitHub 调查了美国、巴西、德国和印度 2,000 名企业软件团队成员，其中 [60% 至 71% 的受访者认为，AI 工具让采用新语言或理解现有代码库变得容易](https://github.blog/news-insights/research/survey-ai-wave-grows/) 。语言门槛确实在下降，但这不等于语言选择的后果消失了。

## 开发者真的在减少手写代码吗？

世界上没有一块仪表盘统计手写代码与 AI 代码的总量，所以任何全球统一百分比都是表演。但多项使用研究展示了明确方向。Stack Overflow 2025 开发者调查显示， [84% 的受访者已经或计划使用 AI 工具](https://survey.stackoverflow.co/2025/ai) 。在部分接入 AI 的人群中，写代码是最常见用途，占 59%。

在 Anthropic 内部，请注意，这是厂商自身，不是中立样本，132 名工程师与研究人员自报在 59% 的工作中使用 Claude，生产力提高 50%。Anthropic 还观察到 [每位工程师每天合并的 pull request 增加了 67%](https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic) 。最值得看的不是自报提升的精确数字，而是变化形态：每类任务少花一点时间，总产出明显增加，而且 27% 的 AI 辅助工作原本根本不会被做。

Anthropic 此前对 50 万次编程交互的分析中， [79% 的 Claude Code 对话被归类为自动化](https://www.anthropic.com/research/impact-software-development) ，21% 是增强。到 2026 年 6 月，一项覆盖约 40 万次 Claude Code 会话的研究把分工描述得更清楚：人类做大多数关于*做什么*的规划决策；Claude 做大多数关于*怎么做*的执行决策。

## AI 会让软件专业能力贬值吗？

不会。它只是在重新分配专业能力的回报。

Anthropic 2026 年 6 月的研究中，被评为新手的会话，严格意义上的“可验证成功率”是 15%；中级与专家会话为 28% 至 33%。研究者发现， [一个人带入的领域知识越多，智能体每条指令能完成的工作就越多](https://www.anthropic.com/research/claude-code-expertise) 。他们的结论很直接：把智能体导向成功，更多取决于对领域的掌握，而不是亲手写代码的能力。

![Kevin Riedl](/img/team/kevin.webp)

"当代码变得过剩，判断力就成了稀缺输入。最有价值的不再是敲出最多实现的人，而是能决定该造什么、约束智能体，并证明结果有资格运行的人。"

这不代表所有架构师都会赢、所有程序员都会输。脱离实现反馈的架构很快会变成 PowerPoint。真正强的工程师，仍然离代码、trace、数据库、队列、部署流水线和故障足够近，能发现自己的系统模型何时错了；他们只是减少了把稀缺注意力花在可预测的手工输入上。

## 为什么关于生产力的研究看起来互相矛盾？

因为“AI 让开发者更快”不是一个单一实验。任务熟悉度、工具代际、仓库质量、开发者经验、评审延迟，以及是否并行运行多个智能体，都会改变结果。

METR 在 2025 年初的对照实验中发现，经验丰富的开源开发者在自己非常熟悉的代码库里使用 AI，完成任务反而慢了 19%。2026 年 2 月，METR 表示后续数据开始指向提速，却也坦承选择偏差和计时问题让估计不可靠。其更新最诚实的表述是： [到 2026 年初，开发者很可能比此前获得了更多加速，但幅度无法可靠测量](https://metr.org/blog/2026-02-24-uplift-update/) 。

DORA 2025 的研究解释了部分矛盾：AI 是放大器。它与吞吐和产品绩效正相关，但与软件交付稳定性仍是负相关。换成直白的话： [AI 把更多变更推过系统，也让薄弱测试、过大批次、缓慢反馈和不成熟的平台工程暴露出来](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) 。

所以，正确问题不是“AI 让一个开发者快了多少”，而是“实现吞吐上涨后，整个交付系统发生什么”。如果评审、测试、架构决策、安全关卡、部署保障与可观测性没有同步扩容，公司每周增加的是风险，而不是价值。

## 为什么编程语言依然重要？

因为语言不只是语法，而是一组默认行为与保证。智能体关掉 pull request 后，这些东西还留在系统里。

### 运行时行为最终会写在账单上

垃圾回收、启动时间、JIT 预热、事件循环、线程调度、异步运行时、二进制体积与 FFI 边界，都会影响延迟、基础设施成本、部署能力和失效模式。LLM 可以写出两个版本，生产环境仍要为你的选择买单。

### 内存模型最终会写进安全事件

Google 的 Android 团队提供了少见的真实对比。随着新原生代码向 Rust 迁移，2025 年内存安全问题首次降到 Android 全部漏洞的 20% 以下。Google 估计， [Rust 的内存安全漏洞密度比其历史 C/C++ 代码低 1,000 倍以上](https://blog.google/security/rust-in-android-move-fast-fix-things/) ；Rust 变更的回滚率低四倍，代码评审时间少 25%。

这些数字只属于 Android，不能直接套到每个团队。但它们足以反驳“语言选择已经无所谓”。CISA 同样建议新产品线使用内存安全语言，并逐步迁移暴露面大或权限高的组件。AI 让两种语言都更容易写，却不会废除它们不同的安全模型。

### 类型系统与并发模型仍在塑造故障

如果编译器让非法状态难以表达，智能体能误交付的东西就会改变。所有权、可空性、代数数据类型、effect 边界、结构化并发与竞争检测，不是审美偏好。它们把问题从生产环境前移到生成或编译阶段，修复成本更低。

### 生态仍决定结果是否可运维

包的成熟度、安全响应、数据库驱动、可观测性工具、云支持、招聘深度、发布节奏与长期治理，比“智能体能不能生成这个函数”更重要。基准测试完美、运维生态薄弱的语言，可能恰恰是昂贵选择。

## 哪些能力会比语言熟练度更重要？

1. **系统设计：** 边界、数据所有权、故障隔离、一致性、集成契约，以及修改局部时不必理解整个世界。
2. **运行时理解：** 知道代码之后发生什么：分配、syscall、进程、线程、事件循环、网络连接、数据库锁、缓存与队列。
3. **有证据的架构：** 用 fitness function、依赖规则、契约测试、性能预算、威胁模型与可观测性，把图变成可执行约束。
4. **领域建模：** 模型无法从 ticket 猜出的规则：钱归谁、订单何时最终生效、删除意味着什么、哪些状态转换合法。
5. **验证：** 测试、静态分析、评审、fuzzing、压测、迁移、回滚和生产遥测。只有拒绝能力同步扩展，生成能力才真正可扩展。
6. **可维护性：** 命名、内聚、小接口、决策记录、依赖克制，以及让新人无需原始 prompt 也能读懂的代码库。
7. **技术领导力：** 限定范围、安排风险顺序、制定标准、决定什么不该自动化，并把所有权留在团队里。

这延伸了我们此前的判断： [编码智能体的瓶颈是上下文，而不是原始智能](/zh/blog/ai-coding-agents-context-not-intelligence/) 。上下文告诉智能体现在有什么；工程判断决定应该有什么，以及如何证明它安全。

## 今天的 CTO 应该怎样选择编程语言？

为系统和组织选，不要为智能体选。智能体降低了陌生语法的成本，团队反而可以把更多权重给那些长期存在的性质。

| 决策维度 | 真正要问的问题 | 通常影响 |
| --- | --- | --- |
| 安全 | 语言默认应该阻止哪些缺陷类别？ | 安全暴露面与评审负担 |
| 运行时 | 延迟、吞吐、内存与启动约束是什么？ | 云成本与用户体验 |
| 并发 | 系统如何协调许多同时发生的事情？ | 竞争、背压与运维 |
| 生态 | 该领域的库、驱动与工具是否成熟？ | 交付风险与依赖质量 |
| 团队 | 人能否评审、调试并拥有生成结果？ | Bus factor 与故障响应 |
| 寿命 | 预期产品寿命内，这套技术能否持续维护？ | 招聘与迁移成本 |

流行技术栈很少是答案。更常见的正确答案，是团队能运维的一套无聊主栈，再加上少数刻意的例外，只有当不同运行时或安全模型能带来可测量价值时才例外。AI 降低了实现例外的成本，却没有让持有成本归零。

## 怎样让 AI 生成代码保持可维护？

1. **先写约束，再写 prompt。** 架构边界、非功能需求、禁止依赖、数据规则与验收测试都应该进仓库。
2. **保持小变更。** 每个 pull request 只承载一个明确意图。大型生成 diff 会把人工评审变成仪式性盖章。
3. **让架构可执行。** 依赖测试、linter、schema、API 契约、policy-as-code 和性能预算，都应该让违规自动失败。
4. **测试性质，不只测试样例。** 面对非法输入、重试、并发、部分失败和攻击时，哪些事实必须永远成立？
5. **先评审设计，再评审 diff。** 对错误边界的完美实现仍然是错的。先批准计划，再让智能体执行。
6. **追踪系统结果。** 看变更失败率、评审时间、逃逸缺陷、故障负担、每个成功任务成本与恢复时间，而不是生成行数。
7. **积极删除。** AI 让加代码变便宜。强团队用这份速度试验想法，然后把输掉的实现、依赖和抽象一起删掉。

如果你的 AI 生成代码库已经快速膨胀，可以先用我们的 [AI 生成代码 QA 清单](/zh/blog/qa-for-ai-generated-code/) ，或更偏运维的 [生产就绪清单](/zh/blog/vibe-code-production-readiness-checklist/) 。目标不是证明智能体写了坏代码，而是证明团队可以安全地拥有这个系统。

## AI-first 工程团队应该招聘什么样的人？

招聘能跨层工作的人。他能解释客户规则、画出数据流、预测运行时后果、检查生成代码、设计测试、阅读生产 trace，再把 trade-off 讲给业务听。纯语法专家更容易被替代；能跨层对结果负责的人，价值反而上升。

对初级工程师，这不代表可以跳过编程基础。你从未学会观察内存、并发、数据库与安全，就不可能真正评审它们。用 AI 加速练习，不要用它绕过心智模型。我们关于 [vibe coder 是否会取代初级开发者](/zh/blog/vibe-coders-new-junior-developers/) 的分析，把这一变化转化为招聘与培养模型。对资深工程师，则意味着把隐性的判断写成仓库里可见、可执行的约束，让智能体和经验较少的同事都能遵循。

## 2026 年 8 月 11 日研究更新：Semaprax

[Semaprax](/zh/semaprax/) 是一种围绕稳定语义程序图构建、面向智能体的实验性系统编程语言。其 v0.2 原型让编码智能体能够查询类型化语义、提交绑定到特定修订版的语义补丁，并将经过验证的子集编译为原生可执行文件和浏览器/Wasm 软件包。

它是对本文论点的具体测试，不是论点已被证实。该项目研究语言设计能否把语义、身份、效果、所有权和变更边界直接提供给编码智能体，同时保持源代码对人类可读。带日期的 [Semaprax v0.2 证据台账](/zh/semaprax/evidence/) 区分已实现、已演示、实验性与路线图工作。 [Semaprax 基准](/zh/semaprax/benchmarks/) 明确尚未声称 Token 或成本节省。

如需了解该接口的 Rust 实现，请阅读关于 [语义身份、已检查 HIR 和可重放智能体补丁](/zh/blog/semantic-identity-rust-agent-edits/) 的技术解析。

## 来源与研究说明

- [Anthropic：Agentic coding and persistent returns to expertise](https://www.anthropic.com/research/claude-code-expertise) ，2026 年 6 月 16 日；约 40 万次会话；厂商数据，作者明确披露分类器局限。
- [Anthropic：How AI is transforming work at Anthropic](https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic) ，2025 年 12 月 2 日；内部调查、访谈与使用数据，不代表所有开发者。
- [DORA：State of AI-assisted Software Development 2025](https://dora.dev/research/2025/dora-report/) ；AI 是底层交付系统的放大器。
- [Stack Overflow 2025 开发者调查：AI](https://survey.stackoverflow.co/2025/ai) ；采用率与信任度；整项调查超过 49,000 名受访者。
- [METR：开发者生产力实验更新](https://metr.org/blog/2026-02-24-uplift-update/) ，2026 年 2 月 24 日；为何后续提速幅度仍不确定。
- [GitHub：企业 AI 编程工具调查](https://github.blog/news-insights/research/survey-ai-wave-grows/) ，2025 年 4 月 15 日更新；对跨语言与代码库理解的主观评价。
- [Google Android Security：Rust in Android](https://blog.google/security/rust-in-android-move-fast-fix-things/) ，2025 年 11 月 13 日；Android 特定的安全、回滚与评审数据。

## 常见问题

### AI 会让编程语言过时吗？

不会。AI 会降低语法生成和跨语言翻译的成本，但不同语言仍有不同的运行时、内存安全、并发、生态和运维约束。语言会从个人身份或打字技能，转向一项系统设计决策。

### 哪种编程语言最适合 AI 辅助开发？

不存在通用最佳语言。优先选择团队能评审和运维的成熟技术栈，只有在安全、延迟、并发或生态上有可测量收益时才做例外。主流智能体已经覆盖主要语言，因此智能体是否会写只是次要指标。

### 当 AI 写代码时，哪些技能最重要？

问题定义、领域建模、系统设计、运行时理解、安全、测试、可观测性、可维护性和技术领导力。稀缺能力是定义并验证正确结果，而不是产出第一个看似合理的实现。

### 不懂编程的人能用编码智能体构建生产软件吗？

他们可以构建有用的软件与原型，近期研究也表明领域知识能强力迁移。但生产所有权仍需要有人能评估架构、安全、数据、故障、部署与维护。执行可以委派，责任不能委派给模型。

### 有了 AI，应如何衡量工程生产力？

衡量交付与产品结果：lead time、变更失败率、逃逸缺陷、评审延迟、故障负担、恢复时间、每个成功任务成本与客户价值。代码行数和 PR 数量会奖励产出，即使它正在增加系统风险。

## 最终思考

编程语言作为软件生产门槛，确实没那么重要了；作为安全、运行时、生态和所有权成本的选择，它依然重要。AI 拿掉了意图与实现之间的一部分翻译层，却没有拿掉下面的工程现实。

胜出的不会是生成代码最多的团队，而是能把领域知识与架构判断变成约束、让智能体在约束内执行，并让验证能力与生成能力同步扩张的团队。语法已经过剩，系统思维才是新的瓶颈。

## 你可能也喜欢..

[**瓶颈从来不是智能，而是上下文** 为什么编码智能体把深度工作从亲手敲出解法，转向组装上下文、限定任务与审查结果。](/zh/blog/ai-coding-agents-context-not-intelligence/) [**直接上线 vibe-coded 原型，还是先加固？** 判断何时快速原型已经足够，以及何时真实用户、资金或敏感数据要求先完成生产加固。](/zh/compare/ship-vibe-coded-as-is-vs-harden/)

架构与平台

## 继续浏览此集群

对长期交付产生影响的框架、平台与系统设计选择。

[从核心文章开始**智慧城市软件架构：MQTT、LoRaWAN、Kubernetes 与 Terraform**](/zh/blog/smart-city-architecture-best-practices-2026/)

- [欧盟电池护照软件架构：面向 2027](/zh/blog/eu-battery-passport-software-architecture-2027/)
- [欧盟《数据法》：连接产品 API 清单](/zh/blog/eu-data-act-connected-product-api-2026/)
- [Cursor Origin 与 GitHub 对比：团队该迁移吗？](/zh/blog/cursor-origin-vs-github-code-hosting/)
- [MoneyPrinterTurbo 评测 2026：免费 AI 视频与真实成本](/zh/blog/moneyprinterturbo-review-2026/)
- [Odoo API 集成：决定架构的五条限制](/zh/blog/odoo-erp-api-integration-limits-2026/)

只收重要内容

## 关注与你相关的内容

每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。

[**返回**](/zh/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/)

[Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt

12 分钟 阅读 · 2026年7月15日

[**下一篇**](/zh/blog/colibri-glm-5-2-consumer-hardware/)

邮件订阅新文章 ×

×

通过邮件获取新文章

我们发布时给你一封简短邮件。免费，不做跟踪。

## Structured Data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@id": "https://wavect.io/#organization",
      "@type": [
        "Organization",
        "ProfessionalService",
        "LocalBusiness"
      ],
      "employee": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "founder": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "legalRepresentative": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "name": "Wavect GmbH",
      "subjectOf": {
        "@id": "https://wavect.io/verified-claims.json#dataset",
        "@type": "Dataset",
        "creator": {
          "@id": "https://wavect.io/#organization",
          "@type": [
            "Organization",
            "ProfessionalService",
            "LocalBusiness"
          ]
        },
        "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.",
        "inLanguage": "en",
        "isAccessibleForFree": true,
        "license": "https://creativecommons.org/licenses/by/4.0/",
        "name": "Wavect verified publication claims",
        "url": "https://wavect.io/verified-claims.json"
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/team/kevin-riedl/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Kevin Riedl",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796365",
        "https://www.linkedin.com/in/wsdt",
        "https://github.com/wsdt"
      ],
      "url": "https://wavect.io/team/kevin-riedl/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/team/christof-jori/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Christof Jori",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796367",
        "https://www.linkedin.com/in/jocr77/",
        "https://github.com/jo-chris"
      ],
      "url": "https://wavect.io/team/christof-jori/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/#website",
      "@type": "WebSite",
      "inLanguage": [
        "en",
        "de",
        "es",
        "zh"
      ],
      "name": "Wavect",
      "potentialAction": {
        "@type": "SearchAction",
        "query-input": "required name=search_term_string",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://wavect.io/search/?q={search_term_string}"
        }
      },
      "publisher": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/zh/blog/programming-languages-matter-less-ai/#webpage",
      "@type": "WebPage",
      "dateModified": "2026-07-15",
      "inLanguage": "zh",
      "isPartOf": {
        "@id": "https://wavect.io/#website",
        "@type": "WebSite"
      },
      "lastReviewed": "2026-07-15",
      "url": "https://wavect.io/zh/blog/programming-languages-matter-less-ai/"
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "abstract": "编程语言作为代码生产门槛，确实没那么重要了；作为系统决策，它依然重要。AI 让语法、 样板代码与跨语言翻译变便宜，但运行时、内存安全、并发、架构、领域规则、验证与 可维护性仍决定结果是否安全、是否值得长期持有。最新证据展示了新的分工：人类负责 大多数规划，智能体负责执行；领域知识让可验证成功率相比新手会话提高一倍以上； DORA 则发现 AI 会同时放大交付系统的优势与缺陷，包括不稳定性。正确策略不是生成 最多代码，而是按长期系统约束选语言，把架构写成可执行测试与策略，保持小变更，并让 评审、拒绝与可观测性和生成能力同步扩张。",
  "articleBody": " 博客概览/交付与 QA/架构与平台 编程语言没那么重要了，软件工程却更重要了。 要点速览 编程语言作为代码生产门槛，确实没那么重要了；作为系统决策，它依然重要。AI 让语法、 样板代码与跨语言翻译变便宜，但运行时、内存安全、并发、架构、领域规则、验证与 可维护性仍决定结果是否安全、是否值得长期持有。最新证据展示了新的分工：人类负责 大多数规划，智能体负责执行；领域知识让可验证成功率相比新手会话提高一倍以上； DORA 则发现 AI 会同时放大交付系统的优势与缺陷，包括不稳定性。正确策略不是生成 最多代码，而是按长期系统约束选语言，把架构写成可执行测试与策略，保持小变更，并让 评审、拒绝与可观测性和生成能力同步扩张。 在 AI 时代，编程语言还重要吗？如果它衡量的是谁能产出代码，那么重要性确实下降了；如果它代表的是系统约束，就依然重要。AI 可以随时生成 Java、Go、Python、Rust 或 TypeScript，却无法抹去它们在运行时、内存、并发、安全、生态与维护上的差异。语法越来越便宜，工程判断没有。 所以，“编程语言已经不重要”这句标题，几乎对了，却对在最没用的地方。团队亲手写的常规代码变少了，借助编码智能体产出的软件变多了。但代码来得越快，越需要有人知道究竟该造什么、各部分如何衔接、运行时在压力下会怎样，以及两年后另一个人能否安全地修改这个系统。 “编程语言没那么重要”究竟是什么意思？ 它意味着，把明确需求翻译成有效语法这件事的市场价值正在下降；并不意味着所有实现选择都可以互换。编码智能体可以在几分钟内把一段数据转换逻辑从 Python 改写成 Go。但这段逻辑究竟该放在请求处理器、队列 worker、数据库查询、流处理器里，还是根本不该存在，属于完全不同的一类决策。 被 AI 变便宜的能力被 AI 放大的价值 记住语法与库调用定义正确的问题与验收标准 生成样板代码与适配器决定系统边界与所有权 在语言之间翻译理解运行时、内存与并发行为 快速给出一个貌似合理的初版证明正确性、安全性与可运维性 迅速增加代码让系统保持小、清楚、可维护 GitHub 调查了美国、巴西、德国和印度 2,000 名企业软件团队成员，其中 60% 至 71% 的受访者认为，AI 工具让采用新语言或理解现有代码库变得容易。语言门槛确实在下降，但这不等于语言选择的后果消失了。 开发者真的在减少手写代码吗？ 世界上没有一块仪表盘统计手写代码与 AI 代码的总量，所以任何全球统一百分比都是表演。但多项使用研究展示了明确方向。Stack Overflow 2025 开发者调查显示，84% 的受访者已经或计划使用 AI 工具。在部分接入 AI 的人群中，写代码是最常见用途，占 59%。 在 Anthropic 内部，请注意，这是厂商自身，不是中立样本，132 名工程师与研究人员自报在 59% 的工作中使用 Claude，生产力提高 50%。Anthropic 还观察到每位工程师每天合并的 pull request 增加了 67%。最值得看的不是自报提升的精确数字，而是变化形态：每类任务少花一点时间，总产出明显增加，而且 27% 的 AI 辅助工作原本根本不会被做。 Anthropic 此前对 50 万次编程交互的分析中，79% 的 Claude Code 对话被归类为自动化，21% 是增强。到 2026 年 6 月，一项覆盖约 40 万次 Claude Code 会话的研究把分工描述得更清楚：人类做大多数关于做什么的规划决策；Claude 做大多数关于怎么做的执行决策。 AI 会让软件专业能力贬值吗？ 不会。它只是在重新分配专业能力的回报。 Anthropic 2026 年 6 月的研究中，被评为新手的会话，严格意义上的“可验证成功率”是 15%；中级与专家会话为 28% 至 33%。研究者发现，一个人带入的领域知识越多，智能体每条指令能完成的工作就越多。他们的结论很直接：把智能体导向成功，更多取决于对领域的掌握，而不是亲手写代码的能力。 \"当代码变得过剩，判断力就成了稀缺输入。最有价值的不再是敲出最多实现的人，而是能决定该造什么、约束智能体，并证明结果有资格运行的人。\" 这不代表所有架构师都会赢、所有程序员都会输。脱离实现反馈的架构很快会变成 PowerPoint。真正强的工程师，仍然离代码、trace、数据库、队列、部署流水线和故障足够近，能发现自己的系统模型何时错了；他们只是减少了把稀缺注意力花在可预测的手工输入上。 为什么关于生产力的研究看起来互相矛盾？ 因为“AI 让开发者更快”不是一个单一实验。任务熟悉度、工具代际、仓库质量、开发者经验、评审延迟，以及是否并行运行多个智能体，都会改变结果。 METR 在 2025 年初的对照实验中发现，经验丰富的开源开发者在自己非常熟悉的代码库里使用 AI，完成任务反而慢了 19%。2026 年 2 月，METR 表示后续数据开始指向提速，却也坦承选择偏差和计时问题让估计不可靠。其更新最诚实的表述是：到 2026 年初，开发者很可能比此前获得了更多加速，但幅度无法可靠测量。 DORA 2025 的研究解释了部分矛盾：AI 是放大器。它与吞吐和产品绩效正相关，但与软件交付稳定性仍是负相关。换成直白的话：AI 把更多变更推过系统，也让薄弱测试、过大批次、缓慢反馈和不成熟的平台工程暴露出来。 所以，正确问题不是“AI 让一个开发者快了多少”，而是“实现吞吐上涨后，整个交付系统发生什么”。如果评审、测试、架构决策、安全关卡、部署保障与可观测性没有同步扩容，公司每周增加的是风险，而不是价值。 为什么编程语言依然重要？ 因为语言不只是语法，而是一组默认行为与保证。智能体关掉 pull request 后，这些东西还留在系统里。 运行时行为最终会写在账单上 垃圾回收、启动时间、JIT 预热、事件循环、线程调度、异步运行时、二进制体积与 FFI 边界，都会影响延迟、基础设施成本、部署能力和失效模式。LLM 可以写出两个版本，生产环境仍要为你的选择买单。 内存模型最终会写进安全事件 Google 的 Android 团队提供了少见的真实对比。随着新原生代码向 Rust 迁移，2025 年内存安全问题首次降到 Android 全部漏洞的 20% 以下。Google 估计，Rust 的内存安全漏洞密度比其历史 C/C++ 代码低 1,000 倍以上；Rust 变更的回滚率低四倍，代码评审时间少 25%。 这些数字只属于 Android，不能直接套到每个团队。但它们足以反驳“语言选择已经无所谓”。CISA 同样建议新产品线使用内存安全语言，并逐步迁移暴露面大或权限高的组件。AI 让两种语言都更容易写，却不会废除它们不同的安全模型。 类型系统与并发模型仍在塑造故障 如果编译器让非法状态难以表达，智能体能误交付的东西就会改变。所有权、可空性、代数数据类型、effect 边界、结构化并发与竞争检测，不是审美偏好。它们把问题从生产环境前移到生成或编译阶段，修复成本更低。 生态仍决定结果是否可运维 包的成熟度、安全响应、数据库驱动、可观测性工具、云支持、招聘深度、发布节奏与长期治理，比“智能体能不能生成这个函数”更重要。基准测试完美、运维生态薄弱的语言，可能恰恰是昂贵选择。 哪些能力会比语言熟练度更重要？ 系统设计：边界、数据所有权、故障隔离、一致性、集成契约，以及修改局部时不必理解整个世界。 运行时理解：知道代码之后发生什么：分配、syscall、进程、线程、事件循环、网络连接、数据库锁、缓存与队列。 有证据的架构：用 fitness function、依赖规则、契约测试、性能预算、威胁模型与可观测性，把图变成可执行约束。 领域建模：模型无法从 ticket 猜出的规则：钱归谁、订单何时最终生效、删除意味着什么、哪些状态转换合法。 验证：测试、静态分析、评审、fuzzing、压测、迁移、回滚和生产遥测。只有拒绝能力同步扩展，生成能力才真正可扩展。 可维护性：命名、内聚、小接口、决策记录、依赖克制，以及让新人无需原始 prompt 也能读懂的代码库。 技术领导力：限定范围、安排风险顺序、制定标准、决定什么不该自动化，并把所有权留在团队里。 这延伸了我们此前的判断：编码智能体的瓶颈是上下文，而不是原始智能。上下文告诉智能体现在有什么；工程判断决定应该有什么，以及如何证明它安全。 今天的 CTO 应该怎样选择编程语言？ 为系统和组织选，不要为智能体选。智能体降低了陌生语法的成本，团队反而可以把更多权重给那些长期存在的性质。 决策维度真正要问的问题通常影响 安全语言默认应该阻止哪些缺陷类别？安全暴露面与评审负担 运行时延迟、吞吐、内存与启动约束是什么？云成本与用户体验 并发系统如何协调许多同时发生的事情？竞争、背压与运维 生态该领域的库、驱动与工具是否成熟？交付风险与依赖质量 团队人能否评审、调试并拥有生成结果？Bus factor 与故障响应 寿命预期产品寿命内，这套技术能否持续维护？招聘与迁移成本 流行技术栈很少是答案。更常见的正确答案，是团队能运维的一套无聊主栈，再加上少数刻意的例外，只有当不同运行时或安全模型能带来可测量价值时才例外。AI 降低了实现例外的成本，却没有让持有成本归零。 怎样让 AI 生成代码保持可维护？ 先写约束，再写 prompt。架构边界、非功能需求、禁止依赖、数据规则与验收测试都应该进仓库。 保持小变更。每个 pull request 只承载一个明确意图。大型生成 diff 会把人工评审变成仪式性盖章。 让架构可执行。依赖测试、linter、schema、API 契约、policy-as-code 和性能预算，都应该让违规自动失败。 测试性质，不只测试样例。面对非法输入、重试、并发、部分失败和攻击时，哪些事实必须永远成立？ 先评审设计，再评审 diff。对错误边界的完美实现仍然是错的。先批准计划，再让智能体执行。 追踪系统结果。看变更失败率、评审时间、逃逸缺陷、故障负担、每个成功任务成本与恢复时间，而不是生成行数。 积极删除。AI 让加代码变便宜。强团队用这份速度试验想法，然后把输掉的实现、依赖和抽象一起删掉。 如果你的 AI 生成代码库已经快速膨胀，可以先用我们的AI 生成代码 QA 清单，或更偏运维的生产就绪清单。目标不是证明智能体写了坏代码，而是证明团队可以安全地拥有这个系统。 AI-first 工程团队应该招聘什么样的人？ 招聘能跨层工作的人。他能解释客户规则、画出数据流、预测运行时后果、检查生成代码、设计测试、阅读生产 trace，再把 trade-off 讲给业务听。纯语法专家更容易被替代；能跨层对结果负责的人，价值反而上升。 对初级工程师，这不代表可以跳过编程基础。你从未学会观察内存、并发、数据库与安全，就不可能真正评审它们。用 AI 加速练习，不要用它绕过心智模型。我们关于 vibe coder 是否会取代初级开发者的分析，把这一变化转化为招聘与培养模型。对资深工程师，则意味着把隐性的判断写成仓库里可见、可执行的约束，让智能体和经验较少的同事都能遵循。 2026 年 8 月 11 日研究更新：Semaprax Semaprax 是一种围绕稳定语义程序图构建、面向智能体的实验性系统编程语言。其 v0.2 原型让编码智能体能够查询类型化语义、提交绑定到特定修订版的语义补丁，并将经过验证的子集编译为原生可执行文件和浏览器/Wasm 软件包。 它是对本文论点的具体测试，不是论点已被证实。该项目研究语言设计能否把语义、身份、效果、所有权和变更边界直接提供给编码智能体，同时保持源代码对人类可读。带日期的 Semaprax v0.2 证据台账区分已实现、已演示、实验性与路线图工作。Semaprax 基准明确尚未声称 Token 或成本节省。 如需了解该接口的 Rust 实现，请阅读关于语义身份、已检查 HIR 和可重放智能体补丁的技术解析。 来源与研究说明 Anthropic：Agentic",
  "articleSection": "Engineering",
  "author": {
    "@id": "https://wavect.io/team/kevin-riedl/#person",
    "@type": "Person",
    "name": "Kevin Riedl",
    "sameAs": [
      "https://www.wikidata.org/wiki/Q139796365",
      "https://www.linkedin.com/in/wsdt",
      "https://github.com/wsdt"
    ],
    "url": "https://wavect.io/team/kevin-riedl/"
  },
  "dateModified": "2026-07-15",
  "datePublished": "2026-07-15",
  "description": "编程语言作为代码生产门槛，确实没那么重要了；作为系统决策，它依然重要。AI 让语法、 样板代码与跨语言翻译变便宜，但运行时、内存安全、并发、架构、领域规则、验证与 可维护性仍决定结果是否安全、是否值得长期持有。最新证据展示了新的分工：人类负责 大多数规划，智能体负责执行；领域知识让可验证成功率相比新手会话提高一倍以上； DORA 则发现 AI 会同时放大交付系统的优势与缺陷，包括不稳定性。正确策略不是生成 最多代码，而是按长期系统约束选语言，把架构写成可执行测试与策略，保持小变更，并让 评审、拒绝与可观测性和生成能力同步扩张。",
  "headline": "编程语言没那么重要了，软件工程却更重要了",
  "image": "https://wavect.io/img/blog/headers/header_programming-languages-matter-less-ai.svg",
  "inLanguage": "zh",
  "mainEntityOfPage": {
    "@id": "https://wavect.io/zh/blog/programming-languages-matter-less-ai/",
    "@type": "WebPage"
  },
  "publisher": {
    "@id": "https://wavect.io/#organization",
    "@type": [
      "Organization",
      "ProfessionalService",
      "LocalBusiness"
    ]
  },
  "url": "https://wavect.io/zh/blog/programming-languages-matter-less-ai/",
  "wordCount": 430
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/",
      "name": "首页",
      "position": 1
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/overview/",
      "name": "博客概览",
      "position": 2
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/topics/delivery-qa/",
      "name": "交付与 QA",
      "position": 3
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/clusters/architecture-platforms/",
      "name": "架构与平台",
      "position": 4
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/programming-languages-matter-less-ai/",
      "name": "AI 时代，编程语言还重要吗？| ",
      "position": 5
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不会。AI 会降低语法生成和跨语言翻译的成本，但不同语言仍有不同的运行时、内存安全、并发、生态和运维约束。语言会从个人身份或打字技能，转向一项系统设计决策。"
      },
      "name": "AI 会让编程语言过时吗？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不存在通用最佳语言。优先选择团队能评审和运维的成熟技术栈，只有在安全、延迟、并发或生态上有可测量收益时才做例外。主流智能体已经覆盖主要语言，因此智能体是否会写只是次要指标。"
      },
      "name": "哪种编程语言最适合 AI 辅助开发？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "问题定义、领域建模、系统设计、运行时理解、安全、测试、可观测性、可维护性和技术领导力。稀缺能力是定义并验证正确结果，而不是产出第一个看似合理的实现。"
      },
      "name": "当 AI 写代码时，哪些技能最重要？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "他们可以构建有用的软件与原型，近期研究也表明领域知识能强力迁移。但生产所有权仍需要有人能评估架构、安全、数据、故障、部署与维护。执行可以委派，责任不能委派给模型。"
      },
      "name": "不懂编程的人能用编码智能体构建生产软件吗？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "衡量交付与产品结果：lead time、变更失败率、逃逸缺陷、评审延迟、故障负担、恢复时间、每个成功任务成本与客户价值。代码行数和 PR 数量会奖励产出，即使它正在增加系统风险。"
      },
      "name": "有了 AI，应如何衡量工程生产力？"
    }
  ]
}
```
