用 AI 做开发时，我真正学到了什么

这篇文章发表在 dev.to 社区，作者以第一人称回顾了自己用 AI 工具构建项目的过程，核心问题只有一个：在让 AI 写代码、查资料、给方案的时候，人究竟学到了什么。文章没有把重点放在某款工具的评测或效率数字上，而是把视线转向使用者本身，讨论这种新型协作方式留给开发者的是能力的增长，还是对工具的依赖。标题里的“真正”二字已经表明立场：作者认为，生成了多少代码并不重要，重要的是做完之后，脑子里多了什么。这个话题近两年在开发者圈子里反复出现。随着各类编程助手进入日常工作流，许多人都有过类似体验：项目很快跑起来了，但回头一看，自己说不清其中某些关键设计为什么这样做。这篇文章正是对这种体验的一次诚实复盘，适合作为想引入 AI 辅助开发的人的参考。

从技术角度看，这类反思之所以重要，是因为大语言模型的工作方式决定了它擅长给出看起来合理的完整答案，却不会替使用者承担理解的成本。传统开发中，一个人要写出一段可用的代码，必须先弄懂接口、数据结构和错误处理，理解是实现的副产品。引入 AI 之后，实现和理解被拆开了：实现可以由模型完成，理解则必须由人主动补上。如果使用者只接受输出，缺少追问和验证，学习就会停在表面。反过来，如果把模型当作随时可问的搭档，让它解释为什么选这个库、这段逻辑的边界条件是什么、换一种写法会有什么代价，那么每一次对话都可以变成一次小型的结对学习。区别在于提问的方式，也在于使用者是否愿意阅读和运行生成的结果，并亲手改动它。此外，调试环节往往最能暴露理解上的缺口：模型给出的方案一旦报错，开发者必须顺着报错信息回到原理层面去排查，这一步恰好是最扎实的学习时刻。因此，真正有效的用法不是把任务整块交出去，而是把模型放在思考的旁边，用它放大自己的判断，而不是替代判断。

对行业而言，这个视角会影响多个层面。对个人开发者，尤其是初学者，最直接的影响是学习路径的变化。过去靠大量重复编码积累的手感，现在可能被压缩，但与此同时，阅读代码、审查代码、识别模型幻觉的能力变得更加关键，这些能力需要刻意训练。对团队和技术负责人，问题则是如何评估产出：如果只看交付速度，容易忽略隐含的维护风险，因为没人真正理解的代码，会在半年后变成难以修改的负担。代码评审、测试覆盖和文档沉淀因此比以前更重要，它们是把模型的输出转化为团队共同知识的通道。对工具厂商而言，竞争的焦点也在悄悄转移，从单纯比拼生成能力，转向如何帮助用户理解生成内容，例如更好的解释、可追溯的修改记录和更清晰的差异展示。能让用户越用越明白的工具，长期看比只会替用户做完的工具更有黏性。对教育和培训机构，这也意味着课程设计需要调整，把提问、验证和审查当作和语法同等重要的基本功来教授。

往后看，有几个信号值得关注。第一，开发者社区里这类经验分享会越来越多，从“怎么用好某个工具”逐渐转向“怎么在使用中保持成长”，这说明行业正从尝鲜阶段进入反思阶段。第二，团队层面可能出现更明确的使用规范，例如要求提交者能够解释自己提交的每一段由模型生成的代码，或者在评审中专门检查边界条件和依赖选择。第三，随着模型能力继续提升，人与模型的分工会不断重新划线，但有一点大概率不会变：需求的界定、方案的取舍和对结果负责，仍然属于人。对读者来说，最实际的做法是从小处开始，每次让 AI 参与一个范围清楚的任务，做完后主动回答三个问题：我为什么接受这个方案，它在哪些情况下会失败，我下次能否不靠它独立完成。如果这三个问题都能回答，说明这次协作确实带来了学习；如果答不上来，就该回头补课。这篇文章的价值，正在于提醒我们，工具会不断更新，而理解力才是开发者真正带得走的资产。