29:Tbcf,

入行三年,有些CLI命令我到现在还要先愣一下才能打对。而且不是什么冷门命令,是最基本的那些:cd、sudo、带各种参数的ls和ll、nano、cat、grep。反倒是composer、npx、npm、node、php这些我学得很轻松,因为这些是程序员"该会"的东西。没人指望我会终端本身。

在自托管这块我是自学的,而这个短板就暴露出来了。Cordova Public College教的基础是npm、node和php,对于培养能交付代码的开发者来说这很合理。但它漏掉了底下那一层:你实际用来敲这些命令的shell本身。SSH就是最明显的例子。我大多数同事除非是系统管理员,否则都不怎么碰它。它被当成一种专业技能来对待,而不是每个后端开发者都该刻进肌肉记忆里的东西。

我一直在反复琢磨,这到底是AI造成的问题,还是本来就一直存在、只是AI让它更显眼了。我猜多半是后者。训练营和计算机科学课程都在为"最快找到工作"这个目标优化工具选择,而shell命令提示符不会出现在作品集网站上。早在AI能帮你自动补全绕过它之前,它就已经是个门槛了。现在只是变得更容易被彻底跳过而已,因为你可以直接问,而不用学。

这周,一个我真的从来没用过的git命令,让这个想法变得更具体了:git restore --source= 。

交付代码三年下来,"restore"对我来说一直只有两种意思:撤销工作目录里的所有改动,或者回退整个提交。把单单一个文件拉回到早期版本、而其他一切都不动——这作为一种工作流,我甚至从来没想到过。我不知道这是因为没人教过,还是因为我从来没遇到过恰好逼着我去学它的情况,大概两者都有吧。

真正重要的部分,也是我差点搞错的部分,是提交哈希后面那个~1或~10的后缀。如果你指向的那个提交本身已经包含了文件的改动,那么恢复到那个提交本身,得到的还是你正想逃离的那个损坏状态。你得再往前退一步,退到那个改动发生之前的那个提交,而这正是<commit-hash>~1做的事。漏掉这个细节,命令照样能顺利执行,但什么有用的事都没做,然后你就会带着"git restore根本不像大家说的那样好用"的想法走开。

这类基础知识,过去往往是靠年复一年地卡住、再自己爬出来这个过程,不知不觉中吸收进来的。AI正在以比我们大多数人意识到的更快的速度,关闭这条"意外习得"的路径。如果下一代开发者可以选择问而不是学,而且大多数时候确实这么选,那种只有在卡住、又没人可问的时候才会长出来的肌肉记忆,又会变成什么样呢?我们是不是没救了?

博客文章.

早在AI出现之前,我们就已经忘了基础