当项目一直在 Build，而我很少 Review，也很少真正 Coding。

最近在玩树莓派时，我尝试做了一件现在看来很普通、对我来说却有些陌生的事情：不用 AI 生成代码，也不开代码补全，只在终端里用 vi 和 nano 编辑文件，再分别用 Python、gcc 和 javac 运行或编译程序。

面对一个几乎空白的文件，我原本以为自己很快就能写完。真正动手以后，我才发现事情并没有想象中顺利。

写 C 语言输入时，我一时想不起 scanf("%d", &a); 为什么需要取地址符 &；定义函数时，也会短暂忘记形参前必须写类型。换到 Python，又需要重新确认 input() 返回的是字符串，如果要读取整数，还得写成 int(input())。Java 的 Scanner、类名、入口方法和各种括号，也不再像以前那样自然地从手指里流出来。

这些语法并不难，查一下文档也很正常。真正让我不安的不是忘记某个符号，而是我已经很久没有独立面对一个空白文件了。

离开 AI 以后，我还剩下多少能力

过去一段时间，我做过不少项目。

我搭建过 Hexo 博客，接触过 Claude Code、Codex、OpenClaw，也尝试过各种 AI 项目和自动化工具。一个需求交给 AI，几分钟后就能看到目录结构；继续对话，页面、接口、配置和部署脚本也会逐渐出现。从结果上看，我好像一直在写代码，也一直在完成项目。

但站在树莓派终端前，我忽然开始怀疑：这些项目里，究竟有多少代码是我真正亲手写过、认真理解过的？

如果只计算那些不依赖生成、能够解释每一个关键步骤、出现问题后也能独立修改的代码，我真正写过的有效代码，也许只有一千多行。

项目数量给了我一种一直在进步的感觉，空白文件却揭穿了这种熟练感。

“做过项目”和“拥有项目中的能力”，原来是两回事。

项目一直在 Build，但我没有跟着成长

AI Coding 很容易让人进入一种循环：提出需求，等待生成，执行 Build，把报错发回去，再等待下一次修改。

如果运行成功，就继续增加功能；如果运行失败，就把错误信息交给模型。项目在这个循环中变得越来越完整，代码量也越来越多，但我很少停下来认真阅读一次 diff，很少顺着调用链理解数据怎样流动，也很少检查异常处理是否可靠。

我一直在 Build，却没有认真 Review；一直在催促项目向前，却很少真正 Coding。

更严重的是，我已经很久没有进入过去那种写代码的状态了。不是不断告诉模型“继续”“修复”“再加一个功能”，也不是盯着构建日志等待结果，而是停在一个模块前，认真考虑数据应该怎样组织、接口为什么这样设计、错误应该在哪里处理。

那种过程很慢，有时一个问题需要想很久，却会形成真正属于自己的理解。AI 缩短了实现时间，也让我越来越少经历这段缓慢但重要的思考。

项目越来越多，真正沉淀下来的设计经验却没有同步增加。

“100% 由 AI 开发”还能证明什么

现在很多项目会特意强调：“这个项目由 AI 完成。”

但当任何人都能通过对话迅速得到一个像样的 Demo，这句话越来越难证明一个人的能力。AI 参与了多少并不重要，真正值得追问的是：问题是谁发现的，方案是谁决定的，生成结果有没有被认真审查，系统出错时又有谁能够接住。

一个项目可以完全由 AI 生成，但项目产生的判断、经验和能力，不会因此自动属于我。

过去，独立做出一个网站、写完一个程序或者完成一个可运行的系统，本身就是一件值得骄傲的事情。现在，实现的门槛正在快速降低。曾经能够带来成就感的结果，正在变成每个人都能获得的普通产物。

这并不意味着做项目失去了价值，而是项目的价值不再只由“有没有做出来”决定。

当生成变得廉价，理解、判断、验证和责任反而变得更重要。

几小时完成的课程设计，可能什么也没有留下

这种问题在课程设计里更加明显。

过去可能需要几周完成的任务，现在把要求交给 AI，几个小时就能生成代码、报告、运行截图，甚至连答辩稿都可以一起准备好。从提交结果来看，任务完成得更快，页面也可能比以前更漂亮。

但课程设计原本是为了什么？

它应该迫使我把专业课中的概念真正用一次：选择数据结构，理解网络通信过程，设计串口收发流程，观察协议字段，定位异常，处理边界情况。

如果这些步骤全部被 AI 代替，我得到的只是一个可以提交的文件夹。代码运行了，报告写完了，分数也许不会低，但专业知识并没有因此留在我的脑子里。

任务被完成，不等于学习发生过。

更讽刺的是，AI 节省下来的时间，我未必真的用来理解知识。很多时候，我只是更快地完成这一个任务，然后马上开始下一个任务。效率提高了，欠下的理解却越来越多。

被掏空的不只是语法

树莓派上的几行代码让我回头看了看学过的课程。

计算机组成原理、计算机网络、串口通信、协议分析……这些内容我都学过，也参加过考试。但如果现在真的遇到通信失败，我能不能从电平、波特率、数据帧、字节序一路排查？遇到网络异常，我能不能独立抓包，理解报文，再定位是哪一层出了问题？

很多知识在我的记忆里只剩下“好像见过”。

语法忘记了还可以查，真正危险的是基础知识没有形成可以调用的能力。没有这些基础，即使 AI 给出了一份看起来正确的代码，我也很难判断它是否真的可靠，更不知道问题发生时应该从哪里开始检查。

AI 并没有让基础知识失去价值。恰恰相反，生成能力越强，审查生成结果所需要的基础就越重要。

这种效率，究竟是不是我的

还有一种焦虑来自工具本身。

我现在可以使用一些非常先进的模型，它们能够快速理解项目、修改多个文件、运行命令并修复错误。但这些能力建立在一个前提上：服务始终可以访问，账号仍然有效，价格和使用条件没有发生无法承受的变化。

今天能够使用的模型，明天未必还能以同样的渠道、成本和条件继续使用。

如果我的效率完全建立在某个外部服务始终可用的前提上，那么这种效率并不真正属于我，它更像是一种暂时租来的能力。一旦模型不可用、额度耗尽或者网络中断，我是否还能继续工作，才真正暴露了自己的能力边界。

最危险的不是 AI 突然消失，而是它没有消失的时候，我已经把它的能力误认为了自己的能力。

AI 可以替我提高速度，但不能替我形成能力

写到这里，我并不想得出“以后不要使用 AI”的结论。

拒绝 AI 并不会自动让人变强。相反，合理使用 AI 可以降低试错成本，帮助我更快接触陌生技术，也能把时间从重复劳动中释放出来。问题从来不是用不用，而是我把什么交给了它。

AI 可以替我提高速度，但不能替我形成能力。

真正危险的不是使用 AI，而是在没有理解、没有验证、没有复盘的情况下，把思考也一起外包。

如果我只要求 AI 给出结果，却不再理解过程，那么每一次看似成功的交付，都可能进一步掏空自己的能力。久而久之，我拥有的不是技术，只是一套不断向模型提要求的操作习惯。

写在最后

树莓派终端里的那个空白文件，没有证明我不适合写代码，却提醒我重新审视自己正在成为怎样的开发者。

项目完成得越来越快，不代表我理解得越来越深；代码生成得越来越多，也不代表其中有更多东西真正属于我。

以后，当我再次说“这个项目是我做的”时，我希望自己不只是能够打开页面、展示功能和介绍用了哪个模型。

我还应该能够解释它为什么这样设计，能够在没有 AI 立即给出答案时继续思考，能够发现生成代码中的问题，也能够在系统真正出错时承担修复它的责任。

否则，我拥有的可能不是一个项目，只是一次成功的生成记录。