面试还考手写代码？2026年该醒醒了
面试还考手写代码？2026年该醒醒了
上周面试，候选人打开Cursor，30分钟搭了一套完整的CRUD后台——用户管理、权限控制、数据看板，一气呵成。我问他：你这个ORM背后生成的SQL长什么样？他愣了三秒，说”没看过，跑得挺好的”。
我当时的表情，大概跟你现在一样。
录，还是不录？这个问题，正在拷问每一个带技术团队的人。
一个新悖论正在成型
Vibe Coding这个词火了之后，我跟十几个技术leader聊过。大家的感受出奇一致：团队里那个最能”出活”的人，未必是技术最扎实的人。
以前这两者高度重叠。能写出高性能代码的人，产出自然高。但现在AI把编码环节的门槛踩到了地板上——不对，踩穿地板掉到了地下室。一个刚学三个月编程的人，产出速度可能不输五年经验的老手。老手的内心OS大概是：”我花五年练的手速，你用Tab键一秒就补完了？”
这就是Vibe Coding制造的新悖论：生产力爆炸的同时，”能干活”和”真懂技术”之间的裂缝，正在以肉眼可见的速度撕裂。
Google工程师Addy Osmani在《Beyond Vibe Coding》里提了一个精准的概念叫”70%问题”——AI能帮你秒杀70%的功能，但剩下那30%，可能让你加班到怀疑人生。修一个bug引出三个新bug，两步前进三步后退，越改越乱。
问题出在哪？出在那70%的代码，写代码的人根本不理解它在干什么。这就好比你让一个不会做菜的人开了家餐厅，菜单是AI设计的，厨师是机器人——味道居然还不错，直到有一天客人说”我对花生过敏”，而老板根本不知道哪道菜里放了花生。
一个反直觉的信号
说个看起来不相关的事。
Claude Code团队的工程师Thariq最近公开发文，说他们团队正在把文档输出从Markdown全面切换到HTML。理由不是HTML更好写——恰恰相反，HTML对人类来说更难编辑。但关键转变是：这些文档已经不是人在写了，是AI在生成。
当AI成为主要的内容生产者，选型逻辑就变了。不再是”人类写起来方不方便”，而是”AI生成后人类看起来好不好”。Markdown简洁但表达力有限，HTML虽然笨重但能承载表格、样式、交互——AI生成这些毫无压力，人只需要看结果。
Thariq管这叫”Stay in the Loop”——保持在环里。不是你亲手干每件事，而是你能看懂、能判断、能在关键节点介入。
这个逻辑迁移到招人上，味道就变了：我们需要的不再是”亲手写每一行代码”的人，而是”看得懂AI写了什么、判断得了对不对、知道什么时候该踩刹车”的人。
新的团队分工模型
传统技术团队的分层很简单：初级写CRUD，中级做模块设计，高级把控架构。这是一条线性的成长路径，底层逻辑是”写代码越多越熟练，越熟练越高级”。
AI把这个逻辑打碎了。
当初级的活被AI接管了大半，”初级→中级→高级”这条爬梯子的路径还成立吗？梯子还在，但底下三层台阶被AI抽走了，你要么直接跳上去，要么摔下来。一个用Cursor三个月的新人，代码产出可能跟中级持平，但他缺的不是代码量，是判断力。
我观察到一些走在前面的团队，已经开始用新的三角模型来替代线性分层：
架构师——团队里那个”灵魂拷问”担当。别人都在想怎么写，他在想该不该写。想清楚要解决什么问题，哪些该做哪些不该做，系统的边界在哪里。AI能写代码，但它不知道应该写什么代码——这件事只能由人来定义。
AI操作员——驾驭AI的人。精通各种AI编程工具，知道怎么写prompt能拿到最优结果，能快速搭建原型验证想法。你可以把他理解成”AI时代的驾校教练”——他自己可能不是最好的赛车手，但他最懂怎么让这台车跑出最优成绩。
质量守门员——兜底的人。Review AI生成的代码，盯安全问题，盯性能陷阱，盯那些”看起来能跑但上线必炸”的隐藏bug。Addy Osmani说得好：把AI代码当初级开发者的产出来Review——它能干活，但你不能完全信任它。就像你不会让实习生独自上线一样，AI写的代码也需要一个老司机把关。
这三个角色不是三个级别，而是三个维度。同一个人可以兼具多个角色，但每个角色需要的核心能力完全不同。
给技术Leader的三个落地建议
说了半天框架，再不上干货你大概要划走了。落到招聘场景，具体怎么操作？
第一，面试加一道”问题拆解”题。 别再只考”实现一个LRU Cache”了——说真的，2026年还考这个，跟考驾照还要求手摇启动发动机差不多。给一个模糊的业务需求，让候选人现场拆解：核心问题是什么？可以拆成几步？哪些该用AI快速搞定，哪些需要人工把控？你考的不是他的编码速度，而是他定义问题的清晰度。
第二，设计一轮”AI协作实操”。 让候选人现场用Cursor或Claude Code完成一个任务——关键考察点不是他多快搞定，而是他怎么跟AI交互。会不会先规划再动手？AI给出的代码能不能看出问题？出了bug是自己分析定位，还是无脑复制报错让AI再试？这一轮下来，谁在”驾驭AI”、谁在”被AI驾驭”，一目了然。
第三，团队OKR里加一项”AI效能比”。 别只看产出量，看产出中AI辅助的比例和最终质量的关系。一个人用AI写了80%的代码但上线零事故，比另一个人亲手写100%但频繁hotfix，前者对团队的价值显然更大。这个指标会倒逼团队重新思考”什么才算好的工程师”。
回到开头那个问题
那个30分钟搭完CRUD后台、但说不清SQL的候选人，我最后录了。
不是因为他”能出活”，而是因为在后续的系统设计讨论中，他问了一个让我刮目相看的问题：”这个系统最可能在哪里出事？”——他不知道每一行代码的细节，但他知道该去担心什么。
招人标准这事，本质上反映的是你对”工程师价值”的定义。过去十年，好工程师等于”写代码快且好”。接下来十年，这个等式要改写了。
未来最值钱的，不是写代码最快的人，而是知道该写什么代码的人。