--- 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" author: ["Kevin Riedl"] published: "2026-07-15" updated: "2026-09-16" reviewed: "2026-09-16" --- # 编程语言没那么重要了，软件工程却更重要了。 [**返回**](/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日 最近审核 2026年9月16日 [**下一篇**](/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 及合作机构同样建议](https://www.cisa.gov/sites/default/files/2025-02/secure-by-design-alert-eliminating-buffer-overflow-vulnerabilities-508c.pdf) 新代码使用内存安全语言，并逐步迁移暴露面大或权限高的组件。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/) 的分析，把这一变化转化为招聘与培养模型。对资深工程师，则意味着把隐性的判断写成仓库里可见、可执行的约束，让智能体和经验较少的同事都能遵循。 **Semaprax研究更新：2026年10月15日** Semaprax是一门开源、面向智能体的系统编程语言，目前处于Beta阶段。可读的.spx源码保留在Git中，编码智能体可以查询带类型的程序语义、检查源码定律，并提出绑定特定修订的修改。0.9.0在类型化运行时Agent、编译器连接的开发工具和受限的原生、Rust、WebAssembly配置之上，新增预编译安装脚本、策略优先的模型路由及更明确的修复提示。 [发布记录 v0.9.0](https://github.com/wavect/semaprax/releases/tag/v0.9.0) · [证据](/zh/semaprax/evidence/) · [Semaprax 语义程序图](/zh/semaprax/architecture/) 当前证据包含实测的紧凑上下文 token 数、模型提供方用量回执、付费开发工具评测、Rust 应用开销及经检查的热重载耗时。结果同时记录了性能退步和未通过的成本评测；尚未证明普遍的成本或生产率优势。 [Semaprax 对编码智能体更便宜吗？](/zh/semaprax/benchmarks/) 如需了解该接口的 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 特定的安全、回滚与评审数据。 - [CISA 及合作机构：消除缓冲区溢出漏洞的 Secure by Design 警报](https://www.cisa.gov/sites/default/files/2025-02/secure-by-design-alert-eliminating-buffer-overflow-vulnerabilities-508c.pdf) ；关于新代码采用内存安全语言和分阶段迁移的建议。 ## 常见问题 ### 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/) - [NVIDIA Run:ai 开源：GPU 编排不等于软件工厂](/zh/blog/nvidia-runai-open-source-gpu-software-factory/) - [GitButler 并行 AI 智能体：多个分支，一个运行中的应用](/zh/blog/gitbutler-parallel-ai-agents-one-workspace/) - [Vendo SaaS 集成：租户隔离与审批边界](/zh/blog/vendo-saas-tenant-isolation/) - [SaaS 集成 AgentMail：租户隔离与重复邮件恢复](/zh/blog/agentmail-saas-duplicate-sends-recovery/) - [AI 编程时代的软件护城河：谁来维护你构建的系统？](/zh/blog/ai-coding-software-moat-operations/) [上一篇文章**Git Worktree 与 Jujutsu：AI 编程智能体版本控制决策指南（2026）**](/zh/blog/git-worktrees-vs-jujutsu-ai-coding-agents/) [下一篇文章**企业软件的未来**](/zh/blog/future-of-enterprise-software/) [**返回**](/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日 最近审核 2026年9月16日 [**下一篇**](/zh/blog/colibri-glm-5-2-consumer-hardware/)