夜雨聆风当代码的生产成本快速下降，工程师真正稀缺的能力，反而会变得更清晰。
“AI 会不会取代软件工程师？”
这个问题之所以总也讨论不清，往往是因为我们默认了一个并不准确的前提：软件工程师的工作就是写代码。
如果把工程师等同于“把需求翻译成代码的人”，那么答案似乎很悲观。代码生成、重构、补测试、查文档、解释报错，这些过去需要工程师逐行完成的任务，如今已经可以被 AI 大幅加速。随着模型能力继续提升，其中相当一部分甚至会走向自动化。
但在真实的软件组织中，代码只是交付链条的一环。一个成熟工程师创造价值的过程，通常包含发现问题、争取资源、设计方案、推动落地、处理事故以及建设团队。AI 对这些环节的影响并不相同。
因此，比“这个职业会不会消失”更有意义的问题是：软件工程中的哪些任务正在商品化，哪些能力仍然稀缺？
一个判断任务可替代性的简单模型
可以用三个维度判断一项工作是否容易被 AI 接管：
标准化程度决定任务能否被清楚描述。输入、输出和操作步骤越固定，越适合自动化。
结果可验证性决定错误能否被低成本发现。编译是否通过、单元测试是否成功都很容易检查；但“这个项目是否值得做”很难用一个测试用例证明。
责任可转移性决定组织是否愿意把最终决定交给机器。AI 可以给出建议，却无法真正承担线上事故、预算损失或战略误判的责任。
当一项任务同时具备“高度标准化、容易验证、无需承担最终责任”这三个特征时，它最容易被 AI 替代。反过来，只要任务涉及模糊信息、多方博弈或结果责任，人就仍然处在决策闭环的中心。
沿着这个模型，我们可以重新拆解软件工程师的工作。
一、发现值得解决的问题：AI 能找线索，但不能替你下注
很多有价值的项目并不是从一张写好的需求单开始，而是从一个不够明确的异常开始：某类用户的留存突然下降，某个链路的转化长期低于预期，某项基础设施成本持续增加，或者一个被大家习以为常的人工流程其实极其低效。
AI 很适合参与前期研究。它可以生成查询语句、汇总数据、归纳用户反馈，也可以帮助工程师快速建立多个假设。但从“发现相关性”到“确认问题”，中间仍有很长的距离。
数据表是否选对了？指标口径是否一致？样本是否存在偏差？异常究竟来自产品变化、流量结构，还是埋点故障？即使问题存在，它是否大到值得投入一个团队数月时间？这些判断依赖业务背景、组织优先级和对机会成本的理解。
AI 可以把搜索空间压缩，却无法替团队承担资源配置的后果。真正稀缺的能力，是从噪声中识别信号，并愿意为判断下注。
替代判断：低。 AI 会成为强大的研究助手，但问题定义权仍掌握在人手中。
二、让一个想法获得支持：工程师也在“销售”
技术方案不会因为逻辑正确就自动获得资源。尤其是跨团队项目，工程师还需要回答一组代码之外的问题：为什么现在做？预期收益是什么？不做的代价是什么？需要哪些团队配合？上线风险如何控制？投入是否与收益匹配？
这本质上是一场内部销售。
AI 可以帮忙整理材料、润色文档、模拟反对意见，甚至生成几版汇报结构。但真正困难的部分发生在动态互动中。不同角色关注的目标并不一致：产品关心用户价值，业务关心增长，研发关心复杂度，管理者关心资源与风险。一个方案能否推进，取决于提案者能否理解这些立场，并在质疑、冲突和妥协中形成共识。
会议现场也不会暂停五分钟，让你把对方的问题完整复制给 AI。说服力来自长期积累的可信度、对上下文的掌握，以及在不确定局面中的即时判断。
替代判断：很低。 AI 能优化表达，却很难替代人与人之间的信任和影响力。
三、实现与交付：代码生产会自动化，工程责任不会
在所有环节中，编码无疑是受 AI 冲击最明显的部分。只要上下文充分、边界清楚，AI 已经能够完成大量样板代码、接口适配、测试补充、局部重构和缺陷修复。
但“生成代码”和“交付可靠的软件”不是同一件事。
一段代码是否可用，不能只看它能否编译。工程师还要确认它是否满足真实需求，能否处理异常输入，是否引入安全问题，是否符合系统架构，是否具备可观测性，以及上线后能否安全回滚。更重要的是，代码最终会以某个工程师或团队的名义进入生产环境。
当 AI 生成的修改导致数据损坏或服务中断时，组织不会让模型参加事故复盘。最终责任仍然属于批准、提交和发布这段代码的人。
这意味着工程师的工作重心会从“亲手生产每一行代码”，转向“设计约束、提供上下文、验证产出并对结果负责”。未来优秀工程师的核心竞争力，不一定是输入速度最快，而是能建立最可靠的 AI 协作闭环：
明确目标 → 提供上下文 → 生成方案 → 自动化验证 → 人工审查 → 灰度发布 → 观测反馈替代判断：中等。 大量编码任务会被自动化，但端到端交付责任仍需要人承担。
四、线上事故处理：AI 缩短排查时间，人负责混乱现场
事故响应看似非常适合 AI：日志、指标、调用链和历史案例都是机器擅长处理的信息。AI 可以快速总结异常、关联变更、提出根因假设，甚至生成修复补丁。这些能力会显著降低平均发现时间和平均恢复时间。
然而，真实事故往往不是一道信息完整的技术题。
报警可能相互矛盾，监控本身可能失真，故障可能横跨多个系统，恢复动作也可能带来新的风险。与此同时，团队还需要同步影响范围、协调上下游、决定是否回滚、安排流量切换，并持续向相关方更新进展。
事故现场最缺的通常不是“更多可能性”，而是有人根据不完整信息做出及时决策，并为这个决策负责。AI 可以成为副驾驶，但很难担任事故总指挥。
替代判断：中低。 诊断和修复速度会提升，协调、取舍与责任仍属于值班工程师。
五、招聘与团队建设：这是关于人的长期决策
资深工程师的另一项重要工作，是帮助团队选择合适的人，并让合适的人愿意加入。
AI 可以筛选信息、生成面试题、记录面试内容，也可以辅助识别评价中的不一致。但面试真正要回答的是：候选人如何处理陌生问题？遇到分歧时如何沟通？他能否在当前团队环境中持续成长？我们是否愿意在未来几年与他一起解决困难问题？
这些都不是一次静态打分能够完全回答的。招聘同时也是双向选择。工程师需要向候选人解释团队正在解决什么问题、为什么值得加入，并诚实说明挑战和约束。这个过程依赖真实的人际互动，也会直接塑造团队未来的能力上限。
替代判断：低。 AI 会改变招聘流程，却难以替代最终的人才判断和关系建立。
真正被重构的，是工程师的价值分布
把以上环节放在一起，可以看到一个明显趋势：
AI 不会平均地影响整个职业。它会先压缩标准化任务的价值，再放大判断力、影响力和责任感的价值。
因此，初级工程师面临的挑战可能更直接。过去，很多人通过编写样板代码、修复简单缺陷和完成边界明确的小需求来积累经验；当这些任务大量自动化后，传统的成长阶梯会变窄。团队需要重新设计培养机制，而个人也要更主动地理解系统、业务和决策过程，不能只停留在执行层。
AI 时代，工程师该如何升级自己的能力栈
第一，从接受需求转向定义问题。不要只问“这个功能怎么实现”，还要问“为什么要做”“成功如何衡量”“是否存在更便宜的解法”。能够定义正确的问题，往往比快速回答错误的问题更有价值。
第二，建立验证 AI 的能力。把测试、静态检查、安全扫描、性能基准、灰度发布和可观测性接入工作流。使用 AI 的上限，不取决于它一次生成了多少代码，而取决于你能多快发现它错在哪里。
第三，扩大端到端责任范围。主动理解需求、设计、发布、运营和复盘，而不是把自己限制在某个代码模块中。越接近业务结果，越不容易被单点自动化能力替代。
第四，训练书面表达和现场沟通。能否把复杂技术问题讲清楚，能否处理反对意见，能否推动跨团队合作，会越来越直接地决定工程师可以负责多大范围的问题。
第五，积累真实世界的判断样本。架构取舍、事故处置、项目失败和团队协作中的经验，很难只靠阅读获得。每次做完决策，都应该回看当时掌握了什么信息、忽略了什么信号，以及结果为什么偏离预期。
结语：不要和 AI 比谁更像代码生成器
AI 会替代一部分编码任务，也会改变软件工程师的数量、分工和成长方式。但它是否会取代“软件工程师”这个角色，取决于我们如何定义这个角色。
如果工程师只负责把明确指令转换成代码，那么可替代性确实会越来越高。如果工程师能够发现问题、设计系统、推动协作、验证结果并承担责任，那么 AI 更像是一种能力放大器。
未来最危险的位置，不是“不会手写所有代码”，而是只会等待别人给出边界清晰的任务。未来最有价值的工程师，也未必是代码写得最多的人，而是能借助 AI，用更低成本把模糊问题变成可靠结果的人。
代码正在变得便宜，判断、影响与责任正在变得更贵。
-- END --
推荐阅读