我是一名即将进入大四的学生。
从大一到临近毕业，我越来越强烈地感受到：AI 正在改变大学生完成作业、学习编程乃至认识自身能力的方式。
这种改变很难简单地用“好”或者“坏”来概括。
一方面，我借助 AI 完成了过去很难独立完成的项目，作业质量和分数也越来越高；另一方面，我对自己真实能力的判断却变得越来越模糊。有时我甚至会怀疑：如果离开 AI，我究竟还能独立完成多少事情？
大一时，我和代码的关系还很亲近
刚进入大学的时候，我使用 AI 的频率还很低。
那时做学生管理系统，我真的是在晚上坐在电脑前，一段一段地把代码敲出来。遇到报错，就自己搜索资料、查看日志，再回到代码里逐行排查。
那个项目现在看来可能并不复杂，代码质量或许也不高，但我对它很熟悉。
我知道每个模块为什么存在，知道数据是怎样流转的，也知道一个功能出现问题时，应该从哪里开始检查。
更重要的是，那时我和代码之间有一种很直接的关系。
功能是自己一点点做出来的，错误是自己一点点改掉的。每解决一个问题，都能获得非常具体的成就感。虽然做得慢，但心里很踏实。
AI 让我的作业变好了，却没有让我同等程度地变强
到了大二、大三，我使用 AI 的频率开始逐渐增加。
一开始，我只是让 AI 帮忙解释报错、补充代码。后来，它开始参与功能设计、接口编写、页面实现，甚至可以直接生成项目中的大部分代码。
有了 AI 托底之后，我完成作业的效率明显提高了。
以前可能需要花费几个晚上才能完成的功能，现在经过几轮对话就能得到基本可用的版本。过去很难独立完成的前后端项目，在 AI 的辅助下也能够做出来。
表面上看，一切都在变好：
- 项目规模更大了；
- 页面看起来更完整了；
- 功能实现得更多了；
- 作业分数也提高了。
但与此同时，我真正投入课堂和课后学习的时间却减少了。
一些知识点在完成平时作业和期末考试后，很快就被遗忘。更明显的问题是，虽然我能够借助 AI 搭建一个前后端项目，但自己对项目框架的认识反而变得模糊了。
AI 生成的代码可以运行，我却不一定能解释它为什么这样写；一个功能能够正常使用，我却未必知道它依赖了哪些模块；项目一旦出现超出对话上下文的问题，我就很难独立定位。
慢慢地，我发现自己进入了一种矛盾状态：
作业的得分越来越高，我却对自己的能力越来越心虚。
如果不用 AI，我可能连一些原本应该独立完成的作业都无法按时完成。AI 提高了我的能力上限，却也在不知不觉中降低了我独立行动的意愿。
这种状态如果一直持续到毕业，真正面对实习、求职和工作中的复杂问题时，我可能会感到更加无措。
老师们也在调整考核方式
AI 对学习的影响并不只发生在学生身上。
据我观察，一些老师已经开始调整课程的考核方式，试图判断学生是否真正掌握了知识。目前比较常见的方式大致有三类。
第一类：把机试改成笔试
有些课程开始减少上机考试，改为让学生在试卷上阅读、分析甚至手写代码。
这种方式确实能迫使学生重新关注代码本身。没有编辑器的自动补全，也不能随时询问 AI，学生至少需要知道代码的基本结构和执行逻辑。
但它的局限也很明显。
纸面编程和真实开发环境之间仍有差距。在评分标准相对宽松、答案形式五花八门的情况下，笔试未必能准确判断学生的工程能力。很多知识在考试前被集中记忆，考试结束后又会迅速遗忘。
它能够暂时限制 AI，却未必能真正解决学习深度不足的问题。
第二类：提高作业难度，同时允许使用 AI
另一类课程不再限制 AI，而是主动提高题目难度，最终以项目完成效率、功能完整性和实际可用性作为考核标准。
这种方式比较顺应技术发展的趋势。
既然未来的工作中大概率也会使用 AI，那么考核学生能否借助工具解决复杂问题，确实比单纯禁止工具更接近真实环境。
但问题在于，项目完成并不等于知识掌握。
如果只看最终结果，一个对技术原理并不了解的学生，同样可能利用 AI 交出外观完整的作品。项目通过了，课程结束了，但学生依然说不清楚代码为什么能够运行。
第三类：强化答辩，追问代码细节
我认为，目前相对有效的方式是加强答辩环节。
老师可以临时选取一段没有注释的代码，让学生解释执行过程、数据流转和设计理由，也可以要求学生现场修改某个功能，或者分析一处潜在问题。
对于主要依赖 AI 完成作业的学生来说，这种方式确实更有辨别力。
因为一个人可能在 AI 的帮助下生成代码，却很难在没有理解的情况下持续回答“为什么这样写”“换一种情况会发生什么”“如果需求改变应该改哪里”。
不过，考核方式的变化只能解决一部分问题。
如果课程内容、案例和教学方法长期不变，只是在考试阶段限制 AI，那么效果依然有限。
一些基础知识虽然看起来“老旧”，但并不过时。数据结构、网络原理、数据库和软件工程思想依然重要。真正的问题是，部分课程停留在知识点讲解上，没有告诉学生这些基础知识如何与今天的工程实践、开发工具和 AI 协作方式结合。
我们需要的可能不是彻底推翻旧课程，而是重新建立基础知识与当代技术之间的联系。
AI 时代，大学生应该学习什么？
与过去的学生相比，我们可能少了一些“手搓代码”的洗礼，却多了一种新的能力要求：如何在 AI 深度参与开发的情况下，仍然保持对项目的理解和控制。
结合自己的经历，我认为至少有以下几个方向。
一、不要只学习“提示词”，要学习如何与 AI 协作
会写提示词当然有用，但真正重要的并不是掌握几个固定模板。
我们更需要学习的是：
- 如何把模糊需求拆分成明确任务；
- 如何向 AI 提供必要的项目背景；
- 如何限制不合理的技术方案；
- 如何让 AI 在已有代码上进行修改；
- 如何检查生成结果是否可靠；
- 如何控制代码规模，减少重复和无意义的封装；
- 如何通过测试、日志和文档验证代码。
好的提示词不是辞藻复杂，而是问题定义清楚、上下文充分、约束条件明确。
而且，节省 Token 也不应只是追求对话更短。真正需要减少的是无效沟通、重复生成和缺乏规划造成的大规模返工。
二、基础知识和项目框架必须真正理解
AI 可以替我们生成代码，但不能替我们承担代码出错后的责任。
我们未必需要脱离工具，从零手写一个完整的商业项目，但至少应该能够看懂项目的主要结构，理解数据如何流动，知道每个模块承担什么职责。
对于关键模块，也应该保留独立实现的能力。
如果我们连代码在做什么都不知道，就无法判断 AI 给出的方案是优秀、勉强可用，还是埋下了安全隐患。
“代码能运行”只是最低标准。它是否正确、可靠、可维护和安全，仍然需要使用者判断。
三、保留一部分不使用 AI 的训练
完全拒绝 AI 并不现实，但完全依赖 AI 同样危险。
我认为可以有意识地给自己保留一块“无 AI 区域”。
例如，在学习一个新知识点时，先自己完成最小版本；遇到报错时，先阅读日志并尝试定位；让 AI 给出答案后，关掉对话，再凭自己的理解重新实现一次。
这类训练的效率可能不高，却是在建立最重要的底层能力：当工具暂时无法给出正确答案时，自己仍然知道下一步该做什么。
四、培养项目应用、需求挖掘与审美能力
当 AI 能够快速生成一个功能甚至一个项目时，“能不能做出来”可能不再是唯一的竞争力。
更有价值的问题会逐渐变成：
- 什么问题值得解决？
- 用户真正需要的是什么？
- 哪些功能只是看起来很丰富，实际却没有价值？
- 一个产品应该怎样设计，才能让人愿意使用？
- AI 生成的方案是否符合真实场景？
对于代码能力没有那么突出的学生来说，这并不一定意味着失去机会。
项目应用思维、需求挖掘能力、产品意识、表达能力和审美判断，都会变得更加重要。AI 可以生成页面，却很难自动决定什么样的产品真正值得被创造。
但需要注意的是，这些“软能力”不能完全替代技术基础。
最理想的状态不是只懂技术，也不是只会提出想法，而是能够理解技术边界，并借助 AI 把真实需求转化成可靠的产品。
我们究竟是在使用 AI，还是被 AI 托着前进？
我并不反对大学生使用 AI。
恰恰相反，我认为 AI 会成为这一代学生很难绕开的基础工具。要求学生完全回到没有 AI 的学习环境，既不现实，也未必符合未来的工作方式。
真正需要警惕的是：我们可能在结果上走得越来越远，却逐渐失去了独立走路的能力。
AI 能够帮助我们完成更大的项目，但项目规模不等于个人能力；AI 能够帮助我们获得更高的分数，但分数也不一定代表真正掌握了知识。
对我而言，最值得思考的问题已经不再是“大学生应不应该使用 AI”，而是：
当 AI 可以替我们完成越来越多事情时，我们应该保留哪些必须由自己完成的过程？
或许，未来真正稀缺的并不是生成代码的速度，而是判断问题、理解系统、验证结果以及为最终作品负责的能力。
AI 可以成为我们的工具、老师和搭档。
但至少在现阶段，我不希望它成为一副让我看起来走得很快，却再也不敢独自行走的拐杖。
