编程这行当技术更迭快得吓人但有些底层能力是穿越周期的。我这几年带团队、做项目、面试新人越来越清楚一件事决定一个人能走多远的从来不是他最新掌握了哪个框架而是那几项最容易被忽略的硬核 skills。尤其是AI辅助编程普及之后会提问、会判断、会兜底比会背API值钱得多。这篇不聊虚的聊聊我眼里的四组核心技能以及我是怎么在日常工作中刻意打磨它们的。1. 为什么AI时代反而要重新定义“会写代码”三年前我招人重点看算法基础和工程习惯。现在我面试会特意留出二十分钟给候选人一个模糊需求观察他怎么把需求理清楚、怎么提问、怎么验证结果。AI把写代码的门槛拉低了但把“判断力”的权重拉高了。1.1 从“会写”到“会判”AI带来的技能迁移以前写一个接口要手撸逻辑、查文档、调试边界条件一套下来少说半小时。现在把需求丢给AI可能几分钟就有初稿。但问题也来了AI生成的代码你的团队敢直接上生产吗我见过不少人复制粘贴跑通了就完事结果线上出了事故连问题在哪都不知道。因为AI只负责“生成”不负责“理解”。代码是它写的逻辑是你确认的出了事得你来扛。所以“会写代码”这个技能的定义变了。现在真正稀缺的是下面这几项:能把模糊需求拆成AI能理解的结构化描述能快速审阅AI产出判断能不能用、哪里有问题能在AI给你错误答案时有条理地反向排查、修正方向能建立一套验收习惯保证交付物在真实环境里站得住这四项就是我说的核心技能组合。1.2 环境变了基本功没变工具变了但底层的东西没变数据结构、算法思维、系统设计、排查逻辑。AI能帮你写出快速排序但如果你不知道什么时候该用哈希表、什么时候该用树你连Prompt都不知道该怎么写。我常用一个比喻AI像是经验很丰富的实习生你交代得越清楚它干得越好但它没见过你的业务、不了解你的历史包袱所以你必须有能力当那个“把关的师傅”。这一点决定了下面的每项技能都值得认真打磨。2. 技能一把模糊想法压成精确需求的结构化提问能力我观察到一个很普遍的现象很多人觉得“AI不好用”其实是“提问能力没跟上”。你问得模糊它答得也模糊最后两边扯皮。这不是AI的问题是需求传达的问题。2.1 我现在是怎么写Prompt的早期我用AI也随意后来发现效果不稳定才开始研究Prompt的结构化。现在我的标准写法基本固定成四个部分你可以直接拿去用:角色与目标明确告诉AI“你是什么角色、要完成什么目标”比如“你是一个熟悉Python性能优化的资深工程师目标是帮我定位这段代码的内存泄漏点”。背景信息给出必要的上下文包括语言版本、框架、数据量级、运行环境。这个最容易被忽略但对结果影响最大。约束条件把你的红线写出来比如“不要引入新的第三方依赖”、“兼容Python 3.8以下版本”、“必须在O(n)时间复杂度内完成”。输出格式规定返回结构比如“先列出根因假设再给出修改后的完整代码最后附上测试用例”。这里有个容易出问题的地方背景给少了AI只能瞎猜背景给多了它可能跑偏。我的经验是跟业务相关的核心限制一定要给足通用环境描述可以精简优先保证上下文整洁。2.2 追问一次拿到可用结果的关键第一次生成的答案很少能直接用。我试过很多次最终能跑通的结果往往在第三、第四次追问之后。追问不能是“这不对重写”而是带着反馈去沟通“这个方案在数据量到百万级别时会OOM请改用流式处理。”“你用了eval这不安全项目要求不能使用eval请换一种解析方式。”“测试用例覆盖了正常路径但没覆盖空指针场景请补充。”说到底AI是你的协作者你才是那个知道自己要什么的人。能把“要什么”表达清楚效果立刻翻倍。提示如果你发现自己反复追问都得不到想要的答案先停下来回头检查第一轮Prompt里的背景信息是不是给漏了。很多时候不是AI不行是你第一步就没描述清楚。3. 技能二对AI产出保持警觉的代码审判力AI生成的代码我用之前默认它是“有嫌疑的”需要经过审阅才能转正。这不是不信任工具而是工程安全的底线。我把审阅流程固定成了几个动作每步都不算复杂但组合起来很稳。3.1 我审查AI代码时的具体步骤第一眼看结构第二眼看边界第三眼看异常路径。这三步走完大部分问题能暴露出来。结构审查代码有没有按职责分层逻辑是不是堆在一个函数里AI倾向于把所有处理都塞进一段流程里可读性很差。我会要求拆分否则后面维护的人会骂娘。边界审查数组越界、空值处理、极端输入。这一步要反复问如果入参是None呢如果是超大数呢如果是空字符串呢AI经常漏掉防御性校验。异常路径审查网络超时、磁盘满了、下游服务挂了代码怎么表现AI默认世界是美好的但生产环境的现实是残酷的。有一个词在我们的团队里是硬规矩“没见过测试覆盖的代码就等于不存在”。AI生成的代码坚决要求补测试核心路径必须跑到。3.2 一个我踩过的坑至今印象很深有一回我让AI帮我写一个日志解析脚本它给的版本看着很简洁逻辑也很清晰。我没细看就接上了生产数据跑。结果输出全乱糟糟的排查了很久发现是因为AI在解析时默认日志格式里的时间戳始终是两位数年份没考虑过跨年场景。出问题之后我没怪AI怪自己跳过了边界审查。标准流程应该是先人工读一遍关键解析逻辑再拿三年跨度里的日志样本跑一跑。那次之后我给自己定了个规矩凡是涉及日期、编码、时区、路径拼接、并发状态的AI产出一律重点审查。这几类是最容易出隐蔽Bug的重灾区。4. 技能三从报错现场反推根因的调试基本功调试这项能力在AI时代不是变弱了而是更关键了。因为AI帮你把代码写好了但出了问题AI没法替你上生产环境背锅。排查思路这块硬功夫只能自己练。4.1 我调试时遵循的底层逻辑我不太相信直觉式的“这里改一下试试”那是在碰运气。我更信“假设-验证”循环复现先稳定复现问题。如果不能稳定复现先想办法固定现场拿日志、抓变量、留现场数据。分层按“输入-处理-输出”把系统切成几段用二分法定位问题在哪一段。这是效率最高的做法一次能排除一半的可能性。假设基于现象提出最可能的根因假设比如“可能是缓存没失效”“可能是浮点精度问题”。验证围绕假设取证据。加日志、写最小复现用例、查依赖版本。用证据说话而不是用猜的。这套逻辑不管面对多复杂的系统都适用。我带新人时发现很多人卡在“复现”上问题无法稳定复现就不敢动。我的建议是别干等主动构造条件用测试数据、Mock服务、调试器去逼近现场抓不到复现路径就从日志里找蛛丝马迹先定位到具体分支。4.2 现场实战一个超时问题从现象到根因的排查过程举一个实际例子。上线后某个接口偶发超时平均一小时出现两三次重启就好了但过一阵又冒出来监盘页面看不出规律API监控也一片正常。当时第一反应可能是内存泄漏。我先把超时接口的链路整条画出来网关-鉴权-业务逻辑-缓存-数据库。然后加了两层日志分别在入口和出口。跑了一个多小时拿到数据后发现出口耗时正常但网关到应用的时间出现了间隙也就是说时间不是耗在业务里而是耗在了请求等待上。接着查线程池状态发现核心线程池被打满队列里堆了一堆任务在排队。继续深挖发现有一个定时任务每天早上10点批量跑数据调用的是同一个线程池把资源吃光了。修复方案很简单给不同优先级任务分配独立的线程池批量任务隔离出去不影响在线接口。回头看整个过程每一步都靠证据推动没有靠猜。如果没有那套“复现-分层-假设-验证”的流程我大概率会在业务代码里白挖半天。5. 技能四建立自己的验收清单把AI协作变成可复现流程用AI最大的风险不是它写得不好而是你无法稳定地“让它写得好”。想解决这个不稳定就要把协作流程标准化。我把这件事落地成了一份验收清单每次跟AI协作必须走完这套流程才允许交付。5.1 我的AI协作流程长这样每次任务我都按下面五步走定义任务边界写清楚目标、约束、输入输出标准。这个阶段花5分钟后面能省50分钟。生成初稿把结构化Prompt发给AI拿到初版结果。静态审阅不看运行效果先只看代码做结构、边界、异常三件套审查。测试验证能写单测就写单测能跑集成就跑集成用真实数据样本压一遍。复盘沉淀如果这次AI产出了高质量的段落我会把它存档当成工具链里的模板下次同类任务直接复用。最后一步容易被忽略但长期价值最大。积累的模板和Prompt词库越厚后面的工作效率越高。我现在的做法是每个项目都会建一个prompts/目录把验证过的Prompt、对应产出、评审结论放在一起逃不出这个工作流。5.2 你不需要所有技能都满分但底线不能破看了上面这些别焦虑——我不是每项都满分同样在不停翻车。想清楚哪些是底线哪些是加分项优先级就出来了。底线技能代码审判力与调试基本功。这两项直接决定你交付的东西会不会出事不行就重点练没有捷径。加分技能结构化提问、验收习惯。决定你的产出质量和协作效率可以积累经验慢慢打磨不用指望一口吃成胖子。我用这个标准带团队也把自己放在同样的标准下审视。这四组技能核心不是天赋是刻意练习带来的可复制能力。如果你正准备开始我个人的建议是先挑一个你最近踩过的真实Bug用“复现-分层-假设-验证”的流程走一遍写下记录下次再用AI帮你写代码强制自己完成边界审查和测试补齐。就这两个小动作坚持一个月你会明显感觉到自己的判断力和稳定性上了一个台阶。