对 AI 取代工程师的最终判断——1400 篇写下来我怎么看这件事
对 AI 取代工程师的最终判断——1400 篇写下来我怎么看这件事
适读人群：担心被AI取代的工程师，以及对这个问题有认真思考的所有人 | 阅读时长：约16分钟 | 核心价值：两年多AI应用开发实践后形成的真实判断，不是套话
这个问题我被问过几百次了。
在评论区、在私信里、在饭桌上，有在校学生问，有工作了十年的老工程师问，有刚失业在考虑转型的人问。
我一直没有认真正面回答过，因为我觉得自己还没想清楚，或者说，我觉得还没到做判断的时候。
写完这1400篇，我觉得到了。
不是因为1400是个整数，是因为两年多下来，我见过了足够多的真实案例，做过了足够多的真实项目，形成了一些可以被检验的判断。
先说我不认同的两个极端
极端1："AI会取代大部分工程师，5年内编程工作量减少80%"
这个判断的持有者通常是两类人：AI领域的投资者/布道者（有叙事动机），以及从来没有做过真实工程项目的观察者（没有校正信息）。
我不认同，理由很实际：我天天在做AI应用开发，用着最先进的AI工具，我知道它能做什么，不能做什么。它没有让我的需求变少，它改变的是我的时间分配。
极端2："AI只是工具，工程师的核心工作完全不会改变"
这个判断的持有者通常是在安慰自己。
AI工具已经在改变工程师的工作方式，这是事实。某些工作的需求确实在减少，这也是事实。否认这些，是把头埋在沙子里。
真实的情况在中间，但不是简单的"一半一半"。
AI已经在真实替代的能力
我不用理论分析，就说我亲眼见到的。
1. 重复性代码的生成
初级工程师做的一大块工作：写增删改查，写Controller，写测试用例的骨架，按照已有模式写新的模块。
这些，AI工具现在做得比很多初级工程师更快，质量也不差（错误更少）。
这个替代效应是真实的。不是"可能会"，是"已经在发生"。
表现：很多公司的初级岗位招聘需求在下降，不是因为行业萎缩，而是因为一个高级工程师配合AI工具，能覆盖以前需要三个工程师的产出量。
我不是在说这件事好，我是在说这件事在发生。
2. 规范化的技术文档
按固定格式写API文档、写接口说明、写部署文档——这类工作的边际价值在降低。
不是说文档不重要了，而是写这类文档不再需要高技能的工程师花大量时间。
3. 单纯的bug排查和日志分析
给一段报错日志，找到根本原因——AI工具在处理常见错误类型上已经很好。
有经验的工程师在调试时的价值，更多来自对系统上下文的理解（"这个错误在我们这个特定架构下通常意味着XX"），而不是纯粹的报错解读能力。
4. 技术方案的初稿生成
"给一个技术架构方案"——AI可以给出一个像样的初稿，覆盖主要的考量点。
这个初稿需要有经验的工程师审查和修改，但它确实大幅降低了"从白板到初版方案"的时间。
AI至今无法替代的能力
这才是我真正想说的部分。
1. 对系统长期演化的感知和判断
一个系统在运行了三年之后，为什么某个模块特别脆弱？为什么某个接口的命名这么奇怪？为什么这里有一段看起来多余的逻辑？
这些问题的答案往往不在代码里，在历史里——在历史需求变更里、在某个事故之后的应急修复里、在某个已经离职的工程师的设计决策里。
有经验的工程师能从代码里读出这段历史，能判断什么可以安全地重构，什么必须保留，什么看起来安全但实际上动了会出问题。
AI没有这个能力。它看到的是代码当下的状态，没有时间维度的感知。
2. 在模糊约束下做权衡决策
真实的工程决策通常是这样的：
"我们有两个月，四个工程师，用户在三个月后上线，但需求还不稳定，公司明年可能融资然后扩张，现在应该怎么设计架构？"
这是一个没有标准答案的问题，正确的答案取决于对公司战略、团队能力、风险偏好的综合判断，不是纯技术问题。
AI可以给你列一个"各方案的优缺点"，但它无法做出这个判断，因为它不真正了解你的具体处境。
3. 用户真实使用行为的洞察
工程师和用户打交道的过程里，会形成一种感觉：用户说的和用户想的不总是一样的，用户遇到的问题和他们描述的不总是一样的。
有经验的工程师能从用户行为中发现需求的真正来源，能在需求文档里识别那些"技术上可行但用户根本不需要"的内容。
这是一种来自真实交互经验的判断力，AI不具备。
4. 在不完整信息下快速定位问题
生产环境的故障通常发生在信息最不完整的时候：日志有缺失，监控告警不准确，复现路径不明确，同时还有人在催。
有经验的工程师在这种情况下的表现，依赖的是对系统行为的直觉——在脑子里有系统各个部分的运作模型，在信息有限的情况下能快速缩小范围、提出高质量的假设。
AI处理这类场景的效果，我亲身测试过，在"常见问题模式"上还行，但一旦是系统特有的行为或者不常见的交叉影响，AI给的假设往往帮助有限，方向性正确但不够准确。
5. 建立和维护技术信任
一个能让业务方、产品方、管理层信任的技术判断——"老张说没问题，那就没问题"，或者"老张说这样做有风险，那我们认真对待"——这种信任是长期积累的，来自你对这个团队、这个产品、这个公司的理解。
AI工具没有这个维度。它可以辅助你做出判断，但"信任"这件事是人和人之间的，不能被AI替代。
我真正担心的是什么
我担心的不是"AI会取代工程师"这件事，我担心的是另一件事：
一部分工程师会因为AI工具的存在，降低了对真实能力的积累。
我说的很具体：如果一个工程师在职业早期把大量时间花在"让AI写代码然后微调"，而不是"自己写、然后遇到问题、然后深入理解"，他可能在表面指标上（代码产出量）很好看，但在上面那5个AI无法替代的能力上，积累速度会慢很多。
这不是AI的问题，是使用者的问题。工具用得好，能加速成长；用得不好，会成为一个精致的外包经理——用AI做，但自己不真的懂。
当AI工具处理不了复杂情况时，这个缺口会暴露出来。而那时候，别人也在用AI工具，凭什么雇你？
最后的判断
写了1400篇，做了两年多AI应用开发，我的判断是：
AI不会取代工程师，但会重新定义"工程师的价值在哪里"。
以前，工程师的价值有很大一部分来自"能把东西写出来"——写代码、写脚本、写配置、写文档。这部分价值在降低，因为AI工具让这件事变容易了。
未来，工程师的价值会越来越集中在AI无法替代的那5个能力上：系统感知、模糊约束下的判断、用户洞察、快速定位问题、建立技术信任。
这个变化意味着：工程师之间的能力差距会变大，不是变小。AI工具会让中等水平的工程师产出增加，但它同样会让优秀工程师的价值更加凸显，因为AI工具放大了能力，而不是平均化了能力。
对我这种从失业转型的人来说，这其实是个好消息。我没有职场资历，没有大厂背景，但我在这两年里真实积累了上面那5个能力，而不是躺在AI工具上。
会被取代的，是停止积累这5个能力的工程师，不是所有工程师。
这是我两年多以后能给出的最诚实的判断。