前阵子一位在某海外大厂做了多年后端的朋友，转了一段内部分享的截图给我。标题就一句话——《未来两年，软件工程还剩下什么》。分享的工程师没有给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能有高质量输入的前提。第四，给自己建立一套“责任出镜”意识：凡是你署名的代码，凡是你评审通过的方案，都要有“我来担保”的底气。
这套动作不一定让你成为最顶尖的人，但至少能让你在大多数只知道焦虑、不知道调整的同行面前，保持足够稳定的职业竞争力。
写到这里，我又想起那位工程师截图的最后一行字。他没有写“祝好运”，也没有写“保持冷静”，他只写了一句：“问题抛出来了，剩下的看你自己怎么回答了。”我这些天反复嚼这句话，嚼出来的味道是：软件工程这个行业不会消失，消失的只是“只要会写代码就能有口饭吃”的舒适区。我们这一代工程师，可能真的要习惯在持续的问题中重新定位自己。而我的体会是，焦虑没有用，把命令改得更准确、把方案审得更严格、把业务问得更清楚，这些今天就能做的事，才是两年后依然站得住的东西。
