AI 正在重写程序员的能力结构

这两年，AI 编程工具的发展速度快得有点不像话。

很多程序员应该都经历过类似的时刻：你把一段报错贴给 Claude，或者在 Cursor 里简单描述一下需求，几秒钟之后，一个相当完整的实现就已经出现在屏幕上了。它甚至不只是“能跑”，很多时候连代码结构、注释风格、工程组织都已经像模像样。

第一次体验的时候，人其实会有一种轻微的恍惚感。

因为过去那些需要花很长时间积累的能力，好像突然被压缩了。

尤其是在一些原本学习门槛很高的语言上，这种感受会更加明显。

比如 Rust。

如果是几年前，一个普通开发者想认真学习 Rust，其实是一件挺痛苦的事情。Ownership、生命周期、Trait、Borrow Checker……很多概念都不像传统语言那样直观。过去很多人不是不会写逻辑，而是根本过不了编译器。

所以早期的 Rust 社区，总有一种“硬核技术圈”的气质。会 Rust，本身就像是一种能力证明。

但现在情况已经开始变化了。

你会发现，即使对 Rust 并没有那么深的理解，只要大体知道自己想做什么，AI 就已经能够帮你补齐大量细节。它会解释 borrow checker，会修生命周期，会自动补 trait，会生成工程结构，甚至连一些晦涩的编译错误都能给你翻译成人话。

以前那些需要几年经验慢慢积累的东西，现在正在被 AI 快速压缩。

于是我越来越觉得：

AI 真正改变的，也许并不只是“程序员会不会被替代”这么简单。

它更像是在重新定义：

程序员真正的价值，到底在哪里。

过去很长一段时间里，“会写代码”本身就是一种相当稀缺的能力。

那时候的软件开发存在大量的信息摩擦。你需要记忆语法、查 API、翻文档、研究框架源码、解决环境问题，还要和各种奇怪的 Bug 反复搏斗。很多能力，其实是靠时间硬堆出来的。

但 AI 出现之后，这些摩擦正在迅速减少。

因为代码这种东西，实在太适合 AI 学习了。

它高度结构化，反馈明确，而且互联网上还有海量训练数据。于是 AI 在代码生成这件事上，天然就拥有一种极强的优势。尤其是在样板代码、API 调用、代码补全、多语言切换这些方面，人类其实已经很难和 AI 拼效率了。

所以我越来越觉得，Programming 这件事本身，正在逐渐从“核心竞争力”变成一种基础能力。

这并不意味着它不重要。

而是它越来越像：“会使用搜索引擎”、“会使用 IDE”、“会使用 Git”一样，开始成为一种默认能力。

未来大部分会使用 AI 工具的人，某种意义上都会默认具备一定程度的 Programming 能力。

而真正的问题，开始慢慢变成：

当“会写代码”不再稀缺之后，程序员真正的价值还剩下什么？

以前看到一种对程序员能力的划分，现在看越来越有意思。

它大概把程序开发能力分成三个层次：

第一层是 Programming，也就是编码本身；第二层是 Develop，是真正把东西开发出来；第三层则更接近 Operations，也就是让系统长期运转、持续演化的能力。

AI 对这三层的影响，其实完全不一样。

第一层，也就是 Programming，本质上是“如何把代码写出来”。它关注的是语法、算法、局部逻辑、API 调用这些东西。

而这一层，恰恰是 AI 最擅长的部分。

因为绝大多数代码工作，本身就存在大量重复结构。CRUD、接口封装、前端组件、配置生成、测试代码……很多东西对于 AI 来说，其实已经接近一种工业化生产。

所以我越来越觉得，未来真正的问题可能已经不是：

“你会不会写代码？”

而是：

“你知不知道应该写什么代码。”

但真正的软件开发，其实从来都不只是写代码。

真正复杂的部分，很多时候恰恰是从代码之外才刚刚开始。

一个真正能落地的软件系统，需要考虑的事情远比“实现功能”复杂得多。架构怎么拆？数据怎么流动？系统如何迭代？权限如何设计？测试怎么做？日志怎么管理？系统如何长期维护？

这些东西合在一起，才真正构成了“开发”这件事。

而我觉得，AI 目前在这一层，其实还远远没有达到第一层那种“碾压式”的程度。

很多人第一次用 Cursor、Claude Code 的时候都会特别兴奋，因为那种“想到什么它就能写什么”的感觉确实很震撼。但真正做复杂项目之后，很快就会遇到另一个问题：

AI 开始失控。

它会乱改代码，会误伤别的模块，会把原本清晰的架构慢慢搞乱。你让它改一个按钮，它顺手把半个页面都重构了；你让它修一个接口，它顺便帮你“优化”了一堆根本不该动的逻辑。

最后整个系统开始逐渐变成一种“半自动堆屎山”。

于是你会发现，未来的软件工程能力，可能会越来越变成：

如何管理 AI 与系统协作。

比如一个 Feature 应该怎么拆，Prompt 应该怎么组织，Context 应该怎么维护，Agent Workflow 应该如何设计，怎么限制 AI 的修改边界，怎么让系统能够一步一步稳定演化。

这些东西，其实已经不再是传统意义上的“编码能力”了。

它更是一种工程组织能力。

过去的软件工程，很多时候是在管理人；未来的软件工程，很可能会越来越变成：

人管理 AI，AI 管理代码。

也正因为如此，我反而开始觉得，那些曾经被很多人认为“有点过时”的软件工程方法论，可能会重新焕发生命力。

比如 Scrum、DDD、TDD、XP、敏捷开发这些东西。

很多人以前觉得它们繁琐、形式主义，但现在回头看，会发现它们真正解决的问题，其实从来都不是“代码怎么写”。

它们解决的，本质上一直都是：

如何控制复杂度。

过去是在控制人的复杂度、团队的复杂度、协作的复杂度。

而未来，可能会变成：

管理 AI 的复杂度、管理上下文的复杂度、管理系统演化的复杂度。

甚至未来可能真的会出现一种新的东西：

AI-Native Software Engineering。

它不是传统软件工程，也不是简单的 AI Coding，而是一种真正面向“人 + AI 协作”的工程体系。

但如果继续往上看，还有一个比 Develop 更重要的层次。

那就是 Operations。

不过这里的 Operations，已经不只是传统意义上的“运维”了。

它更像是：

让复杂系统长期活下去的能力。

因为任何系统，只要活得够久，都会开始腐烂。

代码会膨胀，架构会变形，历史包袱会越来越重。很多系统刚做出来的时候都很优雅，但时间一长，几乎都会慢慢失控。

所以真正困难的事情，从来不是：

“把系统做出来”。

而是：

“如何让系统长期稳定演化”。

这已经开始接近一种更高层的能力了。

它不只是技术，还包括产品、运营、商业、用户生态、组织协作，甚至包括一个系统如何在现实世界里持续生存。

而且我越来越觉得，未来真正高级的能力，可能会越来越体现为一种“跨领域跃迁能力”。

过去很多程序员的能力，其实都绑定在某种语言、某个框架、某个行业上。

但 AI 逐渐拉平底层技术门槛之后，真正重要的东西，可能会开始变成：

对复杂系统共性的理解能力。

一个真正强的人，也许可以从社交产品跳到游戏，从工具软件跳到 AI 系统，从推荐系统跳到内容平台。

因为他真正理解的，已经不只是技术细节，而是：

系统如何演化、用户如何反馈、复杂度如何增长、协作如何形成、产品如何长期存在。

我觉得这种能力，才是现在以及未来真正稀缺的东西。

所以我并不觉得程序员会消失。

但我越来越觉得，程序员的价值坐标系，正在整体向上迁移。

Programming 被压缩。

Develop 被重构。

Operations 被放大。

未来真正稀缺的，不再是“生产代码”的能力。

而是：

理解复杂世界，并让复杂系统持续运转的能力。