跳到主要内容

AI Coding 学习方式的阶段复盘

我经历过这几个阶段​

1. 手搓代码阶段：先会写，再谈项目​

最早做前端页面的时候，思路很直白：

  • 先想这个页面该怎么搭
  • 再拆布局
  • 然后一点点补样式
  • 最后对着效果不断微调

后端也差不多。比如 Java 项目，通常先把基本工程搭起来，再慢慢拆业务逻辑、写接口、接数据层。

这一阶段最典型的学习顺序是：

  • 先理解 CSS 规则和语法
  • 先理解框架的基本写法
  • 先会搭后端分层
  • 然后再去做项目

也就是说，过去更像是“先学会，再开工”。

这种方式当然有价值。它能让你对技术细节更扎实，也更容易知道自己到底在写什么。

但问题也很明显：启动阻力很大。很多项目不是做不出来，而是在“我是不是还没学够”这里就先停住了。

2. 半自动阶段：模板代码生成器开始介入​

再往后一点，开发会变得更“工程化”一些。

比如前后端都开始用脚手架、代码生成器，后端可以先让代码生成器把一部分基础代码搭出来，再按项目实际情况调整。

这时候效率确实提升了，但本质上还是老思路：

  • 先知道标准结构长什么样
  • 借工具把重复劳动省掉
  • 再自己补业务逻辑

也就是说，工具只是加速器，还没有改掉学习顺序本身。

3. 注释驱动阶段：先描述，再让代码跟上​

后面一个很明显的变化，是我开始越来越多地先写注释、写意图、写步骤，再让补全工具往下接代码。

这一步看起来只是“补全更强了”，其实不是。

它意味着我开始把“代码怎么写”往后放一点，把“我想让它做什么”往前放一点。

从这个阶段开始，开发过程里出现了一个新的中间层：

  • 不是直接写代码
  • 也不是只在脑子里想
  • 而是先把意图表达出来

这对学习方式影响很大。很多时候卡住的不是语法，而是表达不清。

4. AI IDE 阶段：先把东西做出来​

再到后面，像 Cursor、Kiro、Qoder 这一类 AI IDE 进来之后，开发的阻力又往下掉了一层。

以前你搭一个页面，可能要先回忆很多样式规则，或者先找以前看过的项目案例，再慢慢拼出一个差不多的效果。

现在不一样了。你可以先把理想效果描述出来，让 AI 先给你做一个版本。哪怕第一版不准，它也很可能比“从空白开始”更快进入能改的状态。

这个阶段最重要的变化，不是“AI 会写代码”这么简单，而是：

  • 你可以在干中学
  • 你可以先把东西做出来
  • 你可以边做边逼自己把需求讲清楚

5. Codex + skill 阶段：不只是生成代码，而是组织开发过程​

再往后，我更明显的体会是：更强的模型和更结构化的技能体系，开始改变的已经不只是“写代码快一点”，而是整个开发范式。

比如 Codex + skill 这种方式，价值已经不只是补几行代码，而是能一起参与：

  • 需求澄清
  • 技术选型讨论
  • 拆任务
  • 落文档
  • 复盘问题

这时会发现，AI 不再只是一个“高级补全器”，而更像一个能一起推进项目的协作对象。

当然，前提是自己也得知道要怎么引导它，尤其是知道什么时候该先讨论，什么时候该先落实现，什么时候该先把上下文和边界讲清楚。

真正变化的，不是工具，而是学习顺序​

如果只把这段变化理解成“AI 越来越强，所以写代码越来越快”，那其实还是看浅了。

我现在更认可的一种说法是：

过去的学习顺序更像这样：

  1. 先学会技术点
  2. 再做项目
  3. 在项目里慢慢积累经验
  4. 最后做到熟能生巧

现在更像这样：

  1. 先尽量把理想效果描述清楚
  2. 先和 AI 一起把东西做出来
  3. 再在做的过程中看懂、修正、补细节
  4. 最后把过程沉淀成维护文档和自己的判断

这不是说技术细节不重要了，而是说“先做再学”这条路，终于不像以前那么费劲了。

以前你要先跨过很多门槛，才有资格开始做。

现在很多门槛没有消失，但 AI 把它们压低了。于是“做中学”不再只是口号，而是真的更可执行了。

为什么这种方式更容易推进项目​

我现在越来越明显地感受到，AI Coding 最大的价值，不是替你省掉全部学习，而是替你省掉前期那种很重的启动摩擦。

比如你要搭一个文档型站点项目，过去你可能要先想：

  • 用什么技术栈
  • 页面结构怎么搭
  • 导航怎么组织
  • 样式怎么起步

这些问题以前任何一个都可能让人拖很久。

现在如果前期能尽量把目标说清楚，再把技术选型提前想明白，很多事情可以更快推进。

而且还有一个过去不太容易做到、现在很值得做的动作：

  • 让 AI 不只是写出来
  • 还让它解释这是怎么开发的
  • 再让它补后续怎么维护

这样最后留下来的就不只是一个“能跑的结果”，而是一套更容易继续接手的项目上下文。

新的成本和坑点也很真实​

这套方法更高效，不等于它没有代价。

1. token 真的会变成成本​

以前主要花的是时间。

现在你会明显开始在意：

  • 哪些上下文值得给
  • 哪些描述太散会浪费额度
  • 哪些来回反复，其实是在烧钱

所以“高效使用 AI”这件事，已经不只是会不会提问的问题，也变成了成本管理的问题。

2. 技术选型如果前面没想清楚，后面一样会返工​

AI 能帮你很快做出一个效果，但如果前面方向选错了，后面返工也一样很快，只是返得更大。

所以我现在会更看重前期判断：

  • 这个项目适合什么栈
  • 什么地方应该先简单做
  • 什么地方一开始就该考虑维护性

先做出来，不等于乱做出来。

3. 切换不同 IDE 时，工程管理反而更容易出问题​

这是很实际的坑。

当你在不同 AI IDE 之间切来切去，如果没有及时做好 git 管理，没有及时提交、分支、留痕，就很容易出现这种问题：

  • 之前改过的代码没有保存好
  • 某一版思路回不去了
  • 你知道“好像做过”，但找不到那次改动到底在哪

过去手写代码时，这个问题也有，但现在因为试错更快、切换更频繁，风险会被放大。

4. 很容易把“做出来”误当成“真的掌握了”​

这是我觉得最需要警惕的地方。

AI 确实能帮你快速做出东西，但做出来和你真正理解了它，仍然不是一回事。

如果你最后只是拿到了结果，却没有回过头去看：

  • 它为什么这样组织
  • 哪些地方以后最难维护
  • 这次选型为什么成立

那你得到的可能只是一次顺利的代工，不一定是能力真的长了。

我现在更认可的一种做法​

如果把这段时间的体会收束一下，我现在更认可的不是“先把所有技术学透再做”，也不是“什么都丢给 AI 就行”，而是一种更折中的顺序：

  1. 先描述清楚你想要的理想效果
  2. 先和 AI 讨论技术选型和值得注意的边界
  3. 先把可运行的结果做出来
  4. 再回头看懂关键实现
  5. 同时补维护文档、复盘和后续演进思路

如果工具支持得更好，比如能把讨论、规划、编码、复盘串起来，那这套方法会更顺。

像 skill 这一类东西对我来说，真正有价值的地方也在这里：它不是单纯提高一点补全命中率，而是帮助你把“和 AI 一起开发”这件事做得更有结构。

一句话收尾​

过去更像是先学会怎么做，再去做项目。

现在更像是先尽量把项目做出来，再在做的过程中学会它、看懂它、维护它。

AI 没有让学习消失，但它确实让“做中学”这件事，比以前少了很多阻力。