★ FEATURED ARTICLE 1. 底气从哪来AI放大的是判断力不是代码量先说个可能有点反直觉的结论AI编程工具铺天盖地这一年多我们组里最早用上头、用得最溜的不是那几个九八五应届生反而是两个写了十几年业务代码、平时连GitHub Copilot都懒得装的老同事。我自己也有类似感受——好几年了第一次觉得这行当又有点意思了。为什么因为AI真正解放的不是写代码的双手而是知道该让AI写什么、写得对不对、出了问题去哪儿查的脑子。而这颗脑子恰恰是时间喂出来的。1.1 领域知识让AI的输出可以被快速校验我自己带过好几个新人带过之后最大的体会是写代码这个动作本身早就不是门槛了。真正的门槛是拿到一段代码能不能快速判断它靠不靠谱。举个例子。我们系统里有个祖传的订单状态机模块状态流转规则散落在四个服务里触发条件还牵涉到MQ消息时序。我让AI帮我梳理状态迁移的边界情况它给我列了满满十二种分支看着头头是道。我扫了一眼就发现其中三种分支在业务上根本不可能出现——因为上游系统压根不会推送那种状态的订单过来。这种判断从哪来是从过去无数次熬夜排查线上故障、翻了几百个工单、被产品经理按着头改需求之后沉淀下来的。AI能把十二种分支写得漂漂亮亮但哪些分支根本不需要处理这种业务判断它给不了你因为它没有经历过你被业务方半夜电话叫醒的痛。新人拿到同样一份AI输出大概率会把这十二种分支全部实现项目周期多排三天代码量多了两千行然后还觉得AI挺能干。这不是新人的错是他们缺少一套对业务上下文进行校准的坐标系统。1.2 从需求到代码的翻译能力成了真正的护城河我发现一个很有趣的现象这两年网上铺天盖地教人怎么写AI提示词什么角色扮演、思维链、few-shot花里胡哨。但我自己实测下来最有效的提示词往往就是一段自然语言的需求描述配上一两句边界条件说明顶多再贴一段现有代码作为风格参考。为什么我能用大白话就让AI写出合用的代码因为我脑子里已经把需求拆解完了。我知道这段逻辑该由哪个服务承担、该在哪个时机触发、该返回什么结构、该留哪些扩展点。AI对我来说就是一个打字特别快、语法永远不会写错、但完全不懂业务的实习生。我只需要把翻译好的需求喂给它它把代码吐出来我来验收就行。新人如果需求理解本身就有偏差给AI的指令再花哨也没用。AI会非常礼貌地用看起来专业的代码把错误的需求实现得漂漂亮亮。这个能力不是提示词技巧能弥补的它来自对系统架构、产品逻辑和业务目标的长年浸泡。说到底十年经验让我有底气的核心原因是AI终于把我的优势从手写代码的速度转移到了理解复杂系统的深度。而后者是我真正擅长的事情。2. 新人的困局不是不会用AI而是没有可兜底的判断力说不担心新人那是假的。我最近面试了几位有两三年经验的候选人技术热情都不错但有一个共通问题让我非常警觉他们太相信AI给出的答案而且没有一套怀疑AI的本能。2.1 AI的自信语气对新人是一种致命误导用过AI编程的人都知道它回答问题时那种笃定的口吻——这个方案是最优的这样写可以避免并发问题标准做法是……——特别容易让人信服。它不像搜索引擎那样给你一堆博客让你自己分辨它直接给你一个看起来完整、结构清晰、甚至还带注释的答案。问题在于它偶尔会一本正经地编造API接口、用错已被废弃的库、或者给出一个在Demo环境跑得通但一上生产就会出事的写法。我见过一个新人用它生成的代码做支付回调验签AI用了某种对称加密的方案逻辑上完全自洽但真实业务里支付平台压根不支持这种算法好在code review被拦下来了。老程序员为什么不容易被带偏因为我们被坑过太多次了。看到某个技术方案第一反应往往是这个方案在什么场景下会翻车而不是这个方案看上去挺完整。这种本能的防御性思维是建立在大量真实失败样本之上的AI没有能力替新人积累这些样本。2.2 被工具带着走跳过地基盖楼看着快塌得也快我观察到一个趋势现在不少新人靠AI组装功能的速度确实惊人。今天要一个登录注册明天要一个后台管理后天要一个文件上传。每个单点功能都能快速产出但一旦把这些功能串起来问题就来了——Session和Token混用、异常处理流于形式、数据库连接到处乱开、日志打得乱七八糟。这不怪他们。AI天生是来一个需求写一段代码的模式而真实系统的复杂度恰恰藏在跨模块的约定里。以前的程序员是先从地基搭起写过增删改查写过中间件手撸过底层网络请求知道每个环节的重量。现在的新人是直接用AI生成标准件每个标准件本身看着没问题但装修得再漂亮也掩盖不了承重墙被省掉了的事实。我见过最典型的案例是一个新人让AI帮忙重构一段报错的代码AI给出的新版本看着更简洁了但把原来代码里的一个超时重试机制给顺手删掉了。因为AI只看了当前函数没看到调用方对超时时间的依赖。这种局部优化导致全局破坏的问题在AI辅助开发场景下频繁发生而且新人往往根本意识不到是AI改坏的。2.3 缺少手动挡经验就无法给AI当裁判我个人喜欢把AI编程比作自动挡汽车。以前大家都是开手动挡过来的知道离合器在哪、换挡逻辑是什么、怠速是什么概念。现在很多新人一上车就开自动挡当然舒服但一旦遇上坡、烂路、爆胎这些特殊情况你就不知道车辆为什么会顿挫更不知道该怎么处理。对应到编程里什么算手动挡经验就是不看任何框架文档自己用原生代码实现过一遍HTTP请求就是不用ORM自己手写过几条SQL联表查询就是不依赖现成的状态管理库自己用事件机制实现过一套简单的数据流。这些笨功夫看似低效但它们会在大脑里留下关于底层机制的印记。有了这些印记你再看AI生成的代码一眼就能看出它在这个项目里其实不需要引入那么重的框架或者它把应该放在事务里的操作拆到了事务外。没有这些印记AI的代码对你来说就是黑盒你只能祈祷它是对的而不敢拍胸脯说它是错的。所以我逐渐意识到新人的焦虑其实比我们想象中更深。他们不是不努力而是被AI抢走了本该属于自己的试错过程结果就是AI太能干反而让他们失去了建立判断力的土壤。3. 如果我是新人一套应对AI时代的自我训练路径标题里问新人怎么办这个问题我认真想过很久不是站着说话不腰疼地喊多学基础保持学习这种空话而是真正能落地的操作方法。如果我现在是一个刚入行或还没入行的新人我会按下面这套逻辑来安排自己的成长路线。3.1 先学会问问题再学会用答案很多新人用AI的方式是给我一段代码而我会建议他们改成告诉我这个问题的本质是什么。同样是写一个分页查询前者直接生成三行代码后者会逼着AI解释分页的底层原理、不同数据库的差异、深分页的性能陷阱。一个特别实用的习惯是拿到AI的答案之后不要急着复制粘贴先追问三个问题——这个方案在什么场景下不适用这个方案的性能瓶颈可能在哪里如果数据量扩大十倍这个方案还成立吗哪怕AI的回答可能有点泛泛而谈这个追问动作本身就在训练你的批判性思维。慢慢地你会形成一种拿到答案先找边界的肌肉记忆这是未来所有技术判断力的地基。另一个很有价值的习惯是让AI给你出题而不是做题。比如你刚学完Redis缓存策略让AI设计几个相关场景让你猜结果或者让它故意给你一段有缺陷的代码你来当code review的人。这种攻防练习比被动接受知识有效得多因为它在逼你调用已有的知识体系做出判断。3.2 用问题清单给AI输出做质检我自己在实际工作中摸索出一套给AI代码做检查的清单分享出来新人可以直接抄作业。拿到AI生成的一段代码之后别管它编译通没通过先用下面这五个维度过一遍异常处理它处理了哪些异常漏掉了哪些如果数据库连接失败、网络超时、消息重复消费分别会发生什么边界条件入参为空怎么办集合只有一个元素怎么办并发情况下同一个用户提交两次请求怎么办数据一致性这段代码是放在事务里的吗如果中途失败会不会产生脏数据性能假设它是不是在一个循环里发了N次外部请求是不是每次调用都新建了一个连接可维护性三个月后的你或者同事看得懂这段代码为什么要这么写吗有没有足够清晰的注释我开发了这套清单模板后第一件事就是让团队的每个人贴在工位上。它是目前我看到过降低AI辅助开发风险最有效的方式比任何提示词技巧都顶用。3.3 刻意保留无AI训练的固定时间现在很多新人从入职第一天起就是AI全程陪同这让我挺忧虑的。我的建议是每周刻意留出几个小时关掉所有AI辅助工具纯靠自己的记忆和能力去写一段代码、修一个bug、或者实现一个以前没用过的新API。这个无AI训练不是为了怀旧而是为了让你的大脑保持从零推导的能力。说得直白一点面试的时候不能开AI吧线上出了紧急故障你总不能让AI去翻日志吧系统设计评审的时候你总不能在会议室里现场问AI吧这些场景都在考核你有没有脱离AI独立思考和表达的能力。我自己有个习惯学一个新框架时一定先把官方文档从头到尾过一遍然后合上电脑凭记忆画出它的核心流程再把AI叫出来和自己对照。这样AI对我来说就是复习教练而不是代写枪手。这两种角色带来的成长速度差距非常明显。3.4 借助AI搭建个人知识库而不是当聊天机器人用我发现很多新人把AI当搜索引擎用问完就关窗口什么也没留下。这太浪费了。在我眼里AI最大的价值是帮你整理、串联、复盘已有的知识碎片——而不是替你从零生成知识。我现在的工作方式是这样的每学一个新概念比如分布式事务先在白纸上用自己的话写出理解然后让AI帮忙检查、补充、找漏洞。最后我会把对话整理成一篇带目录、带示例、带易错点的个人笔记存到自己的知识库里。等再过三个月回头看这些笔记就成了我自己的第二大脑。对新人来说也一样。与其每天问AI一百个零散问题不如每周挑一个主题和AI做一次深聊聊完沉淀一篇完整的笔记。半年下来别人是收藏了一堆聊天记录你拥有一套自己的知识体系。这种差距会在工作中非常直观地体现出来。4. 关于新人怎么办的最终回答从拼手速到拼品味写到这里又回到标题里那个问题。其实我内心真正想说的是新人们你们担心被AI取代的焦虑我可以理解但这个焦虑很可能放错了重点。让我用我自己的经历来说明。4.1 AI淘汰的不是不会写代码的人而是不知道该写什么的人我的第一份工作是在一家传统软件公司做外包整天写各种报表和增删改查。那时候我特别羡慕那些能设计系统架构的技术大牛觉得他们懂的东西遥不可及。十几年后回头看我走过的路其实很普通——就是在一个又一个项目里被迫做判断。这个需求该不该做那个方案能不能复用线上故障先恢复还是先查根因这个技术选型是看长远还是看眼前每一个选择都在积累判断力。而AI的到来本质上把做判断的价值放大了十倍。因为执行的部分已经被AI大幅压缩了该做什么、做到什么程度、什么不该做反而成了所有技术决策的核心。这个论点对新人意味着什么意味着如果你们把成长重点放在提高品味而不是提高手速你在这个行业的价值不但不会被AI稀释反而会被AI放大。4.2 品味是可以刻意训练出来的有人可能会说你说的判断力和品味听着太玄了新人从哪入手其实不难就是多接触好和坏两端的东西。一端是大量阅读高质量代码。GitHub上有的是知名开源项目看别人怎么组织模块、怎么写注释、怎么做异常处理。现在有了AI你可以让它把一段代码逐行讲给你听也可以问它这个设计有什么优点如果让你改进你会怎么改。另一端是大量踩坑。年轻人现在写代码AI兜底踩坑概率其实变高了但很多人踩完坑也不复盘下次照样掉进去。我的建议是给自己建一个踩坑日记每次线上出问题或代码被review挑出毛病都把过程、原因、以后怎么避免写下来。一年下来这本日记就是你的判断力起步资产。如果你现在开始有意识地做这两件事两年后你再看AI生成的那段代码就不会只觉得好厉害而是会觉得这里有个并发隐患那里可以简化一下这个方案用在这里其实不合适。这种不满足于表面正确、愿意深挖本质的习惯就是我在标题里说的底气。4.3 我也会焦虑只是不再对AI焦虑最后说点掏心窝的话。我虽然标题写着重新有了底气但也别误会成我从此高枕无忧了。我真正常常焦虑的事情不是AI会不会取代我而是我的知识结构会不会老化到连该问AI什么问题都不知道的程度。以前我觉得技术更新快什么新框架、新语言层出不穷追得人喘不过气。现在AI把新技术学习曲线削平了一截我反而敢去碰那些以前觉得太新、太杂的领域了。比如之前我一直没决心去碰大模型应用开发后来靠AI辅助几天就把一套完整流程跑通了。这种敢碰陌生领域的信心在AI时代之前对于老程序员来说是稀缺品。所以我特别想跟新人们说你们其实拥有一个我这代人没有的机遇。你们可以在入行早期就建立AI协作的工作习惯可以利用AI把接触新项目、新领域的成本降到最低可以更早地把精力投到判断力、创造力和沟通能力这些AI难以替代的维度上。至于那些被AI抢了饭碗的论调听听就好真上项目了你就知道一个会思考的工程师加AI和两个不会思考的工程师加AI产出的差距有多大了。4.4 一点私心的小建议如果只能送新人一条建议我会说试着把AI当成一个需要你管理、指导、验收的实习生而不是有问必答的老师。你对实习生不会直接收下它交上来的代码你会先问它为什么这么写、考虑过哪些边界条件、有没有更好的方案。养成这个习惯你带出来的AI会越来越懂你的风格你对代码的理解也会越来越深。我见过太多人把AI养成了打字机却没让AI变成自己的思维磨刀石——后者才是这笔技术红利里最值钱的部分。行业里总有人说AI会让程序员失业我说句不太好听的会让一部分人失业的从来不是工具而是那些只依赖工具却不更新自己的人。这件事放在十年前成立放在现在依然成立。只不过以前我们用搜索引擎筛选信息现在我们用AI筛选方案本质都是信息变多了判断力更值钱了。新人同志们你们脚下的起跑线确实和我当年不一样了。跟我当年比你们的起跑线前移了——AI替你们铲平了很多低洼地。但赛道变长了真正需要冲刺的路段还在后面你们得提前为那些路段储备体能。这份体能就是今天开始建立的判断力、业务理解力和系统思维。加油这行比你们想象的有意思也值得你们沉下心来深耕。
阅读完成 · 觉得有帮助？
