这两年，AI 编程工具的发展速度快得有些超出我的预期。
最开始，它们更多只是用来补全几行代码、解释报错，或者帮忙生成一些简单函数。到了现在，AI 已经可以根据一段自然语言描述，直接生成相对完整的类、接口、页面、数据库操作，甚至还能主动补充异常处理、日志记录和代码注释。
就连这篇文章本身，都使用了AI进行扩展和润色。
很多以前需要花半天甚至一天完成的工作，现在可能只需要十几分钟。
面对这种变化，程序员很难不产生焦虑。
如果 AI 以后真的什么代码都会写，那么程序员还会存在吗？我们现在积累的编程经验，会不会突然变得没有价值？未来的公司是不是只需要少数几个人，带着 AI 就能完成过去一个团队的工作？
我无法确定几年以后会发生什么，但从目前的体验来看，我认为有一点已经越来越明确：
AI 确实会减少一部分程序员岗位，但它首先替代的，并不是“软件工程师”这个职业，而是软件开发中那些标准化、重复化、容易描述的编码工作。
或者说，AI 正在让“写出代码”这件事变得越来越便宜。
但一个完整的软件项目，从来不只是把代码写出来。
AI 写代码，确实已经很强了
首先必须承认，AI 在编程方面已经非常强。
如果只是一些相对明确的任务，例如：
编写普通的增删改查代码
生成一个配置文件
封装数据库访问方法
编写简单的 WinForms 事件
生成 Excel 导出功能
修改重复代码
解释异常信息
将一种语言的代码改写成另一种语言
根据现有网页结构生成 HTML、CSS 或 JavaScript
AI 通常都可以很快给出一个看起来不错的结果。
过去，程序员遇到问题时，往往要先搜索报错信息，再翻阅文档、论坛和 Stack Overflow，然后从多个答案中拼凑出一个能够使用的解决方案。
现在，这个过程被大幅缩短了。
你可以直接把报错、代码和项目背景交给 AI，让它帮你分析问题、修改实现，甚至直接给出一份完整代码。
从这个角度来说，AI 的确正在提高程序员的生产效率。
但与此同时，它也会让一部分原本依靠信息差和重复劳动存在的工作失去价值。
如果一个人的主要能力只是搜索代码、复制示例、修改变量名，然后把程序调到勉强能运行，那么 AI 对他的冲击一定会非常大。
因为这些事情，AI 不仅可以做，而且往往做得更快。
AI 降低的，不只是编程成本，也是技术领域之间的门槛
我自己的博客就是一个很直观的例子。
我平时主要做的是 C#、工业视觉、运动控制和设备通信，并不擅长前后端开发，对 HTML、JavaScript 和 CSS 也只能算是会看一点。
博客使用的是别人开发的主题。
当我想修改页面内容时，例如：
在已有页脚中插入新的备案信息
调整某些文字或链接
增加版权协议区块
修改留言板页面
根据主题现有结构增加新的显示内容
如果放在以前，我可能需要先学习主题的页面结构，再通过浏览器开发者工具分析 DOM，查找合适的选择器，最后一点点尝试 JavaScript 和 CSS。
而现在，我只需要告诉 AI：
当前主题支持在哪些位置进行代码注入
页面现有结构是什么样的
我希望修改哪一部分
最终需要达到什么效果
AI 就可以直接给出一段能够使用的 HTML、JavaScript 或 CSS 注入代码。
我不需要先系统学习完整的前端技术栈，也可以完成这些小范围的定制。
这并不意味着我突然变成了一名前端工程师。
因为如果主题结构发生巨大变化、代码之间产生复杂冲突，或者需要从头设计一个完整的 Web 应用，我依然缺少足够的专业经验。
但 AI 确实帮助我跨过了原本较高的实现门槛。
这件事说明，未来很多简单开发任务，未必还需要一个完全掌握对应技术栈的人亲自完成。
懂需求的人，只要能够清楚描述现状、约束和目标，就可能借助 AI 完成过去必须交给专业开发者的工作。
这对程序员来说既是机会，也是压力。
机会在于，我们可以更轻松地跨越不同技术领域。
压力在于，一些过去依赖技术门槛存在的简单工作，正在失去稀缺性。
最先被压缩的，可能是“只负责写代码”的岗位
以前，一个需求从提出到完成，往往需要经过很多人工步骤。
例如，产品提出一个明确需求：
增加一个页面，用来查询、编辑和导出数据库中的记录。
如果需求足够明确，这类工作在过去可能需要程序员完成页面布局、数据库查询、数据绑定、校验和导出逻辑。
但现在，AI 完全可以快速生成一个基础版本。
程序员需要做的，可能只剩下调整字段、修改样式、接入现有项目和测试结果。
这意味着，未来一部分需求明确、实现方式标准化的工作，确实不再需要那么多人。
过去需要五个人完成的项目，未来也许只需要两三个人。
一个熟练使用 AI，同时具有代码审查和系统设计能力的工程师，可能会完成过去数名普通开发者的工作量。
所以我并不认同“AI 完全不会导致程序员失业”这种过于乐观的说法。
岗位数量减少、团队规模缩小、初级岗位变少，都很可能真实发生。
但这里还需要区分两个经常被混为一谈的概念：
程序员和软件工程师，并不完全是一回事。
程序员和软件工程师的区别
在日常交流中，“程序员”和“软件工程师”经常被当成同一个职业。
但如果放到 AI 时代，我觉得有必要重新区分它们。
这里的“程序员”并不是某个正式岗位名称，而是指一种更偏向执行层面的工作角色：
根据已经明确的需求，把逻辑转换成可以运行的代码。
例如：
根据接口文档补充接口
根据数据库结构编写查询
根据页面原型实现表单
根据已有模式增加相似功能
根据错误信息修改代码
这类工作当然也需要技术能力。
但它的输入和输出通常比较明确，过程也相对容易验证。
这正是 AI 最擅长的部分。
而“软件工程师”关注的不只是代码本身。
软件工程师需要处理的是一个更完整的问题：
需求是否合理
系统应该如何拆分
模块之间如何协同
性能瓶颈可能在哪里
异常发生后如何恢复
数据是否允许丢失
系统是否可以长期维护
不同方案之间应该如何取舍
最终风险由谁承担
程序员更关注：
这段代码应该怎么写？
软件工程师更关注：
这个问题到底应该怎么解决？
程序员完成的是实现。
软件工程师完成的是从问题到结果的整个过程。
当然，现实中大多数开发者同时承担这两种角色，并不存在绝对边界。
但 AI 的出现，会让这种区别越来越明显。
以后，单纯把明确需求转化为代码的价值会不断降低。
而能够理解模糊需求、设计系统、判断风险并对最终结果负责的人，价值反而可能更高。
能生成代码，不代表能解决工程问题
我之前中途接手过一个 VR 显示模组 AA 项目。
因为是双目显示模组，设备上存在左右两套运动轴，两套轴需要按照相同的步骤一起运动。
之前的程序在轴运动部分使用了 Task.Run。
从代码表面来看，这种写法非常自然：
Task.Run(() => LeftAxis.Move());
Task.Run(() => RightAxis.Move());
两个任务被同时提交，左右两边似乎就应该同时运动。
而且这段代码非常简洁，看起来也没有明显错误。
但实际运行时，两套轴经常出现明显不同步。有时一边先动，另一边过一段时间才开始；严重时甚至会出现步骤跳过，例如原本应该按照 A、B、C 执行，却直接从 A 跳到了 C。
最终的结果可能不是简单的程序报错，而是机械机构发生撞击。
后来，我把运动逻辑从线程池任务改成了独立线程执行，问题才没有再次发生。
这个案例让我意识到，代码“能运行”和系统“能稳定工作”完全是两回事。
如果把需求描述给 AI：
请同时控制左右两套轴运动，并且不要阻塞 UI。
它很可能也会生成基于 Task.Run 的代码。
从语法上说，这段代码没有问题；从普通应用程序的角度看，它甚至是常见写法。
但在运动控制场景中，真正重要的问题并不是“怎么异步执行”，而是：
两套轴是否真的需要软件层面同步
是否应该使用控制器提供的多轴联动功能
指令是否保证顺序执行
线程调度延迟是否可以接受
运动完成信号是否可靠
某一步失败后是否允许继续
如何避免撞击
是否存在机械限位和软件互锁
这些问题并不会自动出现在代码需求里。
它们来自项目经验、设备理解和对风险的判断。
AI 可以帮忙生成实现，但它并不知道现场哪一个错误会导致产品报废，哪一个异常会让设备撞机，也不会为最终结果承担责任。
这里真正需要的，不只是一个能写出运动控制代码的程序员。
而是一个理解整套设备、能够判断风险的软件工程师。
AI 可以回答问题，但它未必知道真正的问题是什么
现实中的项目，很少像考试题一样，把条件和目标完整地摆在程序员面前。
更多时候，我们看到的只是一些表面现象。
比如：
软件偶尔卡住几十秒
UI 看起来还能操作
相机似乎没有断线
PLC 还在继续运行
日志里没有明显异常
看门狗却判断程序失去响应并强制退出
这种情况下，真正困难的并不是写一段代码，而是判断问题可能发生在哪里。
是 UI 线程被阻塞了吗？
是某个第三方 DLL 卡住了吗？
是锁竞争导致线程无法继续吗？
是设备通信超时吗？
是 GDI+ 在跨线程访问图像时出现了问题吗？
还是硬件和驱动本身发生了异常？
如果没有正确的问题描述，AI 也只能根据有限信息给出各种可能性。
真正有价值的工作，是知道接下来应该做什么：
需要增加哪些日志
是否应该生成完整 Dump
哪些线程需要重点检查
如何复现问题
哪些现象只是巧合
哪些线索最值得继续追踪
未来，程序员可能不再需要记住所有 API，也不需要亲手写出每一段模板代码。
但仍然需要有人能够从混乱现象中找到关键问题。
这正是软件工程师与单纯代码编写者之间的重要区别。
程序员在等待一个明确的问题。
软件工程师需要先从现场中找出真正的问题。
写代码只是软件开发的一部分
过去，我们常常用编程语言来定义一个程序员。
会 Java、C#、C++、Python，就可以被称为某种开发工程师。
但随着 AI 越来越擅长生成代码，单纯掌握一门语言的价值可能会逐渐下降。
因为语言本身只是表达工具。
真正困难的是知道要表达什么。
例如在一个工业视觉项目中，开发者面对的并不只是图像处理算法。
还要考虑：
相机的采集速度
图像数据如何传输
内存是否会持续增长
队列堆积后应该丢弃还是等待
UI 应该以什么频率刷新
设备断线后如何恢复
算法异常后是否允许继续生产
数据库写入失败时如何处理
PLC、相机、运动轴之间如何保持状态一致
其中很多问题没有唯一答案。
需要根据生产节拍、硬件能力、项目预算和故障风险进行取舍。
AI 可以分别告诉你队列、线程、数据库和相机 SDK 怎么使用。
但如何把这些东西组合成一个能够连续运行几个月的系统，仍然需要工程判断。
AI 擅长给出局部答案。
软件工程师需要保证这些局部答案组合起来之后，仍然是一个正确的整体。
未来更重要的，不是写得快，而是判断得对
以前评价一个程序员，经常会关注：
写代码速度快不快
熟悉多少框架
能记住多少 API
能不能独立完成一个功能
以后这些能力仍然有用，但可能不再是最关键的部分。
因为有了 AI，很多人都可以快速生成大量代码。
真正拉开差距的，可能变成以下几件事。
理解业务和现场
AI 可以生成运动控制代码，但它不一定理解机械结构。
它可以生成图像采集程序，但它不一定知道某种相机在高帧率下会遇到什么问题。
它可以写数据库代码，但它不一定知道哪些数据绝对不能丢失。
未来，只懂编程语言可能不够。
更有价值的组合可能是：
会 C#，同时懂工业视觉
会 C++，同时懂运动控制
会 Python，同时懂数据分析
会嵌入式，同时懂电路和通信
会后端开发，同时理解具体业务
行业经验和现场知识，比单纯的代码语法更难快速复制。
系统设计能力
AI 很擅长生成一个方法或者一个类。
但项目应该如何拆分，模块之间如何通信，异常应该在哪里处理，系统在局部失败后是否还能继续运行，这些仍然需要人来设计。
一个系统真正的质量，往往不取决于某一段代码写得多么漂亮，而取决于整体结构是否合理。
验证和审查能力
AI 生成代码最危险的地方，并不是完全不能运行。
相反，很多代码看起来非常合理，也能够通过编译，甚至可以在简单测试中正常执行。
但它可能在某个边界条件下出现问题。
例如：
多线程下存在竞态
资源没有正确释放
SDK 生命周期使用错误
忽略了异常返回值
在高负载下产生队列堆积
在设备断线后无法恢复
执行顺序和预期不一致
未来，开发者必须具备判断 AI 输出是否可靠的能力。
一个不会审查代码的人，即使使用 AI 提高了开发速度，也可能只是更快地制造问题。
调试能力
写代码的成本可能越来越低，但定位问题的成本仍然很高。
特别是多线程、性能、硬件联动和偶发异常。
这些问题通常不会因为 AI 会写代码就自动消失。
相反，当项目中出现大量由 AI 生成的代码后，调试和理解系统可能会变得更加重要。
对结果负责
AI 不会承担责任。
当设备撞击、产线停机、数据丢失或者产品出现质量问题时，最终仍然需要人来判断、处理和解释。
软件工程师的价值不只是输出代码。
还包括对需求、设计方案、风险和最终结果负责。
程序员以后应该怎么办
既然变化已经发生，单纯焦虑并没有意义。
比起反复讨论 AI 会不会取代程序员，更重要的是调整自己的能力结构。
不要继续和 AI 比拼模板代码
CRUD、工具类、配置文件、格式转换，这些工作未来只会越来越容易自动生成。
开发者应该把更多精力放在：
需求理解
系统设计
问题定位
代码审查
结果验证
风险控制
行业知识
让 AI 去完成重复工作，人负责关键判断。
尽早把 AI 当成工具
不会使用 AI 的程序员，未来很可能不是被 AI 本身淘汰，而是被更会使用 AI 的程序员淘汰。
AI 很适合用来：
快速理解陌生代码
生成初始实现
阅读 SDK 文档
整理日志
编写测试
对比多种方案
检查潜在问题
补充异常处理
跨越自己不熟悉的技术领域
我修改博客主题的经历就是如此。
我并没有因为 AI 就掌握完整的前端开发能力，但它让我能够完成原本超出自己熟悉范围的小型需求。
这意味着未来的工程师，不一定需要亲自精通所有技术栈，但必须具备快速理解问题、描述约束和验证结果的能力。
更合理的协作方式是：
AI 负责扩大个人能力边界，人负责判断生成结果是否真正可用。
建立自己的专业壁垒
以后，“会某种语言”本身可能越来越难成为竞争力。
真正难以替代的是长期积累出来的行业理解。
例如，我在工业软件项目中逐渐认识到，很多问题不是单靠代码知识能够解决的。
相机、传感器、PLC、运动控制器、机械结构和算法之间，往往互相影响。
只有真正接触过现场，才会知道哪些问题最容易发生，哪些地方必须预留保护，哪些看起来偶发的小问题可能最终演变成严重故障。
这些经验不会因为 AI 能生成代码就立刻失效。
相反，它们会让人更清楚应该如何使用 AI。
从程序员转向软件工程师
这可能是未来最重要的变化。
不要只满足于：
需求给我，我把代码写出来。
而应该逐渐学会：
判断需求是否合理
识别隐藏风险
设计完整流程
选择合适技术
验证最终效果
为系统长期运行负责
当写代码的成本不断下降后，真正有价值的就不再是代码数量，而是工程判断。
保留对底层原理的理解
AI 会让学习过程变得更轻松，但也容易让人跳过基础。
如果完全不了解线程、内存、网络、数据库和操作系统，那么当 AI 输出错误答案时，就很难发现问题。
未来也许不再需要手写每一行代码，但仍然需要理解：
为什么它能够运行
它依赖什么条件
在什么情况下会失败
是否还有更合适的实现方式
工具越强，判断能力反而越重要。
程序员真的会失业吗
我认为，一部分程序员会失业。
一部分岗位会消失，一部分团队会缩小，初级开发岗位也可能变得更少。
这并不是什么值得回避的结论。
当一个工程师借助 AI 能够完成过去数个人的工作时，公司自然不会继续维持原来的人员规模。
尤其是那些主要承担标准化编码、简单页面修改、接口拼接和重复业务实现的岗位，受到的影响可能会更早、更明显。
但是，这并不代表软件工程师会作为一个职业彻底消失。
更可能发生的是，程序员的角色会逐渐改变。
过去，程序员可能更像代码生产者。
未来，软件工程师可能更接近：
问题分析者
系统设计者
技术决策者
AI 输出审查者
跨领域协调者
项目结果负责人
以后可能不再需要那么多只负责敲代码的人。
但仍然需要能够理解需求、发现问题、判断风险、设计系统、验证结果并处理异常的人。
从这个角度来说，AI 淘汰的未必是程序员这个职业。
它更可能迫使很多程序员完成一次身份转变：
从按照要求生产代码的人，转变为使用代码和 AI 解决真实问题的软件工程师。
写在最后
AI 的出现，确实让写代码这件事变得越来越便宜。
很多曾经需要反复搜索、阅读文档和手动实现的工作，现在几分钟就能得到一个不错的结果。
甚至像我这样并不擅长前端开发的人，也可以借助 AI，根据博客主题提供的代码注入能力，完成页面和功能上的一些定制。
这种变化不会停止。
未来的 AI 也一定会比现在更强。
但软件开发从来不只是写代码。
真实项目中，最困难的往往不是如何实现一个功能，而是判断应该实现什么，选择什么方案，怎样保证系统长期稳定，以及出问题时如何找到真正的原因。
AI 可以成为非常强大的助手。
它可以提高效率，减少重复劳动，帮助开发者快速进入陌生领域，也可以把一个人的能力范围扩展到过去很难触及的地方。
但至少目前，它仍然需要一个能够理解问题、判断方向、验证结果并承担责任的人。
所以，与其反复担心 AI 会不会取代程序员，不如先问自己一个问题：
如果未来不再需要我亲手写下每一行代码，我还能为一个项目提供什么价值？
如果答案只是“我会写代码”，那么焦虑或许确实有理由。
但如果答案是：
我能够理解问题、设计方案、识别风险、使用 AI，并最终把事情做好。
那么未来需要担心的，可能就不再是 AI 会不会取代自己，而是如何借助 AI，成为一名更好的软件工程师。
评论