不要将学习外包给AI，AI时代应如何学习编程

过去半年，技术圈里出现了一个很诡异的现象。

很多人的简历上写着“熟练使用 AI 辅助开发”，项目作品也很漂亮：UI 精致，功能完整，甚至能把前后端、登录态、部署流程都串起来。

但只要把 AI 插件关掉，现场让他手写一个最基础的递归函数，或者处理一个简单的 for 循环嵌套，很多人会突然卡住。

一位有 7 年架构经验的开发者分享过一个观察：他近期协作过 200 多名开发者，发现不少人能用 AI 做出非常完整的 Full-stack 项目，但一旦离开 AI，面对基础逻辑题和代码拆解，反而暴露出明显短板。

这就是现在很流行的“氛围感编程”（Vibe Coding）。

开发者熟练地在提示词框里输入需求，看着代码像瀑布一样倾泻下来，然后微调、运行、部署。一切看起来都很 impressive。

但你只要多追问一句：

• 为什么这里要用这个数据结构？
• 这段异步逻辑在高并发下会有什么隐患？
• 如果数据库写入失败，应该返回什么状态码？
• 这个函数为什么要这样拆？

空气里往往只剩下尴尬的沉默。

这就是 AI 时代给学习者设下的一个温柔又致命的陷阱：

你以为自己在利用 AI 加速成长，实际上可能正在丧失独立拆解问题的能力。

用 AI 做出东西，真的等于学会了编程吗？

这是这篇文章真正想讨论的问题。

我不是反对用 AI 学编程。

现在还劝人刻意不用 AI，已经不现实，也没必要。

真正需要警惕的是：你到底是在用 AI 训练自己，还是把学习动作外包给 AI。

前者会让你变强。

后者会让你越来越像一个“会操作 AI 的伪程序员”。

一、AI 编程学习的绕不开的三件事

工具本身无罪。

真正的问题，是你用它绕开了本该训练自己的部分。

如果没有底层逻辑支撑，盲目拥抱 AI，最容易导向三种“慢性死亡”。

1. 抄而不问

编程社区里曾有观察：引入 AI 辅助后，初学者修复 Bug 的速度明显提升，但几个月后的测试却显示，重度依赖 AI 自动生成的学员，面对全新问题时的解决能力几乎为零。

这类人不是没写过代码。

他们写过很多。

但那些代码从来没有真正经过自己的大脑。

AI 被当成了廉价外包，没有被当成随身导师。代码没有经过你一点点推演，而是从提示词框里“降落”到编辑器里。

时间久了，你会越来越熟练地复制，越来越不习惯追问。

2. 速度幻觉

有研究显示，使用 Copilot 的开发者完成任务速度提升超过一半。这个数据很有价值。

但它提醒我们的，不只是“AI 能提速”，还有另一个更隐蔽的问题：速度提升很容易伪装成能力提升。

当你跳过基础概念，直接通过 AI 搭出一个高级框架项目时，很容易产生一种“我已经掌握了”的错觉。

页面能打开，接口能返回，功能能演示。

但你可能并不知道：

• 为什么这个组件要这样拆；
• 为什么状态要放在这里；
• 为什么接口要这样设计；
• 为什么这个错误处理在高并发下会出问题。

这就是速度幻觉。

你跑得很快，但底盘没有长出来。

3. 验证税

很多团队在半年后才发现，AI 带来的效率红利，正在被巨额的“验证税”抵消。

不少开发者反馈，手动验证、调试 AI 给出的”幻觉代码”所花的时间，已经逐渐逼近甚至超过了从头手写的时间。

“It works, but I don't know why。”

这句话是依赖中毒的强信号。

代码能跑，但你不知道为什么能跑。

代码报错，但你不知道从哪里查。

AI 改了一版又一版，但你只是不断点击“Regenerate”，把希望寄托在下一次生成上。

当你不再理解每一行代码背后的逻辑，你就从代码的主人，变成了代码的保姆。

二、这个“会了”的错觉，是怎么来的

这个错觉最麻烦的地方，是它很难第一时间被发现。

以前你学一个接口，会被迫经历很多笨动作。

你要想清楚路由怎么写。

你要查请求体怎么拿。

你要处理参数为空。

你要看数据库报错。

你要反复打印日志，最后才知道错在哪里。

这些过程很慢，也很烦，但它们会训练三个底层能力：

• 拆解：一个需求到底由哪些小问题组成；
• 验证：代码是不是真的符合预期；
• 复盘：这次踩的坑下次能不能少踩。

AI 介入以后，这些动作很容易被跳过去。

你输入一句“帮我写一个 Todo 接口”，它直接给你完整代码。

你复制、运行、能通。

于是大脑会给你一个很舒服的反馈：

“我好像掌握了。”

但真正到了代码 Review、线上排查、复杂业务改造的时候，问题就出来了。

因为你真正缺的，是生成代码之前的拆解能力、生成代码之后的验证能力，以及出错以后的定位能力。

如果这些能力没有长出来，AI 给你的速度越快，你越容易绕开真正该练的部分。

三、判断是否过度依赖 AI，看你能不能解释代码

判断自己有没有把学习外包给 AI，其实很简单。

看你能不能解释自己的代码。

举个很小的例子。

你让 AI 写一个 POST /todos 接口，它可能很快生成：

• 接收 title；
• 校验参数；
• 写入数据库；
• 返回创建结果；
• 捕获异常。

如果你只是复制进去，接口可以跑，但你未必真的学到了什么。

你应该继续追问：

• 为什么 title 要做非空校验？
• 如果 title 很长怎么办？
• 如果数据库写入失败，应该返回什么状态码？
• 这个接口要不要防重复提交？
• 如果以后加用户系统，todo 表要怎么改？
• 这段逻辑应该放在 controller、service，还是 model 里？

这些问题，才是编程训练真正发生的地方。

AI 给你代码，只是开始。

你围绕代码做解释、验证、改写、复盘，学习才算真正开始。

四、把 AI 改造成训练系统：六个动作

我更建议用这套框架学编程：

Prompt -> Context -> Test -> Explain -> Review -> Asset

1. Prompt：先要思路，别急着要完整答案

不要一上来就问：

“帮我写一个 Todo 接口。”

更好的问法是：

“我想实现一个 POST /todos 接口，请先帮我拆解需要考虑哪些模块、边界条件和测试点，暂时不要写完整代码。”

先拿结构，再写代码。

结构会逼你思考，答案容易诱导你复制。

2. Context：把真实约束说清楚

AI 很容易写出“看起来对、放进项目就不合适”的代码。

常见原因是上下文不够。

比如：

• 项目用 Express 还是 NestJS；
• 数据库是 MySQL、PostgreSQL 还是 MongoDB；
• 当前错误处理规范是什么；
• 返回格式是否统一；
• 是否已有 service 层；
• 是否需要兼容已有字段。

学编程不能只学语法，也要学会描述约束。

能把上下文讲清楚，本身就是工程能力的一部分。

3. Test：让代码先接受测试

AI 生成代码之后，不要只看它顺不顺眼。

先问测试。

继续用 POST /todos 这个例子，至少要有几类测试：

• title 为空时应该失败；
• title 正常时应该创建成功；
• 数据库异常时应该返回明确错误；
• 返回结构要和项目约定一致；
• 重复请求是否会产生脏数据。

测试的价值，是把“我觉得对”变成“我能验证它对”。

社区里有一个值得注意的趋势：对 AI 工具输出准确性表示不信任的开发者比例，高于表示信任的比例。

这个数据提醒我们：AI 输出需要人来校准。

4. Explain：让 AI 解释，也让自己复述

解释有两层。

第一层是让 AI 解释：

“请逐行解释这段代码，尤其说明参数校验、异常处理和数据库写入顺序。”

第二层更重要：你自己复述。

打开一个空白文档，把这段代码的逻辑用自己的话写一遍。

如果写不出来，就说明你还没有真正理解。

这一步很慢，但它非常值。

学习编程，光看懂不够。能用自己的语言重新组织一遍，才开始进入自己的能力系统。

5. Review：把自己当成代码审查者

不要默认 AI 写出来的就是标准答案。

你可以用 Review 清单来审它：

• 变量命名是否清楚；
• 函数职责是否单一；
• 错误处理是否符合项目规范；
• 是否有多余抽象；
• 是否有安全风险；
• 是否方便以后扩展；
• 是否能被测试覆盖。

这个过程会训练你的代码审美。

只会让 AI 生成代码的人，遇到问题只能反复让 AI “再改一下”。

能 Review AI 代码的人，才开始拥有主动权。

6. Asset：把一次学习沉淀成资产

每学完一个小功能，都可以沉淀一个小资产。

比如：

• 一个接口开发 checklist；
• 一个错误处理模板；
• 一组单元测试样例；
• 一个 Prompt 模板；
• 一篇项目复盘；
• 一个“我踩过的坑”记录。

这就是 AI 时代学习很重要的一件事：不要只消费 AI 给你的答案，要把过程变成自己的数字生产资料。

五、更适合 AI 时代的训练法：PRIMM

如果觉得上面的框架还是有点抽象，可以借用一个更成熟的编程教育方法：PRIMM。

PRIMM 来自计算机教育领域，全称是：

• Predict：预测
• Run：运行
• Investigate：调查
• Modify：修改
• Make：创造

它的核心思想很简单：不要一上来就从零写代码，先读懂一段能工作的代码，再逐步修改，最后独立创造。

这套方法本来就适合初学者。

到了 AI 时代，它反而更重要。

因为 AI 最大的问题，是太容易让你跳过“读懂”和“修改”，直接进入“生成”。

还是用 POST /todos 举例。

1. Predict：先预测，不要先运行

你可以先让 AI 给一段接口代码，但不要急着复制运行。

先问自己：

• 这段代码会接收哪些参数？
• title 为空时会发生什么？
• 数据库写入失败时会走到哪里？
• 最后返回给前端的结构是什么？

这一步训练的是代码阅读能力。

一个人能不能学会编程，很大程度上取决于他能不能读懂别人写的代码。

2. Run：运行代码，验证自己的预测

接下来再运行。

重点不是看“能不能跑”，而是看结果和你的预测是否一致。

如果不一致，不要马上让 AI 改。

先记录下来：

• 我预测错在哪里？
• 是参数理解错了，还是执行顺序理解错了？
• 是异常分支没想到，还是返回结构没看清？

这一步训练的是验证能力。

3. Investigate：逐行调查，而不是整段吞掉

运行之后，让 AI 帮你解释代码，但不要接受泛泛解释。

你可以这样问：

“请按执行顺序解释这段 POST /todos 代码，重点说明参数校验、数据库写入、异常处理和返回结构。”

然后你自己再复述一遍。

如果复述不出来，就继续追问。

真正的学习，往往发生在这里。

4. Modify：做小修改，观察系统变化

下一步，不要急着写新功能。

先做小修改：

• 把 title 最大长度限制为 50；
• 增加 completed 默认值；
• 数据库异常时返回统一错误码；
• 把逻辑从 controller 拆到 service；
• 增加一条单元测试。

每改一处，都观察系统行为发生了什么变化。

这一步训练的是因果感。

你不只是知道“代码长什么样”，而是开始知道“改哪里会影响哪里”。

5. Make：最后再独立创造

等你预测过、运行过、调查过、修改过，最后再关掉 AI，自己写一个类似功能。

比如：

• POST /notes
• POST /comments
• POST /projects

结构类似，但场景不同。

这一步才是真正的迁移。

如果你能把 POST /todos 里学到的拆解、校验、异常处理、测试方法迁移到另一个接口上，才说明这套能力开始长到你身上。

所以，AI 时代学编程，我更建议把 PRIMM 改造成一个固定动作：

先预测，再运行；先调查，再修改；最后创造。

这比单纯刷项目更慢一点，但它会逼你把 AI 生成的代码变成自己的能力。

结尾：别把学习动作外包掉

AI 会继续变强。

以后写代码会越来越快，生成项目会越来越容易，很多今天看起来复杂的东西，明天可能只需要几句话。

越是这样，越要分清两件事：

AI 可以帮你生成答案。

你必须训练自己的判断。

真正的编程能力，不只是敲出代码，也不是把 Prompt 写得很花。

它包括理解问题、拆解结构、验证结果、修正错误、复盘经验，以及把一次实践变成下一次可以复用的资产。

如果你只是让 AI 替你写，你会得到越来越多代码。

如果你把 AI 改造成训练系统，你会得到越来越强的自己。

这也是我理解的 AI 时代学习方法：

让 AI 负责加速。

让系统负责校准。

让人保留方向和判断。

编程如此，写作、研究、知识管理也一样。

不要把学习外包给 AI。

你可以借助 AI 走得更快，但理解这条路，还是要自己走一遍。

你现在用 AI 写代码时，最容易依赖它的是哪一步？

是拆需求、写代码、改 Bug，还是解释报错？

欢迎在评论区聊聊。

下一篇我会继续拆“用 AI 学写作”：AI 可以帮你改结构、找反例、做诊断，但表达权和判断权必须留给自己。