这是一篇程序员视角的反思。AI 时代，每个人都在谈”怎么让 AI 帮我干活”，但很少有人谈——反过来——AI 时代，我自己该练什么。这一篇想把这个视角补上。

一句话总结

你会了的、重复的部分，交给 AI 去做；不会的，一定要亲手去做，一行一行代码去敲；会了之后，再交给 AI 去做。

这句话有三层意思。

第一层：会了的 → 交给 AI。 把重复劳动外包出去，把精力放在真正需要思考的地方。

第二层：不会的 → 亲手做。 一行一行敲，不能跳。你没跳过的部分，才是你真正掌握的。

第三层：会了再交 → 螺旋上升。 你每会一个新东西，就能从重复劳动里再释放一份精力，去啃下一个不会的东西。

听起来像老生常谈。但写代码这件事，我越做越发现，很多人用 AI 的姿势是完全反的——把不会的交给 AI，把自己变成 AI 的附庸。

Part 1：AI 时代最大的错觉——用 AI 跳过学习

我见过这样的场景。

一个初学者，要写一个 HTTP 服务器。他打开 Cursor，输入”用 Python 写一个支持 GET/POST 的 HTTP 服务器”。AI 三秒钟吐出来 50 行代码，他复制粘贴，运行成功。

他觉得”我现在会写 HTTP 服务器了”。

但如果我问他：

• 那 50 行代码里，每一行在做什么？
• 如果用户发来的不是合法 HTTP 请求，会怎样？
• Content-Length 没传会怎么样？
• 服务器是怎么把字节流拼成请求行的？

他答不上来。

他没有学会 HTTP 服务器，他只是学会了一次”提问 + 复制粘贴”。

这是 AI 时代最大的错觉：用 AI 跳过学习，表面上节省了时间，实际上你什么都没学到——而且你永远不知道自己没学到。

为什么”永远不知道”？因为 AI 给的代码通常是能跑的——不会报错。但”能跑”和”对”是两回事：

• 能跑，可能是因为凑巧这个场景下没问题
• 能跑，可能藏了一个会在并发 / 异常输入 / 生产流量下爆掉的 bug
• 能跑，但用了你不理解的库、版本、API，半年后你升级时全崩

更糟糕的是——当 AI 给出错误代码时，你不一定看得出来。

我自己在调一段 SQL 的时候，AI 给了一个看起来”标准”的写法。我顺手复制了，运行没问题。但后来我发现，那个写法在一个边界条件下会扫全表——AI 漏掉了一个索引提示。如果我不是写了十年 SQL，根本看不出来。

所以有个反直觉的结论：

AI 让会的人更强，让不会的人更脆弱。

会的人，能用 AI 砍掉重复劳动，把时间花在刀刃上。不会的人，看起来用 AI 做了很多事，但底层能力是空的——一旦 AI 答错，他接不住。

Part 2：能力是 1，效率是 0

我很喜欢一个比喻：能力是 1，效率是 0。

• 没有那个 1，后面加多少 0 都是 0
• 有了 1，每多一个 0 都放大十倍

对程序员来说，这个”1”具体是什么？是这几样能力——

这些能力，没有一个可以靠”让 AI 写”获得。它们只能靠——一行一行敲。

我带过两个实习生。

第一个，让他手写一个链表反转。他憋了一周才写对，但他写完之后，对指针、对递归、对边界条件，都有非常深的理解。

第二个，让 AI 生成代码，他五分钟就交了，看起来”完成度”很高。但我让他解释，他答不上来。半年后他遇到一个稍微复杂的 bug，他只能继续问 AI——AI 给的方案他不知道对不对，他又没办法判断。

第一个人的能力在涨。第二个人的能力在原地。

这就是”会了交给 AI” 和”不会也交给 AI” 的根本区别。

Part 3：三条铁律

讲完原则，回到操作层面。我自己用 AI 写代码，遵循三条铁律。

铁律一：不会的，必须亲手一行一行敲

我学 Rust 的时候，闭包、生命周期、所有权，每一个概念都不会。我的做法是：

1. 不让 AI 提示，自己敲
2. 报错就报错，看着报错一行一行调
3. 等到某个模式写顺了（比如闭包捕获变量），才让 AI 帮我写变体

这个过程慢吗？慢。

值得吗？值得。

因为我通过亲手敲，建立了对 Rust 的”肌肉记忆”——下次再写类似代码，我不需要问 AI，我知道怎么写。

**这一条铁律的反面，是”用 AI 加速学习”**。很多人学新技术时，让 AI 解释、让 AI 写、让 AI 总结。最后学完了，问他基础问题，他还是不会。

为什么？因为学习这件事本身就不该被加速。

学习 = 不会 → 挣扎 → 弄懂 → 会了

AI 把”挣扎”那一步跳过了。所以你跳过了最关键的一步。

铁律二：会了的，重复的部分交给 AI

当我熟练掌握某个模式之后，我会让 AI 替我写。

比如：

• 写数据库 schema，我会手写第一个；后面类似的，让 AI 写，我审
• 写 API 接口，我会手写第一个；后面批量生成，让 AI 写
• 写测试用例，我会手写一个；后面覆盖边界条件，让 AI 生成

为什么可以交？因为我有能力判断 AI 给的东西对不对。我能在 10 秒内看出来”这个不对”——要么是字段名错了，要么是漏了边界，要么是用了一个有性能问题的写法。

会了，是交给 AI 的前提。不是因为 AI 写得比你好，是因为你有判断力。

铁律三：会了再交，但要能看出 AI 错了

这一条最难，也最重要。

我经常看到一种工作流：

AI 写 → 直接用 → 出问题 → 问 AI → AI 改 → 直接用 → 又出问题 → …

这种工作流的人，看起来”效率很高”，实际上一直在和 AI 玩猫鼠游戏。AI 给出方案，你盲信；AI 错的地方你没接住，结果反复横跳。

正确的工作流是：

AI 写 → 自己审 → 有问题就改 → 没问题才用 → 出问题能定位

“自己审”三个字，看起来简单，做起来非常考验基本功。

要能”自己审”，你得：

• 看得懂 AI 写的每一行
• 知道哪种写法是对的、哪种是有坑的
• 能想象代码在边界条件下的行为

这些，都不会凭空长出来——它们来自你曾经亲手写过、亲手调过、亲手踩过坑。

Part 4：怎么判断”会了没有”

这是个高频问题。我自己的判断标准有三个。

1. 不看屏幕能不能写出来

最简单的方法：合上电脑，拿张纸，把刚才那段代码的关键逻辑默写一遍。

• 写得出 → 真会了
• 写不出 → 还没会，回到铁律一

2. 能解释 AI 给你的方案

让 AI 给你一个方案，然后解释为什么这么写。

• 解释不出来 → 你还没会，回到铁律一
• 能解释，但觉得 AI 写得不够好 → 你已经会了，回到铁律二

3. 能找出 AI 的错

最直接的测试：故意用一个有边界的输入，让 AI 跑一下，看看它怎么处理。

• 你立刻能看出”这里 AI 处理错了” → 你已经会了，而且会得不错
• 你觉得”AI 说的好像对啊” → 你还没会，回到铁律一

这三个标准都很朴素，但很有效。

Part 5：程序员视角的具体场景

光讲原则太空。讲几个我自己在用的具体场景。

场景一：学习新技术

错的姿势：打开 AI，让它解释、让它写例子、让它总结核心概念。看完觉得自己”懂了”。

对的姿势：

1. 先读官方文档（或者一本口碑好的书），读到似懂非懂
2. 关掉所有参考，自己写一个最小的 demo
3. 报错就报错，调到能跑
4. 加需求、加边界条件，重复 2-3

AI 在哪用：在你卡了一周、怎么也调不通的时候，问 AI 一个具体的小问题。但主战场仍然是亲手写。

场景二：写熟悉的代码

错的姿势：让 AI 写整个模块，自己只看结果。

对的姿势：

1. 自己先想清楚架构、关键接口、边界条件
2. 让 AI 写样板代码（CRUD、序列化、配置解析等）
3. 自己审，审完调
4. 关键路径（核心算法、性能瓶颈、安全相关）自己写

场景三：debug

错的姿势：把报错信息复制给 AI，等它给答案。

对的姿势：

1. 自己先看报错，先想”大概是哪里出问题”
2. 自己加日志、跑一遍，看实际的输入输出
3. 自己定位到具体几行
4. 让 AI 解释为什么这几行会出错（这才是 AI 最有效的地方——解释”为什么”，不是直接给答案）

场景四：写没把握的代码

错的姿势：让 AI 写，AI 说”应该这样”，你就信了。

对的姿势：

1. 自己先想清楚要解决什么问题
2. 自己先列两三个可能的方案
3. 让 AI 补充方案的细节，但主方案是你定的
4. 自己写，自己调
5. 调不通才让 AI 介入

Part 6：反模式——警惕这些用法

最后列一些我见过的反模式，提醒自己别踩。

反模式 1：不会就问 AI

表面效率最高，实际能力归零。

你让 AI 写了一段 Go 的 channel 代码，跑通了。你觉得”我会 Go 的 channel 了”。但三个月后你遇到一个稍微不一样的并发场景，你还是不会——因为上次你跳过的是”思考”。

反模式 2：让 AI 解释 AI 写的代码

如果你看不懂 AI 写的代码，让 AI 解释一遍，你以为这就懂了？

没有。因为你听的是 AI 的解释——你信的不是逻辑，是 AI 的权威。

正确做法：要么自己看懂，要么承认自己没懂、回到铁律一。

反模式 3：用 AI 替代 debug 思考

很多人 debug 的姿势是：”AI，我这段代码有问题，你看看”。

但你没说”问题在哪”——你自己都不知道。

debug 的本质是自己缩小范围。AI 在这一步帮不了你。能帮你的是：你已经知道大概哪里错了，让 AI 解释那个具体点为什么错。

反模式 4：用 AI 替代架构思考

架构这种东西，AI 给的方案永远是”教科书式”——标准、安全、但常常过度设计。

真正好的架构，来自你对业务、对团队、对演进路径的理解。AI 不知道你的团队怎么协作、不知道你半年后的方向、不知道你已有的技术债。

架构决策，AI 是参考，主意是你自己的。

回到那句话

你会了的重复的交给 AI 去做，不会的一定要亲手去做，一行一行代码去敲，会了之后再交给 AI 去做。

这句话展开来就是一个螺旋上升的循环：

会了 → 交给 AI → 释放精力 → 学下一个不会的 → 会了 → 再交给 AI → 释放精力 → 学下一个不会的 → …

AI 在这个循环里扮演的角色，是”放大器”——它把你已经有的能力放大 10 倍。

但如果你没有那个 1，放大器放大的是 0。

杠杆离不开支点。

支点，就是你自己。

写在最后

AI 不会让程序员失业。

但会用 AI 的程序员会让不会用 AI 的程序员失业。

而”会用 AI”不是”会问 AI”——是会用 AI 的前提是自己会。

这个区别，决定了你是被 AI 替代的人，还是驾驭 AI 的人。

愿你我都做驾驭 AI 的人。

相关文章：

• AI 写代码有多厉害？——快了 55%，但错多了 75%
• 怎么跟AI协作不翻车——AI说的话你该信几分
• AI会取代我们吗——它不懂孤独是什么意思