乐于分享
好东西不私藏
当前位置：夜雨聆风 > 技术教程 > 软件教程 > AI编程Agent第五篇:AI Coding Agent 会取代程序员吗?先别急着焦虑

AI编程Agent第五篇:AI Coding Agent 会取代程序员吗?先别急着焦虑

当前时间： 2026-05-01 15:34:38 更新时间： 2026-05-01 分类：软件教程 评论(0)

AI编程Agent第五篇:AI Coding Agent 会取代程序员吗?先别急着焦虑

最近，我在杭州电子科技大学、东南大学、浙江大学等高校，与老师、研究生和本科生交流 AI-Assisted Engineering 和 Project Velocity 时，经常被问到一个问题。与此同时，也有不少读者通过微信公众号私信我，提出类似的疑问：

OpenAI Codex、Claude Code、Google Antigravity、OpenCode 这些 AI 编程 Agent 越来越强，程序员是不是快要被取代了？

这确实是一个很现实的问题。

因为今天的 AI编程Agent，已经不只是帮我们补全几行代码。它可以读代码、改代码、跑命令、生成测试，甚至在一个项目目录里连续完成一组开发任务。

所以，很多人的顾虑并不是没有道理。

这个问题很现实，也很容易让人焦虑。

于是很多人开始担心：

如果 AI 已经能写代码，那程序员还剩下什么价值？

我的看法是：

AI编程Agent 不会简单取代程序员，但会快速取代只会“等需求、写代码、不验证、不理解系统边界”的程序员。

真正被改变的，不是“程序员这个职业”，而是“程序员工作的方式”。

一、这次变化，和过去的代码补全不一样

过去我们用 IDE、代码模板、栈溢出、搜索引擎，主要是在“找答案”。

后来有了 Copilot、ChatGPT，我们开始让 AI 帮我们“写片段”。

但今天的AI编程Agent 不一样。

它不只是回答问题，而是可以进入工程目录，理解上下文，然后执行一系列动作：

  • 阅读已有代码

  • 修改多个文件

  • 运行测试

  • 根据报错继续调整

  • 生成提交说明

  • 解释设计思路

  • 帮助重构项目结构

这意味着，AI 正在从“代码助手”变成“工程执行单元”。

但注意，是执行单元，不是工程负责人。

这两者的区别，非常重要。

二、为什么很多人一用 Agent 就翻车？

很多人第一次使用 AI Coding Agent，会非常兴奋。

输入一句：

帮我实现这个功能。

然后 Agent 开始飞快改文件、生成代码、运行命令。

看起来非常智能。

但过一会儿，问题就来了：

  • 代码能跑，但不一定符合真实硬件约束

  • 功能看起来完成了，但边界条件没有处理

  • 测试通过了，但测试本身太弱

  • 文件改了很多，但没有清楚说明为什么这么改

  • 出了问题，很难回滚

  • 系统越改越复杂，最后没人敢继续维护

这就是所谓的“Agent 翻车”。

不是因为 AI 不够强，而是因为使用者没有给它清晰的工程边界。

AI Agent 很擅长执行，但它并不知道你的产品目标、硬件限制、安全要求、交付节奏和客户场景。

这些东西，仍然需要工程师来定义。

三、程序员不会消失，但角色会变化

在传统开发模式中，程序员的主要工作是：

理解需求 → 写代码 → 调试 → 修 bug → 交付。

在 AI-Assisted Engineering 模式下，工程师的角色会变成：

定义目标 → 设计架构 → 约束 Agent → 审查结果 → 建立测试 → 控制风险 → 持续迭代。

也就是说，程序员不再只是“代码生产者”，而是逐渐变成：

系统设计者、验证负责人、工程流程控制者。

未来真正重要的能力，不是你每分钟能敲多少行代码，而是你能不能回答这些问题：

  • 这个功能为什么要做？

  • 它运行在什么硬件和系统环境上？

  • 它和哪些模块通信？

  • 失败时应该如何处理？

  • 如何测试它真的可靠？

  • 如何回滚？

  • 如何让下一个工程师看得懂？

这些问题，AI 可以辅助，但不能替你承担最终责任。

四、用 Project Velocity 看得更清楚

以我一直在做的 Project Velocity 为例。

这是一个端到端 AIoT 工程系统，不是一个简单 demo。

它包括三个层次：

  1. Node 层：STM32F103 + Zephyr RTOS，连接传感器、按键、LCD、IR、DC Motor 等外设。

  2. Edge 层：RK3588 作为边缘网关，运行 Ubuntu，负责协议转换、数据处理和边缘控制。

  3. Cloud 层：ThingsBoard 负责遥测数据展示、RPC 控制和设备管理。

系统里还有 MQTT、CANopen、OPC UA、UART、Device Tree、Kconfig、main.c、Python Gateway、Dashboard、Telemetry、RPC 等一整条链路。

如果只是让 AI Coding Agent 写代码，它确实可以帮你生成很多文件。

比如：

  • Zephyr 的 main.c

  • CANopen 通信代码

  • MQTT 客户端代码

  • ThingsBoard RPC 处理逻辑

  • Python 网关脚本

  • 数据格式转换函数

  • README 文档

  • 测试脚本

这些它都可以做，而且速度很快。

但真正的问题是：

这些代码能不能组成一个可靠的端到端系统？

这就不是单纯“会写代码”能解决的问题。

五、在嵌入式和 AIoT 里，Agent 更不能乱用

在 Web 应用里，Agent 写错了，最多页面报错、接口失败、服务重启。

但在嵌入式和 AIoT 系统里，错误可能直接影响真实设备。

比如 Project Velocity 里，如果 Agent 没有理解硬件边界，可能会出现这些问题：

  • STM32 的 GPIO 引脚定义错误

  • Zephyr overlay 文件和实际硬件不一致

  • CANopen Node ID 冲突

  • MQTT Topic 设计混乱

  • ThingsBoard RPC 下发后，边缘网关解析错误

  • 电机控制逻辑没有保护条件

  • IR 控制没有状态确认

  • 传感器数据上传正常，但控制链路没有验证

这些问题，AI编程Agent 不一定会主动发现。

因为它看到的是代码，而不是完整的硬件系统。

所以在 Project Velocity 里，我一直强调一个观点：

AI-Assisted Engineering 不是让 AI 自由发挥，而是让 AI 在工程约束下工作。

六、从 Vibe Coding 到 AI-Assisted Engineering

很多人说自己在做 AI 编程，其实只是 Vibe Coding。

所谓 Vibe Coding，就是：

给 AI 一个大概想法，让它凭感觉生成代码。

这种方式适合快速探索、做原型、写小工具。

但如果你要做的是 Project Velocity 这样的 MCU–Edge–Cloud 系统，仅靠 Vibe Coding 就很危险。

因为真实工程需要的不只是“代码能生成”，而是：

  • 架构清楚

  • 硬件映射正确

  • 协议链路一致

  • 数据模型统一

  • 控制路径可追踪

  • 测试可以复现

  • 版本可以回滚

  • 出错可以定位

这就是 AI-Assisted Engineering 和 Vibe Coding 的区别。

Vibe Coding 关注生成。AI-Assisted Engineering 关注交付。

七、工程师的新价值：会给 Agent 设边界

未来的工程师，不一定要比 AI 更快写代码。

但一定要比 AI 更清楚：

什么代码不该写，什么方案不能用，什么风险必须提前处理。

使用 Coding Agent 时，真正重要的不是一句“帮我写代码”，而是给出工程化约束。

比如在 Project Velocity 中，我不会简单说：

帮我写一个 STM32 程序。

我会要求 AI 同时考虑：

  • 使用 Zephyr RTOS

  • 基于 STM32F103

  • 外设必须在 Device Tree overlay 中定义

  • Kconfig 必须在 prj.conf 中打开

  • 应用逻辑写在 main.c

  • CANopen 参数要和边缘网关保持一致

  • MQTT Topic 要和 ThingsBoard Dashboard 匹配

  • 控制命令必须有边界检查

  • 所有关键修改要能测试和回滚

这就是我在Project Velocity讲座多次提到的“三文件策略”：

overlay / prj.conf / main.c

对于 Zephyr 来说，如果只让 AI 写 main.c，很容易出现“代码看起来对，但根本无法在硬件上工作”的问题。

只有同时约束硬件映射、系统配置和应用逻辑，AI 生成的代码才更接近真实工程。

八、AI Agent 会淘汰哪类程序员？

AI Coding Agent 最先淘汰的，不是所有程序员，而是以下几类工作方式：

第一类：只会机械写代码的人。

如果一个任务已经被清楚定义，输入输出明确，测试也明确，那么 Agent 很快就能完成大部分编码工作。

第二类：不理解系统上下文的人。

只知道改当前文件，不理解上游数据、下游接口、硬件限制和运行环境，这类工作会越来越危险。

第三类：不写测试、不做验证的人。

AI 写代码很快，但也可能很快制造隐蔽 bug。如果工程师不建立验证体系，速度越快，风险越大。

第四类：不愿意学习新工具的人。

编程Agent 不会等你准备好。它会先改变团队的开发流程，然后改变招聘标准。

但同时，AI Agent 也会放大另一类工程师的价值。

九、AI编程Agent 会放大哪类工程师？

未来更有竞争力的工程师，往往具备以下能力：

第一，能把模糊需求变成清晰任务。

AI 很怕模糊指令。你说得越清楚，它越有价值。

第二，能设计系统边界。

知道哪些模块由 MCU 处理，哪些放到 Edge，哪些交给 Cloud，哪些必须保留人工审核。

第三，能建立测试和验证方法。

包括单元测试、接口测试、硬件在环测试、日志检查、回归测试和异常场景测试。

第四，能看懂 AI 生成的代码。

不会盲目信任，也不会因为 AI 生成得快就直接合并。

第五，能把 AI 放进工程流程。

让 Agent 参与文档、代码、测试、Review、CI、版本管理，而不是只当一个聊天机器人使用。

这类工程师不会被 AI 取代，反而会因为 AI 获得更强的生产力。

十、学生、研究生、工程师应该怎么准备？

对于学生来说，不要只学“如何让 AI 帮你写作业”。

更重要的是学会：

  • 如何描述问题

  • 如何拆解任务

  • 如何阅读 AI 生成的代码

  • 如何发现错误

  • 如何写测试

  • 如何用 Git 管理版本

对于研究生来说，不要只把 AI 当论文助手。

你应该学会用 Agent 帮你：

  • 阅读资料

  • 整理实验流程

  • 生成原型代码

  • 设计实验记录

  • 对比不同方案

  • 形成可复现的研究工程

对于工程师来说，不要把 Agent 当“高级自动补全”。

你应该把它看成一个需要管理的初级工程团队成员。

它可以很快，但需要你给方向。

它可以执行，但需要你做判断。

它可以生成，但需要你验证。

十一、我的结论：不要焦虑，但必须升级

所以，AI编程Agent 会不会取代程序员？

我的回答是：

它不会取代真正理解系统、能设计架构、能验证结果、能承担交付责任的工程师。

但它会取代很多低价值、重复性、缺乏上下文的编码工作。

这其实不是坏事。

因为工程师本来就不应该只做“代码搬运工”。

真正的工程能力，应该体现在：

  • 你能否把一个想法变成系统？

  • 你能否把一个 demo 变成产品？

  • 你能否把一段代码放进真实硬件、真实网络、真实客户场景里运行？

  • 你能否在出错时找到原因、控制风险、持续交付？

Project Velocity 给我的最大启发是：

AI 让代码生成变快，但工程交付并没有因此变简单。

相反，越是有 AI，越需要工程师定义边界、建立验证、管理复杂度。

结尾

AI编程Agent 的到来，不是程序员职业的结束。

它更像是一次分水岭。

一边是继续停留在“我会写代码”的旧模式。

另一边是进入“我能用 AI 组织工程交付”的新阶段。

未来，真正重要的问题不是：

AI 会不会写代码？

而是：

你能不能带着 AI，把代码变成一个可靠系统？

这才是从 Vibe Coding 走向 AI-Assisted Engineering 的关键。

也才是 AI 时代工程师真正的护城河。