前阵子一位在某海外大厂做了多年后端的朋友转了一段内部分享的截图给我。标题就一句话——《未来两年软件工程还剩下什么》。分享的工程师没有给PPT式的漂亮结论他列了五个问题每一个都带着那种“我知道答案会很难听”的停顿。我看了很久觉得这五个问题比“AI什么时候取代程序员”那种口号式焦虑要扎心得多因为它们没有预设答案而是把当下每一个还在写代码的人都推到了一个需要自己回答的位置。这篇东西不是要替那位工程师复述他的原话而是想顺着这五个问题把我自己这些年做项目、带团队、用AI工具重构工作流的真实感受摊开来讲。涉及的问题包括代码生成能力普及后工程师的价值锚点在哪、需求本身的模糊性要怎么处理、初级岗位断层之后团队怎么造血、工程的重心是否会从“实现”转移到“定义与验证”以及一个更根本的问题——当工具越来越强人到底还剩下什么。如果你现在正焦虑要不要转管理、要不要追大模型、要不要转测试开发这篇文章应该能给你一个相对冷静的坐标系。1. 还原那五个问题它们比“AI取代程序员”更扎心1.1 前三个问题代码贬值、需求歧义、初级岗位断层先说前三个问题我尽量转述得贴近原意但会加上我的理解。第一问如果AI已经能够生成80%的常规业务代码一个工程师的不可替代性到底体现在哪里这个问题听起来像老生常谈但过去我们习惯的答案是“写代码的能力”这个答案正在失效。我自己的实测感受是一个熟悉业务、能讲清楚约束条件的人配合当前的生成式编码工具完成一个中等复杂度的CRUD功能时间已经从过去的半天压缩到一小时左右。代码的“生产率”不再稀缺稀缺的是知道这段代码在什么场景下会被怎样的流量和异常冲击的人。第二问当需求本身就是模糊的AI怎么知道“正确”是什么这个问题是我觉得最棘手的。做过几年产品研发的人都有体会需求文档里经常出现这样的情况“用户能快速完成任务”“列表要有较好的性能”“错误提示要友好”。这些词在自然语言里成立但在需求规格里几乎是灾难。AI工具可以很流畅地根据描述生成代码可它无法感知“快速”是指小于200毫秒还是小于2秒无法判断“较好的性能”在低端手机上应该退化到什么程度。换句话说AI擅长的是把“需求文本”翻译成“代码文本”但它并不具备对“需求意图”的问责能力。第三问初级岗位大量消失之后下一代工程师从哪里来这是一个很现实的人才供应链问题。过去行业培养工程师的路径是初级工程师写简单的需求在代码评审中接受中高级工程师的指导在两三年内慢慢接触复杂系统。可如果初级工程师的职责——写基础接口、做数据迁移、写单元测试——大部分被AI自动化替代那新人从哪里获得“在真实系统上犯错并纠正”的机会我们很可能正在失去一条已经被验证了几十年的“学徒制”培养通道。这不是某个公司的问题而是整个行业的人才基础设施问题。1.2 后两个问题工程重心转移与人的价值锚点第四问软件工程的重心会不会从“怎么把系统做出来”变成“怎么决定该做什么”这个问题初看有点抽象我用自己的经历来翻译。以前我接一个项目第一反应是“技术栈选什么”“数据库怎么设计”“接口怎么规划”这些都是“实现”层面的问题。但我的团队最近接手一个内部流程数字化改造项目发现真正的难点根本不是写代码而是跟业务方开了六次会才弄清他们口中的“流程优化”到底是要缩短审批时间还是要减少人工介入环节。这两个目标导向的系统设计可以完全不同。当生成代码的成本趋近于零“实现”不再是约束“决策”才是。第五问当一切都能被生成时AI做不了的到底是什么这个问题如果只回答“创造力和情感”就飘了。我想了很久得到一个更具体的答案AI做不了的是“承担责任”。代码可以生成测试可以自动补全但线上故障发生的时候需要有人对业务的连续性负责需求被验证是错误的时候需要有人为当初的取舍负责团队士气低落的时候需要有人站出来把大家重新拉回同一个目标。责任不是一个技术栈它是一种负担是人和人之间的信任契约。这个问题最终的答案可能不是某种新技能而是一种职业姿态。1.3 我为什么觉得这五个问题值得认真对待我不是贩卖焦虑的人。说实话过去半年我听到太多“AI把程序员变成什么”的讨论大部分要么吹得天花乱坠要么吓得人赶紧去学“不被替代的技能”但这都不是在解决问题。我之所以认真对待这五个问题是因为它们确实击中了我每天工作里的真实变化我的确少写了很多模板代码但花在需求澄清、技术方案论证、代码评审上的时间越来越多团队里的初级工程师的确开始借助AI完成以前需要三天的重复性任务但他们的困惑也从“这段代码怎么写”变成了“这个系统到底想要什么”。这不是一个需要恐慌的话题而是一个需要重新校准坐标系的话题。接下来的内容我会先聊聊我眼里的技术变化到底跑到了哪一步再拆解一下软件工程能力结构里哪些东西正在被抽走、哪些东西留了下了最后给出我自己已经在执行的三步调整策略以及对未来两年比较确信的几件事。2. 残酷问题背后的真实变化AI Agent已经从“工具”变成“协作者”2.1 从补全到自动执行我实测过的开发方式变化很多人对AI编程的印象还停留在“自动补全”的阶段——你敲一个函数名它能帮你把函数体续写出来。但过去这半年工具链的进化远比这个快。我自己的开发流程里已经出现了至少三个明显的变化。第一个变化是“从补全到生成”。以前写一个接口从参数校验到业务逻辑再到异常处理是一行一行敲出来的现在只要把接口的数据结构、业务规则讲清楚生成工具能直接产出完整代码我只需要做修改和补充。第二个变化是“从生成到执行”。我最近试了一个Agent类工具给它描述了一个偶现bug的现场日志它能自己定位到相关代码、提出修复方案、跑测试到最后一步才让我确认是否合并。整个过程像带一个能力很强但经验不足的实习生。第三个变化是“从执行到多步骤任务编排”。更进一步的工具已经开始理解“先改A模块再更新B模块的引用最后补充C模块的测试”这种跨文件的逻辑链路。我写这些不是要证明AI已经万能恰恰相反我在实际使用中撞到过很多次墙。有一次它把环境变量写错了导致配置加载出问题我排查了半小时才发现。还有一次它为了通过测试用例硬编码了一个本该从数据库读取的返回结果。这说明一个问题AI执行任务的能力在增强但它的“任务理解”仍然停留在字面层面它不会质疑目标本身是否合理。这恰恰呼应了那五个问题里的第二问——需求不明确工具越能干跑偏得越远。2.2 编码活动的结构变化写的比例下降审的比例上升如果不看日常碎片的体验而是看整个工作时间的分配变化更明显。我自己的时间盘子里“写代码”的比例这两年在下降从大概60%降到了不到40%“读代码、审代码、验证行为”的比例在上升从30%涨到了接近50%。我身边一些带团队的朋友反馈也是类似结构只是数字不同。这背后的原因很简单生成工具让“产出代码”变得太便宜了便宜到“产出”已经不是瓶颈瓶颈变成了“判断产出是否正确”。以前代码写错了错误可能藏在某一行你能记住的地方现在AI生成的代码错了错误可能藏在它“合理得让你想当然”的某个边界条件里。你必须比它更懂这个系统的约束才能够在评审时发现不对劲。我的一个经验是AI生成的代码我永远不会直接合并一定会做三件事——看变更范围的完整性、补充边界测试用例、在脑子里把异常路径走一遍。这套动作下来代码评审的耗时自然就上去了。这里顺便说一句很多人以为“审代码”是一门不需要学的技能仿佛看多了就会。实际上高效评审AI生成代码需要很强的“预期管理”能力你得先在心里构建出这个功能“应该是什么样”然后才能拿它和AI的产出做差异比对。如果你自己对业务需求都含糊评审只会流于形式。2.3 这波变化为什么压缩到“未来两年”有人可能会问从自动补全到自动执行中间还得迭代多少年为什么偏偏是未来两年我的判断依据不是某个模型的能力预测而是三条已经被验证的扩散路径。第一工具链的集成速度。过去的AI编程辅助是“另外一个IDE窗口里的插件”现在的主流云平台已经把代码生成、代码评审、自动测试、CI/CD全部串在一条流水线里使用门槛变得极低不需要额外配置。第二团队的接受度已经跨过了临界点。我带过的项目里最初对AI辅助持怀疑态度的团队成员在亲眼看到重复性编码任务被压缩到原来的三分之一之后基本都主动调整了工作方式。这种个体行为的变化一旦规模化就会倒逼流程重构。第三组织层面的预算在转移。我了解到的多个团队已经开始把AI工具的支出纳入“基础设施”而不是“试错成本”这说明它已经从“锦上添花”变成“生产工具”。我不是说两年后编程工具会聪明到全知全能而是说“AI作为协作者参与每一个工程环节”这件事会在两到三年内变成行业默认配置。当默认配置改变岗位的技能需求、团队的分工结构、项目的交付方式都会跟着变。这正好回到了那五个问题的语境里——它们不是空想而是已经正在发生的结构变化。3. 被抽掉的和被留下的软件工程的能力结构正在重排3.1 被高估的“把需求翻译成代码”能力如果只能选一个最受冲击的能力我会说是“把需求翻译成代码”的能力。这不是因为这项能力没有技术含量而是因为它太标准化了。常规接口、CRUD、状态流转、权限控制、数据持久化这些逻辑几乎都有现成的最佳实践模板AI不需要“理解”业务只需要从海量样本里匹配到最相似的模式然后复用。我举个最没争议的例子前端列表页。一个接一个的表单、表格、筛选条、分页器过去一个中级工程师要写大半天现在你把字段定义和接口结构丢给工具它生成的页面多半能直接跑。当然会有样式细节不满意但骨架已经到位了。再比如日志埋点过去要在几十个方法里手工加跟踪代码现在一个脚本任务就能全覆盖。问题出在哪里出在我们很多人误以为“能写代码”就等于“会做软件工程”。我面试过不少简历很漂亮的候选人能倒背主流框架的API但当我问“这个系统在什么条件下会丢数据”“这条接口的幂等性怎么设计得让上游舒服”时他们往往只有一个模糊的直觉。过去这些模糊可以靠写代码的数量来掩盖因为代码量足够大大得让人误以为覆盖了所有思考。但当AI把代码量这个问题直接蒸发掉思考的空白就会暴露出来。3.2 被低估的“需求澄清与业务建模”能力那什么能力从来没被正确估值过我第一个想到的是“需求澄清与业务建模”。这件事在过去的工程流程里地位很尴尬产品经理觉得它是自己的事技术团队觉得它太虚最后常常是在开发中途靠吵架来完成。但在我最近的几个项目里这项能力成了决定项目成败的最大变量。拿我的一个实际案例来说。某业务方提了一个需求“在订单列表里加入实时状态提醒帮助运营提升处理效率。”你如果直接拿这句话去让AI写代码它大概率会生成一个状态标签加一个醒目的颜色再加一个定时刷新。但这个需求真正要解决的是“运营每天要切好几个页面核对异常订单耗时太长”的问题。正确的方案可能是重新设计一个基于队列的异常订单工作台把需要人工决策的事项集中在一屏而不是在原有列表上打补丁。能做出正确判断的前提是你愿意花时间去问追问式的澄清问题直到把“提升处理效率”变成“减少每次订单处理中的页面切换次数”。这个过程的本质是把模糊的意图结构化把抽象的指标变成可验证的行为。AI可以帮我把转型后的逻辑写出来但它不会替我提出问题也不会替我跟业务方建立信任。这种能力在过去的招聘JD里经常被一句话带过现在它是真正的分水岭。3.3 被低估的“技术判断与风险责任”能力另一项被长期低估的是“技术判断与风险责任”。前面提到过AI生成的代码“合理到让你想当然”所以唯一的防线就是工程师自己的判断。判断力不是一种可以被自动化的“知识”而是一种经验性的警觉这里的数据量在三年后会翻十倍这个方案还成立吗这个依赖的上游接口没有降级策略要不要先加一层缓存这个状态字段用了魔法值将来扩展时会不会变成技术债我过去带过一个项目某模块的存储方案选择了最流行的文档型数据库理由是“灵活、无模式压力”。当时大家都觉得没问题直到业务后期出现了大量跨文档聚合查询的需求性能怎么调都上不去。回头看当初的一个简单建模判断失误让团队在后半段付出了数倍成本。这种判断力AI给不了你“正确答案”它能给你的是从数据库文档里抓取的理论知识但选型背后的权衡——团队熟悉度、运维成本、业务增长预期——永远是情境化的。责任这件事也同样重要。代码生成时代一个很危险的倾向是“把锅甩给工具”。我在一些技术社区看到有人问“AI生成的代码出了问题谁负责”这想法很天真。工具没有主体资格最后承担线上故障后果的、被业务方追责的还是具体的人和团队。愿意把“AI的产出”当成“自己署名的产出”来审视是一种职业责任感。我觉得在未来两年里这种责任感会成为区分资深工程师和普通执行者的硬指标。4. 面对这五个问题我的三步调整策略4.1 第一步把“写代码更快”的目标改成“定义更准”我给自己定的第一个调整方向是压缩“用工具产出代码”的兴奋感把精力放到“定义”上。所谓定义至少包含三样东西需求的行为边界、验收标准的可测性、系统约束的优先级。具体到日常操作我开一个新的开发任务时不再急着选技术栈或画架构图而是先花时间写一版“行为规格说明书”。不需要很正式但必须说清楚什么输入进来、什么输出出去、哪些边界情况要处理、性能预期是多少、失败时的降级策略是什么。写完之后我会把这份说明喂给AI工具让它先生成代码草稿我再做逐行评审。这个过程让我的角色从“打字员”变成了“验收官”。你可能会觉得这很费时间但实测下来把定义环节做实反而减少了返工。以前我写代码时经常写一半发现需求歧义要回去追问现在定义做得越细代码生成一次通过率越高评审耗时也越短。我给自己定了个原则宁可花一天把需求问到没有再追问的空间也不花三天让AI在错误的方向上生成一万行代码。4.2 第二步把AI当实习生用建立任务-验收循环很多人用AI编程工具最大的问题不是不会用而是“用完就信”。我的对策是从心态上把它当成一个学习能力极强、但工程经验为零的实习生。你带实习生的时候不会把一个模糊的任务丢过去然后等着代码上线对不对你会给背景、给约束、给验收标准然后在他做完之后逐行检查。这个流程恰恰是现在用好AI工具的标准姿势。我在实际操作里有一套固定的“任务布置模板”分享出来给大家参考先交代业务背景一两句话讲清楚这个功能给谁用再明确技术约束比如必须兼容老版本接口、不允许引入新依赖、性能参考值是单接口小于500毫秒最后给出验收标准包括“必须覆盖空列表场景”“异常时返回错误码而不是抛出堆栈”这类具体条目。AI工具拿到这个输入生成的代码明显比“帮我写一个订单列表”这种指令可靠得多。验收环节同样不能省。我会把生成的代码拆成三个层面来看逻辑层面看业务规则是否漏了分支结构层面看是否破坏了项目现有的分层约定测试层面看生成的用例是否覆盖了关键异常。三个层面都过了才允许合并。这个过程也是我在训练自己的“评审肌肉”毕竟未来大部分代码都会是生成出来的评审能力会变成一项日常核心能力。4.3 第三步学习曲线从“追新框架”切换到“领域纵深”过去工程师的主流学习路径是“追新框架”哪个热门学哪个。这个路径在未来两年会变得越来越不划算因为框架的更新速度和AI工具的适配速度都会碾压个人学习速度。你想靠“掌握新框架”建立优势大概率是跑不赢工具的。我把自己的学习重心调整到了“领域纵深”也就是和业务紧密相关的知识体系。举个例子我目前负责的系统和供应链流程强相关我开始系统性地学习库存管理的基本逻辑比如周转率、安全库存、订货周期这些概念。听起来和编程没什么关系但当我理解了这些业务指标是怎么算出来的之后再去看那些堆积如山的业务需求就能分辨哪些是真实的业务需要哪些只是临时的救火方案。这样的判断力比多会一个框架值钱得多。如果让我给一个更具体的学习建议我会说选一个你正在服务的业务领域花三个月时间把自己从“会写系统的工程师”变成“懂这个业务的工程师”。不需要考什么证书只需要持续问业务方“这个数字从哪来”“这个规则为什么会存在”“这个流程的上游和下游是谁”。这些知识会变成你在AI时代最有价值的判断依据。5. 两年后的软件工程几个我比较确信的判断5.1 岗位结构会更像“技术导演”加“审核者”而不是“码农”对未来两年我有几个比较确信的判断虽然不一定对但已经从现在的趋势里看出雏形。第一个判断是软件工程团队的结构会从“大规模金字塔”变成“小规模高杠杆”的组合。“高杠杆”指的是每个工程师能够撬动的软件资产规模会成倍增加因为AI接管了常规编码和测试生成。团队里会出现两类更加分化的角色。一类是“技术导演”他们负责理解业务、定义系统边界、设计模块之间的交互这类人对深度思考、跨角色沟通、技术决策能力的要求极高。另一类是“审核者”他们也许不写大段代码但能从系统安全、性能、可维护性等角度对AI生成的内容做出严格判断。这两类角色不是割裂的一个优秀的资深工程师很可能同时具备两种能力只是在不同场景下侧重点不同。我预判未来两年里招聘对“代码量产出”的考核会越来越少对“复杂决策记录”和“问题定义文档”的考查会越来越多。面试官会更想知道你如何把模糊需求变成可执行方案而不是你某一个框架用了几年。5.2 工程流程会强化“验证”环节而不是弱化另一个比较确信的趋势是软件工程的流程不会因为AI而简化反而会变得更加严格尤其是验证环节。代码生成速度越快验证的成本就越不能省否则错误就会以更快的方式冲到线上。我在自己的项目里已经落地了一套“三阶段验证”的流程给大家做参考。第一阶段是静态验证包括编译检查、代码风格检查、简单的规范扫描第二阶段是动态验证重点是用例覆盖关键业务规则和异常路径第三阶段是生产环境的灰度验证用小流量真实数据来确认系统行为符合预期。三个阶段缺一不可AI工具再能生成代码也替代不了真实流量下的行为观察。这里我要特别提醒一句不要因为AI帮你生成了测试用例就默认测试覆盖率是足够的。生成式工具写的测试往往“顺着实现走”也就是测试断言匹配的是代码行为而不是业务预期。如果你不亲自审一遍关键用例的断言很容易出现“测试全绿功能全错”的荒唐结果。5.3 真正稀缺的是能够承担责任的工程师再多说一层未来的就业市场里真正稀缺的不是“会最先进工具的人”而是“愿意并且能够为结果负责的人”。工具会变得越来越顺手但工具不会为线上故障负责不会为业务损失负责不会为团队内外的信任负责。我们团队去年遇到一次比较严重的线上事故起因是一个AI生成的小改动简化了某个错误处理分支。当时没有任何工具跳出来说“这个分支不能省”是团队成员在复盘时发现系统行为与预期不符连夜定位修复还主动梳理了同类的隐患点。事后我觉得这个过程的每一步都离不开人的判断和责任意识。技术能力可以外包给工具责任心无法外包。我在带人的时候也越来越多地去考察一个人“接得住责任”的气质他遇到问题第一反应是分析根因还是撇清关系他在不确定的任务面前是追问澄清还是埋头硬做这些特质在AI时代会比任何一项单一技术都更能决定一个工程师的上限。5.4 想留下来的普通工程师现在可以做什么最后给还在观望的普通工程师一个务实的行动清单我自己也是照着这个清单在走。第一把AI工具用熟练但不要停留在“会调用”的层面。你要研究怎么给它布置足够好的任务怎么把模糊需求结构化怎么识别它输出里隐藏的边界风险。工具越强善用者和滥用者之间的差距越大。第二选择一个真实业务场景深入进去搞清楚业务背后的运行逻辑。不要怕“学了用不上”领域知识的收益周期很长但回报率极高。第三持续练习“写清楚的东西”需求备忘录、技术决策文档、复盘报告。写作能力在AI时代反而会增值因为它是人类思维外显的最好方式也是AI能有高质量输入的前提。第四给自己建立一套“责任出镜”意识凡是你署名的代码凡是你评审通过的方案都要有“我来担保”的底气。这套动作不一定让你成为最顶尖的人但至少能让你在大多数只知道焦虑、不知道调整的同行面前保持足够稳定的职业竞争力。写到这里我又想起那位工程师截图的最后一行字。他没有写“祝好运”也没有写“保持冷静”他只写了一句“问题抛出来了剩下的看你自己怎么回答了。”我这些天反复嚼这句话嚼出来的味道是软件工程这个行业不会消失消失的只是“只要会写代码就能有口饭吃”的舒适区。我们这一代工程师可能真的要习惯在持续的问题中重新定位自己。而我的体会是焦虑没有用把命令改得更准确、把方案审得更严格、把业务问得更清楚这些今天就能做的事才是两年后依然站得住的东西。