我今年五十出头，大厂出来后一直在创业公司，现在仍活跃在一线，做的多是 AI 相关的工程落地。博客篇幅有限，一些工作碎片、对新工具的持续琢磨、以及过去几十年里摔过的跤，会不定期写在微信公众号「字与码」。若这里的文章对你有点用，欢迎顺手关注。

下面从知乎上一位大二计科同学的焦虑聊起：作业基本靠 AI，期末也大都是大作业，很少闭卷手写；Cursor、OpenCode 用得顺手，可又听说「不懂代码肯定扛不住高要求项目」——从 vibe coding 到满屏 agent，要不要为「手搓」特别焦虑？

我在与实习生交流、同事闲聊、社群里也听过几乎同一套话。有的是在校生，有的是工作一两年的新人：工具越用越爽，心里越不踏实。这篇不只写给题主，也写给还在打基础的同学和刚入行的初级程序员；后面顺带说一句现在还要不要选计算机相关专业，因为不少高中生和家长也在问。

我自己没有「吓唬你」或者「没事啦都会好的」这种立场。更实在一点：先想清楚你到底在怕什么——很多时候怕的是两件事搅在一起，分开看会清楚很多。

你怕的可能是两件不同的事

一件是怕不会「表演式手写」：白板快排、闭卷语法、手推指针。如果你的课本身就不考这些，短期内它多半不会单独把你拖垮；行业里对「逐字默写」的看重程度，本来也在降。

另一件是怕以后真项目顶不住：读不懂别人的代码、线上出了问题不知道从哪查、需求糊成一团时拆不动、性能和安全心里没数。这和「手速」有关，但更和读代码、排错、做判断有关——和是不是每一行都亲手敲，并不是同一件事。

真正该上心的，通常是后者；前者里有一部分，已经被新工具重新定价了，不必为此硬套上一代人的标准自我攻击。

「手搓」的标准一直在换

十多年前会背 API 算本事；Stack Overflow 时代会搜、会改也算本事；再后来，会看文档、会调试、能把 bug 复现成最小例子，比会默写某个框架初始化重要得多。现在多了一步：把「查资料 + 试凑」交给模型。工具又往前走了一格而已。

要是你烦的是「我怎么不像学长那样一行行敲满 boilerplate」，那真不用觉得丢人——行业要的早就不是打字比赛。

有一条线别踩混就行：省力可以，甩锅不行。 自动驾驶再成熟，落地那一下还是机长签字。代码谁生成的都行，merge 进仓库的人要对行为负责：改了啥、啥情况下会炸、炸了怎么回滚或修——这些赖不掉。

vibe coding：词被用宽了，意思可以更刻薄

「vibe coding」最早是 Andrej Karpathy 在社交平台上半开玩笑说的：生成靠模型，验收靠感觉，细节尽量不看。带点自嘲，不是培训班包装出来的「新范式」。现在大家把它泛化成「用 AI 写代码」，讨论就容易糊。

我习惯用两种用法区分一下，不说教，只方便自检：

一种是你把 AI 当加强版补全：出来的段落你能看懂，diff 愿意过一眼，关键路径会跑测试或手点一遍。另一种是当黑箱施工队：不报错就行，错了就再 prompt 一轮，问起来为什么好、为什么坏，说不上来。作业或需求如果长期停在第二种，心里发毛很正常——那攒下来的更像运气，不像本事。

卡人的常常是验收，不是「没手写」

带过人、也见过不同年限的同事之后，我体感差距经常出在下面这些地方，和「手搓」只有部分重叠。

接手一块代码，敢不敢自己顺着调用链往下啃，还是永远等别人指「改第几行」？测试红了、线上挂了、接口慢了，能不能把现象收成能复现的一小步，用日志、断点、注释二分、profiler 这些老办法往下缩？模型很会给「看起来很完整」的目录和注释，甚至附带测试文件，但边界条件可能全错——演示很亮，一上量就露馅。 agent 一口气改十个文件很爽，密钥进没进仓库、循环里有没有偷偷打外部接口、事务有没有被拆烂，这些靠的是认真读，不是靠手速。

所以「不懂代码就做不了高要求项目」这句话，如果翻译得实在一点，更接近：不能独立验收、不能对结果负责的人，扛不住高要求。 和是不是每个字符都自己敲，不等价。

demo 便宜了，活儿往两头挤

工具越强，中间那段「糊一个能跑的 demo」越不值钱，压力会挪到两头：前面是问题是不是提对了、约束清不清、架构和接口怎么定、数据和权限模型是否合理；后面是测试、观测、发布、回滚、线上救火、长期维护。

学校大作业、公司内部小需求，常常只奖励「做出来了」；可读性、边界、运维权重不高，容易让人误以为「我已经能交付了」。一进实习或真业务，尺子换了，焦虑突然冒出来——很多时候不是因为不会手写，而是第一次要用负责这把尺子量自己。

具体一点：可以养成的小习惯

不用回到「纯手搓年代」，几条小事长期坚持，对在校生和初级程序员都管用。

每周抠出一小段尽量自己写或弱 AI的时间，两三个小时就够：实现一个小数据结构、写个小脚本，或者把课上的算法自己推一遍再落代码。不是为了感动自己，是留个「没助手脑子也能转」的底。比一次熬通宵更有用的是频率。

每次作业或需求结束，随手写几行验收笔记：测了啥、预期啥、已知哪还可能翻车。往往比多敲几百行更能治「vibe 式交差」。

找一个小而真的开源仓库，看看 issue、PR、测试怎么写的——工程里烦人的经常不是语法，是协作和约束。把 Cursor/agent 当写得快的实习生，你当 reviewer：说不清动机和风险的改动，就不该合进去。准备实习或跳槽的，面经可以各看一点，别被某一种「必须手写」的叙事绑死，岗位之间差很多。

数据结构、OS、计网还要不要自己啃一点

有人会说：数据结构我也能让 AI 写，考前背背。能混过考试，但复杂度直觉容易空掉——以后服务为什么越跑越慢、查询顶不顶得住峰值，靠的是量级感，多半来自你曾经在纸上推过、在 debugger 里盯过、笨办法和巧办法比过。答案可以问模型，「落到自己心里」那一步还得自己来。

操作系统、计算机网络如果全程跳过「自己动手推一小段」，后面看日志、抓包、看延迟也会虚。环境搭建、样板代码可以让 AI 帮忙，但尽量保留几次：先对着现象自己推原因，推不动再问——顺序反了，学到的容易是话术。

海外教学圈也在吵同样的事，比如 CACM 这篇 How Can Vibe Coding Transform Programming Education?，讨论语法课还要占多少、学生时间该不该更多给问题分解。没有标准答案，但有一句反复出现：少抄不等于少想。 翻翻当背景就行，至少说明不是只有你一个人在纠结。

那还要不要读计算机相关专业

这是另一路问题，和「用不用 AI」叠在一起，更容易乱。

我的看法偏保守：如果你确定自己想长期做软件、系统、工程落地，计算机类（计科、软工、信安等）仍然是很稳的入口——不是因为你四年能背多少语法，而是你有整块时间把操作系统、网络、数据结构、数据库这些共同的底层语言过一遍；以后转语言、转栈，这套底子还在。AI 再强，问题怎么拆、系统怎么坏、边界在哪里，仍然吃这套训练；专业训练给的是时间密度和同伴环境，自学不是不可能，只是更挑自律。

如果你兴趣其实在别的领域，只是「听说计算机挣钱」才想挤进来，那要诚实一点：红利没有十年前那么粗暴，入门门槛在工具帮助下变低了，竞争也在变形状。 更现实的路线有时是「主修你真正喜欢的 + 辅修或自学编程到能干活」，而不是硬着头皮读四年自己不爱的专业——后者往往既痛苦又难拔尖。

没有「唯一正确」的志愿表。关键是别被单一叙事带着跑：既不是「不学计算机就落伍」，也不是「计算机已死快逃」。你想解决什么问题、愿意为什么负责，比选哪两个字写在毕业证上更要紧——专业是通道，不是判决书。

收尾

工具用得顺，不必羞耻，那是当下做这一行的常态。更值得问自己的是：关掉模型，你还能不能大致说清这段代码在干什么、可能在哪里翻车、翻了怎么查。

把 AI 从「代写」调成「协作，你签字」，压力不会一下子消失，但会好办一点：这周验收了几次？有没有读完一个小仓库？有没有靠自己推通过一个 bug？都是能排进日程的事，比整夜刷「程序员会不会失业」有用。

题主才大二，时间还长；刚工作一两年的朋友也一样，补判断力和负责习惯，什么时候都不晚。 真影响到睡眠了，就把焦虑拆成每周固定几小时的具体动作——比空转内耗划算。