我让 AI 修改一个 C++ 项目后,发现程序员真正危险的不是写代码

很多程序员第一次真正感到不安，不是因为 AI 会聊天，也不是因为它会写八股文。

而是因为它开始能改代码了。

以前我们还能安慰自己：它只是补全几行、写个脚本、生成一段 demo。

但现在 Codex、Claude Code、Cursor 这类 coding agent，已经能读仓库、跑命令、改文件、看报错、继续修，甚至还能先帮你做 code review。

于是那个老问题又回来了：

程序员会不会被 AI 取代？

我觉得这个问题，如果只拿一个 Python 脚本、一个前端页面、一个算法题来判断，很容易得出过于乐观或者过于悲观的结论。

因为那些场景里，代码和结果之间的距离很短。

输入是什么，输出是什么，错了马上能看出来。

但真实工程不是这样。

尤其是 C++ 工程。

你让 AI 改一个 C++ 项目，很快会发现：真正难的不是让它写出一段看起来正确的代码，而是让它理解这段代码背后那些没有写在代码里的东西。

线程模型。

对象归属。

生命周期假设。

ABI 边界。

性能约束。

历史兼容。

团队默认的代码风格。

以及那些老程序员一眼能看出来，但新人和 AI 都很容易忽略的工程契约。

试完之后，我对“AI 会不会替代程序员”这件事，反而有了一个更清楚的判断：

程序员真正危险的，不是不会写代码。

真正危险的是，当代码变得越来越便宜，你还只把自己的价值放在“我能写代码”上。

AI 真正便宜掉的，不是编程，而是“局部实现”

过去我们说 AI 编程，很多人想到的是 Copilot 那种体验：你写一半，它补一半。

这当然有用，但它更像一个聪明的输入法。

现在的变化不一样。

新一代 coding agent 开始参与完整任务：它会先看项目结构，再找相关文件，然后修改代码，接着跑测试。如果测试失败，它会读错误信息，再改一轮。

这意味着 AI 不再只是帮你敲键盘，而是在尝试进入一个真实的工程现场。

这件事对程序员的冲击很大。

因为很多初级工作，本质上就是在工程现场里完成一串相对明确的动作：

找到函数。

改一个分支。

补一个测试。

修一个编译错误。

根据 review 意见再改一次。

如果任务边界足够清楚，AI 的确可以把这些工作做得越来越快。

但这里有一个关键区别：

AI 便宜掉的不是“软件工程”，而是“局部实现”。

这句话很重要。

很多人把“会写代码”误以为就是“会做工程”。

但在真实项目里，写代码只是工程链条中最显眼的一环，不是最贵的一环。

最贵的部分常常是：判断该不该改，改在哪里，改到什么程度，风险在哪里，怎么证明它没有破坏其他东西。

AI 越强，这个区别越明显。

过去局部实现比较费时间，所以它遮住了很多人的短板。

以后局部实现越来越快，真正暴露出来的就是：你到底有没有工程判断。

C++ 项目为什么更适合作为压力测试

很多 AI 编程演示看起来很惊艳，是因为场景足够干净。

一个函数。

一个文件。

一个明确输入输出。

甚至没有复杂依赖。

但 C++ 工程通常不是这样。

你改一个 .cpp 文件，可能牵扯到对应的头文件；改一个类的成员，可能影响构造、析构、拷贝、移动；改一个接口，可能影响 ABI；改一段异步逻辑，可能引入悬垂引用；改一个锁，可能让死锁从“偶现”变成“必现”。

还有更麻烦的：很多 C++ bug 不会在第一时间喊出来。

对象生命周期错了，可能能编译。

std::move 后继续使用，可能能编译。

数据竞争，可能本机跑十次都没问题。

UB 更是这样，今天正常，明天优化选项一开就变脸。

所以 C++ 项目对 AI 的要求，不只是“能不能生成语法正确的代码”。

它要求 AI 理解上下文、尊重边界、知道哪些地方不能乱碰，并且能用测试和工具证明修改是可靠的。

这也是 C++ 程序员看 AI 编程时，不应该只问“它能不能写出来”的原因。

更应该问：

它知道这段代码背后的契约吗？

比如一个函数签名是这样：

void setBuffer(const char* data, size_t len);

这看起来只是两个参数。

但工程里真正重要的问题是：

这个函数会拷贝数据，还是只保存指针？

调用方传进来的内存要活多久？

能不能传空指针？

多线程下能不能同时调用？

异常策略是什么？

失败时对象处于什么状态？

这些东西，很多时候不会全部写在函数名里。

它们藏在调用习惯、历史实现、测试用例和团队共识里。

这就是 C++ 项目最适合测试 AI 编程的地方：它逼你承认，代码不只是文本，代码是一组工程契约的表面。

如果一个程序员只看见文本，他和 AI 的差距会越来越小。

如果一个程序员能看见契约，他的价值反而会变大。

真正的分水岭：你能不能把隐含契约显性化

我现在对 AI 编程工具的判断比较简单：

边界越清楚，它越强。边界越模糊，它越危险。

比如你让它做这些事，它已经很有价值：

给一个函数补边界条件。

根据失败测试定位一个明显 bug。

把重复代码整理成一个小 helper。

补一组单元测试。

根据编译报错修 include 或类型问题。

解释一段不熟悉的代码。

把 clang-tidy 或 sanitizer 报出来的问题逐个修掉。

这些任务都有一个共同点：目标明确，反馈明确，错了能比较快暴露。

AI 在这里像一个很能干的执行者。

但如果你只是说“帮我优化一下这个模块”，事情就变了。

优化什么？

延迟、吞吐、内存、可读性、编译速度，还是接口稳定性？

能不能改 public API？

能不能引入依赖？

能不能改变线程模型？

性能提升多少才算值得？

如果这些问题没人回答，AI 就只能猜。

而在 C++ 工程里，让一个东西靠猜，往往就是事故的开始。

所以未来程序员最关键的能力，不是把一句自然语言需求丢给 AI。

而是把一个模糊问题，拆成 AI 可以安全执行的工程任务。

比如你不是说：

“帮我修一下这个 crash。”

而是说：

先确认 crash 栈在哪个线程。

再找最近改过的对象所有权逻辑。

先不要改代码，先列出可能的生命周期路径。

每个方案说明会不会改变 public API。

最后只实现风险最小的方案，并补一个能复现问题的测试。

这不是提示词技巧。

这是软件工程能力。

真正的变化在这里：

过去你写代码，是把脑子里的判断翻译成代码。

以后你用 AI，是把脑子里的判断翻译成任务边界、约束和验收标准。

翻译对象变了，但判断没有消失。

甚至更重要了。

AI 时代，最值钱的是验证闭环

很多人担心 AI 写错代码。

这个担心没错，但还不够准确。

更准确地说，危险的是你让 AI 写完代码，却没有验证闭环。

在 C++ 项目里，验证闭环至少包括几层：

能不能编译。

给 AI 搭工程现场，而不是许愿

未来会写代码的人当然还需要。

但只会等需求、写实现、交差的人，会越来越被动。

更有价值的程序员，会开始做另一件事：

给 AI 搭一个稳定工作的工程现场。

这个现场里应该有清楚的项目规则。

比如接口命名、成员变量风格、日志规范、异常策略、线程模型、模块边界。

应该有清楚的任务说明。

比如目标、上下文、约束、验收标准。

应该有自动化验证。

比如构建、单测、静态检查、sanitizer、benchmark。

应该有 review 机制。

AI 可以先扫一遍低级问题，人再看设计、边界和取舍。

如果这些东西都没有，AI 就只能靠猜。

从这个角度看，AI 编程真正推动的不是“程序员消失”，而是程序员工作重心发生变化。

过去你花很多时间写代码。

以后你会花更多时间定义任务、整理上下文、制定规则、设计验证、审查结果。

写代码仍然重要，但它不再是全部。

更准确地说，程序员会从“代码生产者”，越来越变成“工程系统的设计者和验收者”。

这句话听起来有点抽象，但落到日常工作里其实很具体：

你给 AI 的不是一句“帮我改一下”。

你给它的是一段可执行的工程协议：

只能改哪些文件。

不能破坏哪些接口。

必须跑哪些测试。

遇到不确定性先停下来说明。

每个修改都要解释风险。

这才是 AI 时代真正有效的编程方式。

不是向 AI 许愿。

而是给 AI 搭工地、划红线、装监控、定验收。

最后真正危险的是什么？

所以，回到开头那个问题：

AI 会不会取代程序员？

我的答案是：它会取代一部分只会执行局部任务的人。

但它也会放大另一部分人。

能把问题讲清楚的人，会被放大。

能把复杂工程拆成可验证任务的人，会被放大。

能看懂 AI 代码风险的人，会被放大。

能把团队经验沉淀成规则、测试和工具链的人，会被放大。

对 C++ 程序员来说，这其实是一个很现实的提醒。

你过去积累的那些看起来“很底层、很麻烦、很难讲清楚”的经验，并没有过时。

对象生命周期、并发边界、性能判断、构建系统、测试习惯、代码规范，这些东西在 AI 时代反而更重要。

因为 AI 能帮你更快地产生代码。

但它不能替你承担工程后果。

如果说过去程序员的核心问题是：

“我能不能把代码写出来？”

那么 AI 时代更重要的问题会变成：

“我能不能判断这段代码是否值得存在？”

“我能不能证明它可以进入工程？”

“我能不能把模糊需求变成可验证任务？”

这才是很多人读完 AI 编程新闻后，真正应该意识到的变化。

程序员真正危险的，不是不会写代码。

而是当代码越来越便宜时，你还没有学会判断什么代码值得写、应该怎么写、以及怎样证明它真的可以交付。

这不是焦虑。

这是新的分工已经开始了。

结尾

我是 everystep 的作者。

我写这些文章，只做一件事：

把工程里的底层问题讲清楚。

今天这篇想讲的其实也是同一件事：

AI 会让代码生成越来越便宜，但“从代码到系统”的判断力，反而更值钱。

我正在更新一个专栏：《把计算机拆开给你看》。

每一篇都会挑一个工程里真实会遇到的问题，从现象讲到原理，再落到可复用的实现。

如果你想补齐“从代码到系统”的视角，欢迎关注。

后台回复 「C++基础」，可以领取 PDF 手册。

也可以先看看这几篇实战长文：

• 用现代 C++ 手搓一个 RISC-V 模拟器
• 想用现代 C++ 写点“真家伙”？来手搓一个 mini-Redis。
• 想知道 Git 背后到底在干嘛？这篇“从零实现 Git”讲透了。
• 用现代 C++ 从零手写智能指针。

如果你想系统训练，而不是只看单篇文章，我现在主要整理了三门课。

1. mini-Redis：把 C++ 写成一个能跑的后台系统

从 epoll、Reactor、RESP 协议、Buffer、AOF 持久化一路写到一个能放进简历、能在面试里讲清楚的后台项目。

适合想补高性能网络服务、C++ 工程项目和后端面试材料的同学。

扫码备注 “redis”。

2. mini-Git：把每天都在用的工具拆到对象模型

从 blob、tree、commit、index、refs、diff、branch 开始，亲手实现一个版本控制内核。

适合想真正理解 Git 底层、工程工具、内容寻址和 DAG 历史模型的同学。

扫码备注 “git”。

3. RISC-V 模拟器：把 CPU、内存和系统接口串起来

从指令执行、寄存器、内存、异常、中断、MMU 到能跑程序的模拟器，把计算机底层链路完整串一次。

适合想补 CPU / 操作系统 / 计算机系统底层，并且希望简历上有一个硬项目的同学。

扫码备注 “cpu”。

如果你不知道怎么选：

• 想补后端项目和面试工程能力，选 mini-Redis。
• 想补 Git 底层、工程工具和数据结构，选 mini-Git。
• 想补计算机系统底层、CPU / 内存 / 指令执行，选 RISC-V 模拟器。

扫码加我微信，备注对应关键词。

我把课程大纲、学习节奏和适合建议发给你，你再决定报不报。

如果你对某个话题感兴趣，或者正卡在某个具体问题上，直接在评论区告诉我。

你的每一次关注、在看和转发，都是我继续写下去的动力。